[drm-tip:drm-tip 5/7] drivers/gpu/drm/i915/gt/intel_workarounds.c:1479:27: warning: unused variable 'i915'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: b21ced77ae1dbc3d8b01d3aef3c99bba7377a69b
commit: 878ab630c6059f436bdf6bdef59f97eb5753a155 [5/7] Merge remote-tracking
branch 'drm-intel/drm-intel-gt-next' into drm-tip
config: i386-randconfig-a013
(https://download.01.org/0day-ci/archive/20230312/202303121305.surb4y2b-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip
git fetch --no-tags drm-tip drm-tip
git checkout 878ab630c6059f436bdf6bdef59f97eb5753a155
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303121305.surb4y2b-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gt/intel_workarounds.c:1479:27: warning: unused
>> variable 'i915' [-Wunused-variable]
struct drm_i915_private *i915 = gt->i915;
^
1 warning generated.
vim +/i915 +1479 drivers/gpu/drm/i915/gt/intel_workarounds.c
f52fa57ae70e2e Matt Roper 2020-07-16 1475
da942750928a03 Stuart Summers 2020-10-14 1476 static void
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1477
dg1_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
da942750928a03 Stuart Summers 2020-10-14 1478 {
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 @1479 struct
drm_i915_private *i915 = gt->i915;
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1480
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1481
gen12_gt_workarounds_init(gt, wal);
da942750928a03 Stuart Summers 2020-10-14 1482
da942750928a03 Stuart Summers 2020-10-14 1483 /*
Wa_1409420604:dg1 */
d1b3657fb5b66a Lucas De Marchi 2023-03-06 1484
wa_mcr_write_or(wal, SUBSLICE_UNIT_LEVEL_CLKGATE2,
da942750928a03 Stuart Summers 2020-10-14 1485
CPSSUNIT_CLKGATE_DIS);
da942750928a03 Stuart Summers 2020-10-14 1486
da942750928a03 Stuart Summers 2020-10-14 1487 /*
Wa_1408615072:dg1 */
da942750928a03 Stuart Summers 2020-10-14 1488 /* Empirical
testing shows this register is unaffected by engine reset. */
d1b3657fb5b66a Lucas De Marchi 2023-03-06 1489
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2, VSUNIT_CLKGATE_DIS_TGL);
da942750928a03 Stuart Summers 2020-10-14 1490 }
da942750928a03 Stuart Summers 2020-10-14 1491
:: The code at line 1479 was first introduced by commit
:: d0a652493abd86180ad0cc0ed44427831d37fabe drm/i915: Make wa list per-gt
:: TO: Venkata Sandeep Dhanalakota
:: CC: Matt Roper
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[drm-tip:drm-tip 5/7] drivers/gpu/drm/i915/gt/intel_workarounds.c:1479:34: warning: unused variable 'i915'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: b21ced77ae1dbc3d8b01d3aef3c99bba7377a69b
commit: 878ab630c6059f436bdf6bdef59f97eb5753a155 [5/7] Merge remote-tracking
branch 'drm-intel/drm-intel-gt-next' into drm-tip
config: x86_64-randconfig-a011
(https://download.01.org/0day-ci/archive/20230312/202303121324.bobjdmp9-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip
git fetch --no-tags drm-tip drm-tip
git checkout 878ab630c6059f436bdf6bdef59f97eb5753a155
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303121324.bobjdmp9-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/intel_workarounds.c: In function
'dg1_gt_workarounds_init':
>> drivers/gpu/drm/i915/gt/intel_workarounds.c:1479:34: warning: unused
>> variable 'i915' [-Wunused-variable]
1479 | struct drm_i915_private *i915 = gt->i915;
| ^~~~
vim +/i915 +1479 drivers/gpu/drm/i915/gt/intel_workarounds.c
f52fa57ae70e2e Matt Roper 2020-07-16 1475
da942750928a03 Stuart Summers 2020-10-14 1476 static void
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1477
dg1_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
da942750928a03 Stuart Summers 2020-10-14 1478 {
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 @1479 struct
drm_i915_private *i915 = gt->i915;
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1480
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1481
gen12_gt_workarounds_init(gt, wal);
da942750928a03 Stuart Summers 2020-10-14 1482
da942750928a03 Stuart Summers 2020-10-14 1483 /*
Wa_1409420604:dg1 */
d1b3657fb5b66a Lucas De Marchi 2023-03-06 1484
wa_mcr_write_or(wal, SUBSLICE_UNIT_LEVEL_CLKGATE2,
da942750928a03 Stuart Summers 2020-10-14 1485
CPSSUNIT_CLKGATE_DIS);
da942750928a03 Stuart Summers 2020-10-14 1486
da942750928a03 Stuart Summers 2020-10-14 1487 /*
Wa_1408615072:dg1 */
da942750928a03 Stuart Summers 2020-10-14 1488 /* Empirical
testing shows this register is unaffected by engine reset. */
d1b3657fb5b66a Lucas De Marchi 2023-03-06 1489
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2, VSUNIT_CLKGATE_DIS_TGL);
da942750928a03 Stuart Summers 2020-10-14 1490 }
da942750928a03 Stuart Summers 2020-10-14 1491
:: The code at line 1479 was first introduced by commit
:: d0a652493abd86180ad0cc0ed44427831d37fabe drm/i915: Make wa list per-gt
:: TO: Venkata Sandeep Dhanalakota
:: CC: Matt Roper
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[drm-tip:drm-tip 5/7] drivers/gpu/drm/i915/gt/intel_workarounds.c:1479:34: error: unused variable 'i915'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: b21ced77ae1dbc3d8b01d3aef3c99bba7377a69b
commit: 878ab630c6059f436bdf6bdef59f97eb5753a155 [5/7] Merge remote-tracking
branch 'drm-intel/drm-intel-gt-next' into drm-tip
config: x86_64-defconfig
(https://download.01.org/0day-ci/archive/20230312/202303121304.7ijxtedu-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip
git fetch --no-tags drm-tip drm-tip
git checkout 878ab630c6059f436bdf6bdef59f97eb5753a155
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303121304.7ijxtedu-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/intel_workarounds.c: In function
'dg1_gt_workarounds_init':
>> drivers/gpu/drm/i915/gt/intel_workarounds.c:1479:34: error: unused variable
>> 'i915' [-Werror=unused-variable]
1479 | struct drm_i915_private *i915 = gt->i915;
| ^~~~
cc1: all warnings being treated as errors
vim +/i915 +1479 drivers/gpu/drm/i915/gt/intel_workarounds.c
f52fa57ae70e2e Matt Roper 2020-07-16 1475
da942750928a03 Stuart Summers 2020-10-14 1476 static void
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1477
dg1_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
da942750928a03 Stuart Summers 2020-10-14 1478 {
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 @1479 struct
drm_i915_private *i915 = gt->i915;
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1480
d0a652493abd86 Venkata Sandeep Dhanalakota 2021-09-17 1481
gen12_gt_workarounds_init(gt, wal);
da942750928a03 Stuart Summers 2020-10-14 1482
da942750928a03 Stuart Summers 2020-10-14 1483 /*
Wa_1409420604:dg1 */
d1b3657fb5b66a Lucas De Marchi 2023-03-06 1484
wa_mcr_write_or(wal, SUBSLICE_UNIT_LEVEL_CLKGATE2,
da942750928a03 Stuart Summers 2020-10-14 1485
CPSSUNIT_CLKGATE_DIS);
da942750928a03 Stuart Summers 2020-10-14 1486
da942750928a03 Stuart Summers 2020-10-14 1487 /*
Wa_1408615072:dg1 */
da942750928a03 Stuart Summers 2020-10-14 1488 /* Empirical
testing shows this register is unaffected by engine reset. */
d1b3657fb5b66a Lucas De Marchi 2023-03-06 1489
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2, VSUNIT_CLKGATE_DIS_TGL);
da942750928a03 Stuart Summers 2020-10-14 1490 }
da942750928a03 Stuart Summers 2020-10-14 1491
:: The code at line 1479 was first introduced by commit
:: d0a652493abd86180ad0cc0ed44427831d37fabe drm/i915: Make wa list per-gt
:: TO: Venkata Sandeep Dhanalakota
:: CC: Matt Roper
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH] drm/bridge: adv7533: Fix adv7533_mode_valid for adv7533 and adv7535
On 12/03/2023 01:10, Adam Ford wrote:
When dynamically switching lanes was removed, the intent of the code
was to check to make sure that higher speed items used 4 lanes, but
it had the unintended consequence of removing the slower speeds for
4-lane users.
This attempts to remedy this by doing a check to see that the
max frequency doesn't exceed the chip limit, and a second
check to make sure that the max bit-rate doesn't exceed the
number of lanes * max bit rate / lane.
Fixes: 9a0cdcd6649b ("drm/bridge: adv7533: remove dynamic lane switching from
adv7533 bridge")
Please remove the empty line here. There should be no empty lines
between the tags
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index fdfeadcefe80..10a112d36945 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -103,13 +103,9 @@ void adv7533_dsi_power_off(struct adv7511 *adv)
enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
const struct drm_display_mode *mode)
{
- int lanes;
+ unsigned long max_lane_freq;
struct mipi_dsi_device *dsi = adv->dsi;
-
- if (mode->clock > 8)
- lanes = 4;
- else
- lanes = 3;
+ u8 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
/*
* TODO: add support for dynamic switching of lanes
Drop the comment please. It makes little sense with your new implementation.
@@ -117,8 +113,16 @@ enum drm_mode_status adv7533_mode_valid(struct adv7511
*adv,
* out the modes which shall need different number of lanes
* than what was configured in the device tree.
*/
- if (lanes != dsi->lanes)
- return MODE_BAD;
+
+ /* Check max clock for either 7533 or 7535 */
+ if (mode->clock > (adv->type == ADV7533 ? 8 : 148500))
+ return MODE_CLOCK_HIGH;
+
+ /* Check max clock for each lane */
+ max_lane_freq = (adv->type == ADV7533 ? 80 : 891000);
+
+ if (mode->clock * bpp > max_lane_freq * adv->num_dsi_lanes)
+ return MODE_CLOCK_HIGH;
return MODE_OK;
}
--
With best wishes
Dmitry
Re: [PATCH v16 14/16] drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
On Wed, Mar 8, 2023 at 10:41 AM Jagan Teki wrote:
>
> Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
>
> Add compatible and associated driver_data for it.
>
I have a few updates that I want to push once this series has been
accepted to support non-burst mode, fine-tune the PMS clock, and a few
other things. I have the DSI working through a DSI to HDMI bridge
along with audio in case anyone is interested.
I have my repo here which is based on Jagan's V16 branch:
https://github.com/aford173/linux/tree/imx8mm-dsi-v16-beacon
For the series:
Tested-by: Adam Ford #imx8mm-beacon
> Reviewed-by: Marek Vasut
> Reviewed-by: Frieder Schrempf
> Acked-by: Robert Foss
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Jagan Teki
> ---
> Changes for v16, v15, v13:
> - none
> Changes for v12:
> - collect RB from Marek
> Changes for v11:
> - collect RB from Frieder
> - collect ACK from Robert
> Changes for v10, v9:
> - none
> Changed for v8:
> - fix and update the comment
> Changes for v7, v6:
> - none
> Changes for v3:
> - enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
> Changes for v5:
> - [mszyprow] rebased and adjusted to the new driver initialization
> - drop quirk
> Changes for v4:
> - none
> Changes for v3:
> - enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
> Changes for v2:
> - collect Laurent r-b
> Changes for v1:
> - none
>
> drivers/gpu/drm/bridge/samsung-dsim.c | 44 +++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index f9a5e69a0fcd..f3bd06489a39 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -376,6 +376,24 @@ static const unsigned int exynos5433_reg_values[] = {
> [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
> };
>
> +static const unsigned int imx8mm_dsim_reg_values[] = {
> + [RESET_TYPE] = DSIM_SWRST,
> + [PLL_TIMER] = 500,
> + [STOP_STATE_CNT] = 0xf,
> + [PHYCTRL_ULPS_EXIT] = 0,
> + [PHYCTRL_VREG_LP] = 0,
> + [PHYCTRL_SLEW_UP] = 0,
> + [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
> + [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
> + [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
> + [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
> + [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
> + [PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
> + [PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
> + [PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
> + [PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
> +};
> +
> static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
> .reg_ofs = exynos_reg_ofs,
> .plltmr_reg = 0x50,
> @@ -437,6 +455,22 @@ static const struct samsung_dsim_driver_data
> exynos5422_dsi_driver_data = {
> .reg_values = exynos5422_reg_values,
> };
>
> +static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
> + .reg_ofs = exynos5433_reg_ofs,
> + .plltmr_reg = 0xa0,
> + .has_clklane_stop = 1,
> + .num_clks = 2,
> + .max_freq = 2100,
> + .wait_for_reset = 0,
> + .num_bits_resol = 12,
> + /*
> +* Unlike Exynos, PLL_P(PMS_P) offset 14 is used in i.MX8M
> Mini/Nano/Plus
> +* downstream driver - drivers/gpu/drm/bridge/sec-dsim.c
> +*/
> + .pll_p_offset = 14,
> + .reg_values = imx8mm_dsim_reg_values,
> +};
> +
> static const struct samsung_dsim_driver_data *
> samsung_dsim_types[DSIM_TYPE_COUNT] = {
> [DSIM_TYPE_EXYNOS3250] = _dsi_driver_data,
> @@ -444,6 +478,7 @@ samsung_dsim_types[DSIM_TYPE_COUNT] = {
> [DSIM_TYPE_EXYNOS5410] = _dsi_driver_data,
> [DSIM_TYPE_EXYNOS5422] = _dsi_driver_data,
> [DSIM_TYPE_EXYNOS5433] = _dsi_driver_data,
> + [DSIM_TYPE_IMX8MM] = _dsi_driver_data,
> };
>
> static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
> @@ -1877,7 +1912,16 @@ const struct dev_pm_ops samsung_dsim_pm_ops = {
> };
> EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
>
> +static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
> + .hw_type = DSIM_TYPE_IMX8MM,
> + .host_ops = _dsim_host_ops,
> +};
> +
> static const struct of_device_id samsung_dsim_of_match[] = {
> + {
> + .compatible = "fsl,imx8mm-mipi-dsim",
> + .data = _dsim_imx8mm_pdata,
> + },
> { /* sentinel. */ }
> };
> MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
> --
> 2.25.1
>
[PATCH] drm/bridge: adv7533: Fix adv7533_mode_valid for adv7533 and adv7535
When dynamically switching lanes was removed, the intent of the code
was to check to make sure that higher speed items used 4 lanes, but
it had the unintended consequence of removing the slower speeds for
4-lane users.
This attempts to remedy this by doing a check to see that the
max frequency doesn't exceed the chip limit, and a second
check to make sure that the max bit-rate doesn't exceed the
number of lanes * max bit rate / lane.
Fixes: 9a0cdcd6649b ("drm/bridge: adv7533: remove dynamic lane switching from
adv7533 bridge")
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index fdfeadcefe80..10a112d36945 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -103,13 +103,9 @@ void adv7533_dsi_power_off(struct adv7511 *adv)
enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
const struct drm_display_mode *mode)
{
- int lanes;
+ unsigned long max_lane_freq;
struct mipi_dsi_device *dsi = adv->dsi;
-
- if (mode->clock > 8)
- lanes = 4;
- else
- lanes = 3;
+ u8 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
/*
* TODO: add support for dynamic switching of lanes
@@ -117,8 +113,16 @@ enum drm_mode_status adv7533_mode_valid(struct adv7511
*adv,
* out the modes which shall need different number of lanes
* than what was configured in the device tree.
*/
- if (lanes != dsi->lanes)
- return MODE_BAD;
+
+ /* Check max clock for either 7533 or 7535 */
+ if (mode->clock > (adv->type == ADV7533 ? 8 : 148500))
+ return MODE_CLOCK_HIGH;
+
+ /* Check max clock for each lane */
+ max_lane_freq = (adv->type == ADV7533 ? 80 : 891000);
+
+ if (mode->clock * bpp > max_lane_freq * adv->num_dsi_lanes)
+ return MODE_CLOCK_HIGH;
return MODE_OK;
}
--
2.37.2
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On 12/03/2023 00:52, Adam Ford wrote:
On Sat, Mar 11, 2023 at 4:42 PM Dmitry Baryshkov
wrote:
On 12/03/2023 00:40, Adam Ford wrote:
On Sat, Mar 11, 2023 at 4:02 PM Dmitry Baryshkov
wrote:
On 11/03/2023 23:53, Adam Ford wrote:
On Sat, Mar 11, 2023 at 3:40 PM Dmitry Baryshkov
wrote:
"Hi Abhinav,
On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar wrote:
Hi Adam
On 3/11/2023 9:28 AM, Adam Ford wrote:
On Thu, Oct 13, 2022 at 3:39 AM Robert Foss wrote:
On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of dynamic switch of
detaching and attaching the mipi dsi device also results in removing
and adding the component which is not necessary.
This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
lock_acquire+0x6c/0x90
drm_modeset_acquire_init+0xf4/0x150
drmm_mode_config_init+0x220/0x770
msm_drm_bind+0x13c/0x654
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x18/0x2c
dsi_dev_attach+0x24/0x30
dsi_host_attach+0x98/0x14c
devm_mipi_dsi_attach+0x38/0xb0
adv7533_attach_dsi+0x8c/0x110
adv7511_probe+0x5a0/0x930
i2c_device_probe+0x30c/0x350
really_probe.part.0+0x9c/0x2b0
__driver_probe_device+0x98/0x144
driver_probe_device+0xac/0x14c
__device_attach_driver+0xbc/0x124
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x90/0xd0
process_one_work+0x28c/0x6b0
worker_thread+0x240/0x444
kthread+0x110/0x114
ret_from_fork+0x10/0x20
-> #0 (component_mutex){+.+.}-{3:3}:
__lock_acquire+0x1280/0x20ac
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x6c/0x90
__mutex_lock+0x84/0x400
mutex_lock_nested+0x3c/0x70
component_del+0x34/0x170
dsi_dev_detach+0x24/0x30
dsi_host_detach+0x20/0x64
mipi_dsi_detach+0x2c/0x40
adv7533_mode_set+0x64/0x90
adv7511_bridge_mode_set+0x210/0x214
drm_bridge_chain_mode_set+0x5c/0x84
crtc_set_mode+0x18c/0x1dc
drm_atomic_helper_commit_modeset_disables+0x40/0x50
msm_atomic_commit_tail+0x1d0/0x6e0
commit_tail+0xa4/0x180
drm_atomic_helper_commit+0x178/0x3b0
drm_atomic_commit+0xa4/0xe0
drm_client_modeset_commit_atomic+0x228/0x284
drm_client_modeset_commit_locked+0x64/0x1d0
drm_client_modeset_commit+0x34/0x60
drm_fb_helper_lastclose+0x74/0xcc
drm_lastclose+0x3c/0x80
drm_release+0xfc/0x114
__fput+0x70/0x224
fput+0x14/0x20
task_work_run+0x88/0x1a0
do_exit+0x350/0xa50
do_group_exit+0x38/0xa4
__wake_up_parent+0x0/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x60/0x11c
do_el0_svc+0x30/0xc0
el0_svc+0x58/0x100
el0t_64_sync_handler+0x1b0/0x1bc
el0t_64_sync+0x18c/0x190
Due to above reasons, remove the dynamic lane switching
code from adv7533 bridge chip and filter out the modes
which would need different number of lanes as compared
to the initialization time using the mode_valid callback.
This can be potentially re-introduced by using the pre_enable()
callback but this needs to be evaluated first whether such an
approach will work so this will be done with a separate change.
changes since RFC:
- Fix commit text and add TODO comment
changes in v2:
- Fix checkpatch formatting errors
Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
dynamically")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Robert Foss
Link:
https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
3 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index a031a0cd1f18..1053d185b24c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On Sat, Mar 11, 2023 at 4:42 PM Dmitry Baryshkov
wrote:
>
> On 12/03/2023 00:40, Adam Ford wrote:
> > On Sat, Mar 11, 2023 at 4:02 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On 11/03/2023 23:53, Adam Ford wrote:
> >>> On Sat, Mar 11, 2023 at 3:40 PM Dmitry Baryshkov
> >>> wrote:
>
> "Hi Abhinav,
>
> On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar
> wrote:
> >
> > Hi Adam
> >
> > On 3/11/2023 9:28 AM, Adam Ford wrote:
> >> On Thu, Oct 13, 2022 at 3:39 AM Robert Foss
> >> wrote:
> >>>
> >>> On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar
> >>> wrote:
>
> adv7533 bridge tries to dynamically switch lanes based on the
> mode by detaching and attaching the mipi dsi device.
>
> This approach is incorrect because this method of dynamic switch of
> detaching and attaching the mipi dsi device also results in removing
> and adding the component which is not necessary.
>
> This approach is also prone to deadlocks. So for example, on the
> db410c whenever this path is executed with lockdep enabled,
> this results in a deadlock due to below ordering of locks.
>
> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> lock_acquire+0x6c/0x90
> drm_modeset_acquire_init+0xf4/0x150
> drmm_mode_config_init+0x220/0x770
> msm_drm_bind+0x13c/0x654
> try_to_bring_up_aggregate_device+0x164/0x1d0
> __component_add+0xa8/0x174
> component_add+0x18/0x2c
> dsi_dev_attach+0x24/0x30
> dsi_host_attach+0x98/0x14c
> devm_mipi_dsi_attach+0x38/0xb0
> adv7533_attach_dsi+0x8c/0x110
> adv7511_probe+0x5a0/0x930
> i2c_device_probe+0x30c/0x350
> really_probe.part.0+0x9c/0x2b0
> __driver_probe_device+0x98/0x144
> driver_probe_device+0xac/0x14c
> __device_attach_driver+0xbc/0x124
> bus_for_each_drv+0x78/0xd0
> __device_attach+0xa8/0x1c0
> device_initial_probe+0x18/0x24
> bus_probe_device+0xa0/0xac
> deferred_probe_work_func+0x90/0xd0
> process_one_work+0x28c/0x6b0
> worker_thread+0x240/0x444
> kthread+0x110/0x114
> ret_from_fork+0x10/0x20
>
> -> #0 (component_mutex){+.+.}-{3:3}:
> __lock_acquire+0x1280/0x20ac
> lock_acquire.part.0+0xe0/0x230
> lock_acquire+0x6c/0x90
> __mutex_lock+0x84/0x400
> mutex_lock_nested+0x3c/0x70
> component_del+0x34/0x170
> dsi_dev_detach+0x24/0x30
> dsi_host_detach+0x20/0x64
> mipi_dsi_detach+0x2c/0x40
> adv7533_mode_set+0x64/0x90
> adv7511_bridge_mode_set+0x210/0x214
> drm_bridge_chain_mode_set+0x5c/0x84
> crtc_set_mode+0x18c/0x1dc
> drm_atomic_helper_commit_modeset_disables+0x40/0x50
> msm_atomic_commit_tail+0x1d0/0x6e0
> commit_tail+0xa4/0x180
> drm_atomic_helper_commit+0x178/0x3b0
> drm_atomic_commit+0xa4/0xe0
> drm_client_modeset_commit_atomic+0x228/0x284
> drm_client_modeset_commit_locked+0x64/0x1d0
> drm_client_modeset_commit+0x34/0x60
> drm_fb_helper_lastclose+0x74/0xcc
> drm_lastclose+0x3c/0x80
> drm_release+0xfc/0x114
> __fput+0x70/0x224
> fput+0x14/0x20
> task_work_run+0x88/0x1a0
> do_exit+0x350/0xa50
> do_group_exit+0x38/0xa4
> __wake_up_parent+0x0/0x34
> invoke_syscall+0x48/0x114
> el0_svc_common.constprop.0+0x60/0x11c
> do_el0_svc+0x30/0xc0
> el0_svc+0x58/0x100
> el0t_64_sync_handler+0x1b0/0x1bc
> el0t_64_sync+0x18c/0x190
>
> Due to above reasons, remove the dynamic lane switching
> code from adv7533 bridge chip and filter out the modes
> which would need different number of lanes as compared
> to the initialization time using the mode_valid callback.
>
> This can be potentially re-introduced by using the pre_enable()
> callback but this needs to be evaluated first whether such an
> approach will work so this will be done with a
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On 12/03/2023 00:40, Adam Ford wrote:
On Sat, Mar 11, 2023 at 4:02 PM Dmitry Baryshkov
wrote:
On 11/03/2023 23:53, Adam Ford wrote:
On Sat, Mar 11, 2023 at 3:40 PM Dmitry Baryshkov
wrote:
"Hi Abhinav,
On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar wrote:
Hi Adam
On 3/11/2023 9:28 AM, Adam Ford wrote:
On Thu, Oct 13, 2022 at 3:39 AM Robert Foss wrote:
On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of dynamic switch of
detaching and attaching the mipi dsi device also results in removing
and adding the component which is not necessary.
This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
lock_acquire+0x6c/0x90
drm_modeset_acquire_init+0xf4/0x150
drmm_mode_config_init+0x220/0x770
msm_drm_bind+0x13c/0x654
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x18/0x2c
dsi_dev_attach+0x24/0x30
dsi_host_attach+0x98/0x14c
devm_mipi_dsi_attach+0x38/0xb0
adv7533_attach_dsi+0x8c/0x110
adv7511_probe+0x5a0/0x930
i2c_device_probe+0x30c/0x350
really_probe.part.0+0x9c/0x2b0
__driver_probe_device+0x98/0x144
driver_probe_device+0xac/0x14c
__device_attach_driver+0xbc/0x124
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x90/0xd0
process_one_work+0x28c/0x6b0
worker_thread+0x240/0x444
kthread+0x110/0x114
ret_from_fork+0x10/0x20
-> #0 (component_mutex){+.+.}-{3:3}:
__lock_acquire+0x1280/0x20ac
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x6c/0x90
__mutex_lock+0x84/0x400
mutex_lock_nested+0x3c/0x70
component_del+0x34/0x170
dsi_dev_detach+0x24/0x30
dsi_host_detach+0x20/0x64
mipi_dsi_detach+0x2c/0x40
adv7533_mode_set+0x64/0x90
adv7511_bridge_mode_set+0x210/0x214
drm_bridge_chain_mode_set+0x5c/0x84
crtc_set_mode+0x18c/0x1dc
drm_atomic_helper_commit_modeset_disables+0x40/0x50
msm_atomic_commit_tail+0x1d0/0x6e0
commit_tail+0xa4/0x180
drm_atomic_helper_commit+0x178/0x3b0
drm_atomic_commit+0xa4/0xe0
drm_client_modeset_commit_atomic+0x228/0x284
drm_client_modeset_commit_locked+0x64/0x1d0
drm_client_modeset_commit+0x34/0x60
drm_fb_helper_lastclose+0x74/0xcc
drm_lastclose+0x3c/0x80
drm_release+0xfc/0x114
__fput+0x70/0x224
fput+0x14/0x20
task_work_run+0x88/0x1a0
do_exit+0x350/0xa50
do_group_exit+0x38/0xa4
__wake_up_parent+0x0/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x60/0x11c
do_el0_svc+0x30/0xc0
el0_svc+0x58/0x100
el0t_64_sync_handler+0x1b0/0x1bc
el0t_64_sync+0x18c/0x190
Due to above reasons, remove the dynamic lane switching
code from adv7533 bridge chip and filter out the modes
which would need different number of lanes as compared
to the initialization time using the mode_valid callback.
This can be potentially re-introduced by using the pre_enable()
callback but this needs to be evaluated first whether such an
approach will work so this will be done with a separate change.
changes since RFC:
- Fix commit text and add TODO comment
changes in v2:
- Fix checkpatch formatting errors
Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
dynamically")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Robert Foss
Link:
https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
3 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index a031a0cd1f18..1053d185b24c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -405,7 +405,8 @@ static inline int adv7511_cec_init(struct device *dev,
struct adv7511 *adv7511)
void adv7533_dsi_power_on(struct adv7511 *adv);
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On Sat, Mar 11, 2023 at 4:02 PM Dmitry Baryshkov
wrote:
>
> On 11/03/2023 23:53, Adam Ford wrote:
> > On Sat, Mar 11, 2023 at 3:40 PM Dmitry Baryshkov
> > wrote:
> >>
> >> "Hi Abhinav,
> >>
> >> On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar
> >> wrote:
> >>>
> >>> Hi Adam
> >>>
> >>> On 3/11/2023 9:28 AM, Adam Ford wrote:
> On Thu, Oct 13, 2022 at 3:39 AM Robert Foss
> wrote:
> >
> > On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar
> > wrote:
> >>
> >> adv7533 bridge tries to dynamically switch lanes based on the
> >> mode by detaching and attaching the mipi dsi device.
> >>
> >> This approach is incorrect because this method of dynamic switch of
> >> detaching and attaching the mipi dsi device also results in removing
> >> and adding the component which is not necessary.
> >>
> >> This approach is also prone to deadlocks. So for example, on the
> >> db410c whenever this path is executed with lockdep enabled,
> >> this results in a deadlock due to below ordering of locks.
> >>
> >> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> >> lock_acquire+0x6c/0x90
> >> drm_modeset_acquire_init+0xf4/0x150
> >> drmm_mode_config_init+0x220/0x770
> >> msm_drm_bind+0x13c/0x654
> >> try_to_bring_up_aggregate_device+0x164/0x1d0
> >> __component_add+0xa8/0x174
> >> component_add+0x18/0x2c
> >> dsi_dev_attach+0x24/0x30
> >> dsi_host_attach+0x98/0x14c
> >> devm_mipi_dsi_attach+0x38/0xb0
> >> adv7533_attach_dsi+0x8c/0x110
> >> adv7511_probe+0x5a0/0x930
> >> i2c_device_probe+0x30c/0x350
> >> really_probe.part.0+0x9c/0x2b0
> >> __driver_probe_device+0x98/0x144
> >> driver_probe_device+0xac/0x14c
> >> __device_attach_driver+0xbc/0x124
> >> bus_for_each_drv+0x78/0xd0
> >> __device_attach+0xa8/0x1c0
> >> device_initial_probe+0x18/0x24
> >> bus_probe_device+0xa0/0xac
> >> deferred_probe_work_func+0x90/0xd0
> >> process_one_work+0x28c/0x6b0
> >> worker_thread+0x240/0x444
> >> kthread+0x110/0x114
> >> ret_from_fork+0x10/0x20
> >>
> >> -> #0 (component_mutex){+.+.}-{3:3}:
> >> __lock_acquire+0x1280/0x20ac
> >> lock_acquire.part.0+0xe0/0x230
> >> lock_acquire+0x6c/0x90
> >> __mutex_lock+0x84/0x400
> >> mutex_lock_nested+0x3c/0x70
> >> component_del+0x34/0x170
> >> dsi_dev_detach+0x24/0x30
> >> dsi_host_detach+0x20/0x64
> >> mipi_dsi_detach+0x2c/0x40
> >> adv7533_mode_set+0x64/0x90
> >> adv7511_bridge_mode_set+0x210/0x214
> >> drm_bridge_chain_mode_set+0x5c/0x84
> >> crtc_set_mode+0x18c/0x1dc
> >> drm_atomic_helper_commit_modeset_disables+0x40/0x50
> >> msm_atomic_commit_tail+0x1d0/0x6e0
> >> commit_tail+0xa4/0x180
> >> drm_atomic_helper_commit+0x178/0x3b0
> >> drm_atomic_commit+0xa4/0xe0
> >> drm_client_modeset_commit_atomic+0x228/0x284
> >> drm_client_modeset_commit_locked+0x64/0x1d0
> >> drm_client_modeset_commit+0x34/0x60
> >> drm_fb_helper_lastclose+0x74/0xcc
> >> drm_lastclose+0x3c/0x80
> >> drm_release+0xfc/0x114
> >> __fput+0x70/0x224
> >> fput+0x14/0x20
> >> task_work_run+0x88/0x1a0
> >> do_exit+0x350/0xa50
> >> do_group_exit+0x38/0xa4
> >> __wake_up_parent+0x0/0x34
> >> invoke_syscall+0x48/0x114
> >> el0_svc_common.constprop.0+0x60/0x11c
> >> do_el0_svc+0x30/0xc0
> >> el0_svc+0x58/0x100
> >> el0t_64_sync_handler+0x1b0/0x1bc
> >> el0t_64_sync+0x18c/0x190
> >>
> >> Due to above reasons, remove the dynamic lane switching
> >> code from adv7533 bridge chip and filter out the modes
> >> which would need different number of lanes as compared
> >> to the initialization time using the mode_valid callback.
> >>
> >> This can be potentially re-introduced by using the pre_enable()
> >> callback but this needs to be evaluated first whether such an
> >> approach will work so this will be done with a separate change.
> >>
> >> changes since RFC:
> >> - Fix commit text and add TODO comment
> >>
> >> changes in v2:
> >> - Fix checkpatch formatting errors
> >>
> >> Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
> >> dynamically")
> >> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On 11/03/2023 23:53, Adam Ford wrote:
On Sat, Mar 11, 2023 at 3:40 PM Dmitry Baryshkov
wrote:
"Hi Abhinav,
On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar wrote:
Hi Adam
On 3/11/2023 9:28 AM, Adam Ford wrote:
On Thu, Oct 13, 2022 at 3:39 AM Robert Foss wrote:
On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of dynamic switch of
detaching and attaching the mipi dsi device also results in removing
and adding the component which is not necessary.
This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
lock_acquire+0x6c/0x90
drm_modeset_acquire_init+0xf4/0x150
drmm_mode_config_init+0x220/0x770
msm_drm_bind+0x13c/0x654
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x18/0x2c
dsi_dev_attach+0x24/0x30
dsi_host_attach+0x98/0x14c
devm_mipi_dsi_attach+0x38/0xb0
adv7533_attach_dsi+0x8c/0x110
adv7511_probe+0x5a0/0x930
i2c_device_probe+0x30c/0x350
really_probe.part.0+0x9c/0x2b0
__driver_probe_device+0x98/0x144
driver_probe_device+0xac/0x14c
__device_attach_driver+0xbc/0x124
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x90/0xd0
process_one_work+0x28c/0x6b0
worker_thread+0x240/0x444
kthread+0x110/0x114
ret_from_fork+0x10/0x20
-> #0 (component_mutex){+.+.}-{3:3}:
__lock_acquire+0x1280/0x20ac
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x6c/0x90
__mutex_lock+0x84/0x400
mutex_lock_nested+0x3c/0x70
component_del+0x34/0x170
dsi_dev_detach+0x24/0x30
dsi_host_detach+0x20/0x64
mipi_dsi_detach+0x2c/0x40
adv7533_mode_set+0x64/0x90
adv7511_bridge_mode_set+0x210/0x214
drm_bridge_chain_mode_set+0x5c/0x84
crtc_set_mode+0x18c/0x1dc
drm_atomic_helper_commit_modeset_disables+0x40/0x50
msm_atomic_commit_tail+0x1d0/0x6e0
commit_tail+0xa4/0x180
drm_atomic_helper_commit+0x178/0x3b0
drm_atomic_commit+0xa4/0xe0
drm_client_modeset_commit_atomic+0x228/0x284
drm_client_modeset_commit_locked+0x64/0x1d0
drm_client_modeset_commit+0x34/0x60
drm_fb_helper_lastclose+0x74/0xcc
drm_lastclose+0x3c/0x80
drm_release+0xfc/0x114
__fput+0x70/0x224
fput+0x14/0x20
task_work_run+0x88/0x1a0
do_exit+0x350/0xa50
do_group_exit+0x38/0xa4
__wake_up_parent+0x0/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x60/0x11c
do_el0_svc+0x30/0xc0
el0_svc+0x58/0x100
el0t_64_sync_handler+0x1b0/0x1bc
el0t_64_sync+0x18c/0x190
Due to above reasons, remove the dynamic lane switching
code from adv7533 bridge chip and filter out the modes
which would need different number of lanes as compared
to the initialization time using the mode_valid callback.
This can be potentially re-introduced by using the pre_enable()
callback but this needs to be evaluated first whether such an
approach will work so this will be done with a separate change.
changes since RFC:
- Fix commit text and add TODO comment
changes in v2:
- Fix checkpatch formatting errors
Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
dynamically")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Robert Foss
Link:
https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
3 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index a031a0cd1f18..1053d185b24c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -405,7 +405,8 @@ static inline int adv7511_cec_init(struct device *dev,
struct adv7511 *adv7511)
void adv7533_dsi_power_on(struct adv7511 *adv);
void adv7533_dsi_power_off(struct adv7511 *adv);
-void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
*mode);
+enum drm_mode_status
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On Sat, Mar 11, 2023 at 3:40 PM Dmitry Baryshkov
wrote:
>
> "Hi Abhinav,
>
> On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar wrote:
> >
> > Hi Adam
> >
> > On 3/11/2023 9:28 AM, Adam Ford wrote:
> > > On Thu, Oct 13, 2022 at 3:39 AM Robert Foss
> > > wrote:
> > >>
> > >> On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar
> > >> wrote:
> > >>>
> > >>> adv7533 bridge tries to dynamically switch lanes based on the
> > >>> mode by detaching and attaching the mipi dsi device.
> > >>>
> > >>> This approach is incorrect because this method of dynamic switch of
> > >>> detaching and attaching the mipi dsi device also results in removing
> > >>> and adding the component which is not necessary.
> > >>>
> > >>> This approach is also prone to deadlocks. So for example, on the
> > >>> db410c whenever this path is executed with lockdep enabled,
> > >>> this results in a deadlock due to below ordering of locks.
> > >>>
> > >>> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> > >>> lock_acquire+0x6c/0x90
> > >>> drm_modeset_acquire_init+0xf4/0x150
> > >>> drmm_mode_config_init+0x220/0x770
> > >>> msm_drm_bind+0x13c/0x654
> > >>> try_to_bring_up_aggregate_device+0x164/0x1d0
> > >>> __component_add+0xa8/0x174
> > >>> component_add+0x18/0x2c
> > >>> dsi_dev_attach+0x24/0x30
> > >>> dsi_host_attach+0x98/0x14c
> > >>> devm_mipi_dsi_attach+0x38/0xb0
> > >>> adv7533_attach_dsi+0x8c/0x110
> > >>> adv7511_probe+0x5a0/0x930
> > >>> i2c_device_probe+0x30c/0x350
> > >>> really_probe.part.0+0x9c/0x2b0
> > >>> __driver_probe_device+0x98/0x144
> > >>> driver_probe_device+0xac/0x14c
> > >>> __device_attach_driver+0xbc/0x124
> > >>> bus_for_each_drv+0x78/0xd0
> > >>> __device_attach+0xa8/0x1c0
> > >>> device_initial_probe+0x18/0x24
> > >>> bus_probe_device+0xa0/0xac
> > >>> deferred_probe_work_func+0x90/0xd0
> > >>> process_one_work+0x28c/0x6b0
> > >>> worker_thread+0x240/0x444
> > >>> kthread+0x110/0x114
> > >>> ret_from_fork+0x10/0x20
> > >>>
> > >>> -> #0 (component_mutex){+.+.}-{3:3}:
> > >>> __lock_acquire+0x1280/0x20ac
> > >>> lock_acquire.part.0+0xe0/0x230
> > >>> lock_acquire+0x6c/0x90
> > >>> __mutex_lock+0x84/0x400
> > >>> mutex_lock_nested+0x3c/0x70
> > >>> component_del+0x34/0x170
> > >>> dsi_dev_detach+0x24/0x30
> > >>> dsi_host_detach+0x20/0x64
> > >>> mipi_dsi_detach+0x2c/0x40
> > >>> adv7533_mode_set+0x64/0x90
> > >>> adv7511_bridge_mode_set+0x210/0x214
> > >>> drm_bridge_chain_mode_set+0x5c/0x84
> > >>> crtc_set_mode+0x18c/0x1dc
> > >>> drm_atomic_helper_commit_modeset_disables+0x40/0x50
> > >>> msm_atomic_commit_tail+0x1d0/0x6e0
> > >>> commit_tail+0xa4/0x180
> > >>> drm_atomic_helper_commit+0x178/0x3b0
> > >>> drm_atomic_commit+0xa4/0xe0
> > >>> drm_client_modeset_commit_atomic+0x228/0x284
> > >>> drm_client_modeset_commit_locked+0x64/0x1d0
> > >>> drm_client_modeset_commit+0x34/0x60
> > >>> drm_fb_helper_lastclose+0x74/0xcc
> > >>> drm_lastclose+0x3c/0x80
> > >>> drm_release+0xfc/0x114
> > >>> __fput+0x70/0x224
> > >>> fput+0x14/0x20
> > >>> task_work_run+0x88/0x1a0
> > >>> do_exit+0x350/0xa50
> > >>> do_group_exit+0x38/0xa4
> > >>> __wake_up_parent+0x0/0x34
> > >>> invoke_syscall+0x48/0x114
> > >>> el0_svc_common.constprop.0+0x60/0x11c
> > >>> do_el0_svc+0x30/0xc0
> > >>> el0_svc+0x58/0x100
> > >>> el0t_64_sync_handler+0x1b0/0x1bc
> > >>> el0t_64_sync+0x18c/0x190
> > >>>
> > >>> Due to above reasons, remove the dynamic lane switching
> > >>> code from adv7533 bridge chip and filter out the modes
> > >>> which would need different number of lanes as compared
> > >>> to the initialization time using the mode_valid callback.
> > >>>
> > >>> This can be potentially re-introduced by using the pre_enable()
> > >>> callback but this needs to be evaluated first whether such an
> > >>> approach will work so this will be done with a separate change.
> > >>>
> > >>> changes since RFC:
> > >>> - Fix commit text and add TODO comment
> > >>>
> > >>> changes in v2:
> > >>> - Fix checkpatch formatting errors
> > >>>
> > >>> Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
> > >>> dynamically")
> > >>> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
> > >>> Suggested-by: Dmitry Baryshkov
> > >>> Signed-off-by: Abhinav Kumar
> > >>> Reviewed-by: Robert Foss
> > >>> Link:
> > >>> https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
> > >>> ---
> > >>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
>
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
"Hi Abhinav,
On Sat, 11 Mar 2023 at 23:18, Abhinav Kumar wrote:
>
> Hi Adam
>
> On 3/11/2023 9:28 AM, Adam Ford wrote:
> > On Thu, Oct 13, 2022 at 3:39 AM Robert Foss wrote:
> >>
> >> On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar
> >> wrote:
> >>>
> >>> adv7533 bridge tries to dynamically switch lanes based on the
> >>> mode by detaching and attaching the mipi dsi device.
> >>>
> >>> This approach is incorrect because this method of dynamic switch of
> >>> detaching and attaching the mipi dsi device also results in removing
> >>> and adding the component which is not necessary.
> >>>
> >>> This approach is also prone to deadlocks. So for example, on the
> >>> db410c whenever this path is executed with lockdep enabled,
> >>> this results in a deadlock due to below ordering of locks.
> >>>
> >>> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> >>> lock_acquire+0x6c/0x90
> >>> drm_modeset_acquire_init+0xf4/0x150
> >>> drmm_mode_config_init+0x220/0x770
> >>> msm_drm_bind+0x13c/0x654
> >>> try_to_bring_up_aggregate_device+0x164/0x1d0
> >>> __component_add+0xa8/0x174
> >>> component_add+0x18/0x2c
> >>> dsi_dev_attach+0x24/0x30
> >>> dsi_host_attach+0x98/0x14c
> >>> devm_mipi_dsi_attach+0x38/0xb0
> >>> adv7533_attach_dsi+0x8c/0x110
> >>> adv7511_probe+0x5a0/0x930
> >>> i2c_device_probe+0x30c/0x350
> >>> really_probe.part.0+0x9c/0x2b0
> >>> __driver_probe_device+0x98/0x144
> >>> driver_probe_device+0xac/0x14c
> >>> __device_attach_driver+0xbc/0x124
> >>> bus_for_each_drv+0x78/0xd0
> >>> __device_attach+0xa8/0x1c0
> >>> device_initial_probe+0x18/0x24
> >>> bus_probe_device+0xa0/0xac
> >>> deferred_probe_work_func+0x90/0xd0
> >>> process_one_work+0x28c/0x6b0
> >>> worker_thread+0x240/0x444
> >>> kthread+0x110/0x114
> >>> ret_from_fork+0x10/0x20
> >>>
> >>> -> #0 (component_mutex){+.+.}-{3:3}:
> >>> __lock_acquire+0x1280/0x20ac
> >>> lock_acquire.part.0+0xe0/0x230
> >>> lock_acquire+0x6c/0x90
> >>> __mutex_lock+0x84/0x400
> >>> mutex_lock_nested+0x3c/0x70
> >>> component_del+0x34/0x170
> >>> dsi_dev_detach+0x24/0x30
> >>> dsi_host_detach+0x20/0x64
> >>> mipi_dsi_detach+0x2c/0x40
> >>> adv7533_mode_set+0x64/0x90
> >>> adv7511_bridge_mode_set+0x210/0x214
> >>> drm_bridge_chain_mode_set+0x5c/0x84
> >>> crtc_set_mode+0x18c/0x1dc
> >>> drm_atomic_helper_commit_modeset_disables+0x40/0x50
> >>> msm_atomic_commit_tail+0x1d0/0x6e0
> >>> commit_tail+0xa4/0x180
> >>> drm_atomic_helper_commit+0x178/0x3b0
> >>> drm_atomic_commit+0xa4/0xe0
> >>> drm_client_modeset_commit_atomic+0x228/0x284
> >>> drm_client_modeset_commit_locked+0x64/0x1d0
> >>> drm_client_modeset_commit+0x34/0x60
> >>> drm_fb_helper_lastclose+0x74/0xcc
> >>> drm_lastclose+0x3c/0x80
> >>> drm_release+0xfc/0x114
> >>> __fput+0x70/0x224
> >>> fput+0x14/0x20
> >>> task_work_run+0x88/0x1a0
> >>> do_exit+0x350/0xa50
> >>> do_group_exit+0x38/0xa4
> >>> __wake_up_parent+0x0/0x34
> >>> invoke_syscall+0x48/0x114
> >>> el0_svc_common.constprop.0+0x60/0x11c
> >>> do_el0_svc+0x30/0xc0
> >>> el0_svc+0x58/0x100
> >>> el0t_64_sync_handler+0x1b0/0x1bc
> >>> el0t_64_sync+0x18c/0x190
> >>>
> >>> Due to above reasons, remove the dynamic lane switching
> >>> code from adv7533 bridge chip and filter out the modes
> >>> which would need different number of lanes as compared
> >>> to the initialization time using the mode_valid callback.
> >>>
> >>> This can be potentially re-introduced by using the pre_enable()
> >>> callback but this needs to be evaluated first whether such an
> >>> approach will work so this will be done with a separate change.
> >>>
> >>> changes since RFC:
> >>> - Fix commit text and add TODO comment
> >>>
> >>> changes in v2:
> >>> - Fix checkpatch formatting errors
> >>>
> >>> Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
> >>> dynamically")
> >>> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
> >>> Suggested-by: Dmitry Baryshkov
> >>> Signed-off-by: Abhinav Kumar
> >>> Reviewed-by: Robert Foss
> >>> Link:
> >>> https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
> >>> ---
> >>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
> >>> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
> >>> drivers/gpu/drm/bridge/adv7511/adv7533.c | 25
> >>> +
> >>> 3 files changed, 29 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
Hi Adam
On 3/11/2023 9:28 AM, Adam Ford wrote:
On Thu, Oct 13, 2022 at 3:39 AM Robert Foss wrote:
On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of dynamic switch of
detaching and attaching the mipi dsi device also results in removing
and adding the component which is not necessary.
This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
lock_acquire+0x6c/0x90
drm_modeset_acquire_init+0xf4/0x150
drmm_mode_config_init+0x220/0x770
msm_drm_bind+0x13c/0x654
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x18/0x2c
dsi_dev_attach+0x24/0x30
dsi_host_attach+0x98/0x14c
devm_mipi_dsi_attach+0x38/0xb0
adv7533_attach_dsi+0x8c/0x110
adv7511_probe+0x5a0/0x930
i2c_device_probe+0x30c/0x350
really_probe.part.0+0x9c/0x2b0
__driver_probe_device+0x98/0x144
driver_probe_device+0xac/0x14c
__device_attach_driver+0xbc/0x124
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x90/0xd0
process_one_work+0x28c/0x6b0
worker_thread+0x240/0x444
kthread+0x110/0x114
ret_from_fork+0x10/0x20
-> #0 (component_mutex){+.+.}-{3:3}:
__lock_acquire+0x1280/0x20ac
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x6c/0x90
__mutex_lock+0x84/0x400
mutex_lock_nested+0x3c/0x70
component_del+0x34/0x170
dsi_dev_detach+0x24/0x30
dsi_host_detach+0x20/0x64
mipi_dsi_detach+0x2c/0x40
adv7533_mode_set+0x64/0x90
adv7511_bridge_mode_set+0x210/0x214
drm_bridge_chain_mode_set+0x5c/0x84
crtc_set_mode+0x18c/0x1dc
drm_atomic_helper_commit_modeset_disables+0x40/0x50
msm_atomic_commit_tail+0x1d0/0x6e0
commit_tail+0xa4/0x180
drm_atomic_helper_commit+0x178/0x3b0
drm_atomic_commit+0xa4/0xe0
drm_client_modeset_commit_atomic+0x228/0x284
drm_client_modeset_commit_locked+0x64/0x1d0
drm_client_modeset_commit+0x34/0x60
drm_fb_helper_lastclose+0x74/0xcc
drm_lastclose+0x3c/0x80
drm_release+0xfc/0x114
__fput+0x70/0x224
fput+0x14/0x20
task_work_run+0x88/0x1a0
do_exit+0x350/0xa50
do_group_exit+0x38/0xa4
__wake_up_parent+0x0/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x60/0x11c
do_el0_svc+0x30/0xc0
el0_svc+0x58/0x100
el0t_64_sync_handler+0x1b0/0x1bc
el0t_64_sync+0x18c/0x190
Due to above reasons, remove the dynamic lane switching
code from adv7533 bridge chip and filter out the modes
which would need different number of lanes as compared
to the initialization time using the mode_valid callback.
This can be potentially re-introduced by using the pre_enable()
callback but this needs to be evaluated first whether such an
approach will work so this will be done with a separate change.
changes since RFC:
- Fix commit text and add TODO comment
changes in v2:
- Fix checkpatch formatting errors
Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
dynamically")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Robert Foss
Link:
https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
3 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index a031a0cd1f18..1053d185b24c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -405,7 +405,8 @@ static inline int adv7511_cec_init(struct device *dev,
struct adv7511 *adv7511)
void adv7533_dsi_power_on(struct adv7511 *adv);
void adv7533_dsi_power_off(struct adv7511 *adv);
-void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
*mode);
+enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
+ const struct drm_display_mode *mode);
int adv7533_patch_registers(struct adv7511 *adv);
int adv7533_patch_cec_registers(struct adv7511 *adv);
int
Re: [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On Fri, 10 Mar 2023 16:33:58 -0800, Ashutosh Dixit wrote: > > On dGfx, the PL1 power limit being enabled and set to a low value results > in a low GPU operating freq. It also negates the freq raise operation which > is done before GuC firmware load. As a result GuC firmware load can time > out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power > limit was enabled and set to a low value). Therefore disable the PL1 power > limit when possible when loading GuC firmware. There are a couple of bugs in the patch. Please don't review yet, will post a v2. Thanks.
[no subject]
Date: Sat, 11 Mar 2023 19:00:03 + Subject: [PATCH 5.10 1/1] drm/amdgpu: add error handling for drm_fb_helper_initial_config The type of return value of drm_fb_helper_initial_config is int, which may return wrong result, so we add error handling for it to reclaim memory resource, and return when an error occurs. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d38ceaf99ed0 (drm/amdgpu: add core driver (v4)) Signed-off-by: Danila Chernetsov --- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c index 43f29ee0e3b0..e445a2c9f569 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c @@ -348,8 +348,17 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev) if (!amdgpu_device_has_dc_support(adev)) drm_helper_disable_unused_functions(adev_to_drm(adev)); - drm_fb_helper_initial_config(>helper, bpp_sel); - return 0; + ret = drm_fb_helper_initial_config(>helper, bpp_sel); + if (ret) + goto fini; + + return 0; + +fini: + drm_fb_helper_fini(>helper); + + kfree(rfbdev); + return ret; } void amdgpu_fbdev_fini(struct amdgpu_device *adev) -- 2.25.1
[PATCH 2/2] backlight: arcxcnn_bl: drop of_match_ptr for ID table
The driver will match mostly by DT table (even thought there is regular
ID table) so there is little benefit in of_match_ptr (this also allows
ACPI matching via PRP0001, even though it might not be relevant here).
drivers/video/backlight/arcxcnn_bl.c:378:34: error: ‘arcxcnn_dt_ids’ defined
but not used [-Werror=unused-const-variable=]
Signed-off-by: Krzysztof Kozlowski
---
drivers/video/backlight/arcxcnn_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/arcxcnn_bl.c
b/drivers/video/backlight/arcxcnn_bl.c
index e610d7a1d13d..088bcca547dd 100644
--- a/drivers/video/backlight/arcxcnn_bl.c
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -390,7 +390,7 @@ MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
static struct i2c_driver arcxcnn_driver = {
.driver = {
.name = "arcxcnn_bl",
- .of_match_table = of_match_ptr(arcxcnn_dt_ids),
+ .of_match_table = arcxcnn_dt_ids,
},
.probe_new = arcxcnn_probe,
.remove = arcxcnn_remove,
--
2.34.1
[PATCH 1/2] backlight: lp855x: mark OF related data as maybe unused
The driver can be compile tested with !CONFIG_OF making certain data
unused:
drivers/video/backlight/lp855x_bl.c:551:34: error: ‘lp855x_dt_ids’ defined
but not used [-Werror=unused-const-variable=]
Signed-off-by: Krzysztof Kozlowski
---
drivers/video/backlight/lp855x_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index 81012bf29baf..a57c9ef3b1cc 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -548,7 +548,7 @@ static void lp855x_remove(struct i2c_client *cl)
sysfs_remove_group(>dev->kobj, _attr_group);
}
-static const struct of_device_id lp855x_dt_ids[] = {
+static const struct of_device_id lp855x_dt_ids[] __maybe_unused = {
{ .compatible = "ti,lp8550", },
{ .compatible = "ti,lp8551", },
{ .compatible = "ti,lp8552", },
--
2.34.1
[PATCH 1/2] dma-buf/dma-fence: Add dma_fence_init_noref()
From: Rob Clark
Add a way to initialize a fence without touching the refcount. This is
useful, for example, if the fence is embedded in a drm_sched_job. In
this case the refcount will be initialized before the job is queued.
But the seqno of the hw_fence is not known until job_run().
Signed-off-by: Rob Clark
---
drivers/dma-buf/dma-fence.c | 43 -
include/linux/dma-fence.h | 2 ++
2 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 74e36f6d05b0..97c05a465cb4 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -989,28 +989,27 @@ void dma_fence_describe(struct dma_fence *fence, struct
seq_file *seq)
EXPORT_SYMBOL(dma_fence_describe);
/**
- * dma_fence_init - Initialize a custom fence.
+ * dma_fence_init_noref - Initialize a custom fence without initializing
refcount.
* @fence: the fence to initialize
* @ops: the dma_fence_ops for operations on this fence
* @lock: the irqsafe spinlock to use for locking this fence
* @context: the execution context this fence is run on
* @seqno: a linear increasing sequence number for this context
*
- * Initializes an allocated fence, the caller doesn't have to keep its
- * refcount after committing with this fence, but it will need to hold a
- * refcount again if _fence_ops.enable_signaling gets called.
- *
- * context and seqno are used for easy comparison between fences, allowing
- * to check which fence is later by simply using dma_fence_later().
+ * Like _fence_init but does not initialize the refcount. Suitable
+ * for cases where the fence is embedded in another struct which has it's
+ * refcount initialized before the fence is initialized. Such as embedding
+ * in a _sched_job, where the job is created before knowing the seqno
+ * of the hw_fence.
*/
void
-dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
- spinlock_t *lock, u64 context, u64 seqno)
+dma_fence_init_noref(struct dma_fence *fence, const struct dma_fence_ops *ops,
+spinlock_t *lock, u64 context, u64 seqno)
{
BUG_ON(!lock);
BUG_ON(!ops || !ops->get_driver_name || !ops->get_timeline_name);
+ BUG_ON(!kref_read(>refcount));
- kref_init(>refcount);
fence->ops = ops;
INIT_LIST_HEAD(>cb_list);
fence->lock = lock;
@@ -1021,4 +1020,28 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
trace_dma_fence_init(fence);
}
+EXPORT_SYMBOL(dma_fence_init_noref);
+
+/**
+ * dma_fence_init - Initialize a custom fence.
+ * @fence: the fence to initialize
+ * @ops: the dma_fence_ops for operations on this fence
+ * @lock: the irqsafe spinlock to use for locking this fence
+ * @context: the execution context this fence is run on
+ * @seqno: a linear increasing sequence number for this context
+ *
+ * Initializes an allocated fence, the caller doesn't have to keep its
+ * refcount after committing with this fence, but it will need to hold a
+ * refcount again if _fence_ops.enable_signaling gets called.
+ *
+ * context and seqno are used for easy comparison between fences, allowing
+ * to check which fence is later by simply using dma_fence_later().
+ */
+void
+dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
+ spinlock_t *lock, u64 context, u64 seqno)
+{
+ kref_init(>refcount);
+ dma_fence_init_noref(fence, ops, lock, context, seqno);
+}
EXPORT_SYMBOL(dma_fence_init);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index d54b595a0fe0..f617c78a2e0a 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -279,6 +279,8 @@ struct dma_fence_ops {
void (*set_deadline)(struct dma_fence *fence, ktime_t deadline);
};
+void dma_fence_init_noref(struct dma_fence *fence, const struct dma_fence_ops
*ops,
+ spinlock_t *lock, u64 context, u64 seqno);
void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
spinlock_t *lock, u64 context, u64 seqno);
--
2.39.2
[PATCH 0/2] drm/msm: Get rid of fence allocation in job_run()
From: Rob Clark Inspired by https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/ it seemed like a good idea to get rid of memory allocation in job_run() by embedding the hw dma_fence in the job/submit struct. Applies on top of https://patchwork.freedesktop.org/series/93035/ but I can re-work it to swap the order. I think the first patch would be useful to amdgpu and perhaps anyone else embedding the hw_fence in the struct containing drm_sched_job. Rob Clark (2): dma-buf/dma-fence: Add dma_fence_init_noref() drm/msm: Embed the hw_fence in msm_gem_submit drivers/dma-buf/dma-fence.c | 43 +++--- drivers/gpu/drm/msm/msm_fence.c | 45 +++- drivers/gpu/drm/msm/msm_fence.h | 2 +- drivers/gpu/drm/msm/msm_gem.h| 10 +++ drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++--- drivers/gpu/drm/msm/msm_gpu.c| 4 +-- drivers/gpu/drm/msm/msm_ringbuffer.c | 4 +-- include/linux/dma-fence.h| 2 ++ 8 files changed, 66 insertions(+), 52 deletions(-) -- 2.39.2
[PATCH 2/2] drm/msm: Embed the hw_fence in msm_gem_submit
From: Rob Clark
Avoid allocating memory in job_run() by embedding the fence in the
submit object. Since msm gpu fences are always 1:1 with msm_gem_submit
we can just use the fence's refcnt to track the submit. And since we
can get the fence ctx from the submit we can just drop the msm_fence
struct altogether. This uses the new dma_fence_init_noref() to deal
with the fact that the fence's refcnt is initialized when the submit is
created, long before job_run().
Signed-off-by: Rob Clark
---
Note that this applies on top of https://patchwork.freedesktop.org/series/93035/
out of convenience for myself, but I can re-work it to go before
depending on the order that things land.
drivers/gpu/drm/msm/msm_fence.c | 45 +++-
drivers/gpu/drm/msm/msm_fence.h | 2 +-
drivers/gpu/drm/msm/msm_gem.h| 10 +++
drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++---
drivers/gpu/drm/msm/msm_gpu.c| 4 +--
drivers/gpu/drm/msm/msm_ringbuffer.c | 4 +--
6 files changed, 31 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index 51b461f32103..51f9f1f0cb66 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -103,14 +103,9 @@ void msm_update_fence(struct msm_fence_context *fctx,
uint32_t fence)
spin_unlock_irqrestore(>spinlock, flags);
}
-struct msm_fence {
- struct dma_fence base;
- struct msm_fence_context *fctx;
-};
-
-static inline struct msm_fence *to_msm_fence(struct dma_fence *fence)
+static inline struct msm_gem_submit *fence_to_submit(struct dma_fence *fence)
{
- return container_of(fence, struct msm_fence, base);
+ return container_of(fence, struct msm_gem_submit, hw_fence);
}
static const char *msm_fence_get_driver_name(struct dma_fence *fence)
@@ -120,20 +115,20 @@ static const char *msm_fence_get_driver_name(struct
dma_fence *fence)
static const char *msm_fence_get_timeline_name(struct dma_fence *fence)
{
- struct msm_fence *f = to_msm_fence(fence);
- return f->fctx->name;
+ struct msm_gem_submit *submit = fence_to_submit(fence);
+ return submit->ring->fctx->name;
}
static bool msm_fence_signaled(struct dma_fence *fence)
{
- struct msm_fence *f = to_msm_fence(fence);
- return msm_fence_completed(f->fctx, f->base.seqno);
+ struct msm_gem_submit *submit = fence_to_submit(fence);
+ return msm_fence_completed(submit->ring->fctx, fence->seqno);
}
static void msm_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
{
- struct msm_fence *f = to_msm_fence(fence);
- struct msm_fence_context *fctx = f->fctx;
+ struct msm_gem_submit *submit = fence_to_submit(fence);
+ struct msm_fence_context *fctx = submit->ring->fctx;
unsigned long flags;
ktime_t now;
@@ -165,26 +160,22 @@ static void msm_fence_set_deadline(struct dma_fence
*fence, ktime_t deadline)
spin_unlock_irqrestore(>spinlock, flags);
}
+static void msm_fence_release(struct dma_fence *fence)
+{
+ __msm_gem_submit_destroy(fence_to_submit(fence));
+}
+
static const struct dma_fence_ops msm_fence_ops = {
.get_driver_name = msm_fence_get_driver_name,
.get_timeline_name = msm_fence_get_timeline_name,
.signaled = msm_fence_signaled,
.set_deadline = msm_fence_set_deadline,
+ .release = msm_fence_release,
};
-struct dma_fence *
-msm_fence_alloc(struct msm_fence_context *fctx)
+void
+msm_fence_init(struct msm_fence_context *fctx, struct dma_fence *f)
{
- struct msm_fence *f;
-
- f = kzalloc(sizeof(*f), GFP_KERNEL);
- if (!f)
- return ERR_PTR(-ENOMEM);
-
- f->fctx = fctx;
-
- dma_fence_init(>base, _fence_ops, >spinlock,
- fctx->context, ++fctx->last_fence);
-
- return >base;
+ dma_fence_init_noref(f, _fence_ops, >spinlock,
+fctx->context, ++fctx->last_fence);
}
diff --git a/drivers/gpu/drm/msm/msm_fence.h b/drivers/gpu/drm/msm/msm_fence.h
index cdaebfb94f5c..8fca37e9773b 100644
--- a/drivers/gpu/drm/msm/msm_fence.h
+++ b/drivers/gpu/drm/msm/msm_fence.h
@@ -81,7 +81,7 @@ void msm_fence_context_free(struct msm_fence_context *fctx);
bool msm_fence_completed(struct msm_fence_context *fctx, uint32_t fence);
void msm_update_fence(struct msm_fence_context *fctx, uint32_t fence);
-struct dma_fence * msm_fence_alloc(struct msm_fence_context *fctx);
+void msm_fence_init(struct msm_fence_context *fctx, struct dma_fence *f);
static inline bool
fence_before(uint32_t a, uint32_t b)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c4844cf3a585..e06afed99d5b 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -259,10 +259,10 @@ struct msm_gem_submit {
struct ww_acquire_ctx ticket;
uint32_t seqno; /* Sequence number of the submit on the ring
Re: [PATCH v2] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
On Thu, Oct 13, 2022 at 3:39 AM Robert Foss wrote:
>
> On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
> >
> > adv7533 bridge tries to dynamically switch lanes based on the
> > mode by detaching and attaching the mipi dsi device.
> >
> > This approach is incorrect because this method of dynamic switch of
> > detaching and attaching the mipi dsi device also results in removing
> > and adding the component which is not necessary.
> >
> > This approach is also prone to deadlocks. So for example, on the
> > db410c whenever this path is executed with lockdep enabled,
> > this results in a deadlock due to below ordering of locks.
> >
> > -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> > lock_acquire+0x6c/0x90
> > drm_modeset_acquire_init+0xf4/0x150
> > drmm_mode_config_init+0x220/0x770
> > msm_drm_bind+0x13c/0x654
> > try_to_bring_up_aggregate_device+0x164/0x1d0
> > __component_add+0xa8/0x174
> > component_add+0x18/0x2c
> > dsi_dev_attach+0x24/0x30
> > dsi_host_attach+0x98/0x14c
> > devm_mipi_dsi_attach+0x38/0xb0
> > adv7533_attach_dsi+0x8c/0x110
> > adv7511_probe+0x5a0/0x930
> > i2c_device_probe+0x30c/0x350
> > really_probe.part.0+0x9c/0x2b0
> > __driver_probe_device+0x98/0x144
> > driver_probe_device+0xac/0x14c
> > __device_attach_driver+0xbc/0x124
> > bus_for_each_drv+0x78/0xd0
> > __device_attach+0xa8/0x1c0
> > device_initial_probe+0x18/0x24
> > bus_probe_device+0xa0/0xac
> > deferred_probe_work_func+0x90/0xd0
> > process_one_work+0x28c/0x6b0
> > worker_thread+0x240/0x444
> > kthread+0x110/0x114
> > ret_from_fork+0x10/0x20
> >
> > -> #0 (component_mutex){+.+.}-{3:3}:
> > __lock_acquire+0x1280/0x20ac
> > lock_acquire.part.0+0xe0/0x230
> > lock_acquire+0x6c/0x90
> > __mutex_lock+0x84/0x400
> > mutex_lock_nested+0x3c/0x70
> > component_del+0x34/0x170
> > dsi_dev_detach+0x24/0x30
> > dsi_host_detach+0x20/0x64
> > mipi_dsi_detach+0x2c/0x40
> > adv7533_mode_set+0x64/0x90
> > adv7511_bridge_mode_set+0x210/0x214
> > drm_bridge_chain_mode_set+0x5c/0x84
> > crtc_set_mode+0x18c/0x1dc
> > drm_atomic_helper_commit_modeset_disables+0x40/0x50
> > msm_atomic_commit_tail+0x1d0/0x6e0
> > commit_tail+0xa4/0x180
> > drm_atomic_helper_commit+0x178/0x3b0
> > drm_atomic_commit+0xa4/0xe0
> > drm_client_modeset_commit_atomic+0x228/0x284
> > drm_client_modeset_commit_locked+0x64/0x1d0
> > drm_client_modeset_commit+0x34/0x60
> > drm_fb_helper_lastclose+0x74/0xcc
> > drm_lastclose+0x3c/0x80
> > drm_release+0xfc/0x114
> > __fput+0x70/0x224
> > fput+0x14/0x20
> > task_work_run+0x88/0x1a0
> > do_exit+0x350/0xa50
> > do_group_exit+0x38/0xa4
> > __wake_up_parent+0x0/0x34
> > invoke_syscall+0x48/0x114
> > el0_svc_common.constprop.0+0x60/0x11c
> > do_el0_svc+0x30/0xc0
> > el0_svc+0x58/0x100
> > el0t_64_sync_handler+0x1b0/0x1bc
> > el0t_64_sync+0x18c/0x190
> >
> > Due to above reasons, remove the dynamic lane switching
> > code from adv7533 bridge chip and filter out the modes
> > which would need different number of lanes as compared
> > to the initialization time using the mode_valid callback.
> >
> > This can be potentially re-introduced by using the pre_enable()
> > callback but this needs to be evaluated first whether such an
> > approach will work so this will be done with a separate change.
> >
> > changes since RFC:
> > - Fix commit text and add TODO comment
> >
> > changes in v2:
> > - Fix checkpatch formatting errors
> >
> > Fixes: 62b2f026cd8e ("drm/bridge: adv7533: Change number of DSI lanes
> > dynamically")
> > Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16
> > Suggested-by: Dmitry Baryshkov
> > Signed-off-by: Abhinav Kumar
> > Reviewed-by: Robert Foss
> > Link:
> > https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhin...@quicinc.com
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
> > 3 files changed, 29 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > index a031a0cd1f18..1053d185b24c 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > @@ -405,7 +405,8 @@ static inline int adv7511_cec_init(struct device *dev,
> > struct adv7511 *adv7511)
> >
> > void adv7533_dsi_power_on(struct adv7511 *adv);
> > void adv7533_dsi_power_off(struct adv7511 *adv);
> > -void
Re: [PATCH] fbdev: Use of_property_present() for testing DT property presence
On Fri, Mar 10, 2023 at 10:41 PM kernel test robot wrote: > > Hi Rob, > > I love your patch! Yet something to improve: > > [auto build test ERROR on drm-misc/drm-misc-next] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: > https://github.com/intel-lab-lkp/linux/commits/Rob-Herring/fbdev-Use-of_property_present-for-testing-DT-property-presence/20230310-225754 > base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next > patch link: > https://lore.kernel.org/r/20230310144729.1545943-1-robh%40kernel.org > patch subject: [PATCH] fbdev: Use of_property_present() for testing DT > property presence > config: arm64-randconfig-r032-20230310 > (https://download.01.org/0day-ci/archive/20230311/202303111229.3uuc8jqv-...@intel.com/config) > compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project > 67409911353323ca5edf2049ef0df54132fa1ca7) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://github.com/intel-lab-lkp/linux/commit/c013f4111f36b0b4327e7fbf46c0dd93399e9209 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review > Rob-Herring/fbdev-Use-of_property_present-for-testing-DT-property-presence/20230310-225754 > git checkout c013f4111f36b0b4327e7fbf46c0dd93399e9209 Looks like this patch was applied to drm-next which was/is based on v6.2-rc6. This patch is dependent on a change in v6.3-rc1. Rob
Re: [PATCH] fbdev: Use of_property_present() for testing DT property presence
Hi Rob,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Rob-Herring/fbdev-Use-of_property_present-for-testing-DT-property-presence/20230310-225754
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230310144729.1545943-1-robh%40kernel.org
patch subject: [PATCH] fbdev: Use of_property_present() for testing DT property
presence
config: arm-allyesconfig
(https://download.01.org/0day-ci/archive/20230311/202303112153.upbfjeui-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/c013f4111f36b0b4327e7fbf46c0dd93399e9209
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Rob-Herring/fbdev-Use-of_property_present-for-testing-DT-property-presence/20230310-225754
git checkout c013f4111f36b0b4327e7fbf46c0dd93399e9209
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arm olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arm SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303112153.upbfjeui-...@intel.com/
All errors (new ones prefixed by >>):
drivers/video/fbdev/amba-clcd.c: In function 'clcdfb_of_get_board':
>> drivers/video/fbdev/amba-clcd.c:857:13: error: implicit declaration of
>> function 'of_property_present'; did you mean 'fwnode_property_present'?
>> [-Werror=implicit-function-declaration]
857 | if (of_property_present(node, "memory-region")) {
| ^~~
| fwnode_property_present
cc1: some warnings being treated as errors
vim +857 drivers/video/fbdev/amba-clcd.c
843
844 static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
845 {
846 struct clcd_board *board = devm_kzalloc(>dev,
sizeof(*board),
847 GFP_KERNEL);
848 struct device_node *node = dev->dev.of_node;
849
850 if (!board)
851 return NULL;
852
853 board->name = of_node_full_name(node);
854 board->caps = CLCD_CAP_ALL;
855 board->check = clcdfb_check;
856 board->decode = clcdfb_decode;
> 857 if (of_property_present(node, "memory-region")) {
858 board->setup = clcdfb_of_vram_setup;
859 board->mmap = clcdfb_of_vram_mmap;
860 board->remove = clcdfb_of_vram_remove;
861 } else {
862 board->setup = clcdfb_of_dma_setup;
863 board->mmap = clcdfb_of_dma_mmap;
864 board->remove = clcdfb_of_dma_remove;
865 }
866
867 return board;
868 }
869 #else
870 static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
871 {
872 return NULL;
873 }
874 #endif
875
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[PATCH v3 2/2] drm/format-helper: Make "destination_pitch" test case usable for the monochrome case
This test case uses an arbitrary pitch size, different of the default
one, to test if the conversions methods obey.
Change the "destination_pitch" colors to change the monochrome expected
result from being just zeros, as this makes the arbitrary pitch use
unusable.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 78 +--
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 041b3d2f100f..bfa47f8ffd09 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -323,104 +323,104 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.pitch = 3 * 4,
.clip = DRM_RECT_INIT(0, 0, 3, 3),
.xrgb = {
- 0xA10E449C, 0xB1114D05, 0xC1A80303,
- 0xD16C7073, 0xA20E449C, 0xB2114D05,
- 0xC2A80303, 0xD26C7073, 0xA30E449C,
+ 0xA10E449C, 0xB1114D05, 0xC1A8F303,
+ 0xD16CF073, 0xA20E449C, 0xB2114D05,
+ 0xC2A80303, 0xD26CF073, 0xA30E449C,
},
.gray8_result = {
.dst_pitch = 5,
.expected = {
- 0x3C, 0x33, 0x34, 0x00, 0x00,
- 0x6F, 0x3C, 0x33, 0x00, 0x00,
- 0x34, 0x6F, 0x3C, 0x00, 0x00,
+ 0x3C, 0x33, 0xC4, 0x00, 0x00,
+ 0xBB, 0x3C, 0x33, 0x00, 0x00,
+ 0x34, 0xBB, 0x3C, 0x00, 0x00,
},
},
.rgb332_result = {
.dst_pitch = 5,
.expected = {
- 0x0A, 0x08, 0xA0, 0x00, 0x00,
- 0x6D, 0x0A, 0x08, 0x00, 0x00,
- 0xA0, 0x6D, 0x0A, 0x00, 0x00,
+ 0x0A, 0x08, 0xBC, 0x00, 0x00,
+ 0x7D, 0x0A, 0x08, 0x00, 0x00,
+ 0xA0, 0x7D, 0x0A, 0x00, 0x00,
},
},
.rgb565_result = {
.dst_pitch = 10,
.expected = {
- 0x0A33, 0x1260, 0xA800, 0x, 0x,
- 0x6B8E, 0x0A33, 0x1260, 0x, 0x,
- 0xA800, 0x6B8E, 0x0A33, 0x, 0x,
+ 0x0A33, 0x1260, 0xAF80, 0x, 0x,
+ 0x6F8E, 0x0A33, 0x1260, 0x, 0x,
+ 0xA800, 0x6F8E, 0x0A33, 0x, 0x,
},
.expected_swab = {
- 0x330A, 0x6012, 0x00A8, 0x, 0x,
- 0x8E6B, 0x330A, 0x6012, 0x, 0x,
- 0x00A8, 0x8E6B, 0x330A, 0x, 0x,
+ 0x330A, 0x6012, 0x80AF, 0x, 0x,
+ 0x8E6F, 0x330A, 0x6012, 0x, 0x,
+ 0x00A8, 0x8E6F, 0x330A, 0x, 0x,
},
},
.xrgb1555_result = {
.dst_pitch = 10,
.expected = {
- 0x0513, 0x0920, 0x5400, 0x, 0x,
- 0x35CE, 0x0513, 0x0920, 0x, 0x,
- 0x5400, 0x35CE, 0x0513, 0x, 0x,
+ 0x0513, 0x0920, 0x57C0, 0x, 0x,
+ 0x37CE, 0x0513, 0x0920, 0x, 0x,
+ 0x5400, 0x37CE, 0x0513, 0x, 0x,
},
},
.argb1555_result = {
.dst_pitch = 10,
.expected = {
- 0x8513, 0x8920, 0xD400, 0x, 0x,
- 0xB5CE, 0x8513, 0x8920, 0x, 0x,
- 0xD400, 0xB5CE, 0x8513, 0x, 0x,
+ 0x8513, 0x8920, 0xD7C0, 0x, 0x,
+ 0xB7CE, 0x8513, 0x8920, 0x, 0x,
+ 0xD400, 0xB7CE, 0x8513, 0x, 0x,
},
},
.rgba5551_result = {
.dst_pitch = 10,
.expected = {
- 0x0A27, 0x1241, 0xA801, 0x, 0x,
- 0x6B9D, 0x0A27, 0x1241, 0x, 0x,
- 0xA801, 0x6B9D, 0x0A27, 0x, 0x,
+ 0x0A27, 0x1241, 0xAF81,
[PATCH v3 1/2] drm/format-helper: Add Kunit tests for drm_fb_xrgb8888_to_mono()
Extend the existing test cases to test the conversion from XRGB to
monochromatic.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 62 +++
1 file changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 84b5cc29c8fc..041b3d2f100f 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -67,6 +67,11 @@ struct convert_to_argb2101010_result {
const u32 expected[TEST_BUF_SIZE];
};
+struct convert_to_mono_result {
+ unsigned int dst_pitch;
+ const u8 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -82,6 +87,7 @@ struct convert_xrgb_case {
struct convert_to_argb_result argb_result;
struct convert_to_xrgb2101010_result xrgb2101010_result;
struct convert_to_argb2101010_result argb2101010_result;
+ struct convert_to_mono_result mono_result;
};
static struct convert_xrgb_case convert_xrgb_cases[] = {
@@ -131,6 +137,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = 0,
.expected = { 0xFFF0 },
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = { 0b0 },
+ },
},
{
.name = "single_pixel_clip_rectangle",
@@ -181,6 +191,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = 0,
.expected = { 0xFFF0 },
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = { 0b0 },
+ },
},
{
/* Well known colors: White, black, red, green, blue, magenta,
@@ -293,6 +307,15 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0xFC00, 0xC00F,
},
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = {
+ 0b01,
+ 0b10,
+ 0b00,
+ 0b11,
+ },
+ },
},
{
/* Randomly picked colors. Full buffer within the clip area. */
@@ -392,6 +415,14 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0xEA20300C, 0xDB1705CD, 0xC3844672, 0x,
0x,
},
},
+ .mono_result = {
+ .dst_pitch = 2,
+ .expected = {
+ 0b000, 0b000,
+ 0b000, 0b000,
+ 0b000, 0b000,
+ },
+ },
},
};
@@ -792,6 +823,36 @@ static void drm_test_fb_xrgb_to_argb2101010(struct
kunit *test)
KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
+static void drm_test_fb_xrgb_to_mono(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct convert_to_mono_result *result = >mono_result;
+ size_t dst_size;
+ u8 *buf = NULL;
+ __le32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size(DRM_FORMAT_C1, result->dst_pitch,
>clip);
+
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(, buf);
+
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(, xrgb);
+
+ drm_fb_xrgb_to_mono(, >dst_pitch, , ,
>clip);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_gray8,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_rgb332,
convert_xrgb_gen_params),
@@ -803,6 +864,7 @@ static struct kunit_case drm_format_helper_test_cases[] = {
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_argb,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_xrgb2101010,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_argb2101010,
convert_xrgb_gen_params),
+
[PATCH v3 0/2] drm/format-helper: Add Kunit tests for drm_fb_xrgb8888_to_mono()
This patchset aims to insert a unit test for the conversion from XRGB to monochromatic. Previously this was a single patch, but as the changes grew from v1 to v2, I thought it would be better to split it in two. Thanks for reviewing! Best regards, ~Arthur Grillo --- v1->v2: https://lore.kernel.org/all/20230302200131.754154-1-arthurgri...@riseup.net/ - Remove extra helper an use the existing one that Javier patched [1]. - Make the expected results more intuitive by using the BIT macro. - Change the "destination_pitch" test case colors. v2->v3: https://lore.kernel.org/all/20230310200901.216971-1-arthurgri...@riseup.net/ - Use binary constants instead of the BIT macros, to suppress a warning pointed out by the kernel bot and still maintain the intuitive intention. --- [1]: https://lore.kernel.org/all/20230307215039.346863-1-javi...@redhat.com/ --- Arthur Grillo (2): drm/format-helper: Add Kunit tests for drm_fb_xrgb_to_mono() drm/format-helper: Make "destination_pitch" test case usable for the monochrome case .../gpu/drm/tests/drm_format_helper_test.c| 134 +- 1 file changed, 98 insertions(+), 36 deletions(-) -- 2.39.2
Re: [PATCH v5 2/2] drm/panel: Add driver for Novatek NT36523
On Sat, Mar 11, 2023 at 01:38:52PM +0100, Konrad Dybcio wrote:
>
>
> On 11.03.2023 13:32, Jianhua Lu wrote:
> > Add a driver for panels using the Novatek NT36523 display driver IC.
> >
> > Signed-off-by: Jianhua Lu
> > ---
> [...]
>
> > +
> > +static int nt36523_get_modes(struct drm_panel *panel,
> > + struct drm_connector *connector)
> > +{
> > + struct panel_info *pinfo = to_panel_info(panel);
> > + int i;
> > +
> > + for (i = 0; i < pinfo->desc->num_modes; i++) {
> > + const struct drm_display_mode *m = >desc->modes[i];
> > + struct drm_display_mode *mode;
> > +
> > + mode = drm_mode_duplicate(connector->dev, m);
> > + if (!mode) {
> > + dev_err(panel->dev, "failed to add mode %ux%u@%u\n",
> > + m->hdisplay, m->vdisplay, drm_mode_vrefresh(m));
> > + return -ENOMEM;
> > + }
> > +
> > + mode->type = DRM_MODE_TYPE_DRIVER;
> > + if (pinfo->desc->num_modes == 1)
> > + mode->type |= DRM_MODE_TYPE_PREFERRED;
> That's not quite correct, as that means "if you have more than one
> defined panel mode (say 60Hz and 120 Hz), there will be no preferred one".
This piece of code I see in the other panels, so I'm not sure if it is
correct. Should
if (pinfo->desc->num_modes > 1)
mode->type |= DRM_MODE_TYPE_PREFERRED;
is correct?
>
> Konrad
> >
Re: [PATCH v5 2/2] drm/panel: Add driver for Novatek NT36523
On 11.03.2023 13:32, Jianhua Lu wrote:
> Add a driver for panels using the Novatek NT36523 display driver IC.
>
> Signed-off-by: Jianhua Lu
> ---
[...]
> +
> +static int nt36523_get_modes(struct drm_panel *panel,
> +struct drm_connector *connector)
> +{
> + struct panel_info *pinfo = to_panel_info(panel);
> + int i;
> +
> + for (i = 0; i < pinfo->desc->num_modes; i++) {
> + const struct drm_display_mode *m = >desc->modes[i];
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(connector->dev, m);
> + if (!mode) {
> + dev_err(panel->dev, "failed to add mode %ux%u@%u\n",
> + m->hdisplay, m->vdisplay, drm_mode_vrefresh(m));
> + return -ENOMEM;
> + }
> +
> + mode->type = DRM_MODE_TYPE_DRIVER;
> + if (pinfo->desc->num_modes == 1)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
That's not quite correct, as that means "if you have more than one
defined panel mode (say 60Hz and 120 Hz), there will be no preferred one".
Konrad
> +
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(connector, mode);
> + }
> +
> + connector->display_info.width_mm = pinfo->desc->width_mm;
> + connector->display_info.height_mm = pinfo->desc->height_mm;
> + connector->display_info.bpc = pinfo->desc->bpc;
> +
> + return pinfo->desc->num_modes;
> +}
> +
> +static const struct drm_panel_funcs nt36523_panel_funcs = {
> + .disable = nt36523_disable,
> + .prepare = nt36523_prepare,
> + .unprepare = nt36523_unprepare,
> + .get_modes = nt36523_get_modes,
> +};
> +
> +static int nt36523_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = >dev;
> + struct device_node *dsi1;
> + struct mipi_dsi_host *dsi1_host;
> + struct panel_info *pinfo;
> + const struct mipi_dsi_device_info *info;
> + int i, ret;
> +
> + pinfo = devm_kzalloc(dev, sizeof(*pinfo), GFP_KERNEL);
> + if (!pinfo)
> + return -ENOMEM;
> +
> + pinfo->vddio = devm_regulator_get(dev, "vddio");
> + if (IS_ERR(pinfo->vddio))
> + return dev_err_probe(dev, PTR_ERR(pinfo->vddio), "failed to get
> vddio regulator\n");
> +
> + pinfo->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(pinfo->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(pinfo->reset_gpio), "failed
> to get reset gpio\n");
> +
> + pinfo->desc = of_device_get_match_data(dev);
> + if (!pinfo->desc)
> + return -ENODEV;
> +
> + /* If the panel is dual dsi, register DSI1 */
> + if (pinfo->desc->is_dual_dsi) {
> + info = >desc->dsi_info;
> +
> + dsi1 = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
> + if (!dsi1) {
> + dev_err(dev, "cannot get secondary DSI node.\n");
> + return -ENODEV;
> + }
> +
> + dsi1_host = of_find_mipi_dsi_host_by_node(dsi1);
> + of_node_put(dsi1);
> + if (!dsi1_host)
> + return dev_err_probe(dev, -EPROBE_DEFER, "cannot get
> secondary DSI host\n");
> +
> + pinfo->dsi[1] = mipi_dsi_device_register_full(dsi1_host, info);
> + if (!pinfo->dsi[1]) {
> + dev_err(dev, "cannot get secondary DSI device\n");
> + return -ENODEV;
> + }
> + }
> +
> + pinfo->dsi[0] = dsi;
> + mipi_dsi_set_drvdata(dsi, pinfo);
> + drm_panel_init(>panel, dev, _panel_funcs,
> DRM_MODE_CONNECTOR_DSI);
> +
> + ret = drm_panel_of_backlight(>panel);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to get backlight\n");
> +
> + drm_panel_add(>panel);
> +
> + for (i = 0; i < DSI_NUM_MIN + pinfo->desc->is_dual_dsi; i++) {
> + pinfo->dsi[i]->lanes = pinfo->desc->lanes;
> + pinfo->dsi[i]->format = pinfo->desc->format;
> + pinfo->dsi[i]->mode_flags = pinfo->desc->mode_flags;
> +
> + ret = mipi_dsi_attach(pinfo->dsi[i]);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "cannot attach to DSI%d
> host.\n", i);
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id nt36523_of_match[] = {
> + {
> + .compatible = "xiaomi,elish-boe-nt36523",
> + .data = _boe_desc,
> + },
> + {
> + .compatible = "xiaomi,elish-csot-nt36523",
> + .data = _csot_desc,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, nt36523_of_match);
> +
> +static struct mipi_dsi_driver nt36523_driver = {
> + .probe = nt36523_probe,
> + .remove = nt36523_remove,
> + .driver = {
> + .name = "panel-novatek-nt36523",
> + .of_match_table = nt36523_of_match,
> + },
> +};
>
[PATCH v5 2/2] drm/panel: Add driver for Novatek NT36523
Add a driver for panels using the Novatek NT36523 display driver IC.
Signed-off-by: Jianhua Lu
---
Changes in v5:
- use lowercase hex for init sequence
- fix code style
- enable DRM_MODE_TYPE_PREFERRED if where is only one mode.
Changes in v4:
- add multiple modes support
- use dev_err_probe helper
- fix dsi_info type string
- reimplement mipi_dsi_dual_dcs_write_seq() macro
Changes in v3:
- Refactor source code
Changes in v2:
- Refactor and clean up source code
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-novatek-nt36523.c | 777 ++
4 files changed, 795 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36523.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5383af5d3b45..3586248bb05d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6537,6 +6537,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt35560.c
+DRM DRIVER FOR NOVATEK NT36523 PANELS
+M: Jianhua Lu
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
+F: drivers/gpu/drm/panel/panel-novatek-nt36523.c
+
DRM DRIVER FOR NOVATEK NT36672A PANELS
M: Sumit Semwal
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 871c..268508743b5c 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -377,6 +377,16 @@ config DRM_PANEL_NOVATEK_NT35950
Sharp panels used in Sony Xperia Z5 Premium and XZ Premium
mobile phones.
+config DRM_PANEL_NOVATEK_NT36523
+ tristate "Novatek NT36523 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the panels built
+ around the Novatek NT36523 display controller, such as some
+ Boe panels used in Xiaomi Mi Pad 5 and 5 Pro tablets.
+
config DRM_PANEL_NOVATEK_NT36672A
tristate "Novatek NT36672A DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index c05aa9e23907..570eab8bf2b2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3052C) +=
panel-newvision-nv3052c.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36523) += panel-novatek-nt36523.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36523.c
b/drivers/gpu/drm/panel/panel-novatek-nt36523.c
new file mode 100644
index ..86b38be35c4e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36523.c
@@ -0,0 +1,777 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Novatek NT36523 DriverIC panels driver
+ *
+ * Copyright (c) 2022, 2023 Jianhua Lu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define DSI_NUM_MIN 1
+
+#define mipi_dsi_dual_dcs_write_seq(dsi0, dsi1, cmd, seq...)\
+ do { \
+ mipi_dsi_dcs_write_seq(dsi0, cmd, seq); \
+ mipi_dsi_dcs_write_seq(dsi1, cmd, seq); \
+ } while (0)
+
+struct panel_info {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ const struct panel_desc *desc;
+
+ struct gpio_desc *reset_gpio;
+ struct backlight_device *backlight;
+ struct regulator *vddio;
+
+ bool prepared;
+};
+
+struct panel_desc {
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned int bpc;
+ unsigned int lanes;
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+
+ const struct drm_display_mode *modes;
+ unsigned int num_modes;
+ const struct mipi_dsi_device_info dsi_info;
+ int (*init_sequence)(struct panel_info *pinfo);
+
+ bool is_dual_dsi;
+};
+
+static inline struct panel_info *to_panel_info(struct drm_panel *panel)
+{
+ return container_of(panel, struct panel_info, panel);
+}
+
+static int elish_boe_init_sequence(struct panel_info *pinfo)
+{
+ struct mipi_dsi_device *dsi0 = pinfo->dsi[0];
+ struct mipi_dsi_device *dsi1 = pinfo->dsi[1];
+
[PATCH v5 1/2] dt-bindings: display: panel: Add Novatek NT36523 bindings
Novatek NT36523 is a display driver IC used to drive DSI panels.
Signed-off-by: Jianhua Lu
Reviewed-by: Krzysztof Kozlowski
---
No changes in v5
No changes in v4
Changes in v3:
- pick up Krzysztof's R-b
- remove vddpos and vddneg supply
Changes in v2:
- Drop unnecessary description
- dsi0 -> dsi
- Correct indentation
.../display/panel/novatek,nt36523.yaml| 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
new file mode 100644
index ..0039561ef04c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36523.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36523 based DSI display Panels
+
+maintainers:
+ - Jianhua Lu
+
+description: |
+ The Novatek NT36523 is a generic DSI Panel IC used to drive dsi
+ panels. Support video mode panels from China Star Optoelectronics
+ Technology (CSOT) and BOE Technology.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - xiaomi,elish-boe-nt36523
+ - xiaomi,elish-csot-nt36523
+ - const: novatek,nt36523
+
+ reset-gpios:
+maxItems: 1
+description: phandle of gpio for reset line - This should be 8mA
+
+ vddio-supply:
+description: regulator that supplies the I/O voltage
+
+ reg: true
+ ports: true
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - reset-gpios
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xiaomi,elish-csot-nt36523", "novatek,nt36523";
+reg = <0>;
+
+vddio-supply = <_l14a_1p88>;
+reset-gpios = < 75 GPIO_ACTIVE_LOW>;
+backlight = <>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+panel_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1{
+reg = <1>;
+panel_in_1: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+};
+
+...
--
2.39.2
Re: [PATCH] fbdev: Use of_property_read_bool() for boolean properties
On 3/10/23 15:47, Rob Herring wrote: It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring applied. Thanks, Helge --- drivers/video/fbdev/offb.c | 4 ++-- drivers/video/fbdev/sm501fb.c | 4 ++-- drivers/video/fbdev/tcx.c | 3 +-- drivers/video/fbdev/xilinxfb.c | 3 +-- 4 files changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c index f7ad6bc9d02d..b97d251d894b 100644 --- a/drivers/video/fbdev/offb.c +++ b/drivers/video/fbdev/offb.c @@ -549,10 +549,10 @@ static void offb_init_nodriver(struct platform_device *parent, struct device_nod int foreign_endian = 0; #ifdef __BIG_ENDIAN - if (of_get_property(dp, "little-endian", NULL)) + if (of_property_read_bool(dp, "little-endian")) foreign_endian = FBINFO_FOREIGN_ENDIAN; #else - if (of_get_property(dp, "big-endian", NULL)) + if (of_property_read_bool(dp, "big-endian")) foreign_endian = FBINFO_FOREIGN_ENDIAN; #endif diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c index f743bfbde2a6..1f3cbe723def 100644 --- a/drivers/video/fbdev/sm501fb.c +++ b/drivers/video/fbdev/sm501fb.c @@ -1737,10 +1737,10 @@ static int sm501fb_init_fb(struct fb_info *fb, enum sm501_controller head, #if defined(CONFIG_OF) #ifdef __BIG_ENDIAN - if (of_get_property(info->dev->parent->of_node, "little-endian", NULL)) + if (of_property_read_bool(info->dev->parent->of_node, "little-endian")) fb->flags |= FBINFO_FOREIGN_ENDIAN; #else - if (of_get_property(info->dev->parent->of_node, "big-endian", NULL)) + if (of_property_read_bool(info->dev->parent->of_node, "big-endian")) fb->flags |= FBINFO_FOREIGN_ENDIAN; #endif #endif diff --git a/drivers/video/fbdev/tcx.c b/drivers/video/fbdev/tcx.c index 01d87f53324d..f2eaf6e7fff6 100644 --- a/drivers/video/fbdev/tcx.c +++ b/drivers/video/fbdev/tcx.c @@ -379,8 +379,7 @@ static int tcx_probe(struct platform_device *op) spin_lock_init(>lock); - par->lowdepth = - (of_find_property(dp, "tcx-8-bit", NULL) != NULL); + par->lowdepth = of_property_read_bool(dp, "tcx-8-bit"); sbusfb_fill_var(>var, dp, 8); info->var.red.length = 8; diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c index 1ac83900a21c..c17cfffd9a84 100644 --- a/drivers/video/fbdev/xilinxfb.c +++ b/drivers/video/fbdev/xilinxfb.c @@ -469,8 +469,7 @@ static int xilinxfb_of_probe(struct platform_device *pdev) pdata.yvirt = prop[1]; } - if (of_find_property(pdev->dev.of_node, "rotate-display", NULL)) - pdata.rotate_screen = 1; + pdata.rotate_screen = of_property_read_bool(pdev->dev.of_node, "rotate-display"); platform_set_drvdata(pdev, drvdata); return xilinxfb_assign(pdev, drvdata, );
Re: [PATCH -next] fbdev/clps711x-fb: Use devm_platform_get_and_ioremap_resource()
On 3/8/23 06:49, Yang Li wrote:
According to commit 890cc39a8799 ("drivers: provide
devm_platform_get_and_ioremap_resource()"), convert
platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yang Li
applied.
Thanks!
Helge
---
drivers/video/fbdev/clps711x-fb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/clps711x-fb.c
b/drivers/video/fbdev/clps711x-fb.c
index 45c75ff01eca..c8bfc608bd9c 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -238,8 +238,7 @@ static int clps711x_fb_probe(struct platform_device *pdev)
info->fix.mmio_start = res->start;
info->fix.mmio_len = resource_size(res);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- info->screen_base = devm_ioremap_resource(dev, res);
+ info->screen_base = devm_platform_get_and_ioremap_resource(pdev, 1,
);
if (IS_ERR(info->screen_base)) {
ret = PTR_ERR(info->screen_base);
goto out_fb_release;
[PATCH] drm/panel: simple: add support for innolux at070tn83
Add config for innolux at070tn83 [1] which is a 152x91 display.
Tested on a stm32mp1 based platform.
[1] https://elinux.org/images/0/07/AT070TN83.pdf
Signed-off-by: Pawel Zalewski
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 065f378bba9d..ad84e9b21299 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2120,6 +2120,31 @@ static const struct panel_desc innolux_at043tn24 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
};
+static const struct drm_display_mode innolux_at070tn83_mode = {
+ .clock = 4,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 1,
+ .htotal = 800 + 210 + 1 + 45,
+ .vdisplay = 480,
+ .vsync_start = 480 + 132,
+ .vsync_end = 480 + 132 + 1,
+ .vtotal = 480 + 132 + 1 + 22,
+};
+
+static const struct panel_desc innolux_at070tn83 = {
+ .modes = _at070tn83_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode innolux_at070tn92_mode = {
.clock = 3,
.hdisplay = 800,
@@ -4095,6 +4120,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,at043tn24",
.data = _at043tn24,
+ }, {
+ .compatible = "innolux,at070tn83",
+ .data = _at070tn83,
}, {
.compatible = "innolux,at070tn92",
.data = _at070tn92,
--
2.34.1
[PATCH] gpu/drm: Remove unnecessary semicolon
Drop the extra semicolon after nvkm_memory_map() call.
Signed-off-by: zhounan
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
index 5f20079c3660..204516891ece 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -420,7 +420,7 @@ gf100_gr_chan_new(struct nvkm_gr *base, struct
nvkm_fifo_chan *fifoch,
return ret;
} else {
ret = nvkm_memory_map(gr->attrib_cb, 0, chan->vmm,
chan->attrib_cb,
- , sizeof(args));;
+ , sizeof(args));
if (ret)
return ret;
}
--
2.39.1
Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors
-- Brandi B Gulbin
Re: [RFC v2 0/6] drm/amd/display: Pass proper parent for DM backlight device v2
Hi Rodrigo, On 3/10/23 23:12, Rodrigo Siqueira Jordao wrote: > Hi Hans, > > Which AMD device do you have available for testing this series? As mentioned in a reply to the cover-letter (should have been in the cover-letter itself but I forgot, sorry. I don't have any hw to test this which is why this was marked as a RFC. In the mean time 2 reporters of: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/730 who have affected hw hitting the changed code paths have confirmed that this series works and that the correct parent now gets set. So as I also already mentioned in a reply to the cover-letter (1): this series no longer is RFC, but is ready for merging (from my pov) now. > P.s.: If you have a new version of this series, could you also Cc me? Sure, although atm I see no need to do a new version, please consider this a non RFC submission now and review it. If the review leads to changes being requested then I'll prepare a new version and Cc you. Regards, Hans 1) Next time mayvw read the entire thread before replying ? > On 3/8/23 14:58, Hans de Goede wrote: >> Hi All, >> >> Here is version 2 of my patch series to pass the proper parent device >> to backlight_device_register(). >> >> New in version 2 is delaying the registering of the backlight_dev till >> after the drm_connector is registered by doing it from >> drm_connector_funcs.late_register. >> >> This involves first reworking the code a bit to allow delaying >> the registering, so this has turned from a single patch into >> a 6 patch set. >> >> Regards, >> >> Hans >> >> >> Hans de Goede (6): >> drm/amd/display/amdgpu_dm: Fix backlight_device_register() error >> handling >> drm/amd/display/amdgpu_dm: Refactor register_backlight_device() >> drm/amd/display/amdgpu_dm: Add a bl_idx to amdgpu_dm_connector >> drm/amd/display/amdgpu_dm: Move most backlight setup into >> setup_backlight_device() >> drm/amd/display/amdgpu_dm: Make amdgpu_dm_register_backlight_device() >> take an amdgpu_dm_connector >> drm/amd/display: Pass proper parent for DM backlight device >> registration v2 >> >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 99 --- >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 + >> 2 files changed, 44 insertions(+), 56 deletions(-) >> >
Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)
AL13N schreef op 2023-03-10 13:38: Dave Stevenson schreef op 2023-03-09 13:59: On Wed, 8 Mar 2023 at 22:46, AL13N wrote: AL13N schreef op 2023-03-08 22:16: > Maxime Ripard schreef op 2023-03-08 13:35: >> Hi, >> >> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote: >>> On Tue, 7 Mar 2023 at 16:25, AL13N wrote: >>> > AL13N schreef op 2023-03-06 17:34: >>> > > I have a RPI4B connected on 2nd HDMI port (furthest away from power) >>> > > to a 4K TV, which works until 5.16, from 5.17 there is no X (or >>> > > plymouth), the cause of no X is that EDID gives nothing, and in the >>> > > journal; there is "Cannot find any crct or sizes". Only the kernel is >>> > > changed for this. >>> > > >>> > > In 5.16 instead of this message there is a bunch of hex lines prefixed >>> > > with BAD. >>> > > >>> > > It is still broken in 6.1 at the very least. >>> > > >>> > > I donno if this is related to this part, but I wanted to try a newer >>> > > kernel, because the RPI4 seems to do all the video decoding in >>> > > software and cannot seem to handle it. >>> > > >>> > > >>> > > logs: >>> > > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4]) >>> > > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) >>> > > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > > checking generic (3ea81000 12c000) vs hw (0 ) >>> > > fb0: switching to vc4 from simple >>> > > Console: switching to colour dummy device 80x25 >>> > > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 >>> > > vc4-drm gpu: [drm] Cannot find any crtc or sizes >>> > >>> > 5.16 log has: >>> > >>> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4]) >>> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) >>> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4]) >>> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 >>> > [00] BAD 00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00 >>> > [00] BAD 0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23 >>> > [00] BAD 09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01 >>> > [00] BAD 01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58 >>> > [00] BAD 8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40 >>> > [00] BAD 58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53 >>> > [00] BAD 41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd >>> > [00] BAD 00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa >>> > Console: switching to colour frame buffer device 240x67 >>> > vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device >>> > >>> > >>> > i donno what this bad is, but it doesn't happen in 5.17... maybe these >>> > BAD got filtered out, but they did end up working for me? or something? >>> > i donno... >>> >>> Run it through edid-decode - the checksum is wrong. >>> >>> Block 0, Base EDID: >>> EDID Structure Version & Revision: 1.3 >>> Vendor & Product Identification: >>> Manufacturer: MST >>> Model: 0 >>> Made in: week 11 of 2021 >>> Basic Display Parameters & Features: >>> Analog display >>> Input voltage level: 0.7/0.3 V >>> Blank level equals black level >>> Maximum image size: 35 cm x 1 cm >>> Gamma: 2.20 >>> RGB color display >>> First detailed timing is the preferred timing >>> Color Characteristics: >>> Red : 0.6396, 0.3398 >>> Green: 0.2998, 0.6904 >>> Blue : 0.1376, 0.0380 >>> White: 0.2822, 0.2968 >>> Established Timings I & II: none >>> Standard Timings: >>> GTF : 2288x1432 61.000 Hz 16:10 90.463 kHz 282.245 MHz >>> Detailed Timing Descriptors: >>> DTD 1: 3840x2160 60.000 Hz 16:9 135.000 kHz 594.000 MHz >>> (708 >>> mm x 398 mm) >>> Hfront 176 Hsync 88 Hback 296 Hpol P >>> Vfront8 Vsync 10 Vback 72 Vpol P >>> DTD 2: 1920x1080 60.000 Hz 16:967.500 kHz 148.500 MHz >>> (708 >>> mm x 398 mm) >>> Hfront 88 Hsync 44 Hback 148 Hpol P >>> Vfront4 Vsync 5 Vback 36 Vpol P >>> Display Product Name: 'SALORA' >>> Display Range Limits: >>> Monitor ranges (GTF): 59-70 Hz V, 31-140 kHz H, max dotclock 600 >>> MHz >>> Extension blocks: 1 >>> Checksum: 0xaa (should be 0xeb) >>> >>> Weird that it also says that it's an analog display when it's >>> connected over HDMI. Something rather bizarre there, and I think >>> it'll >>> hit problems in
Re: [PATCH v4 2/2] drm/panel: Add driver for Novatek NT36523
Le 10/03/2023 à 23:50, Linus Walleij a écrit :
On Fri, Mar 10, 2023 at 7:35 PM Jianhua Lu wrote:
On Fri, Mar 10, 2023 at 07:10:21PM +0100, Konrad Dybcio wrote:
+#define mipi_dsi_dual_dcs_write_seq(dsi0, dsi1, cmd, seq...)\
+ do { \
+ mipi_dsi_dcs_write_seq(dsi0, cmd, seq); \
+ mipi_dsi_dcs_write_seq(dsi1, cmd, seq); \
+ } while (0)
This should be in the same file as mipi_dsi_dcs_write_seq, imo
I have sent a patch to do it, upstream don't think this wrapper is a proper
approach to deal with dual dsi and wrap all of mipi_dsi_* function is
useless.
https://lore.kernel.org/lkml/20230310110542.6649-1-lujianhua...@gmail.com/
We can keep it locally if the fight isn't worthwhile, but I will try to enter
the discussion.
It's ok to keep it in the driver until we find a way to move it in the generic
includes.
Neil
Yours,
Linus Walleij
