Re: (subset) [PATCH v3 0/3] drm/msm/hdmi: turn MSM8996 HDMI PHY into OF clock provider
On Mon, 4 Jul 2022 19:11:45 +0300, Dmitry Baryshkov wrote: > On MSM8996 the HDMI PHY is the QMP PHY, it provides an HDMI PLL clock > used by the MMCC. Add support for providing this clock to the OF > framework by registerding the clock provider and adding #clock-cells > property to the DT node. > > The dt-bindings from this series depends on changes from [1] (part of > linux-next, but not of the msm-next yet). > > [...] Applied, thanks! [3/3] arm64: dts: qcom: msm8996: add #clock-cells and XO clock to the HDMI PHY node commit: 157b615066288f84e1812964a439603cfe8c1a19 Best regards, -- Bjorn Andersson
[PATCH -next 5/6] drm/amd/display: clean up some inconsistent indentings
clean up some inconsistent indentings Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2181 Reported-by: Abaci Robot Signed-off-by: Yang Li --- .../gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c index 2829f179f982..f6ffcf1596bc 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c @@ -1362,7 +1362,7 @@ static bool CalculatePrefetchSchedule( // - ((NumberOfCursors > 0 || GPUVMEnable || DCCEnable) ? - ((GPUVMEnable || myPipe->DCCEnable) ? (*DestinationLinesToRequestVMInVBlank + 2 * *DestinationLinesToRequestRowInVBlank) : 0.0); // TODO: Did someone else add this?? #else - LinesToRequestPrefetchPixelData = *DestinationLinesForPrefetch - *DestinationLinesToRequestVMInVBlank - 2 * *DestinationLinesToRequestRowInVBlank; + LinesToRequestPrefetchPixelData = *DestinationLinesForPrefetch - *DestinationLinesToRequestVMInVBlank - 2 * *DestinationLinesToRequestRowInVBlank; #endif #ifdef __DML_VBA_DEBUG__ -- 2.20.1.7.g153144c
[PATCH -next 2/6] drm/amd/display: clean up some inconsistent indentings
clean up some inconsistent indentings
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2178
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 10477ca52a41..47159e9a0884 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -406,14 +406,14 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct
amdgpu_device *adev)
if (adev->reset_domain->type != XGMI_HIVE) {
hive->reset_domain =
amdgpu_reset_create_reset_domain(XGMI_HIVE,
"amdgpu-reset-hive");
- if (!hive->reset_domain) {
- dev_err(adev->dev, "XGMI: failed
initializing reset domain for xgmi hive\n");
- ret = -ENOMEM;
- kobject_put(>kobj);
- kfree(hive);
- hive = NULL;
- goto pro_end;
- }
+ if (!hive->reset_domain) {
+ dev_err(adev->dev, "XGMI: failed initializing
reset domain for xgmi hive\n");
+ ret = -ENOMEM;
+ kobject_put(>kobj);
+ kfree(hive);
+ hive = NULL;
+ goto pro_end;
+ }
} else {
amdgpu_reset_get_reset_domain(adev->reset_domain);
hive->reset_domain = adev->reset_domain;
--
2.20.1.7.g153144c
[PATCH -next 6/6] drm/amd/display: clean up some inconsistent indentings
clean up some inconsistent indentings Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2182 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c index d40d32e380f4..1d84ae50311d 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c @@ -2636,7 +2636,7 @@ static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman _lib->vba.SrcActiveDrainRate, _lib->vba.TInitXFill, _lib->vba.TslvChk); - locals->XFCRemoteSurfaceFlipLatency[k] = + locals->XFCRemoteSurfaceFlipLatency[k] = dml_floor( mode_lib->vba.XFCRemoteSurfaceFlipDelay / (mode_lib->vba.HTotal[k] -- 2.20.1.7.g153144c
[PATCH -next 3/6] drm/amd/display: clean up some inconsistent indentings
clean up some inconsistent indentings Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2179 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c index 11f1435b8c07..2aa79b832e25 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c @@ -919,10 +919,10 @@ static struct hubp *dcn32_hubp_create( #undef REG_STRUCT #define REG_STRUCT hubp_regs - hubp_regs_init(0), - hubp_regs_init(1), - hubp_regs_init(2), - hubp_regs_init(3); + hubp_regs_init(0), + hubp_regs_init(1), + hubp_regs_init(2), + hubp_regs_init(3); if (hubp32_construct(hubp2, ctx, inst, _regs[inst], _shift, _mask)) -- 2.20.1.7.g153144c
[PATCH -next 4/6] drm/amd/display: clean up some inconsistent indentings
clean up some inconsistent indentings Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2180 Reported-by: Abaci Robot Signed-off-by: Yang Li --- .../amd/display/dc/dcn321/dcn321_resource.c | 26 +-- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c b/drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c index 1bbc0bdf5dc3..355b4b1d6628 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c @@ -820,11 +820,11 @@ static struct dce_i2c_hw *dcn321_i2c_hw_create( #undef REG_STRUCT #define REG_STRUCT i2c_hw_regs - i2c_inst_regs_init(1), - i2c_inst_regs_init(2), - i2c_inst_regs_init(3), - i2c_inst_regs_init(4), - i2c_inst_regs_init(5); + i2c_inst_regs_init(1), + i2c_inst_regs_init(2), + i2c_inst_regs_init(3), + i2c_inst_regs_init(4), + i2c_inst_regs_init(5); dcn2_i2c_hw_construct(dce_i2c_hw, ctx, inst, _hw_regs[inst], _shifts, _masks); @@ -922,10 +922,10 @@ static struct hubp *dcn321_hubp_create( #undef REG_STRUCT #define REG_STRUCT hubp_regs - hubp_regs_init(0), - hubp_regs_init(1), - hubp_regs_init(2), - hubp_regs_init(3); + hubp_regs_init(0), + hubp_regs_init(1), + hubp_regs_init(2), + hubp_regs_init(3); if (hubp32_construct(hubp2, ctx, inst, _regs[inst], _shift, _mask)) @@ -1670,10 +1670,10 @@ static bool dcn321_resource_construct( #undef REG_STRUCT #define REG_STRUCT abm_regs - abm_regs_init(0), - abm_regs_init(1), - abm_regs_init(2), - abm_regs_init(3); + abm_regs_init(0), + abm_regs_init(1), + abm_regs_init(2), + abm_regs_init(3); #undef REG_STRUCT #define REG_STRUCT dccg_regs -- 2.20.1.7.g153144c
[PATCH -next 1/6] drm/amd/display: clean up some inconsistent indentings
clean up some inconsistent indentings Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2177 Reported-by: Abaci Robot Signed-off-by: Yang Li --- .../gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c index 4e3356d12147..8dfe639b6508 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c @@ -1051,10 +1051,10 @@ static bool CalculatePrefetchSchedule( bytes_pp = myPipe->BytePerPixelY + myPipe->BytePerPixelC; /*rev 99*/ prefetch_bw_pr = dml_min(1, bytes_pp * myPipe->PixelClock / (double) myPipe->DPPPerPlane); -max_Tsw = dml_max(PrefetchSourceLinesY, PrefetchSourceLinesC) * LineTime; + max_Tsw = dml_max(PrefetchSourceLinesY, PrefetchSourceLinesC) * LineTime; prefetch_sw_bytes = PrefetchSourceLinesY * swath_width_luma_ub * myPipe->BytePerPixelY + PrefetchSourceLinesC * swath_width_chroma_ub * myPipe->BytePerPixelC; prefetch_bw_oto = dml_max(bytes_pp * myPipe->PixelClock / myPipe->DPPPerPlane, prefetch_sw_bytes / (dml_max(PrefetchSourceLinesY, PrefetchSourceLinesC) * LineTime)); -prefetch_bw_oto = dml_max(prefetch_bw_pr, prefetch_sw_bytes / max_Tsw); + prefetch_bw_oto = dml_max(prefetch_bw_pr, prefetch_sw_bytes / max_Tsw); min_Lsw = dml_max(1, dml_max(PrefetchSourceLinesY, PrefetchSourceLinesC) / max_vratio_pre); Lsw_oto = dml_ceil(4 * dml_max(prefetch_sw_bytes / prefetch_bw_oto / LineTime, min_Lsw), 1) / 4; -- 2.20.1.7.g153144c
Re: [PATCH 4/4] drm/i915: Handle all GTs on driver (un)load paths
On 9/14/2022 3:04 PM, Matt Roper wrote:
From: Tvrtko Ursulin
This, along with the changes already landed in commit 1c66a12ab431
("drm/i915: Handle each GT on init/release and suspend/resume") makes
engines from all GTs actually known to the driver.
To accomplish this we need to sprinkle a lot of for_each_gt calls around
but is otherwise pretty un-eventuful.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c| 46 ++
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47..9d1fc2477f80 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1661,7 +1661,8 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_gt_runtime_resume(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_runtime_resume(gt);
enable_rpm_wakeref_asserts(rpm);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f18cc6270b2b..0bf71082f21a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1128,6 +1128,8 @@ void i915_gem_drain_workqueue(struct drm_i915_private
*i915)
int i915_gem_init(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
int ret;
/* We need to fallback to 4K pages if host doesn't support huge gtt. */
@@ -1158,9 +1160,11 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
*/
intel_init_clock_gating(dev_priv);
- ret = intel_gt_init(to_gt(dev_priv));
- if (ret)
- goto err_unlock;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_gt_init(gt);
+ if (ret)
+ goto err_unlock;
+ }
return 0;
@@ -1173,8 +1177,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
err_unlock:
i915_gem_drain_workqueue(dev_priv);
- if (ret != -EIO)
- intel_uc_cleanup_firmwares(_gt(dev_priv)->uc);
+ if (ret != -EIO) {
+ for_each_gt(gt, dev_priv, i) {
+ intel_gt_driver_remove(gt);
+ intel_gt_driver_release(gt);
+ }
+
+ for_each_gt(gt, dev_priv, i)
+ intel_uc_cleanup_firmwares(>uc);
Any reason not to have the uc_cleanup in the same loop as the gt functions?
Also, you're looping intel_uc_cleanup_firmwares but not
intel_uc_fetch_firmwares(). Not an issue since the cleanup function will
skip if the fetch was not done, but I though it was worth mentioning. I
can include the loop for the fetch as part of the support for the media
GuC (which I'll send after this is merged).
+ }
if (ret == -EIO) {
/*
@@ -1182,10 +1193,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
* as wedged. But we only want to do this when the GPU is angry,
* for all other failure, such as an allocation failure, bail.
*/
- if (!intel_gt_is_wedged(to_gt(dev_priv))) {
- i915_probe_error(dev_priv,
-"Failed to initialize GPU, declaring it
wedged!\n");
- intel_gt_set_wedged(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i) {
+ if (!intel_gt_is_wedged(gt)) {
+ i915_probe_error(dev_priv,
+ "Failed to initialize GPU, declaring
it wedged!\n");
+ intel_gt_set_wedged(gt);
+ }
}
/* Minimal basic recovery for KMS */
@@ -1213,10 +1226,14 @@ void i915_gem_driver_unregister(struct drm_i915_private
*i915)
void i915_gem_driver_remove(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
intel_wakeref_auto_fini(_gt(dev_priv)->userfault_wakeref);
i915_gem_suspend_late(dev_priv);
- intel_gt_driver_remove(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_remove(gt);
dev_priv->uabi_engines = RB_ROOT;
/* Flush any outstanding unpin_work. */
@@ -1227,9 +1244,14 @@ void i915_gem_driver_remove(struct drm_i915_private
*dev_priv)
void i915_gem_driver_release(struct drm_i915_private *dev_priv)
{
- intel_gt_driver_release(to_gt(dev_priv));
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_release(gt);
- intel_uc_cleanup_firmwares(_gt(dev_priv)->uc);
+ for_each_gt(gt, dev_priv, i)
+ intel_uc_cleanup_firmwares(>uc);
Same
Re: [PATCH v3 7/8] drm/amd/display: Introduce KUnit tests to dc_dmub_srv library
Hi Maíra,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master
v6.0-rc5 next-20220914]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Ma-ra-Canal/drm-amd-display-Introduce-KUnit-to-Display-Mode-Library/20220913-000256
base: git://anongit.freedesktop.org/drm/drm drm-next
config: loongarch-randconfig-r026-20220914
(https://download.01.org/0day-ci/archive/20220915/202209150834.m0besply-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/50e2391775a6552a521c783a6fcd36942b906e3f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ma-ra-Canal/drm-amd-display-Introduce-KUnit-to-Display-Mode-Library/20220913-000256
git checkout 50e2391775a6552a521c783a6fcd36942b906e3f
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=loongarch SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:863:
drivers/gpu/drm/amd/amdgpu/../display/dc/../tests/dc/dc_dmub_srv_test.c: In
function 'populate_subvp_cmd_drr_info_test':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/../tests/dc/dc_dmub_srv_test.c:260:9:
>> error: implicit declaration of function 'populate_subvp_cmd_drr_info'; did
>> you mean 'populate_subvp_cmd_drr_info_test'?
>> [-Werror=implicit-function-declaration]
260 | populate_subvp_cmd_drr_info(test_param->dc,
test_param->subvp_pipe,
| ^~~
| populate_subvp_cmd_drr_info_test
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/core_types.h:32,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:31:
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h: At top
level:
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:137:22:
warning: 'SYNAPTICS_DEVICE_ID' defined but not used [-Wunused-const-variable=]
137 | static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
| ^~~
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:134:17:
warning: 'DP_SINK_BRANCH_DEV_NAME_7580' defined but not used
[-Wunused-const-variable=]
134 | static const u8 DP_SINK_BRANCH_DEV_NAME_7580[] = "7580\x80u";
| ^~~~
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:132:22:
warning: 'DP_SINK_DEVICE_STR_ID_2' defined but not used
[-Wunused-const-variable=]
132 | static const uint8_t DP_SINK_DEVICE_STR_ID_2[] = {7, 1, 8, 7, 5, 0};
| ^~~
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:131:22:
warning: 'DP_SINK_DEVICE_STR_ID_1' defined but not used
[-Wunused-const-variable=]
131 | static const uint8_t DP_SINK_DEVICE_STR_ID_1[] = {7, 1, 8, 7, 3, 0};
| ^~~
cc1: some warnings being treated as errors
vim +260 drivers/gpu/drm/amd/amdgpu/../display/dc/../tests/dc/dc_dmub_srv_test.c
246
247 KUNIT_ARRAY_PARAM(populate_subvp_cmd_drr_info,
populate_subvp_cmd_drr_info_cases,
248populate_subvp_cmd_drr_info_test_to_desc);
249
250 static void populate_subvp_cmd_drr_info_test(struct kunit *test)
251 {
252 const struct populate_subvp_cmd_drr_info_test_case *test_param =
253 test->param_value;
254 struct dmub_cmd_fw_assisted_mclk_switch_pipe_data_v2 *pipe_data;
255
256 pipe_data = kunit_kzalloc(test,
257sizeof(struct
dmub_cmd_fw_assisted_mclk_switch_pipe_data_v2),
258GFP_KERNEL);
259
> 260 populate_subvp_cmd_drr_info(test_param->dc,
> test_param->subvp_pipe,
261 test_param->vblank_pipe, pipe_data);
262
263 KUNIT_EXPECT_EQ(test, test_param->drr_in_use,
264
pipe_data->pipe_c
Re: [Intel-gfx] [PATCH 1/1] drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
On 9/14/2022 4:46 PM, john.c.harri...@intel.com wrote: From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected GuC version numbers to the latest firmware release for those platforms. You didn't record that this is a v2 (the patch name is different but it is the same patch ;) ). The changes LGTM: Reviewed-by: Daniele Ceraolo Spurio Daniele Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 1169e2a09da24..b91ad4aede1f7 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,12 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ - fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ + fw_def(DG1, 0, guc_maj(dg1, 70, 5)) \ fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ @@ -92,9 +94,11 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ - fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ + fw_def(DG1, 0, huc_raw(dg1)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(JASPERLAKE, 0, huc_mmp(ehl, 9, 0, 0)) \
Re: [PATCH 1/1] drm/i915/guc: Fix release build bug in 'remove log size module parameters'
On 9/12/2022 6:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A patch was merged to remove the GuC log size override module
parameters. That patch was broken and caused kernel error messages on
boot in non CONFIG_DEBUG_GUC|GEM builds:
[ 12.085121] i915 :00:02.0: [drm] *ERROR* Zero GuC log crash dump size!
[ 12.092035] i915 :00:02.0: [drm] *ERROR* Zero GuC log debug size!
So fit it.
Fixes: f54e515c9180 ("drm/i915/guc: Remove log size module parameters")
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Alan Previn
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Matthew Brost
Cc: Julia Lawall
Cc: Chris Wilson
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 25 +-
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index b071973ac41c1..55d3ef93e86f8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -36,24 +36,6 @@ struct guc_log_section {
const char *name;
};
-static s32 scale_log_param(struct intel_guc_log *log, const struct guc_log_section *section,
- s32 param)
-{
- /* -1 means default */
- if (param < 0)
- return section->default_val;
-
- /* Check for 32-bit overflow */
- if (param >= SZ_4K) {
- drm_err(_to_gt(log_to_guc(log))->i915->drm, "Size too large for
GuC %s log: %dMB!",
- section->name, param);
- return section->default_val;
- }
-
- /* Param units are 1MB */
- return param * SZ_1M;
-}
-
static void _guc_log_init_sizes(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
@@ -78,15 +60,10 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
"capture",
}
};
- s32 params[GUC_LOG_SECTIONS_LIMIT] = {
- GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE / SZ_1M,
- GUC_LOG_DEFAULT_DEBUG_BUFFER_SIZE / SZ_1M,
- GUC_LOG_DEFAULT_CAPTURE_BUFFER_SIZE / SZ_1M,
- };
int i;
for (i = 0; i < GUC_LOG_SECTIONS_LIMIT; i++)
- log->sizes[i].bytes = scale_log_param(log, sections + i,
params[i]);
+ log->sizes[i].bytes = sections[i].default_val;
/* If debug size > 1MB then bump default crash size to keep the same units */
if (log->sizes[GUC_LOG_SECTIONS_DEBUG].bytes >= SZ_1M &&
If the user can't tweak the values anymore then we can guarantee that
the sizes use the same units and change this if to a BUILD_BUG_ON() to
check that.
Not a blocker for the fix.
Reviewed-by: Daniele Ceraolo Spurio
Daniele
[PATCH drm-misc-next 7/8] drm/fsl-dcu: crtc: protect device resources after removal
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 37 ++
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 1dad90f701c8..c77df9b7893f 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -26,6 +27,10 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
struct drm_pending_vblank_event *event = crtc->state->event;
+ int idx;
+
+ if (!drm_dev_enter(dev, ))
+ return;
regmap_write(fsl_dev->regmap,
DCU_UPDATE_MODE, DCU_UPDATE_MODE_READREG);
@@ -40,6 +45,8 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irq(>dev->event_lock);
}
+
+ drm_dev_exit(idx);
}
static void fsl_dcu_drm_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -49,6 +56,10 @@ static void fsl_dcu_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
crtc);
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
+ int idx;
+
+ if (!drm_dev_enter(dev, ))
+ return;
/* always disable planes on the CRTC */
drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, true);
@@ -61,6 +72,8 @@ static void fsl_dcu_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
DCU_UPDATE_MODE_READREG);
clk_disable_unprepare(fsl_dev->pix_clk);
+
+ drm_dev_exit(idx);
}
static void fsl_dcu_drm_crtc_atomic_enable(struct drm_crtc *crtc,
@@ -68,6 +81,10 @@ static void fsl_dcu_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
{
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
+ int idx;
+
+ if (!drm_dev_enter(dev, ))
+ return;
clk_prepare_enable(fsl_dev->pix_clk);
regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
@@ -77,6 +94,8 @@ static void fsl_dcu_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
DCU_UPDATE_MODE_READREG);
drm_crtc_vblank_on(crtc);
+
+ drm_dev_exit(idx);
}
static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
@@ -87,6 +106,10 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
struct drm_display_mode *mode = >state->mode;
unsigned int pol = 0;
struct videomode vm;
+ int idx;
+
+ if (!drm_dev_enter(dev, ))
+ return;
clk_set_rate(fsl_dev->pix_clk, mode->clock * 1000);
@@ -122,6 +145,8 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
DCU_THRESHOLD_LS_BF_VS(BF_VS_VAL) |
DCU_THRESHOLD_OUT_BUF_HIGH(BUF_MAX_VAL) |
DCU_THRESHOLD_OUT_BUF_LOW(BUF_MIN_VAL));
+
+ drm_dev_exit(idx);
return;
}
@@ -137,11 +162,17 @@ static int fsl_dcu_drm_crtc_enable_vblank(struct drm_crtc
*crtc)
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
unsigned int value;
+ int idx;
+
+ if (!drm_dev_enter(dev, ))
+ return -ENODEV;
regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
value &= ~DCU_INT_MASK_VBLANK;
regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
+ drm_dev_exit(idx);
+
return 0;
}
@@ -150,10 +181,16 @@ static void fsl_dcu_drm_crtc_disable_vblank(struct
drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
unsigned int value;
+ int idx;
+
+ if (!drm_dev_enter(dev, ))
+ return;
regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
value |= DCU_INT_MASK_VBLANK;
regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
+
+ drm_dev_exit(idx);
}
static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs = {
--
2.37.3
[PATCH drm-misc-next 8/8] drm/fsl-dcu: remove trailing return statements
Remove the trailing return statements at the end of void functions.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 1 -
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index c77df9b7893f..23687551c831 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -147,7 +147,6 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
DCU_THRESHOLD_OUT_BUF_LOW(BUF_MIN_VAL));
drm_dev_exit(idx);
- return;
}
static const struct drm_crtc_helper_funcs fsl_dcu_drm_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index 1be3062a95df..d0a14b5b506e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -172,7 +172,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct
drm_plane *plane,
}
drm_dev_exit(idx);
- return;
}
static const struct drm_plane_helper_funcs fsl_dcu_drm_plane_helper_funcs = {
--
2.37.3
[PATCH drm-misc-next 4/8] drm/fsl-dcu: plane: use drm managed resources
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 4 ++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 25 -
2 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 0b70624260fc..1dad90f701c8 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -176,8 +176,8 @@ int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device
*fsl_dev)
fsl_dcu_drm_init_planes(drm);
primary = fsl_dcu_drm_primary_create_plane(drm);
- if (!primary)
- return -ENOMEM;
+ if (IS_ERR(primary))
+ return PTR_ERR(primary);
ret = drmm_crtc_init_with_planes(drm, crtc, primary, NULL,
_dcu_drm_crtc_funcs, NULL);
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index 91865956da02..23ff285da477 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -174,7 +174,6 @@ static const struct drm_plane_helper_funcs
fsl_dcu_drm_plane_helper_funcs = {
static const struct drm_plane_funcs fsl_dcu_drm_plane_funcs = {
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
- .destroy = drm_plane_helper_destroy,
.disable_plane = drm_atomic_helper_disable_plane,
.reset = drm_atomic_helper_plane_reset,
.update_plane = drm_atomic_helper_update_plane,
@@ -206,24 +205,18 @@ void fsl_dcu_drm_init_planes(struct drm_device *dev)
struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev)
{
struct drm_plane *primary;
- int ret;
-
- primary = kzalloc(sizeof(*primary), GFP_KERNEL);
- if (!primary) {
- DRM_DEBUG_KMS("Failed to allocate primary plane\n");
- return NULL;
- }
/* possible_crtc's will be filled in later by crtc_init */
- ret = drm_universal_plane_init(dev, primary, 0,
- _dcu_drm_plane_funcs,
- fsl_dcu_drm_plane_formats,
- ARRAY_SIZE(fsl_dcu_drm_plane_formats),
- NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
- if (ret) {
- kfree(primary);
- primary = NULL;
+ primary = drmm_universal_plane_alloc(dev, struct drm_plane, dev, 0,
+_dcu_drm_plane_funcs,
+fsl_dcu_drm_plane_formats,
+
ARRAY_SIZE(fsl_dcu_drm_plane_formats),
+NULL, DRM_PLANE_TYPE_PRIMARY,
NULL);
+ if (IS_ERR(primary)) {
+ DRM_DEBUG_KMS("Failed to create primary plane\n");
+ return primary;
}
+
drm_plane_helper_add(primary, _dcu_drm_plane_helper_funcs);
return primary;
--
2.37.3
[PATCH drm-misc-next 3/8] drm/fsl-dcu: crtc: use drmm_crtc_init_with_planes()
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes()
to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index e05311e2b0e0..0b70624260fc 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -159,7 +159,6 @@ static void fsl_dcu_drm_crtc_disable_vblank(struct drm_crtc
*crtc)
static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs = {
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
- .destroy = drm_crtc_cleanup,
.page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
.set_config = drm_atomic_helper_set_config,
@@ -180,8 +179,8 @@ int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device
*fsl_dev)
if (!primary)
return -ENOMEM;
- ret = drm_crtc_init_with_planes(drm, crtc, primary, NULL,
- _dcu_drm_crtc_funcs, NULL);
+ ret = drmm_crtc_init_with_planes(drm, crtc, primary, NULL,
+_dcu_drm_crtc_funcs, NULL);
if (ret) {
primary->funcs->destroy(primary);
return ret;
--
2.37.3
[PATCH drm-misc-next 6/8] drm/fsl-dcu: plane: protect device resources after removal
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index 23ff285da477..1be3062a95df 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,7 +66,10 @@ static void fsl_dcu_drm_plane_atomic_disable(struct
drm_plane *plane,
{
struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(plane->dev);
unsigned int value;
- int index;
+ int index, idx;
+
+ if (!drm_dev_enter(plane->dev, ))
+ return;
index = fsl_dcu_drm_plane_index(plane);
if (index < 0)
@@ -74,6 +78,8 @@ static void fsl_dcu_drm_plane_atomic_disable(struct drm_plane
*plane,
regmap_read(fsl_dev->regmap, DCU_CTRLDESCLN(index, 4), );
value &= ~DCU_LAYER_EN;
regmap_write(fsl_dev->regmap, DCU_CTRLDESCLN(index, 4), value);
+
+ drm_dev_exit(idx);
}
static void fsl_dcu_drm_plane_atomic_update(struct drm_plane *plane,
@@ -86,7 +92,10 @@ static void fsl_dcu_drm_plane_atomic_update(struct drm_plane
*plane,
struct drm_framebuffer *fb = plane->state->fb;
struct drm_gem_dma_object *gem;
unsigned int alpha = DCU_LAYER_AB_NONE, bpp;
- int index;
+ int index, idx;
+
+ if (!drm_dev_enter(plane->dev, ))
+ return;
if (!fb)
return;
@@ -162,6 +171,7 @@ static void fsl_dcu_drm_plane_atomic_update(struct
drm_plane *plane,
DCU_LAYER_PRE_SKIP(0));
}
+ drm_dev_exit(idx);
return;
}
--
2.37.3
[PATCH drm-misc-next 5/8] drm/fsl-dcu: use drm_dev_unplug()
When the driver is unbound, there might still be users in userspace having an open fd and are calling into the driver. While this is fine for drm managed resources, it is not for resources bound to the device/driver lifecycle, e.g. clocks or MMIO mappings. To prevent use-after-free issues we need to protect those resources with drm_dev_enter() and drm_dev_exit(). This does only work if we indicate that the drm device was unplugged, hence use drm_dev_unplug() instead of drm_dev_unregister(). Protecting the particular resources with drm_dev_enter()/drm_dev_exit() is handled by subsequent patches. Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c index 4139f674c5de..3ac57516c3fe 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c @@ -340,7 +340,7 @@ static int fsl_dcu_drm_remove(struct platform_device *pdev) struct fsl_dcu_drm_device *fsl_dev = platform_get_drvdata(pdev); struct drm_device *drm = _dev->base; - drm_dev_unregister(drm); + drm_dev_unplug(drm); clk_disable_unprepare(fsl_dev->clk); clk_unregister(fsl_dev->pix_clk); -- 2.37.3
[PATCH drm-misc-next 1/8] drm/fsl-dcu: use drmm_* to allocate driver structures
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 7 ++---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 30 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 19 +++---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 8 +++---
5 files changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 2af60d98f48f..a1b8ce70928a 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -171,15 +171,16 @@ int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device
*fsl_dev)
{
struct drm_plane *primary;
struct drm_crtc *crtc = _dev->crtc;
+ struct drm_device *drm = _dev->base;
int ret;
- fsl_dcu_drm_init_planes(fsl_dev->drm);
+ fsl_dcu_drm_init_planes(drm);
- primary = fsl_dcu_drm_primary_create_plane(fsl_dev->drm);
+ primary = fsl_dcu_drm_primary_create_plane(drm);
if (!primary)
return -ENOMEM;
- ret = drm_crtc_init_with_planes(fsl_dev->drm, crtc, primary, NULL,
+ ret = drm_crtc_init_with_planes(drm, crtc, primary, NULL,
_dcu_drm_crtc_funcs, NULL);
if (ret) {
primary->funcs->destroy(primary);
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index b4acc3422ba4..a47b72995fcf 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -168,6 +168,7 @@ static const struct drm_driver fsl_dcu_drm_driver = {
static int fsl_dcu_drm_pm_suspend(struct device *dev)
{
struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
+ struct drm_device *drm = _dev->base;
int ret;
if (!fsl_dev)
@@ -175,7 +176,7 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
disable_irq(fsl_dev->irq);
- ret = drm_mode_config_helper_suspend(fsl_dev->drm);
+ ret = drm_mode_config_helper_suspend(drm);
if (ret) {
enable_irq(fsl_dev->irq);
return ret;
@@ -189,6 +190,7 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
static int fsl_dcu_drm_pm_resume(struct device *dev)
{
struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
+ struct drm_device *drm = _dev->base;
int ret;
if (!fsl_dev)
@@ -202,10 +204,10 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
- fsl_dcu_drm_init_planes(fsl_dev->drm);
+ fsl_dcu_drm_init_planes(drm);
enable_irq(fsl_dev->irq);
- drm_mode_config_helper_resume(fsl_dev->drm);
+ drm_mode_config_helper_resume(drm);
return 0;
}
@@ -255,9 +257,10 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
int ret;
u8 div_ratio_shift = 0;
- fsl_dev = devm_kzalloc(dev, sizeof(*fsl_dev), GFP_KERNEL);
- if (!fsl_dev)
- return -ENOMEM;
+ fsl_dev = devm_drm_dev_alloc(dev, _dcu_drm_driver,
+typeof(*fsl_dev), base);
+ if (IS_ERR(fsl_dev))
+ return PTR_ERR(fsl_dev);
id = of_match_node(fsl_dcu_of_match, pdev->dev.of_node);
if (!id)
@@ -317,28 +320,19 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
fsl_dev->tcon = fsl_tcon_init(dev);
- drm = drm_dev_alloc(_dcu_drm_driver, dev);
- if (IS_ERR(drm)) {
- ret = PTR_ERR(drm);
- goto unregister_pix_clk;
- }
-
fsl_dev->dev = dev;
- fsl_dev->drm = drm;
fsl_dev->np = dev->of_node;
drm->dev_private = fsl_dev;
dev_set_drvdata(dev, fsl_dev);
ret = drm_dev_register(drm, 0);
if (ret < 0)
- goto put;
+ goto unregister_pix_clk;
drm_fbdev_generic_setup(drm, legacyfb_depth);
return 0;
-put:
- drm_dev_put(drm);
unregister_pix_clk:
clk_unregister(fsl_dev->pix_clk);
disable_clk:
@@ -349,9 +343,9 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
static int fsl_dcu_drm_remove(struct platform_device *pdev)
{
struct fsl_dcu_drm_device *fsl_dev = platform_get_drvdata(pdev);
+ struct drm_device *drm = _dev->base;
- drm_dev_unregister(fsl_dev->drm);
- drm_dev_put(fsl_dev->drm);
+ drm_dev_unregister(drm);
clk_disable_unprepare(fsl_dev->clk);
clk_unregister(fsl_dev->pix_clk);
diff --git
[PATCH drm-misc-next 2/8] drm/fsl-dcu: replace drm->dev_private with drm_to_fsl_dcu_drm_dev()
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
malidp_drm, hence we can use container_of() to get the struct drm_device
instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 12 ++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 13 -
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 8
4 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index a1b8ce70928a..e05311e2b0e0 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -24,7 +24,7 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
struct drm_pending_vblank_event *event = crtc->state->event;
regmap_write(fsl_dev->regmap,
@@ -48,7 +48,7 @@ static void fsl_dcu_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
crtc);
struct drm_device *dev = crtc->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
/* always disable planes on the CRTC */
drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, true);
@@ -67,7 +67,7 @@ static void fsl_dcu_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
clk_prepare_enable(fsl_dev->pix_clk);
regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
@@ -82,7 +82,7 @@ static void fsl_dcu_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
struct drm_connector *con = _dev->connector.base;
struct drm_display_mode *mode = >state->mode;
unsigned int pol = 0;
@@ -135,7 +135,7 @@ static const struct drm_crtc_helper_funcs
fsl_dcu_drm_crtc_helper_funcs = {
static int fsl_dcu_drm_crtc_enable_vblank(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
unsigned int value;
regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
@@ -148,7 +148,7 @@ static int fsl_dcu_drm_crtc_enable_vblank(struct drm_crtc
*crtc)
static void fsl_dcu_drm_crtc_disable_vblank(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
unsigned int value;
regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index a47b72995fcf..4139f674c5de 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -52,7 +52,7 @@ static const struct regmap_config fsl_dcu_regmap_config = {
static void fsl_dcu_irq_reset(struct drm_device *dev)
{
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
regmap_write(fsl_dev->regmap, DCU_INT_STATUS, ~0);
regmap_write(fsl_dev->regmap, DCU_INT_MASK, ~0);
@@ -61,7 +61,7 @@ static void fsl_dcu_irq_reset(struct drm_device *dev)
static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg)
{
struct drm_device *dev = arg;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
unsigned int int_status;
int ret;
@@ -91,7 +91,7 @@ static int fsl_dcu_irq_install(struct drm_device *dev,
unsigned int irq)
static void fsl_dcu_irq_uninstall(struct drm_device *dev)
{
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = drm_to_fsl_dcu_drm_dev(dev);
fsl_dcu_irq_reset(dev);
free_irq(fsl_dev->irq, dev);
@@ -99,7 +99,7 @@ static void fsl_dcu_irq_uninstall(struct
[PATCH drm-misc-next 0/8] drm/fsl-dcu: use drm managed resources
Hi, This patch series converts the driver to use drm managed resources to prevent potential use-after-free issues on driver unbind/rebind and to get rid of the usage of deprecated APIs. Danilo Krummrich (8): drm/fsl-dcu: use drmm_* to allocate driver structures drm/fsl-dcu: replace drm->dev_private with drm_to_fsl_dcu_drm_dev() drm/fsl-dcu: crtc: use drmm_crtc_init_with_planes() drm/fsl-dcu: plane: use drm managed resources drm/fsl-dcu: use drm_dev_unplug() drm/fsl-dcu: plane: protect device resources after removal drm/fsl-dcu: crtc: protect device resources after removal drm/fsl-dcu: remove trailing return statements drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 64 - drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 43 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 4 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 19 +++--- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 48 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 8 +-- 6 files changed, 108 insertions(+), 78 deletions(-) base-commit: 961bcdf956a4645745407a5d919be8757549b062 -- 2.37.3
[PATCH 1/1] drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names
From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected GuC version numbers to the latest firmware release for those platforms. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 1169e2a09da24..b91ad4aede1f7 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,12 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ - fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ + fw_def(DG1, 0, guc_maj(dg1, 70, 5)) \ fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ @@ -92,9 +94,11 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ - fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ + fw_def(DG1, 0, huc_raw(dg1)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(JASPERLAKE, 0, huc_mmp(ehl, 9, 0, 0)) \ -- 2.37.3
[PATCH 0/1] New GuC and new GuC/HuC names
From: John Harrison Update the GuC version numbers to expect the latest release. Also start using GuC/HuC firmware files with reduced version information in the file name. Signed-off-by: John Harrison John Harrison (1): drm/i915/uc: Update to latest GuC and use new-format GuC/HuC names drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) -- 2.37.3
[PATCH 4/4] drm/i915: Handle all GTs on driver (un)load paths
From: Tvrtko Ursulin
This, along with the changes already landed in commit 1c66a12ab431
("drm/i915: Handle each GT on init/release and suspend/resume") makes
engines from all GTs actually known to the driver.
To accomplish this we need to sprinkle a lot of for_each_gt calls around
but is otherwise pretty un-eventuful.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c| 46 ++
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47..9d1fc2477f80 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1661,7 +1661,8 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_gt_runtime_resume(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_runtime_resume(gt);
enable_rpm_wakeref_asserts(rpm);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f18cc6270b2b..0bf71082f21a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1128,6 +1128,8 @@ void i915_gem_drain_workqueue(struct drm_i915_private
*i915)
int i915_gem_init(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
int ret;
/* We need to fallback to 4K pages if host doesn't support huge gtt. */
@@ -1158,9 +1160,11 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
*/
intel_init_clock_gating(dev_priv);
- ret = intel_gt_init(to_gt(dev_priv));
- if (ret)
- goto err_unlock;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_gt_init(gt);
+ if (ret)
+ goto err_unlock;
+ }
return 0;
@@ -1173,8 +1177,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
err_unlock:
i915_gem_drain_workqueue(dev_priv);
- if (ret != -EIO)
- intel_uc_cleanup_firmwares(_gt(dev_priv)->uc);
+ if (ret != -EIO) {
+ for_each_gt(gt, dev_priv, i) {
+ intel_gt_driver_remove(gt);
+ intel_gt_driver_release(gt);
+ }
+
+ for_each_gt(gt, dev_priv, i)
+ intel_uc_cleanup_firmwares(>uc);
+ }
if (ret == -EIO) {
/*
@@ -1182,10 +1193,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
* as wedged. But we only want to do this when the GPU is angry,
* for all other failure, such as an allocation failure, bail.
*/
- if (!intel_gt_is_wedged(to_gt(dev_priv))) {
- i915_probe_error(dev_priv,
-"Failed to initialize GPU, declaring
it wedged!\n");
- intel_gt_set_wedged(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i) {
+ if (!intel_gt_is_wedged(gt)) {
+ i915_probe_error(dev_priv,
+ "Failed to initialize GPU,
declaring it wedged!\n");
+ intel_gt_set_wedged(gt);
+ }
}
/* Minimal basic recovery for KMS */
@@ -1213,10 +1226,14 @@ void i915_gem_driver_unregister(struct drm_i915_private
*i915)
void i915_gem_driver_remove(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
intel_wakeref_auto_fini(_gt(dev_priv)->userfault_wakeref);
i915_gem_suspend_late(dev_priv);
- intel_gt_driver_remove(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_remove(gt);
dev_priv->uabi_engines = RB_ROOT;
/* Flush any outstanding unpin_work. */
@@ -1227,9 +1244,14 @@ void i915_gem_driver_remove(struct drm_i915_private
*dev_priv)
void i915_gem_driver_release(struct drm_i915_private *dev_priv)
{
- intel_gt_driver_release(to_gt(dev_priv));
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_release(gt);
- intel_uc_cleanup_firmwares(_gt(dev_priv)->uc);
+ for_each_gt(gt, dev_priv, i)
+ intel_uc_cleanup_firmwares(>uc);
i915_gem_drain_freed_objects(dev_priv);
--
2.37.3
[PATCH 2/4] drm/i915: Make GEM resume all engines
From: Tvrtko Ursulin
Walk all GTs from i915_gem_resume when resuming engines.
Cc: Andi Shyti
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 3428f735e786..2c80cc8362b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -212,7 +212,8 @@ int i915_gem_freeze_late(struct drm_i915_private *i915)
void i915_gem_resume(struct drm_i915_private *i915)
{
- int ret;
+ struct intel_gt *gt;
+ int ret, i, j;
GEM_TRACE("%s\n", dev_name(i915->drm.dev));
@@ -224,8 +225,25 @@ void i915_gem_resume(struct drm_i915_private *i915)
* guarantee that the context image is complete. So let's just reset
* it and start again.
*/
- intel_gt_resume(to_gt(i915));
+ for_each_gt(gt, i915, i)
+ if (intel_gt_resume(gt))
+ goto err_wedged;
ret = lmem_restore(i915, I915_TTM_BACKUP_ALLOW_GPU);
GEM_WARN_ON(ret);
+
+ return;
+
+err_wedged:
+ for_each_gt(gt, i915, j) {
+ if (!intel_gt_is_wedged(gt)) {
+ dev_err(i915->drm.dev,
+ "Failed to re-initialize GPU[%u], declaring it
wedged!\n",
+ j);
+ intel_gt_set_wedged(gt);
+ }
+
+ if (j == i)
+ break;
+ }
}
--
2.37.3
[PATCH 0/4] Further multi-gt handling
Now that MTL is going to start providing two GTs, there are a few more places in the driver that need to iterate over each GT instead of operating directly on gt0. Also some more deliberate cleanup is needed, in cases where we fail GT/engine initialization after the first GT has been fully setup. Cc: Daniele Ceraolo Spurio Chris Wilson (1): drm/i915/gt: Cleanup partial engine discovery failures Tvrtko Ursulin (3): drm/i915: Make GEM resume all engines drm/i915: Make GEM suspend all GTs drm/i915: Handle all GTs on driver (un)load paths drivers/gpu/drm/i915/gem/i915_gem_pm.c| 33 ++-- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 ++-- drivers/gpu/drm/i915/i915_driver.c| 3 +- drivers/gpu/drm/i915/i915_gem.c | 46 +-- 4 files changed, 78 insertions(+), 20 deletions(-) -- 2.37.3
[PATCH 3/4] drm/i915: Make GEM suspend all GTs
From: Tvrtko Ursulin
Walk all GTs when suspending.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 2c80cc8362b6..e5bfb6be9f7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -22,6 +22,9 @@
void i915_gem_suspend(struct drm_i915_private *i915)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
GEM_TRACE("%s\n", dev_name(i915->drm.dev));
intel_wakeref_auto(_gt(i915)->userfault_wakeref, 0);
@@ -36,7 +39,8 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* state. Fortunately, the kernel_context is disposable and we do
* not rely on its state.
*/
- intel_gt_suspend_prepare(to_gt(i915));
+ for_each_gt(gt, i915, i)
+ intel_gt_suspend_prepare(gt);
i915_gem_drain_freed_objects(i915);
}
@@ -131,7 +135,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
>mm.purge_list,
NULL
}, **phase;
+ struct intel_gt *gt;
unsigned long flags;
+ unsigned int i;
bool flush = false;
/*
@@ -154,7 +160,8 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
* machine in an unusable condition.
*/
- intel_gt_suspend_late(to_gt(i915));
+ for_each_gt(gt, i915, i)
+ intel_gt_suspend_late(gt);
spin_lock_irqsave(>mm.obj_lock, flags);
for (phase = phases; *phase; phase++) {
--
2.37.3
[PATCH 1/4] drm/i915/gt: Cleanup partial engine discovery failures
From: Chris Wilson
If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have 'engine->release == NULL' and so will leak any of the
common objects allocated.
Signed-off-by: Chris Wilson
Cc: Janusz Krzysztofik
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1f7188129cd1..bff12b4ec314 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1196,6 +1196,12 @@ void intel_engine_destroy_pinned_context(struct
intel_context *ce)
intel_context_put(ce);
}
+static void destroy_pinned_context(struct intel_context *ce)
+{
+ if (ce)
+ intel_engine_destroy_pinned_context(ce);
+}
+
static struct intel_context *
create_kernel_context(struct intel_engine_cs *engine)
{
@@ -1274,8 +1280,13 @@ int intel_engines_init(struct intel_gt *gt)
return err;
err = setup(engine);
- if (err)
+ if (err) {
+ intel_engine_cleanup_common(engine);
return err;
+ }
+
+ /* The backend should now be responsible for cleanup */
+ GEM_BUG_ON(engine->release == NULL);
err = engine_init_common(engine);
if (err)
@@ -1307,8 +1318,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
if (engine->default_state)
fput(engine->default_state);
- if (engine->kernel_context)
- intel_engine_destroy_pinned_context(engine->kernel_context);
+ destroy_pinned_context(engine->kernel_context);
GEM_BUG_ON(!llist_empty(>barrier_tasks));
cleanup_status_page(engine);
--
2.37.3
Re: [PATCH 1/5] dt-bindings: arm: mediatek: mmsys: change compatible for MT8195
On 14/09/2022 20:23, Jason-JH.Lin wrote:
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
component). It makes VDOSYS1 supports the HDR function while it's not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys hardwares to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195 SoC
binding")
Signed-off-by: Jason-JH.Lin
Signed-off-by: Bo-Chen Chen
Acked-by: Krzysztof Kozlowski
I'm not sure Krzysztof gave his Acked-by tag.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml| 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index 6ad023eec193..a53b32c0a608 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -32,6 +32,8 @@ properties:
- mediatek,mt8186-mmsys
- mediatek,mt8192-mmsys
- mediatek,mt8195-mmsys
+ - mediatek,mt8195-vdosys0
As I said in the last submission, we should make mediatek,mt8195-mmsys as a
fallback of vdosys0. Actually mediatek,mt8195-mmsys is only used for the
fallback of vdosys0.
Regards,
Matthias
+ - mediatek,mt8195-vdosys1
- mediatek,mt8365-mmsys
- const: syscon
- items:
Re: [PATCH 5/5] dt-bindings: arm: mediatek: mmsys: remove the unused compatible for mt8195
On 14/09/2022 20:23, Jason-JH.Lin wrote:
The compatible properties of mt8195 have changed to mediatek,mt8195-vdosys0
and mediatek,mt8195-vdosys1 from mediatek,mt895-mmsys, so remove the unused
compatible.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195 SoC
binding")
Signed-off-by: Jason-JH.Lin
Signed-off-by: Bo-Chen Chen
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index a53b32c0a608..bfbdd30d2092 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -31,7 +31,6 @@ properties:
- mediatek,mt8183-mmsys
- mediatek,mt8186-mmsys
- mediatek,mt8192-mmsys
- - mediatek,mt8195-mmsys
Should be part of the first patch. As described in the review.
Regards,
Matthias
- mediatek,mt8195-vdosys0
- mediatek,mt8195-vdosys1
- mediatek,mt8365-mmsys
Re: [PATCH 2/5] soc: mediatek: change compatible name for mt8195
On 14/09/2022 20:23, Jason-JH.Lin wrote:
In mt8195, vdosys0 and vdosys1 are 2 different function blocks
for mediatek-drm, so using 2 compatible instead of identifying
multiple mmsys by io_start.
Fixes: b804923b7ccb ("soc: mediatek: add mtk-mmsys support for mt8195 vdosys0")
Signed-off-by: Jason-JH.Lin
From what I have seen we can just revert the commit. No fixes tag needed, it
does not fix any (runtime) bug.
Regards,
Matthias
---
drivers/soc/mediatek/mtk-mmsys.c | 141 +--
drivers/soc/mediatek/mtk-mmsys.h | 6 --
2 files changed, 21 insertions(+), 126 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 06d8e83a2cb5..e1c653f3abc0 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -26,61 +26,26 @@ static const struct mtk_mmsys_driver_data
mt2701_mmsys_driver_data = {
.num_routes = ARRAY_SIZE(mmsys_default_routing_table),
};
-static const struct mtk_mmsys_match_data mt2701_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
.clk_driver = "clk-mt2712-mm",
.routes = mmsys_default_routing_table,
.num_routes = ARRAY_SIZE(mmsys_default_routing_table),
};
-static const struct mtk_mmsys_match_data mt2712_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt6779_mmsys_driver_data = {
.clk_driver = "clk-mt6779-mm",
};
-static const struct mtk_mmsys_match_data mt6779_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
.clk_driver = "clk-mt6797-mm",
};
-static const struct mtk_mmsys_match_data mt6797_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt8167_mmsys_driver_data = {
.clk_driver = "clk-mt8167-mm",
.routes = mt8167_mmsys_routing_table,
.num_routes = ARRAY_SIZE(mt8167_mmsys_routing_table),
};
-static const struct mtk_mmsys_match_data mt8167_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
.clk_driver = "clk-mt8173-mm",
.routes = mmsys_default_routing_table,
@@ -88,13 +53,6 @@ static const struct mtk_mmsys_driver_data
mt8173_mmsys_driver_data = {
.sw0_rst_offset = MT8183_MMSYS_SW0_RST_B,
};
-static const struct mtk_mmsys_match_data mt8173_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
.clk_driver = "clk-mt8183-mm",
.routes = mmsys_mt8183_routing_table,
@@ -102,13 +60,6 @@ static const struct mtk_mmsys_driver_data
mt8183_mmsys_driver_data = {
.sw0_rst_offset = MT8183_MMSYS_SW0_RST_B,
};
-static const struct mtk_mmsys_match_data mt8183_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt8186_mmsys_driver_data = {
.clk_driver = "clk-mt8186-mm",
.routes = mmsys_mt8186_routing_table,
@@ -116,13 +67,6 @@ static const struct mtk_mmsys_driver_data
mt8186_mmsys_driver_data = {
.sw0_rst_offset = MT8186_MMSYS_SW0_RST_B,
};
-static const struct mtk_mmsys_match_data mt8186_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
.clk_driver = "clk-mt8192-mm",
.routes = mmsys_mt8192_routing_table,
@@ -130,66 +74,29 @@ static const struct mtk_mmsys_driver_data
mt8192_mmsys_driver_data = {
.sw0_rst_offset = MT8186_MMSYS_SW0_RST_B,
};
-static const struct mtk_mmsys_match_data mt8192_mmsys_match_data = {
- .num_drv_data = 1,
- .drv_data = {
- _mmsys_driver_data,
- },
-};
-
static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
- .io_start = 0x1c01a000,
.clk_driver = "clk-mt8195-vdo0",
.routes = mmsys_mt8195_routing_table,
.num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table),
};
static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
- .io_start = 0x1c10,
.clk_driver = "clk-mt8195-vdo1",
};
-static const struct mtk_mmsys_match_data mt8195_mmsys_match_data = {
- .num_drv_data = 2,
-
Re: [PATCH V3 46/47] drm/amd/display: Fix failures of disabling primary plans
On 2022-09-14 10:55, Michel Dänzer wrote:
[ Adding the dri-devel list ]
On 2022-09-14 18:30, Alex Hung wrote:
On 2022-09-14 07:40, Michel Dänzer wrote:
On 2022-09-14 15:31, Michel Dänzer wrote:
On 2022-09-14 07:10, Wayne Lin wrote:
From: Alex Hung
[Why & How]
This fixes kernel errors when IGT disables primary planes during the
tests kms_universal_plane::functional_test_pipe/pageflip_test_pipe.
NAK.
This essentially reverts commit b836a274b797 ("drm/amdgpu/dc: Require primary plane
to be enabled whenever the CRTC is") (except that it goes even further and
completely removes the requirement for any HW plane to be enabled when the HW cursor is),
so it would reintroduce the issues described in that commit log.
Actually not exactly the same issues, due to going even further than reverting
my fix.
Instead, the driver will claim that an atomic commit which enables the CRTC and
the cursor plane, while leaving all other KMS planes disabled, succeeds. But
the HW cursor will not actually be visible.
I did not observe problems with cursors (GNOME 42.4 - desktop and youtube/mpv
video playback: windowed/fullscreen). Are there steps to reproduce cursor
problems?
As described in my last follow-up e-mail: An atomic KMS commit which enables
the CRTC and the cursor plane, but disables all other KMS planes for the CRTC.
The commit will succeed, but will not result in the HW cursor being actually
visible. (I don't know of any specific application or test which exercises this)
Did you mean cursor plane depends on primary plane (i.e. no primary
plane = no visible HW cursor)? If there is no primary plane, what
scenario would it be required to draw a cursor?
If this is a rare case, would it still be a concern?
Also see the commit log of bc92c06525e5 ("drm/amd/display: Allow commits with no
planes active").
Does it mean dm_crtc_helper_atomic_check does not need to return -EINVAL
if there is no active cursor because there are no cursors to be shown
anyways, as shown in the below diff:
+static bool does_crtc_have_active_cursor(struct drm_crtc_state
*new_crtc_state)
+{
+ struct drm_device *dev = new_crtc_state->crtc->dev;
+ struct drm_plane *plane;
+
+ drm_for_each_plane_mask(plane, dev, new_crtc_state->plane_mask) {
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
+ return true;
+ }
+
+ return false;
+}
+
static int dm_crtc_helper_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -383,7 +396,8 @@ static int dm_crtc_helper_atomic_check(struct
drm_crtc *crtc,
* userspace which stops using the HW cursor altogether in
response to the resulting EINVAL.
*/
if (crtc_state->enable &&
- !(crtc_state->plane_mask & drm_plane_mask(crtc->primary))) {
+ !(crtc_state->plane_mask & drm_plane_mask(crtc->primary)) &&
+ does_crtc_have_active_cursor(crtc_state)) {
Note: This would fix kms_universal_plane but not kms_cursor_legacy.
If IGT tests disable the primary plane while leaving the CRTC enabled, those
tests are broken and need to be fixed instead.
There are IGT cursor tests fixed by this:
igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions
igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size
It also reduces amdgpu workaround in IGT's kms_concurrent:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F499382%2F%3Fseries%3D107734%26rev%3D1data=05%7C01%7Calex.hung%40amd.com%7Cc757c9e4fbda4f8474a308da9671f920%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637987713521806985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=XRRvilVZMBALIWHAOLArxjiAcgqQ%2FwNRnuUUJCTOYzY%3Dreserved=0
The change affect multiple IGT tests. Adding amdgpu-specific workarounds to
each of the IGT tests is not an ideal solution.
It's not amdgpu specific, other atomic KMS drivers have the same restriction. IGT tests
need to be able to handle this. See e.g. 88e379cef970 ("kms_cursor_legacy: Keep
primary plane enabled for XRGB overlay fallback").
Commit 88e379cef970 adds the following change to keep primary plane enabled:
+ igt_plane_set_fb(primary, prim_fb)
but kms_universal_plane fails at testing disabling primary plane, ex.
tests/kms_universal_plane.c:
192 /* Step 5: Universal API's, disable primary plane (CRC 5) */
193 igt_plane_set_fb(primary, NULL);
194 igt_display_commit2(display, COMMIT_UNIVERSAL);
195 igt_pipe_crc_collect_crc(test.pipe_crc, _5);
...
230 /* Step 11: Disable primary plane */
231 igt_plane_set_fb(primary, NULL);
232 igt_display_commit2(display, COMMIT_UNIVERSAL);
and so on.
P.S. Per above, this patch should never have made it this far without getting
in touch with me directly.
diff
[linux-next:master] BUILD REGRESSION f117c01187301a087412bd6697fcf5463cb427d8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: f117c01187301a087412bd6697fcf5463cb427d8 Add linux-next specific files for 20220914 Error/Warning reports: https://lore.kernel.org/linux-mm/202209150141.wgbakqmx-...@intel.com https://lore.kernel.org/llvm/202209141913.nxzv3hwm-...@intel.com Error/Warning: (recently discovered and may have been fixed) ERROR: modpost: "devm_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_memremap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_memunmap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/clk/xilinx/clk-xlnx-clock-wizard.ko] undefined! ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined! ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined! arch/parisc/lib/iomap.c:363:5: warning: no previous prototype for 'ioread64_lo_hi' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:373:5: warning: no previous prototype for 'ioread64_hi_lo' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:448:6: warning: no previous prototype for 'iowrite64_lo_hi' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:454:6: warning: no previous prototype for 'iowrite64_hi_lo' [-Wmissing-prototypes] drivers/gpu/drm/drm_atomic_helper.c:802: warning: expecting prototype for drm_atomic_helper_check_wb_connector_state(). Prototype was for drm_atomic_helper_check_wb_encoder_state() instead drivers/scsi/qla2xxx/qla_os.c:2854:23: warning: assignment to 'struct trace_array *' from 'int' makes pointer from integer without a cast [-Wint-conversion] drivers/scsi/qla2xxx/qla_os.c:2854:25: error: implicit declaration of function 'trace_array_get_by_name'; did you mean 'trace_array_set_clr_event'? [-Werror=implicit-function-declaration] drivers/scsi/qla2xxx/qla_os.c:2869:9: error: implicit declaration of function 'trace_array_put' [-Werror=implicit-function-declaration] sound/soc/codecs/tas2562.c:442:13: warning: variable 'ret' set but not used [-Wunused-but-set-variable] Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead | |-- drivers-scsi-qla2xxx-qla_os.c:error:implicit-declaration-of-function-trace_array_get_by_name | |-- drivers-scsi-qla2xxx-qla_os.c:error:implicit-declaration-of-function-trace_array_put | |-- drivers-scsi-qla2xxx-qla_os.c:warning:assignment-to-struct-trace_array-from-int-makes-pointer-from-integer-without-a-cast | `-- sound-soc-codecs-tas2562.c:warning:variable-ret-set-but-not-used |-- arc-allyesconfig | |-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead | `-- sound-soc-codecs-tas2562.c:warning:variable-ret-set-but-not-used |-- arc-randconfig-r043-20220914 | |-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead | `-- sound-soc-codecs-tas2562.c:warning:variable-ret-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead | `-- sound-soc-codecs-tas2562.c:warning:variable-ret-set-but-not-used |-- arm-buildonly-randconfig-r003-20220914 | |-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead | `-- sound-soc-codecs-tas2562.c:warning:variable-ret-set-but-not-used |-- arm-defconfig | `-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead |-- arm64-allyesconfig | |-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead | `-- sound-soc-codecs-tas2562.c:warning:variable-ret-set-but-not-used |-- arm64-randconfig-r036-20220914 | `-- drivers-gpu-drm-drm_atomic_helper.c:warning:expecting-prototype-for-drm_atomic_helper_check_wb_connector_state().-Prototype-was-for-drm_atomic_helper_check_wb_encoder_state()-instead |-- i386-allyesconfig | |-- drivers-gpu-drm-drm_atomic_hel
[pull] amdgpu drm-fixes-6.0
Hi Dave, Daniel, Fixes for 6.0. A bit bigger than usual, but this is mainly caused by some regression fixes which took a while to sort out and validate. The rest is fixes for new IPs added in the 6.0 cycle. The following changes since commit 2edb79a5fb303dff577d6a0c7d571c3bab1d1455: Merge tag 'drm-intel-fixes-2022-09-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-09-10 01:42:47 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.0-2022-09-14 for you to fetch changes up to a8671493d2074950553da3cf07d1be43185ef6c6: drm/amdgpu: make sure to init common IP before gmc (2022-09-14 14:21:49 -0400) amd-drm-fixes-6.0-2022-09-14: amdgpu: - BACO fixes for some RDNA2 boards - PCI AER fixes uncovered by a core PCI change - Properly hook up dirtyfb helper - RAS fixes for GC 11.x - TMR fix - DCN 3.2.x fixes - DCN 3.1.4 fixes - LLVM DML stack size fixes Alex Deucher (4): drm/amdgpu: add HDP remap functionality to nbio 7.7 drm/amdgpu: move nbio ih_doorbell_range() into ih code for vega drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega drm/amdgpu: make sure to init common IP before gmc Alvin Lee (3): drm/amd/display: Update MBLK calculation for SubVP drm/amd/display: SW cursor fallback for SubVP drm/amd/display: Refactor SubVP calculation to remove FPU Aric Cyr (1): drm/amd/display: Fix divide by zero in DML Aurabindo Pillai (2): drm/amd/display: Revert "Fallback to SW cursor if SubVP + cursor too big" drm/amd/display: add workaround for subvp cursor corruption for DCN32/321 Candice Li (2): drm/amdgpu: Enable full reset when RAS is supported on gc v11_0_0 drm/amdgpu: Skip reset error status for psp v13_0_0 Duncan Ma (1): drm/amd/display: Correct dram channel width for dcn314 Guchun Chen (1): drm/amd/pm: disable BACO entry/exit completely on several sienna cichlid cards Hamza Mahfooz (1): drm/amdgpu: use dirty framebuffer helper Leo Chen (1): drm/amd/display: Fixing DIG FIFO Error Lijo Lazar (1): drm/amdgpu: Don't enable LTR if not supported Nathan Chancellor (5): drm/amd/display: Reduce number of arguments of dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport() drm/amd/display: Reduce number of arguments of dml32_CalculatePrefetchSchedule() drm/amd/display: Reduce number of arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport() drm/amd/display: Reduce number of arguments of dml31's CalculateFlipSchedule() drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage Nicholas Kazlauskas (2): drm/amd/display: Hook up DCN314 specific dml implementation drm/amd/display: Relax swizzle checks for video non-RGB formats on DCN314 Rodrigo Siqueira (2): drm/amd/display: Fix compilation errors on DCN314 drm/amd/display: Enable dlg and vba compilation for dcn314 Taimur Hassan (1): drm/amd/display: Round cursor width up for MALL allocation Yang Wang (1): drm/amdgpu: change the alignment size of TMR BO to 1M Yao Wang1 (1): drm/amd/display: Limit user regamma to a valid value drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 3 +- drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 9 +- drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c | 9 +- drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 9 +- drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 9 + drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 5 + drivers/gpu/drm/amd/amdgpu/soc15.c | 25 -- drivers/gpu/drm/amd/amdgpu/soc21.c | 1 + drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 4 + drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 4 + .../amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 2 + drivers/gpu/drm/amd/display/dc/core/dc_stream.c| 2 +- drivers/gpu/drm/amd/display/dc/dc.h| 1 + drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 89 +++-- .../display/dc/dcn314/dcn314_dio_stream_encoder.c | 3 +- drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubp.c | 24 +- drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hwseq.c | 24 +- .../gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 4 +- .../gpu/drm/amd/display/dc/dcn32/dcn32_resource.h | 3 + .../amd/display/dc/dcn32/dcn32_resource_helpers.c | 59 ++- .../drm/amd/display/dc/dcn321/dcn321_resource.c| 4 +- drivers/gpu/drm/amd/display/dc/dml/Makefile| 3 +
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Am 14.09.22 um 20:14 schrieb Stephen Boyd: Quoting Stefan Wahren (2022-09-14 11:09:04) Am 14.09.22 um 20:05 schrieb Stephen Boyd: Quoting Stefan Wahren (2022-09-14 10:45:48) Am 14.09.22 um 17:50 schrieb Stephen Boyd: Furthermore, I wonder if even that part needs to be implemented. Why not make a direct call to rpi_firmware_property() and get the max rate? All of that can live in the drm driver. Making it a generic API that takes a 'struct clk' means that it looks like any clk can be passed, when that isn't true. It would be better to restrict it to the one use case so that the scope of the problem doesn't grow. I understand that it duplicates a few lines of code, but that looks like a fair tradeoff vs. exposing an API that can be used for other clks in the future. it would be nice to keep all the Rpi specific stuff out of the DRM driver, since there more users of it. Instead of 'all' did you mean 'any'? yes Why? This firmware is written specific for the Raspberry Pi and not stable from interface point of view. So i'm afraid that the DRM driver is only usable for the Raspberry Pi at the end with all these board specific dependencies. Emma invested a lot of time to make this open source and now it looks that like that more and more functionality moves back to firmware.
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Quoting Stefan Wahren (2022-09-14 11:09:04) > Am 14.09.22 um 20:05 schrieb Stephen Boyd: > > Quoting Stefan Wahren (2022-09-14 10:45:48) > >> Am 14.09.22 um 17:50 schrieb Stephen Boyd: > >>> Furthermore, I wonder if even that part needs to be implemented. Why > >>> not make a direct call to rpi_firmware_property() and get the max rate? > >>> All of that can live in the drm driver. Making it a generic API that > >>> takes a 'struct clk' means that it looks like any clk can be passed, > >>> when that isn't true. It would be better to restrict it to the one use > >>> case so that the scope of the problem doesn't grow. I understand that it > >>> duplicates a few lines of code, but that looks like a fair tradeoff vs. > >>> exposing an API that can be used for other clks in the future. > >> it would be nice to keep all the Rpi specific stuff out of the DRM > >> driver, since there more users of it. > > Instead of 'all' did you mean 'any'? > yes Another idea is to populate an OPP table in the rpi firmware driver for this platform device with the adjusted max frequency. That would be an SoC/firmware agnostic interface that expresses the constraints. I'm almost certain we talked about this before.
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Quoting Stefan Wahren (2022-09-14 11:09:04) > Am 14.09.22 um 20:05 schrieb Stephen Boyd: > > Quoting Stefan Wahren (2022-09-14 10:45:48) > >> Am 14.09.22 um 17:50 schrieb Stephen Boyd: > >>> Furthermore, I wonder if even that part needs to be implemented. Why > >>> not make a direct call to rpi_firmware_property() and get the max rate? > >>> All of that can live in the drm driver. Making it a generic API that > >>> takes a 'struct clk' means that it looks like any clk can be passed, > >>> when that isn't true. It would be better to restrict it to the one use > >>> case so that the scope of the problem doesn't grow. I understand that it > >>> duplicates a few lines of code, but that looks like a fair tradeoff vs. > >>> exposing an API that can be used for other clks in the future. > >> it would be nice to keep all the Rpi specific stuff out of the DRM > >> driver, since there more users of it. > > Instead of 'all' did you mean 'any'? > yes Why?
Re: [PATCH v5 00/15] drm/i915: HuC loading for DG2
On Wed, Sep 14, 2022 at 04:51:03PM +, Winkler, Tomas wrote: > > > > On DG2, HuC loading is performed by the GSC, via a PXP command. The load > > operation itself is relatively simple (just send a message to the GSC with > > the > > physical address of the HuC in LMEM), but there are timing changes that > > requires special attention. In particular, to send a PXP command we need to > > first export the GSC as an aux device and then wait for the mei-gsc and mei- > > pxp modules to start, which means that HuC load will complete after i915 > > load is complete. This means that there is a small window of time after > > i915 is > > registered and before HuC is loaded during which userspace could submit > > and/or check the HuC load status, although this is quite unlikely to happen > > (HuC is usually loaded before kernel init/resume completes). > > We've consulted with the media team in regards to how to handle this and > > they've asked us to stall all userspace VCS submission until HuC is loaded. > > Stalls are expected to be very rare (if any), due to the fact that HuC is > > usually > > loaded before kernel init/resume is completed. > > > > Timeouts are in place to ensure all submissions are unlocked in case > > something goes wrong. Since we need to monitor the status of the mei > > driver to know what's happening and when to time out, a notifier has been > > added so we get a callback when the status of the mei driver changes. > > > > Note that this series includes several mei patches that add support for > > sending the HuC loading command via mei-gsc. We plan to merge those > > patches through the drm tree because i915 is the sole user. > > > > v2: address review comments, Reporting HuC loading still in progress while > > we wait for mei-gsc init to complete, rebase on latest mei-gsc series. > > > > v3: fix cc list in mei patches. > > > > v4: update mei patches, fix includes, rebase on new FW fetch logic and > > merged mei-gsc support. > > > > v5: update mei patches > > Greg, I hope I've addressed most of your comments. > Can you please check if the mei patches are in acceptable state or anything > else can be improved with this series. Appreciated. These were sent 2 days ago, in the middle of a conference travel. Please relax, there's no special rush needed here, you know better. In the mean time, if you are just waiting for my review, please take the time to review other pending patches from other developers to help lighten the load on me, and other maintainers. thanks, greg k-h
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Am 14.09.22 um 20:05 schrieb Stephen Boyd: Quoting Stefan Wahren (2022-09-14 10:45:48) Am 14.09.22 um 17:50 schrieb Stephen Boyd: Furthermore, I wonder if even that part needs to be implemented. Why not make a direct call to rpi_firmware_property() and get the max rate? All of that can live in the drm driver. Making it a generic API that takes a 'struct clk' means that it looks like any clk can be passed, when that isn't true. It would be better to restrict it to the one use case so that the scope of the problem doesn't grow. I understand that it duplicates a few lines of code, but that looks like a fair tradeoff vs. exposing an API that can be used for other clks in the future. it would be nice to keep all the Rpi specific stuff out of the DRM driver, since there more users of it. Instead of 'all' did you mean 'any'? yes
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Quoting Maxime Ripard (2022-09-14 09:15:02)
> Hi Stephen,
>
> Thanks for reviewing that series
>
> On Wed, Sep 14, 2022 at 08:50:33AM -0700, Stephen Boyd wrote:
> > Quoting Maxime Ripard (2022-08-15 08:31:24)
> > > @@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(struct
> > > clk_hw *hw,
> > > return 0;
> > > }
> > >
> > > +unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk)
> > > +{
> > > + const struct raspberrypi_clk_data *data;
> > > + struct raspberrypi_clk *rpi;
> > > + struct clk_hw *hw;
> > > + u32 max_rate;
> > > + int ret;
> > > +
> > > + if (!clk)
> > > + return 0;
> > > +
> > > + hw = __clk_get_hw(clk);
> >
> > Ideally we don't add more users of this API. I should document that :/
>
> What should be the proper way to implement this?
>
> > It begs the question though, why do we need this API to take a 'struct
> > clk'? Can it simply hardcode the data->id value for the clk you care
> > about and call rpi_firmware_property() directly (or some wrapper of it)?
>
> You mean push it down to the consumer?
>
> We will have two users of that function eventually. The KMS driver, and
> the codec driver that isn't upstream yet. AFAIK, both are using a
> different clock, so we can' really hardcode it, and duplicating it at
> the consumer level would be weird.
Can you make an API that returns 'max freq for KMS' and 'max freq for
codec'? For example, it could take the enum value that the clk driver
uses for data->id?
>
> > Furthermore, I wonder if even that part needs to be implemented. Why
> > not make a direct call to rpi_firmware_property() and get the max rate?
> > All of that can live in the drm driver. Making it a generic API that
> > takes a 'struct clk' means that it looks like any clk can be passed,
> > when that isn't true. It would be better to restrict it to the one use
> > case so that the scope of the problem doesn't grow. I understand that it
> > duplicates a few lines of code, but that looks like a fair tradeoff vs.
> > exposing an API that can be used for other clks in the future.
>
> So we'll want to have that function shared between the KMS and codec
> drivers eventually. The clock id used by both drivers is stored in the
> DT so we would create a function (outside of the clock drivers) that
> would parse the clocks property, get the ID, and then queries the
> firmware for it. Would that make sense?
>
Sure. Is the ID ever changing? If not then a simpler design would be to
ask for the particular ID and hardcode that in the driver.
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Quoting Stefan Wahren (2022-09-14 10:45:48) > Am 14.09.22 um 17:50 schrieb Stephen Boyd: > > > > Furthermore, I wonder if even that part needs to be implemented. Why > > not make a direct call to rpi_firmware_property() and get the max rate? > > All of that can live in the drm driver. Making it a generic API that > > takes a 'struct clk' means that it looks like any clk can be passed, > > when that isn't true. It would be better to restrict it to the one use > > case so that the scope of the problem doesn't grow. I understand that it > > duplicates a few lines of code, but that looks like a fair tradeoff vs. > > exposing an API that can be used for other clks in the future. > it would be nice to keep all the Rpi specific stuff out of the DRM > driver, since there more users of it. Instead of 'all' did you mean 'any'?
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Hi,
Am 14.09.22 um 17:50 schrieb Stephen Boyd:
Quoting Maxime Ripard (2022-08-15 08:31:24)
@@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(struct
clk_hw *hw,
return 0;
}
+unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk)
+{
+ const struct raspberrypi_clk_data *data;
+ struct raspberrypi_clk *rpi;
+ struct clk_hw *hw;
+ u32 max_rate;
+ int ret;
+
+ if (!clk)
+ return 0;
+
+ hw = __clk_get_hw(clk);
Ideally we don't add more users of this API. I should document that :/
It begs the question though, why do we need this API to take a 'struct
clk'? Can it simply hardcode the data->id value for the clk you care
about and call rpi_firmware_property() directly (or some wrapper of it)?
Furthermore, I wonder if even that part needs to be implemented. Why
not make a direct call to rpi_firmware_property() and get the max rate?
All of that can live in the drm driver. Making it a generic API that
takes a 'struct clk' means that it looks like any clk can be passed,
when that isn't true. It would be better to restrict it to the one use
case so that the scope of the problem doesn't grow. I understand that it
duplicates a few lines of code, but that looks like a fair tradeoff vs.
exposing an API that can be used for other clks in the future.
it would be nice to keep all the Rpi specific stuff out of the DRM
driver, since there more users of it.
+ if (!hw)
+ return 0;
+
+ data = clk_hw_to_data(hw);
+ rpi = data->rpi;
+ ret = raspberrypi_clock_property(rpi->firmware, data,
+RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
+_rate);
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 1/1] drm/i915/uc: Fix issues with overriding firmware files
On 9/13/2022 5:58 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The earlier update to support reduced versioning of firmware files
introduced an issue with the firmware override module parameter. If an
invalid file was specified then an infinite loop could occur trying to
find a backup firmware.
The fix is that if an explicit override has been set, then don't scan
for backup options because there is no point anyway. The user wanted X
and if X is not available, that's their problem.
This patch also fixes up the scanning loop code so that if an invalid
file is passed in, it will exit rather than loop forever. So if the
impossible situation did somehow occur in the future, it wouldn't be
such a big problem.
v2: Also remove ANSI colour codes that accidentally got left in an
error message in the original patch.
With the commit message updated to include what you mentioned in your
reply, this is:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
Fixes: 665ae9c9ca79 ("drm/i915/uc: Support for version reduced and multiple
firmware files")
Cc: Daniele Ceraolo Spurio
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Matthew Brost
Cc: Umesh Nerlige Ramappa
Cc: Matthew Auld
Cc: Alan Previn
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinay Belgaumkar
Cc: "Thomas Hellström"
Cc: Venkata Sandeep Dhanalakota
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index af425916cdf64..1169e2a09da24 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -232,6 +232,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
u32 fw_count;
u8 rev = INTEL_REVID(i915);
int i;
+ bool found;
/*
* The only difference between the ADL GuC FWs is the HWConfig support.
@@ -246,6 +247,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
fw_blobs = blobs_all[uc_fw->type].blobs;
fw_count = blobs_all[uc_fw->type].count;
+ found = false;
for (i = 0; i < fw_count && p <= fw_blobs[i].p; i++) {
const struct uc_fw_blob *blob = _blobs[i].blob;
@@ -266,9 +268,15 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
uc_fw->file_wanted.path = blob->path;
uc_fw->file_wanted.major_ver = blob->major;
uc_fw->file_wanted.minor_ver = blob->minor;
+ found = true;
break;
}
+ if (!found && uc_fw->file_selected.path) {
+ /* Failed to find a match for the last attempt?! */
+ uc_fw->file_selected.path = NULL;
+ }
+
/* make sure the list is ordered as expected */
if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified) {
verified = true;
@@ -322,7 +330,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
continue;
bad:
- drm_err(>drm, "\x1B[35;1mInvalid FW blob order: %s r%u
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
+ drm_err(>drm, "Invalid FW blob order: %s r%u
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
intel_platform_name(fw_blobs[i - 1].p),
fw_blobs[i - 1].rev,
fw_blobs[i - 1].blob.legacy ? "L" : "v",
fw_blobs[i - 1].blob.major,
@@ -553,10 +561,14 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
err = firmware_request_nowarn(, uc_fw->file_selected.path, dev);
memcpy(_ideal, _fw->file_wanted, sizeof(file_ideal));
- if (!err || intel_uc_fw_is_overridden(uc_fw))
- goto done;
+
+ /* Any error is terminal if overriding. Don't bother searching for
older versions */
+ if (err && intel_uc_fw_is_overridden(uc_fw))
+ goto fail;
while (err == -ENOENT) {
+ old_ver = true;
+
__uc_fw_auto_select(i915, uc_fw);
if (!uc_fw->file_selected.path) {
/*
@@ -576,8 +588,6 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (err)
goto fail;
- old_ver = true;
-done:
if (uc_fw->loaded_via_gsc)
err = check_gsc_manifest(fw, uc_fw);
else
[PATCH][next] drm/amdkfd: Fix spelling mistake "detroyed" -> "destroyed"
There is a spelling mistake in a pr_debug message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 7522bf2d2f57..c70c026c9a93 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -898,7 +898,7 @@ static vm_fault_t svm_migrate_to_ram(struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
if (!mmget_not_zero(svm_bo->eviction_fence->mm)) {
- pr_debug("addr 0x%lx of process mm is detroyed\n", addr);
+ pr_debug("addr 0x%lx of process mm is destroyed\n", addr);
return VM_FAULT_SIGBUS;
}
--
2.37.1
Re: [GIT PULL] Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86
Hi, On 9/14/22 12:29, Maxime Ripard wrote: > Hi Hans, > > On Mon, Sep 05, 2022 at 10:35:47AM +0200, Hans de Goede wrote: >> Hi All, >> >> Now that all patches have been reviewed/acked here is an immutable >> backlight-detect-refactor >> branch with 6.0-rc1 + the v5 patch-set, for merging into the relevant (acpi, >> drm-* and pdx86) >> subsystems. >> >> Please pull this branch into the relevant subsystems. >> >> I will merge this into the review-hans branch of the pdx86 git tree today and >> from there it will move to for-next once the builders have successfully >> build-tested >> the merge. > > I merged it into drm-misc-next, thanks! Great, thank you! Regards, Hans
RE: [PATCH v5 00/15] drm/i915: HuC loading for DG2
> > On DG2, HuC loading is performed by the GSC, via a PXP command. The load > operation itself is relatively simple (just send a message to the GSC with the > physical address of the HuC in LMEM), but there are timing changes that > requires special attention. In particular, to send a PXP command we need to > first export the GSC as an aux device and then wait for the mei-gsc and mei- > pxp modules to start, which means that HuC load will complete after i915 > load is complete. This means that there is a small window of time after i915 > is > registered and before HuC is loaded during which userspace could submit > and/or check the HuC load status, although this is quite unlikely to happen > (HuC is usually loaded before kernel init/resume completes). > We've consulted with the media team in regards to how to handle this and > they've asked us to stall all userspace VCS submission until HuC is loaded. > Stalls are expected to be very rare (if any), due to the fact that HuC is > usually > loaded before kernel init/resume is completed. > > Timeouts are in place to ensure all submissions are unlocked in case > something goes wrong. Since we need to monitor the status of the mei > driver to know what's happening and when to time out, a notifier has been > added so we get a callback when the status of the mei driver changes. > > Note that this series includes several mei patches that add support for > sending the HuC loading command via mei-gsc. We plan to merge those > patches through the drm tree because i915 is the sole user. > > v2: address review comments, Reporting HuC loading still in progress while > we wait for mei-gsc init to complete, rebase on latest mei-gsc series. > > v3: fix cc list in mei patches. > > v4: update mei patches, fix includes, rebase on new FW fetch logic and > merged mei-gsc support. > > v5: update mei patches Greg, I hope I've addressed most of your comments. Can you please check if the mei patches are in acceptable state or anything else can be improved with this series. Appreciated. Thanks Tomas > > Cc: Alan Previn > Cc: Tony Ye > Cc: Alexander Usyskin > Cc: Tomas Winkler > Cc: Greg Kroah-Hartman > > Daniele Ceraolo Spurio (7): > drm/i915/pxp: load the pxp module when we have a gsc-loaded huc > drm/i915/dg2: setup HuC loading via GSC > drm/i915/huc: track delayed HuC load with a fence > drm/i915/huc: stall media submission until HuC is loaded > drm/i915/huc: better define HuC status getparam possible return > values. > drm/i915/huc: define gsc-compatible HuC fw for DG2 > HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI > > Tomas Winkler (5): > mei: add support to GSC extended header > mei: bus: enable sending gsc commands > mei: adjust extended header kdocs > mei: pxp: support matching with a gfx discrete card > drm/i915/pxp: add huc authentication and loading command > > Vitaly Lubart (3): > mei: bus: extend bus API to support command streamer API > mei: pxp: add command streamer API to the PXP driver > drm/i915/pxp: implement function for sending tee stream command > > drivers/gpu/drm/i915/Kconfig.debug| 2 + > drivers/gpu/drm/i915/Makefile | 11 +- > drivers/gpu/drm/i915/gt/intel_gsc.c | 22 +- > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 + > drivers/gpu/drm/i915/gt/uc/intel_huc.c| 254 -- > drivers/gpu/drm/i915/gt/uc/intel_huc.h| 31 +++ > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 34 +++ > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 1 + > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 24 +- > drivers/gpu/drm/i915/i915_request.c | 24 ++ > drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 ++- > drivers/gpu/drm/i915/pxp/intel_pxp.h | 32 --- > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 69 + > drivers/gpu/drm/i915/pxp/intel_pxp_huc.h | 13 + > drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 + > drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 8 +- > drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 11 +- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 138 +- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 5 + > .../drm/i915/pxp/intel_pxp_tee_interface.h| 23 +- > drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 + > drivers/misc/mei/bus.c| 146 +- > drivers/misc/mei/client.c | 55 ++-- > drivers/misc/mei/hbm.c| 13 + > drivers/misc/mei/hw-me.c | 7 +- > drivers/misc/mei/hw.h | 89 +- > drivers/misc/mei/interrupt.c | 47 +++- > drivers/misc/mei/mei_dev.h| 8 + > drivers/misc/mei/pxp/mei_pxp.c| 38 ++- > include/drm/i915_pxp_tee_interface.h | 5 + > include/linux/mei_cl_bus.h| 6 + > include/uapi/drm/i915_drm.h
[PATCH v4 5/6] drm/sched: Use parent fence instead of finished
Using the parent fence instead of the finished fence
to get the job status. This change is to avoid GPU
scheduler timeout error which can cause GPU reset.
Signed-off-by: Arvind Yadav
Reviewed-by: Andrey Grodzovsky
---
changes in v1,v2 - Enable signaling for finished fence in sche_main()
is removed
---
drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index e0ab14e0fb6b..2ac28ad11432 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -829,7 +829,7 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
job = list_first_entry_or_null(>pending_list,
struct drm_sched_job, list);
- if (job && dma_fence_is_signaled(>s_fence->finished)) {
+ if (job && dma_fence_is_signaled(job->s_fence->parent)) {
/* remove job from pending_list */
list_del_init(>list);
@@ -841,7 +841,7 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
if (next) {
next->s_fence->scheduled.timestamp =
- job->s_fence->finished.timestamp;
+ job->s_fence->parent->timestamp;
/* start TO timer for next job */
drm_sched_start_timeout(sched);
}
--
2.25.1
[PATCH v4 6/6] dma-buf: Check status of enable-signaling bit on debug
Fence signaling must be enabled to make sure that
the dma_fence_is_signaled() function ever returns true.
Since drivers and implementations sometimes mess this up,
this ensures correct behaviour when DMABUF_DEBUG_ENABLE_SIGNALING
is used during debugging.
This should make any implementation bugs resulting in not
signaled fences much more obvious.
Signed-off-by: Arvind Yadav
---
Changes in v1,v2 :
1- Addressing Christian's comment to replace
CONFIG_DEBUG_WW_MUTEX_SLOWPATH instead of CONFIG_DEBUG_FS.
2- As per Christian's comment moving this patch at last so
The version of this patch is also changed and previously
it was [PATCH 1/4]
Changes in v3:
1 - Adding new config DMABUF_DEBUG_ENABLE_SIGNALING.
2 - Replace CONFIG_DEBUG_WW_MUTEX_SLOWPATH to new
CONFIG_DMABUF_DEBUG_ENABLE_SIGNALING.
---
drivers/dma-buf/Kconfig | 7 +++
include/linux/dma-fence.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index e4dc53a36428..c991e6a51510 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -65,6 +65,13 @@ config DMABUF_SELFTESTS
default n
depends on DMA_SHARED_BUFFER
+config DMABUF_DEBUG_ENABLE_SIGNALING
+ bool "DMA Fence enable signaling debug checks"
+ default n
+ depends on DMA_SHARED_BUFFER
+ help
+ This option enables additional checks for software signaling of fence.
+
menuconfig DMABUF_HEAPS
bool "DMA-BUF Userland Memory Heaps"
select DMA_SHARED_BUFFER
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 775cdc0b4f24..01e1fa4d3cec 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -428,6 +428,11 @@ dma_fence_is_signaled_locked(struct dma_fence *fence)
static inline bool
dma_fence_is_signaled(struct dma_fence *fence)
{
+#ifdef CONFIG_DMABUF_DEBUG_ENABLE_SIGNALING
+ if (!test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >flags))
+ return false;
+#endif
+
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
return true;
--
2.25.1
[PATCH v4 3/6] dma-buf: Enable signaling on fence for selftests
Here's enabling software signaling on fence for selftest.
Signed-off-by: Arvind Yadav
Reviewed-by: Christian König
---
Changes in v1 :
1- Addressing Christian's comment to remove unnecessary callback.
2- Replacing CONFIG_DEBUG_WW_MUTEX_SLOWPATH instead of CONFIG_DEBUG_FS.
3- The version of this patch is also changed and previously
it was [PATCH 4/4]
Changes in v2 :
1- #ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH removed
---
drivers/dma-buf/st-dma-fence-chain.c | 4
drivers/dma-buf/st-dma-fence-unwrap.c | 22 ++
drivers/dma-buf/st-dma-fence.c| 16
drivers/dma-buf/st-dma-resv.c | 10 ++
4 files changed, 52 insertions(+)
diff --git a/drivers/dma-buf/st-dma-fence-chain.c
b/drivers/dma-buf/st-dma-fence-chain.c
index 8ce1ea59d31b..0a9b099d0518 100644
--- a/drivers/dma-buf/st-dma-fence-chain.c
+++ b/drivers/dma-buf/st-dma-fence-chain.c
@@ -87,6 +87,8 @@ static int sanitycheck(void *arg)
if (!chain)
err = -ENOMEM;
+ dma_fence_enable_sw_signaling(chain);
+
dma_fence_signal(f);
dma_fence_put(f);
@@ -143,6 +145,8 @@ static int fence_chains_init(struct fence_chains *fc,
unsigned int count,
}
fc->tail = fc->chains[i];
+
+ dma_fence_enable_sw_signaling(fc->chains[i]);
}
fc->chain_length = i;
diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c
b/drivers/dma-buf/st-dma-fence-unwrap.c
index 4105d5ea8dde..f0cee984b6c7 100644
--- a/drivers/dma-buf/st-dma-fence-unwrap.c
+++ b/drivers/dma-buf/st-dma-fence-unwrap.c
@@ -102,6 +102,8 @@ static int sanitycheck(void *arg)
if (!f)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f);
+
array = mock_array(1, f);
if (!array)
return -ENOMEM;
@@ -124,12 +126,16 @@ static int unwrap_array(void *arg)
if (!f1)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f1);
+
f2 = mock_fence();
if (!f2) {
dma_fence_put(f1);
return -ENOMEM;
}
+ dma_fence_enable_sw_signaling(f2);
+
array = mock_array(2, f1, f2);
if (!array)
return -ENOMEM;
@@ -164,12 +170,16 @@ static int unwrap_chain(void *arg)
if (!f1)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f1);
+
f2 = mock_fence();
if (!f2) {
dma_fence_put(f1);
return -ENOMEM;
}
+ dma_fence_enable_sw_signaling(f2);
+
chain = mock_chain(f1, f2);
if (!chain)
return -ENOMEM;
@@ -204,12 +214,16 @@ static int unwrap_chain_array(void *arg)
if (!f1)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f1);
+
f2 = mock_fence();
if (!f2) {
dma_fence_put(f1);
return -ENOMEM;
}
+ dma_fence_enable_sw_signaling(f2);
+
array = mock_array(2, f1, f2);
if (!array)
return -ENOMEM;
@@ -248,12 +262,16 @@ static int unwrap_merge(void *arg)
if (!f1)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f1);
+
f2 = mock_fence();
if (!f2) {
err = -ENOMEM;
goto error_put_f1;
}
+ dma_fence_enable_sw_signaling(f2);
+
f3 = dma_fence_unwrap_merge(f1, f2);
if (!f3) {
err = -ENOMEM;
@@ -296,10 +314,14 @@ static int unwrap_merge_complex(void *arg)
if (!f1)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f1);
+
f2 = mock_fence();
if (!f2)
goto error_put_f1;
+ dma_fence_enable_sw_signaling(f2);
+
f3 = dma_fence_unwrap_merge(f1, f2);
if (!f3)
goto error_put_f2;
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index c8a12d7ad71a..fb6e0a6ae2c9 100644
--- a/drivers/dma-buf/st-dma-fence.c
+++ b/drivers/dma-buf/st-dma-fence.c
@@ -102,6 +102,8 @@ static int sanitycheck(void *arg)
if (!f)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f);
+
dma_fence_signal(f);
dma_fence_put(f);
@@ -117,6 +119,8 @@ static int test_signaling(void *arg)
if (!f)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f);
+
if (dma_fence_is_signaled(f)) {
pr_err("Fence unexpectedly signaled on creation\n");
goto err_free;
@@ -190,6 +194,8 @@ static int test_late_add_callback(void *arg)
if (!f)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f);
+
dma_fence_signal(f);
if (!dma_fence_add_callback(f, , simple_callback)) {
@@ -282,6 +288,8 @@ static int test_status(void *arg)
if (!f)
return -ENOMEM;
+ dma_fence_enable_sw_signaling(f);
+
if
[PATCH v4 4/6] dma-buf: dma_fence_wait must enable signaling
dma_fence_wait() should always enable signaling even
when the fence is already signaled.
Signed-off-by: Arvind Yadav
---
Changes in v1..v3: This new patch was not part of previous series.
---
drivers/dma-buf/dma-fence.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 645c158b7e01..a5fbf1c1e0ea 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -508,6 +508,8 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr,
signed long timeout)
__dma_fence_might_wait();
+ dma_fence_enable_sw_signaling(fence);
+
trace_dma_fence_wait_start(fence);
if (fence->ops->wait)
ret = fence->ops->wait(fence, intr, timeout);
@@ -771,9 +773,6 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
goto out;
}
- if (!__dma_fence_enable_signaling(fence))
- goto out;
-
if (!timeout) {
ret = 0;
goto out;
--
2.25.1
[PATCH v4 2/6] dma-buf: set signaling bit for the stub fence
Here's setting software signaling bit for the stub fence which is always signaled. If this fence signaling bit is not set then the AMD GPU scheduler will cause a GPU reset due to a GPU scheduler cleanup activity timeout. Signed-off-by: Arvind Yadav Reviewed-by: Christian König --- Changes in v1 : 1- Addressing Christian's comment to remove unnecessary callback. 2- Replacing CONFIG_DEBUG_WW_MUTEX_SLOWPATH instead of CONFIG_DEBUG_FS. 3- The version of this patch is also changed and previously it was [PATCH 3/4] Changes in v2 : 1 - perviously using __dma_fence_enable_signaling() for enable signaling. 2 - #ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH removed Changes in v3 : 1 - Enable Signaling bit for dma_fence_allocate_private_stub. --- drivers/dma-buf/dma-fence.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 64c99739ad23..645c158b7e01 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -136,6 +136,10 @@ struct dma_fence *dma_fence_get_stub(void) _fence_stub_ops, _fence_stub_lock, 0, 0); + + set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, + _fence_stub.flags); + dma_fence_signal_locked(_fence_stub); } spin_unlock(_fence_stub_lock); @@ -161,6 +165,10 @@ struct dma_fence *dma_fence_allocate_private_stub(void) _fence_stub_ops, _fence_stub_lock, 0, 0); + + set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, + _fence_stub.flags); + dma_fence_signal(fence); return fence; -- 2.25.1
[PATCH v4 1/6] dma-buf: Remove the signaled bit status check
Remove the signaled bit status check because it is returning
early when the fence is already signaled and
__dma_fence_enable_signaling is checking the status of signaled
bit again.
Signed-off-by: Arvind Yadav
Reviewed-by: Christian König
---
Changes in v1, v2: This new patch was not part of previous series.
---
drivers/dma-buf/dma-fence.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 066400ed8841..64c99739ad23 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -601,9 +601,6 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence)
{
unsigned long flags;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
- return;
-
spin_lock_irqsave(fence->lock, flags);
__dma_fence_enable_signaling(fence);
spin_unlock_irqrestore(fence->lock, flags);
--
2.25.1
[PATCH v4 0/6] dma-buf: Check status of enable-signaling bit on debug
Fence signaling must be enabled to make sure that the dma_fence_is_signaled() function ever returns true. Since drivers and implementations sometimes mess this up, this ensures correct behaviour when DEBUG_WW_MUTEX_SLOWPATH is used during debugging. This should make any implementation bugs resulting in not signaled fences much more obvious. Arvind Yadav (6): [PATCH v4 1/6] dma-buf: Remove the signaled bit status check [PATCH v4 2/6] dma-buf: set signaling bit for the stub fence [PATCH v4 3/6] dma-buf: Enable signaling on fence for selftests [PATCH v4 4/6] dma-buf: dma_fence_wait must enable signaling [PATCH v4 5/6] drm/sched: Use parent fence instead of finished [PATCH v4 6/6] dma-buf: Check status of enable-signaling bit on debug drivers/dma-buf/Kconfig| 7 +++ drivers/dma-buf/dma-fence.c| 16 ++-- drivers/dma-buf/st-dma-fence-chain.c | 4 drivers/dma-buf/st-dma-fence-unwrap.c | 22 ++ drivers/dma-buf/st-dma-fence.c | 16 drivers/dma-buf/st-dma-resv.c | 10 ++ drivers/gpu/drm/scheduler/sched_main.c | 4 ++-- include/linux/dma-fence.h | 5 + 8 files changed, 76 insertions(+), 8 deletions(-) -- 2.25.1
Re: [PATCH v2 1/1] drm/i915/uc: Fix issues with overriding firmware files
On 9/13/2022 17:58, john.c.harri...@intel.com wrote:
From: John Harrison
The earlier update to support reduced versioning of firmware files
introduced an issue with the firmware override module parameter. If an
invalid file was specified then an infinite loop could occur trying to
find a backup firmware.
The above not entirely correct - got myself confused while typing it up.
A self test would specify an invalid file name (invalid meaning not in
the table) both with and without setting the override flag. The
*non-override* case would cause the infinite loop. I.e. a situation that
is impossible to hit outside of the selftest because either the file
name has come from the table in first place or it came from an override.
However, the override case was still broken in that it would bypass some
of the later processing.
The fix is that if an explicit override has been set, then don't scan
for backup options because there is no point anyway. The user wanted X
and if X is not available, that's their problem.
This patch also fixes up the scanning loop code so that if an invalid
file is passed in, it will exit rather than loop forever. So if the
impossible situation did somehow occur in the future, it wouldn't be
such a big problem.
It also flips the logic on the override early exit to be negative rather
than positive so as not to skip code that still needs to be run.
John.
v2: Also remove ANSI colour codes that accidentally got left in an
error message in the original patch.
Fixes: 665ae9c9ca79 ("drm/i915/uc: Support for version reduced and multiple
firmware files")
Cc: Daniele Ceraolo Spurio
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Matthew Brost
Cc: Umesh Nerlige Ramappa
Cc: Matthew Auld
Cc: Alan Previn
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Vinay Belgaumkar
Cc: "Thomas Hellström"
Cc: Venkata Sandeep Dhanalakota
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index af425916cdf64..1169e2a09da24 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -232,6 +232,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
u32 fw_count;
u8 rev = INTEL_REVID(i915);
int i;
+ bool found;
/*
* The only difference between the ADL GuC FWs is the HWConfig support.
@@ -246,6 +247,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
fw_blobs = blobs_all[uc_fw->type].blobs;
fw_count = blobs_all[uc_fw->type].count;
+ found = false;
for (i = 0; i < fw_count && p <= fw_blobs[i].p; i++) {
const struct uc_fw_blob *blob = _blobs[i].blob;
@@ -266,9 +268,15 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
uc_fw->file_wanted.path = blob->path;
uc_fw->file_wanted.major_ver = blob->major;
uc_fw->file_wanted.minor_ver = blob->minor;
+ found = true;
break;
}
+ if (!found && uc_fw->file_selected.path) {
+ /* Failed to find a match for the last attempt?! */
+ uc_fw->file_selected.path = NULL;
+ }
+
/* make sure the list is ordered as expected */
if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified) {
verified = true;
@@ -322,7 +330,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
continue;
bad:
- drm_err(>drm, "\x1B[35;1mInvalid FW blob order: %s r%u
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
+ drm_err(>drm, "Invalid FW blob order: %s r%u
%s%d.%d.%d comes before %s r%u %s%d.%d.%d\n",
intel_platform_name(fw_blobs[i - 1].p),
fw_blobs[i - 1].rev,
fw_blobs[i - 1].blob.legacy ? "L" : "v",
fw_blobs[i - 1].blob.major,
@@ -553,10 +561,14 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
err = firmware_request_nowarn(, uc_fw->file_selected.path, dev);
memcpy(_ideal, _fw->file_wanted, sizeof(file_ideal));
- if (!err || intel_uc_fw_is_overridden(uc_fw))
- goto done;
+
+ /* Any error is terminal if overriding. Don't bother searching for
older versions */
+ if (err && intel_uc_fw_is_overridden(uc_fw))
+ goto fail;
while (err == -ENOENT) {
+ old_ver = true;
+
__uc_fw_auto_select(i915, uc_fw);
if (!uc_fw->file_selected.path) {
/*
@@ -576,8 +588,6 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (err)
goto fail;
-
[PATCH 1/1] drm/i915/uc: Enable version reduced firmware files for newest platforms
From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected version numbers to the latest firmware release for those platforms. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index af425916cdf64..57faba11029ac 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,13 +72,18 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_maj(dg1, 70, 5)) \ fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ + fw_def(ROCKETLAKE, 0, guc_maj(tgl, 70, 5)) \ fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ + fw_def(TIGERLAKE,0, guc_maj(tgl, 70, 5)) \ fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ fw_def(ELKHARTLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \ @@ -92,10 +97,15 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(DG1, 0, huc_raw(dg1)) \ fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ + fw_def(ROCKETLAKE, 0, huc_raw(tgl)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(TIGERLAKE,0, huc_raw(tgl)) \ fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(JASPERLAKE, 0, huc_mmp(ehl, 9, 0, 0)) \ fw_def(ELKHARTLAKE, 0, huc_mmp(ehl, 9, 0, 0)) \ -- 2.37.3
[PATCH 0/1] Update to version reduced firmware file names
From: John Harrison Start using GuC/HuC firmware files with reduced version information in the file name. Signed-off-by: John Harrison John Harrison (1): drm/i915/uc: Enable version reduced firmware files for newest platforms drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 2.37.3
Re: mgag200 broken on kernel-6.0-rc3 on DELL/T620
Hi, > Hi > > Am 14.09.22 um 16:58 schrieb Wang Yugui: > > Hi, > > > >> (cc: Jocelyn) > >> > >> Hi > >> > >> Am 14.09.22 um 10:29 schrieb Wang Yugui: > >>> Hi, > >>> > >>> > Hi > > Am 13.09.22 um 17:15 schrieb Wang Yugui: > [...] > >>> > >>> so I tried to revert patch of mgag200 driver in batch of 2 or 3, the I > >>> noticed the patch 'Subject: drm/mgag200: Remove special case for > >>> G200SE > >>> with <2 MiB' and then tried this dirty fix. > >> > >> Oh, great work! Thank you. From looking at the screenshot that you > >> provided, it seems as if the 24-bit mode setting is broken. I'm not > >> sure why the G200SE workaround applies to a G200ER, but we'll see. > > > > I tested 'preferred_depth = 32' too. it works on T630 too. > > > > so both 16 and 32 work, but 24 failed on DELL/T630. > > I tried on my test machine with a 5.19 kernel and found that 32-bit and > 24-bit pixels work, but 16-bit looks incorrect. > > What are the results if you boot your kernel 5.19.3 with the parameter > video=1024x768-24? This should enable 24-bit pixels. > > How does video=1024x768-16 look with the 5.19 kernel? > >>> > >>> test result here > >>> kernel 5.19.3 & video=1024x768-24 > >>> dell/T620/centos-8.5broken > >>> dell/T630/centos-7.9broken > >> > >> I assume that Centos 7 and 8 have fairly old kernels? So it's been a > >> long-standing bug. > > > > We install kernel 5.19.3/5.15.67 into Centos 7 and 8. > > default it work well. broken just when 'video=1024x768-24', so it may > > not a long-standing bug. > > I don't quite understand. Does 'video=1024x768-24' work with 5.15.67? kernel 5.15.67 with 'video=1024x768-24' is broken on DELL/T630. kernel 5.15.67 without 'video=1024x768-24' works well on DELL/T630. Best Regards Wang Yugui (wangyu...@e16-tech.com) 2022/09/15
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Hi Stephen,
Thanks for reviewing that series
On Wed, Sep 14, 2022 at 08:50:33AM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-08-15 08:31:24)
> > @@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(struct
> > clk_hw *hw,
> > return 0;
> > }
> >
> > +unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk)
> > +{
> > + const struct raspberrypi_clk_data *data;
> > + struct raspberrypi_clk *rpi;
> > + struct clk_hw *hw;
> > + u32 max_rate;
> > + int ret;
> > +
> > + if (!clk)
> > + return 0;
> > +
> > + hw = __clk_get_hw(clk);
>
> Ideally we don't add more users of this API. I should document that :/
What should be the proper way to implement this?
> It begs the question though, why do we need this API to take a 'struct
> clk'? Can it simply hardcode the data->id value for the clk you care
> about and call rpi_firmware_property() directly (or some wrapper of it)?
You mean push it down to the consumer?
We will have two users of that function eventually. The KMS driver, and
the codec driver that isn't upstream yet. AFAIK, both are using a
different clock, so we can' really hardcode it, and duplicating it at
the consumer level would be weird.
> Furthermore, I wonder if even that part needs to be implemented. Why
> not make a direct call to rpi_firmware_property() and get the max rate?
> All of that can live in the drm driver. Making it a generic API that
> takes a 'struct clk' means that it looks like any clk can be passed,
> when that isn't true. It would be better to restrict it to the one use
> case so that the scope of the problem doesn't grow. I understand that it
> duplicates a few lines of code, but that looks like a fair tradeoff vs.
> exposing an API that can be used for other clks in the future.
So we'll want to have that function shared between the KMS and codec
drivers eventually. The clock id used by both drivers is stored in the
DT so we would create a function (outside of the clock drivers) that
would parse the clocks property, get the ID, and then queries the
firmware for it. Would that make sense?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH 4/6] drm/format-helper: Support the AB24 format
On Wed, Sep 07, 2022 at 09:23:01AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.09.22 um 18:32 schrieb Thierry Reding:
> > From: Thierry Reding
> >
> > Add a conversion helper for the AB24 format to use in drm_fb_blit().
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/gpu/drm/drm_format_helper.c | 35 +
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_format_helper.c
> > b/drivers/gpu/drm/drm_format_helper.c
> > index 56642816fdff..d564412a816b 100644
> > --- a/drivers/gpu/drm/drm_format_helper.c
> > +++ b/drivers/gpu/drm/drm_format_helper.c
> > @@ -503,6 +503,36 @@ static void drm_fb_rgb888_to_xrgb(struct iosys_map
> > *dst, const unsigned int
> > drm_fb_rgb888_to_xrgb_line);
> > }
> > +static void drm_fb_xrgb_to_abgr_line(void *dbuf, const void *sbuf,
> > unsigned int pixels)
> > +{
> > + __le32 *dbuf32 = dbuf;
> > + const __le32 *sbuf32 = sbuf;
> > + unsigned int x;
> > + u32 pix;
> > +
> > + for (x = 0; x < pixels; x++) {
> > + pix = le32_to_cpu(sbuf32[x]);
> > + pix = ((pix & 0xff00) >> 24) << 24 |
> > + ((pix & 0x00ff) >> 16) << 0 |
> > + ((pix & 0xff00) >> 8) << 8 |
> > + ((pix & 0x00ff) >> 0) << 16;
> > + *dbuf32++ = cpu_to_le32(pix);
> > + }
> > +}
>
> What does the Jetson device do with these alpha bits?
>
> AFAIK the X channel's content is undefined. Shifting the bits into the A
> channel might result in wrong results in the general case. Better just set
> the alpha to 0xff unconditionally.
I'm not exactly sure, so I'd have to do some digging. I suspect that
perhaps this might actually be XBGR rather than ABGR, so this may end up
doing nothing. EFI FB reports this as ABGR, at least if I read the
output right, so that's what I went with for the DT implementation.
> > +
> > +static void drm_fb_xrgb_to_abgr(struct iosys_map *dst, const
> > unsigned int *dst_pitch,
> > + const struct iosys_map *src,
> > + const struct drm_framebuffer *fb,
> > + const struct drm_rect *clip)
> > +{
> > + static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
> > + 4,
> > + };
> > +
> > + drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
> > + drm_fb_xrgb_to_abgr_line);
> > +}
> > +
> > static void drm_fb_xrgb_to_xrgb2101010_line(void *dbuf, const void
> > *sbuf, unsigned int pixels)
> > {
> > __le32 *dbuf32 = dbuf;
> > @@ -672,6 +702,11 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned
> > int *dst_pitch, uint32_t d
> > drm_fb_rgb565_to_xrgb(dst, dst_pitch, src, fb,
> > clip);
> > return 0;
> > }
> > + } else if (dst_format == DRM_FORMAT_ABGR) {
> > + if (fb_format == DRM_FORMAT_XRGB) {
> > + drm_fb_xrgb_to_abgr(dst, dst_pitch, src, fb,
> > clip);
> > + return 0;
> > + }
>
> For the other alpha-containing formats, we treat them like non-alpha formats
> (see the top of this function). Maybe just do the same here and then
> implement the conversion as drm_fb_xrgb_to_xbgr() helpers?
Yeah, that's probably for the best. None of the boot splash uses alpha
as far as I can tell and neither does the kernel framebuffer console, so
there's really little point in trying to support it.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH 2/6] dt-bindings: reserved-memory: Support framebuffer reserved memory
On Tue, Sep 06, 2022 at 09:27:21AM -0500, Rob Herring wrote:
> On Mon, Sep 05, 2022 at 06:32:56PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Document the "framebuffer" compatible string for reserved memory nodes
> > to annotate reserved memory regions used for framebuffer carveouts.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > .../bindings/reserved-memory/framebuffer.yaml | 46 +++
> > 1 file changed, 46 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
> > b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
> > new file mode 100644
> > index ..80574854025d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
> > @@ -0,0 +1,46 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: /reserved-memory framebuffer node bindings
> > +
> > +maintainers:
> > + - devicetree-s...@vger.kernel.org
> > +
> > +allOf:
> > + - $ref: "reserved-memory.yaml"
>
> Don't need quotes.
>
> > +
> > +properties:
> > + compatible:
> > +const: framebuffer
> > +description: >
> > + This indicates a region of memory meant to be used as a framebuffer
> > for
> > + a set of display devices. It can be used by an operating system to
> > keep
> > + the framebuffer from being overwritten and use it as the backing
> > memory
> > + for a display device (such as simple-framebuffer).
>
> I'm on the fence whether we need this. It doesn't really add anything
> because 'simple-framebuffer' will reference this node and you can find
> it that way. I guess a bootloader may not setup 'simple-framebuffer',
> but then it should probably not have this node either.
>
> On the flip side, better to have compatibles than not to identify nodes.
Yeah, I think given some of the comments that Robin Murphy had on the
iommu-addresses thread, having some compatible string to derive more
information from will be useful. I'm not sure if "framebuffer" is the
greatest choice, but it says exactly what this is, so if there are no
better suggestions, I'll stick with that.
Adding Robin in case he has anything to contribute on this side of the
discussion. In retrospect it might have been good to have more overlap
between the recipients of both series.
Thierry
>
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
>
> Use '/ {' to skip the boilerplate causing the error.
>
> > + chosen {
> > +framebuffer {
> > + compatible = "simple-framebuffer";
> > + memory-region = <>;
> > +};
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + fb: framebuffer@8000 {
> > + compatible = "framebuffer";
> > + reg = <0x8000 0x007e9000>;
> > + };
> > + };
> > +
> > +...
> > --
> > 2.37.2
> >
> >
signature.asc
Description: PGP signature
Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum
Quoting Maxime Ripard (2022-08-15 08:31:24)
> @@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(struct
> clk_hw *hw,
> return 0;
> }
>
> +unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk)
> +{
> + const struct raspberrypi_clk_data *data;
> + struct raspberrypi_clk *rpi;
> + struct clk_hw *hw;
> + u32 max_rate;
> + int ret;
> +
> + if (!clk)
> + return 0;
> +
> + hw = __clk_get_hw(clk);
Ideally we don't add more users of this API. I should document that :/
It begs the question though, why do we need this API to take a 'struct
clk'? Can it simply hardcode the data->id value for the clk you care
about and call rpi_firmware_property() directly (or some wrapper of it)?
Furthermore, I wonder if even that part needs to be implemented. Why
not make a direct call to rpi_firmware_property() and get the max rate?
All of that can live in the drm driver. Making it a generic API that
takes a 'struct clk' means that it looks like any clk can be passed,
when that isn't true. It would be better to restrict it to the one use
case so that the scope of the problem doesn't grow. I understand that it
duplicates a few lines of code, but that looks like a fair tradeoff vs.
exposing an API that can be used for other clks in the future.
> + if (!hw)
> + return 0;
> +
> + data = clk_hw_to_data(hw);
> + rpi = data->rpi;
> + ret = raspberrypi_clock_property(rpi->firmware, data,
> +RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
> +_rate);
Re: mgag200 broken on kernel-6.0-rc3 on DELL/T620
Hi
Am 14.09.22 um 16:58 schrieb Wang Yugui:
Hi,
(cc: Jocelyn)
Hi
Am 14.09.22 um 10:29 schrieb Wang Yugui:
Hi,
Hi
Am 13.09.22 um 17:15 schrieb Wang Yugui:
[...]
so I tried to revert patch of mgag200 driver in batch of 2 or 3, the I
noticed the patch 'Subject: drm/mgag200: Remove special case for G200SE
with <2 MiB' and then tried this dirty fix.
Oh, great work! Thank you. From looking at the screenshot that you provided, it
seems as if the 24-bit mode setting is broken. I'm not sure why the G200SE
workaround applies to a G200ER, but we'll see.
I tested 'preferred_depth = 32' too. it works on T630 too.
so both 16 and 32 work, but 24 failed on DELL/T630.
I tried on my test machine with a 5.19 kernel and found that 32-bit and 24-bit
pixels work, but 16-bit looks incorrect.
What are the results if you boot your kernel 5.19.3 with the parameter
video=1024x768-24? This should enable 24-bit pixels.
How does video=1024x768-16 look with the 5.19 kernel?
test result here
kernel 5.19.3 & video=1024x768-24
dell/T620/centos-8.5broken
dell/T630/centos-7.9broken
I assume that Centos 7 and 8 have fairly old kernels? So it's been a
long-standing bug.
We install kernel 5.19.3/5.15.67 into Centos 7 and 8.
default it work well. broken just when 'video=1024x768-24', so it may
not a long-standing bug.
I don't quite understand. Does 'video=1024x768-24' work with 5.15.67?
24-bit works on my G200HE and G200 test machines. Maybe the G200ER has a bug.
When I try 16-bit depth, the display works, but is way too dark. No fiddling
with the LUT tables fixes this. It's 90s hardware, so it should support 16-bit
framebuffers well, but there's no obvious bug to be seen.
I guess, we could remove 16 and 24 bit support for now if nothing else helps.
maybe better if we revert 73f54d5d9682 (drm/mgag200: Remove special case
for G200SE with <2 MiB)
because there is no test result on device G200_SE
We cannot revert it directly, but tomorrow I'll send you a patch that
should restore the old behavior.
Best regards
Thomas
static unsigned int mgag200_preferred_depth(struct mga_device *mdev)
{
if (IS_G200_SE(mdev) && mdev->vram_fb_available < (2048*1024))
return 16;
else
return 32;
}
Best Regards
Wang Yugui (wangyu...@e16-tech.com)
2022/09/14
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 3/8] dt-bindings: Add bindings for Tegra234 NVDEC
On Wed, Sep 14, 2022 at 9:32 AM Thierry Reding wrote: > > On Wed, Sep 14, 2022 at 03:19:01PM +0300, Mikko Perttunen wrote: > > On 9/14/22 15:08, Rob Herring wrote: > > > On Tue, Sep 13, 2022 at 04:14:41PM +0300, Mikko Perttunen wrote: > > > > From: Mikko Perttunen > > > > > > > > Update NVDEC bindings for Tegra234. This new engine version only has > > > > two memory clients, but now requires three clocks, and as a bigger > > > > change the engine loads firmware from a secure carveout configured by > > > > the bootloader. > > > > > > > > For the latter, we need to add a phandle to the memory controller > > > > to query the location of this carveout, and several other properties > > > > containing offsets into the firmware inside the carveout. These > > > > properties are intended to be populated through a device tree overlay > > > > configured at flashing time, so that the values correspond to the > > > > flashed NVDEC firmware. > > > > > > > > As the binding was getting large with many conditional properties, > > > > also split the Tegra234 version out into a separate file. > > > > > > > > Signed-off-by: Mikko Perttunen > > > > --- > > > > v2: > > > > - Split out into separate file to avoid complexity with > > > >conditionals etc. > > > > --- > > > > .../gpu/host1x/nvidia,tegra234-nvdec.yaml | 154 ++ > > > > 1 file changed, 154 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > > > > > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > > new file mode 100644 > > > > index ..eab0475ca983 > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > > @@ -0,0 +1,154 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: > > > > "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#; > > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > > > > + > > > > +title: Device tree binding for NVIDIA Tegra234 NVDEC > > > > + > > > > +description: | > > > > + NVDEC is the hardware video decoder present on NVIDIA Tegra210 > > > > + and newer chips. It is located on the Host1x bus and typically > > > > + programmed through Host1x channels. > > > > + > > > > +maintainers: > > > > + - Thierry Reding > > > > + - Mikko Perttunen > > > > + > > > > +properties: > > > > + $nodename: > > > > +pattern: "^nvdec@[0-9a-f]*$" > > > > + > > > > + compatible: > > > > +enum: > > > > + - nvidia,tegra234-nvdec > > > > + > > > > + reg: > > > > +maxItems: 1 > > > > + > > > > + clocks: > > > > +maxItems: 3 > > > > + > > > > + clock-names: > > > > +items: > > > > + - const: nvdec > > > > + - const: fuse > > > > + - const: tsec_pka > > > > + > > > > + resets: > > > > +maxItems: 1 > > > > + > > > > + reset-names: > > > > +items: > > > > + - const: nvdec > > > > + > > > > + power-domains: > > > > +maxItems: 1 > > > > + > > > > + iommus: > > > > +maxItems: 1 > > > > + > > > > + dma-coherent: true > > > > + > > > > + interconnects: > > > > +items: > > > > + - description: DMA read memory client > > > > + - description: DMA write memory client > > > > + > > > > + interconnect-names: > > > > +items: > > > > + - const: dma-mem > > > > + - const: write > > > > + > > > > + nvidia,memory-controller: > > > > +$ref: /schemas/types.yaml#/definitions/phandle > > > > +description: > > > > + phandle to the memory controller for determining carveout > > > > information. > > > > + > > > > + nvidia,bl-manifest-offset: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +description: > > > > + Offset to bootloader manifest from beginning of firmware. > > > > Typically set as > > > > + part of a device tree overlay corresponding to flashed firmware. > > > > + > > > > + nvidia,bl-code-offset: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +description: > > > > + Offset to bootloader code section from beginning of firmware. > > > > Typically set as > > > > + part of a device tree overlay corresponding to flashed firmware. > > > > + > > > > + nvidia,bl-data-offset: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +description: > > > > + Offset to bootloader data section from beginning of firmware. > > > > Typically set as > > > > + part of a device tree overlay corresponding to flashed firmware. > > > > + > > > > + nvidia,os-manifest-offset: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +description: > > > > + Offset to operating system manifest from beginning of firmware. > > > > Typically set as > > > > +
Re: mgag200 broken on kernel-6.0-rc3 on DELL/T620
Hi,
> (cc: Jocelyn)
>
> Hi
>
> Am 14.09.22 um 10:29 schrieb Wang Yugui:
> > Hi,
> >
> >
> >> Hi
> >>
> >> Am 13.09.22 um 17:15 schrieb Wang Yugui:
> >> [...]
> >
> > so I tried to revert patch of mgag200 driver in batch of 2 or 3, the I
> > noticed the patch 'Subject: drm/mgag200: Remove special case for G200SE
> > with <2 MiB' and then tried this dirty fix.
>
> Oh, great work! Thank you. From looking at the screenshot that you
> provided, it seems as if the 24-bit mode setting is broken. I'm not sure
> why the G200SE workaround applies to a G200ER, but we'll see.
> >>>
> >>> I tested 'preferred_depth = 32' too. it works on T630 too.
> >>>
> >>> so both 16 and 32 work, but 24 failed on DELL/T630.
> >>
> >> I tried on my test machine with a 5.19 kernel and found that 32-bit and
> >> 24-bit pixels work, but 16-bit looks incorrect.
> >>
> >> What are the results if you boot your kernel 5.19.3 with the parameter
> >> video=1024x768-24? This should enable 24-bit pixels.
> >>
> >> How does video=1024x768-16 look with the 5.19 kernel?
> >
> > test result here
> > kernel 5.19.3 & video=1024x768-24
> > dell/T620/centos-8.5broken
> > dell/T630/centos-7.9broken
>
> I assume that Centos 7 and 8 have fairly old kernels? So it's been a
> long-standing bug.
We install kernel 5.19.3/5.15.67 into Centos 7 and 8.
default it work well. broken just when 'video=1024x768-24', so it may
not a long-standing bug.
> 24-bit works on my G200HE and G200 test machines. Maybe the G200ER has a bug.
>
> When I try 16-bit depth, the display works, but is way too dark. No fiddling
> with the LUT tables fixes this. It's 90s hardware, so it should support
> 16-bit framebuffers well, but there's no obvious bug to be seen.
>
> I guess, we could remove 16 and 24 bit support for now if nothing else helps.
maybe better if we revert 73f54d5d9682 (drm/mgag200: Remove special case
for G200SE with <2 MiB)
because there is no test result on device G200_SE
static unsigned int mgag200_preferred_depth(struct mga_device *mdev)
{
if (IS_G200_SE(mdev) && mdev->vram_fb_available < (2048*1024))
return 16;
else
return 32;
}
Best Regards
Wang Yugui (wangyu...@e16-tech.com)
2022/09/14
[PATCH v2 1/3] ARM: dts: am335x: Fix TDA998x ports addressing
Fix addressing in the NXP TDA998x HDMI transmitters' subnodes:
- Add missing #{address,size}-cells properties to ports capsule,
- Add missing reg properties to port child nodes,
- Drop bogus unit addresses from endpoint grandchildren nodes.
Signed-off-by: Geert Uytterhoeven
---
v2:
- No changes.
---
arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi | 7 ++-
arch/arm/boot/dts/am335x-myirtech-myd.dts| 7 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi
b/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi
index 7cfddada934861bc..486f24deb875c688 100644
--- a/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi
+++ b/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi
@@ -85,8 +85,13 @@ tda19988: tda19988@70 {
audio-ports = < TDA998x_I2S 0x03>;
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@0 {
- hdmi_0: endpoint@0 {
+ reg = <0>;
+
+ hdmi_0: endpoint {
remote-endpoint = <_0>;
};
};
diff --git a/arch/arm/boot/dts/am335x-myirtech-myd.dts
b/arch/arm/boot/dts/am335x-myirtech-myd.dts
index 9d81d4cc6890eea9..425ad9b81a68ab18 100644
--- a/arch/arm/boot/dts/am335x-myirtech-myd.dts
+++ b/arch/arm/boot/dts/am335x-myirtech-myd.dts
@@ -161,8 +161,13 @@ tda9988: tda9988@70 {
#sound-dai-cells = <0>;
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@0 {
- hdmi_0: endpoint@0 {
+ reg = <0>;
+
+ hdmi_0: endpoint {
remote-endpoint = <_0>;
};
};
--
2.25.1
[PATCH v2 3/3] dt-bindings: display: bridge: nxp, tda998x: Convert to json-schema
Convert the NXP TDA998x HDMI transmitter Device Tree binding
documentation to json-schema.
Add missing "#sound-dai-cells" property.
Add ports hierarchy, as an alternative to port.
Drop pinctrl properties, as they do not belong here.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Add maximum to video-ports,
- Drop unneeded maxItems for audio-ports,
- Complete port descriptions.
---
.../bindings/display/bridge/nxp,tda998x.yaml | 109 ++
.../bindings/display/bridge/tda998x.txt | 54 -
2 files changed, 109 insertions(+), 54 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
delete mode 100644 Documentation/devicetree/bindings/display/bridge/tda998x.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
new file mode 100644
index ..c4bf543974737b5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nxp,tda998x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP TDA998x HDMI transmitter
+
+maintainers:
+ - Russell King
+
+properties:
+ compatible:
+const: nxp,tda998x
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ video-ports:
+default: 0x230145
+maximum: 0xff
+description:
+ 24 bits value which defines how the video controller output is wired to
+ the TDA998x input.
+
+ audio-ports:
+description:
+ Array of 8-bit values, 2 values per DAI
(Documentation/sound/soc/dai.rst).
+ The implementation allows one or two DAIs.
+ If two DAIs are defined, they must be of different type.
+$ref: /schemas/types.yaml#/definitions/uint32-matrix
+items:
+ minItems: 1
+ items:
+- description: |
+The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S
+(see include/dt-bindings/display/tda998x.h).
+- description:
+The second value defines the tda998x AP_ENA reg content when the
+DAI in question is used.
+
+ '#sound-dai-cells':
+enum: [ 0, 1 ]
+
+ nxp,calib-gpios:
+maxItems: 1
+description:
+ Calibration GPIO, which must correspond with the gpio used for the
+ TDA998x interrupt pin.
+
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+description: Parallel input port
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+type: object
+description: Parallel input port
+
+ port@1:
+type: object
+description: HDMI output port
+
+required:
+ - compatible
+ - reg
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+tda998x: hdmi-encoder@70 {
+compatible = "nxp,tda998x";
+reg = <0x70>;
+interrupt-parent = <>;
+interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+video-ports = <0x230145>;
+
+#sound-dai-cells = <1>;
+ /* DAI-format / AP_ENA reg value */
+audio-ports = ,
+ ;
+
+port {
+tda998x_in: endpoint {
+remote-endpoint = <_0>;
+};
+};
+};
+};
diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
deleted file mode 100644
index f5a02f61dd36f1c6..
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Device-Tree bindings for the NXP TDA998x HDMI transmitter
-
-Required properties;
- - compatible: must be "nxp,tda998x"
-
- - reg: I2C address
-
-Required node:
- - port: Input port node with endpoint definition, as described
-in Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
- - interrupts: interrupt number and trigger type
- default: polling
-
- - pinctrl-0: pin control group to be used for
- screen plug/unplug interrupt.
-
- - pinctrl-names: must contain a "default" entry.
-
- - video-ports: 24 bits value which defines how the video controller
- output is wired to the TDA998x input - default: <0x230145>
-
- - audio-ports: array of 8-bit values, 2 values per one DAI[1].
- The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2].
- The second value defines the tda998x AP_ENA reg content when the DAI
- in question is used. The implementation allows one or two DAIs. If two
- DAIs are defined, they must be of different type.
-
- - nxp,calib-gpios:
[PATCH v2 0/3] dt-bindings: display: bridge: nxp, tda998x: Json-schema conversion and fixes
Hi all,
This patch series converts the NXP TDA998x HDMI transmitter Device Tree
binding documentation to json-schema, after a few customary fixes.
Changes compared to v1:
- Add maximum to video-ports,
- Drop unneeded maxItems for audio-ports,
- Complete port descriptions.
Thanks for your comments!
[1] "[PATCH 0/3] dt-bindings: display: bridge: nxp,tda998x: Json-schema
conversion and fixes"
https://lore.kernel.org/r/cover.1634822085.git.geert+rene...@glider.be/
Geert Uytterhoeven (3):
ARM: dts: am335x: Fix TDA998x ports addressing
[RFC] arm64: dts: renesas: cat874: Drop bogus clocks property
dt-bindings: display: bridge: nxp,tda998x: Convert to json-schema
.../bindings/display/bridge/nxp,tda998x.yaml | 109 ++
.../bindings/display/bridge/tda998x.txt | 54 -
arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi | 7 +-
arch/arm/boot/dts/am335x-myirtech-myd.dts | 7 +-
.../boot/dts/renesas/r8a774c0-cat874.dts | 1 -
5 files changed, 121 insertions(+), 57 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
delete mode 100644 Documentation/devicetree/bindings/display/bridge/tda998x.txt
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 2/3] [RFC] arm64: dts: renesas: cat874: Drop bogus clocks property
The NXP TDA998x HDMI transmitter Device Tree binding documentation does
not mention a clocks property.
Signed-off-by: Geert Uytterhoeven
---
Is this property just missing from the bindings?
The driver doesn't seem to use it.
v2:
- No changes.
---
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
index 5a6ea08ffd2b2791..d42e24d9c09b9162 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
@@ -239,7 +239,6 @@ tda19988: tda19988@70 {
#sound-dai-cells = <0>;
audio-ports = ;
- clocks = <_sound 1>;
ports {
#address-cells = <1>;
--
2.25.1
Re: mgag200 broken on kernel-6.0-rc3 on DELL/T620
(cc: Jocelyn) Hi Am 14.09.22 um 10:29 schrieb Wang Yugui: Hi, Hi Am 13.09.22 um 17:15 schrieb Wang Yugui: [...] so I tried to revert patch of mgag200 driver in batch of 2 or 3, the I noticed the patch 'Subject: drm/mgag200: Remove special case for G200SE with <2 MiB' and then tried this dirty fix. Oh, great work! Thank you. From looking at the screenshot that you provided, it seems as if the 24-bit mode setting is broken. I'm not sure why the G200SE workaround applies to a G200ER, but we'll see. I tested 'preferred_depth = 32' too. it works on T630 too. so both 16 and 32 work, but 24 failed on DELL/T630. I tried on my test machine with a 5.19 kernel and found that 32-bit and 24-bit pixels work, but 16-bit looks incorrect. What are the results if you boot your kernel 5.19.3 with the parameter video=1024x768-24? This should enable 24-bit pixels. How does video=1024x768-16 look with the 5.19 kernel? test result here kernel 5.19.3 & video=1024x768-24 dell/T620/centos-8.5broken dell/T630/centos-7.9broken I assume that Centos 7 and 8 have fairly old kernels? So it's been a long-standing bug. 24-bit works on my G200HE and G200 test machines. Maybe the G200ER has a bug. When I try 16-bit depth, the display works, but is way too dark. No fiddling with the LUT tables fixes this. It's 90s hardware, so it should support 16-bit framebuffers well, but there's no obvious bug to be seen. I guess, we could remove 16 and 24 bit support for now if nothing else helps. Best regards Thomas kernel 5.19.3 & video=1024x768-32 dell/T620/centos-8.5OK dell/T630/centos-7.9OK Both DELL/T620 and DELL/T630 have the lastest BIOS/iDRAC installed. Best Regards Wang Yugui (wangyu...@e16-tech.com) 2022/09/14 Best regards Thomas diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c index 225cca2ed60e..563e3ab05fbc 100644 --- a/drivers/gpu/drm/mgag200/mgag200_mode.c +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c @@ -1070,7 +1070,7 @@ int mgag200_modeset_init(struct mga_device *mdev, resource_size_t vram_available dev->mode_config.max_width = MGAG200_MAX_FB_WIDTH; dev->mode_config.max_height = MGAG200_MAX_FB_HEIGHT; - dev->mode_config.preferred_depth = 24; + dev->mode_config.preferred_depth = 32; dev->mode_config.fb_base = mdev->vram_res->start; dev->mode_config.funcs = _mode_config_funcs; Best Regards Wang Yugui (wangyu...@e16-tech.com) 2022/09/13 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Gesch?ftsführer: Ivo Totev -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 3/8] dt-bindings: Add bindings for Tegra234 NVDEC
On Wed, Sep 14, 2022 at 03:19:01PM +0300, Mikko Perttunen wrote: > On 9/14/22 15:08, Rob Herring wrote: > > On Tue, Sep 13, 2022 at 04:14:41PM +0300, Mikko Perttunen wrote: > > > From: Mikko Perttunen > > > > > > Update NVDEC bindings for Tegra234. This new engine version only has > > > two memory clients, but now requires three clocks, and as a bigger > > > change the engine loads firmware from a secure carveout configured by > > > the bootloader. > > > > > > For the latter, we need to add a phandle to the memory controller > > > to query the location of this carveout, and several other properties > > > containing offsets into the firmware inside the carveout. These > > > properties are intended to be populated through a device tree overlay > > > configured at flashing time, so that the values correspond to the > > > flashed NVDEC firmware. > > > > > > As the binding was getting large with many conditional properties, > > > also split the Tegra234 version out into a separate file. > > > > > > Signed-off-by: Mikko Perttunen > > > --- > > > v2: > > > - Split out into separate file to avoid complexity with > > >conditionals etc. > > > --- > > > .../gpu/host1x/nvidia,tegra234-nvdec.yaml | 154 ++ > > > 1 file changed, 154 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > new file mode 100644 > > > index ..eab0475ca983 > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > > @@ -0,0 +1,154 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > > "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#; > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > > > + > > > +title: Device tree binding for NVIDIA Tegra234 NVDEC > > > + > > > +description: | > > > + NVDEC is the hardware video decoder present on NVIDIA Tegra210 > > > + and newer chips. It is located on the Host1x bus and typically > > > + programmed through Host1x channels. > > > + > > > +maintainers: > > > + - Thierry Reding > > > + - Mikko Perttunen > > > + > > > +properties: > > > + $nodename: > > > +pattern: "^nvdec@[0-9a-f]*$" > > > + > > > + compatible: > > > +enum: > > > + - nvidia,tegra234-nvdec > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + clocks: > > > +maxItems: 3 > > > + > > > + clock-names: > > > +items: > > > + - const: nvdec > > > + - const: fuse > > > + - const: tsec_pka > > > + > > > + resets: > > > +maxItems: 1 > > > + > > > + reset-names: > > > +items: > > > + - const: nvdec > > > + > > > + power-domains: > > > +maxItems: 1 > > > + > > > + iommus: > > > +maxItems: 1 > > > + > > > + dma-coherent: true > > > + > > > + interconnects: > > > +items: > > > + - description: DMA read memory client > > > + - description: DMA write memory client > > > + > > > + interconnect-names: > > > +items: > > > + - const: dma-mem > > > + - const: write > > > + > > > + nvidia,memory-controller: > > > +$ref: /schemas/types.yaml#/definitions/phandle > > > +description: > > > + phandle to the memory controller for determining carveout > > > information. > > > + > > > + nvidia,bl-manifest-offset: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: > > > + Offset to bootloader manifest from beginning of firmware. > > > Typically set as > > > + part of a device tree overlay corresponding to flashed firmware. > > > + > > > + nvidia,bl-code-offset: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: > > > + Offset to bootloader code section from beginning of firmware. > > > Typically set as > > > + part of a device tree overlay corresponding to flashed firmware. > > > + > > > + nvidia,bl-data-offset: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: > > > + Offset to bootloader data section from beginning of firmware. > > > Typically set as > > > + part of a device tree overlay corresponding to flashed firmware. > > > + > > > + nvidia,os-manifest-offset: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: > > > + Offset to operating system manifest from beginning of firmware. > > > Typically set as > > > + part of a device tree overlay corresponding to flashed firmware. > > > + > > > + nvidia,os-code-offset: > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > +description: > > > + Offset to operating system code section from beginning of > > > firmware. Typically set as > > > + part of a device tree
Re: [PATCH] A simple doc fix
On 2022-09-14 06:36, Anup K Parikh wrote:
Fix two warnings during doc build which also results in corresponding
additions in generated docs
Warnings Fixed:
1. include/drm/gpu_scheduler.h:462: warning: Function parameter or member
'dev' not described in 'drm_gpu_scheduler'
2. drivers/gpu/drm/scheduler/sched_main.c:1005: warning: Function
parameter or member 'dev' not described in 'drm_sched_init'
Signed-off-by: Anup K Parikh
---
drivers/gpu/drm/scheduler/sched_main.c | 1 +
include/drm/gpu_scheduler.h| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 68317d3a7a27..875d00213849 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -994,6 +994,7 @@ static int drm_sched_main(void *param)
*used
* @score: optional score atomic shared with other schedulers
* @name: name used for debugging
+ * @dev: A device pointer for use in error reporting in a multiple GPU
scenario.
Why multiple GPUs scenario ? It's also used in single GPU scenario.
Andrey
*
* Return 0 on success, otherwise error code.
*/
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index addb135eeea6..920b91fd1719 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -435,6 +435,7 @@ struct drm_sched_backend_ops {
* @_score: score used when the driver doesn't provide one
* @ready: marks if the underlying HW is ready to work
* @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: A device pointer for use in error reporting in a multiple GPU
scenario.
*
* One scheduler is implemented for each hardware ring.
*/
Re: [PATCH] drm/amd/display: fix boolconv.cocci warning
Applied. Thanks! On Wed, Sep 14, 2022 at 3:53 AM Yihao Han wrote: > > ./drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c:729:63-68: > WARNING: conversion to bool not needed here > > Generated by: scripts/coccinelle/misc/boolconv.cocci > Signed-off-by: Yihao Han > --- > drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c > b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c > index f4bc77972c4e..4edd0655965b 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c > @@ -726,7 +726,7 @@ static bool mpc32_program_shaper( > else > next_mode = LUT_RAM_A; > > - mpc32_configure_shaper_lut(mpc, next_mode == LUT_RAM_A ? true:false, > mpcc_id); > + mpc32_configure_shaper_lut(mpc, next_mode == LUT_RAM_A, mpcc_id); > > if (next_mode == LUT_RAM_A) > mpc32_program_shaper_luta_settings(mpc, params, mpcc_id); > -- > 2.17.1 >
Re: [PATCH 8/8] drm/amd/display: make optc32_phantom_crtc_post_enable, optc32_setup_manual_trigger and optc32_set_drr static
Applied the series. Thanks!
Alex
On Wed, Sep 14, 2022 at 1:29 AM Jiapeng Chong
wrote:
>
> These three functions are not used outside the function
> dcn32_optc.c, so the modification is defined as static.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_optc.c:159:6: warning:
> no previous prototype for function 'optc32_phantom_crtc_post_enable'.
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_optc.c:218:6: warning:
> no previous prototype for ‘optc32_set_drr’.
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_optc.c:193:6: warning:
> no previous prototype for ‘optc32_setup_manual_trigger’.
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2140
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> index 1fad7b48bd5b..ec3989d37086 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> @@ -156,7 +156,7 @@ static bool optc32_disable_crtc(struct timing_generator
> *optc)
> return true;
> }
>
> -void optc32_phantom_crtc_post_enable(struct timing_generator *optc)
> +static void optc32_phantom_crtc_post_enable(struct timing_generator *optc)
> {
> struct optc *optc1 = DCN10TG_FROM_TG(optc);
>
> @@ -190,7 +190,7 @@ static void optc32_set_odm_bypass(struct timing_generator
> *optc,
> optc1->opp_count = 1;
> }
>
> -void optc32_setup_manual_trigger(struct timing_generator *optc)
> +static void optc32_setup_manual_trigger(struct timing_generator *optc)
> {
> struct optc *optc1 = DCN10TG_FROM_TG(optc);
> struct dc *dc = optc->ctx->dc;
> @@ -215,7 +215,7 @@ void optc32_setup_manual_trigger(struct timing_generator
> *optc)
> }
> }
>
> -void optc32_set_drr(
> +static void optc32_set_drr(
> struct timing_generator *optc,
> const struct drr_params *params)
> {
> --
> 2.20.1.7.g153144c
>
Re: [Intel-gfx] [PATCH] drm/i915: Fix return type of mode_valid function hook
On 13.09.2022 22:55, Nathan Huckleberry wrote:
All of the functions used for intel_dvo_dev_ops.mode_valid have a return
type of enum drm_mode_status, but the mode_valid field in the struct
definition has a return type of int.
The mismatched return type breaks forward edge kCFI since the underlying
function definitions do not match the function hook definition.
The return type of the mode_valid field should be changed from int to
enum drm_mode_status.
Reported-by: Dan Carpenter
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: l...@lists.linux.dev
Signed-off-by: Nathan Huckleberry
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/display/intel_dvo_dev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dvo_dev.h
b/drivers/gpu/drm/i915/display/intel_dvo_dev.h
index d96c3cc46e50..50205f064d93 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo_dev.h
+++ b/drivers/gpu/drm/i915/display/intel_dvo_dev.h
@@ -75,8 +75,8 @@ struct intel_dvo_dev_ops {
*
* \return MODE_OK if the mode is valid, or another MODE_* otherwise.
*/
- int (*mode_valid)(struct intel_dvo_device *dvo,
- struct drm_display_mode *mode);
+ enum drm_mode_status (*mode_valid)(struct intel_dvo_device *dvo,
+ struct drm_display_mode *mode);
/*
* Callback for preparing mode changes on an output
Re: [PATCH] drm/rockchip: vop2: Fix Null Pointer Dereference on Multiple VPs
On Wed, Sep 14, 2022 at 08:04:18AM -0500, Chris Morgan wrote: > On Wed, Sep 14, 2022 at 08:49:27AM +0200, Sascha Hauer wrote: > > On Tue, Sep 13, 2022 at 08:55:22AM +0200, Michael Riesch wrote: > > > Hi, > > > > > > On 9/12/22 20:02, Chris Morgan wrote: > > > > From: Chris Morgan > > > > > > Cc: Sascha -> any thoughts on this one? > > > > > > Best regards, > > > Michael > > > > > > > If I use more than one VP to output on an RK3566 based device I > > > > receive the following error (and then everything freezes): > > > > > > > > [0.838375] Unable to handle kernel NULL pointer dereference at > > > > virtual address 0250 > > > > [0.839191] Mem abort info: > > > > [0.839442] ESR = 0x9605 > > > > [0.839785] EC = 0x25: DABT (current EL), IL = 32 bits > > > > [0.840256] SET = 0, FnV = 0 > > > > [0.840530] EA = 0, S1PTW = 0 > > > > [0.840821] FSC = 0x05: level 1 translation fault > > > > [0.841254] Data abort info: > > > > [0.841512] ISV = 0, ISS = 0x0005 > > > > [0.841864] CM = 0, WnR = 0 > > > > [0.842130] [0250] user address but active_mm is swapper > > > > [0.842704] Internal error: Oops: 9605 [#1] SMP > > > > [0.843139] Modules linked in: > > > > [0.843420] CPU: 0 PID: 37 Comm: kworker/u8:1 Not tainted 6.0.0-rc5+ > > > > #40 > > > > [0.844013] Hardware name: RG503 (DT) > > > > [0.844343] Workqueue: events_unbound deferred_probe_work_func > > > > [0.844871] pstate: 8009 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS > > > > BTYPE=--) > > > > [0.845487] pc : __drm_crtc_init_with_planes+0x48/0x2e4 > > > > [0.845956] lr : drm_crtc_init_with_planes+0x68/0x94 > > > > [0.846399] sp : ffc00a7a3710 > > > > [0.846695] x29: ffc00a7a3710 x28: ff8000fb4080 x27: > > > > ffc00a7a37a0 > > > > [0.847332] x26: ffc0097d01c7 x25: ff8000fb44d8 x24: > > > > ffc0097d01c7 > > > > [0.847967] x23: ffc009311870 x22: x21: > > > > 0008 > > > > [0.848603] x20: ff80010d0800 x19: ff8000fb44e8 x18: > > > > > > > > [0.849237] x17: 08d1 x16: 0891 x15: > > > > 08c1 > > > > [0.849874] x14: x13: 3432564e3631564e x12: > > > > 3231564e36314742 > > > > [0.850509] x11: 3631475234324742 x10: 002d x9 : > > > > ffc008682004 > > > > [0.851144] x8 : 006f7475 x7 : fff0 x6 : > > > > ffc00a7a37a0 > > > > [0.851778] x5 : ffc0097d01c7 x4 : ffc009311870 x3 : > > > > > > > > [0.852412] x2 : 0008 x1 : ff8000fb44e8 x0 : > > > > ff80010d0800 > > > > [0.853048] Call trace: > > > > [0.853270] __drm_crtc_init_with_planes+0x48/0x2e4 > > > > [0.853706] drm_crtc_init_with_planes+0x68/0x94 > > > > [0.854118] vop2_bind+0x89c/0x920 > > > > [0.854429] component_bind_all+0x18c/0x290 > > > > [0.854805] rockchip_drm_bind+0xe4/0x1f0 > > > > [0.855166] try_to_bring_up_aggregate_device+0x9c/0x290 > > > > [0.855639] __component_add+0x110/0x168 > > > > [0.855991] component_add+0x1c/0x28 > > > > [0.856312] dw_mipi_dsi_rockchip_host_attach+0x98/0x10c > > > > [0.856785] dw_mipi_dsi_host_attach+0xbc/0xd0 > > > > [0.857184] mipi_dsi_attach+0x30/0x44 > > > > [0.857521] devm_mipi_dsi_attach+0x2c/0x70 > > > > [0.857896] ams495qa01_probe+0x2d4/0x33c > > > > [0.858257] spi_probe+0x8c/0xb8 > > > > [0.858550] really_probe+0x1e0/0x3b8 > > > > [0.858881] __driver_probe_device+0x16c/0x184 > > > > [0.859278] driver_probe_device+0x4c/0xfc > > > > [0.859646] __device_attach_driver+0xf0/0x170 > > > > [0.860043] bus_for_each_drv+0xa4/0xcc > > > > [0.860389] __device_attach+0xfc/0x1a8 > > > > [0.860733] device_initial_probe+0x1c/0x28 > > > > [0.861108] bus_probe_device+0x38/0x9c > > > > [0.861452] deferred_probe_work_func+0xdc/0xf0 > > > > [0.861855] process_one_work+0x1b0/0x260 > > > > [0.862217] process_scheduled_works+0x4c/0x50 > > > > [0.862614] worker_thread+0x1f0/0x26c > > > > [0.862949] kthread+0xc4/0xd4 > > > > [0.863227] ret_from_fork+0x10/0x20 > > > > [0.863553] Code: aa0503fa f9002bfb aa0603fb b4a2 (b9424840) > > > > [0.864095] ---[ end trace ]--- > > > > > > > > A cursory reading of the datasheet suggests it's possible to have > > > > simultaneous output to 2 distinct outputs. On page 13 it states: > > > > > > > > Support two simultaneous displays(same source) in the following > > > > interfaces: > > > > - MIPI_DSI_TX > > > > - LVDS > > > > - HDMI > > > > - eDP > > > > > > > > In order to achieve this though, I need to output to VP0 and VP1 (or > > > > any 2 distinct VPs really). This is so I can have the ref clock set > > > > to 24MHz for the HDMI and the pixel clock of the DSI panel (for the > > > > example
Re: [PATCH] drm/rockchip: vop2: Fix Null Pointer Dereference on Multiple VPs
On Wed, Sep 14, 2022 at 08:49:27AM +0200, Sascha Hauer wrote: > On Tue, Sep 13, 2022 at 08:55:22AM +0200, Michael Riesch wrote: > > Hi, > > > > On 9/12/22 20:02, Chris Morgan wrote: > > > From: Chris Morgan > > > > Cc: Sascha -> any thoughts on this one? > > > > Best regards, > > Michael > > > > > If I use more than one VP to output on an RK3566 based device I > > > receive the following error (and then everything freezes): > > > > > > [0.838375] Unable to handle kernel NULL pointer dereference at > > > virtual address 0250 > > > [0.839191] Mem abort info: > > > [0.839442] ESR = 0x9605 > > > [0.839785] EC = 0x25: DABT (current EL), IL = 32 bits > > > [0.840256] SET = 0, FnV = 0 > > > [0.840530] EA = 0, S1PTW = 0 > > > [0.840821] FSC = 0x05: level 1 translation fault > > > [0.841254] Data abort info: > > > [0.841512] ISV = 0, ISS = 0x0005 > > > [0.841864] CM = 0, WnR = 0 > > > [0.842130] [0250] user address but active_mm is swapper > > > [0.842704] Internal error: Oops: 9605 [#1] SMP > > > [0.843139] Modules linked in: > > > [0.843420] CPU: 0 PID: 37 Comm: kworker/u8:1 Not tainted 6.0.0-rc5+ > > > #40 > > > [0.844013] Hardware name: RG503 (DT) > > > [0.844343] Workqueue: events_unbound deferred_probe_work_func > > > [0.844871] pstate: 8009 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS > > > BTYPE=--) > > > [0.845487] pc : __drm_crtc_init_with_planes+0x48/0x2e4 > > > [0.845956] lr : drm_crtc_init_with_planes+0x68/0x94 > > > [0.846399] sp : ffc00a7a3710 > > > [0.846695] x29: ffc00a7a3710 x28: ff8000fb4080 x27: > > > ffc00a7a37a0 > > > [0.847332] x26: ffc0097d01c7 x25: ff8000fb44d8 x24: > > > ffc0097d01c7 > > > [0.847967] x23: ffc009311870 x22: x21: > > > 0008 > > > [0.848603] x20: ff80010d0800 x19: ff8000fb44e8 x18: > > > > > > [0.849237] x17: 08d1 x16: 0891 x15: > > > 08c1 > > > [0.849874] x14: x13: 3432564e3631564e x12: > > > 3231564e36314742 > > > [0.850509] x11: 3631475234324742 x10: 002d x9 : > > > ffc008682004 > > > [0.851144] x8 : 006f7475 x7 : fff0 x6 : > > > ffc00a7a37a0 > > > [0.851778] x5 : ffc0097d01c7 x4 : ffc009311870 x3 : > > > > > > [0.852412] x2 : 0008 x1 : ff8000fb44e8 x0 : > > > ff80010d0800 > > > [0.853048] Call trace: > > > [0.853270] __drm_crtc_init_with_planes+0x48/0x2e4 > > > [0.853706] drm_crtc_init_with_planes+0x68/0x94 > > > [0.854118] vop2_bind+0x89c/0x920 > > > [0.854429] component_bind_all+0x18c/0x290 > > > [0.854805] rockchip_drm_bind+0xe4/0x1f0 > > > [0.855166] try_to_bring_up_aggregate_device+0x9c/0x290 > > > [0.855639] __component_add+0x110/0x168 > > > [0.855991] component_add+0x1c/0x28 > > > [0.856312] dw_mipi_dsi_rockchip_host_attach+0x98/0x10c > > > [0.856785] dw_mipi_dsi_host_attach+0xbc/0xd0 > > > [0.857184] mipi_dsi_attach+0x30/0x44 > > > [0.857521] devm_mipi_dsi_attach+0x2c/0x70 > > > [0.857896] ams495qa01_probe+0x2d4/0x33c > > > [0.858257] spi_probe+0x8c/0xb8 > > > [0.858550] really_probe+0x1e0/0x3b8 > > > [0.858881] __driver_probe_device+0x16c/0x184 > > > [0.859278] driver_probe_device+0x4c/0xfc > > > [0.859646] __device_attach_driver+0xf0/0x170 > > > [0.860043] bus_for_each_drv+0xa4/0xcc > > > [0.860389] __device_attach+0xfc/0x1a8 > > > [0.860733] device_initial_probe+0x1c/0x28 > > > [0.861108] bus_probe_device+0x38/0x9c > > > [0.861452] deferred_probe_work_func+0xdc/0xf0 > > > [0.861855] process_one_work+0x1b0/0x260 > > > [0.862217] process_scheduled_works+0x4c/0x50 > > > [0.862614] worker_thread+0x1f0/0x26c > > > [0.862949] kthread+0xc4/0xd4 > > > [0.863227] ret_from_fork+0x10/0x20 > > > [0.863553] Code: aa0503fa f9002bfb aa0603fb b4a2 (b9424840) > > > [0.864095] ---[ end trace ]--- > > > > > > A cursory reading of the datasheet suggests it's possible to have > > > simultaneous output to 2 distinct outputs. On page 13 it states: > > > > > > Support two simultaneous displays(same source) in the following > > > interfaces: > > > - MIPI_DSI_TX > > > - LVDS > > > - HDMI > > > - eDP > > > > > > In order to achieve this though, I need to output to VP0 and VP1 (or > > > any 2 distinct VPs really). This is so I can have the ref clock set > > > to 24MHz for the HDMI and the pixel clock of the DSI panel (for the > > > example above it's 33.5MHz). Currently, only by removing this code > > > block is such a thing possible, though I'm not sure if long-term > > > there should only be 1 CRTC for the rk3566 (and 2 CRTCs for 3568) > > > along with a max of 2 encoders for rk3566 (and 3 encoders for
Re: [PATCH v2 3/8] dt-bindings: Add bindings for Tegra234 NVDEC
On 9/14/22 15:08, Rob Herring wrote: On Tue, Sep 13, 2022 at 04:14:41PM +0300, Mikko Perttunen wrote: From: Mikko Perttunen Update NVDEC bindings for Tegra234. This new engine version only has two memory clients, but now requires three clocks, and as a bigger change the engine loads firmware from a secure carveout configured by the bootloader. For the latter, we need to add a phandle to the memory controller to query the location of this carveout, and several other properties containing offsets into the firmware inside the carveout. These properties are intended to be populated through a device tree overlay configured at flashing time, so that the values correspond to the flashed NVDEC firmware. As the binding was getting large with many conditional properties, also split the Tegra234 version out into a separate file. Signed-off-by: Mikko Perttunen --- v2: - Split out into separate file to avoid complexity with conditionals etc. --- .../gpu/host1x/nvidia,tegra234-nvdec.yaml | 154 ++ 1 file changed, 154 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml new file mode 100644 index ..eab0475ca983 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#; +$schema: "http://devicetree.org/meta-schemas/core.yaml#; + +title: Device tree binding for NVIDIA Tegra234 NVDEC + +description: | + NVDEC is the hardware video decoder present on NVIDIA Tegra210 + and newer chips. It is located on the Host1x bus and typically + programmed through Host1x channels. + +maintainers: + - Thierry Reding + - Mikko Perttunen + +properties: + $nodename: +pattern: "^nvdec@[0-9a-f]*$" + + compatible: +enum: + - nvidia,tegra234-nvdec + + reg: +maxItems: 1 + + clocks: +maxItems: 3 + + clock-names: +items: + - const: nvdec + - const: fuse + - const: tsec_pka + + resets: +maxItems: 1 + + reset-names: +items: + - const: nvdec + + power-domains: +maxItems: 1 + + iommus: +maxItems: 1 + + dma-coherent: true + + interconnects: +items: + - description: DMA read memory client + - description: DMA write memory client + + interconnect-names: +items: + - const: dma-mem + - const: write + + nvidia,memory-controller: +$ref: /schemas/types.yaml#/definitions/phandle +description: + phandle to the memory controller for determining carveout information. + + nvidia,bl-manifest-offset: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Offset to bootloader manifest from beginning of firmware. Typically set as + part of a device tree overlay corresponding to flashed firmware. + + nvidia,bl-code-offset: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Offset to bootloader code section from beginning of firmware. Typically set as + part of a device tree overlay corresponding to flashed firmware. + + nvidia,bl-data-offset: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Offset to bootloader data section from beginning of firmware. Typically set as + part of a device tree overlay corresponding to flashed firmware. + + nvidia,os-manifest-offset: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Offset to operating system manifest from beginning of firmware. Typically set as + part of a device tree overlay corresponding to flashed firmware. + + nvidia,os-code-offset: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Offset to operating system code section from beginning of firmware. Typically set as + part of a device tree overlay corresponding to flashed firmware. + + nvidia,os-data-offset: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Offset to operating system data section from beginning of firmware. Typically set as + part of a device tree overlay corresponding to flashed firmware. I don't think DT is the place for describing your runtime loaded firmware layout. Rob The way I see it, from the kernel's point of view it's not runtime loaded but a contract with the bootloader. Bootloader sets up hardware in a certain way the kernel doesn't otherwise know so the bootloader needs to tell the kernel how the hardware is set up. The fact that the information is supplied through an overlay is accidental -- equivalently the bootloader that sets up the firmware could adjust the device tree like we do in other situations, but in this case an overlay is an easier implementation
[v5] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nits (Doug, Dmitry)
- Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
Changes in v2:
- Move the address offset to flush macro (Dmitry)
- Seperate ops for the sub block flush (Dmitry)
Changes in v3:
- Reuse the DPU_DSPP_xx enum instead of a new one (Dmitry)
Changes in v4:
- Use shorter version for unsigned int (Stephen)
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 35 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++--
5 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 601d687..4170fbe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
/* stage config flush mask */
ctl->ops.update_pending_flush_dspp(ctl,
- mixer[i].hw_dspp->idx);
+ mixer[i].hw_dspp->idx, DPU_DSPP_PCC);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029f..0eecb2f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -65,7 +65,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38a..8148e91 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -161,10 +161,12 @@ enum {
* DSPP sub-blocks
* @DPU_DSPP_PCC Panel color correction block
* @DPU_DSPP_GC Gamma correction block
+ * @DPU_DSPP_IGC Inverse Gamma correction block
*/
enum {
DPU_DSPP_PCC = 0x1,
DPU_DSPP_GC,
+ DPU_DSPP_IGC,
DPU_DSPP_MAX
};
@@ -191,6 +193,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_DSPP_BLOCK_FLUSH: CTL config to support dspp sub-block flush
* @DPU_CTL_MAX
*/
enum {
@@ -198,6 +201,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a35ecb6..f26f484 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -33,6 +33,7 @@
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n - 1) * 4))
#define CTL_MIXER_BORDER_OUTBIT(24)
#define CTL_FLUSH_MASK_CTL BIT(17)
@@ -287,8 +288,9 @@ static void
dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
}
static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
- enum dpu_dspp dspp)
+ enum dpu_dspp dspp, u32 dspp_sub_blk)
{
+
switch (dspp) {
case DSPP_0:
ctx->pending_flush_mask |= BIT(13);
@@ -307,6 +309,31 @@ static void dpu_hw_ctl_update_pending_flush_dspp(struct
dpu_hw_ctl *ctx,
}
}
+static void dpu_hw_ctl_update_pending_flush_dspp_subblocks(
+ struct dpu_hw_ctl *ctx, enum dpu_dspp dspp, u32 dspp_sub_blk)
+{
+ u32 flushbits = 0, active;
+
+ switch (dspp_sub_blk) {
+ case DPU_DSPP_IGC:
+ flushbits = BIT(2);
+ break;
+ case DPU_DSPP_PCC:
+ flushbits = BIT(4);
+ break;
+ case DPU_DSPP_GC:
+ flushbits = BIT(5);
+ break;
+ default:
+ return;
+ }
+
+ active = DPU_REG_READ(>hw, CTL_DSPP_n_FLUSH(dspp));
+ DPU_REG_WRITE(>hw, CTL_DSPP_n_FLUSH(dspp), active | flushbits);
+
+ ctx->pending_flush_mask |= BIT(29);
+}
+
Re: [PATCH v2 3/8] dt-bindings: Add bindings for Tegra234 NVDEC
On Tue, Sep 13, 2022 at 04:14:41PM +0300, Mikko Perttunen wrote: > From: Mikko Perttunen > > Update NVDEC bindings for Tegra234. This new engine version only has > two memory clients, but now requires three clocks, and as a bigger > change the engine loads firmware from a secure carveout configured by > the bootloader. > > For the latter, we need to add a phandle to the memory controller > to query the location of this carveout, and several other properties > containing offsets into the firmware inside the carveout. These > properties are intended to be populated through a device tree overlay > configured at flashing time, so that the values correspond to the > flashed NVDEC firmware. > > As the binding was getting large with many conditional properties, > also split the Tegra234 version out into a separate file. > > Signed-off-by: Mikko Perttunen > --- > v2: > - Split out into separate file to avoid complexity with > conditionals etc. > --- > .../gpu/host1x/nvidia,tegra234-nvdec.yaml | 154 ++ > 1 file changed, 154 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > > diff --git > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > new file mode 100644 > index ..eab0475ca983 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml > @@ -0,0 +1,154 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > + > +title: Device tree binding for NVIDIA Tegra234 NVDEC > + > +description: | > + NVDEC is the hardware video decoder present on NVIDIA Tegra210 > + and newer chips. It is located on the Host1x bus and typically > + programmed through Host1x channels. > + > +maintainers: > + - Thierry Reding > + - Mikko Perttunen > + > +properties: > + $nodename: > +pattern: "^nvdec@[0-9a-f]*$" > + > + compatible: > +enum: > + - nvidia,tegra234-nvdec > + > + reg: > +maxItems: 1 > + > + clocks: > +maxItems: 3 > + > + clock-names: > +items: > + - const: nvdec > + - const: fuse > + - const: tsec_pka > + > + resets: > +maxItems: 1 > + > + reset-names: > +items: > + - const: nvdec > + > + power-domains: > +maxItems: 1 > + > + iommus: > +maxItems: 1 > + > + dma-coherent: true > + > + interconnects: > +items: > + - description: DMA read memory client > + - description: DMA write memory client > + > + interconnect-names: > +items: > + - const: dma-mem > + - const: write > + > + nvidia,memory-controller: > +$ref: /schemas/types.yaml#/definitions/phandle > +description: > + phandle to the memory controller for determining carveout information. > + > + nvidia,bl-manifest-offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Offset to bootloader manifest from beginning of firmware. Typically > set as > + part of a device tree overlay corresponding to flashed firmware. > + > + nvidia,bl-code-offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Offset to bootloader code section from beginning of firmware. > Typically set as > + part of a device tree overlay corresponding to flashed firmware. > + > + nvidia,bl-data-offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Offset to bootloader data section from beginning of firmware. > Typically set as > + part of a device tree overlay corresponding to flashed firmware. > + > + nvidia,os-manifest-offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Offset to operating system manifest from beginning of firmware. > Typically set as > + part of a device tree overlay corresponding to flashed firmware. > + > + nvidia,os-code-offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Offset to operating system code section from beginning of firmware. > Typically set as > + part of a device tree overlay corresponding to flashed firmware. > + > + nvidia,os-data-offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Offset to operating system data section from beginning of firmware. > Typically set as > + part of a device tree overlay corresponding to flashed firmware. I don't think DT is the place for describing your runtime loaded firmware layout. Rob
Re: [GIT PULL] Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86
Hi Hans, On Mon, Sep 05, 2022 at 10:35:47AM +0200, Hans de Goede wrote: > Hi All, > > Now that all patches have been reviewed/acked here is an immutable > backlight-detect-refactor > branch with 6.0-rc1 + the v5 patch-set, for merging into the relevant (acpi, > drm-* and pdx86) > subsystems. > > Please pull this branch into the relevant subsystems. > > I will merge this into the review-hans branch of the pdx86 git tree today and > from there it will move to for-next once the builders have successfully > build-tested > the merge. I merged it into drm-misc-next, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, 13 Sep 2022, Stanislav Lisovskiy wrote: > Adding DP DSC register definitions, we might need for further > DSC implementation, supporting MST and DP branch pass-through mode. > > v2: - Fixed checkpatch comment warning > v3: - Removed function which is not yet used(Jani Nikula) > > Reviewed-by: Vinod Govindapillai > > Signed-off-by: Stanislav Lisovskiy Maarten, Maxime, Thomas - Retry, can we get an ack for merging this one via drm-intel-next? Thanks, Jani. > --- > include/drm/display/drm_dp.h | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index e934aab357be..9bc22a02874d 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -240,6 +240,8 @@ > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > # define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) > > #define DP_DSC_REV 0x061 > # define DP_DSC_MAJOR_MASK (0xf << 0) > @@ -278,12 +280,15 @@ > > #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) > > #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > > #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 > +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 > +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 > > #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > # define DP_DSC_RGB (1 << 0) > @@ -345,11 +350,13 @@ > # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) > > #define DP_DSC_BITS_PER_PIXEL_INC 0x06F > +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f > +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 > # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 > # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 > # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 > # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > -# define DP_DSC_BITS_PER_PIXEL_10x4 > +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED1 -- Jani Nikula, Intel Open Source Graphics Center
[PATCH] video: fbdev: arkfb: Remove the unused function dac_read_reg()
The function dac_read_reg() is defined in the arkfb.c file, but not
called elsewhere, so delete this unused function.
drivers/video/fbdev/arkfb.c:322:18: warning: unused function 'dac_read_reg'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2155
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/video/fbdev/arkfb.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index a317d9fe1d67..5f8fec9e5fd4 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -318,14 +318,6 @@ struct dac_info
void *data;
};
-
-static inline u8 dac_read_reg(struct dac_info *info, u8 reg)
-{
- u8 code[2] = {reg, 0};
- info->dac_read_regs(info->data, code, 1);
- return code[1];
-}
-
static inline void dac_read_regs(struct dac_info *info, u8 *code, int count)
{
info->dac_read_regs(info->data, code, count);
--
2.20.1.7.g153144c
[PATCH] video: fbdev: tridentfb: Remove the unused function shadowmode_off()
The function shadowmode_off() is defined in the tridentfb.c file, but not
called elsewhere, so delete this unused function.
drivers/video/fbdev/tridentfb.c:1131:20: warning: unused function
'shadowmode_off'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2154
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/video/fbdev/tridentfb.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index f9c3b1d38fc2..2154dd5e37bd 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -1128,11 +1128,6 @@ static inline void shadowmode_on(struct tridentfb_par
*par)
write3CE(par, CyberControl, read3CE(par, CyberControl) | 0x81);
}
-static inline void shadowmode_off(struct tridentfb_par *par)
-{
- write3CE(par, CyberControl, read3CE(par, CyberControl) & 0x7E);
-}
-
/* Set the hardware to the requested video mode */
static int tridentfb_set_par(struct fb_info *info)
{
--
2.20.1.7.g153144c
[PATCH] video: fbdev: controlfb: Remove the unused function VAR_MATCH()
The function VAR_MATCH is defined in the controlfb.c file, but not
called elsewhere, so delete this unused function.
drivers/video/fbdev/controlfb.c:111:19: warning: unused function 'VAR_MATCH'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2153
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/video/fbdev/controlfb.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index aba46118b208..6bbcd9fc864e 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -108,13 +108,6 @@ static inline int PAR_EQUAL(struct fb_par_control *x,
struct fb_par_control *y)
return (!DIRTY(cmode) && !DIRTY(xres) && !DIRTY(yres)
&& !DIRTY(vxres) && !DIRTY(vyres));
}
-static inline int VAR_MATCH(struct fb_var_screeninfo *x, struct
fb_var_screeninfo *y)
-{
- return (!DIRTY(bits_per_pixel) && !DIRTY(xres)
- && !DIRTY(yres) && !DIRTY(xres_virtual)
- && !DIRTY(yres_virtual)
- && !DIRTY_CMAP(red) && !DIRTY_CMAP(green) && !DIRTY_CMAP(blue));
-}
struct fb_info_control {
struct fb_info info;
--
2.20.1.7.g153144c
Re: [PATCH 4/4] drm/edid: Avoid multiple log lines for HFVSDB parsing
Thanks Jani for the review and suggestions.
I agree with the suggestions and will make changes in next version.
Please find my response inline:
On 9/13/2022 7:24 PM, Jani Nikula wrote:
On Thu, 11 Aug 2022, Ankit Nautiyal wrote:
Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c9c3a9c8fa26..7a319d570297 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5781,6 +5781,9 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
+ u32 max_tmds_clock = 0;
This should be int because display->max_tmds_clock is int. Yes, it's a
change from the current local var, but logging u32 would require %u
instead of %d in the format string anyway, so better just use the right
type.
Alright, makes sense.
+ u8 max_frl_rate = 0;
+ bool dsc_support = false;
display->has_hdmi_infoframe = true;
@@ -5800,14 +5803,13 @@ static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
*/
if (hf_scds[5]) {
- /* max clock is 5000 KHz times block value */
- u32 max_tmds_clock = hf_scds[5] * 5000;
struct drm_scdc *scdc = >scdc;
+ /* max clock is 5000 KHz times block value */
+ max_tmds_clock = hf_scds[5] * 5000;
+
if (max_tmds_clock > 34) {
display->max_tmds_clock = max_tmds_clock;
- DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
- display->max_tmds_clock);
Hmm, the logic for what is logged gets changed.
You are right, we are now logging this always.
Should we log this only for rate > 340MHz? The logging line at last will
require some jugglery.
}
if (scdc->supported) {
@@ -5820,9 +5822,6 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
}
if (hf_scds[7]) {
- u8 max_frl_rate;
-
- DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
@@ -5830,8 +5829,14 @@ static void drm_parse_hdmi_forum_scds(struct
drm_connector *connector,
drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
- if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])
+ if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
drm_parse_dsc_info(hdmi_dsc, hf_scds);
+ dsc_support = true;
+ }
+
+ drm_dbg_kms(connector->dev,
+ "HF-VSDB: max TMDS clock:%d Khz, HDMI2.1 support:%s, DSC1.2
support:%s\n",
Nitpicks, %d needs int instead of u32, "kHz" not "Khz", "HDMI 2.1" and
"DSC 1.2" with spaces, would prefer a space after ":".
Noted, Will fix this.
+ max_tmds_clock, max_frl_rate ? "yes" : "no", dsc_support ? "yes" :
"no");
See str_yes_no().
Right, should have used str_yes_no().
Thanks & Regards,
Ankit
BR,
Jani.
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
Re: [PATCH V2 2/4] drm/bridge: Introduce pre_enable_upstream_first to alter bridge init order
Hi Dave, On Fri, Mar 4, 2022 at 8:48 PM Dave Stevenson wrote: > > DSI sink devices typically want the DSI host powered up and configured > before they are powered up. pre_enable is the place this would normally > happen, but they are called in reverse order from panel/connector towards > the encoder, which is the "wrong" order. > > Add a new flag pre_enable_upstream_first that any bridge can set > to swap the order of pre_enable (and post_disable) for that and the > immediately upstream bridge. > Should the immediately upstream bridge also set the > pre_enable_upstream_first flag, the bridge upstream of that will be called > before either of those which requested pre_enable_upstream_first. > > eg: > - Panel > - Bridge 1 > - Bridge 2 pre_enable_upstream_first > - Bridge 3 > - Bridge 4 pre_enable_upstream_first > - Bridge 5 pre_enable_upstream_first > - Bridge 6 > - Encoder > Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3, > Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. Look like this is something that I've reproduced before, isn't it? https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-6-ja...@amarulasolutions.com/ Jagan.
Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver
On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski wrote: > > Hi Jagan, > > On 13.09.2022 19:29, Jagan Teki wrote: > > On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski > > wrote: > >> On 06.09.2022 21:07, Jagan Teki wrote: > >>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski > >>> wrote: > On 02.09.2022 12:47, Marek Szyprowski wrote: > > On 29.08.2022 20:40, Jagan Teki wrote: > >> Samsung MIPI DSIM controller is common DSI IP that can be used in > >> various > >> SoCs like Exynos, i.MX8M Mini/Nano. > >> > >> In order to access this DSI controller between various platform SoCs, > >> the ideal way to incorporate this in the drm stack is via the drm > >> bridge > >> driver. > >> > >> This patch is trying to differentiate platform-specific and bridge > >> driver > >> code and keep maintaining the exynos_drm_dsi.c code as > >> platform-specific > >> glue code and samsung-dsim.c as a common bridge driver code. > >> > >> - Exynos specific glue code is exynos specific te_irq, host_attach, and > >> detach code along with conventional component_ops. > >> > >> - Samsung DSIM is a bridge driver which is common across all > >> platforms and > >> the respective platform-specific glue will initialize at the end > >> of the > >> probe. The platform-specific operations and other glue calls will > >> invoke > >> on associate code areas. > >> > >> v4: > >> * include Inki Dae in MAINTAINERS > >> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > > This breaks Exynos DRM completely as the Exynos DRM driver is not able > > to wait until the DSI driver is probed and registered as component. > > > > I will show how to rework this the way it is done in > > drivers/gpu/drm/exynos/exynos_dp.c and > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon... > I've finally had some time to implement such approach, see > https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked > > If you want me to send the patches against your v4 patchset, let me > know, but imho my changes are much more readable after squashing to the > original patches. > > Now the driver is fully multi-arch safe and ready for further > extensions. I've removed the weak functions, reworked the way the > plat_data is used (dropped the patch related to it) and restored > exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel > free to resend the above as v5 after testing on your hardware. At least > it properly works now on all Exynos boards I have, both compiled into > the kernel or as modules. > >>> Thanks. I've seen the repo added on top of Dave patches - does it mean > >>> these depends on Dave changes as well? > >> Yes and no. My rework doesn't change anything with this dependency. It > >> comes from my patch "drm: exynos: dsi: Restore proper bridge chain > >> order" already included in your series (patch #1). Without it exynos-dsi > >> driver hacks the list of bridges to ensure the order of pre_enable calls > >> needed for proper operation. This works somehow with DSI panels on my > >> test systems, but it has been reported that it doesn't work with a bit > >> more complex display pipelines. Only that patch depends on the Dave's > >> patches. If you remove it, you would need to adjust the code in the > >> exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be > >> better to keep it and merge Dave's patches together with dsi changes, as > >> they are the first real client of it. > > I think the Dave patches especially "drm/bridge: Introduce > > pre_enable_upstream_first to alter bridge init order" seems not 100% > > relevant to this series as they affect bridge chain call flow > > globally. Having a separate series for that makes sense to me. I'm > > sending v5 by excluding those parts. > > If so then drop the "drm: exynos: dsi: Restore proper bridge chain > order" patch and adjust code respectively in samsung-dsim.c. Without the > Dave's patches, that one doesn't make sense. Doesn't it break Exynos? Jagan.
Re: [PATCH] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
On Tue, 13 Sep 2022 13:55:55 -0700, Nathan Huckleberry wrote: > The mode_valid field in drm_connector_helper_funcs is expected to be of > type: > enum drm_mode_status (* mode_valid) (struct drm_connector *connector, >struct drm_display_mode *mode); > > The mismatched return type breaks forward edge kCFI since the underlying > function definition does not match the function hook definition. > > [...] Applied, thanks! [1/1] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid commit: b0b9408f132623dc88e78adb5282f74e4b64bb57 Best regards, -- Heiko Stuebner
Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver
Hi Jagan, On 13.09.2022 19:29, Jagan Teki wrote: > On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski > wrote: >> On 06.09.2022 21:07, Jagan Teki wrote: >>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski >>> wrote: On 02.09.2022 12:47, Marek Szyprowski wrote: > On 29.08.2022 20:40, Jagan Teki wrote: >> Samsung MIPI DSIM controller is common DSI IP that can be used in >> various >> SoCs like Exynos, i.MX8M Mini/Nano. >> >> In order to access this DSI controller between various platform SoCs, >> the ideal way to incorporate this in the drm stack is via the drm bridge >> driver. >> >> This patch is trying to differentiate platform-specific and bridge >> driver >> code and keep maintaining the exynos_drm_dsi.c code as platform-specific >> glue code and samsung-dsim.c as a common bridge driver code. >> >> - Exynos specific glue code is exynos specific te_irq, host_attach, and >> detach code along with conventional component_ops. >> >> - Samsung DSIM is a bridge driver which is common across all >> platforms and >> the respective platform-specific glue will initialize at the end >> of the >> probe. The platform-specific operations and other glue calls will >> invoke >> on associate code areas. >> >> v4: >> * include Inki Dae in MAINTAINERS >> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > This breaks Exynos DRM completely as the Exynos DRM driver is not able > to wait until the DSI driver is probed and registered as component. > > I will show how to rework this the way it is done in > drivers/gpu/drm/exynos/exynos_dp.c and > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon... I've finally had some time to implement such approach, see https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked If you want me to send the patches against your v4 patchset, let me know, but imho my changes are much more readable after squashing to the original patches. Now the driver is fully multi-arch safe and ready for further extensions. I've removed the weak functions, reworked the way the plat_data is used (dropped the patch related to it) and restored exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel free to resend the above as v5 after testing on your hardware. At least it properly works now on all Exynos boards I have, both compiled into the kernel or as modules. >>> Thanks. I've seen the repo added on top of Dave patches - does it mean >>> these depends on Dave changes as well? >> Yes and no. My rework doesn't change anything with this dependency. It >> comes from my patch "drm: exynos: dsi: Restore proper bridge chain >> order" already included in your series (patch #1). Without it exynos-dsi >> driver hacks the list of bridges to ensure the order of pre_enable calls >> needed for proper operation. This works somehow with DSI panels on my >> test systems, but it has been reported that it doesn't work with a bit >> more complex display pipelines. Only that patch depends on the Dave's >> patches. If you remove it, you would need to adjust the code in the >> exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be >> better to keep it and merge Dave's patches together with dsi changes, as >> they are the first real client of it. > I think the Dave patches especially "drm/bridge: Introduce > pre_enable_upstream_first to alter bridge init order" seems not 100% > relevant to this series as they affect bridge chain call flow > globally. Having a separate series for that makes sense to me. I'm > sending v5 by excluding those parts. If so then drop the "drm: exynos: dsi: Restore proper bridge chain order" patch and adjust code respectively in samsung-dsim.c. Without the Dave's patches, that one doesn't make sense. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
[PATCH AUTOSEL 4.9 08/13] video: fbdev: simplefb: Check before clk_put() not needed
From: Yihao Han
[ Upstream commit 5491424d17bdeb7b7852a59367858251783f8398 ]
clk_put() already checks the clk ptr using !clk and IS_ERR()
so there is no need to check it again before calling it.
Signed-off-by: Yihao Han
Reviewed-by: Hans de Goede
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/simplefb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 61f799a515dc7..1efdbbc20f99e 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -231,8 +231,7 @@ static int simplefb_clocks_init(struct simplefb_par *par,
if (IS_ERR(clock)) {
if (PTR_ERR(clock) == -EPROBE_DEFER) {
while (--i >= 0) {
- if (par->clks[i])
- clk_put(par->clks[i]);
+ clk_put(par->clks[i]);
}
kfree(par->clks);
return -EPROBE_DEFER;
--
2.35.1
[PATCH AUTOSEL 4.9 07/13] video: fbdev: pxa3xx-gcu: Fix integer overflow in pxa3xx_gcu_write
From: Hyunwoo Kim [ Upstream commit a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7 ] In pxa3xx_gcu_write, a count parameter of type size_t is passed to words of type int. Then, copy_from_user() may cause a heap overflow because it is used as the third argument of copy_from_user(). Signed-off-by: Hyunwoo Kim Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/pxa3xx-gcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c index 184773b6b9e4f..2cca4b763d8dc 100644 --- a/drivers/video/fbdev/pxa3xx-gcu.c +++ b/drivers/video/fbdev/pxa3xx-gcu.c @@ -391,7 +391,7 @@ pxa3xx_gcu_write(struct file *file, const char *buff, struct pxa3xx_gcu_batch *buffer; struct pxa3xx_gcu_priv *priv = to_pxa3xx_gcu_priv(file); - int words = count / 4; + size_t words = count / 4; /* Does not need to be atomic. There's a lock in user space, * but anyhow, this is just for statistics. */ -- 2.35.1
[PATCH AUTOSEL 4.9 06/13] video: fbdev: intelfb: Use aperture size from pci_resource_len
From: Petr Cvek [ Upstream commit 25c9a15fb7bbfafb94dd3b4e3165c18b8e1bd039 ] Aperture size for i9x5 variants is determined from PCI base address. if (pci_resource_start(pdev, 2) & 0x0800) *aperture_size = MB(128); ... This condition is incorrect as 128 MiB address can have the address set as 0x?800 or 0x?000. Also the code can be simplified to just use pci_resource_len(). The true settings of the aperture size is in the MSAC register, which could be used instead. However the value is used only as an info message, so it doesn't matter. Signed-off-by: Petr Cvek Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/intelfb/intelfbhw.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/video/fbdev/intelfb/intelfbhw.c b/drivers/video/fbdev/intelfb/intelfbhw.c index d31ed4e2c46f1..3aa93565e935f 100644 --- a/drivers/video/fbdev/intelfb/intelfbhw.c +++ b/drivers/video/fbdev/intelfb/intelfbhw.c @@ -199,13 +199,11 @@ int intelfbhw_get_memory(struct pci_dev *pdev, int *aperture_size, case PCI_DEVICE_ID_INTEL_945GME: case PCI_DEVICE_ID_INTEL_965G: case PCI_DEVICE_ID_INTEL_965GM: - /* 915, 945 and 965 chipsets support a 256MB aperture. - Aperture size is determined by inspected the - base address of the aperture. */ - if (pci_resource_start(pdev, 2) & 0x0800) - *aperture_size = MB(128); - else - *aperture_size = MB(256); + /* +* 915, 945 and 965 chipsets support 64MB, 128MB or 256MB +* aperture. Determine size from PCI resource length. +*/ + *aperture_size = pci_resource_len(pdev, 2); break; default: if ((tmp & INTEL_GMCH_MEM_MASK) == INTEL_GMCH_MEM_64M) -- 2.35.1
[PATCH AUTOSEL 4.9 05/13] video: fbdev: skeletonfb: Fix syntax errors in comments
From: Xiang wangx
[ Upstream commit fc378794a2f7a19cf26010dc33b89ba608d4c70f ]
Delete the redundant word 'its'.
Signed-off-by: Xiang wangx
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/skeletonfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index f948baa16d829..254bb6e2187cd 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -96,7 +96,7 @@ static struct fb_fix_screeninfo xxxfb_fix = {
/*
* Modern graphical hardware not only supports pipelines but some
- * also support multiple monitors where each display can have its
+ * also support multiple monitors where each display can have
* its own unique data. In this case each display could be
* represented by a separate framebuffer device thus a separate
* struct fb_info. Now the struct xxx_par represents the graphics
--
2.35.1
[PATCH AUTOSEL 4.9 03/13] drm/vc4: crtc: Use an union to store the page flip callback
From: Maxime Ripard
[ Upstream commit 2523e9dcc3be91bf9fdc0d1e542557ca00bbef42 ]
We'll need to extend the vc4_async_flip_state structure to rely on
another callback implementation, so let's move the current one into a
union.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
Link: https://lore.kernel.org/r/20220610115149.964394-10-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 51d34e7275ab0..9d97f535a4d66 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -717,17 +717,17 @@ struct vc4_async_flip_state {
struct drm_framebuffer *fb;
struct drm_pending_vblank_event *event;
- struct vc4_seqno_cb cb;
+ union {
+ struct vc4_seqno_cb seqno;
+ } cb;
};
/* Called when the V3D execution for the BO being flipped to is done, so that
* we can actually update the plane's address to point to it.
*/
static void
-vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
+vc4_async_page_flip_complete(struct vc4_async_flip_state *flip_state)
{
- struct vc4_async_flip_state *flip_state =
- container_of(cb, struct vc4_async_flip_state, cb);
struct drm_crtc *crtc = flip_state->crtc;
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -749,6 +749,14 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
up(>async_modeset);
}
+static void vc4_async_page_flip_seqno_complete(struct vc4_seqno_cb *cb)
+{
+ struct vc4_async_flip_state *flip_state =
+ container_of(cb, struct vc4_async_flip_state, cb.seqno);
+
+ vc4_async_page_flip_complete(flip_state);
+}
+
/* Implements async (non-vblank-synced) page flips.
*
* The page flip ioctl needs to return immediately, so we grab the
@@ -794,8 +802,8 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
drm_atomic_set_fb_for_plane(plane->state, fb);
plane->fb = fb;
- vc4_queue_seqno_cb(dev, _state->cb, bo->seqno,
- vc4_async_page_flip_complete);
+ vc4_queue_seqno_cb(dev, _state->cb.seqno, bo->seqno,
+ vc4_async_page_flip_seqno_complete);
/* Driver takes ownership of state on successful async commit. */
return 0;
--
2.35.1
[PATCH AUTOSEL 5.15 15/16] drm/panfrost: devfreq: set opp to the recommended one to configure regulator
From: Clément Péron
[ Upstream commit d76034a427a2660b080bc155e4fd8f6393eefb48 ]
Enabling panfrost GPU OPP with dynamic regulator will make OPP
responsible to enable and configure it.
Unfortunately OPP configure and enable the regulator when an OPP
is asked to be set, which is not the case during
panfrost_devfreq_init().
This leave the regulator unconfigured and if no GPU load is
triggered, no OPP is asked to be set which make the regulator framework
switching it off during regulator_late_cleanup() without
noticing and therefore make the board hang as any access to GPU
memory space make bus locks up.
Call dev_pm_opp_set_opp() with the recommend OPP in
panfrost_devfreq_init() to enable the regulator, this will properly
configure and enable the regulator and will avoid any switch off
by regulator_late_cleanup().
Suggested-by: Viresh Kumar
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906153034.153321-5-peron.c...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 194af7f607a6e..be36dd060a2b4 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -132,6 +132,17 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return PTR_ERR(opp);
panfrost_devfreq_profile.initial_freq = cur_freq;
+
+ /*
+* Set the recommend OPP this will enable and configure the regulator
+* if any and will avoid a switch off by regulator_late_cleanup()
+*/
+ ret = dev_pm_opp_set_opp(dev, opp);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Couldn't set recommended OPP\n");
+ return ret;
+ }
+
dev_pm_opp_put(opp);
/*
--
2.35.1
[PATCH AUTOSEL 5.19 21/22] drm/panfrost: devfreq: set opp to the recommended one to configure regulator
From: Clément Péron
[ Upstream commit d76034a427a2660b080bc155e4fd8f6393eefb48 ]
Enabling panfrost GPU OPP with dynamic regulator will make OPP
responsible to enable and configure it.
Unfortunately OPP configure and enable the regulator when an OPP
is asked to be set, which is not the case during
panfrost_devfreq_init().
This leave the regulator unconfigured and if no GPU load is
triggered, no OPP is asked to be set which make the regulator framework
switching it off during regulator_late_cleanup() without
noticing and therefore make the board hang as any access to GPU
memory space make bus locks up.
Call dev_pm_opp_set_opp() with the recommend OPP in
panfrost_devfreq_init() to enable the regulator, this will properly
configure and enable the regulator and will avoid any switch off
by regulator_late_cleanup().
Suggested-by: Viresh Kumar
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906153034.153321-5-peron.c...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 194af7f607a6e..be36dd060a2b4 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -132,6 +132,17 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return PTR_ERR(opp);
panfrost_devfreq_profile.initial_freq = cur_freq;
+
+ /*
+* Set the recommend OPP this will enable and configure the regulator
+* if any and will avoid a switch off by regulator_late_cleanup()
+*/
+ ret = dev_pm_opp_set_opp(dev, opp);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Couldn't set recommended OPP\n");
+ return ret;
+ }
+
dev_pm_opp_put(opp);
/*
--
2.35.1
[PATCH AUTOSEL 5.19 20/22] drm/amdgpu: prevent toc firmware memory leak
From: Guchun Chen
[ Upstream commit aac4cec1ec45d72bd03eaf3fd772c5a609f5ed26 ]
It's missed in psp fini.
Signed-off-by: Guchun Chen
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index e9411c28d88ba..9cb7d208a09ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -481,11 +481,14 @@ static int psp_sw_fini(void *handle)
release_firmware(psp->ta_fw);
psp->ta_fw = NULL;
}
- if (adev->psp.cap_fw) {
+ if (psp->cap_fw) {
release_firmware(psp->cap_fw);
psp->cap_fw = NULL;
}
-
+ if (psp->toc_fw) {
+ release_firmware(psp->toc_fw);
+ psp->toc_fw = NULL;
+ }
if (adev->ip_versions[MP0_HWIP][0] == IP_VERSION(11, 0, 0) ||
adev->ip_versions[MP0_HWIP][0] == IP_VERSION(11, 0, 7))
psp_sysfs_fini(adev);
--
2.35.1
[PATCH AUTOSEL 5.19 15/22] drm/ttm: update bulk move object of ghost BO
From: ZhenGuo Yin
[ Upstream commit d91c411c744b55e860fbafc9a499f4f22d64c762 ]
[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 ttm_bo_release+0x2e1/0x2f0
[amdttm]
Call Trace:
amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
amdttm_bo_put+0x28/0x30 [amdttm]
amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
amdgpu_bo_move+0x1a8/0x770 [amdgpu]
ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
amdttm_bo_validate+0xbf/0x100 [amdttm]
[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.
v2: set bulk move to NULL manually if no resource associated with ghost BO
Fixed: 5b951e487fd6bf5f ("drm/ttm: fix bulk move handling v2")
Signed-off-by: ZhenGuo Yin
Reviewed-by: Christian König
Signed-off-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906084619.2545456-1-zhenguo@amd.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1cbfb00c1d658..57a27847206ff 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -239,6 +239,9 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
if (fbo->base.resource) {
ttm_resource_set_bo(fbo->base.resource, >base);
bo->resource = NULL;
+ ttm_bo_set_bulk_move(>base, NULL);
+ } else {
+ fbo->base.bulk_move = NULL;
}
dma_resv_init(>base.base._resv);
--
2.35.1
Re: mgag200 broken on kernel-6.0-rc3 on DELL/T620
Hi, > Hi > > Am 13.09.22 um 17:15 schrieb Wang Yugui: > [...] > >>> > >>> so I tried to revert patch of mgag200 driver in batch of 2 or 3, the I > >>> noticed the patch 'Subject: drm/mgag200: Remove special case for G200SE > >>> with <2 MiB' and then tried this dirty fix. > >> > >> Oh, great work! Thank you. From looking at the screenshot that you > >> provided, it seems as if the 24-bit mode setting is broken. I'm not sure > >> why the G200SE workaround applies to a G200ER, but we'll see. > > > > I tested 'preferred_depth = 32' too. it works on T630 too. > > > > so both 16 and 32 work, but 24 failed on DELL/T630. > > I tried on my test machine with a 5.19 kernel and found that 32-bit and > 24-bit pixels work, but 16-bit looks incorrect. > > What are the results if you boot your kernel 5.19.3 with the parameter > video=1024x768-24? This should enable 24-bit pixels. > > How does video=1024x768-16 look with the 5.19 kernel? test result here kernel 5.19.3 & video=1024x768-24 dell/T620/centos-8.5broken dell/T630/centos-7.9broken kernel 5.19.3 & video=1024x768-32 dell/T620/centos-8.5OK dell/T630/centos-7.9OK Both DELL/T620 and DELL/T630 have the lastest BIOS/iDRAC installed. Best Regards Wang Yugui (wangyu...@e16-tech.com) 2022/09/14 > > Best regards > Thomas > > > > > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c > > b/drivers/gpu/drm/mgag200/mgag200_mode.c > > index 225cca2ed60e..563e3ab05fbc 100644 > > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c > > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c > > @@ -1070,7 +1070,7 @@ int mgag200_modeset_init(struct mga_device *mdev, > > resource_size_t vram_available > > > > dev->mode_config.max_width = MGAG200_MAX_FB_WIDTH; > > dev->mode_config.max_height = MGAG200_MAX_FB_HEIGHT; > > - dev->mode_config.preferred_depth = 24; > > + dev->mode_config.preferred_depth = 32; > > dev->mode_config.fb_base = mdev->vram_res->start; > > dev->mode_config.funcs = _mode_config_funcs; > > > > Best Regards > > Wang Yugui (wangyu...@e16-tech.com) > > 2022/09/13 > > > > > > > -- Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Gesch?ftsführer: Ivo Totev
Re: [PATCH v4 07/12] drm: bridge: samsung-dsim: Fix PLL_P (PMS_P) offset
On Tue, Aug 30, 2022 at 1:12 AM Adam Ford wrote: > > On Mon, Aug 29, 2022 at 1:41 PM Jagan Teki wrote: > > > > The i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020 > > with 13.7.10.1 Master PLL PMS Value setting Register mentioned PMS_P offset > > range from BIT[18-13] and the upstream driver is using the same offset. > > > > However, offset 13 is not working on i.MX8M Mini platforms but downstream > > NXP driver is using 14 [1] and it is working with i.MX8M Mini SoC. > > From the line you highlighted in the link, the downstream NXP ones > shows 13 if I'm reading it correctly. > > #define PLLCTRL_SET_P(x) REG_PUT(x, 18, 13) PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P() with offset 13 and then an additional offset of one bit added in sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS(). Please check this for additional information https://github.com/fschrempf/linux/commit/bbb3549a99e162ef6ad4c83d5fd4d39a6daa6d56 I'll update the additional information in commit messages in v5. Thanks, Jagan.
Re: [PATCH] drm: mediatek: Fix display vblank timeout when disable dsi
Il 14/09/22 08:18, xinlei@mediatek.com ha scritto:
From: Xinlei Lee
Dsi is turned off at bridge.disable, causing crtc to wait for vblank timeout.
It is necessary to add count protection to turn off dsi, and turn off at
post_disable.
Fixes: cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from enable/disable
and define new funcs")
Signed-off-by: Xinlei Lee
Hello Xinlei,
which machine is this commit targeting?
Can you please try to reproduce again the issue that you're seeing with my
mtk_dsi fix [1], but without this commit?
Thanks,
Angelo
[1]:
https://patchwork.kernel.org/project/linux-mediatek/patch/20220721172727.14624-1-angelogioacchino.delre...@collabora.com/
