[PATCH] drm/amd/pm: Clean up errors in vega10_hwmgr.c
Fix the following errors reported by checkpatch:
ERROR: trailing statements should be on next line
ERROR: space required before the open brace '{'
ERROR: space required before the open parenthesis '('
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Ran Sun
---
.../drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
index 08518bc1cbbe..ba7294daddfe 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
@@ -670,17 +670,23 @@ static int
vega10_patch_voltage_dependency_tables_with_lookup_table(
for (i = 0; i < 6; i++) {
struct phm_ppt_v1_clock_voltage_dependency_table *vdt;
switch (i) {
- case 0: vdt = table_info->vdd_dep_on_socclk;
+ case 0:
+ vdt = table_info->vdd_dep_on_socclk;
break;
- case 1: vdt = table_info->vdd_dep_on_sclk;
+ case 1:
+ vdt = table_info->vdd_dep_on_sclk;
break;
- case 2: vdt = table_info->vdd_dep_on_dcefclk;
+ case 2:
+ vdt = table_info->vdd_dep_on_dcefclk;
break;
- case 3: vdt = table_info->vdd_dep_on_pixclk;
+ case 3:
+ vdt = table_info->vdd_dep_on_pixclk;
break;
- case 4: vdt = table_info->vdd_dep_on_dispclk;
+ case 4:
+ vdt = table_info->vdd_dep_on_dispclk;
break;
- case 5: vdt = table_info->vdd_dep_on_phyclk;
+ case 5:
+ vdt = table_info->vdd_dep_on_phyclk;
break;
}
--
2.17.1
RE: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages)
Hi Jason,
>
> > > Later the importer decides it needs the memory again so it again asks
> > > for the dmabuf to be present, which does hmm_range_fault and gets
> > > whatever is appropriate at the time.
> > Unless I am missing something, I think just doing the above still won't
> > solve
> > the problem. Consider this sequence:
> > write_to_memfd(addr1, size, 'a');
> > buf = create_udmabuf_list(devfd, memfd, size);
> > addr2 = mmap_fd(buf, NUM_PAGES * NUM_ENTRIES * getpagesize());
> > read(addr2);
> > write_to_memfd(addr1, size, 'b');
> > punch_hole(memfd, MEMFD_SIZE / 2);
> > -> Since we can process the invalidate at this point, as per your
> > suggestion,
> > we can trigger dmabuf move to let the importers know that the
> dmabuf's
> > backing memory has changed (or moved).
> >
> > read(addr2);
> > -> Because there is a hole, we can handle the read by either providing the
> > old pages or zero pages (if using hmm_range_fault()) to the
> > importers.
>
> You never provide the old pages. After trunctate the only correct
> value to read is zero.
>
> > Maybe it is against convention, but I think it makes sense to provide
> > old
> > pages (that were mapped before the hole punch) because the importers
> > have not read the data in these pages ('b' above) yet.
>
> Nope.
>
> > And, another reason to provide old pages is because the data in
> > these pages is shown in a window on the Host's screen so it
> > doesn't make sense to show zero page data.
>
> So why did you trucate it if you want to keep the data?
>
>
> > -> write_to_memfd(addr1, size, 'c');
> > As the hole gets refilled (with new pages) after the above write,
> > AFAIU,
> we
> > have to tell the importers again that since the backing memory has
> changed,
> > (new pages) they need to recreate their mappings. But herein lies the
> problem:
> > from inside the udmabuf driver, we cannot know when this write occurs,
> so we
> > would not be able to notify the importers of the dmabuf move.
>
> You get another invalidate because the memfd removes the zero pages
> that hmm_range_fault installed in the PTEs before replacing them with
> actual writable pages. Then you do the move, and another
> hmm_range_fault, and basically the whole thing over again. Except this
> time instead of returning zero pages it returns actual writable page.
Ok, when I tested earlier (by registering an invalidate callback) but without
hmm_range_fault(), I did not find this additional invalidate getting triggered.
Let me try with hmm_range_fault() and see if everything works as expected.
Thank you for your help.
Thanks,
Vivek
>
> Jason
Re: [PATCH] drm/amd/display: check attr flag before set cursor degamma on DCN3+
Tested-by: Alex Hung
On 2023-07-31 02:35, Melissa Wen wrote:
Don't set predefined degamma curve to cursor plane if the cursor
attribute flag is not set. Applying a degamma curve to the cursor by
default breaks userspace expectation. Checking the flag before
performing any color transformation prevents too dark cursor gamma in
DCN3+ on many Linux desktop environment (KDE Plasma, GNOME,
wlroots-based, etc.) as reported at:
- https://gitlab.freedesktop.org/drm/amd/-/issues/1513
This is the same approach followed by DCN2 drivers where the issue is
not present.
Fixes: 03f54d7d3448 ("drm/amd/display: Add DCN3 DPP")
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
index e5b7ef7422b8..50dc83404644 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
@@ -357,8 +357,11 @@ void dpp3_set_cursor_attributes(
int cur_rom_en = 0;
if (color_format == CURSOR_MODE_COLOR_PRE_MULTIPLIED_ALPHA ||
- color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA)
- cur_rom_en = 1;
+ color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA) {
+ if
(cursor_attributes->attribute_flags.bits.ENABLE_CURSOR_DEGAMMA) {
+ cur_rom_en = 1;
+ }
+ }
REG_UPDATE_3(CURSOR0_CONTROL,
CUR0_MODE, color_format,
[PATCH] drm/amd/pm: Clean up errors in vega10_powertune.c
Fix the following errors reported by checkpatch:
ERROR: that open brace { should be on the previous line
ERROR: space prohibited after that open parenthesis '('
Signed-off-by: Ran Sun
---
.../amd/pm/powerplay/hwmgr/vega10_powertune.c | 89 +++
1 file changed, 31 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_powertune.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_powertune.c
index 309a9d3bc1b7..3007b054c873 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_powertune.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_powertune.c
@@ -30,8 +30,7 @@
#include "pp_debug.h"
#include "soc15_common.h"
-static const struct vega10_didt_config_reg SEDiDtTuningCtrlConfig_Vega10[] =
-{
+static const struct vega10_didt_config_reg SEDiDtTuningCtrlConfig_Vega10[] = {
/*
-
* Offset Mask
Shift Value
*
-
@@ -55,8 +54,7 @@ static const struct vega10_didt_config_reg
SEDiDtTuningCtrlConfig_Vega10[] =
{ 0x } /* End of list */
};
-static const struct vega10_didt_config_reg SEDiDtCtrl3Config_vega10[] =
-{
+static const struct vega10_didt_config_reg SEDiDtCtrl3Config_vega10[] = {
/*
-
* Offset Mask
ShiftValue
*
-
@@ -120,8 +118,7 @@ static const struct vega10_didt_config_reg
SEDiDtCtrl3Config_vega10[] =
{ 0x } /* End of list */
};
-static const struct vega10_didt_config_reg SEDiDtCtrl2Config_Vega10[] =
-{
+static const struct vega10_didt_config_reg SEDiDtCtrl2Config_Vega10[] = {
/*
-
* OffsetMask
Shift Value
*
-
@@ -149,8 +146,7 @@ static const struct vega10_didt_config_reg
SEDiDtCtrl2Config_Vega10[] =
{ 0x } /* End of list */
};
-static const struct vega10_didt_config_reg SEDiDtCtrl1Config_Vega10[] =
-{
+static const struct vega10_didt_config_reg SEDiDtCtrl1Config_Vega10[] = {
/*
-
* Offset Mask
Shift Value
*
-
@@ -172,8 +168,7 @@ static const struct vega10_didt_config_reg
SEDiDtCtrl1Config_Vega10[] =
};
-static const struct vega10_didt_config_reg SEDiDtWeightConfig_Vega10[] =
-{
+static const struct vega10_didt_config_reg SEDiDtWeightConfig_Vega10[] = {
/*
-
* Offset Mask
Shift Value
*
-
@@ -201,8 +196,7 @@ static const struct vega10_didt_config_reg
SEDiDtWeightConfig_Vega10[] =
{ 0x } /* End of list */
};
-static const struct vega10_didt_config_reg SEDiDtCtrl0Config_Vega10[] =
-{
+static const struct vega10_didt_config_reg SEDiDtCtrl0Config_Vega10[] = {
/*
[PATCH -next v2] drm/i2c: tda998x: remove redundant CONFIG_OF and of_match_ptr
The driver depends on CONFIG_OF, so it is not necessary to use CONFIG_OF
and of_match_ptr here, we remove them all.
Even for drivers that do not depend on CONFIG_OF, it's almost always
better to leave out the of_match_ptr(), since the only thing it can
possibly do is to save a few bytes of .text if a driver can be used both
with and without it.
Signed-off-by: Zhu Wang
---
Changes in v2:
Remove CONFIG_OF which includes tda998x_ids
---
drivers/gpu/drm/i2c/tda998x_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d8d7de18dd65..9666e0746240 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -2084,13 +2084,11 @@ static void tda998x_remove(struct i2c_client *client)
tda998x_destroy(>dev);
}
-#ifdef CONFIG_OF
static const struct of_device_id tda998x_dt_ids[] = {
{ .compatible = "nxp,tda998x", },
{ }
};
MODULE_DEVICE_TABLE(of, tda998x_dt_ids);
-#endif
static const struct i2c_device_id tda998x_ids[] = {
{ "tda998x", 0 },
@@ -2103,7 +2101,7 @@ static struct i2c_driver tda998x_driver = {
.remove = tda998x_remove,
.driver = {
.name = "tda998x",
- .of_match_table = of_match_ptr(tda998x_dt_ids),
+ .of_match_table = tda998x_dt_ids,
},
.id_table = tda998x_ids,
};
--
2.17.1
Re: [PATCH -next] drm/i2c: tda998x: remove redundant of_match_ptr
Hi Zhu,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20230731]
url:
https://github.com/intel-lab-lkp/linux/commits/Zhu-Wang/drm-i2c-tda998x-remove-redundant-of_match_ptr/20230731-210417
base: next-20230731
patch link:
https://lore.kernel.org/r/20230731130257.94751-1-wangzhu9%40huawei.com
patch subject: [PATCH -next] drm/i2c: tda998x: remove redundant of_match_ptr
config: i386-randconfig-i012-20230731
(https://download.01.org/0day-ci/archive/20230801/202308011156.jv5blepl-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce:
(https://download.01.org/0day-ci/archive/20230801/202308011156.jv5blepl-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202308011156.jv5blepl-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i2c/tda998x_drv.c:2106:21: error: use of undeclared
>> identifier 'tda998x_dt_ids'; did you mean 'tda998x_ids'?
.of_match_table = tda998x_dt_ids,
^~
tda998x_ids
drivers/gpu/drm/i2c/tda998x_drv.c:2095:35: note: 'tda998x_ids' declared here
static const struct i2c_device_id tda998x_ids[] = {
^
>> drivers/gpu/drm/i2c/tda998x_drv.c:2106:21: error: incompatible pointer types
>> initializing 'const struct of_device_id *' with an expression of type 'const
>> struct i2c_device_id[2]' [-Werror,-Wincompatible-pointer-types]
.of_match_table = tda998x_dt_ids,
^~
2 errors generated.
vim +2106 drivers/gpu/drm/i2c/tda998x_drv.c
2100
2101 static struct i2c_driver tda998x_driver = {
2102 .probe = tda998x_probe,
2103 .remove = tda998x_remove,
2104 .driver = {
2105 .name = "tda998x",
> 2106 .of_match_table = tda998x_dt_ids,
2107 },
2108 .id_table = tda998x_ids,
2109 };
2110
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH] drm/amd/pm: Clean up errors in fiji_baco.c
Fix the following errors reported by checkpatch:
ERROR: that open brace { should be on the previous line
Signed-off-by: Ran Sun
---
.../drm/amd/pm/powerplay/hwmgr/fiji_baco.c| 24 +++
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/fiji_baco.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/fiji_baco.c
index c0368f2dfb21..b3e768fa79f2 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/fiji_baco.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/fiji_baco.c
@@ -36,8 +36,7 @@
#include "smu/smu_7_1_3_sh_mask.h"
-static const struct baco_cmd_entry gpio_tbl[] =
-{
+static const struct baco_cmd_entry gpio_tbl[] = {
{ CMD_WRITE, mmGPIOPAD_EN, 0, 0, 0, 0x0 },
{ CMD_WRITE, mmGPIOPAD_PD_EN, 0, 0, 0, 0x0 },
{ CMD_WRITE, mmGPIOPAD_PU_EN, 0, 0, 0, 0x0 },
@@ -50,15 +49,13 @@ static const struct baco_cmd_entry gpio_tbl[] =
{ CMD_READMODIFYWRITE, mmDC_GPIO_SYNCA_MASK, 0, 0, 0, 0x }
};
-static const struct baco_cmd_entry enable_fb_req_rej_tbl[] =
-{
+static const struct baco_cmd_entry enable_fb_req_rej_tbl[] = {
{ CMD_WRITE, mmGCK_SMC_IND_INDEX, 0, 0, 0, 0xC0300024 },
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA, 0x1, 0x0, 0, 0x1 },
{ CMD_WRITE, mmBIF_FB_EN, 0, 0, 0, 0x0 }
};
-static const struct baco_cmd_entry use_bclk_tbl[] =
-{
+static const struct baco_cmd_entry use_bclk_tbl[] = {
{ CMD_WRITE, mmGCK_SMC_IND_INDEX, 0, 0, 0, ixCG_SPLL_FUNC_CNTL },
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA,
CG_SPLL_FUNC_CNTL__SPLL_BYPASS_EN_MASK,
CG_SPLL_FUNC_CNTL__SPLL_BYPASS_EN__SHIFT, 0, 0x1 },
{ CMD_WRITE, mmGCK_SMC_IND_INDEX, 0, 0, 0, ixCG_SPLL_FUNC_CNTL_2 },
@@ -78,8 +75,7 @@ static const struct baco_cmd_entry use_bclk_tbl[] =
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA,
MPLL_BYPASSCLK_SEL__MPLL_CLKOUT_SEL_MASK,
MPLL_BYPASSCLK_SEL__MPLL_CLKOUT_SEL__SHIFT, 0, 0x2 }
};
-static const struct baco_cmd_entry turn_off_plls_tbl[] =
-{
+static const struct baco_cmd_entry turn_off_plls_tbl[] = {
{ CMD_WRITE, mmGCK_SMC_IND_INDEX, 0, 0, 0, ixCG_SPLL_FUNC_CNTL },
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA,
CG_SPLL_FUNC_CNTL__SPLL_RESET_MASK, CG_SPLL_FUNC_CNTL__SPLL_RESET__SHIFT, 0,
0x1 },
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA,
CG_SPLL_FUNC_CNTL__SPLL_PWRON_MASK, CG_SPLL_FUNC_CNTL__SPLL_PWRON__SHIFT, 0,
0x0 },
@@ -88,8 +84,7 @@ static const struct baco_cmd_entry turn_off_plls_tbl[] =
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA, 0x800, 0x1b, 0, 0x0 }
};
-static const struct baco_cmd_entry clk_req_b_tbl[] =
-{
+static const struct baco_cmd_entry clk_req_b_tbl[] = {
{ CMD_WRITE, mmGCK_SMC_IND_INDEX, 0, 0, 0, ixCG_CLKPIN_CNTL_2 },
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA,
CG_CLKPIN_CNTL_2__FORCE_BIF_REFCLK_EN_MASK,
CG_CLKPIN_CNTL_2__FORCE_BIF_REFCLK_EN__SHIFT, 0, 0x0 },
{ CMD_WRITE, mmGCK_SMC_IND_INDEX, 0, 0, 0, ixMPLL_BYPASSCLK_SEL },
@@ -104,8 +99,7 @@ static const struct baco_cmd_entry clk_req_b_tbl[] =
{ CMD_READMODIFYWRITE, mmGCK_SMC_IND_DATA,
THM_CLK_CNTL__TMON_CLK_SEL_MASK, THM_CLK_CNTL__TMON_CLK_SEL__SHIFT, 0, 0x1 }
};
-static const struct baco_cmd_entry enter_baco_tbl[] =
-{
+static const struct baco_cmd_entry enter_baco_tbl[] = {
{ CMD_READMODIFYWRITE, mmBACO_CNTL, BACO_CNTL__BACO_EN_MASK,
BACO_CNTL__BACO_EN__SHIFT, 0, 0x01 },
{ CMD_READMODIFYWRITE, mmBACO_CNTL,
BACO_CNTL__BACO_BIF_SCLK_SWITCH_MASK, BACO_CNTL__BACO_BIF_SCLK_SWITCH__SHIFT,
0, 0x01 },
{ CMD_WAITFOR, mmBACO_CNTL, BACO_CNTL__BACO_BIF_SCLK_SWITCH_MASK, 0, 5,
0x4 },
@@ -122,8 +116,7 @@ static const struct baco_cmd_entry enter_baco_tbl[] =
#define BACO_CNTL__PWRGOOD_MASK
BACO_CNTL__PWRGOOD_GPIO_MASK+BACO_CNTL__PWRGOOD_MEM_MASK+BACO_CNTL__PWRGOOD_DVO_MASK
-static const struct baco_cmd_entry exit_baco_tbl[] =
-{
+static const struct baco_cmd_entry exit_baco_tbl[] = {
{ CMD_READMODIFYWRITE, mmBACO_CNTL, BACO_CNTL__BACO_RESET_EN_MASK,
BACO_CNTL__BACO_RESET_EN__SHIFT, 0, 0x01 },
{ CMD_READMODIFYWRITE, mmBACO_CNTL, BACO_CNTL__BACO_BCLK_OFF_MASK,
BACO_CNTL__BACO_BCLK_OFF__SHIFT, 0, 0x00 },
{ CMD_READMODIFYWRITE, mmBACO_CNTL, BACO_CNTL__BACO_POWER_OFF_MASK,
BACO_CNTL__BACO_POWER_OFF__SHIFT, 0, 0x00 },
@@ -138,8 +131,7 @@ static const struct baco_cmd_entry exit_baco_tbl[] =
{ CMD_WAITFOR, mmBACO_CNTL, BACO_CNTL__BACO_MODE_MASK, 0, 0x,
0x00 }
};
-static const struct baco_cmd_entry clean_baco_tbl[] =
-{
+static const struct baco_cmd_entry clean_baco_tbl[] = {
{ CMD_WRITE, mmBIOS_SCRATCH_0, 0, 0, 0, 0 },
{ CMD_WRITE, mmBIOS_SCRATCH_1, 0, 0, 0, 0 },
{ CMD_WRITE, mmBIOS_SCRATCH_2, 0, 0, 0, 0 },
--
2.17.1
[PATCH] drm/amd/pm: Clean up errors in smu10_hwmgr.c
Fix the following errors reported by checkpatch:
ERROR: spaces required around that '=' (ctx:VxW)
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Ran Sun
---
.../gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
index 86d6e88c7386..02ba68d7c654 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c
@@ -430,37 +430,37 @@ static int smu10_apply_state_adjust_rules(struct pp_hwmgr
*hwmgr,
}
/* temporary hardcoded clock voltage breakdown tables */
-static const DpmClock_t VddDcfClk[]= {
+static const DpmClock_t VddDcfClk[] = {
{ 300, 2600},
{ 600, 3200},
{ 600, 3600},
};
-static const DpmClock_t VddSocClk[]= {
+static const DpmClock_t VddSocClk[] = {
{ 478, 2600},
{ 722, 3200},
{ 722, 3600},
};
-static const DpmClock_t VddFClk[]= {
+static const DpmClock_t VddFClk[] = {
{ 400, 2600},
{1200, 3200},
{1200, 3600},
};
-static const DpmClock_t VddDispClk[]= {
+static const DpmClock_t VddDispClk[] = {
{ 435, 2600},
{ 661, 3200},
{1086, 3600},
};
-static const DpmClock_t VddDppClk[]= {
+static const DpmClock_t VddDppClk[] = {
{ 435, 2600},
{ 661, 3200},
{ 661, 3600},
};
-static const DpmClock_t VddPhyClk[]= {
+static const DpmClock_t VddPhyClk[] = {
{ 540, 2600},
{ 810, 3200},
{ 810, 3600},
@@ -1358,7 +1358,7 @@ static int smu10_set_watermarks_for_clocks_ranges(struct
pp_hwmgr *hwmgr,
struct amdgpu_device *adev = hwmgr->adev;
int i;
- smu_set_watermarks_for_clocks_ranges(table,wm_with_clock_ranges);
+ smu_set_watermarks_for_clocks_ranges(table, wm_with_clock_ranges);
if (adev->apu_flags & AMD_APU_IS_RAVEN2) {
for (i = 0; i < NUM_WM_RANGES; i++)
@@ -1461,7 +1461,7 @@ static int smu10_get_power_profile_mode(struct pp_hwmgr
*hwmgr, char *buf)
phm_get_sysfs_buf(, );
- size += sysfs_emit_at(buf, size, "%s %16s %s %s %s %s\n",title[0],
+ size += sysfs_emit_at(buf, size, "%s %16s %s %s %s %s\n", title[0],
title[1], title[2], title[3], title[4], title[5]);
for (i = 0; i <= PP_SMC_POWER_PROFILE_COMPUTE; i++)
--
2.17.1
[PATCH] drm/amd/pm/powerplay/hwmgr/ppevvmath: Clean up errors in ppevvmath.h
Fix the following errors reported by checkpatch:
ERROR: return is not a function, parentheses are not required
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required before the open parenthesis '('
ERROR: need consistent spacing around '-' (ctx:WxV)
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
index dac29fe6cfc6..6f54c410c2f9 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
@@ -166,7 +166,7 @@ static fInt fNaturalLog(fInt value)
error_term = fAdd(fNegativeOne, value);
- return (fAdd(solution, error_term));
+ return fAdd(solution, error_term);
}
static fInt fDecodeLinearFuse(uint32_t fuse_value, fInt f_min, fInt f_range,
uint32_t bitlength)
@@ -230,7 +230,7 @@ static fInt ConvertToFraction(int X) /*Add all range
checking here. Is it possib
static fInt fNegate(fInt X)
{
fInt CONSTANT_NEGONE = ConvertToFraction(-1);
- return (fMultiply(X, CONSTANT_NEGONE));
+ return fMultiply(X, CONSTANT_NEGONE);
}
static fInt Convert_ULONG_ToFraction(uint32_t X)
@@ -382,14 +382,14 @@ static int ConvertBackToInteger (fInt A) /*THIS is the
function that will be use
scaledDecimal.full = uGetScaledDecimal(A);
- fullNumber = fAdd(scaledDecimal,scaledReal);
+ fullNumber = fAdd(scaledDecimal, scaledReal);
return fullNumber.full;
}
static fInt fGetSquare(fInt A)
{
- return fMultiply(A,A);
+ return fMultiply(A, A);
}
/* x_new = x_old - (x_old^2 - C) / (2 * x_old) */
@@ -447,7 +447,7 @@ static fInt fSqrt(fInt num)
} while (uAbs(error) > 0);
- return (x_new);
+ return x_new;
}
static void SolveQuadracticEqn(fInt A, fInt B, fInt C, fInt Roots[])
@@ -459,7 +459,7 @@ static void SolveQuadracticEqn(fInt A, fInt B, fInt C, fInt
Roots[])
f_CONSTANT100 = ConvertToFraction(100);
f_CONSTANT10 = ConvertToFraction(10);
- while(GreaterThan(A, f_CONSTANT100) || GreaterThan(B, f_CONSTANT100) ||
GreaterThan(C, f_CONSTANT100)) {
+ while (GreaterThan(A, f_CONSTANT100) || GreaterThan(B, f_CONSTANT100)
|| GreaterThan(C, f_CONSTANT100)) {
A = fDivide(A, f_CONSTANT10);
B = fDivide(B, f_CONSTANT10);
C = fDivide(C, f_CONSTANT10);
@@ -515,7 +515,7 @@ static int uGetScaledDecimal (fInt A) /*Converts the
fractional portion to whole
dec[i] = tmp / (1 << SHIFT_AMOUNT);
tmp = tmp - ((1 << SHIFT_AMOUNT)*dec[i]);
tmp *= 10;
- scaledDecimal = scaledDecimal + dec[i]*uPow(10, PRECISION - 1
-i);
+ scaledDecimal = scaledDecimal + dec[i]*uPow(10, PRECISION - 1 -
i);
}
return scaledDecimal;
--
2.17.1
[RESEND PATCH] drm/qxl: prevent memory leak
The allocated memory for qdev->dumb_heads should be released in qxl_destroy_monitors_object before qxl suspend. otherwise,qxl_create_monitors_object will be called to reallocate memory for qdev->dumb_heads after qxl resume, it will cause memory leak. Signed-off-by: Zongmin Zhou --- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 6492a70e3c39..404b0483bb7c 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -1229,6 +1229,9 @@ int qxl_destroy_monitors_object(struct qxl_device *qdev) if (!qdev->monitors_config_bo) return 0; + kfree(qdev->dumb_heads); + qdev->dumb_heads = NULL; + qdev->monitors_config = NULL; qdev->ram_header->monitors_config = 0; -- 2.34.1
[PATCH] drm/amd/pm: Clean up errors in vega12_hwmgr.c
Fix the following errors reported by checkpatch:
ERROR: need consistent spacing around '/' (ctx:WxV)
ERROR: code indent should use tabs where possible
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
index 1937be1cf5b4..4bd573d815ff 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
@@ -1623,13 +1623,13 @@ static int
vega12_notify_smc_display_config_after_ps_adjustment(
if (data->smu_features[GNLD_DPM_DCEFCLK].supported) {
clock_req.clock_type = amd_pp_dcef_clock;
- clock_req.clock_freq_in_khz = min_clocks.dcefClock/10;
+ clock_req.clock_freq_in_khz = min_clocks.dcefClock / 10;
if (!vega12_display_clock_voltage_request(hwmgr, _req)) {
if (data->smu_features[GNLD_DS_DCEFCLK].supported)
PP_ASSERT_WITH_CODE(
!smum_send_msg_to_smc_with_parameter(
hwmgr, PPSMC_MSG_SetMinDeepSleepDcefclk,
- min_clocks.dcefClockInSR /100,
+ min_clocks.dcefClockInSR / 100,
NULL),
"Attempt to set divider for DCEFCLK
Failed!",
return -1);
@@ -2354,8 +2354,8 @@ static int vega12_apply_clocks_adjust_rules(struct
pp_hwmgr *hwmgr)
uint32_t i, latency;
disable_mclk_switching = ((1 < hwmgr->display_config->num_display) &&
-
!hwmgr->display_config->multi_monitor_in_sync) ||
- vblank_too_short;
+ !hwmgr->display_config->multi_monitor_in_sync)
||
+ vblank_too_short;
latency = hwmgr->display_config->dce_tolerable_mclk_in_active_latency;
/* gfxclk */
@@ -2522,7 +2522,7 @@ static int vega12_set_uclk_to_highest_dpm_level(struct
pp_hwmgr *hwmgr,
dpm_table->dpm_state.hard_min_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
PP_ASSERT_WITH_CODE(!(ret =
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinByFreq,
- (PPCLK_UCLK << 16 ) |
dpm_table->dpm_state.hard_min_level,
+ (PPCLK_UCLK << 16) |
dpm_table->dpm_state.hard_min_level,
NULL)),
"[SetUclkToHightestDpmLevel] Set hard min uclk
failed!",
return ret);
--
2.17.1
[PATCH] drm/amd/pm: Clean up errors in vega10_baco.c
Fix the following errors reported by checkpatch:
ERROR: that open brace { should be on the previous line
ERROR: space required after that ',' (ctx:VxV)
ERROR: space prohibited before that ',' (ctx:WxV)
Signed-off-by: Ran Sun
---
.../drm/amd/pm/powerplay/hwmgr/vega10_baco.c | 26 ---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_baco.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_baco.c
index 46bb16c29cf6..6836e98d37be 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_baco.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_baco.c
@@ -31,24 +31,22 @@
-static const struct soc15_baco_cmd_entry pre_baco_tbl[] =
-{
+static const struct soc15_baco_cmd_entry pre_baco_tbl[] = {
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBIF_DOORBELL_CNTL),
BIF_DOORBELL_CNTL__DOORBELL_MONITOR_EN_MASK,
BIF_DOORBELL_CNTL__DOORBELL_MONITOR_EN__SHIFT, 0, 1},
{CMD_WRITE, SOC15_REG_ENTRY(NBIF, 0, mmBIF_FB_EN), 0, 0, 0, 0},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_DSTATE_BYPASS_MASK, BACO_CNTL__BACO_DSTATE_BYPASS__SHIFT, 0, 1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_RST_INTR_MASK_MASK, BACO_CNTL__BACO_RST_INTR_MASK__SHIFT, 0, 1}
};
-static const struct soc15_baco_cmd_entry enter_baco_tbl[] =
-{
+static const struct soc15_baco_cmd_entry enter_baco_tbl[] = {
{CMD_WAITFOR, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__SOC_DOMAIN_IDLE_MASK, THM_BACO_CNTL__SOC_DOMAIN_IDLE__SHIFT,
0x, 0x8000},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_EN_MASK, BACO_CNTL__BACO_EN__SHIFT, 0, 1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_BIF_LCLK_SWITCH_MASK, BACO_CNTL__BACO_BIF_LCLK_SWITCH__SHIFT,
0, 1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_DUMMY_EN_MASK, BACO_CNTL__BACO_DUMMY_EN__SHIFT, 0, 1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_SOC_VDCI_RESET_MASK,
THM_BACO_CNTL__BACO_SOC_VDCI_RESET__SHIFT, 0, 1},
- {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_SMNCLK_MUX_MASK, THM_BACO_CNTL__BACO_SMNCLK_MUX__SHIFT,0,
1},
+ {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_SMNCLK_MUX_MASK, THM_BACO_CNTL__BACO_SMNCLK_MUX__SHIFT, 0,
1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_ISO_EN_MASK, THM_BACO_CNTL__BACO_ISO_EN__SHIFT, 0, 1},
- {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_AEB_ISO_EN_MASK, THM_BACO_CNTL__BACO_AEB_ISO_EN__SHIFT,0,
1},
+ {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_AEB_ISO_EN_MASK, THM_BACO_CNTL__BACO_AEB_ISO_EN__SHIFT, 0,
1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_ANA_ISO_EN_MASK, THM_BACO_CNTL__BACO_ANA_ISO_EN__SHIFT, 0,
1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_SOC_REFCLK_OFF_MASK,
THM_BACO_CNTL__BACO_SOC_REFCLK_OFF__SHIFT, 0, 1},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_POWER_OFF_MASK, BACO_CNTL__BACO_POWER_OFF__SHIFT, 0, 1},
@@ -58,13 +56,12 @@ static const struct soc15_baco_cmd_entry enter_baco_tbl[] =
{CMD_WAITFOR, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_MODE_MASK, BACO_CNTL__BACO_MODE__SHIFT, 0x, 0x100}
};
-static const struct soc15_baco_cmd_entry exit_baco_tbl[] =
-{
+static const struct soc15_baco_cmd_entry exit_baco_tbl[] = {
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(NBIF, 0, mmBACO_CNTL),
BACO_CNTL__BACO_POWER_OFF_MASK, BACO_CNTL__BACO_POWER_OFF__SHIFT, 0, 0},
- {CMD_DELAY_MS, 0, 0, 0, 0, 0, 0, 10,0},
- {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_SOC_REFCLK_OFF_MASK,
THM_BACO_CNTL__BACO_SOC_REFCLK_OFF__SHIFT, 0,0},
+ {CMD_DELAY_MS, 0, 0, 0, 0, 0, 0, 10, 0},
+ {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_SOC_REFCLK_OFF_MASK,
THM_BACO_CNTL__BACO_SOC_REFCLK_OFF__SHIFT, 0, 0},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_ANA_ISO_EN_MASK, THM_BACO_CNTL__BACO_ANA_ISO_EN__SHIFT, 0,
0},
- {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_AEB_ISO_EN_MASK, THM_BACO_CNTL__BACO_AEB_ISO_EN__SHIFT,0,
0},
+ {CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_AEB_ISO_EN_MASK, THM_BACO_CNTL__BACO_AEB_ISO_EN__SHIFT, 0,
0},
{CMD_READMODIFYWRITE, SOC15_REG_ENTRY(THM, 0, mmTHM_BACO_CNTL),
THM_BACO_CNTL__BACO_ISO_EN_MASK,
Re: [PATCH v7 03/13] drm/mediatek: gamma: Support SoC specific LUT size
[PATCH] drm/amd/pm: Clean up errors in vega20_hwmgr.h
Fix the following errors reported by checkpatch:
ERROR: open brace '{' following enum go on the same line
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
index 075c0094da9c..1ba9b5fe2a5d 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
@@ -385,8 +385,7 @@ struct vega20_odn_data {
struct vega20_odn_temp_tableodn_temp_table;
};
-enum OD8_FEATURE_ID
-{
+enum OD8_FEATURE_ID {
OD8_GFXCLK_LIMITS = 1 << 0,
OD8_GFXCLK_CURVE= 1 << 1,
OD8_UCLK_MAX= 1 << 2,
@@ -399,8 +398,7 @@ enum OD8_FEATURE_ID
OD8_FAN_ZERO_RPM_CONTROL= 1 << 9
};
-enum OD8_SETTING_ID
-{
+enum OD8_SETTING_ID {
OD8_SETTING_GFXCLK_FMIN = 0,
OD8_SETTING_GFXCLK_FMAX,
OD8_SETTING_GFXCLK_FREQ1,
--
2.17.1
[PATCH] drm/amd/pm: Clean up errors in amd_powerplay.c
Fix the following errors reported by checkpatch:
ERROR: that open brace { should be on the previous line
ERROR: spaces required around that '||' (ctx:WxO)
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
index ff360c699171..9e4f8a4104a3 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
@@ -612,7 +612,7 @@ static int pp_dpm_get_pp_num_states(void *handle,
memset(data, 0, sizeof(*data));
- if (!hwmgr || !hwmgr->pm_en ||!hwmgr->ps)
+ if (!hwmgr || !hwmgr->pm_en || !hwmgr->ps)
return -EINVAL;
data->nums = hwmgr->num_ps;
@@ -644,7 +644,7 @@ static int pp_dpm_get_pp_table(void *handle, char **table)
{
struct pp_hwmgr *hwmgr = handle;
- if (!hwmgr || !hwmgr->pm_en ||!hwmgr->soft_pp_table)
+ if (!hwmgr || !hwmgr->pm_en || !hwmgr->soft_pp_table)
return -EINVAL;
*table = (char *)hwmgr->soft_pp_table;
@@ -1002,7 +1002,7 @@ static int pp_get_power_limit(void *handle, uint32_t
*limit,
struct pp_hwmgr *hwmgr = handle;
int ret = 0;
- if (!hwmgr || !hwmgr->pm_en ||!limit)
+ if (!hwmgr || !hwmgr->pm_en || !limit)
return -EINVAL;
if (power_type != PP_PWR_TYPE_SUSTAINED)
@@ -1047,7 +1047,7 @@ static int pp_get_display_power_level(void *handle,
{
struct pp_hwmgr *hwmgr = handle;
- if (!hwmgr || !hwmgr->pm_en ||!output)
+ if (!hwmgr || !hwmgr->pm_en || !output)
return -EINVAL;
return phm_get_dal_power_level(hwmgr, output);
@@ -1120,7 +1120,7 @@ static int pp_get_clock_by_type_with_latency(void *handle,
{
struct pp_hwmgr *hwmgr = handle;
- if (!hwmgr || !hwmgr->pm_en ||!clocks)
+ if (!hwmgr || !hwmgr->pm_en || !clocks)
return -EINVAL;
return phm_get_clock_by_type_with_latency(hwmgr, type, clocks);
@@ -1132,7 +1132,7 @@ static int pp_get_clock_by_type_with_voltage(void *handle,
{
struct pp_hwmgr *hwmgr = handle;
- if (!hwmgr || !hwmgr->pm_en ||!clocks)
+ if (!hwmgr || !hwmgr->pm_en || !clocks)
return -EINVAL;
return phm_get_clock_by_type_with_voltage(hwmgr, type, clocks);
@@ -1155,7 +1155,7 @@ static int pp_display_clock_voltage_request(void *handle,
{
struct pp_hwmgr *hwmgr = handle;
- if (!hwmgr || !hwmgr->pm_en ||!clock)
+ if (!hwmgr || !hwmgr->pm_en || !clock)
return -EINVAL;
return phm_display_clock_voltage_request(hwmgr, clock);
@@ -1167,7 +1167,7 @@ static int pp_get_display_mode_validation_clocks(void
*handle,
struct pp_hwmgr *hwmgr = handle;
int ret = 0;
- if (!hwmgr || !hwmgr->pm_en ||!clocks)
+ if (!hwmgr || !hwmgr->pm_en || !clocks)
return -EINVAL;
clocks->level = PP_DAL_POWERLEVEL_7;
--
2.17.1
[PATCH] drm/amd/pm: Clean up errors in amdgpu_smu.c
Fix the following errors reported by checkpatch:
ERROR: spaces required around that '=' (ctx:WxV)
ERROR: spaces required around that '&&' (ctx:VxW)
ERROR: that open brace { should be on the previous line
ERROR: space required before the open parenthesis '('
ERROR: space required before the open brace '{'
ERROR: spaces required around that ':' (ctx:VxW)
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index ce41a8309582..a7199275ffb8 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -618,7 +618,7 @@ static int smu_set_funcs(struct amdgpu_device *adev)
adev->pm.pp_feature &= ~PP_GFXOFF_MASK;
arcturus_set_ppt_funcs(smu);
/* OD is not supported on Arcturus */
- smu->od_enabled =false;
+ smu->od_enabled = false;
break;
case IP_VERSION(13, 0, 2):
aldebaran_set_ppt_funcs(smu);
@@ -1648,7 +1648,7 @@ static int smu_hw_fini(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
struct smu_context *smu = adev->powerplay.pp_handle;
- if (amdgpu_sriov_vf(adev)&& !amdgpu_sriov_is_pp_one_vf(adev))
+ if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
return 0;
smu_dpm_set_vcn_enable(smu, false);
@@ -1700,7 +1700,7 @@ static int smu_suspend(void *handle)
int ret;
uint64_t count;
- if (amdgpu_sriov_vf(adev)&& !amdgpu_sriov_is_pp_one_vf(adev))
+ if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
return 0;
if (!smu->pm_enabled)
@@ -2217,8 +2217,7 @@ const struct amd_ip_funcs smu_ip_funcs = {
.set_powergating_state = smu_set_powergating_state,
};
-const struct amdgpu_ip_block_version smu_v11_0_ip_block =
-{
+const struct amdgpu_ip_block_version smu_v11_0_ip_block = {
.type = AMD_IP_BLOCK_TYPE_SMC,
.major = 11,
.minor = 0,
@@ -2226,8 +2225,7 @@ const struct amdgpu_ip_block_version smu_v11_0_ip_block =
.funcs = _ip_funcs,
};
-const struct amdgpu_ip_block_version smu_v12_0_ip_block =
-{
+const struct amdgpu_ip_block_version smu_v12_0_ip_block = {
.type = AMD_IP_BLOCK_TYPE_SMC,
.major = 12,
.minor = 0,
@@ -2235,8 +2233,7 @@ const struct amdgpu_ip_block_version smu_v12_0_ip_block =
.funcs = _ip_funcs,
};
-const struct amdgpu_ip_block_version smu_v13_0_ip_block =
-{
+const struct amdgpu_ip_block_version smu_v13_0_ip_block = {
.type = AMD_IP_BLOCK_TYPE_SMC,
.major = 13,
.minor = 0,
@@ -2337,7 +2334,7 @@ int smu_get_power_limit(void *handle,
if (!smu->pm_enabled || !smu->adev->pm.dpm_enabled)
return -EOPNOTSUPP;
- switch(pp_power_type) {
+ switch (pp_power_type) {
case PP_PWR_TYPE_SUSTAINED:
limit_type = SMU_DEFAULT_PPT_LIMIT;
break;
@@ -2349,7 +2346,7 @@ int smu_get_power_limit(void *handle,
break;
}
- switch(pp_limit_level){
+ switch (pp_limit_level) {
case PP_PWR_LIMIT_CURRENT:
limit_level = SMU_PPT_LIMIT_CURRENT;
break;
@@ -2595,7 +2592,7 @@ static int smu_read_sensor(void *handle,
*size = 4;
break;
case AMDGPU_PP_SENSOR_VCN_POWER_STATE:
- *(uint32_t *)data =
atomic_read(>smu_power.power_gate.vcn_gated) ? 0: 1;
+ *(uint32_t *)data =
atomic_read(>smu_power.power_gate.vcn_gated) ? 0 : 1;
*size = 4;
break;
case AMDGPU_PP_SENSOR_MIN_FAN_RPM:
@@ -2868,7 +2865,7 @@ static int smu_set_xgmi_pstate(void *handle,
if (smu->ppt_funcs->set_xgmi_pstate)
ret = smu->ppt_funcs->set_xgmi_pstate(smu, pstate);
- if(ret)
+ if (ret)
dev_err(smu->adev->dev, "Failed to set XGMI pstate!\n");
return ret;
--
2.17.1
[PATCH] drm/amd: Clean up errors in smu_v13_0_5_ppt.c
Fix the following errors reported by checkpatch: ERROR: space prohibited before that ',' (ctx:WxW) Signed-off-by: Ran Sun --- drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h b/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h index ceb13c838067..bcc42abfc768 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h +++ b/drivers/gpu/drm/amd/pm/swsmu/smu_internal.h @@ -61,14 +61,14 @@ #define smu_feature_get_enabled_mask(smu, mask) smu_ppt_funcs(get_enabled_mask, -EOPNOTSUPP, smu, mask) #define smu_feature_is_enabled(smu, mask) smu_ppt_funcs(feature_is_enabled, 0, smu, mask) #define smu_disable_all_features_with_exception(smu, mask) smu_ppt_funcs(disable_all_features_with_exception, 0, smu, mask) -#define smu_is_dpm_running(smu) smu_ppt_funcs(is_dpm_running, 0 , smu) +#define smu_is_dpm_running(smu) smu_ppt_funcs(is_dpm_running, 0, smu) #define smu_notify_display_change(smu) smu_ppt_funcs(notify_display_change, 0, smu) #define smu_populate_umd_state_clk(smu) smu_ppt_funcs(populate_umd_state_clk, 0, smu) #define smu_enable_thermal_alert(smu) smu_ppt_funcs(enable_thermal_alert, 0, smu) #define smu_disable_thermal_alert(smu) smu_ppt_funcs(disable_thermal_alert, 0, smu) #define smu_smc_read_sensor(smu, sensor, data, size) smu_ppt_funcs(read_sensor, -EINVAL, smu, sensor, data, size) #define smu_pre_display_config_changed(smu) smu_ppt_funcs(pre_display_config_changed, 0, smu) -#define smu_display_config_changed(smu) smu_ppt_funcs(display_config_changed, 0 , smu) +#define smu_display_config_changed(smu) smu_ppt_funcs(display_config_changed, 0, smu) #define smu_apply_clocks_adjust_rules(smu) smu_ppt_funcs(apply_clocks_adjust_rules, 0, smu) #define smu_notify_smc_display_config(smu) smu_ppt_funcs(notify_smc_display_config, 0, smu) #define smu_run_btc(smu) smu_ppt_funcs(run_btc, 0, smu) -- 2.17.1
[PATCH] drm/amd/pm: Clean up errors in smu_v13_0_5_ppt.c
Fix the following errors reported by checkpatch: ERROR: space prohibited before that ',' (ctx:WxW) Signed-off-by: Ran Sun --- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c index 42f110602eb1..87a79e6f983b 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c @@ -75,7 +75,7 @@ static struct cmn2asic_msg_mapping smu_v13_0_5_message_map[SMU_MSG_MAX_COUNT] = MSG_MAP(SetDriverDramAddrHigh, PPSMC_MSG_SetDriverDramAddrHigh, 1), MSG_MAP(SetDriverDramAddrLow, PPSMC_MSG_SetDriverDramAddrLow, 1), MSG_MAP(TransferTableSmu2Dram, PPSMC_MSG_TransferTableSmu2Dram, 1), - MSG_MAP(TransferTableDram2Smu, PPSMC_MSG_TransferTableDram2Smu , 1), + MSG_MAP(TransferTableDram2Smu, PPSMC_MSG_TransferTableDram2Smu,1), MSG_MAP(GetGfxclkFrequency, PPSMC_MSG_GetGfxclkFrequency, 1), MSG_MAP(GetEnabledSmuFeatures, PPSMC_MSG_GetEnabledSmuFeatures, 1), MSG_MAP(SetSoftMaxVcn, PPSMC_MSG_SetSoftMaxVcn,1), -- 2.17.1
[PATCH] drm/amd/pm: Clean up errors in smu_v13_0_6_ppt.c
Fix the following errors reported by checkpatch:
ERROR: code indent should use tabs where possible
ERROR: that open brace { should be on the previous line
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index 1ac552142763..43afa1ee1b4a 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -1248,9 +1248,9 @@ static int smu_v13_0_6_get_power_limit(struct smu_context
*smu,
uint32_t *default_power_limit,
uint32_t *max_power_limit)
{
-struct smu_table_context *smu_table = >smu_table;
-struct PPTable_t *pptable =
-(struct PPTable_t *)smu_table->driver_pptable;
+ struct smu_table_context *smu_table = >smu_table;
+ struct PPTable_t *pptable =
+ (struct PPTable_t *)smu_table->driver_pptable;
uint32_t power_limit = 0;
int ret;
@@ -1366,8 +1366,7 @@ static int smu_v13_0_6_set_irq_state(struct amdgpu_device
*adev,
return 0;
}
-static const struct amdgpu_irq_src_funcs smu_v13_0_6_irq_funcs =
-{
+static const struct amdgpu_irq_src_funcs smu_v13_0_6_irq_funcs = {
.set = smu_v13_0_6_set_irq_state,
.process = smu_v13_0_6_irq_process,
};
--
2.17.1
[PATCH] drm/amd/pm: Clean up errors in aldebaran_ppt.c
Fix the following errors reported by checkpatch:
ERROR: that open brace { should be on the previous line
ERROR: space required after that ',' (ctx:VxV)
ERROR: spaces required around that '=' (ctx:VxW)
ERROR: else should follow close brace '}'
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index ce50ef46e73f..8f26123ac703 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -94,8 +94,7 @@
*/
#define SUPPORT_BAD_CHANNEL_INFO_MSG_VERSION 0x00443300
-static const struct smu_temperature_range smu13_thermal_policy[] =
-{
+static const struct smu_temperature_range smu13_thermal_policy[] = {
{-273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000},
{ 12, 12, 12, 12, 12, 12, 12, 12,
12},
};
@@ -196,7 +195,7 @@ static const struct cmn2asic_mapping
aldebaran_feature_mask_map[SMU_FEATURE_COUN
ALDEBARAN_FEA_MAP(SMU_FEATURE_FW_CTF_BIT,
FEATURE_FW_CTF_BIT),
ALDEBARAN_FEA_MAP(SMU_FEATURE_THERMAL_BIT,
FEATURE_THERMAL_BIT),
ALDEBARAN_FEA_MAP(SMU_FEATURE_OUT_OF_BAND_MONITOR_BIT,
FEATURE_OUT_OF_BAND_MONITOR_BIT),
-
ALDEBARAN_FEA_MAP(SMU_FEATURE_XGMI_PER_LINK_PWR_DWN_BIT,FEATURE_XGMI_PER_LINK_PWR_DWN),
+ ALDEBARAN_FEA_MAP(SMU_FEATURE_XGMI_PER_LINK_PWR_DWN_BIT,
FEATURE_XGMI_PER_LINK_PWR_DWN),
ALDEBARAN_FEA_MAP(SMU_FEATURE_DF_CSTATE_BIT,
FEATURE_DF_CSTATE),
};
@@ -580,7 +579,7 @@ static int aldebaran_get_smu_metrics_data(struct
smu_context *smu,
MetricsMember_t member,
uint32_t *value)
{
- struct smu_table_context *smu_table= >smu_table;
+ struct smu_table_context *smu_table = >smu_table;
SmuMetrics_t *metrics = (SmuMetrics_t *)smu_table->metrics_table;
int ret = 0;
@@ -1906,8 +1905,7 @@ static int aldebaran_mode1_reset(struct smu_context *smu)
smu_cmn_get_smc_version(smu, NULL, _version);
if (smu_version < 0x00440700) {
ret = smu_cmn_send_smc_msg(smu, SMU_MSG_Mode1Reset, NULL);
- }
- else {
+ } else {
/* fatal error triggered by ras, PMFW supports the flag
from 68.44.0 */
if ((smu_version >= 0x00442c00) && ras &&
@@ -2116,7 +2114,7 @@ static const struct pptable_funcs aldebaran_ppt_funcs = {
.register_irq_handler = smu_v13_0_register_irq_handler,
.set_azalia_d3_pme = smu_v13_0_set_azalia_d3_pme,
.get_max_sustainable_clocks_by_dc =
smu_v13_0_get_max_sustainable_clocks_by_dc,
- .baco_is_support= aldebaran_is_baco_supported,
+ .baco_is_support = aldebaran_is_baco_supported,
.get_dpm_ultimate_freq = smu_v13_0_get_dpm_ultimate_freq,
.set_soft_freq_limited_range = aldebaran_set_soft_freq_limited_range,
.od_edit_dpm_table = aldebaran_usr_edit_dpm_table,
--
2.17.1
[PATCH] drm/amd/pm: Clean up errors in smu_v13_0.c
Fix the following errors reported by checkpatch:
ERROR: space required before the open parenthesis '('
ERROR: that open brace { should be on the previous line
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index 9b62b45ebb7f..895cda8e6934 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -1121,7 +1121,7 @@ smu_v13_0_display_clock_voltage_request(struct
smu_context *smu,
ret = smu_v13_0_set_hard_freq_limited_range(smu, clk_select,
clk_freq, 0);
- if(clk_select == SMU_UCLK)
+ if (clk_select == SMU_UCLK)
smu->hard_min_uclk_req_from_dal = clk_freq;
}
@@ -1437,8 +1437,7 @@ static int smu_v13_0_irq_process(struct amdgpu_device
*adev,
return 0;
}
-static const struct amdgpu_irq_src_funcs smu_v13_0_irq_funcs =
-{
+static const struct amdgpu_irq_src_funcs smu_v13_0_irq_funcs = {
.set = smu_v13_0_set_irq_state,
.process = smu_v13_0_irq_process,
};
@@ -1933,7 +1932,7 @@ static int smu_v13_0_get_dpm_level_count(struct
smu_context *smu,
ret = smu_v13_0_get_dpm_freq_by_index(smu, clk_type, 0xff, value);
/* SMU v13.0.2 FW returns 0 based max level, increment by one for it */
- if((smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 2)) &&
(!ret && value))
+ if ((smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 2)) &&
(!ret && value))
++(*value);
return ret;
--
2.17.1
Re: [PATCH -next] drm/amdgpu: Remove a lot of unnecessary ternary operators
On 2023/8/1 0:14, Limonciello, Mario wrote:
>
>
> On 7/31/2023 8:26 AM, Ruan Jinjie wrote:
>> Ther are many ternary operators, the true or false judgement
>> of which is unnecessary in C language semantics.
> s/Ther/There/
>
> Unnecessary; sure. But don't they improve the readability quite a bit?
The benevolent people have different opinions, it's redundant in my
opinion. And there are many same operation such as “state ==
AMD_CG_STATE_GATE", which can be encapsulated into a helper.
>
>>
>> Signed-off-by: Ruan Jinjie
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 2 +-
>> .../drm/amd/display/dc/dce/dce_link_encoder.c | 4 +---
>> .../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 6 +++---
>> .../amd/pm/powerplay/hwmgr/smu7_powertune.c | 2 +-
>> .../drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 18 +++---
>> .../amd/pm/powerplay/smumgr/polaris10_smumgr.c | 2 +-
>> .../drm/amd/pm/powerplay/smumgr/vegam_smumgr.c | 7 +++
>> 13 files changed, 23 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
>> index b582b83c4984..38ccec913f00 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
>> @@ -460,7 +460,7 @@ bool amdgpu_get_bios(struct amdgpu_device *adev)
>> return false;
>> success:
>> - adev->is_atom_fw = (adev->asic_type >= CHIP_VEGA10) ? true : false;
>> + adev->is_atom_fw = adev->asic_type >= CHIP_VEGA10;
>> return true;
>> }
>> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
>> index 79791379fc2b..df4440c21bbf 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
>> @@ -479,7 +479,7 @@ static int jpeg_v3_0_set_clockgating_state(void
>> *handle,
>> enum amd_clockgating_state state)
>> {
>> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>> - bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
>> + bool enable = state == AMD_CG_STATE_GATE;
>> if (enable) {
>> if (!jpeg_v3_0_is_idle(handle))
>> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
>> b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
>> index a707d407fbd0..3eb3dcd56b57 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
>> @@ -626,7 +626,7 @@ static int jpeg_v4_0_set_clockgating_state(void
>> *handle,
>> enum amd_clockgating_state state)
>> {
>> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>> - bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
>> + bool enable = state == AMD_CG_STATE_GATE;
>> if (enable) {
>> if (!jpeg_v4_0_is_idle(handle))
>> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
>> b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
>> index ce2b22f7e4e4..153731d6ce8b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
>> @@ -785,7 +785,7 @@ static int jpeg_v4_0_3_set_clockgating_state(void
>> *handle,
>> enum amd_clockgating_state state)
>> {
>> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>> - bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
>> + bool enable = state == AMD_CG_STATE_GATE;
>> int i;
>> for (i = 0; i < adev->jpeg.num_jpeg_inst; ++i) {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index b76ba21b5a89..9b662b105cc1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -2095,7 +2095,7 @@ static int vcn_v3_0_set_clockgating_state(void
>> *handle,
>> enum amd_clockgating_state state)
>> {
>> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>> - bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
>> + bool enable = state == AMD_CG_STATE_GATE;
>> int i;
>> for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
>> index 6089c7deba8a..7c486745bece 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
>> @@ -1918,7 +1918,7 @@ static int vcn_v4_0_wait_for_idle(void *handle)
>> static int vcn_v4_0_set_clockgating_state(void *handle, enum
>> amd_clockgating_state state)
>> {
>> struct amdgpu_device *adev = (struct
[PATCH] drm/amd/pm: Clean up errors in smu_v13_0_7_ppt.c
Fix the following errors reported by checkpatch:
ERROR: open brace '{' following struct go on the same line
ERROR: spaces required around that '=' (ctx:VxW)
ERROR: that open brace { should be on the previous line
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index b1f0937ccade..26ba51ec0567 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -386,8 +386,7 @@ static int smu_v13_0_7_check_fw_status(struct smu_context
*smu)
}
#ifndef atom_smc_dpm_info_table_13_0_7
-struct atom_smc_dpm_info_table_13_0_7
-{
+struct atom_smc_dpm_info_table_13_0_7 {
struct atom_common_table_header table_header;
BoardTable_t BoardTable;
};
@@ -494,7 +493,7 @@ static int smu_v13_0_7_tables_init(struct smu_context *smu)
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_ACTIVITY_MONITOR_COEFF,
sizeof(DpmActivityMonitorCoeffIntExternal_t), PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM);
+ AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_COMBO_PPTABLE,
MP0_MP1_DATA_REGION_SIZE_COMBOPPTABLE,
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
@@ -728,7 +727,7 @@ static int smu_v13_0_7_get_smu_metrics_data(struct
smu_context *smu,
MetricsMember_t member,
uint32_t *value)
{
- struct smu_table_context *smu_table= >smu_table;
+ struct smu_table_context *smu_table = >smu_table;
SmuMetrics_t *metrics =
&(((SmuMetricsExternal_t
*)(smu_table->metrics_table))->SmuMetrics);
int ret = 0;
@@ -1635,8 +1634,7 @@ static int smu_v13_0_7_force_clk_levels(struct
smu_context *smu,
return ret;
}
-static const struct smu_temperature_range smu13_thermal_policy[] =
-{
+static const struct smu_temperature_range smu13_thermal_policy[] = {
{-273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000},
{ 12, 12, 12, 12, 12, 12, 12, 12,
12},
};
--
2.17.1
Re: [PATCH -next] drm/amdgpu: Remove a lot of unnecessary ternary operators
On 2023/8/1 0:22, Tom Rix wrote: > > On 7/31/23 6:26 AM, Ruan Jinjie wrote: >> Ther are many ternary operators, the true or false judgement >> of which is unnecessary in C language semantics. >> >> Signed-off-by: Ruan Jinjie >> --- > > snip >> data->registry_data.avfs_support = >> -hwmgr->feature_mask & PP_AVFS_MASK ? true : false; >> +hwmgr->feature_mask & PP_AVFS_MASK; >> data->registry_data.led_dpm_enabled = 1; > > These are not equivalent, consider 0x & 0x1000 != 1 Sorry! these are actually not equivalent，I'll fix it in v2. But the many others could be more simplified. > > Tom > >
[PATCH] drm/amd/pm: Clean up errors in smu_v11_0.h
Fix the following errors reported by checkpatch:
ERROR: that open brace { should be on the previous line
ERROR: code indent should use tabs where possible
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h | 7 +++---
scripts/checkpatch.pl| 23
2 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h
index d466db6f0ad4..1b4e0e4716ea 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h
@@ -67,8 +67,7 @@ static const __maybe_unused uint16_t link_width[] = {0, 1, 2,
4, 8, 12, 16};
static const __maybe_unused uint16_t link_speed[] = {25, 50, 80, 160};
static const
-struct smu_temperature_range __maybe_unused smu11_thermal_policy[] =
-{
+struct smu_temperature_range __maybe_unused smu11_thermal_policy[] = {
{-273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000},
{ 12, 12, 12, 12, 12, 12, 12, 12,
12},
};
@@ -96,8 +95,8 @@ struct smu_11_0_dpm_table {
};
struct smu_11_0_pcie_table {
-uint8_t pcie_gen[MAX_PCIE_CONF];
-uint8_t pcie_lane[MAX_PCIE_CONF];
+ uint8_t pcie_gen[MAX_PCIE_CONF];
+ uint8_t pcie_lane[MAX_PCIE_CONF];
};
struct smu_11_0_dpm_tables {
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 85a0598bf723..528f619520eb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7449,23 +7449,6 @@ sub process {
}
# Complain about RCU Tasks Trace used outside of BPF (and of course, RCU).
-<<< HEAD
-<<< HEAD
- if ($line =~ /\brcu_read_lock_trace\s*\(/ ||
- $line =~ /\brcu_read_lock_trace_held\s*\(/ ||
- $line =~ /\brcu_read_unlock_trace\s*\(/ ||
- $line =~ /\bcall_rcu_tasks_trace\s*\(/ ||
- $line =~ /\bsynchronize_rcu_tasks_trace\s*\(/ ||
- $line =~ /\brcu_barrier_tasks_trace\s*\(/ ||
- $line =~ /\brcu_request_urgent_qs_task\s*\(/) {
- if ($realfile !~ m@^kernel/bpf@ &&
- $realfile !~ m@^include/linux/bpf@ &&
- $realfile !~ m@^net/bpf@ &&
- $realfile !~ m@^kernel/rcu@ &&
- $realfile !~ m@^include/linux/rcu@) {
-===
-===
->>> d7b3af5a77e8d8da28f435f313e069aea5bcf172
our $rcu_trace_funcs = qr{(?x:
rcu_read_lock_trace |
rcu_read_lock_trace_held |
@@ -7482,14 +7465,8 @@ sub process {
kernel/rcu/ |
include/linux/rcu
)};
-<<< HEAD
- if ($line =~ /\b$rcu_trace_funcs\s*\(/) {
- if ($realfile !~ m@^$rcu_trace_paths@) {
->>> 4d2c646ac07cf4a35ef1c4a935a1a4fd6c6b1a36
-===
if ($line =~ /\b($rcu_trace_funcs)\s*\(/) {
if ($realfile !~ m{^$rcu_trace_paths}) {
->>> d7b3af5a77e8d8da28f435f313e069aea5bcf172
WARN("RCU_TASKS_TRACE",
"use of RCU tasks trace is incorrect
outside BPF or core RCU code\n" . $herecurr);
}
--
2.17.1
Re: [PATCH RFC v5 09/10] drm/msm/dpu: Use DRM solid_fill property
On 01/08/2023 03:39, Jessica Zhang wrote:
On 7/30/2023 9:15 PM, Dmitry Baryshkov wrote:
On 28/07/2023 20:02, Jessica Zhang wrote:
Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
allow userspace to configure the alpha value for the solid fill color.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 24
++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 114c803ff99b..95fc0394d13e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -42,7 +42,6 @@
#define SHARP_SMOOTH_THR_DEFAULT 8
#define SHARP_NOISE_THR_DEFAULT 2
-#define DPU_PLANE_COLOR_FILL_FLAG BIT(31)
#define DPU_ZPOS_MAX 255
/*
@@ -82,7 +81,6 @@ struct dpu_plane {
enum dpu_sspp pipe;
- uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
const struct dpu_mdss_cfg *catalog;
@@ -606,6 +604,20 @@ static void _dpu_plane_color_fill_pipe(struct
dpu_plane_state *pstate,
_dpu_plane_setup_scaler(pipe, fmt, true, _cfg,
pstate->rotation);
}
+static uint32_t _dpu_plane_get_bgr_fill_color(struct drm_solid_fill
solid_fill)
As I commented for v4 (please excuse me for not responding to your
email at thattime), we can return abgr here, taking
plane->state->alpha into account.
Hi Dmitry,
Since it seems that this comment wasn't resolved, I can drop your R-B
tag in the next revision.
It's a minor issue, so no need to drop the tag.
From my previous response, I pointed out that the color parameter
expects an RGB value [1].
So is the intention here to refactor _dpu_plane_color_fill() to accept
an ABGR color?
That's what I'm suggesting.
Thanks,
Jessica Zhang
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c#L676
+{
+ uint32_t ret = 0;
+ uint8_t b = solid_fill.b >> 24;
+ uint8_t g = solid_fill.g >> 24;
+ uint8_t r = solid_fill.r >> 24;
+
+ ret |= b << 16;
+ ret |= g << 8;
+ ret |= r;
+
+ return ret;
+}
+
/**
* _dpu_plane_color_fill - enables color fill on plane
* @pdpu: Pointer to DPU plane object
@@ -977,9 +989,9 @@ void dpu_plane_flush(struct drm_plane *plane)
if (pdpu->is_error)
/* force white frame with 100% alpha pipe output on error */
_dpu_plane_color_fill(pdpu, 0xFF, 0xFF);
- else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
- /* force 100% alpha */
- _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
+ else if (drm_plane_solid_fill_enabled(plane->state))
+ _dpu_plane_color_fill(pdpu,
_dpu_plane_get_bgr_fill_color(plane->state->solid_fill),
+ plane->state->alpha);
else {
dpu_plane_flush_csc(pdpu, >pipe);
dpu_plane_flush_csc(pdpu, >r_pipe);
@@ -1024,7 +1036,7 @@ static void dpu_plane_sspp_update_pipe(struct
drm_plane *plane,
}
/* override for color fill */
- if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG) {
+ if (drm_plane_solid_fill_enabled(plane->state)) {
_dpu_plane_set_qos_ctrl(plane, pipe, false);
/* skip remaining processing on color fill */
--
With best wishes
Dmitry
--
With best wishes
Dmitry
linux-next: manual merge of the fbdev tree with the drm tree
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
drivers/video/fbdev/mx3fb.c
between commit:
8a4675ebbd30 ("fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed
structs")
from the drm tree and commit:
87ac8777d424 ("fbdev: mx3fb: Remove the driver")
from the fbdev tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgps_oMXlXcfo.pgp
Description: OpenPGP digital signature
Re: [PATCH RFC v5 09/10] drm/msm/dpu: Use DRM solid_fill property
On 7/30/2023 9:15 PM, Dmitry Baryshkov wrote:
On 28/07/2023 20:02, Jessica Zhang wrote:
Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
allow userspace to configure the alpha value for the solid fill color.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 114c803ff99b..95fc0394d13e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -42,7 +42,6 @@
#define SHARP_SMOOTH_THR_DEFAULT 8
#define SHARP_NOISE_THR_DEFAULT 2
-#define DPU_PLANE_COLOR_FILL_FLAG BIT(31)
#define DPU_ZPOS_MAX 255
/*
@@ -82,7 +81,6 @@ struct dpu_plane {
enum dpu_sspp pipe;
- uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
const struct dpu_mdss_cfg *catalog;
@@ -606,6 +604,20 @@ static void _dpu_plane_color_fill_pipe(struct
dpu_plane_state *pstate,
_dpu_plane_setup_scaler(pipe, fmt, true, _cfg,
pstate->rotation);
}
+static uint32_t _dpu_plane_get_bgr_fill_color(struct drm_solid_fill
solid_fill)
As I commented for v4 (please excuse me for not responding to your email
at thattime), we can return abgr here, taking plane->state->alpha into
account.
Hi Dmitry,
Since it seems that this comment wasn't resolved, I can drop your R-B
tag in the next revision.
From my previous response, I pointed out that the color parameter
expects an RGB value [1].
So is the intention here to refactor _dpu_plane_color_fill() to accept
an ABGR color?
Thanks,
Jessica Zhang
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c#L676
+{
+ uint32_t ret = 0;
+ uint8_t b = solid_fill.b >> 24;
+ uint8_t g = solid_fill.g >> 24;
+ uint8_t r = solid_fill.r >> 24;
+
+ ret |= b << 16;
+ ret |= g << 8;
+ ret |= r;
+
+ return ret;
+}
+
/**
* _dpu_plane_color_fill - enables color fill on plane
* @pdpu: Pointer to DPU plane object
@@ -977,9 +989,9 @@ void dpu_plane_flush(struct drm_plane *plane)
if (pdpu->is_error)
/* force white frame with 100% alpha pipe output on error */
_dpu_plane_color_fill(pdpu, 0xFF, 0xFF);
- else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
- /* force 100% alpha */
- _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
+ else if (drm_plane_solid_fill_enabled(plane->state))
+ _dpu_plane_color_fill(pdpu,
_dpu_plane_get_bgr_fill_color(plane->state->solid_fill),
+ plane->state->alpha);
else {
dpu_plane_flush_csc(pdpu, >pipe);
dpu_plane_flush_csc(pdpu, >r_pipe);
@@ -1024,7 +1036,7 @@ static void dpu_plane_sspp_update_pipe(struct
drm_plane *plane,
}
/* override for color fill */
- if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG) {
+ if (drm_plane_solid_fill_enabled(plane->state)) {
_dpu_plane_set_qos_ctrl(plane, pipe, false);
/* skip remaining processing on color fill */
--
With best wishes
Dmitry
[PATCH v3] drm/panfrost: Sync IRQ by job's timeout handler
Panfrost IRQ handler may stuck for a long time, for example this happens
when there is a bad HDMI connection and HDMI handler takes a long time to
finish processing, holding Panfrost. Make Panfrost's job timeout handler
to sync IRQ before checking fence signal status in order to prevent
spurious job timeouts due to a slow IRQ processing.
Reviewed-by: Steven Price
Reviewed-by: AngeloGioacchino Del Regno
Tested-by: AngeloGioacchino Del Regno
# MediaTek MT8192 and MT8195 Chromebooks:
Signed-off-by: Dmitry Osipenko
---
Changelog:
v3: - Added comment to the code as was suggested by Boris
- Added r-b/t-b from Steven and Angelo
v2: - Moved synchronize_irq() after first signal-check to avoid unnecessary
blocking on syncing.
- Added warn message about high interrupt latency.
drivers/gpu/drm/panfrost/panfrost_job.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index dbc597ab46fb..ea1149354f9d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -720,6 +720,21 @@ static enum drm_gpu_sched_stat
panfrost_job_timedout(struct drm_sched_job
if (dma_fence_is_signaled(job->done_fence))
return DRM_GPU_SCHED_STAT_NOMINAL;
+ /*
+* Panfrost IRQ handler may take long time to process if there is
+* another IRQ handler hogging the processing. For example, HDMI
+* may stuck in IRQ handler for a significant time in a case of bad
+* cable connection. In order to catch such cases and not report
+* spurious Panfrost job timeouts, synchronize the IRQ handler and
+* re-check the fence status.
+*/
+ synchronize_irq(pfdev->js->irq);
+
+ if (dma_fence_is_signaled(job->done_fence)) {
+ dev_warn(pfdev->dev, "unexpectedly high interrupt latency\n");
+ return DRM_GPU_SCHED_STAT_NOMINAL;
+ }
+
dev_err(pfdev->dev, "gpu sched timeout, js=%d, config=0x%x,
status=0x%x, head=0x%x, tail=0x%x, sched_job=%p",
js,
job_read(pfdev, JS_CONFIG(js)),
--
2.41.0
Re: [PATCH] fbdev/ps3fb: Build without kernel device
On 7/31/23 10:55, Thomas Zimmermann wrote:
> Use fb_info() to print status message at the end of the probe function,
> which avoids decoding the devices. fb_info() works with or without an
> fbdev kernel device. Fixes the following error:
>
> ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
> ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member
> named 'dev'
> 1172 | dev_driver_string(info->dev), dev_name(info->dev),
> |^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro
> 'dev_printk_index_wrap'
> 110 | _p_func(dev, fmt, ##__VA_ARGS__);
> \
> | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
> 1171 | dev_info(info->device, "%s %s, using %u KiB of video
> memory\n",
> | ^~~~
> ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member
> named 'dev'
> 1172 | dev_driver_string(info->dev), dev_name(info->dev),
> | ^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro
> 'dev_printk_index_wrap'
> 110 | _p_func(dev, fmt, ##__VA_ARGS__);
> \
> | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
> 1171 | dev_info(info->device, "%s %s, using %u KiB of video
> memory\n",
> | ^~~~
>
> Reported-by: Randy Dunlap
> Closes:
> https://lore.kernel.org/lkml/ccc63065-2976-88ef-1211-731330bf2...@infradead.org/
> Signed-off-by: Thomas Zimmermann
> Fixes: 701d2054fa31 ("fbdev: Make support for userspace interfaces
> configurable")
> Cc: Michael Ellerman
> Cc: Sam Ravnborg
> Cc: Helge Deller
> Cc: Javier Martinez Canillas
> Cc: Randy Dunlap
> Cc: Bagas Sanjaya
> Cc: Thorsten Leemhuis
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
Acked-by: Randy Dunlap
Tested-by: Randy Dunlap # build-tested
Thanks.
> ---
> drivers/video/fbdev/ps3fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
> index 5aedc30c5f7e..64d291d6b153 100644
> --- a/drivers/video/fbdev/ps3fb.c
> +++ b/drivers/video/fbdev/ps3fb.c
> @@ -1168,9 +1168,7 @@ static int ps3fb_probe(struct ps3_system_bus_device
> *dev)
>
> ps3_system_bus_set_drvdata(dev, info);
>
> - dev_info(info->device, "%s %s, using %u KiB of video memory\n",
> - dev_driver_string(info->dev), dev_name(info->dev),
> - info->fix.smem_len >> 10);
> + fb_info(info, "using %u KiB of video memory\n", info->fix.smem_len >>
> 10);
>
> task = kthread_run(ps3fbd, info, DEVICE_NAME);
> if (IS_ERR(task)) {
--
~Randy
Re: [PATCH -next] drm/i2c: tda998x: remove redundant of_match_ptr
Hi Zhu,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20230731]
url:
https://github.com/intel-lab-lkp/linux/commits/Zhu-Wang/drm-i2c-tda998x-remove-redundant-of_match_ptr/20230731-210417
base: next-20230731
patch link:
https://lore.kernel.org/r/20230731130257.94751-1-wangzhu9%40huawei.com
patch subject: [PATCH -next] drm/i2c: tda998x: remove redundant of_match_ptr
config: i386-buildonly-randconfig-r004-20230731
(https://download.01.org/0day-ci/archive/20230801/202308010739.e8cimoss-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230801/202308010739.e8cimoss-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202308010739.e8cimoss-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i2c/tda998x_drv.c:2106:35: error: 'tda998x_dt_ids'
>> undeclared here (not in a function); did you mean 'tda998x_ids'?
2106 | .of_match_table = tda998x_dt_ids,
| ^~
| tda998x_ids
vim +2106 drivers/gpu/drm/i2c/tda998x_drv.c
2100
2101 static struct i2c_driver tda998x_driver = {
2102 .probe = tda998x_probe,
2103 .remove = tda998x_remove,
2104 .driver = {
2105 .name = "tda998x",
> 2106 .of_match_table = tda998x_dt_ids,
2107 },
2108 .id_table = tda998x_ids,
2109 };
2110
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH v6 3/3] drm/virtio: Support sync objects
On 4/16/23 14:52, Dmitry Osipenko wrote: > Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects > support is needed by native context VirtIO-GPU Mesa drivers, it also will > be used by Venus and Virgl contexts. > > Reviewed-by; Emil Velikov > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/drm/virtio/virtgpu_drv.c| 3 +- > drivers/gpu/drm/virtio/virtgpu_submit.c | 219 > include/uapi/drm/virtgpu_drm.h | 16 +- > 3 files changed, 236 insertions(+), 2 deletions(-) Applied to misc-next Made a minor comment change that was requested by Geert Uytterhoeven and took into account that outfence now could be NULL after the recent virtio-gpu changes -- Best regards, Dmitry
Re: [PATCH v3 00/19] Sitronix ST7789V improvements
Hi, Each patch in the series has at least one Reviewed-by tag and the DT binding changes have an Acked-by from at least one of the DT binding maintainers. It has been pending on the mailing list for two weeks now, so can it be applied? P.S.: Looks like I missed Neil in the original recipients list. Sorry about that. If you are not subscribed to dri-devel and need the full thread it's available here: https://lore.kernel.org/all/20230714013756.1546769-1-...@kernel.org/ Greetings, -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] drm/panel: simple: Initialize unprepared_time in probe
On 7/31/23 23:34, Doug Anderson wrote:
Hi,
On Mon, Jul 31, 2023 at 2:15 PM Marek Vasut wrote:
On 7/31/23 21:50, Doug Anderson wrote:
Hi,
On Mon, Jul 31, 2023 at 11:03 AM Marek Vasut wrote:
On 7/24/23 15:49, Doug Anderson wrote:
Hi,
[...]
Maybe the EPROBE_DEFER actually happens and triggers the failure ?
I could certainly believe that EPROBE_DEFER is involved.
So no, it is not. It is difficult to set this up and access the signals,
but so I did.
What happens is this:
panel_simple_probe() calls devm_regulator_get()
-> If the regulator was ENABLED, then it is now DISABLED
As per my previous response, I don't think this is true.
I just measured that with a scope on actual hardware .
reg_fixed_voltage_probe() is the code which turns the regulator OFF,
specifically in the part gpiod_get_optional(...GPIOD_OUT_LOW);
Great, at least we're on the same page here now.
So just as a point of order, do you agree that prior to the commit
that you are "Fixing" that we _weren't_ doing the full delay at probe
time? That means that if things worked before they were working by
some amount of luck, right? The old code used to do a delay after
turning _off_ the regulator (at unprepare time).
Yes, that's well possible.
...so assuming we agree that this is _not_ a regression introduced by
e5e30dfcf3db ("drm: panel: simple: Defer unprepare delay till next
prepare to shorten it"), that means that all other preexisting users
of panel-simple were fine with the old behavior
No, it does not mean that all the previous users were fine with that
behavior. It means the driver operates panels out of spec, we cannot
know which ones, but we do know it does. Whether users noticed that
defect or not is another question, which we cannot answer.
where the unprepare
delay was only enforced when the panel driver itself turned things off
and then back on and no extra delay was needed at probe. The one board
we know about that has a problem with this behavior is the one you're
reproducing on, which we think only worked previously by chance.
There is at least one device now which shows a problem with the current
state of driver.
I will also continue to assert that trying to fix the problem via a
delay in the probe of the panel code is the wrong place to fix the
code. The problem is that you need a board-level constraint on this
regulator (off-on-delay-us) preventing it from turning on again within
a certain amount of time after it is turned off. This allows the
regulator framework, which is what decided to turn this rail off
during the regulator probe, to enforce this constraint.
No, the driver must respect the unprepare delay, that is what is
currently not happening. Trying to somehow work around that by adding
random changes to DT is not going to fix the fact that panel-simple is
not respecting its own internal built-in constraints.
Well, except that the panel _isn't_ actually unpreparing the panel.
The constant you're talking about is a delay between unpreparing the
panel and then preparing it again and we're not doing that here. Here,
you are trying to account for an implicit unprepare that happened
outside the context of the panel driver (in the regulator framework).
The regulator framework is the one disabling the regulator on its own
and without the knowledge of the panel driver.
I agree until this point.
The problem should be
addressed at the regulator framework, which might involve the
off-on-delay.
I disagree with this point.
I would even go further and say that, perhaps, when the regulator
framework turns this regulator off at bootup then you might be
violating the power sequencing requirements in the panel anyway. If
the bootloader left the panel on and _also_ left an enable GPIO on
then it's entirely possible that you've got a power leak through the
enable GPIO where you're backpowering the panel's logic when the
regulator framework turns things off. This is something that would be
impossible for the panel driver to solve because the panel driver
hasn't even probed yet.
I agree with this part as well.
In any case, at this point it seems unlikely that I'll convince you or
that you'll convince me. I wonder if it's time for someone else on
this thread to provide an opinion.
I agree with this part as well.
Re: [PATCH] drm/panel: simple: Initialize unprepared_time in probe
Hi,
On Mon, Jul 31, 2023 at 2:15 PM Marek Vasut wrote:
>
> On 7/31/23 21:50, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Jul 31, 2023 at 11:03 AM Marek Vasut wrote:
> >>
> >> On 7/24/23 15:49, Doug Anderson wrote:
> >>
> >> Hi,
> >>
> >> [...]
> >>
> Maybe the EPROBE_DEFER actually happens and triggers the failure ?
> >>>
> >>> I could certainly believe that EPROBE_DEFER is involved.
> >>
> >> So no, it is not. It is difficult to set this up and access the signals,
> >> but so I did.
> >>
> >> What happens is this:
> >> panel_simple_probe() calls devm_regulator_get()
> >> -> If the regulator was ENABLED, then it is now DISABLED
> >
> > As per my previous response, I don't think this is true.
>
> I just measured that with a scope on actual hardware .
>
> reg_fixed_voltage_probe() is the code which turns the regulator OFF,
> specifically in the part gpiod_get_optional(...GPIOD_OUT_LOW);
Great, at least we're on the same page here now.
> > So just as a point of order, do you agree that prior to the commit
> > that you are "Fixing" that we _weren't_ doing the full delay at probe
> > time? That means that if things worked before they were working by
> > some amount of luck, right? The old code used to do a delay after
> > turning _off_ the regulator (at unprepare time).
>
> Yes, that's well possible.
...so assuming we agree that this is _not_ a regression introduced by
e5e30dfcf3db ("drm: panel: simple: Defer unprepare delay till next
prepare to shorten it"), that means that all other preexisting users
of panel-simple were fine with the old behavior where the unprepare
delay was only enforced when the panel driver itself turned things off
and then back on and no extra delay was needed at probe. The one board
we know about that has a problem with this behavior is the one you're
reproducing on, which we think only worked previously by chance.
> > I will also continue to assert that trying to fix the problem via a
> > delay in the probe of the panel code is the wrong place to fix the
> > code. The problem is that you need a board-level constraint on this
> > regulator (off-on-delay-us) preventing it from turning on again within
> > a certain amount of time after it is turned off. This allows the
> > regulator framework, which is what decided to turn this rail off
> > during the regulator probe, to enforce this constraint.
>
> No, the driver must respect the unprepare delay, that is what is
> currently not happening. Trying to somehow work around that by adding
> random changes to DT is not going to fix the fact that panel-simple is
> not respecting its own internal built-in constraints.
Well, except that the panel _isn't_ actually unpreparing the panel.
The constant you're talking about is a delay between unpreparing the
panel and then preparing it again and we're not doing that here. Here,
you are trying to account for an implicit unprepare that happened
outside the context of the panel driver (in the regulator framework).
The regulator framework is the one disabling the regulator on its own
and without the knowledge of the panel driver. The problem should be
addressed at the regulator framework, which might involve the
off-on-delay.
I would even go further and say that, perhaps, when the regulator
framework turns this regulator off at bootup then you might be
violating the power sequencing requirements in the panel anyway. If
the bootloader left the panel on and _also_ left an enable GPIO on
then it's entirely possible that you've got a power leak through the
enable GPIO where you're backpowering the panel's logic when the
regulator framework turns things off. This is something that would be
impossible for the panel driver to solve because the panel driver
hasn't even probed yet.
In any case, at this point it seems unlikely that I'll convince you or
that you'll convince me. I wonder if it's time for someone else on
this thread to provide an opinion.
-Doug
Re: [PATCH] drm/i915/huc: fix intel_huc.c doc bulleted list format error
On 7/26/2023 7:54 PM, David Reaver wrote: Fix the following make htmldocs errors/warnings: ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:29: ERROR: Unexpected indentation. ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:30: WARNING: Block quote ends without a blank line; unexpected unindent. ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:35: WARNING: Bullet list ends without a blank line; unexpected unindent. This output is a bit misleading. The real issue here is we need a blank line before and after the bulleted list. Link: https://www.kernel.org/doc/html/latest/gpu/i915.html#huc Link: https://lore.kernel.org/dri-devel/20230530152958.1384061-1-daniele.ceraolospu...@intel.com/ Signed-off-by: David Reaver Reviewed-by: Daniele Ceraolo Spurio and pushed to drm-intel-gt-next. thanks for the fix, Daniele --- drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c b/drivers/gpu/drm/i915/gt/uc/intel_huc.c index ddd146265beb..fa70defcb5b2 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c @@ -26,6 +26,7 @@ * The kernel driver is only responsible for loading the HuC firmware and * triggering its security authentication. This is done differently depending * on the platform: + * * - older platforms (from Gen9 to most Gen12s): the load is performed via DMA * and the authentication via GuC * - DG2: load and authentication are both performed via GSC. @@ -33,6 +34,7 @@ * not-DG2 older platforms), while the authentication is done in 2-steps, * a first auth for clear-media workloads via GuC and a second one for all * workloads via GSC. + * * On platforms where the GuC does the authentication, to correctly do so the * HuC binary must be loaded before the GuC one. * Loading the HuC is optional; however, not using the HuC might negatively
Re: [PATCH] drm/panel: simple: Initialize unprepared_time in probe
On 7/31/23 21:50, Doug Anderson wrote: Hi, On Mon, Jul 31, 2023 at 11:03 AM Marek Vasut wrote: On 7/24/23 15:49, Doug Anderson wrote: Hi, [...] Maybe the EPROBE_DEFER actually happens and triggers the failure ? I could certainly believe that EPROBE_DEFER is involved. So no, it is not. It is difficult to set this up and access the signals, but so I did. What happens is this: panel_simple_probe() calls devm_regulator_get() -> If the regulator was ENABLED, then it is now DISABLED As per my previous response, I don't think this is true. I just measured that with a scope on actual hardware . reg_fixed_voltage_probe() is the code which turns the regulator OFF, specifically in the part gpiod_get_optional(...GPIOD_OUT_LOW); This was the part where I referred to `Documentation/power/regulator/consumer.rst` which said: NOTE: The supply may already be enabled before regulator_enabled() is called. This may happen if the consumer shares the regulator or the regulator has been previously enabled by bootloader or kernel board initialization code. My belief is that what's actually happening is that when the regulator _probes_ that the regulator turns off. In Linux GPIO regulators cannot read the state of the regulator at bootup. That means that when the regulator itself probes that Linux has to decide on the default state of the regulator itself. If the device tree has "regulator-boot-on" then Linux will turn the regulator on (even without any clients). In this case the regulator will stay on until some client enables and then disables the regulator, or until the regulator boot timeout happens and all unused regulators are powered off. If the device tree doesn't have "regulator-boot-on" then Linux will turn the regulator off. -> For regulator-fixed, this means the regulator GPIO goes HIGH->LOW panel_simple_prepare() triggers panel_simple_resume() -> If this occurs too soon after devm_regulator_get() turned the regulator OFF and thus regulator GPIO low, then unprepare time is not respected => FAIL Since there is no way to find out in which state the regulator was when devm_regulator_get() was called, we have to wait the full unprepare time before re-enabling that regulator in panel_simple_resume(). So just as a point of order, do you agree that prior to the commit that you are "Fixing" that we _weren't_ doing the full delay at probe time? That means that if things worked before they were working by some amount of luck, right? The old code used to do a delay after turning _off_ the regulator (at unprepare time). Yes, that's well possible. I will also continue to assert that trying to fix the problem via a delay in the probe of the panel code is the wrong place to fix the code. The problem is that you need a board-level constraint on this regulator (off-on-delay-us) preventing it from turning on again within a certain amount of time after it is turned off. This allows the regulator framework, which is what decided to turn this rail off during the regulator probe, to enforce this constraint. No, the driver must respect the unprepare delay, that is what is currently not happening. Trying to somehow work around that by adding random changes to DT is not going to fix the fact that panel-simple is not respecting its own internal built-in constraints.
[PATCH 1/2] dt-bindings: display: simple: Add Innolux G156HCE-L01 panel
Add entry for Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel. Documentation is available at [1]. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdf Signed-off-by: Marek Vasut --- Cc: Conor Dooley Cc: Daniel Vetter Cc: David Airlie Cc: Krzysztof Kozlowski Cc: Neil Armstrong Cc: Rob Herring Cc: Sam Ravnborg Cc: Thierry Reding Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 1751ad56b158c..25b4589d4a581 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -192,6 +192,8 @@ properties: - innolux,n116bge # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel - innolux,n125hce-gn1 +# InnoLux 15.6" FHD (1920x1080) TFT LCD panel + - innolux,g156hce-l01 # InnoLux 15.6" WXGA TFT LCD panel - innolux,n156bge-l21 # Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel -- 2.40.1
[PATCH 2/2] drm/panel-simple: Add Innolux G156HCE-L01 panel entry
Add support for Innolux G156HCE-L01 15.6" 1920x1080 24bpp
dual-link LVDS TFT panel. Documentation is available at [1].
The middle frequency is tuned slightly upward from 70.93 MHz
to 72 MHz, otherwise the panel shows slight flicker.
[1]
https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdf
Signed-off-by: Marek Vasut
---
Cc: Conor Dooley
Cc: Daniel Vetter
Cc: David Airlie
Cc: Krzysztof Kozlowski
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Thierry Reding
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 396a22177c674..417dd69054fc1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2377,6 +2377,37 @@ static const struct panel_desc innolux_g121x1_l03 = {
},
};
+static const struct display_timing innolux_g156hce_l01_timings = {
+ .pixelclock = { 12000, 14400, 15000 },
+ .hactive = { 1920, 1920, 1920 },
+ .hfront_porch = { 80, 90, 100 },
+ .hback_porch = { 80, 90, 100 },
+ .hsync_len = { 20, 30, 30 },
+ .vactive = { 1080, 1080, 1080 },
+ .vfront_porch = { 3, 10, 20 },
+ .vback_porch = { 3, 10, 20 },
+ .vsync_len = { 4, 10, 10 },
+};
+
+static const struct panel_desc innolux_g156hce_l01 = {
+ .timings = _g156hce_l01_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 344,
+ .height = 194,
+ },
+ .delay = {
+ .prepare = 1, /* T1+T2 */
+ .enable = 450, /* T5 */
+ .disable = 200, /* T6 */
+ .unprepare = 10,/* T3+T7 */
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode innolux_n156bge_l21_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -4243,6 +4274,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g121x1-l03",
.data = _g121x1_l03,
+ }, {
+ .compatible = "innolux,g156hce-l01",
+ .data = _g156hce_l01,
}, {
.compatible = "innolux,n156bge-l21",
.data = _n156bge_l21,
--
2.40.1
Re: [PATCH v2] drm/panel: Enable DSC and CMD mode for Visionox VTDR6130 panel
CC-ing rest of correspondents
On 7/28/2023 5:43 PM, Paloma Arellano wrote:
On 7/28/2023 2:37 AM, Dmitry Baryshkov wrote:
On Fri, 28 Jul 2023 at 04:26, Paloma Arellano
wrote:
Enable display compression (DSC v1.2) and CMD mode for 1080x2400
Visionox
VTDR6130 AMOLED DSI panel. In addition, this patch will set the default
to command mode with DSC enabled.
Note: This patch has only been validated DSC over command mode as
DSC over
video mode has never been validated for the MSM driver before.
Depends on: "Add prepare_prev_first flag to Visionox VTDR6130" [1]
Changes since v1:
- Changed from email address
[1] https://patchwork.freedesktop.org/series/121337/
Suggested-by: Jessica Zhang
Signed-off-by: Paloma Arellano
---
.../gpu/drm/panel/panel-visionox-vtdr6130.c | 77
++-
1 file changed, 73 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c
b/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c
index e1363e128e7e..5658d39a3a6b 100644
--- a/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c
+++ b/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -20,7 +21,8 @@ struct visionox_vtdr6130 {
struct mipi_dsi_device *dsi;
struct gpio_desc *reset_gpio;
struct regulator_bulk_data supplies[3];
- bool prepared;
+ bool prepared, enabled;
+ bool video_mode;
};
static inline struct visionox_vtdr6130
*to_visionox_vtdr6130(struct drm_panel *panel)
@@ -50,12 +52,18 @@ static int visionox_vtdr6130_on(struct
visionox_vtdr6130 *ctx)
if (ret)
return ret;
+ mipi_dsi_dcs_write_seq(dsi, 0x03, 0x01);
mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
0x20);
mipi_dsi_dcs_write_seq(dsi,
MIPI_DCS_SET_DISPLAY_BRIGHTNESS, 0x00, 0x00);
mipi_dsi_dcs_write_seq(dsi, 0x59, 0x09);
mipi_dsi_dcs_write_seq(dsi, 0x6c, 0x01);
mipi_dsi_dcs_write_seq(dsi, 0x6d, 0x00);
- mipi_dsi_dcs_write_seq(dsi, 0x6f, 0x01);
+
+ if (ctx->video_mode)
+ mipi_dsi_dcs_write_seq(dsi, 0x6f, 0x01);
+ else
+ mipi_dsi_dcs_write_seq(dsi, 0x6f, 0x02);
+
mipi_dsi_dcs_write_seq(dsi, 0x70,
0x12, 0x00, 0x00, 0xab, 0x30, 0x80,
0x09, 0x60, 0x04,
0x38, 0x00, 0x28, 0x02, 0x1c, 0x02,
0x1c, 0x02, 0x00,
@@ -214,6 +222,42 @@ static const struct drm_display_mode
visionox_vtdr6130_mode = {
.height_mm = 157,
};
+static int visionox_vtdr6130_enable(struct drm_panel *panel)
+{
+ struct visionox_vtdr6130 *ctx = to_visionox_vtdr6130(panel);
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct drm_dsc_picture_parameter_set pps;
+ int ret;
+
+ if (ctx->enabled)
+ return 0;
+
+ if (!dsi->dsc) {
+ dev_err(>dev, "DSC not attached to DSI\n");
+ return -ENODEV;
+ }
The error message is misleading. Also, if you don't want to enable DSC
for the video mode, this will break.
Changed the phrasing to "DSC not enabled on DSI"
+
+ drm_dsc_pps_payload_pack(, dsi->dsc);
+ ret = mipi_dsi_picture_parameter_set(dsi, );
+ if (ret) {
+ dev_err(>dev, "Failed to set PPS\n");
+ return ret;
+ }
+
+ ctx->enabled = true;
Do we need this refcount just for PPS upload? What will happen if PPS
is uploaded several times?
Removing the refcount does not crash the device. Wouldn't it be better
to send the configuration once, instead of re-sending the pps every
time the panel is enabled?
+
+ return 0;
+}
+
+static int visionox_vtdr6130_disable(struct drm_panel *panel)
+{
+ struct visionox_vtdr6130 *ctx = to_visionox_vtdr6130(panel);
+
+ ctx->enabled = false;
+
+ return 0;
+}
+
static int visionox_vtdr6130_get_modes(struct drm_panel *panel,
struct drm_connector
*connector)
{
@@ -237,6 +281,8 @@ static const struct drm_panel_funcs
visionox_vtdr6130_panel_funcs = {
.prepare = visionox_vtdr6130_prepare,
.unprepare = visionox_vtdr6130_unprepare,
.get_modes = visionox_vtdr6130_get_modes,
+ .enable = visionox_vtdr6130_enable,
+ .disable = visionox_vtdr6130_disable,
};
static int visionox_vtdr6130_bl_update_status(struct
backlight_device *bl)
@@ -269,11 +315,31 @@ static int visionox_vtdr6130_probe(struct
mipi_dsi_device *dsi)
{
struct device *dev = >dev;
struct visionox_vtdr6130 *ctx;
+ struct drm_dsc_config *dsc;
int ret;
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+
+ ctx->video_mode = of_property_read_bool(dev->of_node,
"enforce-video-mode");
Please also add a DT bindings patch.
Ack
+
+ dsc = devm_kzalloc(dev,
Re: [PATCH] drm/panel: simple: Initialize unprepared_time in probe
Hi, On Mon, Jul 31, 2023 at 11:03 AM Marek Vasut wrote: > > On 7/24/23 15:49, Doug Anderson wrote: > > Hi, > > [...] > > >> Maybe the EPROBE_DEFER actually happens and triggers the failure ? > > > > I could certainly believe that EPROBE_DEFER is involved. > > So no, it is not. It is difficult to set this up and access the signals, > but so I did. > > What happens is this: > panel_simple_probe() calls devm_regulator_get() >-> If the regulator was ENABLED, then it is now DISABLED As per my previous response, I don't think this is true. This was the part where I referred to `Documentation/power/regulator/consumer.rst` which said: NOTE: The supply may already be enabled before regulator_enabled() is called. This may happen if the consumer shares the regulator or the regulator has been previously enabled by bootloader or kernel board initialization code. My belief is that what's actually happening is that when the regulator _probes_ that the regulator turns off. In Linux GPIO regulators cannot read the state of the regulator at bootup. That means that when the regulator itself probes that Linux has to decide on the default state of the regulator itself. If the device tree has "regulator-boot-on" then Linux will turn the regulator on (even without any clients). In this case the regulator will stay on until some client enables and then disables the regulator, or until the regulator boot timeout happens and all unused regulators are powered off. If the device tree doesn't have "regulator-boot-on" then Linux will turn the regulator off. >-> For regulator-fixed, this means the regulator GPIO goes HIGH->LOW > > panel_simple_prepare() triggers panel_simple_resume() >-> If this occurs too soon after devm_regulator_get() turned the > regulator OFF and thus regulator GPIO low, then unprepare time is > not respected => FAIL > > Since there is no way to find out in which state the regulator was when > devm_regulator_get() was called, we have to wait the full unprepare time > before re-enabling that regulator in panel_simple_resume(). So just as a point of order, do you agree that prior to the commit that you are "Fixing" that we _weren't_ doing the full delay at probe time? That means that if things worked before they were working by some amount of luck, right? The old code used to do a delay after turning _off_ the regulator (at unprepare time). I will also continue to assert that trying to fix the problem via a delay in the probe of the panel code is the wrong place to fix the code. The problem is that you need a board-level constraint on this regulator (off-on-delay-us) preventing it from turning on again within a certain amount of time after it is turned off. This allows the regulator framework, which is what decided to turn this rail off during the regulator probe, to enforce this constraint. -Doug
Re: [PATCH] fbdev/ps3fb: Build without kernel device
On Mon, Jul 31, 2023 at 07:55:00PM +0200, Thomas Zimmermann wrote:
> Use fb_info() to print status message at the end of the probe function,
> which avoids decoding the devices. fb_info() works with or without an
> fbdev kernel device. Fixes the following error:
>
> ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
> ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member
> named 'dev'
> 1172 | dev_driver_string(info->dev), dev_name(info->dev),
> |^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro
> 'dev_printk_index_wrap'
> 110 | _p_func(dev, fmt, ##__VA_ARGS__);
> \
> | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
> 1171 | dev_info(info->device, "%s %s, using %u KiB of video
> memory\n",
> | ^~~~
> ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member
> named 'dev'
> 1172 | dev_driver_string(info->dev), dev_name(info->dev),
> | ^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro
> 'dev_printk_index_wrap'
> 110 | _p_func(dev, fmt, ##__VA_ARGS__);
> \
> | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
> 1171 | dev_info(info->device, "%s %s, using %u KiB of video
> memory\n",
> | ^~~~
>
> Reported-by: Randy Dunlap
> Closes:
> https://lore.kernel.org/lkml/ccc63065-2976-88ef-1211-731330bf2...@infradead.org/
> Signed-off-by: Thomas Zimmermann
> Fixes: 701d2054fa31 ("fbdev: Make support for userspace interfaces
> configurable")
> Cc: Michael Ellerman
> Cc: Sam Ravnborg
> Cc: Helge Deller
> Cc: Javier Martinez Canillas
> Cc: Randy Dunlap
> Cc: Bagas Sanjaya
> Cc: Thorsten Leemhuis
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/ps3fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
> index 5aedc30c5f7e..64d291d6b153 100644
> --- a/drivers/video/fbdev/ps3fb.c
> +++ b/drivers/video/fbdev/ps3fb.c
> @@ -1168,9 +1168,7 @@ static int ps3fb_probe(struct ps3_system_bus_device
> *dev)
>
> ps3_system_bus_set_drvdata(dev, info);
>
> - dev_info(info->device, "%s %s, using %u KiB of video memory\n",
> - dev_driver_string(info->dev), dev_name(info->dev),
> - info->fix.smem_len >> 10);
> + fb_info(info, "using %u KiB of video memory\n", info->fix.smem_len >>
> 10);
>
> task = kthread_run(ps3fbd, info, DEVICE_NAME);
> if (IS_ERR(task)) {
> --
> 2.41.0
[PATCH] drm/nouveau: fixup the uapi header file.
From: Dave Airlie
nouveau > 10 years ago had a plan for new multiplexer inside a multiplexer
API using nvif. It never fully reached fruition, fast forward 10 years,
and the new vulkan driver is avoiding libdrm and calling ioctls, and
these 3 ioctls, getparam, channel alloc + free don't seem to be things
we'd want to use nvif for.
Undeprecate and put them into the uapi header so we can just copy it
into mesa later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_abi16.h | 41 -
include/uapi/drm/nouveau_drm.h | 48 +++--
2 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index 27eae85f33e6..d5d80d0d9011 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
@@ -43,28 +43,6 @@ int nouveau_abi16_usif(struct drm_file *, void *data, u32
size);
#define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
-struct drm_nouveau_channel_alloc {
- uint32_t fb_ctxdma_handle;
- uint32_t tt_ctxdma_handle;
-
- int channel;
- uint32_t pushbuf_domains;
-
- /* Notifier memory */
- uint32_t notifier_handle;
-
- /* DRM-enforced subchannel assignments */
- struct {
- uint32_t handle;
- uint32_t grclass;
- } subchan[8];
- uint32_t nr_subchan;
-};
-
-struct drm_nouveau_channel_free {
- int channel;
-};
-
struct drm_nouveau_grobj_alloc {
int channel;
uint32_t handle;
@@ -83,31 +61,12 @@ struct drm_nouveau_gpuobj_free {
uint32_t handle;
};
-#define NOUVEAU_GETPARAM_PCI_VENDOR 3
-#define NOUVEAU_GETPARAM_PCI_DEVICE 4
-#define NOUVEAU_GETPARAM_BUS_TYPE5
-#define NOUVEAU_GETPARAM_FB_SIZE 8
-#define NOUVEAU_GETPARAM_AGP_SIZE9
-#define NOUVEAU_GETPARAM_CHIPSET_ID 11
-#define NOUVEAU_GETPARAM_VM_VRAM_BASE12
-#define NOUVEAU_GETPARAM_GRAPH_UNITS 13
-#define NOUVEAU_GETPARAM_PTIMER_TIME 14
-#define NOUVEAU_GETPARAM_HAS_BO_USAGE15
-#define NOUVEAU_GETPARAM_HAS_PAGEFLIP16
-struct drm_nouveau_getparam {
- uint64_t param;
- uint64_t value;
-};
-
struct drm_nouveau_setparam {
uint64_t param;
uint64_t value;
};
-#define DRM_IOCTL_NOUVEAU_GETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_GETPARAM, struct drm_nouveau_getparam)
#define DRM_IOCTL_NOUVEAU_SETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_SETPARAM, struct drm_nouveau_setparam)
-#define DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_CHANNEL_ALLOC, struct drm_nouveau_channel_alloc)
-#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE DRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
#define DRM_IOCTL_NOUVEAU_GROBJ_ALLOCDRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_GROBJ_ALLOC, struct drm_nouveau_grobj_alloc)
#define DRM_IOCTL_NOUVEAU_NOTIFIEROBJ_ALLOC DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_NOTIFIEROBJ_ALLOC, struct drm_nouveau_notifierobj_alloc)
#define DRM_IOCTL_NOUVEAU_GPUOBJ_FREEDRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_GPUOBJ_FREE, struct drm_nouveau_gpuobj_free)
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 853a327433d3..1cd97b3d8eda 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -33,6 +33,44 @@
extern "C" {
#endif
+#define NOUVEAU_GETPARAM_PCI_VENDOR 3
+#define NOUVEAU_GETPARAM_PCI_DEVICE 4
+#define NOUVEAU_GETPARAM_BUS_TYPE5
+#define NOUVEAU_GETPARAM_FB_SIZE 8
+#define NOUVEAU_GETPARAM_AGP_SIZE9
+#define NOUVEAU_GETPARAM_CHIPSET_ID 11
+#define NOUVEAU_GETPARAM_VM_VRAM_BASE12
+#define NOUVEAU_GETPARAM_GRAPH_UNITS 13
+#define NOUVEAU_GETPARAM_PTIMER_TIME 14
+#define NOUVEAU_GETPARAM_HAS_BO_USAGE15
+#define NOUVEAU_GETPARAM_HAS_PAGEFLIP16
+struct drm_nouveau_getparam {
+ uint64_t param;
+ uint64_t value;
+};
+
+struct drm_nouveau_channel_alloc {
+ uint32_t fb_ctxdma_handle;
+ uint32_t tt_ctxdma_handle;
+
+ int channel;
+ uint32_t pushbuf_domains;
+
+ /* Notifier memory */
+ uint32_t notifier_handle;
+
+ /* DRM-enforced subchannel assignments */
+ struct {
+ uint32_t handle;
+ uint32_t grclass;
+ } subchan[8];
+ uint32_t nr_subchan;
+};
+
+struct drm_nouveau_channel_free {
+ int channel;
+};
+
#define NOUVEAU_GEM_DOMAIN_CPU (1 << 0)
#define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
@@ -126,10 +164,10 @@ struct drm_nouveau_gem_cpu_fini {
__u32 handle;
};
-#define DRM_NOUVEAU_GETPARAM 0x00 /* deprecated */
+#define DRM_NOUVEAU_GETPARAM 0x00
#define
[PATCH v3] drm/tests: Alloc drm_device on drm_exec tests
The drm_exec tests where crashing[0] because of a null dereference. This
is caused by a new access of the `driver` attribute of `struct
drm_driver` on drm_gem_private_object_init(). Alloc the drm_device to
fix that.
[0]
[15:05:24] == drm_exec (6 subtests) ===
[15:05:24] [PASSED] sanitycheck
^CERROR:root:Build interruption occurred. Cleaning console.
[15:05:50] [ERROR] Test: drm_exec: missing expected subtest!
[15:05:50] BUG: kernel NULL pointer dereference, address: 00b0
[15:05:50] #PF: supervisor read access in kernel mode
[15:05:50] #PF: error_code(0x) - not-present page
[15:05:50] PGD 0 P4D 0
[15:05:50] Oops: [#1] PREEMPT NOPTI
[15:05:50] CPU: 0 PID: 23 Comm: kunit_try_catch Tainted: G N
6.4.0-rc7-02032-ge6303f323b1a #69
[15:05:50] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.2-1.fc37 04/01/2014
[15:05:50] RIP: 0010:drm_gem_private_object_init+0x60/0xc0
Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
Signed-off-by: Arthur Grillo
Tested-by: Danilo Krummrich
Acked-by: Danilo Krummrich
Reviewed-by: Maíra Canal
---
v1->v2:
https://lore.kernel.org/all/20230727192259.237935-1-arthurgri...@riseup.net/
- s/test_init/drm_exec_test_init/ (Maíra)
- s/test_exit/drm_exec_test_exit/ (Maíra)
- Use test->priv intead of global variables (Maíra and Maxime)
v2->v3:
https://lore.kernel.org/r/20230728183400.306193-1-arthurgri...@riseup.net
- Remove unnecessary call to drm_kunit_helper_free_device() (Maxime)
---
drivers/gpu/drm/tests/drm_exec_test.c | 44 ++-
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_exec_test.c
b/drivers/gpu/drm/tests/drm_exec_test.c
index 727ac267682e..f79c9f0359aa 100644
--- a/drivers/gpu/drm/tests/drm_exec_test.c
+++ b/drivers/gpu/drm/tests/drm_exec_test.c
@@ -12,11 +12,35 @@
#include
#include
+#include
#include
+#include
#include "../lib/drm_random.h"
-static struct drm_device dev;
+struct drm_exec_priv {
+ struct device *dev;
+ struct drm_device *drm;
+};
+
+static int drm_exec_test_init(struct kunit *test)
+{
+ struct drm_exec_priv *priv;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+
+ test->priv = priv;
+
+ priv->dev = drm_kunit_helper_alloc_device(test);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
+
+ priv->drm = __drm_kunit_helper_alloc_drm_device(test, priv->dev,
sizeof(*priv->drm), 0,
+ DRIVER_MODESET);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
+
+ return 0;
+}
static void sanitycheck(struct kunit *test)
{
@@ -29,11 +53,12 @@ static void sanitycheck(struct kunit *test)
static void test_lock(struct kunit *test)
{
+ struct drm_exec_priv *priv = test->priv;
struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
- drm_gem_private_object_init(, , PAGE_SIZE);
+ drm_gem_private_object_init(priv->drm, , PAGE_SIZE);
drm_exec_init(, DRM_EXEC_INTERRUPTIBLE_WAIT);
drm_exec_until_all_locked() {
@@ -48,11 +73,12 @@ static void test_lock(struct kunit *test)
static void test_lock_unlock(struct kunit *test)
{
+ struct drm_exec_priv *priv = test->priv;
struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
- drm_gem_private_object_init(, , PAGE_SIZE);
+ drm_gem_private_object_init(priv->drm, , PAGE_SIZE);
drm_exec_init(, DRM_EXEC_INTERRUPTIBLE_WAIT);
drm_exec_until_all_locked() {
@@ -74,11 +100,12 @@ static void test_lock_unlock(struct kunit *test)
static void test_duplicates(struct kunit *test)
{
+ struct drm_exec_priv *priv = test->priv;
struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
- drm_gem_private_object_init(, , PAGE_SIZE);
+ drm_gem_private_object_init(priv->drm, , PAGE_SIZE);
drm_exec_init(, DRM_EXEC_IGNORE_DUPLICATES);
drm_exec_until_all_locked() {
@@ -102,11 +129,12 @@ static void test_duplicates(struct kunit *test)
static void test_prepare(struct kunit *test)
{
+ struct drm_exec_priv *priv = test->priv;
struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
- drm_gem_private_object_init(, , PAGE_SIZE);
+ drm_gem_private_object_init(priv->drm, , PAGE_SIZE);
drm_exec_init(, DRM_EXEC_INTERRUPTIBLE_WAIT);
drm_exec_until_all_locked() {
@@ -121,14 +149,15 @@ static void test_prepare(struct kunit *test)
static void test_prepare_array(struct kunit *test)
{
+ struct drm_exec_priv *priv = test->priv;
struct drm_gem_object gobj1 = { };
struct drm_gem_object gobj2 = { };
struct drm_gem_object *array[] = { , };
struct drm_exec exec;
Re: [PATCH] drm/panel: simple: Initialize unprepared_time in probe
On 7/24/23 15:49, Doug Anderson wrote: Hi, [...] Maybe the EPROBE_DEFER actually happens and triggers the failure ? I could certainly believe that EPROBE_DEFER is involved. So no, it is not. It is difficult to set this up and access the signals, but so I did. What happens is this: panel_simple_probe() calls devm_regulator_get() -> If the regulator was ENABLED, then it is now DISABLED -> For regulator-fixed, this means the regulator GPIO goes HIGH->LOW panel_simple_prepare() triggers panel_simple_resume() -> If this occurs too soon after devm_regulator_get() turned the regulator OFF and thus regulator GPIO low, then unprepare time is not respected => FAIL Since there is no way to find out in which state the regulator was when devm_regulator_get() was called, we have to wait the full unprepare time before re-enabling that regulator in panel_simple_resume().
[PATCH] fbdev/ps3fb: Build without kernel device
Use fb_info() to print status message at the end of the probe function,
which avoids decoding the devices. fb_info() works with or without an
fbdev kernel device. Fixes the following error:
../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member
named 'dev'
1172 | dev_driver_string(info->dev), dev_name(info->dev),
|^~
../include/linux/dev_printk.h:110:37: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
| ^~~~
../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member
named 'dev'
1172 | dev_driver_string(info->dev), dev_name(info->dev),
| ^~
../include/linux/dev_printk.h:110:37: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
| ^~~~
Reported-by: Randy Dunlap
Closes:
https://lore.kernel.org/lkml/ccc63065-2976-88ef-1211-731330bf2...@infradead.org/
Signed-off-by: Thomas Zimmermann
Fixes: 701d2054fa31 ("fbdev: Make support for userspace interfaces
configurable")
Cc: Michael Ellerman
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Javier Martinez Canillas
Cc: Randy Dunlap
Cc: Bagas Sanjaya
Cc: Thorsten Leemhuis
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
---
drivers/video/fbdev/ps3fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index 5aedc30c5f7e..64d291d6b153 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -1168,9 +1168,7 @@ static int ps3fb_probe(struct ps3_system_bus_device *dev)
ps3_system_bus_set_drvdata(dev, info);
- dev_info(info->device, "%s %s, using %u KiB of video memory\n",
-dev_driver_string(info->dev), dev_name(info->dev),
-info->fix.smem_len >> 10);
+ fb_info(info, "using %u KiB of video memory\n", info->fix.smem_len >>
10);
task = kthread_run(ps3fbd, info, DEVICE_NAME);
if (IS_ERR(task)) {
--
2.41.0
Re: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages)
On Sat, Jul 29, 2023 at 12:08:25AM +, Kasireddy, Vivek wrote:
> Hi Peter,
>
> > > > > > > > I'm not at all familiar with the udmabuf use case but that
> > > > > > > > sounds
> > > > > > > > brittle and effectively makes this notifier udmabuf specific
> > > > > > > > right?
> > > > > > > Oh, Qemu uses the udmabuf driver to provide Host Graphics
> > > > components
> > > > > > > (such as Spice, Gstreamer, UI, etc) zero-copy access to Guest
> > > > > > > created
> > > > > > > buffers. In other words, from a core mm standpoint, udmabuf just
> > > > > > > collects a bunch of pages (associated with buffers) scattered
> > > > > > > inside
> > > > > > > the memfd (Guest ram backed by shmem or hugetlbfs) and wraps
> > > > > > > them in a dmabuf fd. And, since we provide zero-copy access, we
> > > > > > > use DMA fences to ensure that the components on the Host and
> > > > > > > Guest do not access the buffer simultaneously.
> > > > > >
> > > > > > So why do you need to track updates proactively like this?
> > > > > As David noted in the earlier series, if Qemu punches a hole in its
> > memfd
> > > > > that goes through pages that are registered against a udmabuf fd, then
> > > > > udmabuf needs to update its list with new pages when the hole gets
> > > > > filled after (guest) writes. Otherwise, we'd run into the coherency
> > > > > problem (between udmabuf and memfd) as demonstrated in the
> > selftest
> > > > > (patch #3 in this series).
> > > >
> > > > Wouldn't this all be very much better if Qemu stopped punching holes
> > there?
> > > I think holes can be punched anywhere in the memfd for various reasons.
> > Some
> >
> > I just start to read this thread, even haven't finished all of them.. but
> > so far I'm not sure whether this is right at all..
> >
> > udmabuf is a file, it means it should follow the file semantics. Mmu
> Right, it is a file but a special type of file given that it is a dmabuf. So,
> AFAIK,
> operations such as truncate, FALLOC_FL_PUNCH_HOLE, etc cannot be done
> on it. And, in our use-case, since udmabuf driver is sharing (or exporting)
> its
> buffer (via the fd), consumers (or importers) of the dmabuf fd are expected
> to only read from it.
>
> > notifier is per-mm, otoh.
> >
> > Imagine for some reason QEMU mapped the guest pages twice, udmabuf is
> > created with vma1, so udmabuf registers the mm changes over vma1 only.
> Udmabufs are created with pages obtained from the mapping using offsets
> provided by Qemu.
>
> >
> > However the shmem/hugetlb page cache can be populated in either vma1, or
> > vma2. It means when populating on vma2 udmabuf won't get update notify
> > at
> > all, udmabuf pages can still be obsolete. Same thing to when multi-process
> In this (unlikely) scenario you described above,
IMHO it's very legal for qemu to do that, we won't want this to break so
easily and silently simply because qemu mapped it twice. I would hope
it'll not be myself to debug something like that. :)
I actually personally have a tree that does exactly that:
https://github.com/xzpeter/qemu/commit/62050626d6e511d022953165cc0f604bf90c5324
But that's definitely not in main line.. it shouldn't need special
attention, either. Just want to say that it can always happen for various
reasons especially in an relatively involved software piece like QEMU.
> I think we could still find all the
> VMAs (and ranges) where the guest buffer pages are mapped (and register
> for PTE updates) using Qemu's mm_struct. The below code can be modified
> to create a list of VMAs where the guest buffer pages are mapped.
> static struct vm_area_struct *find_guest_ram_vma(struct udmabuf *ubuf,
> struct mm_struct *vmm_mm)
> {
> struct vm_area_struct *vma = NULL;
> MA_STATE(mas, _mm->mm_mt, 0, 0);
> unsigned long addr;
> pgoff_t pg;
>
> mas_set(, 0);
> mmap_read_lock(vmm_mm);
> mas_for_each(, vma, ULONG_MAX) {
> for (pg = 0; pg < ubuf->pagecount; pg++) {
> addr = page_address_in_vma(ubuf->pages[pg], vma);
> if (addr == -EFAULT)
> break;
> }
> if (addr != -EFAULT)
> break;
> }
> mmap_read_unlock(vmm_mm);
>
> return vma;
> }
This is hackish to me, and not working when across mm (multi-proc qemu).
>
> > QEMU is used, where we can have vma1 in QEMU while vma2 in the other
> > process like vhost-user.
> >
> > I think the trick here is we tried to "hide" the fact that these are
> > actually normal file pages, but we're doing PFNMAP on them... then we want
> > the file features back, like hole punching..
> >
> > If we used normal file operations, everything will just work fine; TRUNCATE
> > will unmap the host mapped frame buffers when needed, and when
> > accessed
> > it'll fault on demand from the page cache. We seem
Re: [PATCH v3 02/10] drm/panel: Check for already prepared/enabled in drm_panel
Hi, On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote: > In my case a few different panel drivers disable the regulators in the > unprepare/disable routines. And that's totally fine. > For at least the Rockchip DSI implementations for some reason the > panel gets unprepared more than once, which triggers an unbalanced > regulator disable. "For some reason" being that DW-DSI apparently finds it ok to bypass any kind of abstraction and randomly calling panel functions by itself: https://elixir.bootlin.com/linux/v6.4.7/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868 It looks like it's fixed it current drm-misc-next though. > Obviously though the correct course of action is to fix the reason why > the panel is disabled more than once, but that's at least the root > cause of this behavior on the few panels I've worked with. Like I said we already have a commit on the way to fix that, so it shouldn't be an issue anymore. I stand by what I was saying earlier though, I think it's mostly cargo-cult or drivers being very wrong. If anything, the DW-DSI stuff made me even more convinced that we shouldn't even entertain that idea :) Maxime signature.asc Description: PGP signature
Re: [PATCH 00/14] A7xx support
On 28/06/2023 23:35, Konrad Dybcio wrote: This series attempts to introduce Adreno 700 support (with A730 and A740 found on SM8450 and SM8550 respectively), reusing much of the existing A6xx code. This submission largely lays the groundwork for expansion and more or less gives us feature parity (on the kernel side, that is) with existing A6xx parts. On top of introducing a very messy set of three (!) separate and obfuscated deivce identifiers for each 7xx part, this generation introduces very sophisticated hardware multi-threading and (on some SKUs) hardware ray-tracing (not supported yet). After this series, a long-overdue cleanup of drm/msm/adreno is planned in preparation for adding more features and removing some hardcoding. The last patch is a hack that may or may not be necessary depending on your board's humour.. eh.. :/ Developed atop (and hence depends on) [1] The corresponding devicetree patches are initially available at [2] and will be posted after this series gets merged. To test it, you'll also need firmware that you need to obtain from your board (there's none with a redistributable license, sorry..). Most likely it will be in one of these directories on your stock android installation: * /vendor/firmware * /vendor/firmware_mnt * /system ..but some vendors make it hard and you have to do some grepping ;) Requires [3] to work on the userspace side. You'll almost cerainly want to test it alongside Zink with a lot of debug flags (early impl), like: TU_DEBUG=sysmem,nolrz,flushall,noubwc MESA_LOADER_DRIVER_OVERRIDE=zink kmscube [1] https://lore.kernel.org/linux-arm-msm/20230517-topic-a7xx_prep-v4-0-b16f273a9...@linaro.org/ [2] https://github.com/SoMainline/linux/commits/topic/a7xx_dt [3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23217 Signed-off-by: Konrad Dybcio --- Konrad Dybcio (14): dt-bindings: display/msm/gmu: Add Adreno 7[34]0 GMU dt-bindings: display/msm/gmu: Allow passing QMP handle dt-bindings: display/msm/gpu: Allow A7xx SKUs drm/msm/a6xx: Add missing regs for A7XX drm/msm/a6xx: Introduce a6xx_llc_read drm/msm/a6xx: Move LLC accessors to the common header drm/msm/a6xx: Bail out early if setting GPU OOB fails drm/msm/a6xx: Add skeleton A7xx support drm/msm/a6xx: Send ACD state to QMP at GMU resume drm/msm/a6xx: Mostly implement A7xx gpu_state drm/msm/a6xx: Add A730 support drm/msm/a6xx: Add A740 support drm/msm/a6xx: Vastly increase HFI timeout [RFC] drm/msm/a6xx: Poll for GBIF unhalt status in hw_init .../devicetree/bindings/display/msm/gmu.yaml | 47 +- .../devicetree/bindings/display/msm/gpu.yaml | 4 +- drivers/gpu/drm/msm/adreno/a6xx.xml.h | 9 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 188 -- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 3 + drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 8 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 658 ++--- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 15 + drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c| 52 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h| 61 +- drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 90 ++- drivers/gpu/drm/msm/adreno/adreno_device.c | 26 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 7 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h| 24 +- drivers/gpu/drm/msm/msm_ringbuffer.h | 2 + 15 files changed, 1070 insertions(+), 124 deletions(-) --- base-commit: 6f9b660e9cbb30669fcfec83288d527c0844717d change-id: 20230628-topic-a7xx_drmmsm-123f30d76cf7 Tested-by: Dmitry Baryshkov # sm8450 -- With best wishes Dmitry
Re: [PATCH v4 0/6] Adreno QoL changes
On 20.06.2023 13:10, Konrad Dybcio wrote: > This series brings some niceties in preparation for A7xx introduction. > > It should be fully independent of the GMU wrapper series. > > Signed-off-by: Konrad Dybcio > --- Bump Konrad
Re: [PATCH drm-misc-next v8 11/12] drm/nouveau: implement new VM_BIND uAPI
On Sun, Jul 30, 2023 at 10:30 PM Faith Ekstrand wrote: > > On Tue, Jul 25, 2023 at 5:48 PM Danilo Krummrich wrote: > >> On 7/25/23 18:43, Danilo Krummrich wrote: >> > On 7/25/23 18:16, Faith Ekstrand wrote: >> >> Thanks for the detailed write-up! That would definitely explain it. If >> >> I remember, I'll try to do a single-threaded run or two. If your >> >> theory is correct, there should be no real perf difference when >> >> running single-threaded. Those runs will take a long time, though, so >> >> I'll have to run them over night. I'll let you know in a few days once >> >> I have the results. >> > >> > I can also push a separate branch where I just print out a warning >> > whenever we run into such a condition including the time we were >> waiting >> > for things to complete. I can probably push something later today. >> >> >> https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next-track-stalls >> >> It prints out the duration of every wait as well as the total wait time >> since boot. >> >> - Danilo >> >> > >> >> >> >> If this theory holds, then I'm not concerned about the performance of >> >> the API itself. It would still be good to see if we can find a way to >> >> reduce the cross-process drag in the implementation but that's a perf >> >> optimization we can do later. >> > >> > From the kernel side I think the only thing we could really do is to >> > temporarily run a secondary drm_gpu_scheduler instance, one for >> VM_BINDs >> > and one for EXECs until we got the new page table handling in place. >> > >> > However, the UMD could avoid such conditions more effectively, since it >> > controls the address space. Namely, avoid re-using the same region of >> > the address space right away in certain cases. For instance, instead of >> > replacing a sparse region A[0x0, 0x400] with a larger sparse region >> > B[0x0, 0x800], replace it with B'[0x400, 0xC00] if possible. >> > >> > However, just mentioning this for completeness. The UMD surely >> shouldn't >> > probably even temporarily work around such a kernel limitation. >> > >> > Anyway, before doing any of those, let's see if the theory holds and >> > we're actually running into such cases. >> > >> >> >> >> Does it actually matter? Yes, it kinda does. No, it probably doesn't >> >> matter for games because you're typically only running one game at a >> >> time. From a development PoV, however, if it makes CI take longer then >> >> that slows down development and that's not good for the users, either. >> > > I've run a bunch of tests over the weekend and It's starting to look like > the added CTS time might be from the newly enabled synchronization tests > themselves. We enabled timeline semaphores as well as semaphore and fence > sharing along with the new uAPI and I did not expect those to be nearly > that heavy-weight so I didn't think of that as a likely factor. I'm doing a > couple more runs to confirm but what I'm seeing right now seems to indicate > that the new API with the old feature set has about the same run time now > that the submit overhead issue has been fixed. > My last two runs have come back and confirmed this theory. With the BO fixes, all remaining slow-downs are coming from newly added tests which turn out to be very slow tests. ~Faith > I think this means that we can proceed under the assumption that there are > no more serious perf issues with the new API. I'm happy to RB/ACK the next > version of the API and implementation patches, as long as it has the new > NO_SHARE BO create flag and properly rejects exports of NO_SHARE BOs, even > if not all of the dma_resv plumbing is fully baked. > > ~Faith >
Re: [PATCH v3 02/10] drm/panel: Check for already prepared/enabled in drm_panel
In my case a few different panel drivers disable the regulators in the unprepare/disable routines. For at least the Rockchip DSI implementations for some reason the panel gets unprepared more than once, which triggers an unbalanced regulator disable. Obviously though the correct course of action is to fix the reason why the panel is disabled more than once, but that's at least the root cause of this behavior on the few panels I've worked with. Thank you. On Thu, Jul 27, 2023 at 1:38 AM Maxime Ripard wrote: > > Hi, > > On Wed, Jul 26, 2023 at 08:10:33AM -0700, Doug Anderson wrote: > > On Wed, Jul 26, 2023 at 5:41 AM Maxime Ripard wrote: > > > On Tue, Jul 25, 2023 at 01:34:37PM -0700, Douglas Anderson wrote: > > > > NOTE: arguably, the right thing to do here is actually to skip this > > > > patch and simply remove all the extra checks from the individual > > > > drivers. Perhaps the checks were needed at some point in time in the > > > > past but maybe they no longer are? Certainly as we continue > > > > transitioning over to "panel_bridge" then we expect there to be much > > > > less variety in how these calls are made. When we're called as part of > > > > the bridge chain, things should be pretty simple. In fact, there was > > > > some discussion in the past about these checks [1], including a > > > > discussion about whether the checks were needed and whether the calls > > > > ought to be refcounted. At the time, I decided not to mess with it > > > > because it felt too risky. > > > > > > Yeah, I'd agree here too. I've never found evidence that it was actually > > > needed and it really looks like cargo cult to me. > > > > > > And if it was needed, then I'm not sure we need refcounting either. We > > > don't have refcounting for atomic_enable / disable, we have a sound API > > > design that makes sure we don't fall into that trap :) > > > > > > > Looking closer at it now, I'm fairly certain that nothing in the > > > > existing codebase is expecting these calls to be refcounted. The only > > > > real question is whether someone is already doing something to ensure > > > > prepare()/unprepare() match and enabled()/disable() match. I would say > > > > that, even if there is something else ensuring that things match, > > > > there's enough complexity that adding an extra bool and an extra > > > > double-check here is a good idea. Let's add a drm_warn() to let people > > > > know that it's considered a minor error to take advantage of > > > > drm_panel's double-checking but we'll still make things work fine. > > > > > > I'm ok with this, if we follow-up in a couple of releases and remove it > > > and all the calls. > > > > > > Could you add a TODO item so that we can keep a track of it? A follow-up > > > is fine if you don't send a new version of that series. > > > > By this, I think you mean to add a "TODO" comment inline in the code? > > No, sorry, I meant an entry in our TODO list: Documentation/gpu/todo.rst > > > Also: I was thinking that we'd keep the check in "drm_panel.c" with > > the warning message indefinitely. You think it should be eventually > > removed? If we are truly thinking of removing it eventually, this > > feels like it should be a more serious warning message like a WARN(1, > > ...) to make it really obvious to people that they're relying on > > behavior that will eventually go away. > > Yeah, it really feels like this is cargo-cult to me. Your approach seems > like a good short-term thing to do to warn everyone but eventually we'll > want it to go away. > > So promoting it to a WARN could be a good thing, or let's say we do a > drm_warn for now, WARN next release, and gone in two? > > Maxime
Re: [PATCH v6 0/3] Add sync object UAPI support to VirtIO-GPU driver
On 7/29/23 01:03, Gurchetan Singh wrote: > On Wed, Jul 19, 2023 at 11:58 AM Dmitry Osipenko < > dmitry.osipe...@collabora.com> wrote: > >> 27.06.2023 20:16, Rob Clark пишет: >> ... Now these are just suggestions, and while I think they are good, you >> can safely ignore them. But there's also the DRM requirements, which state "userspace side must >> be fully reviewed and tested to the standards of that user-space >> project.". So I think to meet the minimum requirements, I think we should >> at-least have one of the following (not all, just one) reviewed: 1) venus using the new uapi 2) gfxstream vk using the new uapi 3) amdgpu nctx out of "draft" mode and using the new uapi. 4) virtio-intel using new uapi 5) turnip using your new uapi >>> >>> forgot to mention this earlier, but >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23533 >>> >>> Dmitry, you can also add, if you haven't already: >>> >>> Tested-by: Rob Clark >> >> Gurchetan, Turnip Mesa virtio support is ready to be merged upstream, >> it's using this new syncobj UAPI. Could you please give yours r-b if you >> don't have objections? >> > > Given that Turnip native contexts are reviewed using this UAPI, your change > does now meet the requirements and is ready to merge. > > One thing I noticed is you might need explicit padding between > `num_out_syncobjs` and `in_syncobjs`. Otherwise, feel free to add my > acked-by. The padding looks okay as-as, all the struct size and u64s are properly aligned. I'll merge the patch soon, thanks. -- Best regards, Dmitry
Re: [PATCH -next] drm/amdgpu: Remove a lot of unnecessary ternary operators
On 7/31/23 6:26 AM, Ruan Jinjie wrote: Ther are many ternary operators, the true or false judgement of which is unnecessary in C language semantics. Signed-off-by: Ruan Jinjie --- snip data->registry_data.avfs_support = - hwmgr->feature_mask & PP_AVFS_MASK ? true : false; + hwmgr->feature_mask & PP_AVFS_MASK; data->registry_data.led_dpm_enabled = 1; These are not equivalent, consider 0x & 0x1000 != 1 Tom
Re: [PATCH -next] drm/amdgpu: Remove a lot of unnecessary ternary operators
On 7/31/2023 8:26 AM, Ruan Jinjie wrote:
Ther are many ternary operators, the true or false judgement
of which is unnecessary in C language semantics.
s/Ther/There/
Unnecessary; sure. But don't they improve the readability quite a bit?
Signed-off-by: Ruan Jinjie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 2 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c| 2 +-
.../drm/amd/display/dc/dce/dce_link_encoder.c | 4 +---
.../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c| 6 +++---
.../amd/pm/powerplay/hwmgr/smu7_powertune.c| 2 +-
.../drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 18 +++---
.../amd/pm/powerplay/smumgr/polaris10_smumgr.c | 2 +-
.../drm/amd/pm/powerplay/smumgr/vegam_smumgr.c | 7 +++
13 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index b582b83c4984..38ccec913f00 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -460,7 +460,7 @@ bool amdgpu_get_bios(struct amdgpu_device *adev)
return false;
success:
- adev->is_atom_fw = (adev->asic_type >= CHIP_VEGA10) ? true : false;
+ adev->is_atom_fw = adev->asic_type >= CHIP_VEGA10;
return true;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
index 79791379fc2b..df4440c21bbf 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
@@ -479,7 +479,7 @@ static int jpeg_v3_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
if (enable) {
if (!jpeg_v3_0_is_idle(handle))
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
index a707d407fbd0..3eb3dcd56b57 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
@@ -626,7 +626,7 @@ static int jpeg_v4_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
if (enable) {
if (!jpeg_v4_0_is_idle(handle))
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
index ce2b22f7e4e4..153731d6ce8b 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
@@ -785,7 +785,7 @@ static int jpeg_v4_0_3_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
int i;
for (i = 0; i < adev->jpeg.num_jpeg_inst; ++i) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index b76ba21b5a89..9b662b105cc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -2095,7 +2095,7 @@ static int vcn_v3_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
int i;
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index 6089c7deba8a..7c486745bece 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1918,7 +1918,7 @@ static int vcn_v4_0_wait_for_idle(void *handle)
static int vcn_v4_0_set_clockgating_state(void *handle, enum
amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
int i;
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
index 550ac040b4be..e62472e6e7b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
+++
[PATCH 6/6] accel/ivpu: Add initial support for VPU 4
Add support VPU 4 - new generation of VPU IP with various
hardware design improvements. From driver point of view, it differs
in register set, initialization process and MMU memory ranges.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Co-developed-by: Karol Wachowski
Signed-off-by: Karol Wachowski
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Makefile |1 +
drivers/accel/ivpu/ivpu_drv.c | 10 +-
drivers/accel/ivpu/ivpu_drv.h |5 +
drivers/accel/ivpu/ivpu_fw.c |2 +
drivers/accel/ivpu/ivpu_hw.h |1 +
drivers/accel/ivpu/ivpu_hw_40xx.c | 1178 +
drivers/accel/ivpu/ivpu_hw_40xx_reg.h | 267 ++
7 files changed, 1462 insertions(+), 2 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_hw_40xx.c
create mode 100644 drivers/accel/ivpu/ivpu_hw_40xx_reg.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 3179e146e173..e4328b430564 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -8,6 +8,7 @@ intel_vpu-y := \
ivpu_fw_log.o \
ivpu_gem.o \
ivpu_hw_37xx.o \
+ ivpu_hw_40xx.o \
ivpu_ipc.o \
ivpu_job.o \
ivpu_jsm_msg.o \
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 3da15890bc59..ba79f397c9e8 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -501,8 +501,13 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->pm)
return -ENOMEM;
- vdev->hw->ops = _hw_37xx_ops;
- vdev->hw->dma_bits = 38;
+ if (ivpu_hw_gen(vdev) >= IVPU_HW_40XX) {
+ vdev->hw->ops = _hw_40xx_ops;
+ vdev->hw->dma_bits = 48;
+ } else {
+ vdev->hw->ops = _hw_37xx_ops;
+ vdev->hw->dma_bits = 38;
+ }
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_USER_CONTEXT_MIN_SSID;
@@ -629,6 +634,7 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
static struct pci_device_id ivpu_pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_LNL) },
{ }
};
MODULE_DEVICE_TABLE(pci, ivpu_pci_ids);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 5808a4e6bb6d..9e8c075fe9ef 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -23,8 +23,10 @@
#define DRIVER_DATE "20230117"
#define PCI_DEVICE_ID_MTL 0x7d1d
+#define PCI_DEVICE_ID_LNL 0x643e
#define IVPU_HW_37XX 37
+#define IVPU_HW_40XX 40
#define IVPU_GLOBAL_CONTEXT_MMU_SSID 0
/* SSID 1 is used by the VPU to represent invalid context */
@@ -78,6 +80,7 @@ struct ivpu_wa_table {
bool clear_runtime_mem;
bool d3hot_after_power_off;
bool interrupt_clear_with_0;
+ bool disable_clock_relinquish;
};
struct ivpu_hw_info;
@@ -163,6 +166,8 @@ static inline int ivpu_hw_gen(struct ivpu_device *vdev)
switch (ivpu_device_id(vdev)) {
case PCI_DEVICE_ID_MTL:
return IVPU_HW_37XX;
+ case PCI_DEVICE_ID_LNL:
+ return IVPU_HW_40XX;
default:
ivpu_err(vdev, "Unknown VPU device\n");
return 0;
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 7e75439dec60..9827ea4d7b83 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -51,6 +51,8 @@ static struct {
{ IVPU_HW_37XX, "vpu_37xx.bin" },
{ IVPU_HW_37XX, "mtl_vpu.bin" },
{ IVPU_HW_37XX, "intel/vpu/vpu_37xx_v0.0.bin" },
+ { IVPU_HW_40XX, "vpu_40xx.bin" },
+ { IVPU_HW_40XX, "intel/vpu/vpu_40xx_v0.0.bin" },
};
static int ivpu_fw_request(struct ivpu_device *vdev)
diff --git a/drivers/accel/ivpu/ivpu_hw.h b/drivers/accel/ivpu/ivpu_hw.h
index 69e52d21cd10..ab341237bcf9 100644
--- a/drivers/accel/ivpu/ivpu_hw.h
+++ b/drivers/accel/ivpu/ivpu_hw.h
@@ -60,6 +60,7 @@ struct ivpu_hw_info {
};
extern const struct ivpu_hw_ops ivpu_hw_37xx_ops;
+extern const struct ivpu_hw_ops ivpu_hw_40xx_ops;
static inline int ivpu_hw_info_init(struct ivpu_device *vdev)
{
diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c
b/drivers/accel/ivpu/ivpu_hw_40xx.c
new file mode 100644
index ..32e018c266bd
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_hw_40xx.c
@@ -0,0 +1,1178 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020-2023 Intel Corporation
+ */
+
+#include "ivpu_drv.h"
+#include "ivpu_fw.h"
+#include "ivpu_hw.h"
+#include "ivpu_hw_40xx_reg.h"
+#include "ivpu_hw_reg_io.h"
+#include "ivpu_ipc.h"
+#include "ivpu_mmu.h"
+#include "ivpu_pm.h"
+
+#include
+
+#define TILE_MAX_NUM 6
+#define TILE_MAX_MASK0x3f
+
[PATCH 5/6] accel/ivpu: Refactor memory ranges logic
From: Karol Wachowski
Add new dma range and change naming convention for virtual address
memory ranges managed by KMD.
New available ranges are named as follows:
* global range - global context accessible by FW
* aliased range - user context accessible by FW
* dma range - user context accessible by DMA
* shave range - user context accessible by shaves
* global shave range - global context accessible by shave nn
Signed-off-by: Karol Wachowski
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 4 ++--
drivers/accel/ivpu/ivpu_fw.c | 18 --
drivers/accel/ivpu/ivpu_gem.c | 10 ++
drivers/accel/ivpu/ivpu_hw.h | 9 -
drivers/accel/ivpu/ivpu_hw_37xx.c | 9 -
drivers/accel/ivpu/ivpu_mmu_context.c | 8
include/uapi/drm/ivpu_accel.h | 5 -
7 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index d33eb17007bf..3da15890bc59 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -122,7 +122,7 @@ static int ivpu_get_capabilities(struct ivpu_device *vdev,
struct drm_ivpu_param
args->value = 0;
break;
case DRM_IVPU_CAP_DMA_MEMORY_RANGE:
- args->value = 0;
+ args->value = 1;
break;
default:
return -EINVAL;
@@ -160,7 +160,7 @@ static int ivpu_get_param_ioctl(struct drm_device *dev,
void *data, struct drm_f
args->value = ivpu_get_context_count(vdev);
break;
case DRM_IVPU_PARAM_CONTEXT_BASE_ADDRESS:
- args->value = vdev->hw->ranges.user_low.start;
+ args->value = vdev->hw->ranges.user.start;
break;
case DRM_IVPU_PARAM_CONTEXT_PRIORITY:
args->value = file_priv->priority;
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 7caf90a169a3..7e75439dec60 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -204,7 +204,7 @@ static int ivpu_fw_update_global_range(struct ivpu_device
*vdev)
return -EINVAL;
}
- ivpu_hw_init_range(>hw->ranges.global_low, start, size);
+ ivpu_hw_init_range(>hw->ranges.global, start, size);
return 0;
}
@@ -245,7 +245,7 @@ static int ivpu_fw_mem_init(struct ivpu_device *vdev)
}
if (fw->shave_nn_size) {
- fw->mem_shave_nn = ivpu_bo_alloc_internal(vdev,
vdev->hw->ranges.global_high.start,
+ fw->mem_shave_nn = ivpu_bo_alloc_internal(vdev,
vdev->hw->ranges.shave.start,
fw->shave_nn_size,
DRM_IVPU_BO_UNCACHED);
if (!fw->mem_shave_nn) {
ivpu_err(vdev, "Failed to allocate shavenn buffer\n");
@@ -443,9 +443,9 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev,
struct vpu_boot_params
* Uncached region of VPU address space, covers IPC buffers, job queues
* and log buffers, programmable to L2$ Uncached by VPU MTRR
*/
- boot_params->shared_region_base = vdev->hw->ranges.global_low.start;
- boot_params->shared_region_size = vdev->hw->ranges.global_low.end -
- vdev->hw->ranges.global_low.start;
+ boot_params->shared_region_base = vdev->hw->ranges.global.start;
+ boot_params->shared_region_size = vdev->hw->ranges.global.end -
+ vdev->hw->ranges.global.start;
boot_params->ipc_header_area_start = ipc_mem_rx->vpu_addr;
boot_params->ipc_header_area_size = ipc_mem_rx->base.size / 2;
@@ -453,10 +453,8 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev,
struct vpu_boot_params
boot_params->ipc_payload_area_start = ipc_mem_rx->vpu_addr +
ipc_mem_rx->base.size / 2;
boot_params->ipc_payload_area_size = ipc_mem_rx->base.size / 2;
- boot_params->global_aliased_pio_base =
- vdev->hw->ranges.global_aliased_pio.start;
- boot_params->global_aliased_pio_size =
- ivpu_hw_range_size(>hw->ranges.global_aliased_pio);
+ boot_params->global_aliased_pio_base = vdev->hw->ranges.user.start;
+ boot_params->global_aliased_pio_size =
ivpu_hw_range_size(>hw->ranges.user);
/* Allow configuration for L2C_PAGE_TABLE with boot param value */
boot_params->autoconfig = 1;
@@ -464,7 +462,7 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev,
struct vpu_boot_params
/* Enable L2 cache for first 2GB of high memory */
boot_params->cache_defaults[VPU_BOOT_L2_CACHE_CFG_NN].use = 1;
boot_params->cache_defaults[VPU_BOOT_L2_CACHE_CFG_NN].cfg =
- ADDR_TO_L2_CACHE_CFG(vdev->hw->ranges.global_high.start);
+
[PATCH 4/6] accel/ivpu: Add param ioctl to identify capabilities
Add DRM_IVPU_PARAM_CAPABILITIES ioctl to query driver capabilities.
For now use it for identify metric streamer and new dma memory range
features. Currently upstream version of intel_vpu does not have those,
they will be added it the future.
Reviewed-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 19 +++
include/uapi/drm/ivpu_accel.h | 4
2 files changed, 23 insertions(+)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index fad607dbb2c6..d33eb17007bf 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -115,6 +115,22 @@ void ivpu_file_priv_put(struct ivpu_file_priv **link)
kref_put(_priv->ref, file_priv_release);
}
+static int ivpu_get_capabilities(struct ivpu_device *vdev, struct
drm_ivpu_param *args)
+{
+ switch (args->index) {
+ case DRM_IVPU_CAP_METRIC_STREAMER:
+ args->value = 0;
+ break;
+ case DRM_IVPU_CAP_DMA_MEMORY_RANGE:
+ args->value = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int ivpu_get_param_ioctl(struct drm_device *dev, void *data, struct
drm_file *file)
{
struct ivpu_file_priv *file_priv = file->driver_priv;
@@ -174,6 +190,9 @@ static int ivpu_get_param_ioctl(struct drm_device *dev,
void *data, struct drm_f
case DRM_IVPU_PARAM_SKU:
args->value = vdev->hw->sku;
break;
+ case DRM_IVPU_PARAM_CAPABILITIES:
+ ret = ivpu_get_capabilities(vdev, args);
+ break;
default:
ret = -EINVAL;
break;
diff --git a/include/uapi/drm/ivpu_accel.h b/include/uapi/drm/ivpu_accel.h
index 839820aed87e..3e99b74eef04 100644
--- a/include/uapi/drm/ivpu_accel.h
+++ b/include/uapi/drm/ivpu_accel.h
@@ -60,6 +60,7 @@ extern "C" {
#define DRM_IVPU_PARAM_UNIQUE_INFERENCE_ID 10
#define DRM_IVPU_PARAM_TILE_CONFIG 11
#define DRM_IVPU_PARAM_SKU 12
+#define DRM_IVPU_PARAM_CAPABILITIES13
#define DRM_IVPU_PLATFORM_TYPE_SILICON 0
@@ -68,6 +69,9 @@ extern "C" {
#define DRM_IVPU_CONTEXT_PRIORITY_FOCUS2
#define DRM_IVPU_CONTEXT_PRIORITY_REALTIME 3
+#define DRM_IVPU_CAP_METRIC_STREAMER 1
+#define DRM_IVPU_CAP_DMA_MEMORY_RANGE 2
+
/**
* struct drm_ivpu_param - Get/Set VPU parameters
*/
--
2.25.1
[PATCH 3/6] accel/ivpu: Switch to generation based FW names
From: Jacek Lawrynowicz
Use VPU IP generation for naming FW instead of the platform name.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_fw.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 317716482a15..7caf90a169a3 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -43,12 +43,18 @@ static char *ivpu_firmware;
module_param_named_unsafe(firmware, ivpu_firmware, charp, 0644);
MODULE_PARM_DESC(firmware, "VPU firmware binary in /lib/firmware/..");
+/* TODO: Remove mtl_vpu.bin from names after transition to generation based FW
names */
+static struct {
+ int gen;
+ const char *name;
+} fw_names[] = {
+ { IVPU_HW_37XX, "vpu_37xx.bin" },
+ { IVPU_HW_37XX, "mtl_vpu.bin" },
+ { IVPU_HW_37XX, "intel/vpu/vpu_37xx_v0.0.bin" },
+};
+
static int ivpu_fw_request(struct ivpu_device *vdev)
{
- static const char * const fw_names[] = {
- "mtl_vpu.bin",
- "intel/vpu/mtl_vpu_v0.0.bin"
- };
int ret = -ENOENT;
int i;
@@ -60,9 +66,12 @@ static int ivpu_fw_request(struct ivpu_device *vdev)
}
for (i = 0; i < ARRAY_SIZE(fw_names); i++) {
- ret = firmware_request_nowarn(>fw->file, fw_names[i],
vdev->drm.dev);
+ if (fw_names[i].gen != ivpu_hw_gen(vdev))
+ continue;
+
+ ret = firmware_request_nowarn(>fw->file,
fw_names[i].name, vdev->drm.dev);
if (!ret) {
- vdev->fw->name = fw_names[i];
+ vdev->fw->name = fw_names[i].name;
return 0;
}
}
--
2.25.1
[PATCH 1/6] accel/ivpu: Rename sources to use generation based names
From: Jacek Lawrynowicz
Given that VPU generation can be used by multiple platforms, driver should
use VPU IP generation in names instead of a platform names.
Change naming for sources files.
Use 37XX format, where:
3 - major VPU IP generation version
7 - minor VPU IP generation version
XX - postfix indicating this is a architecture and not marketing name
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Makefile | 2 +-
drivers/accel/ivpu/{ivpu_hw_mtl.c => ivpu_hw_37xx.c} | 2 +-
drivers/accel/ivpu/{ivpu_hw_mtl_reg.h => ivpu_hw_37xx_reg.h} | 0
drivers/accel/ivpu/ivpu_mmu.c| 2 +-
4 files changed, 3 insertions(+), 3 deletions(-)
rename drivers/accel/ivpu/{ivpu_hw_mtl.c => ivpu_hw_37xx.c} (99%)
rename drivers/accel/ivpu/{ivpu_hw_mtl_reg.h => ivpu_hw_37xx_reg.h} (100%)
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 9858d9fea36e..3179e146e173 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -7,7 +7,7 @@ intel_vpu-y := \
ivpu_fw.o \
ivpu_fw_log.o \
ivpu_gem.o \
- ivpu_hw_mtl.o \
+ ivpu_hw_37xx.o \
ivpu_ipc.o \
ivpu_job.o \
ivpu_jsm_msg.o \
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl.c
b/drivers/accel/ivpu/ivpu_hw_37xx.c
similarity index 99%
rename from drivers/accel/ivpu/ivpu_hw_mtl.c
rename to drivers/accel/ivpu/ivpu_hw_37xx.c
index f1211e74017d..495be81840ac 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@ -5,7 +5,7 @@
#include "ivpu_drv.h"
#include "ivpu_fw.h"
-#include "ivpu_hw_mtl_reg.h"
+#include "ivpu_hw_37xx_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl_reg.h
b/drivers/accel/ivpu/ivpu_hw_37xx_reg.h
similarity index 100%
rename from drivers/accel/ivpu/ivpu_hw_mtl_reg.h
rename to drivers/accel/ivpu/ivpu_hw_37xx_reg.h
diff --git a/drivers/accel/ivpu/ivpu_mmu.c b/drivers/accel/ivpu/ivpu_mmu.c
index 53878e77aad3..b64eb094343b 100644
--- a/drivers/accel/ivpu/ivpu_mmu.c
+++ b/drivers/accel/ivpu/ivpu_mmu.c
@@ -7,7 +7,7 @@
#include
#include "ivpu_drv.h"
-#include "ivpu_hw_mtl_reg.h"
+#include "ivpu_hw_37xx_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
--
2.25.1
[PATCH 2/6] accel/ivpu: Use generation based function and registers names
From: Jacek Lawrynowicz
Given that VPU generation can be used by multiple platforms, driver should
use VPU IP generation names instead of a platform names.
Change naming for functions and registries.
Use 37XX format, where:
3 - major VPU IP generation version
7 - minor VPU IP generation version
XX - postfix indicating this is a architecture and not marketing name
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 6 +-
drivers/accel/ivpu/ivpu_drv.h | 18 +-
drivers/accel/ivpu/ivpu_hw.h | 2 +-
drivers/accel/ivpu/ivpu_hw_37xx.c | 476 +-
drivers/accel/ivpu/ivpu_hw_37xx_reg.h | 392 ++---
drivers/accel/ivpu/ivpu_mmu.c | 82 ++---
6 files changed, 492 insertions(+), 484 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 815dd9b588e9..fad607dbb2c6 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -443,8 +443,8 @@ static int ivpu_pci_init(struct ivpu_device *vdev)
/* Clear any pending errors */
pcie_capability_clear_word(pdev, PCI_EXP_DEVSTA, 0x3f);
- /* VPU MTL does not require PCI spec 10m D3hot delay */
- if (ivpu_is_mtl(vdev))
+ /* VPU 37XX does not require 10m D3hot delay */
+ if (ivpu_hw_gen(vdev) == IVPU_HW_37XX)
pdev->d3hot_delay = 0;
ret = pcim_enable_device(pdev);
@@ -482,7 +482,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->pm)
return -ENOMEM;
- vdev->hw->ops = _hw_mtl_ops;
+ vdev->hw->ops = _hw_37xx_ops;
vdev->hw->dma_bits = 38;
vdev->platform = IVPU_PLATFORM_INVALID;
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 8fe8cda2e39d..5808a4e6bb6d 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -24,6 +24,8 @@
#define PCI_DEVICE_ID_MTL 0x7d1d
+#define IVPU_HW_37XX 37
+
#define IVPU_GLOBAL_CONTEXT_MMU_SSID 0
/* SSID 1 is used by the VPU to represent invalid context */
#define IVPU_USER_CONTEXT_MIN_SSID 2
@@ -146,11 +148,6 @@ void ivpu_file_priv_put(struct ivpu_file_priv **link);
int ivpu_boot(struct ivpu_device *vdev);
int ivpu_shutdown(struct ivpu_device *vdev);
-static inline bool ivpu_is_mtl(struct ivpu_device *vdev)
-{
- return to_pci_dev(vdev->drm.dev)->device == PCI_DEVICE_ID_MTL;
-}
-
static inline u8 ivpu_revision(struct ivpu_device *vdev)
{
return to_pci_dev(vdev->drm.dev)->revision;
@@ -161,6 +158,17 @@ static inline u16 ivpu_device_id(struct ivpu_device *vdev)
return to_pci_dev(vdev->drm.dev)->device;
}
+static inline int ivpu_hw_gen(struct ivpu_device *vdev)
+{
+ switch (ivpu_device_id(vdev)) {
+ case PCI_DEVICE_ID_MTL:
+ return IVPU_HW_37XX;
+ default:
+ ivpu_err(vdev, "Unknown VPU device\n");
+ return 0;
+ }
+}
+
static inline struct ivpu_device *to_ivpu_device(struct drm_device *dev)
{
return container_of(dev, struct ivpu_device, drm);
diff --git a/drivers/accel/ivpu/ivpu_hw.h b/drivers/accel/ivpu/ivpu_hw.h
index 0393901be492..335b7f707752 100644
--- a/drivers/accel/ivpu/ivpu_hw.h
+++ b/drivers/accel/ivpu/ivpu_hw.h
@@ -60,7 +60,7 @@ struct ivpu_hw_info {
int dma_bits;
};
-extern const struct ivpu_hw_ops ivpu_hw_mtl_ops;
+extern const struct ivpu_hw_ops ivpu_hw_37xx_ops;
static inline int ivpu_hw_info_init(struct ivpu_device *vdev)
{
diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c
b/drivers/accel/ivpu/ivpu_hw_37xx.c
index 495be81840ac..2cda8e4c4a3d 100644
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@ -39,34 +39,34 @@
#define PLL_TIMEOUT_US (1500 * USEC_PER_MSEC)
#define IDLE_TIMEOUT_US (500 * USEC_PER_MSEC)
-#define ICB_0_IRQ_MASK ((REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0,
HOST_IPC_FIFO_INT)) | \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_0_INT))
| \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_1_INT))
| \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_2_INT))
| \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0,
NOC_FIREWALL_INT)) | \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0,
CPU_INT_REDIRECT_0_INT)) | \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0,
CPU_INT_REDIRECT_1_INT)))
-
-#define ICB_1_IRQ_MASK ((REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_1,
CPU_INT_REDIRECT_2_INT)) | \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_1,
CPU_INT_REDIRECT_3_INT)) | \
- (REG_FLD(MTL_VPU_HOST_SS_ICB_STATUS_1,
CPU_INT_REDIRECT_4_INT)))
+#define ICB_0_IRQ_MASK ((REG_FLD(VPU_37XX_HOST_SS_ICB_STATUS_0,
HOST_IPC_FIFO_INT)) | \
+
[PATCH 0/6] accel/ivpu: Refactor driver code and support new hardware
Various code additions and refactoring in order to add support for VPU IP 4,
which be included in Intel Lunar Lake CPUs.
Jacek Lawrynowicz (3):
accel/ivpu: Rename sources to use generation based names
accel/ivpu: Use generation based function and registers names
accel/ivpu: Switch to generation based FW names
Karol Wachowski (1):
accel/ivpu: Refactor memory ranges logic
Stanislaw Gruszka (2):
accel/ivpu: Add param ioctl to identify capabilities
accel/ivpu: Add initial support for VPU 4
drivers/accel/ivpu/Makefile |3 +-
drivers/accel/ivpu/ivpu_drv.c | 35 +-
drivers/accel/ivpu/ivpu_drv.h | 23 +-
drivers/accel/ivpu/ivpu_fw.c | 41 +-
drivers/accel/ivpu/ivpu_gem.c | 10 +-
drivers/accel/ivpu/ivpu_hw.h | 12 +-
.../ivpu/{ivpu_hw_mtl.c => ivpu_hw_37xx.c}| 485 ---
drivers/accel/ivpu/ivpu_hw_37xx_reg.h | 281
drivers/accel/ivpu/ivpu_hw_40xx.c | 1178 +
drivers/accel/ivpu/ivpu_hw_40xx_reg.h | 267
drivers/accel/ivpu/ivpu_hw_mtl_reg.h | 281
drivers/accel/ivpu/ivpu_mmu.c | 84 +-
drivers/accel/ivpu/ivpu_mmu_context.c |8 +-
include/uapi/drm/ivpu_accel.h |9 +-
14 files changed, 2109 insertions(+), 608 deletions(-)
rename drivers/accel/ivpu/{ivpu_hw_mtl.c => ivpu_hw_37xx.c} (52%)
create mode 100644 drivers/accel/ivpu/ivpu_hw_37xx_reg.h
create mode 100644 drivers/accel/ivpu/ivpu_hw_40xx.c
create mode 100644 drivers/accel/ivpu/ivpu_hw_40xx_reg.h
delete mode 100644 drivers/accel/ivpu/ivpu_hw_mtl_reg.h
--
2.25.1
Re: [PATCH v7 4/4] drm/mediatek: Add DSI support for mt8188 vdosys0
Re: [PATCH 1/2] drm/exec: use unique instead of local label
On Mon, 31 Jul 2023 08:31:19 -0700
Nathan Chancellor wrote:
> On Mon, Jul 31, 2023 at 02:36:24PM +0200, Christian König wrote:
> > GCC forbids to jump to labels in loop conditions and a new clang
> > check stumbled over this.
> >
> > So instead using a local label inside the loop condition use an
> > unique label outside of it.
> >
> > Fixes: commit 09593216bff1 ("drm: execution context for GEM buffers v7")
> > Link: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1890
> > Link:
> > https://github.com/llvm/llvm-project/commit/20219106060208f0c2f5d096eb3aed7b712f5067
> > Reported-by: Nathan Chancellor
> > Reported-by: Naresh Kamboju
> > CC: Boris Brezillon
Reviewed-by: Boris Brezillon
> > Signed-off-by: Christian König
>
> Passes my build tests and I inspected the preprocessed output to make
> sure it should work. I ran the KUnit tests, which all pass (although [1]
> is needed to fix a tangential issue):
>
> Tested-by: Nathan Chancellor
>
> Thanks for fixing this!
>
> [1]: https://lore.kernel.org/20230728183400.306193-1-arthurgri...@riseup.net/
>
> > ---
> > include/drm/drm_exec.h | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/drm/drm_exec.h b/include/drm/drm_exec.h
> > index 73205afec162..e0462361adf9 100644
> > --- a/include/drm/drm_exec.h
> > +++ b/include/drm/drm_exec.h
> > @@ -3,6 +3,7 @@
> > #ifndef __DRM_EXEC_H__
> > #define __DRM_EXEC_H__
> >
> > +#include
> > #include
> >
> > #define DRM_EXEC_INTERRUPTIBLE_WAITBIT(0)
> > @@ -74,13 +75,12 @@ struct drm_exec {
> > * Since labels can't be defined local to the loops body we use a jump
> > pointer
> > * to make sure that the retry is only used from within the loops body.
> > */
> > -#define drm_exec_until_all_locked(exec)\
> > - for (void *__drm_exec_retry_ptr; ({ \
> > - __label__ __drm_exec_retry; \
> > -__drm_exec_retry: \
> > - __drm_exec_retry_ptr = &&__drm_exec_retry; \
> > - (void)__drm_exec_retry_ptr; \
> > - drm_exec_cleanup(exec); \
> > +#define drm_exec_until_all_locked(exec)
> > \
> > +__PASTE(__drm_exec_, __LINE__):
> > \
> > + for (void *__drm_exec_retry_ptr; ({ \
> > + __drm_exec_retry_ptr = &&__PASTE(__drm_exec_, __LINE__);\
> > + (void)__drm_exec_retry_ptr; \
> > + drm_exec_cleanup(exec); \
> > });)
> >
> > /**
> > --
> > 2.34.1
> >
> >
Re: (subset) [PATCH v4 0/3] Add startek-kd070fhfid015 display support
Hi, On Mon, 31 Jul 2023 17:08:55 +0200, Alexandre Mergnat wrote: > Add the support of the Startek KD070FHFID015 panel. > It's a 7-inch TFT LCD display with a resolution of 1024 x 600 pixels. > > I use this display plugged to my mt8365-evk board. > > This serie come from a bigger one [1]. Then I addressed the previous > comments for the related commits here. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/3] dt-bindings: display: panel: add startek kd070fhfid015 support https://cgit.freedesktop.org/drm/drm-misc/commit/?id=5ede23d12b442750ba1298913cf3ce572f1b79d3 [2/3] drm/panel: Support for startek-kd070fhfid015 MIPI-DSI panel https://cgit.freedesktop.org/drm/drm-misc/commit/?id=69312a77cd13e36f87378dfe83480b671ebf9216 -- Neil
Re: [PATCH 1/2] drm/exec: use unique instead of local label
On Mon, Jul 31, 2023 at 02:36:24PM +0200, Christian König wrote:
> GCC forbids to jump to labels in loop conditions and a new clang
> check stumbled over this.
>
> So instead using a local label inside the loop condition use an
> unique label outside of it.
>
> Fixes: commit 09593216bff1 ("drm: execution context for GEM buffers v7")
> Link: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
> Link: https://github.com/ClangBuiltLinux/linux/issues/1890
> Link:
> https://github.com/llvm/llvm-project/commit/20219106060208f0c2f5d096eb3aed7b712f5067
> Reported-by: Nathan Chancellor
> Reported-by: Naresh Kamboju
> CC: Boris Brezillon
> Signed-off-by: Christian König
Passes my build tests and I inspected the preprocessed output to make
sure it should work. I ran the KUnit tests, which all pass (although [1]
is needed to fix a tangential issue):
Tested-by: Nathan Chancellor
Thanks for fixing this!
[1]: https://lore.kernel.org/20230728183400.306193-1-arthurgri...@riseup.net/
> ---
> include/drm/drm_exec.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/drm/drm_exec.h b/include/drm/drm_exec.h
> index 73205afec162..e0462361adf9 100644
> --- a/include/drm/drm_exec.h
> +++ b/include/drm/drm_exec.h
> @@ -3,6 +3,7 @@
> #ifndef __DRM_EXEC_H__
> #define __DRM_EXEC_H__
>
> +#include
> #include
>
> #define DRM_EXEC_INTERRUPTIBLE_WAIT BIT(0)
> @@ -74,13 +75,12 @@ struct drm_exec {
> * Since labels can't be defined local to the loops body we use a jump
> pointer
> * to make sure that the retry is only used from within the loops body.
> */
> -#define drm_exec_until_all_locked(exec) \
> - for (void *__drm_exec_retry_ptr; ({ \
> - __label__ __drm_exec_retry; \
> -__drm_exec_retry:\
> - __drm_exec_retry_ptr = &&__drm_exec_retry; \
> - (void)__drm_exec_retry_ptr; \
> - drm_exec_cleanup(exec); \
> +#define drm_exec_until_all_locked(exec)
> \
> +__PASTE(__drm_exec_, __LINE__):
> \
> + for (void *__drm_exec_retry_ptr; ({ \
> + __drm_exec_retry_ptr = &&__PASTE(__drm_exec_, __LINE__);\
> + (void)__drm_exec_retry_ptr; \
> + drm_exec_cleanup(exec); \
> });)
>
> /**
> --
> 2.34.1
>
>
[PATCH v4 1/3] dt-bindings: display: panel: add startek kd070fhfid015 support
The Startek KD070FHFID015 is a 7-inch TFT LCD display with a resolution
of 1024 x 600 pixels.
Reviewed-by: Conor Dooley
Signed-off-by: Alexandre Mergnat
---
.../display/panel/startek,kd070fhfid015.yaml | 69 ++
1 file changed, 69 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
new file mode 100644
index ..d817f998cddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/startek,kd070fhfid015.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Startek Electronic Technology Co. kd070fhfid015 7 inch TFT LCD panel
+
+maintainers:
+ - Alexandre Mergnat
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: startek,kd070fhfid015
+
+ enable-gpios: true
+
+ iovcc-supply:
+description: Reference to the regulator powering the panel IO pins.
+
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ reset-gpios: true
+
+ port: true
+
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - enable-gpios
+ - iovcc-supply
+ - reg
+ - reset-gpios
+ - port
+ - power-supply
+
+examples:
+ - |
+#include
+
+dsi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "startek,kd070fhfid015";
+reg = <0>;
+enable-gpios = < 67 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 20 GPIO_ACTIVE_HIGH>;
+iovcc-supply = <_vsim1_reg>;
+power-supply = <_lcm_reg>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.25.1
[PATCH v4 2/3] drm/panel: Support for startek-kd070fhfid015 MIPI-DSI panel
From: Guillaume La Roque
This driver support the Startek KD070FHFID015, which is a 7-inch TFT LCD
display using MIPI DSI interface.
Signed-off-by: Guillaume La Roque
Reviewed-by: Neil Armstrong
Signed-off-by: Alexandre Mergnat
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu/drm/panel/panel-startek-kd070fhfid015.c| 406 +
3 files changed, 418 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 203c0ef0bbfd..c45e877c22c1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -733,6 +733,17 @@ config DRM_PANEL_SONY_TULIP_TRULY_NT35521
NT35521 1280x720 video mode panel as found on Sony Xperia M4
Aqua phone.
+config DRM_PANEL_STARTEK_KD070FHFID015
+ tristate "STARTEK KD070FHFID015 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for STARTEK KD070FHFID015
DSI panel
+ based on RENESAS-R69429 controller. The pannel is a 7-inch TFT LCD
display
+ with a resolution of 1024 x 600 pixels. It provides a MIPI DSI
interface to
+ the host, a built-in LED backlight and touch controller.
+
config DRM_PANEL_TDO_TL070WSH30
tristate "TDO TL070WSH30 DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 30cf553c8d1d..f8b362091ce7 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) +=
panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) +=
panel-sony-tulip-truly-nt35521.o
+obj-$(CONFIG_DRM_PANEL_STARTEK_KD070FHFID015) += panel-startek-kd070fhfid015.o
obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
diff --git a/drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c
b/drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c
new file mode 100644
index ..6e77a2d71d81
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Copyright (C) 2016 Linaro Ltd
+ * Copyright (C) 2023 BayLibre, SAS
+ *
+ * Authors:
+ * - Vinay Simha BN
+ * - Sumit Semwal
+ * - Guillaume La Roque
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#define DSI_REG_MCAP 0xB0
+#define DSI_REG_IS 0xB3 /* Interface Setting */
+#define DSI_REG_IIS0xB4 /* Interface ID Setting */
+#define DSI_REG_CTRL 0xB6
+
+enum {
+ IOVCC = 0,
+ POWER = 1
+};
+
+struct stk_panel {
+ bool prepared;
+ const struct drm_display_mode *mode;
+ struct backlight_device *backlight;
+ struct drm_panel base;
+ struct gpio_desc *enable_gpio; /* Power IC supply enable */
+ struct gpio_desc *reset_gpio; /* External reset */
+ struct mipi_dsi_device *dsi;
+ struct regulator_bulk_data supplies[2];
+};
+
+static inline struct stk_panel *to_stk_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct stk_panel, base);
+}
+
+static int stk_panel_init(struct stk_panel *stk)
+{
+ struct mipi_dsi_device *dsi = stk->dsi;
+ struct device *dev = >dsi->dev;
+ int ret;
+
+ ret = mipi_dsi_dcs_soft_reset(dsi);
+ if (ret < 0) {
+ dev_err(dev, "failed to mipi_dsi_dcs_soft_reset: %d\n", ret);
+ return ret;
+ }
+ mdelay(5);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "failed to set exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(120);
+
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_MCAP, 0x04);
+
+ /* Interface setting, video mode */
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_IS, 0x14, 0x08, 0x00, 0x22,
0x00);
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_IIS, 0x0C, 0x00);
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_CTRL, 0x3A, 0xD3);
+
+ ret = mipi_dsi_dcs_set_display_brightness(dsi, 0x77);
+ if (ret < 0) {
+ dev_err(dev, "failed to write display brightness: %d\n", ret);
+ return ret;
+ }
+
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
+ MIPI_DCS_WRITE_MEMORY_START);
+
+ ret = mipi_dsi_dcs_set_pixel_format(dsi, 0x77);
+ if (ret < 0) {
+ dev_err(dev, "failed to set pixel format: %d\n", ret);
+ return
[PATCH v4 3/3] arm64: defconfig: enable STARTEK KD070FHFID015 panel
Build Startek KD070FHFID015 panel driver. This MIPI-DSI display can be used for the mt8365-evk board for example. Signed-off-by: Alexandre Mergnat --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0777bcae9104..cb24a3d1219b 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -816,6 +816,7 @@ CONFIG_DRM_PANEL_EDP=m CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m CONFIG_DRM_PANEL_RAYDIUM_RM67191=m CONFIG_DRM_PANEL_SITRONIX_ST7703=m +CONFIG_DRM_PANEL_STARTEK_KD070FHFID015=m CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m CONFIG_DRM_PANEL_VISIONOX_VTDR6130=m CONFIG_DRM_LONTIUM_LT8912B=m -- 2.25.1
[PATCH v4 0/3] Add startek-kd070fhfid015 display support
Add the support of the Startek KD070FHFID015 panel. It's a 7-inch TFT LCD display with a resolution of 1024 x 600 pixels. I use this display plugged to my mt8365-evk board. This serie come from a bigger one [1]. Then I addressed the previous comments for the related commits here. [1]: https://lore.kernel.org/all/20230220-display-v1-0-45cbc68e1...@baylibre.com/ Signed-off-by: Alexandre Mergnat --- Changes in v4: - Remove useless function: stk_panel_shutdown. - Align parenthesis for readability. - Link to v3: https://lore.kernel.org/r/20230711-startek_display-v3-0-dc847e6b3...@baylibre.com Changes in v3: - Remove spurious line. - Remove useless ops (enable and disable). - Remove brightness value init because it is set right after using mipi_dsi_dcs_get_display_brightness(...). - Link to v2: https://lore.kernel.org/r/20230711-startek_display-v2-0-87bc7bdec...@baylibre.com Changes in v2: - Replace "dcdc-gpio" by "enable-gpio" because this pin enable the Power IC supply. Also, this property come from panel-common. - Remove height-mm and width-mm since they are useless here. - Re-order elements in the stk_panel structure for readability. - Link to v1: https://lore.kernel.org/r/20230711-startek_display-v1-0-163917bed...@baylibre.com Changes in v1: - Fix typos in the driver. - Merge 2 regulators in one bulk variable in the driver. - Remove backlight enable/disable from the driver because it's already managed by the backlight core. - Move hardcoded values from function to the generic structure in the driver. - Remove unnecessary function (stk_panel_del). - Replace some functions by macro to increase the readability. - Link to parent serie: [1] --- Alexandre Mergnat (2): dt-bindings: display: panel: add startek kd070fhfid015 support arm64: defconfig: enable STARTEK KD070FHFID015 panel Guillaume La Roque (1): drm/panel: Support for startek-kd070fhfid015 MIPI-DSI panel .../display/panel/startek,kd070fhfid015.yaml | 69 arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile | 1 + .../gpu/drm/panel/panel-startek-kd070fhfid015.c| 406 + 5 files changed, 488 insertions(+) --- base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5 change-id: 20230711-startek_display-958d265f6baa Best regards, -- Alexandre Mergnat
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Mon, Jul 31, 2023 at 5:25 AM Helen Mae Koike Fornazier
wrote:
>
> Hello all,
>
> Thanks for your comments.
>
> On Friday, July 28, 2023 11:37 -03, Rob Clark wrote:
>
> > On Thu, Jul 27, 2023 at 10:26 PM Daniel Stone wrote:
> > >
> > > On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > > > > I did run into a bit of a chicken vs. egg problem with testing the "in
> > > > > tree" version (compared to earlier versions which kept most of the yml
> > > > > and scripts in a separate tree), is that it actually requires this
> > > > > commit to exist in the branch you want to run CI on. My earlier
> > > > > workaround of pulling the drm/ci commit in via
> > > > > ${branchname}-external-fixes no longer works.
> > > >
> > > > After unwinding some more gitlab repo settings that were for the
> > > > previous out-of-tree yml setup, I have this working.
> > > >
> > > > Tested-by: Rob Clark
> > > > Acked-by: Rob Clark
> > >
> > > And it's also:
> > > Acked-by: Daniel Stone
> > >
> > > It's been back and forth a few times by now and reviewed pretty
> > > heavily by all the people who are across the CI details. I think the
> > > next step is to answer all the workflow questions by actually getting
> > > it into trees and using it in anger. There was some discussion about
> > > whether this should come in from drm-misc, or the core DRM tree, or a
> > > completely separate pull, but I'm not sure what the conclusion was ...
> > > maintainers, thoughts?
> >
> > I'd prefer a separate pull, so that I could merge it into msm-next as
> > well without having to pull in all of drm-misc
>
> Should we create a drm-ci ?
I guess we can just wait and see how often it is that drm/ci updates
need to be merged into multiple driver trees. Hopefully most of the
drm/ci changes are just expectation file updates which should go via
driver tree. Maybe i-g-t uprevs, if they have a lot of expectation
changes would be something drivers would want to merge into their own
tree? But I guess we can see how it goes.
> >
> > Possibly some other driver trees would like to do similar?
> >
> > BR,
> > -R
>
> Also, please wait for v11, I have a few adjustments to make as pointer by
> some comments, and also regarding xfails list and how the configs should
> be organized (unless if you are fine merging this version and I can submit
> the adjustments later).
Ok
BR,
-R
> Thanks,
> Helen
>
Re: [PATCH] drm/amd/display: check attr flag before set cursor degamma on DCN3+
On 2023-07-31 04:35, Melissa Wen wrote:
> Don't set predefined degamma curve to cursor plane if the cursor
> attribute flag is not set. Applying a degamma curve to the cursor by
> default breaks userspace expectation. Checking the flag before
> performing any color transformation prevents too dark cursor gamma in
> DCN3+ on many Linux desktop environment (KDE Plasma, GNOME,
> wlroots-based, etc.) as reported at:
> - https://gitlab.freedesktop.org/drm/amd/-/issues/1513
>
> This is the same approach followed by DCN2 drivers where the issue is
> not present.
>
> Fixes: 03f54d7d3448 ("drm/amd/display: Add DCN3 DPP")
> Signed-off-by: Melissa Wen
Thanks. Good find.
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
> b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
> index e5b7ef7422b8..50dc83404644 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
> @@ -357,8 +357,11 @@ void dpp3_set_cursor_attributes(
> int cur_rom_en = 0;
>
> if (color_format == CURSOR_MODE_COLOR_PRE_MULTIPLIED_ALPHA ||
> - color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA)
> - cur_rom_en = 1;
> + color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA) {
> + if
> (cursor_attributes->attribute_flags.bits.ENABLE_CURSOR_DEGAMMA) {
> + cur_rom_en = 1;
> + }
> + }
>
> REG_UPDATE_3(CURSOR0_CONTROL,
> CUR0_MODE, color_format,
[PATCH] drivers: gpu: drm: nouveau: fix invalid variable name
This commit fixes logic error in function 'nvkm_dp_train':
argument of function nvkm_dp_train_link might be rate, not ret
Co-developed-by: Ivanov Mikhail
Signed-off-by: Konstantin Meskhidze
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
index 40c8ea43c..8740978ac 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
@@ -455,7 +455,7 @@ nvkm_dp_train(struct nvkm_outp *outp, u32 dataKBps)
if (atomic_read(>dp.lt.done)) {
for (rate = 0; rate < outp->dp.rates; rate++) {
if (outp->dp.rate[rate].rate == ior->dp.bw * 27000)
- return nvkm_dp_train_link(outp, ret);
+ return nvkm_dp_train_link(outp, rate);
}
WARN_ON(1);
return -EINVAL;
--
2.34.1
[PATCH v3 1/3] dt-bindings: display: panel: add startek kd070fhfid015 support
The Startek KD070FHFID015 is a 7-inch TFT LCD display with a resolution
of 1024 x 600 pixels.
Reviewed-by: Conor Dooley
Signed-off-by: Alexandre Mergnat
---
.../display/panel/startek,kd070fhfid015.yaml | 69 ++
1 file changed, 69 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
new file mode 100644
index ..d817f998cddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/startek,kd070fhfid015.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Startek Electronic Technology Co. kd070fhfid015 7 inch TFT LCD panel
+
+maintainers:
+ - Alexandre Mergnat
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: startek,kd070fhfid015
+
+ enable-gpios: true
+
+ iovcc-supply:
+description: Reference to the regulator powering the panel IO pins.
+
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ reset-gpios: true
+
+ port: true
+
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - enable-gpios
+ - iovcc-supply
+ - reg
+ - reset-gpios
+ - port
+ - power-supply
+
+examples:
+ - |
+#include
+
+dsi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "startek,kd070fhfid015";
+reg = <0>;
+enable-gpios = < 67 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 20 GPIO_ACTIVE_HIGH>;
+iovcc-supply = <_vsim1_reg>;
+power-supply = <_lcm_reg>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.25.1
[PATCH v3 3/3] arm64: defconfig: enable STARTEK KD070FHFID015 panel
Build Startek KD070FHFID015 panel driver. This MIPI-DSI display can be used for the mt8365-evk board for example. Signed-off-by: Alexandre Mergnat --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0777bcae9104..cb24a3d1219b 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -816,6 +816,7 @@ CONFIG_DRM_PANEL_EDP=m CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m CONFIG_DRM_PANEL_RAYDIUM_RM67191=m CONFIG_DRM_PANEL_SITRONIX_ST7703=m +CONFIG_DRM_PANEL_STARTEK_KD070FHFID015=m CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m CONFIG_DRM_PANEL_VISIONOX_VTDR6130=m CONFIG_DRM_LONTIUM_LT8912B=m -- 2.25.1
[PATCH v3 2/3] drm/panel: Support for startek-kd070fhfid015 MIPI-DSI panel
From: Guillaume La Roque
This driver support the Startek KD070FHFID015, which is a 7-inch TFT LCD
display using MIPI DSI interface.
Signed-off-by: Guillaume La Roque
Reviewed-by: Neil Armstrong
Signed-off-by: Alexandre Mergnat
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu/drm/panel/panel-startek-kd070fhfid015.c| 412 +
3 files changed, 424 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 203c0ef0bbfd..c45e877c22c1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -733,6 +733,17 @@ config DRM_PANEL_SONY_TULIP_TRULY_NT35521
NT35521 1280x720 video mode panel as found on Sony Xperia M4
Aqua phone.
+config DRM_PANEL_STARTEK_KD070FHFID015
+ tristate "STARTEK KD070FHFID015 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for STARTEK KD070FHFID015
DSI panel
+ based on RENESAS-R69429 controller. The pannel is a 7-inch TFT LCD
display
+ with a resolution of 1024 x 600 pixels. It provides a MIPI DSI
interface to
+ the host, a built-in LED backlight and touch controller.
+
config DRM_PANEL_TDO_TL070WSH30
tristate "TDO TL070WSH30 DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 30cf553c8d1d..f8b362091ce7 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) +=
panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) +=
panel-sony-tulip-truly-nt35521.o
+obj-$(CONFIG_DRM_PANEL_STARTEK_KD070FHFID015) += panel-startek-kd070fhfid015.o
obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
diff --git a/drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c
b/drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c
new file mode 100644
index ..1ed950195cdf
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Copyright (C) 2016 Linaro Ltd
+ * Copyright (C) 2023 BayLibre, SAS
+ *
+ * Authors:
+ * - Vinay Simha BN
+ * - Sumit Semwal
+ * - Guillaume La Roque
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#define DSI_REG_MCAP 0xB0
+#define DSI_REG_IS 0xB3 /* Interface Setting */
+#define DSI_REG_IIS0xB4 /* Interface ID Setting */
+#define DSI_REG_CTRL 0xB6
+
+enum {
+ IOVCC = 0,
+ POWER = 1
+};
+
+struct stk_panel {
+ bool prepared;
+ const struct drm_display_mode *mode;
+ struct backlight_device *backlight;
+ struct drm_panel base;
+ struct gpio_desc *enable_gpio; /* Power IC supply enable */
+ struct gpio_desc *reset_gpio; /* External reset */
+ struct mipi_dsi_device *dsi;
+ struct regulator_bulk_data supplies[2];
+};
+
+static inline struct stk_panel *to_stk_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct stk_panel, base);
+}
+
+static int stk_panel_init(struct stk_panel *stk)
+{
+ struct mipi_dsi_device *dsi = stk->dsi;
+ struct device *dev = >dsi->dev;
+ int ret;
+
+ ret = mipi_dsi_dcs_soft_reset(dsi);
+ if (ret < 0) {
+ dev_err(dev, "failed to mipi_dsi_dcs_soft_reset: %d\n", ret);
+ return ret;
+ }
+ mdelay(5);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "failed to set exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(120);
+
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_MCAP, 0x04);
+
+ /* Interface setting, video mode */
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_IS, 0x14, 0x08, 0x00, 0x22,
0x00);
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_IIS, 0x0C, 0x00);
+ mipi_dsi_generic_write_seq(dsi, DSI_REG_CTRL, 0x3A, 0xD3);
+
+ ret = mipi_dsi_dcs_set_display_brightness(dsi, 0x77);
+ if (ret < 0) {
+ dev_err(dev, "failed to write display brightness: %d\n", ret);
+ return ret;
+ }
+
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
+MIPI_DCS_WRITE_MEMORY_START);
+
+ ret = mipi_dsi_dcs_set_pixel_format(dsi, 0x77);
+ if (ret < 0) {
+ dev_err(dev, "failed to set pixel format: %d\n", ret);
+ return
[PATCH v3 0/3] Add startek-kd070fhfid015 display support
Add the support of the Startek KD070FHFID015 panel. It's a 7-inch TFT LCD display with a resolution of 1024 x 600 pixels. I use this display plugged to my mt8365-evk board. This serie come from a bigger one [1]. Then I addressed the previous comments for the related commits here. [1]: https://lore.kernel.org/all/20230220-display-v1-0-45cbc68e1...@baylibre.com/ Signed-off-by: Alexandre Mergnat --- Changes in v3: - Remove spurious line. - Remove useless ops (enable and disable). - Remove brightness value init because it is set right after using mipi_dsi_dcs_get_display_brightness(...). - Link to v2: https://lore.kernel.org/r/20230711-startek_display-v2-0-87bc7bdec...@baylibre.com Changes in v2: - Replace "dcdc-gpio" by "enable-gpio" because this pin enable the Power IC supply. Also, this property come from panel-common. - Remove height-mm and width-mm since they are useless here. - Re-order elements in the stk_panel structure for readability. - Link to v1: https://lore.kernel.org/r/20230711-startek_display-v1-0-163917bed...@baylibre.com Changes in v1: - Fix typos in the driver. - Merge 2 regulators in one bulk variable in the driver. - Remove backlight enable/disable from the driver because it's already managed by the backlight core. - Move hardcoded values from function to the generic structure in the driver. - Remove unnecessary function (stk_panel_del). - Replace some functions by macro to increase the readability. - Link to parent serie: [1] --- Alexandre Mergnat (2): dt-bindings: display: panel: add startek kd070fhfid015 support arm64: defconfig: enable STARTEK KD070FHFID015 panel Guillaume La Roque (1): drm/panel: Support for startek-kd070fhfid015 MIPI-DSI panel .../display/panel/startek,kd070fhfid015.yaml | 69 arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile | 1 + .../gpu/drm/panel/panel-startek-kd070fhfid015.c| 412 + 5 files changed, 494 insertions(+) --- base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5 change-id: 20230711-startek_display-958d265f6baa Best regards, -- Alexandre Mergnat
Re: [PATCH v3] drm/bridge: Add debugfs print for bridge chains
Hi Tomi,
Am Montag, 31. Juli 2023, 14:13:14 CEST schrieb Tomi Valkeinen:
> DRM bridges are not visible to the userspace and it may not be
> immediately clear if the chain is somehow constructed incorrectly. I
> have had two separate instances of a bridge driver failing to do a
> drm_bridge_attach() call, resulting in the bridge connector not being
> part of the chain. In some situations this doesn't seem to cause issues,
> but it will if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is used.
>
> Add a debugfs file to print the bridge chains. For me, on this TI AM62
> based platform, I get the following output:
>
> encoder[39]
> bridge[0] type: 0, ops: 0x0
> bridge[1] type: 0, ops: 0x0, OF:
> /bus@f/i2c@2000/dsi@e:toshiba,tc358778 bridge[2] type: 0, ops: 0x3,
> OF: /bus@f/i2c@2001/hdmi@48:lontium,lt8912b bridge[3] type: 11,
> ops: 0x7, OF: /hdmi-connector:hdmi-connector
>
> Signed-off-by: Tomi Valkeinen
Looks good:
$ for dev in /sys/kernel/debug/dri/*; do cat $dev/bridge_chains; done
cat: /sys/kernel/debug/dri/0/bridge_chains: No such file or directory
encoder[36]
bridge[0] type: 0, ops: 0x0, OF: /soc@0/bus@32c0/display-
bridge@32fc4000:fsl,imx8mp-hdmi-pvi
bridge[1] type: 0, ops: 0x7, OF: /soc@0/bus@32c0/
hdmi@32fd8000:fsl,imx8mp-hdmi
cat: /sys/kernel/debug/dri/128/bridge_chains: No such file or directory
encoder[36]
bridge[0] type: 16, ops: 0x0, OF: /soc@0/bus@32c0/
dsi@32e6:fsl,imx8mp-mipi-dsim
bridge[1] type: 10, ops: 0x3, OF: /soc@0/bus@3080/i2c@30a3/
bridge@f:toshiba,tc9595
Tested-by: Alexander Stein
> ---
> Changes in v3:
> - Use drm_for_each_bridge_in_chain()
> - Drop extra comment
> - Fix whitespace issue
> - Call drm_bridge_debugfs_init() only if the driver uses modeset
> - Drop #ifdef for drm_bridge_debugfs_init() declaration
> - Link to v2:
> https://lore.kernel.org/r/20230721-drm-bridge-chain-debugfs-v2-1-76df943479
> 6...@ideasonboard.com
>
> Changes in v2:
> - Fixed compilation issue when !CONFIG_OF
> - Link to v1:
> https://lore.kernel.org/r/20230721-drm-bridge-chain-debugfs-v1-1-8614ff7e89
> 0...@ideasonboard.com ---
> drivers/gpu/drm/drm_bridge.c | 46
> +++ drivers/gpu/drm/drm_debugfs.c |
> 3 +++
> include/drm/drm_bridge.h | 3 +++
> 3 files changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index c3d69af02e79..39e68e45bb12 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -27,8 +27,10 @@
> #include
>
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -1345,6 +1347,50 @@ struct drm_bridge *of_drm_find_bridge(struct
> device_node *np) EXPORT_SYMBOL(of_drm_find_bridge);
> #endif
>
> +#ifdef CONFIG_DEBUG_FS
> +static int drm_bridge_chains_info(struct seq_file *m, void *data)
> +{
> + struct drm_debugfs_entry *entry = m->private;
> + struct drm_device *dev = entry->dev;
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct drm_mode_config *config = >mode_config;
> + struct drm_encoder *encoder;
> + unsigned int bridge_idx = 0;
> +
> + list_for_each_entry(encoder, >encoder_list, head) {
> + struct drm_bridge *bridge;
> +
> + drm_printf(, "encoder[%u]\n", encoder->base.id);
> +
> + drm_for_each_bridge_in_chain(encoder, bridge) {
> + drm_printf(, "\tbridge[%u] type: %u, ops:
%#x",
> +bridge_idx, bridge->type, bridge-
>ops);
> +
> +#ifdef CONFIG_OF
> + if (bridge->of_node)
> + drm_printf(, ", OF: %pOFfc", bridge-
>of_node);
> +#endif
> +
> + drm_printf(, "\n");
> +
> + bridge_idx++;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct drm_debugfs_info drm_bridge_debugfs_list[] = {
> + { "bridge_chains", drm_bridge_chains_info, 0 },
> +};
> +
> +void drm_bridge_debugfs_init(struct drm_minor *minor)
> +{
> + drm_debugfs_add_files(minor->dev, drm_bridge_debugfs_list,
> + ARRAY_SIZE(drm_bridge_debugfs_list));
> +}
> +#endif
> +
> MODULE_AUTHOR("Ajay Kumar ");
> MODULE_DESCRIPTION("DRM bridge infrastructure");
> MODULE_LICENSE("GPL and additional rights");
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index a3a488205009..3b1de2c61c89 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -31,6 +31,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -274,6 +275,8 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
>
> if (drm_drv_uses_atomic_modeset(dev)) {
> drm_atomic_debugfs_init(minor);
> +
> + drm_bridge_debugfs_init(minor);
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> diff
Re: [PATCH v3 0/4] mm: convert to vma_is_initial_heap/stack()
On Fri, Jul 28, 2023 at 01:00:39PM +0800, Kefeng Wang wrote: > Kefeng Wang (4): > mm: factor out VMA stack and heap checks > drm/amdkfd: use vma_is_initial_stack() and vma_is_initial_heap() > selinux: use vma_is_initial_stack() and vma_is_initial_heap() > perf/core: use vma_is_initial_stack() and vma_is_initial_heap() > > drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 + > fs/proc/task_mmu.c | 24 > fs/proc/task_nommu.c | 15 + > include/linux/mm.h | 25 + > kernel/events/core.c | 33 ++-- > security/selinux/hooks.c | 7 ++ > 6 files changed, 44 insertions(+), 65 deletions(-) Acked-by: Peter Zijlstra (Intel)
Re: [PATCH v14 02/12] drm/shmem-helper: Add pages_pin_count field
+Danilo, to confirm my understanding of the gpuva remap operation is correct. On Mon, 31 Jul 2023 15:27:31 +0300 Dmitry Osipenko wrote: > On 7/25/23 11:32, Boris Brezillon wrote: > >> Can we make it an atomic_t, so we can avoid taking the lock when the > >> GEM has already been pinned. That's something I need to be able to grab > >> a pin-ref in a path where the GEM resv lock is already held[1]. We could > >> of course expose the locked version, > > My bad, that's actually not true. The problem is not that I call > > drm_gem_shmem_pin() with the resv lock already held, but that I call > > drm_gem_shmem_pin() in a dma-signaling path where I'm not allowed to > > take a resv lock. I know for sure pin_count > 0, because all GEM objects > > mapped to a VM have their memory pinned right now, and this should > > stand until we decide to add support for live-GEM eviction, at which > > point we'll probably have a way to detect when a GEM is evicted, and > > avoid calling drm_gem_shmem_pin() on it. > > > > TLDR; I can't trade the atomic_t for a drm_gem_shmem_pin_locked(), > > because that wouldn't solve my problem. The other solution would be to > > add an atomic_t at the driver-GEM level, and only call > > drm_gem_shmem_[un]pin() on 0 <-> 1 transitions, but I thought using an > > atomic at the GEM-shmem level, to avoid locking when we can, would be > > beneficial to the rest of the eco-system. Let me know if that's not an > > option, and I'll go back to the driver-specific atomic_t. > > Could you please explain why do you need to pin GEM in a signal handler? > This is not something drivers usually do or need to do. You likely also > shouldn't need to detect that GEM is evicted in yours driver. I'd expect > that Panthor shouldn't differ from Panfrost in regards to how GEM memory > management is done and Panfrost doesn't need to do anything special. Panthor VM management is completely different, and the case I'm referring to is 'asynchronous VM_BIND': mapping a GEM object to a GPU VM asynchronously, so we can make it depend on other operations, encoded as syncobjs passed to the VM_BIND operation. Here is the workflow we have for this use case: 1. Create + push a VM_BIND job to the VM_BIND queue (a drm_sched_entity that's taking care of asynchronous VM map/unmap operations). Because this operation is asynchronous, and the execution itself happens in a dma-signaling path (drm_sched::run_job()), we need to pre-allocate the MMU page tables for the worst case scenario, and make sure the GEM pages are pinned at job creation time. 2. The VM operation itself is executed when all dependencies are met (drm_sched calls run_job()). In case of a map operation, we call drm_gpuva_sm_map(), which might split the map operation into remap+unamp+map ones if the region being mapped is covering a region that was previously mapped to a different GEM object or a different portion of the same GEM object (see the gpuva_mgr doc [1]). A remap operation is just a way to split an existing mapping in 2 mappings covering the left/right side of the previous mapping, plus a hole in the middle. This means that our VM mapping object (drm_gpuva), which was pointing to a GEM object that had its pages pinned, is now turned into 2 mapping objects, and we need to make sure those 2 mappings own a reference to the pages, otherwise we'll have an unbalanced refcount when we release those 2 mappings further down the road. 3. Release resources attached to mappings that were removed (that includes releasing the ref we had on GEM pages) and free the mapping objects. We do that asynchronously, outside of the dma-signaling path. > > Note that patch #14 makes locked pin/unpin functions public and turns > the unlocked variants into helpers, you'll be able to experiment with > these funcs in the Panthor driver. Unfortunately, those won't help. I really need a way to increment the refcount without holding the lock, because we're in a dma-signaling path when we call drm_gpuva_sm_map(). Note that I could live with a drm_shmem_gem_pin_if_already_pinned() variant that would return NULL if pin_count == 0 instead of trying to acquire the lock, but I'd still need this refcount to be an atomic_t. As I said, an alternative to this approach would be to have a separate atomic refcount at the panthor_gem_object level, but I feel like we'd just be duplicating something that exists already. [1]https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_gpuva_mgr.c#n67
[PATCH -next] drm/amdgpu: Remove a lot of unnecessary ternary operators
Ther are many ternary operators, the true or false judgement
of which is unnecessary in C language semantics.
Signed-off-by: Ruan Jinjie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 2 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c| 2 +-
.../drm/amd/display/dc/dce/dce_link_encoder.c | 4 +---
.../drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c| 6 +++---
.../amd/pm/powerplay/hwmgr/smu7_powertune.c| 2 +-
.../drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 18 +++---
.../amd/pm/powerplay/smumgr/polaris10_smumgr.c | 2 +-
.../drm/amd/pm/powerplay/smumgr/vegam_smumgr.c | 7 +++
13 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index b582b83c4984..38ccec913f00 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -460,7 +460,7 @@ bool amdgpu_get_bios(struct amdgpu_device *adev)
return false;
success:
- adev->is_atom_fw = (adev->asic_type >= CHIP_VEGA10) ? true : false;
+ adev->is_atom_fw = adev->asic_type >= CHIP_VEGA10;
return true;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
index 79791379fc2b..df4440c21bbf 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
@@ -479,7 +479,7 @@ static int jpeg_v3_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
if (enable) {
if (!jpeg_v3_0_is_idle(handle))
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
index a707d407fbd0..3eb3dcd56b57 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
@@ -626,7 +626,7 @@ static int jpeg_v4_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
if (enable) {
if (!jpeg_v4_0_is_idle(handle))
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
index ce2b22f7e4e4..153731d6ce8b 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_3.c
@@ -785,7 +785,7 @@ static int jpeg_v4_0_3_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
int i;
for (i = 0; i < adev->jpeg.num_jpeg_inst; ++i) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index b76ba21b5a89..9b662b105cc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -2095,7 +2095,7 @@ static int vcn_v3_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
int i;
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index 6089c7deba8a..7c486745bece 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
@@ -1918,7 +1918,7 @@ static int vcn_v4_0_wait_for_idle(void *handle)
static int vcn_v4_0_set_clockgating_state(void *handle, enum
amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = state == AMD_CG_STATE_GATE;
int i;
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
index 550ac040b4be..e62472e6e7b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
@@ -1287,7 +1287,7 @@ static int vcn_v4_0_3_set_clockgating_state(void *handle,
[PATCH -next] drm/omap: remove redundant of_match_ptr
The driver depends on CONFIG_OF, so it is not necessary to use
of_match_ptr here.
Even for drivers that do not depend on CONFIG_OF, it's almost always
better to leave out the of_match_ptr(), since the only thing it can
possibly do is to save a few bytes of .text if a driver can be used both
with and without it. Hence we remove of_match_ptr.
Signed-off-by: Zhu Wang
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 9753c1e1f994..99a5dc36f09d 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -1214,7 +1214,7 @@ struct platform_driver omap_dmm_driver = {
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
- .of_match_table = of_match_ptr(dmm_of_match),
+ .of_match_table = dmm_of_match,
.pm = _dmm_pm_ops,
},
};
--
2.17.1
[PATCH -next] drm/mcde: remove redundant of_match_ptr
The driver depends on CONFIG_OF, so it is not necessary to use
of_match_ptr here.
Even for drivers that do not depend on CONFIG_OF, it's almost always
better to leave out the of_match_ptr(), since the only thing it can
possibly do is to save a few bytes of .text if a driver can be used both
with and without it. Hence we remove of_match_ptr.
Signed-off-by: Zhu Wang
---
drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index db82b38600b2..e2fad1a048b5 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -1226,7 +1226,7 @@ static const struct of_device_id mcde_dsi_of_match[] = {
struct platform_driver mcde_dsi_driver = {
.driver = {
.name = "mcde-dsi",
- .of_match_table = of_match_ptr(mcde_dsi_of_match),
+ .of_match_table = mcde_dsi_of_match,
},
.probe = mcde_dsi_probe,
.remove_new = mcde_dsi_remove,
--
2.17.1
Re: [PATCH -next] drm/exynos: remove redundant of_match_ptr
On 31/07/2023 14:33, Zhu Wang wrote: > The driver depends on CONFIG_OF, so it is not necessary to use > of_match_ptr here. > > Even for drivers that do not depend on CONFIG_OF, it's almost always > better to leave out the of_match_ptr(), since the only thing it can > possibly do is to save a few bytes of .text if a driver can be used both > with and without it. Hence we remove of_match_ptr. > > Signed-off-by: Zhu Wang Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] fbdev: fbmem: mark registered_fb static
On 7/14/23 02:37, Min-Hua Chen wrote:
Mark registered_fb, num_registered_fb, fbcon_registered_fb, and
fbcon_num_registered_fb static to fix the following sparse
warnings:
drivers/video/fbdev/core/fbmem.c:51:16: sparse: warning: symbol 'registered_fb'
was not declared. Should it be static?
drivers/video/fbdev/core/fbmem.c:52:5: sparse: warning: symbol
'num_registered_fb' was not declared. Should it be static?
drivers/video/fbdev/core/fbcon.c:105:16: sparse: warning: symbol
'fbcon_registered_fb' was not declared. Should it be static?
drivers/video/fbdev/core/fbcon.c:106:5: sparse: warning: symbol
'fbcon_num_registered_fb' was not declared. Should it be static?
No functional change intended.
num_registered_fb is still used in:
drivers/staging/olpc_dcon/olpc_dcon.c: if (num_registered_fb < 1) {
Helge
[PATCH v7 10/13] drm/mediatek: gamma: Make sure relay mode is disabled
Disable relay mode at the end of LUT programming to make sure that the processed image goes through. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Jason-JH.Lin Reviewed-by: Alexandre Mergnat --- drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c index a846d0dbaa69..659d5c512238 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c @@ -19,6 +19,7 @@ #define DISP_GAMMA_EN 0x #define GAMMA_EN BIT(0) #define DISP_GAMMA_CFG 0x0020 +#define GAMMA_RELAY_MODE BIT(0) #define GAMMA_LUT_EN BIT(1) #define GAMMA_DITHERINGBIT(2) #define DISP_GAMMA_SIZE0x0030 @@ -195,6 +196,9 @@ void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct drm_crt /* Enable the gamma table */ cfg_val |= FIELD_PREP(GAMMA_LUT_EN, 1); + /* Disable RELAY mode to pass the processed image */ + cfg_val &= ~GAMMA_RELAY_MODE; + writel(cfg_val, regs + DISP_GAMMA_CFG); } -- 2.41.0
[PATCH v7 02/13] drm/mediatek: gamma: Reduce indentation in mtk_gamma_set_common()
Invert the check for state->gamma_lut and move it at the beginning
of the function to reduce indentation: this prepares the code for
keeping readability on later additions.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 45 ---
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index d42cc0698d83..47751864bd5c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -64,6 +64,10 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
u32 word;
u32 diff[3] = {0};
+ /* If there's no gamma lut there's nothing to do here. */
+ if (!state->gamma_lut)
+ return;
+
/* If we're called from AAL, dev is NULL */
gamma = dev ? dev_get_drvdata(dev) : NULL;
@@ -72,29 +76,26 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
else
lut_diff = false;
- if (state->gamma_lut) {
- reg = readl(regs + DISP_GAMMA_CFG);
- reg = reg | GAMMA_LUT_EN;
- writel(reg, regs + DISP_GAMMA_CFG);
- lut_base = regs + DISP_GAMMA_LUT;
- lut = (struct drm_color_lut *)state->gamma_lut->data;
- for (i = 0; i < MTK_LUT_SIZE; i++) {
-
- if (!lut_diff || (i % 2 == 0)) {
- word = (((lut[i].red >> 6) & LUT_10BIT_MASK) <<
20) +
- (((lut[i].green >> 6) & LUT_10BIT_MASK)
<< 10) +
- ((lut[i].blue >> 6) & LUT_10BIT_MASK);
- } else {
- diff[0] = (lut[i].red >> 6) - (lut[i - 1].red
>> 6);
- diff[1] = (lut[i].green >> 6) - (lut[i -
1].green >> 6);
- diff[2] = (lut[i].blue >> 6) - (lut[i - 1].blue
>> 6);
-
- word = ((diff[0] & LUT_10BIT_MASK) << 20) +
- ((diff[1] & LUT_10BIT_MASK) << 10) +
- (diff[2] & LUT_10BIT_MASK);
- }
- writel(word, (lut_base + i * 4));
+ reg = readl(regs + DISP_GAMMA_CFG);
+ reg = reg | GAMMA_LUT_EN;
+ writel(reg, regs + DISP_GAMMA_CFG);
+ lut_base = regs + DISP_GAMMA_LUT;
+ lut = (struct drm_color_lut *)state->gamma_lut->data;
+ for (i = 0; i < MTK_LUT_SIZE; i++) {
+ if (!lut_diff || (i % 2 == 0)) {
+ word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
+ (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
+ ((lut[i].blue >> 6) & LUT_10BIT_MASK);
+ } else {
+ diff[0] = (lut[i].red >> 6) - (lut[i - 1].red >> 6);
+ diff[1] = (lut[i].green >> 6) - (lut[i - 1].green >> 6);
+ diff[2] = (lut[i].blue >> 6) - (lut[i - 1].blue >> 6);
+
+ word = ((diff[0] & LUT_10BIT_MASK) << 20) +
+ ((diff[1] & LUT_10BIT_MASK) << 10) +
+ (diff[2] & LUT_10BIT_MASK);
}
+ writel(word, (lut_base + i * 4));
}
}
--
2.41.0
[PATCH v7 09/13] drm/mediatek: gamma: Add support for 12-bit LUT and MT8195
Add support for 12-bit gamma lookup tables and introduce the first
user for it: MT8195.
While at it, also reorder the variables in mtk_gamma_set_common()
and rename `lut_base` to `lut0_base` to improve readability.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 76 +++
1 file changed, 63 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 65b90e1831c5..a846d0dbaa69 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -26,12 +26,20 @@
#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
#define DISP_GAMMA_BANK0x0100
#define DISP_GAMMA_BANK_BANK GENMASK(1, 0)
+#define DISP_GAMMA_BANK_DATA_MODE BIT(2)
#define DISP_GAMMA_LUT 0x0700
+#define DISP_GAMMA_LUT10x0b00
+/* For 10 bit LUT layout, R/G/B are in the same register */
#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20)
#define DISP_GAMMA_LUT_10BIT_G GENMASK(19, 10)
#define DISP_GAMMA_LUT_10BIT_B GENMASK(9, 0)
+/* For 12 bit LUT layout, R/G are in LUT, B is in LUT1 */
+#define DISP_GAMMA_LUT_12BIT_R GENMASK(11, 0)
+#define DISP_GAMMA_LUT_12BIT_G GENMASK(23, 12)
+#define DISP_GAMMA_LUT_12BIT_B GENMASK(11, 0)
+
#define LUT_10BIT_MASK 0x03ff
#define LUT_BITS_DEFAULT 10
#define LUT_SIZE_DEFAULT 512
@@ -77,17 +85,33 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
return LUT_SIZE_DEFAULT;
}
+/*
+ * SoCs supporting 12-bits LUTs are using a new register layout that does
+ * always support (by HW) both 12-bits and 10-bits LUT but, on those, we
+ * ignore the support for 10-bits in this driver and always use 12-bits.
+ *
+ * Summarizing:
+ * - SoC HW support 9/10-bits LUT only
+ * - Old register layout
+ * - 10-bits LUT supported
+ * - 9-bits LUT not supported
+ * - SoC HW support both 10/12bits LUT
+ * - New register layout
+ * - 12-bits LUT supported
+ * - 10-its LUT not supported
+ */
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma;
- unsigned int i;
+ void __iomem *lut0_base = regs + DISP_GAMMA_LUT;
+ void __iomem *lut1_base = regs + DISP_GAMMA_LUT1;
+ u32 cfg_val, data_mode, lbank_val, word[2];
+ int cur_bank, num_lut_banks;
+ u16 lut_bank_size, lut_size;
struct drm_color_lut *lut;
- void __iomem *lut_base;
+ unsigned int i;
bool lut_diff;
- u16 lut_bank_size, lut_size;
u8 lut_bits;
- u32 cfg_val, lbank_val, word;
- int cur_bank, num_lut_banks;
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
@@ -110,14 +134,17 @@ void mtk_gamma_set_common(struct device *dev, void
__iomem *regs, struct drm_crt
num_lut_banks = lut_size / lut_bank_size;
cfg_val = readl(regs + DISP_GAMMA_CFG);
- lut_base = regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
+ /* Switch to 12 bits data mode if supported */
+ data_mode = FIELD_PREP(DISP_GAMMA_BANK_DATA_MODE, !!(lut_bits == 12));
+
for (cur_bank = 0; cur_bank < num_lut_banks; cur_bank++) {
/* Switch gamma bank and set data mode before writing LUT */
if (num_lut_banks > 1) {
lbank_val = FIELD_PREP(DISP_GAMMA_BANK_BANK, cur_bank);
+ lbank_val |= data_mode;
writel(lbank_val, regs + DISP_GAMMA_BANK);
}
@@ -130,9 +157,15 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
hwlut.blue = drm_color_lut_extract(lut[n].blue,
lut_bits);
if (!lut_diff || (i % 2 == 0)) {
- word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R,
hwlut.red);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G,
hwlut.green);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B,
hwlut.blue);
+ if (lut_bits == 12) {
+ word[0] =
FIELD_PREP(DISP_GAMMA_LUT_12BIT_R, hwlut.red);
+ word[0] |=
FIELD_PREP(DISP_GAMMA_LUT_12BIT_G, hwlut.green);
+ word[1] =
FIELD_PREP(DISP_GAMMA_LUT_12BIT_B, hwlut.blue);
+ } else {
+ word[0] =
FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, hwlut.red);
+
[PATCH v7 01/13] drm/mediatek: gamma: Adjust mtk_drm_gamma_set_common parameters
From: "Jason-JH.Lin"
Adjust the parameters in mtk_drm_gamma_set_common()
- add (struct device *dev) to get lut_diff from gamma's driver data
- remove (bool lut_diff) and use false as default value in the function
Signed-off-by: Jason-JH.Lin
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 18 --
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index cdbec79474d1..2f602f1f1c49 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -66,7 +66,7 @@ void mtk_aal_gamma_set(struct device *dev, struct
drm_crtc_state *state)
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
if (aal->data && aal->data->has_gamma)
- mtk_gamma_set_common(aal->regs, state, false);
+ mtk_gamma_set_common(NULL, aal->regs, state);
}
void mtk_aal_start(struct device *dev)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 2254038519e1..75045932353e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -54,7 +54,7 @@ void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
-void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state,
bool lut_diff);
+void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
void mtk_gamma_stop(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 7746dceadb20..d42cc0698d83 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -54,14 +54,24 @@ void mtk_gamma_clk_disable(struct device *dev)
clk_disable_unprepare(gamma->clk);
}
-void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state,
bool lut_diff)
+void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
+ struct mtk_disp_gamma *gamma;
unsigned int i, reg;
struct drm_color_lut *lut;
void __iomem *lut_base;
+ bool lut_diff;
u32 word;
u32 diff[3] = {0};
+ /* If we're called from AAL, dev is NULL */
+ gamma = dev ? dev_get_drvdata(dev) : NULL;
+
+ if (gamma && gamma->data)
+ lut_diff = gamma->data->lut_diff;
+ else
+ lut_diff = false;
+
if (state->gamma_lut) {
reg = readl(regs + DISP_GAMMA_CFG);
reg = reg | GAMMA_LUT_EN;
@@ -91,12 +101,8 @@ void mtk_gamma_set_common(void __iomem *regs, struct
drm_crtc_state *state, bool
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
- bool lut_diff = false;
-
- if (gamma->data)
- lut_diff = gamma->data->lut_diff;
- mtk_gamma_set_common(gamma->regs, state, lut_diff);
+ mtk_gamma_set_common(dev, gamma->regs, state);
}
void mtk_gamma_config(struct device *dev, unsigned int w,
--
2.41.0
[PATCH v7 13/13] drm/mediatek: gamma: Add kerneldoc for struct mtk_disp_gamma
The mtk_disp_gamma structure was completely undocumented: add some
kerneldoc documentation to it.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 6fa3f583f8a1..ee6b06223291 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -54,8 +54,12 @@ struct mtk_disp_gamma_data {
u8 lut_bits;
};
-/*
- * struct mtk_disp_gamma - DISP_GAMMA driver structure
+/**
+ * struct mtk_disp_gamma - Display Gamma driver structure
+ * @clk: clock for DISP_GAMMA block
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform data for DISP_GAMMA
*/
struct mtk_disp_gamma {
struct clk *clk;
--
2.41.0
[PATCH v7 04/13] drm/mediatek: gamma: Improve and simplify HW LUT calculation
Use drm_color_lut_extract() to avoid open-coding the bits reduction
calculations for each color channel and use a struct drm_color_lut
to temporarily store the information instead of an array of u32.
Also, slightly improve the precision of the HW LUT calculation in the
LUT DIFF case by performing the subtractions on the 16-bits values and
doing the 10 bits conversion later.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 30 +++
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 7575237625d2..fd6a75a64a9f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -74,7 +74,6 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
bool lut_diff;
u16 lut_size;
u32 word;
- u32 diff[3] = {0};
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
@@ -97,18 +96,29 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
lut_base = regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
for (i = 0; i < lut_size; i++) {
+ struct drm_color_lut diff, hwlut;
+
+ hwlut.red = drm_color_lut_extract(lut[i].red, 10);
+ hwlut.green = drm_color_lut_extract(lut[i].green, 10);
+ hwlut.blue = drm_color_lut_extract(lut[i].blue, 10);
+
if (!lut_diff || (i % 2 == 0)) {
- word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
- (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
- ((lut[i].blue >> 6) & LUT_10BIT_MASK);
+ word = hwlut.red << 20 +
+ hwlut.green << 10 +
+ hwlut.red;
} else {
- diff[0] = (lut[i].red >> 6) - (lut[i - 1].red >> 6);
- diff[1] = (lut[i].green >> 6) - (lut[i - 1].green >> 6);
- diff[2] = (lut[i].blue >> 6) - (lut[i - 1].blue >> 6);
+ diff.red = lut[i].red - lut[i - 1].red;
+ diff.red = drm_color_lut_extract(diff.red, 10);
+
+ diff.green = lut[i].green - lut[i - 1].green;
+ diff.green = drm_color_lut_extract(diff.green, 10);
+
+ diff.blue = lut[i].blue - lut[i - 1].blue;
+ diff.blue = drm_color_lut_extract(diff.blue, 10);
- word = ((diff[0] & LUT_10BIT_MASK) << 20) +
- ((diff[1] & LUT_10BIT_MASK) << 10) +
- (diff[2] & LUT_10BIT_MASK);
+ word = diff.blue << 20 +
+ diff.green << 10 +
+ diff.red;
}
writel(word, (lut_base + i * 4));
}
--
2.41.0
[PATCH v7 08/13] drm/mediatek: gamma: Support multi-bank gamma LUT
Newer Gamma IP have got multiple LUT banks: support specifying the
size of the LUT banks and handle bank-switching before programming
the LUT in mtk_gamma_set_common() in preparation for adding support
for MT8195 and newer SoCs.
Suggested-by: Jason-JH.Lin
[Angelo: Refactored original commit]
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 74 ++-
1 file changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 8a45eac53875..65b90e1831c5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -24,6 +24,8 @@
#define DISP_GAMMA_SIZE0x0030
#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16)
#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
+#define DISP_GAMMA_BANK0x0100
+#define DISP_GAMMA_BANK_BANK GENMASK(1, 0)
#define DISP_GAMMA_LUT 0x0700
#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20)
@@ -37,6 +39,7 @@
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
+ u16 lut_bank_size;
u16 lut_size;
u8 lut_bits;
};
@@ -81,9 +84,10 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
struct drm_color_lut *lut;
void __iomem *lut_base;
bool lut_diff;
- u16 lut_size;
+ u16 lut_bank_size, lut_size;
u8 lut_bits;
- u32 cfg_val, word;
+ u32 cfg_val, lbank_val, word;
+ int cur_bank, num_lut_banks;
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
@@ -94,43 +98,57 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
if (gamma && gamma->data) {
lut_diff = gamma->data->lut_diff;
+ lut_bank_size = gamma->data->lut_bank_size;
lut_bits = gamma->data->lut_bits;
lut_size = gamma->data->lut_size;
} else {
lut_diff = false;
+ lut_bank_size = LUT_SIZE_DEFAULT;
lut_bits = LUT_BITS_DEFAULT;
lut_size = LUT_SIZE_DEFAULT;
}
+ num_lut_banks = lut_size / lut_bank_size;
cfg_val = readl(regs + DISP_GAMMA_CFG);
lut_base = regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
- for (i = 0; i < lut_size; i++) {
- struct drm_color_lut diff, hwlut;
-
- hwlut.red = drm_color_lut_extract(lut[i].red, lut_bits);
- hwlut.green = drm_color_lut_extract(lut[i].green, lut_bits);
- hwlut.blue = drm_color_lut_extract(lut[i].blue, lut_bits);
-
- if (!lut_diff || (i % 2 == 0)) {
- word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, hwlut.red);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, hwlut.green);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, hwlut.blue);
- } else {
- diff.red = lut[i].red - lut[i - 1].red;
- diff.red = drm_color_lut_extract(diff.red, lut_bits);
-
- diff.green = lut[i].green - lut[i - 1].green;
- diff.green = drm_color_lut_extract(diff.green,
lut_bits);
-
- diff.blue = lut[i].blue - lut[i - 1].blue;
- diff.blue = drm_color_lut_extract(diff.blue, lut_bits);
-
- word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, diff.red);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, diff.green);
- word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, diff.blue);
+
+ for (cur_bank = 0; cur_bank < num_lut_banks; cur_bank++) {
+
+ /* Switch gamma bank and set data mode before writing LUT */
+ if (num_lut_banks > 1) {
+ lbank_val = FIELD_PREP(DISP_GAMMA_BANK_BANK, cur_bank);
+ writel(lbank_val, regs + DISP_GAMMA_BANK);
+ }
+
+ for (i = 0; i < lut_bank_size; i++) {
+ int n = (cur_bank * lut_bank_size) + i;
+ struct drm_color_lut diff, hwlut;
+
+ hwlut.red = drm_color_lut_extract(lut[n].red, lut_bits);
+ hwlut.green = drm_color_lut_extract(lut[n].green,
lut_bits);
+ hwlut.blue = drm_color_lut_extract(lut[n].blue,
lut_bits);
+
+ if (!lut_diff || (i % 2 == 0)) {
+ word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R,
hwlut.red);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G,
hwlut.green);
+ word |=
[PATCH v7 12/13] drm/mediatek: aal: Rewrite kerneldoc for struct mtk_disp_aal
The kerneldoc for struct mtk_disp_aal was entirely wrong: rewrite it
to actually document the structure.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index e2e4155faf01..2b51d6f79bfe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -26,9 +26,11 @@ struct mtk_disp_aal_data {
};
/**
- * struct mtk_disp_aal - DISP_AAL driver structure
- * @ddp_comp - structure containing type enum and hardware resources
- * @crtc - associated crtc to report irq events to
+ * struct mtk_disp_aal - Display Adaptive Ambient Light driver structure
+ * @clk: clock for DISP_AAL controller
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform specific data for DISP_AAL
*/
struct mtk_disp_aal {
struct clk *clk;
--
2.41.0
[PATCH v7 11/13] drm/mediatek: gamma: Program gamma LUT type for descending or rising
All of the SoCs that don't have dithering control in the gamma IP
have got a GAMMA_LUT_TYPE bit that tells to the IP if the LUT is
"descending" (bit set) or "rising" (bit cleared): make sure to set
it correctly after programming the LUT.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 659d5c512238..6fa3f583f8a1 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -22,6 +22,7 @@
#define GAMMA_RELAY_MODE BIT(0)
#define GAMMA_LUT_EN BIT(1)
#define GAMMA_DITHERINGBIT(2)
+#define GAMMA_LUT_TYPE BIT(2)
#define DISP_GAMMA_SIZE0x0030
#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16)
#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
@@ -86,6 +87,16 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
return LUT_SIZE_DEFAULT;
}
+static bool mtk_gamma_lut_is_descending(struct drm_color_lut *lut, u32
lut_size)
+{
+ u64 first, last;
+
+ first = lut[0].red + lut[0].green + lut[0].blue;
+ last = lut[lut_size].red + lut[lut_size].green + lut[lut_size].blue;
+
+ return !!(first > last);
+}
+
/*
* SoCs supporting 12-bits LUTs are using a new register layout that does
* always support (by HW) both 12-bits and 10-bits LUT but, on those, we
@@ -193,6 +204,14 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
}
}
+ if (gamma && gamma->data && !gamma->data->has_dither) {
+ /* Descending or Rising LUT */
+ if (mtk_gamma_lut_is_descending(lut, lut_size))
+ cfg_val |= FIELD_PREP(GAMMA_LUT_TYPE, 1);
+ else
+ cfg_val &= ~GAMMA_LUT_TYPE;
+ }
+
/* Enable the gamma table */
cfg_val |= FIELD_PREP(GAMMA_LUT_EN, 1);
--
2.41.0
[PATCH v7 07/13] drm/mediatek: gamma: Support specifying number of bits per LUT component
New SoCs, like MT8195, not only may support bigger lookup tables, but
have got a different register layout to support bigger precision:
support specifying the number of `lut_bits` for each SoC and use it
in mtk_gamma_set_common() to perform the right calculation.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index ea91d3619716..8a45eac53875 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -38,6 +38,7 @@ struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
u16 lut_size;
+ u8 lut_bits;
};
/*
@@ -81,6 +82,7 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
void __iomem *lut_base;
bool lut_diff;
u16 lut_size;
+ u8 lut_bits;
u32 cfg_val, word;
/* If there's no gamma lut there's nothing to do here. */
@@ -92,9 +94,11 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
if (gamma && gamma->data) {
lut_diff = gamma->data->lut_diff;
+ lut_bits = gamma->data->lut_bits;
lut_size = gamma->data->lut_size;
} else {
lut_diff = false;
+ lut_bits = LUT_BITS_DEFAULT;
lut_size = LUT_SIZE_DEFAULT;
}
@@ -104,9 +108,9 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
for (i = 0; i < lut_size; i++) {
struct drm_color_lut diff, hwlut;
- hwlut.red = drm_color_lut_extract(lut[i].red, LUT_BITS_DEFAULT);
- hwlut.green = drm_color_lut_extract(lut[i].green,
LUT_BITS_DEFAULT);
- hwlut.blue = drm_color_lut_extract(lut[i].blue,
LUT_BITS_DEFAULT);
+ hwlut.red = drm_color_lut_extract(lut[i].red, lut_bits);
+ hwlut.green = drm_color_lut_extract(lut[i].green, lut_bits);
+ hwlut.blue = drm_color_lut_extract(lut[i].blue, lut_bits);
if (!lut_diff || (i % 2 == 0)) {
word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, hwlut.red);
@@ -114,13 +118,13 @@ void mtk_gamma_set_common(struct device *dev, void
__iomem *regs, struct drm_crt
word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, hwlut.blue);
} else {
diff.red = lut[i].red - lut[i - 1].red;
- diff.red = drm_color_lut_extract(diff.red,
LUT_BITS_DEFAULT);
+ diff.red = drm_color_lut_extract(diff.red, lut_bits);
diff.green = lut[i].green - lut[i - 1].green;
- diff.green = drm_color_lut_extract(diff.green,
LUT_BITS_DEFAULT);
+ diff.green = drm_color_lut_extract(diff.green,
lut_bits);
diff.blue = lut[i].blue - lut[i - 1].blue;
- diff.blue = drm_color_lut_extract(diff.blue,
LUT_BITS_DEFAULT);
+ diff.blue = drm_color_lut_extract(diff.blue, lut_bits);
word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, diff.red);
word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, diff.green);
@@ -237,10 +241,12 @@ static int mtk_disp_gamma_remove(struct platform_device
*pdev)
static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
.has_dither = true,
+ .lut_bits = 10,
.lut_size = 512,
};
static const struct mtk_disp_gamma_data mt8183_gamma_driver_data = {
+ .lut_bits = 10,
.lut_diff = true,
.lut_size = 512,
};
--
2.41.0
[PATCH v7 05/13] drm/mediatek: gamma: Enable the Gamma LUT table only after programming
Move the write to DISP_GAMMA_CFG to enable the Gamma LUT to after
programming the actual table to avoid potential visual glitches during
table modification.
Note:
GAMMA should get enabled in between vblanks, but this requires many
efforts in order to make this happen, as that requires migrating all
of the writes to make use of CMDQ instead of cpu writes and that's
not trivial. For this reason, this patch only moves the LUT enable.
The CMDQ rework will come at a later time.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index fd6a75a64a9f..18b102bef370 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -68,12 +68,12 @@ unsigned int mtk_gamma_get_lut_size(struct device *dev)
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma;
- unsigned int i, reg;
+ unsigned int i;
struct drm_color_lut *lut;
void __iomem *lut_base;
bool lut_diff;
u16 lut_size;
- u32 word;
+ u32 cfg_val, word;
/* If there's no gamma lut there's nothing to do here. */
if (!state->gamma_lut)
@@ -90,9 +90,7 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
lut_size = LUT_SIZE_DEFAULT;
}
- reg = readl(regs + DISP_GAMMA_CFG);
- reg = reg | GAMMA_LUT_EN;
- writel(reg, regs + DISP_GAMMA_CFG);
+ cfg_val = readl(regs + DISP_GAMMA_CFG);
lut_base = regs + DISP_GAMMA_LUT;
lut = (struct drm_color_lut *)state->gamma_lut->data;
for (i = 0; i < lut_size; i++) {
@@ -122,6 +120,11 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
}
writel(word, (lut_base + i * 4));
}
+
+ /* Enable the gamma table */
+ cfg_val = cfg_val | GAMMA_LUT_EN;
+
+ writel(cfg_val, regs + DISP_GAMMA_CFG);
}
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
--
2.41.0
[PATCH v7 03/13] drm/mediatek: gamma: Support SoC specific LUT size
Newer SoCs support a bigger Gamma LUT table: wire up a callback
to retrieve the correct LUT size for each different Gamma IP.
Co-developed-by: Jason-JH.Lin
Signed-off-by: Jason-JH.Lin
[Angelo: Rewritten commit message/description + porting]
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 17 ++-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 ++
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 23 ++---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +--
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9
7 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 2f602f1f1c49..e2e4155faf01 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -19,7 +19,7 @@
#define AAL_EN BIT(0)
#define DISP_AAL_SIZE 0x0030
#define DISP_AAL_OUTPUT_SIZE 0x04d8
-
+#define DISP_AAL_LUT_SIZE 512
struct mtk_disp_aal_data {
bool has_gamma;
@@ -61,6 +61,21 @@ void mtk_aal_config(struct device *dev, unsigned int w,
mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, aal->regs,
DISP_AAL_OUTPUT_SIZE);
}
+/**
+ * mtk_aal_gamma_get_lut_size() - Get gamma LUT size for AAL
+ * @dev: Pointer to struct device
+ *
+ * Return: 0 if gamma control not supported in AAL or gamma LUT size
+ */
+unsigned int mtk_aal_gamma_get_lut_size(struct device *dev)
+{
+ struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+ if (aal->data && aal->data->has_gamma)
+ return DISP_AAL_LUT_SIZE;
+ return 0;
+}
+
void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
{
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 75045932353e..ca377265e5eb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -17,6 +17,7 @@ void mtk_aal_clk_disable(struct device *dev);
void mtk_aal_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+unsigned int mtk_aal_gamma_get_lut_size(struct device *dev);
void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
void mtk_aal_start(struct device *dev);
void mtk_aal_stop(struct device *dev);
@@ -53,6 +54,7 @@ void mtk_gamma_clk_disable(struct device *dev);
void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+unsigned int mtk_gamma_get_lut_size(struct device *dev);
void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 47751864bd5c..7575237625d2 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -24,10 +24,12 @@
#define DISP_GAMMA_LUT 0x0700
#define LUT_10BIT_MASK 0x03ff
+#define LUT_SIZE_DEFAULT 512
struct mtk_disp_gamma_data {
bool has_dither;
bool lut_diff;
+ u16 lut_size;
};
/*
@@ -54,6 +56,15 @@ void mtk_gamma_clk_disable(struct device *dev)
clk_disable_unprepare(gamma->clk);
}
+unsigned int mtk_gamma_get_lut_size(struct device *dev)
+{
+ struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
+
+ if (gamma && gamma->data)
+ return gamma->data->lut_size;
+ return LUT_SIZE_DEFAULT;
+}
+
void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct
drm_crtc_state *state)
{
struct mtk_disp_gamma *gamma;
@@ -61,6 +72,7 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
struct drm_color_lut *lut;
void __iomem *lut_base;
bool lut_diff;
+ u16 lut_size;
u32 word;
u32 diff[3] = {0};
@@ -71,17 +83,20 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
/* If we're called from AAL, dev is NULL */
gamma = dev ? dev_get_drvdata(dev) : NULL;
- if (gamma && gamma->data)
+ if (gamma && gamma->data) {
lut_diff = gamma->data->lut_diff;
- else
+ lut_size = gamma->data->lut_size;
+ } else {
lut_diff
[PATCH v7 06/13] drm/mediatek: gamma: Use bitfield macros
Make the code more robust and improve readability by using bitfield
macros instead of open coding bit operations.
While at it, also add a definition for LUT_BITS_DEFAULT.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Jason-JH.Lin
Reviewed-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 41 ++-
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 18b102bef370..ea91d3619716 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -3,6 +3,7 @@
* Copyright (c) 2021 MediaTek Inc.
*/
+#include
#include
#include
#include
@@ -21,9 +22,16 @@
#define GAMMA_LUT_EN BIT(1)
#define GAMMA_DITHERINGBIT(2)
#define DISP_GAMMA_SIZE0x0030
+#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16)
+#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0)
#define DISP_GAMMA_LUT 0x0700
+#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20)
+#define DISP_GAMMA_LUT_10BIT_G GENMASK(19, 10)
+#define DISP_GAMMA_LUT_10BIT_B GENMASK(9, 0)
+
#define LUT_10BIT_MASK 0x03ff
+#define LUT_BITS_DEFAULT 10
#define LUT_SIZE_DEFAULT 512
struct mtk_disp_gamma_data {
@@ -96,33 +104,33 @@ void mtk_gamma_set_common(struct device *dev, void __iomem
*regs, struct drm_crt
for (i = 0; i < lut_size; i++) {
struct drm_color_lut diff, hwlut;
- hwlut.red = drm_color_lut_extract(lut[i].red, 10);
- hwlut.green = drm_color_lut_extract(lut[i].green, 10);
- hwlut.blue = drm_color_lut_extract(lut[i].blue, 10);
+ hwlut.red = drm_color_lut_extract(lut[i].red, LUT_BITS_DEFAULT);
+ hwlut.green = drm_color_lut_extract(lut[i].green,
LUT_BITS_DEFAULT);
+ hwlut.blue = drm_color_lut_extract(lut[i].blue,
LUT_BITS_DEFAULT);
if (!lut_diff || (i % 2 == 0)) {
- word = hwlut.red << 20 +
- hwlut.green << 10 +
- hwlut.red;
+ word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, hwlut.red);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, hwlut.green);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, hwlut.blue);
} else {
diff.red = lut[i].red - lut[i - 1].red;
- diff.red = drm_color_lut_extract(diff.red, 10);
+ diff.red = drm_color_lut_extract(diff.red,
LUT_BITS_DEFAULT);
diff.green = lut[i].green - lut[i - 1].green;
- diff.green = drm_color_lut_extract(diff.green, 10);
+ diff.green = drm_color_lut_extract(diff.green,
LUT_BITS_DEFAULT);
diff.blue = lut[i].blue - lut[i - 1].blue;
- diff.blue = drm_color_lut_extract(diff.blue, 10);
+ diff.blue = drm_color_lut_extract(diff.blue,
LUT_BITS_DEFAULT);
- word = diff.blue << 20 +
- diff.green << 10 +
- diff.red;
+ word = FIELD_PREP(DISP_GAMMA_LUT_10BIT_R, diff.red);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_G, diff.green);
+ word |= FIELD_PREP(DISP_GAMMA_LUT_10BIT_B, diff.blue);
}
writel(word, (lut_base + i * 4));
}
/* Enable the gamma table */
- cfg_val = cfg_val | GAMMA_LUT_EN;
+ cfg_val |= FIELD_PREP(GAMMA_LUT_EN, 1);
writel(cfg_val, regs + DISP_GAMMA_CFG);
}
@@ -139,9 +147,12 @@ void mtk_gamma_config(struct device *dev, unsigned int w,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
+ u32 sz;
+
+ sz = FIELD_PREP(DISP_GAMMA_SIZE_HSIZE, w);
+ sz |= FIELD_PREP(DISP_GAMMA_SIZE_VSIZE, h);
- mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, gamma->regs,
- DISP_GAMMA_SIZE);
+ mtk_ddp_write(cmdq_pkt, sz, >cmdq_reg, gamma->regs,
DISP_GAMMA_SIZE);
if (gamma->data && gamma->data->has_dither)
mtk_dither_set_common(gamma->regs, >cmdq_reg, bpc,
DISP_GAMMA_CFG, GAMMA_DITHERING,
cmdq_pkt);
--
2.41.0
[PATCH v7 00/13] MediaTek DDP GAMMA - 12-bit LUT support
Changes in v7: - Added check for NULL dev for AAL-gamma case - Added get_lut_size callback for AAL-gamma - Added comment to clarify SoC 10/12 bits support and old vs new register layout as suggested by Alexandre M. Changes in v6: - Fixed smatch warning in patch 11/11, ref.: https://lore.kernel.org/all/202306101458.lrxhee0z-...@intel.com/ Changes in v5: - Removed incorrect comment on default LUT size and bits - Removed useless check for num_lut_banks - Added comment about CMDQ implementation on patch 5 - Evaluated passing lut size/bits from AAL, idea discarded as the implementation would be rather tricky while bringing no benefits. Changes in v4: - Fixed assignment typo appeared in v3 Changes in v3: - Fixed issues due to variables renaming during cleanup (oops) - This is actually the right series, since v2 was taken from the wrong kernel tree :-) Changes in v2: - Added explicit inclusion of linux/bitfield.h in patch [06/11] This series adds support for GAMMA IP requiring and/or supporting a 12-bits LUT using a slightly different register layout and programming sequence for multiple LUT banks: this IP version is currently found on a number of SoCs, not only including the Chromebook/IoT oriented Kompanio 1200/1380 MT8195/MT8195T, but also Smartphone chips such as the Dimensity 9200 (MT6985) and others. This series was tested on MT8195, MT8192, MT8173, MT6795: * MT6795, MT8192, MT8173: No regression, works fine. * MT8195: Color correction is finally working! AngeloGioacchino Del Regno (12): drm/mediatek: gamma: Reduce indentation in mtk_gamma_set_common() drm/mediatek: gamma: Support SoC specific LUT size drm/mediatek: gamma: Improve and simplify HW LUT calculation drm/mediatek: gamma: Enable the Gamma LUT table only after programming drm/mediatek: gamma: Use bitfield macros drm/mediatek: gamma: Support specifying number of bits per LUT component drm/mediatek: gamma: Support multi-bank gamma LUT drm/mediatek: gamma: Add support for 12-bit LUT and MT8195 drm/mediatek: gamma: Make sure relay mode is disabled drm/mediatek: gamma: Program gamma LUT type for descending or rising drm/mediatek: aal: Rewrite kerneldoc for struct mtk_disp_aal drm/mediatek: gamma: Add kerneldoc for struct mtk_disp_gamma Jason-JH.Lin (1): drm/mediatek: gamma: Adjust mtk_drm_gamma_set_common parameters drivers/gpu/drm/mediatek/mtk_disp_aal.c | 27 ++- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 +- drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 217 +--- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 + 7 files changed, 226 insertions(+), 42 deletions(-) -- 2.41.0
Re: [PATCH v14 12/12] drm/gem: Add _unlocked postfix to drm_gem_pin/unpin()
On 7/25/23 10:53, Boris Brezillon wrote: > On Sun, 23 Jul 2023 02:47:46 +0300 > Dmitry Osipenko wrote: > >> Make clear that drm_gem_pin/unpin() functions take reservation lock by >> adding _unlocked postfix to the function names. >> >> Suggested-by: Boris Brezillon >> Signed-off-by: Dmitry Osipenko > > I'm still a bit confused by the fact we sometimes use the > xxx[_locked]() pattern (version without the _locked suffix takes the > lock) and other times the xxx[_unlocked]() pattern (version with the > _unlocked suffix takes the lock). It'd be good to chose one pattern and > stick to it, at least for all core functions... After a more close look, agree that the _locked variant is much more common in DRM. Alright, I'll rename the drm-gem funcs. -- Best regards, Dmitry
