* [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
@ 2023-07-12 9:46 Uwe Kleine-König
2023-07-12 9:46 ` [Nouveau] [PATCH RFC v1 26/52] drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev Uwe Kleine-König
` (5 more replies)
0 siblings, 6 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-12 9:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Alex Deucher, Christian König,
Pan, Xinhui, Harry Wentland, Leo Li, Rodrigo Siqueira,
Hamza Mahfooz, Javier Martinez Canillas, Guchun Chen,
Srinivasan Shanmugam, Evan Quan, Likun Gao,
Marek Olšák, David Francis, Hawking Zhang,
Graham Sider, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, Jani Nikula, xurui, Laurent Pinchart,
Maíra Canal, André Almeida, Qingqing Zhuo,
Aurabindo Pillai, Hersen Wu, Fangzhi Zuo, Stylon Wang, Alan Liu,
Wayne Lin, Aaron Liu, Melissa Wen, Bhawanpreet Lakha,
David Tadokoro, Wenjing Liu, Jiapeng Chong, Mario Limonciello,
Alexey Kodanev, Roman Li, Joaquín Ignacio Aramendía,
Dave Airlie, Russell King, Liviu Dudau, Joel Stanley,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Stefan Agner, Alison Wang, Patrik Jakobsson,
Noralf Trønnes, Xinliang Liu, Tian Tao, Danilo Krummrich,
Deepak Rawat, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Ville Syrjälä,
Lucas De Marchi, Ankit Nautiyal, Andrzej Hajda, Matt Roper,
Stanislav Lisovskiy, Radhakrishna Sripada, Hans de Goede,
Luca Coelho, Niranjana Vishwanathapura, Kai Vehmanen,
Vinod Govindapillai, Łukasz Bartosik, Anusha Srivatsa,
Chaitanya Kumar Borah, Uma Shankar, Imre Deak, Mitul Golani,
Swati Sharma, Jouni Högander, Mika Kahola,
José Roberto de Souza, Arun R Murthy, Gustavo Sousa,
Khaled Almahallawy, Juha-Pekka Heikkila, Andi Shyti, Nirmoy Das,
Fei Yang, Animesh Manna, Deepak R Varma, Jiri Slaby (SUSE),
Dmitry Baryshkov, Vandita Kulkarni, Suraj Kandpal, Manasi Navare,
Drew Davenport, Laurentiu Palcu, Shawn Guo, Sascha Hauer,
Philipp Zabel, Marian Cichy, Dan Carpenter, Paul Cercueil,
Anitha Chrisanthus, Edmund Dea, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Neil Armstrong, Kevin Hilman,
Rob Clark, Abhinav Kumar, Vinod Polimera, Jiasheng Jiang,
Konrad Dybcio, Jessica Zhang, Liu Shixin, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Emma Anholt, Gerd Hoffmann, Kieran Bingham, Tomi Valkeinen,
Wolfram Sang, Geert Uytterhoeven, Biju Das, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Thierry Reding, Mikko Perttunen,
Jonathan Hunter, Jyri Sarha, David Lechner, Kamlesh Gurudasani,
Rodrigo Siqueira, Melissa Wen, Oleksandr Andrushchenko,
Michal Simek
Cc: Haneen Mohammed, linux-hyperv, linux-aspeed, nouveau, dri-devel,
virtualization, Yongqin Liu, Alim Akhtar, Marijn Suijten,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
amd-gfx, linux-stm32, linux-rockchip, Xinwei Kong,
VMware Graphics Reviewers, NXP Linux Team, spice-devel,
linux-sunxi, Martin Blumenstingl, linux-arm-msm, intel-gfx,
linux-mediatek, xen-devel, linux-tegra, linux-amlogic,
Gurchetan Singh, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-mips,
Chia-I Wu, linux-renesas-soc, kernel, John Stultz, freedreno,
Lucas Stach
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong preference here though, so "drmdev" or "drm" are fine
for me, too. Let the bikesheding begin!
Some statistics:
$ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
1 struct drm_device *adev_to_drm
1 struct drm_device *drm_
1 struct drm_device *drm_dev
1 struct drm_device *drm_dev
1 struct drm_device *pdev
1 struct drm_device *rdev
1 struct drm_device *vdev
2 struct drm_device *dcss_drv_dev_to_drm
2 struct drm_device **ddev
2 struct drm_device *drm_dev_alloc
2 struct drm_device *mock
2 struct drm_device *p_ddev
5 struct drm_device *device
9 struct drm_device * dev
25 struct drm_device *d
95 struct drm_device *
216 struct drm_device *ddev
234 struct drm_device *drm_dev
611 struct drm_device *drm
4190 struct drm_device *dev
This series starts with renaming struct drm_crtc::dev to drm_dev. If
it's not only me and others like the result of this effort it should be
followed up by adapting the other structs and the individual usages in
the different drivers.
To make this series a bit easier handleable, I first added an alias for
drm_crtc::dev, then converted the drivers one after another and the last
patch drops the "dev" name. This has the advantage of being easier to
review, and if I should have missed an instance only the last patch must
be dropped/reverted. Also this series might conflict with other patches,
in this case the remaining patches can still go in (apart from the last
one of course). Maybe it also makes sense to delay applying the last
patch by one development cycle?
The series was compile tested for arm, arm64, powerpc and amd64 using an
allmodconfig (though I only build drivers/gpu/).
Best regards
Uwe
Uwe Kleine-König (52):
drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/armada: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/exynos: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/gma500: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/meson: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/pl111: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/radeon: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/renesas: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/solomon: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/sun4i: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/tegra: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/tidss: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/tilcdc: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/tiny: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/tve200: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/udl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/vboxvideo: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/vc4: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/virtio: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/vkms: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/vmwgfx: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
drm/xen: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/xlnx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/crtc: Complete renaming struct drm_crtc::dev to drm_dev
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 +-
drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 22 +--
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 26 +--
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 26 +--
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 26 +--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +--
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 8 +-
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 +--
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 +--
.../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-
drivers/gpu/drm/arm/malidp_crtc.c | 7 +-
drivers/gpu/drm/armada/armada_crtc.c | 10 +-
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 6 +-
drivers/gpu/drm/ast/ast_dp.c | 2 +-
drivers/gpu/drm/ast/ast_mode.c | 26 +--
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 10 +-
drivers/gpu/drm/drm_atomic.c | 22 +--
drivers/gpu/drm/drm_atomic_helper.c | 20 ++-
drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
drivers/gpu/drm/drm_atomic_uapi.c | 22 +--
drivers/gpu/drm/drm_blend.c | 2 +-
drivers/gpu/drm/drm_color_mgmt.c | 10 +-
drivers/gpu/drm/drm_crtc.c | 19 ++-
drivers/gpu/drm/drm_crtc_helper.c | 10 +-
drivers/gpu/drm/drm_debugfs.c | 2 +-
drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c | 6 +-
drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_plane_helper.c | 2 +-
drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
drivers/gpu/drm/drm_vblank.c | 40 ++---
drivers/gpu/drm/drm_vblank_work.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 16 +-
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
drivers/gpu/drm/gma500/gma_display.c | 20 +--
drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 +-
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
drivers/gpu/drm/gma500/psb_irq.c | 6 +-
drivers/gpu/drm/gud/gud_pipe.c | 6 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 +--
.../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +-
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 6 +-
drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
drivers/gpu/drm/i915/display/hsw_ips.c | 16 +-
drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +-
drivers/gpu/drm/i915/display/i9xx_wm.c | 40 ++---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
.../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +-
drivers/gpu/drm/i915/display/intel_color.c | 124 +++++++-------
drivers/gpu/drm/i915/display/intel_crtc.c | 20 +--
.../drm/i915/display/intel_crtc_state_dump.c | 4 +-
drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 28 ++--
drivers/gpu/drm/i915/display/intel_display.c | 154 +++++++++---------
.../gpu/drm/i915/display/intel_display_irq.c | 22 +--
.../gpu/drm/i915/display/intel_display_rps.c | 2 +-
.../drm/i915/display/intel_display_trace.h | 12 +-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dpll.c | 38 ++---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 ++---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/display/intel_drrs.c | 10 +-
drivers/gpu/drm/i915/display/intel_dsb.c | 8 +-
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
drivers/gpu/drm/i915/display/intel_fdi.c | 22 +--
.../drm/i915/display/intel_fifo_underrun.c | 6 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
.../drm/i915/display/intel_modeset_setup.c | 22 +--
.../drm/i915/display/intel_modeset_verify.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 4 +-
.../gpu/drm/i915/display/intel_pch_display.c | 32 ++--
.../gpu/drm/i915/display/intel_pch_refclk.c | 2 +-
drivers/gpu/drm/i915/display/intel_pipe_crc.c | 10 +-
.../drm/i915/display/intel_plane_initial.c | 6 +-
drivers/gpu/drm/i915/display/intel_psr.c | 14 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_vblank.c | 24 +--
drivers/gpu/drm/i915/display/intel_vdsc.c | 18 +-
drivers/gpu/drm/i915/display/intel_vrr.c | 18 +-
drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
.../drm/i915/display/skl_universal_plane.c | 6 +-
drivers/gpu/drm/i915/display/skl_watermark.c | 42 ++---
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
drivers/gpu/drm/imx/dcss/dcss-crtc.c | 20 +--
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 15 +-
drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 16 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +-
drivers/gpu/drm/kmb/kmb_crtc.c | 16 +-
drivers/gpu/drm/logicvc/logicvc_crtc.c | 14 +-
drivers/gpu/drm/mcde/mcde_display.c | 18 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 22 +--
drivers/gpu/drm/meson/meson_crtc.c | 12 +-
drivers/gpu/drm/mgag200/mgag200_g200.c | 4 +-
drivers/gpu/drm/mgag200/mgag200_g200eh.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_g200er.c | 4 +-
drivers/gpu/drm/mgag200/mgag200_g200ev.c | 4 +-
drivers/gpu/drm/mgag200/mgag200_g200se.c | 6 +-
drivers/gpu/drm/mgag200/mgag200_g200wb.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 70 ++++----
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 12 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 20 +--
drivers/gpu/drm/msm/msm_drv.c | 4 +-
drivers/gpu/drm/mxsfb/lcdif_kms.c | 18 +-
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 16 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 58 +++----
drivers/gpu/drm/nouveau/dispnv04/cursor.c | 10 +-
drivers/gpu/drm/nouveau/dispnv50/atom.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/crc.c | 30 ++--
drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 6 +-
drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 6 +-
drivers/gpu/drm/nouveau/dispnv50/crcc57d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +-
drivers/gpu/drm/nouveau/dispnv50/head.c | 4 +-
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 26 +--
drivers/gpu/drm/nouveau/dispnv50/head827d.c | 10 +-
drivers/gpu/drm/nouveau/dispnv50/head907d.c | 26 +--
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 6 +-
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 18 +-
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 10 +-
drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/omapdrm/omap_crtc.c | 56 +++----
drivers/gpu/drm/omapdrm/omap_irq.c | 6 +-
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 +-
drivers/gpu/drm/pl111/pl111_display.c | 16 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 54 +++---
drivers/gpu/drm/radeon/radeon_cursor.c | 14 +-
drivers/gpu/drm/radeon/radeon_display.c | 28 ++--
drivers/gpu/drm/radeon/radeon_kms.c | 6 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +-
.../gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 14 +-
.../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 20 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 15 +-
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
drivers/gpu/drm/sprd/sprd_dpu.c | 6 +-
drivers/gpu/drm/sti/sti_crtc.c | 14 +-
drivers/gpu/drm/stm/ltdc.c | 12 +-
drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +-
drivers/gpu/drm/tegra/dc.c | 12 +-
drivers/gpu/drm/tidss/tidss_crtc.c | 19 ++-
drivers/gpu/drm/tidss/tidss_irq.c | 4 +-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 43 ++---
drivers/gpu/drm/tiny/bochs.c | 6 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
drivers/gpu/drm/tiny/gm12u320.c | 4 +-
drivers/gpu/drm/tiny/hx8357d.c | 4 +-
drivers/gpu/drm/tiny/ili9163.c | 4 +-
drivers/gpu/drm/tiny/ili9225.c | 8 +-
drivers/gpu/drm/tiny/ili9341.c | 4 +-
drivers/gpu/drm/tiny/ili9486.c | 4 +-
drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
drivers/gpu/drm/tiny/ofdrm.c | 8 +-
drivers/gpu/drm/tiny/panel-mipi-dbi.c | 6 +-
drivers/gpu/drm/tiny/repaper.c | 8 +-
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
drivers/gpu/drm/tiny/st7586.c | 6 +-
drivers/gpu/drm/tiny/st7735r.c | 4 +-
drivers/gpu/drm/tve200/tve200_display.c | 14 +-
drivers/gpu/drm/udl/udl_modeset.c | 4 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 6 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 38 ++---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
drivers/gpu/drm/vc4/vc4_hvs.c | 12 +-
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
drivers/gpu/drm/xen/xen_drm_front_kms.c | 10 +-
drivers/gpu/drm/xlnx/zynqmp_kms.c | 8 +-
include/drm/drm_atomic_helper.h | 2 +-
include/drm/drm_crtc.h | 4 +-
194 files changed, 1296 insertions(+), 1264 deletions(-)
base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
--
2.39.2
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Nouveau] [PATCH RFC v1 26/52] drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
@ 2023-07-12 9:46 ` Uwe Kleine-König
2023-07-12 10:13 ` [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Paul Kocialkowski
` (4 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-12 9:46 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude Paul, David Airlie,
Daniel Vetter, Thomas Zimmermann, Sam Ravnborg,
Javier Martinez Canillas, Jani Nikula, Dave Airlie, Alex Deucher
Cc: nouveau, kernel, dri-devel
Prepare dropping the alias "dev" for struct drm_crtc::drm_dev. "drm_dev"
is the better name as "dev" is usually a struct device pointer.
No semantic changes.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 58 +++++++++++----------
drivers/gpu/drm/nouveau/dispnv04/cursor.c | 10 ++--
drivers/gpu/drm/nouveau/dispnv50/atom.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/crc.c | 30 +++++------
drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 6 +--
drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 6 +--
drivers/gpu/drm/nouveau/dispnv50/crcc57d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +-
drivers/gpu/drm/nouveau/dispnv50/head.c | 4 +-
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 26 ++++-----
drivers/gpu/drm/nouveau/dispnv50/head827d.c | 10 ++--
drivers/gpu/drm/nouveau/dispnv50/head907d.c | 26 ++++-----
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 6 +--
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 18 +++----
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 10 ++--
drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
17 files changed, 113 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index a6f2e681bde9..fad5c6dc2cf7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -56,18 +56,18 @@ nv04_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
static void
crtc_wr_cio_state(struct drm_crtc *crtc, struct nv04_crtc_reg *crtcstate, int index)
{
- NVWriteVgaCrtc(crtc->dev, nouveau_crtc(crtc)->index, index,
+ NVWriteVgaCrtc(crtc->drm_dev, nouveau_crtc(crtc)->index, index,
crtcstate->CRTC[index]);
}
static void nv_crtc_set_digital_vibrance(struct drm_crtc *crtc, int level)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nv04_crtc_reg *regp = &nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
regp->CRTC[NV_CIO_CRE_CSB] = nv_crtc->saturation = level;
- if (nv_crtc->saturation && nv_gf4_disp_arch(crtc->dev)) {
+ if (nv_crtc->saturation && nv_gf4_disp_arch(crtc->drm_dev)) {
regp->CRTC[NV_CIO_CRE_CSB] = 0x80;
regp->CRTC[NV_CIO_CRE_5B] = nv_crtc->saturation << 2;
crtc_wr_cio_state(crtc, regp, NV_CIO_CRE_5B);
@@ -78,14 +78,15 @@ static void nv_crtc_set_digital_vibrance(struct drm_crtc *crtc, int level)
static void nv_crtc_set_image_sharpening(struct drm_crtc *crtc, int level)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nv04_crtc_reg *regp = &nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
nv_crtc->sharpness = level;
if (level < 0) /* blur is in hw range 0x3f -> 0x20 */
level += 0x40;
regp->ramdac_634 = level;
- NVWriteRAMDAC(crtc->dev, nv_crtc->index, NV_PRAMDAC_634, regp->ramdac_634);
+ NVWriteRAMDAC(crtc->drm_dev, nv_crtc->index, NV_PRAMDAC_634,
+ regp->ramdac_634);
}
#define PLLSEL_VPLL1_MASK \
@@ -116,7 +117,7 @@ static void nv_crtc_set_image_sharpening(struct drm_crtc *crtc, int level)
static void nv_crtc_calc_state_ext(struct drm_crtc *crtc, struct drm_display_mode * mode, int dot_clock)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_bios *bios = nvxx_bios(&drm->client.device);
struct nvkm_clk *clk = nvxx_clk(&drm->client.device);
@@ -175,7 +176,7 @@ static void
nv_crtc_dpms(struct drm_crtc *crtc, int mode)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
unsigned char seq1 = 0, crtc17 = 0;
unsigned char crtc1A;
@@ -236,7 +237,7 @@ nv_crtc_dpms(struct drm_crtc *crtc, int mode)
static void
nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct drm_display_mode *mode)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nv04_crtc_reg *regp = &nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
struct drm_framebuffer *fb = crtc->primary->fb;
@@ -460,7 +461,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct drm_display_mode *mode)
static void
nv_crtc_mode_set_regs(struct drm_crtc *crtc, struct drm_display_mode * mode)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nv04_crtc_reg *regp = &nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
@@ -609,7 +610,7 @@ nv_crtc_mode_set_regs(struct drm_crtc *crtc, struct drm_display_mode * mode)
static int
nv_crtc_swap_fbs(struct drm_crtc *crtc, struct drm_framebuffer *old_fb)
{
- struct nv04_display *disp = nv04_display(crtc->dev);
+ struct nv04_display *disp = nv04_display(crtc->drm_dev);
struct drm_framebuffer *fb = crtc->primary->fb;
struct nouveau_bo *nvbo = nouveau_gem_object(fb->obj[0]);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
@@ -638,7 +639,7 @@ nv_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
int x, int y, struct drm_framebuffer *old_fb)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nouveau_drm *drm = nouveau_drm(dev);
int ret;
@@ -665,16 +666,16 @@ nv_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
static void nv_crtc_save(struct drm_crtc *crtc)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nv04_mode_state *state = &nv04_display(dev)->mode_reg;
struct nv04_crtc_reg *crtc_state = &state->crtc_reg[nv_crtc->index];
struct nv04_mode_state *saved = &nv04_display(dev)->saved_reg;
struct nv04_crtc_reg *crtc_saved = &saved->crtc_reg[nv_crtc->index];
- if (nv_two_heads(crtc->dev))
- NVSetOwner(crtc->dev, nv_crtc->index);
+ if (nv_two_heads(crtc->drm_dev))
+ NVSetOwner(crtc->drm_dev, nv_crtc->index);
- nouveau_hw_save_state(crtc->dev, nv_crtc->index, saved);
+ nouveau_hw_save_state(crtc->drm_dev, nv_crtc->index, saved);
/* init some state to saved value */
state->sel_clk = saved->sel_clk & ~(0x5 << 16);
@@ -686,22 +687,23 @@ static void nv_crtc_save(struct drm_crtc *crtc)
static void nv_crtc_restore(struct drm_crtc *crtc)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
int head = nv_crtc->index;
uint8_t saved_cr21 = nv04_display(dev)->saved_reg.crtc_reg[head].CRTC[NV_CIO_CRE_21];
- if (nv_two_heads(crtc->dev))
- NVSetOwner(crtc->dev, head);
+ if (nv_two_heads(crtc->drm_dev))
+ NVSetOwner(crtc->drm_dev, head);
- nouveau_hw_load_state(crtc->dev, head, &nv04_display(dev)->saved_reg);
- nv_lock_vga_crtc_shadow(crtc->dev, head, saved_cr21);
+ nouveau_hw_load_state(crtc->drm_dev, head,
+ &nv04_display(dev)->saved_reg);
+ nv_lock_vga_crtc_shadow(crtc->drm_dev, head, saved_cr21);
nv_crtc->last_dpms = NV_DPMS_CLEARED;
}
static void nv_crtc_prepare(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
@@ -724,7 +726,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc)
static void nv_crtc_commit(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
@@ -746,7 +748,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc)
static void nv_crtc_destroy(struct drm_crtc *crtc)
{
- struct nv04_display *disp = nv04_display(crtc->dev);
+ struct nv04_display *disp = nv04_display(crtc->drm_dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
if (!nv_crtc)
@@ -770,7 +772,7 @@ static void
nv_crtc_gamma_load(struct drm_crtc *crtc)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = nv_crtc->base.dev;
+ struct drm_device *dev = nv_crtc->base.drm_dev;
struct rgb { uint8_t r, g, b; } __attribute__((packed)) *rgbs;
u16 *r, *g, *b;
int i;
@@ -792,7 +794,7 @@ nv_crtc_gamma_load(struct drm_crtc *crtc)
static void
nv_crtc_disable(struct drm_crtc *crtc)
{
- struct nv04_display *disp = nv04_display(crtc->dev);
+ struct nv04_display *disp = nv04_display(crtc->drm_dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
if (disp->image[nv_crtc->index])
nouveau_bo_unpin(disp->image[nv_crtc->index]);
@@ -827,7 +829,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
int x, int y, bool atomic)
{
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nv04_crtc_reg *regp = &nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
struct nouveau_bo *nvbo;
@@ -982,7 +984,7 @@ static int
nv04_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file *file_priv,
uint32_t buffer_handle, uint32_t width, uint32_t height)
{
- struct nouveau_drm *drm = nouveau_drm(crtc->dev);
+ struct nouveau_drm *drm = nouveau_drm(crtc->drm_dev);
struct drm_device *dev = drm->dev;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nouveau_bo *cursor = NULL;
@@ -1140,7 +1142,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_modeset_acquire_ctx *ctx)
{
const int swap_interval = (flags & DRM_MODE_PAGE_FLIP_ASYNC) ? 0 : 1;
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_framebuffer *old_fb = crtc->primary->fb;
struct nouveau_bo *old_bo = nouveau_gem_object(old_fb->obj[0]);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/cursor.c b/drivers/gpu/drm/nouveau/dispnv04/cursor.c
index 4c6440d29c3f..d7dbe411525b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/cursor.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/cursor.c
@@ -8,20 +8,20 @@
static void
nv04_cursor_show(struct nouveau_crtc *nv_crtc, bool update)
{
- nv_show_cursor(nv_crtc->base.dev, nv_crtc->index, true);
+ nv_show_cursor(nv_crtc->base.drm_dev, nv_crtc->index, true);
}
static void
nv04_cursor_hide(struct nouveau_crtc *nv_crtc, bool update)
{
- nv_show_cursor(nv_crtc->base.dev, nv_crtc->index, false);
+ nv_show_cursor(nv_crtc->base.drm_dev, nv_crtc->index, false);
}
static void
nv04_cursor_set_pos(struct nouveau_crtc *nv_crtc, int x, int y)
{
nv_crtc->cursor_saved_x = x; nv_crtc->cursor_saved_y = y;
- NVWriteRAMDAC(nv_crtc->base.dev, nv_crtc->index,
+ NVWriteRAMDAC(nv_crtc->base.drm_dev, nv_crtc->index,
NV_PRAMDAC_CU_START_POS,
XLATE(y, 0, NV_PRAMDAC_CU_START_POS_Y) |
XLATE(x, 0, NV_PRAMDAC_CU_START_POS_X));
@@ -30,14 +30,14 @@ nv04_cursor_set_pos(struct nouveau_crtc *nv_crtc, int x, int y)
static void
crtc_wr_cio_state(struct drm_crtc *crtc, struct nv04_crtc_reg *crtcstate, int index)
{
- NVWriteVgaCrtc(crtc->dev, nouveau_crtc(crtc)->index, index,
+ NVWriteVgaCrtc(crtc->drm_dev, nouveau_crtc(crtc)->index, index,
crtcstate->CRTC[index]);
}
static void
nv04_cursor_set_offset(struct nouveau_crtc *nv_crtc, uint32_t offset)
{
- struct drm_device *dev = nv_crtc->base.dev;
+ struct drm_device *dev = nv_crtc->base.drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nv04_crtc_reg *regp = &nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
struct drm_crtc *crtc = &nv_crtc->base;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 93f8f4f64578..27804c0bbc42 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -163,7 +163,7 @@ nv50_head_atom_get_encoder(struct nv50_head_atom *atom)
struct drm_encoder *encoder;
/* We only ever have a single encoder */
- drm_for_each_encoder_mask(encoder, atom->state.crtc->dev,
+ drm_for_each_encoder_mask(encoder, atom->state.crtc->drm_dev,
atom->state.encoder_mask)
return encoder;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c b/drivers/gpu/drm/nouveau/dispnv50/crc.c
index 9c942fbd836d..308bf99e2a44 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
@@ -48,7 +48,7 @@ int
nv50_crc_verify_source(struct drm_crtc *crtc, const char *source_name,
size_t *values_cnt)
{
- struct nouveau_drm *drm = nouveau_drm(crtc->dev);
+ struct nouveau_drm *drm = nouveau_drm(crtc->drm_dev);
enum nv50_crc_source source;
if (nv50_crc_parse_source(source_name, &source) < 0) {
@@ -70,7 +70,7 @@ static void
nv50_crc_program_ctx(struct nv50_head *head,
struct nv50_crc_notifier_ctx *ctx)
{
- struct nv50_disp *disp = nv50_disp(head->base.base.dev);
+ struct nv50_disp *disp = nv50_disp(head->base.base.drm_dev);
struct nv50_core *core = disp->core;
u32 interlock[NV50_DISP_INTERLOCK__SIZE] = { 0 };
@@ -84,7 +84,7 @@ static void nv50_crc_ctx_flip_work(struct kthread_work *base)
struct nv50_crc *crc = container_of(work, struct nv50_crc, flip_work);
struct nv50_head *head = container_of(crc, struct nv50_head, crc);
struct drm_crtc *crtc = &head->base.base;
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nv50_disp *disp = nv50_disp(dev);
const uint64_t start_vbl = drm_crtc_vblank_count(crtc);
uint64_t end_vbl;
@@ -154,7 +154,7 @@ void nv50_crc_handle_vblank(struct nv50_head *head)
struct drm_crtc *crtc = &head->base.base;
struct nv50_crc *crc = &head->crc;
const struct nv50_crc_func *func =
- nv50_disp(head->base.base.dev)->core->func->crc;
+ nv50_disp(head->base.base.drm_dev)->core->func->crc;
struct nv50_crc_notifier_ctx *ctx;
bool need_reschedule = false;
@@ -193,7 +193,7 @@ void nv50_crc_handle_vblank(struct nv50_head *head)
* updates back-to-back without waiting, we'll just be
* optimistic and assume we always miss exactly one frame.
*/
- drm_dbg_kms(head->base.base.dev,
+ drm_dbg_kms(head->base.base.drm_dev,
"Notifier ctx flip for head-%d finished, lost CRC for frame %llu\n",
head->base.index, crc->frame);
crc->frame++;
@@ -219,7 +219,7 @@ static void nv50_crc_wait_ctx_finished(struct nv50_head *head,
const struct nv50_crc_func *func,
struct nv50_crc_notifier_ctx *ctx)
{
- struct drm_device *dev = head->base.base.dev;
+ struct drm_device *dev = head->base.base.drm_dev;
struct nouveau_drm *drm = nouveau_drm(dev);
s64 ret;
@@ -256,7 +256,7 @@ void nv50_crc_atomic_stop_reporting(struct drm_atomic_state *state)
drm_crtc_vblank_put(crtc);
drm_vblank_work_cancel_sync(&crc->flip_work);
- NV_ATOMIC(nouveau_drm(crtc->dev),
+ NV_ATOMIC(nouveau_drm(crtc->drm_dev),
"CRC reporting on vblank for head-%d disabled\n",
head->base.index);
@@ -340,7 +340,7 @@ void nv50_crc_atomic_start_reporting(struct drm_atomic_state *state)
true);
spin_unlock_irq(&crc->lock);
- NV_ATOMIC(nouveau_drm(crtc->dev),
+ NV_ATOMIC(nouveau_drm(crtc->drm_dev),
"CRC reporting on vblank for head-%d enabled\n",
head->base.index);
}
@@ -449,7 +449,7 @@ void nv50_crc_atomic_set(struct nv50_head *head,
struct nv50_head_atom *asyh)
{
struct drm_crtc *crtc = &head->base.base;
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct nv50_crc *crc = &head->crc;
const struct nv50_crc_func *func = nv50_disp(dev)->core->func->crc;
struct nouveau_encoder *outp;
@@ -470,7 +470,7 @@ void nv50_crc_atomic_set(struct nv50_head *head,
void nv50_crc_atomic_clr(struct nv50_head *head)
{
const struct nv50_crc_func *func =
- nv50_disp(head->base.base.dev)->core->func->crc;
+ nv50_disp(head->base.base.drm_dev)->core->func->crc;
func->set_src(head, 0, NV50_CRC_SOURCE_TYPE_NONE, NULL);
}
@@ -500,7 +500,7 @@ static inline int
nv50_crc_ctx_init(struct nv50_head *head, struct nvif_mmu *mmu,
struct nv50_crc_notifier_ctx *ctx, size_t len, int idx)
{
- struct nv50_core *core = nv50_disp(head->base.base.dev)->core;
+ struct nv50_core *core = nv50_disp(head->base.base.drm_dev)->core;
int ret;
ret = nvif_mem_ctor_map(mmu, "kmsCrcNtfy", NVIF_MEM_VRAM, len, &ctx->mem);
@@ -537,7 +537,7 @@ nv50_crc_ctx_fini(struct nv50_crc_notifier_ctx *ctx)
int nv50_crc_set_source(struct drm_crtc *crtc, const char *source_str)
{
- struct drm_device *dev = crtc->dev;
+ struct drm_device *dev = crtc->drm_dev;
struct drm_atomic_state *state;
struct drm_modeset_acquire_ctx ctx;
struct nv50_head *head = nv50_head(crtc);
@@ -656,10 +656,10 @@ nv50_crc_debugfs_flip_threshold_set(struct file *file,
struct nv50_head *head = m->private;
struct nv50_head_atom *armh;
struct drm_crtc *crtc = &head->base.base;
- struct nouveau_drm *drm = nouveau_drm(crtc->dev);
+ struct nouveau_drm *drm = nouveau_drm(crtc->drm_dev);
struct nv50_crc *crc = &head->crc;
const struct nv50_crc_func *func =
- nv50_disp(crtc->dev)->core->func->crc;
+ nv50_disp(crtc->drm_dev)->core->func->crc;
int value, ret;
ret = kstrtoint_from_user(ubuf, len, 10, &value);
@@ -706,7 +706,7 @@ int nv50_head_crc_late_register(struct nv50_head *head)
{
struct drm_crtc *crtc = &head->base.base;
const struct nv50_crc_func *func =
- nv50_disp(crtc->dev)->core->func->crc;
+ nv50_disp(crtc->drm_dev)->core->func->crc;
struct dentry *root;
if (!func || !crtc->debugfs_entry)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc907d.c b/drivers/gpu/drm/nouveau/dispnv50/crc907d.c
index f9ad641555b7..1cd83c4dca10 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc907d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc907d.c
@@ -26,7 +26,7 @@ static int
crc907d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source,
struct nv50_crc_notifier_ctx *ctx)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 crc_args = NVDEF(NV907D, HEAD_SET_CRC_CONTROL, CONTROLLING_CHANNEL, CORE) |
NVDEF(NV907D, HEAD_SET_CRC_CONTROL, EXPECT_BUFFER_COLLAPSE, FALSE) |
@@ -74,7 +74,7 @@ crc907d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source
static int
crc907d_set_ctx(struct nv50_head *head, struct nv50_crc_notifier_ctx *ctx)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -97,7 +97,7 @@ static u32 crc907d_get_entry(struct nv50_head *head,
static bool crc907d_ctx_finished(struct nv50_head *head,
struct nv50_crc_notifier_ctx *ctx)
{
- struct nouveau_drm *drm = nouveau_drm(head->base.base.dev);
+ struct nouveau_drm *drm = nouveau_drm(head->base.base.drm_dev);
struct crc907d_notifier __iomem *notifier = ctx->mem.object.map.ptr;
const u32 status = ioread32_native(¬ifier->status);
const u32 overflow = status & 0x0000003e;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crcc37d.c b/drivers/gpu/drm/nouveau/dispnv50/crcc37d.c
index f10f6c484408..dee8c99a6a13 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crcc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crcc37d.c
@@ -15,7 +15,7 @@ static int
crcc37d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source,
struct nv50_crc_notifier_ctx *ctx)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 crc_args = NVVAL(NVC37D, HEAD_SET_CRC_CONTROL, CONTROLLING_CHANNEL, i * 4) |
NVDEF(NVC37D, HEAD_SET_CRC_CONTROL, EXPECT_BUFFER_COLLAPSE, FALSE) |
@@ -53,7 +53,7 @@ crcc37d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source
int crcc37d_set_ctx(struct nv50_head *head, struct nv50_crc_notifier_ctx *ctx)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -81,7 +81,7 @@ u32 crcc37d_get_entry(struct nv50_head *head, struct nv50_crc_notifier_ctx *ctx,
bool crcc37d_ctx_finished(struct nv50_head *head, struct nv50_crc_notifier_ctx *ctx)
{
- struct nouveau_drm *drm = nouveau_drm(head->base.base.dev);
+ struct nouveau_drm *drm = nouveau_drm(head->base.base.drm_dev);
struct crcc37d_notifier __iomem *notifier = ctx->mem.object.map.ptr;
const u32 status = ioread32_native(¬ifier->status);
const u32 overflow = status & 0x0000007e;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crcc57d.c b/drivers/gpu/drm/nouveau/dispnv50/crcc57d.c
index cc0130e3d496..b37fb18fd286 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crcc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crcc57d.c
@@ -13,7 +13,7 @@
static int crcc57d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source,
struct nv50_crc_notifier_ctx *ctx)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 crc_args = NVDEF(NVC57D, HEAD_SET_CRC_CONTROL, CONTROLLING_CHANNEL, CORE) |
NVDEF(NVC57D, HEAD_SET_CRC_CONTROL, EXPECT_BUFFER_COLLAPSE, FALSE) |
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 42e1665ba11a..ecf0c1b972c1 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2213,9 +2213,10 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state *state)
/* Get correct count/ts if racing with vblank irq */
if (new_crtc_state->active)
drm_crtc_accurate_vblank_count(crtc);
- spin_lock_irqsave(&crtc->dev->event_lock, flags);
+ spin_lock_irqsave(&crtc->drm_dev->event_lock, flags);
drm_crtc_send_vblank_event(crtc, new_crtc_state->event);
- spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ spin_unlock_irqrestore(&crtc->drm_dev->event_lock,
+ flags);
new_crtc_state->event = NULL;
if (new_crtc_state->active)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 5f490fbf1877..6d40bb470110 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -225,7 +225,7 @@ static int
nv50_head_atomic_check_lut(struct nv50_head *head,
struct nv50_head_atom *asyh)
{
- struct drm_device *dev = head->base.base.dev;
+ struct drm_device *dev = head->base.base.drm_dev;
struct drm_crtc *crtc = &head->base.base;
struct nv50_disp *disp = nv50_disp(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -336,7 +336,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct drm_atomic_state *state)
crtc);
struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
- struct nouveau_drm *drm = nouveau_drm(crtc->dev);
+ struct nouveau_drm *drm = nouveau_drm(crtc->drm_dev);
struct nv50_head *head = nv50_head(crtc);
struct nv50_head_atom *armh = nv50_head_atom(old_crtc_state);
struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head507d.c b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
index 0edd4e520c8e..fd499a530724 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
@@ -29,7 +29,7 @@
int
head507d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -48,7 +48,7 @@ head507d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head507d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -66,7 +66,7 @@ head507d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head507d_ovly(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 bounds = 0;
int ret;
@@ -94,7 +94,7 @@ head507d_ovly(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head507d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 bounds = 0;
int ret;
@@ -122,7 +122,7 @@ head507d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head507d_curs_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -139,7 +139,7 @@ head507d_curs_clr(struct nv50_head *head)
static int
head507d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -188,7 +188,7 @@ head507d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
int
head507d_core_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -202,7 +202,7 @@ head507d_core_clr(struct nv50_head *head)
static int
head507d_core_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -246,7 +246,7 @@ head507d_core_set(struct nv50_head *head, struct nv50_head_atom *asyh)
void
head507d_core_calc(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nv50_disp *disp = nv50_disp(head->base.base.dev);
+ struct nv50_disp *disp = nv50_disp(head->base.base.drm_dev);
if ((asyh->core.visible = (asyh->base.cpp != 0))) {
asyh->core.x = asyh->base.x;
asyh->core.y = asyh->base.y;
@@ -278,7 +278,7 @@ head507d_core_calc(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head507d_olut_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -293,7 +293,7 @@ head507d_olut_clr(struct nv50_head *head)
static int
head507d_olut_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -345,7 +345,7 @@ head507d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
int
head507d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
struct nv50_head_mode *m = &asyh->mode;
const int i = head->base.index;
int ret;
@@ -400,7 +400,7 @@ head507d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head507d_view(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head827d.c b/drivers/gpu/drm/nouveau/dispnv50/head827d.c
index 194d1771c481..1a9cbeaf0713 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head827d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head827d.c
@@ -29,7 +29,7 @@
static int
head827d_curs_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -48,7 +48,7 @@ head827d_curs_clr(struct nv50_head *head)
static int
head827d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -73,7 +73,7 @@ head827d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head827d_core_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -110,7 +110,7 @@ head827d_core_set(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head827d_olut_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -127,7 +127,7 @@ head827d_olut_clr(struct nv50_head *head)
static int
head827d_olut_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head907d.c b/drivers/gpu/drm/nouveau/dispnv50/head907d.c
index 18fe4c1e2d6a..d09206cfc3f7 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head907d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head907d.c
@@ -36,7 +36,7 @@
int
head907d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -57,7 +57,7 @@ head907d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head907d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -77,7 +77,7 @@ head907d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head907d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -95,7 +95,7 @@ head907d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head907d_ovly(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 bounds = 0;
int ret;
@@ -124,7 +124,7 @@ head907d_ovly(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head907d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 bounds = 0;
int ret;
@@ -152,7 +152,7 @@ head907d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head907d_curs_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -171,7 +171,7 @@ head907d_curs_clr(struct nv50_head *head)
int
head907d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -195,7 +195,7 @@ head907d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head907d_core_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -209,7 +209,7 @@ head907d_core_clr(struct nv50_head *head)
int
head907d_core_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -246,7 +246,7 @@ head907d_core_set(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head907d_olut_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -263,7 +263,7 @@ head907d_olut_clr(struct nv50_head *head)
int
head907d_olut_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -322,7 +322,7 @@ bool head907d_ilut_check(int size)
int
head907d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
struct nv50_head_mode *m = &asyh->mode;
const int i = head->base.index;
int ret;
@@ -378,7 +378,7 @@ head907d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
int
head907d_view(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head917d.c b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
index 4ce47b55f72c..17234667771d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
@@ -30,7 +30,7 @@
static int
head917d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -48,7 +48,7 @@ head917d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head917d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u32 bounds = 0;
int ret;
@@ -77,7 +77,7 @@ head917d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
head917d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index a4a3b78ea42c..3adc33279315 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -30,7 +30,7 @@
static int
headc37d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u8 depth;
int ret;
@@ -64,7 +64,7 @@ headc37d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
headc37d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -85,7 +85,7 @@ headc37d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
int
headc37d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -104,7 +104,7 @@ headc37d_dither(struct nv50_head *head, struct nv50_head_atom *asyh)
int
headc37d_curs_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -122,7 +122,7 @@ headc37d_curs_clr(struct nv50_head *head)
int
headc37d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -161,7 +161,7 @@ headc37d_curs_format(struct nv50_head *head, struct nv50_wndw_atom *asyw,
static int
headc37d_olut_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -175,7 +175,7 @@ headc37d_olut_clr(struct nv50_head *head)
static int
headc37d_olut_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -209,7 +209,7 @@ headc37d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
static int
headc37d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
struct nv50_head_mode *m = &asyh->mode;
const int i = head->base.index;
int ret;
@@ -254,7 +254,7 @@ headc37d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
int
headc37d_view(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 543f08ceaad6..08b7dded554f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -30,7 +30,7 @@
static int
headc57d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
u8 depth;
int ret;
@@ -65,7 +65,7 @@ headc57d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
headc57d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -83,7 +83,7 @@ headc57d_procamp(struct nv50_head *head, struct nv50_head_atom *asyh)
static int
headc57d_olut_clr(struct nv50_head *head)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -97,7 +97,7 @@ headc57d_olut_clr(struct nv50_head *head)
static int
headc57d_olut_set(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
const int i = head->base.index;
int ret;
@@ -188,7 +188,7 @@ headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
static int
headc57d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
{
- struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+ struct nvif_push *push = nv50_disp(head->base.base.drm_dev)->core->chan.push;
struct nv50_head_mode *m = &asyh->mode;
const int i = head->base.index;
int ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 35bcb541722b..26bb8b162235 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -181,7 +181,7 @@ nouveau_connector_is_mst(struct drm_connector *connector)
static inline struct nouveau_connector *
nouveau_crtc_connector_get(struct nouveau_crtc *nv_crtc)
{
- struct drm_device *dev = nv_crtc->base.dev;
+ struct drm_device *dev = nv_crtc->base.drm_dev;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct nouveau_connector *nv_connector = NULL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index ec3ffff487fc..2301db014be3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -83,7 +83,7 @@ static bool
nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int *vpos, int *hpos,
ktime_t *stime, ktime_t *etime)
{
- struct drm_vblank_crtc *vblank = &crtc->dev->vblank[drm_crtc_index(crtc)];
+ struct drm_vblank_crtc *vblank = &crtc->drm_dev->vblank[drm_crtc_index(crtc)];
struct nvif_head *head = &nouveau_crtc(crtc)->head;
struct nvif_head_scanoutpos_v0 args;
int retry = 20;
--
2.39.2
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
2023-07-12 9:46 ` [Nouveau] [PATCH RFC v1 26/52] drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev Uwe Kleine-König
@ 2023-07-12 10:13 ` Paul Kocialkowski
2023-07-12 10:19 ` Thomas Zimmermann
` (3 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: Paul Kocialkowski @ 2023-07-12 10:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Marian Cichy,
Xinliang Liu, Linus Walleij, Tomi Valkeinen, Alexey Kodanev,
dri-devel, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Bhawanpreet Lakha,
Wenjing Liu, Javier Martinez Canillas, Stanislav Lisovskiy,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Jani Nikula, Sascha Hauer,
Lucas De Marchi, Inki Dae, Hersen Wu, Jessica Zhang,
Kamlesh Gurudasani, Matt Roper, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Manasi Navare, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, linux-aspeed, nouveau, Mitul Golani,
Edmund Dea, José Roberto de Souza, virtualization,
Thierry Reding, Yongqin Liu, Mario Limonciello, Fei Yang,
Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Graham Sider, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna, Maxime Ripard,
Jani Nikula, Chaitanya Kumar Borah, Philipp Zabel, linux-amlogic,
Evan Quan, Michal Simek, linux-arm-kernel, Sean Paul,
Neil Armstrong, Kai Vehmanen, Boris Brezillon, Chunyan Zhang,
Qingqing Zhuo, Sandy Huang, Swati Sharma, John Stultz,
linux-renesas-soc, Kyungmin Park, Drew Davenport, Kevin Hilman,
Hawking Zhang, Haneen Mohammed, Anusha Srivatsa, Dan Carpenter,
Joonas Lahtinen, linux-hyperv, Stefan Agner, Melissa Wen,
Maíra Canal, Luca Coelho, Laurent Pinchart, Andrzej Hajda,
Likun Gao, Sam Ravnborg, Alain Volmat, Xinwei Kong,
Jernej Skrabec, Deepak Rawat, Chen-Yu Tsai, Joel Stanley, xurui,
Ankit Nautiyal, Harry Wentland, Sumit Semwal, Alan Liu,
Philip Yang, intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Rodrigo Vivi, Mikko Perttunen,
Tvrtko Ursulin, Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma,
Pan, Xinhui, Biju Das, Chia-I Wu, Konrad Dybcio, Kieran Bingham,
Tian Tao, Shawn Guo, Christian König, Khaled Almahallawy,
linux-stm32, Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Leo Li, Uma Shankar, Mika Kahola,
Maxime Coquelin, Jiasheng Jiang, Srinivasan Shanmugam,
Vinod Govindapillai, linux-tegra, Marek Olšák,
Maarten Lankhorst, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, David Tadokoro,
AngeloGioacchino Del Regno, Orson Zhai, amd-gfx, Jyri Sarha,
Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 19020 bytes --]
Hi Uwe,
On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
Well personally I usually expect that the "dev" member of a subsystem-specific
struct refers to a device of that subsystem, so for me having "dev" refer to
a drm_device for e.g. drm_crtc makes good sense.
I would only expect dev to refer to a struct device in the subsystem-specific
device structure (drm_device). I don't think it makes much sense to carry
the struct device in any other subsystem-specific structure anyway.
So IMO things are fine as-is but this is not a very strong opinion either.
> I think there is a big benefit when these are all renamed to "drm_dev".
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!
I would definitely prefer "drm_dev" over "drmdev" (hard to read, feels like
aborted camelcase, pretty ugly) or "drm" (too vague).
Cheers,
Paul
> Some statistics:
>
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> 1 struct drm_device *adev_to_drm
> 1 struct drm_device *drm_
> 1 struct drm_device *drm_dev
> 1 struct drm_device *drm_dev
> 1 struct drm_device *pdev
> 1 struct drm_device *rdev
> 1 struct drm_device *vdev
> 2 struct drm_device *dcss_drv_dev_to_drm
> 2 struct drm_device **ddev
> 2 struct drm_device *drm_dev_alloc
> 2 struct drm_device *mock
> 2 struct drm_device *p_ddev
> 5 struct drm_device *device
> 9 struct drm_device * dev
> 25 struct drm_device *d
> 95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
> 4190 struct drm_device *dev
>
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.
>
> To make this series a bit easier handleable, I first added an alias for
> drm_crtc::dev, then converted the drivers one after another and the last
> patch drops the "dev" name. This has the advantage of being easier to
> review, and if I should have missed an instance only the last patch must
> be dropped/reverted. Also this series might conflict with other patches,
> in this case the remaining patches can still go in (apart from the last
> one of course). Maybe it also makes sense to delay applying the last
> patch by one development cycle?
>
> The series was compile tested for arm, arm64, powerpc and amd64 using an
> allmodconfig (though I only build drivers/gpu/).
>
> Best regards
> Uwe
>
> Uwe Kleine-König (52):
> drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
> drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/armada: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/exynos: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gma500: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/meson: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/pl111: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/radeon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/renesas: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/solomon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sun4i: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tegra: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tidss: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tilcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tiny: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/tve200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/udl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vboxvideo: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vc4: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/virtio: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vkms: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vmwgfx: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/xen: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/xlnx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/crtc: Complete renaming struct drm_crtc::dev to drm_dev
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 22 +--
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 26 +--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 8 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 +--
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-
> drivers/gpu/drm/arm/malidp_crtc.c | 7 +-
> drivers/gpu/drm/armada/armada_crtc.c | 10 +-
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 6 +-
> drivers/gpu/drm/ast/ast_dp.c | 2 +-
> drivers/gpu/drm/ast/ast_mode.c | 26 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 10 +-
> drivers/gpu/drm/drm_atomic.c | 22 +--
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
> drivers/gpu/drm/drm_atomic_uapi.c | 22 +--
> drivers/gpu/drm/drm_blend.c | 2 +-
> drivers/gpu/drm/drm_color_mgmt.c | 10 +-
> drivers/gpu/drm/drm_crtc.c | 19 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 10 +-
> drivers/gpu/drm/drm_debugfs.c | 2 +-
> drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
> drivers/gpu/drm/drm_fb_helper.c | 6 +-
> drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
> drivers/gpu/drm/drm_plane.c | 2 +-
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
> drivers/gpu/drm/drm_vblank.c | 40 ++---
> drivers/gpu/drm/drm_vblank_work.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 16 +-
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
> drivers/gpu/drm/gma500/gma_display.c | 20 +--
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 +-
> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +-
> drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/psb_irq.c | 6 +-
> drivers/gpu/drm/gud/gud_pipe.c | 6 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 +--
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 6 +-
> drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
> drivers/gpu/drm/i915/display/hsw_ips.c | 16 +-
> drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +-
> drivers/gpu/drm/i915/display/i9xx_wm.c | 40 ++---
> drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +-
> drivers/gpu/drm/i915/display/intel_color.c | 124 +++++++-------
> drivers/gpu/drm/i915/display/intel_crtc.c | 20 +--
> .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 28 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 154 +++++++++---------
> .../gpu/drm/i915/display/intel_display_irq.c | 22 +--
> .../gpu/drm/i915/display/intel_display_rps.c | 2 +-
> .../drm/i915/display/intel_display_trace.h | 12 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dpll.c | 38 ++---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 ++---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_drrs.c | 10 +-
> drivers/gpu/drm/i915/display/intel_dsb.c | 8 +-
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fdi.c | 22 +--
> .../drm/i915/display/intel_fifo_underrun.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> .../drm/i915/display/intel_modeset_setup.c | 22 +--
> .../drm/i915/display/intel_modeset_verify.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.c | 4 +-
> .../gpu/drm/i915/display/intel_pch_display.c | 32 ++--
> .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 10 +-
> .../drm/i915/display/intel_plane_initial.c | 6 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 14 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vblank.c | 24 +--
> drivers/gpu/drm/i915/display/intel_vdsc.c | 18 +-
> drivers/gpu/drm/i915/display/intel_vrr.c | 18 +-
> drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
> .../drm/i915/display/skl_universal_plane.c | 6 +-
> drivers/gpu/drm/i915/display/skl_watermark.c | 42 ++---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
> drivers/gpu/drm/imx/dcss/dcss-crtc.c | 20 +--
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 15 +-
> drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 16 +-
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +-
> drivers/gpu/drm/kmb/kmb_crtc.c | 16 +-
> drivers/gpu/drm/logicvc/logicvc_crtc.c | 14 +-
> drivers/gpu/drm/mcde/mcde_display.c | 18 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 22 +--
> drivers/gpu/drm/meson/meson_crtc.c | 12 +-
> drivers/gpu/drm/mgag200/mgag200_g200.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200eh.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_g200er.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200ev.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200se.c | 6 +-
> drivers/gpu/drm/mgag200/mgag200_g200wb.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 70 ++++----
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 12 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 20 +--
> drivers/gpu/drm/msm/msm_drv.c | 4 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 18 +-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 16 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 58 +++----
> drivers/gpu/drm/nouveau/dispnv04/cursor.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/atom.h | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/crc.c | 30 ++--
> drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc57d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +-
> drivers/gpu/drm/nouveau/dispnv50/head.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv50/head507d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head827d.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/head907d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head917d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 18 +-
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 10 +-
> drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 56 +++----
> drivers/gpu/drm/omapdrm/omap_irq.c | 6 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 +-
> drivers/gpu/drm/pl111/pl111_display.c | 16 +-
> drivers/gpu/drm/qxl/qxl_display.c | 2 +-
> drivers/gpu/drm/radeon/atombios_crtc.c | 54 +++---
> drivers/gpu/drm/radeon/radeon_cursor.c | 14 +-
> drivers/gpu/drm/radeon/radeon_display.c | 28 ++--
> drivers/gpu/drm/radeon/radeon_kms.c | 6 +-
> drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +-
> .../gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 14 +-
> .../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 20 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 15 +-
> drivers/gpu/drm/solomon/ssd130x.c | 2 +-
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 +-
> drivers/gpu/drm/sti/sti_crtc.c | 14 +-
> drivers/gpu/drm/stm/ltdc.c | 12 +-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +-
> drivers/gpu/drm/tegra/dc.c | 12 +-
> drivers/gpu/drm/tidss/tidss_crtc.c | 19 ++-
> drivers/gpu/drm/tidss/tidss_irq.c | 4 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 43 ++---
> drivers/gpu/drm/tiny/bochs.c | 6 +-
> drivers/gpu/drm/tiny/cirrus.c | 2 +-
> drivers/gpu/drm/tiny/gm12u320.c | 4 +-
> drivers/gpu/drm/tiny/hx8357d.c | 4 +-
> drivers/gpu/drm/tiny/ili9163.c | 4 +-
> drivers/gpu/drm/tiny/ili9225.c | 8 +-
> drivers/gpu/drm/tiny/ili9341.c | 4 +-
> drivers/gpu/drm/tiny/ili9486.c | 4 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
> drivers/gpu/drm/tiny/ofdrm.c | 8 +-
> drivers/gpu/drm/tiny/panel-mipi-dbi.c | 6 +-
> drivers/gpu/drm/tiny/repaper.c | 8 +-
> drivers/gpu/drm/tiny/simpledrm.c | 2 +-
> drivers/gpu/drm/tiny/st7586.c | 6 +-
> drivers/gpu/drm/tiny/st7735r.c | 4 +-
> drivers/gpu/drm/tve200/tve200_display.c | 14 +-
> drivers/gpu/drm/udl/udl_modeset.c | 4 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 6 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 38 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 12 +-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
> drivers/gpu/drm/vkms/vkms_crtc.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 10 +-
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 8 +-
> include/drm/drm_atomic_helper.h | 2 +-
> include/drm/drm_crtc.h | 4 +-
> 194 files changed, 1296 insertions(+), 1264 deletions(-)
>
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
> --
> 2.39.2
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
2023-07-12 9:46 ` [Nouveau] [PATCH RFC v1 26/52] drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev Uwe Kleine-König
2023-07-12 10:13 ` [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Paul Kocialkowski
@ 2023-07-12 10:19 ` Thomas Zimmermann
2023-07-12 10:54 ` Uwe Kleine-König
2023-07-12 10:46 ` Christian König
` (2 subsequent siblings)
5 siblings, 1 reply; 33+ messages in thread
From: Thomas Zimmermann @ 2023-07-12 10:19 UTC (permalink / raw)
To: Uwe Kleine-König, Maarten Lankhorst, Maxime Ripard,
David Airlie, Daniel Vetter, Alex Deucher, Christian König,
Pan, Xinhui, Harry Wentland, Leo Li, Rodrigo Siqueira,
Hamza Mahfooz, Javier Martinez Canillas, Guchun Chen,
Srinivasan Shanmugam, Evan Quan, Likun Gao,
Marek Olšák, David Francis, Hawking Zhang,
Graham Sider, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, Jani Nikula, xurui, Laurent Pinchart,
Maíra Canal, André Almeida, Qingqing Zhuo,
Aurabindo Pillai, Hersen Wu, Fangzhi Zuo, Stylon Wang, Alan Liu,
Wayne Lin, Aaron Liu, Melissa Wen, Bhawanpreet Lakha,
David Tadokoro, Wenjing Liu, Jiapeng Chong, Mario Limonciello,
Alexey Kodanev, Roman Li, Joaquín Ignacio Aramendía,
Dave Airlie, Russell King, Liviu Dudau, Joel Stanley,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Stefan Agner, Alison Wang, Patrik Jakobsson,
Noralf Trønnes, Xinliang Liu, Tian Tao, Danilo Krummrich,
Deepak Rawat, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Ville Syrjälä,
Lucas De Marchi, Ankit Nautiyal, Andrzej Hajda, Matt Roper,
Stanislav Lisovskiy, Radhakrishna Sripada, Hans de Goede,
Luca Coelho, Niranjana Vishwanathapura, Kai Vehmanen,
Vinod Govindapillai, Łukasz Bartosik, Anusha Srivatsa,
Chaitanya Kumar Borah, Uma Shankar, Imre Deak, Mitul Golani,
Swati Sharma, Jouni Högander, Mika Kahola,
José Roberto de Souza, Arun R Murthy, Gustavo Sousa,
Khaled Almahallawy, Juha-Pekka Heikkila, Andi Shyti, Nirmoy Das,
Fei Yang, Animesh Manna, Deepak R Varma, Jiri Slaby (SUSE),
Dmitry Baryshkov, Vandita Kulkarni, Suraj Kandpal, Manasi Navare,
Drew Davenport, Laurentiu Palcu, Shawn Guo, Sascha Hauer,
Philipp Zabel, Marian Cichy, Dan Carpenter, Paul Cercueil,
Anitha Chrisanthus, Edmund Dea, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Neil Armstrong, Kevin Hilman,
Rob Clark, Abhinav Kumar, Vinod Polimera, Jiasheng Jiang,
Konrad Dybcio, Jessica Zhang, Liu Shixin, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Emma Anholt, Gerd Hoffmann, Kieran Bingham, Tomi Valkeinen,
Wolfram Sang, Geert Uytterhoeven, Biju Das, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Thierry Reding, Mikko Perttunen,
Jonathan Hunter, Jyri Sarha, David Lechner, Kamlesh Gurudasani,
Rodrigo Siqueira, Melissa Wen, Oleksandr Andrushchenko,
Michal Simek
Cc: Haneen Mohammed, linux-hyperv, linux-aspeed, nouveau, dri-devel,
virtualization, Yongqin Liu, Alim Akhtar, Marijn Suijten,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
amd-gfx, linux-stm32, linux-rockchip, Xinwei Kong,
VMware Graphics Reviewers, NXP Linux Team, spice-devel,
linux-sunxi, Martin Blumenstingl, linux-arm-msm, intel-gfx,
linux-mediatek, xen-devel, linux-tegra, linux-amlogic,
Gurchetan Singh, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-mips,
Chia-I Wu, linux-renesas-soc, kernel, John Stultz, freedreno,
Lucas Stach
[-- Attachment #1.1: Type: text/plain, Size: 18947 bytes --]
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit when these are all renamed to "drm_dev".
If you rename drm_crtc.dev, you should also address *all* other data
structures.
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!
We've discussed this to death. IIRC 'drm' would be the prefered choice.
Best regards
Thomas
>
> Some statistics:
>
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> 1 struct drm_device *adev_to_drm
> 1 struct drm_device *drm_
> 1 struct drm_device *drm_dev
> 1 struct drm_device *drm_dev
> 1 struct drm_device *pdev
> 1 struct drm_device *rdev
> 1 struct drm_device *vdev
> 2 struct drm_device *dcss_drv_dev_to_drm
> 2 struct drm_device **ddev
> 2 struct drm_device *drm_dev_alloc
> 2 struct drm_device *mock
> 2 struct drm_device *p_ddev
> 5 struct drm_device *device
> 9 struct drm_device * dev
> 25 struct drm_device *d
> 95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
> 4190 struct drm_device *dev
>
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.
>
> To make this series a bit easier handleable, I first added an alias for
> drm_crtc::dev, then converted the drivers one after another and the last
> patch drops the "dev" name. This has the advantage of being easier to
> review, and if I should have missed an instance only the last patch must
> be dropped/reverted. Also this series might conflict with other patches,
> in this case the remaining patches can still go in (apart from the last
> one of course). Maybe it also makes sense to delay applying the last
> patch by one development cycle?
>
> The series was compile tested for arm, arm64, powerpc and amd64 using an
> allmodconfig (though I only build drivers/gpu/).
>
> Best regards
> Uwe
>
> Uwe Kleine-König (52):
> drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
> drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/armada: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/exynos: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gma500: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/meson: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/pl111: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/radeon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/renesas: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/solomon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sun4i: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tegra: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tidss: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tilcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tiny: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/tve200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/udl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vboxvideo: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vc4: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/virtio: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vkms: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vmwgfx: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/xen: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/xlnx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/crtc: Complete renaming struct drm_crtc::dev to drm_dev
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 22 +--
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 26 +--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 8 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 +--
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-
> drivers/gpu/drm/arm/malidp_crtc.c | 7 +-
> drivers/gpu/drm/armada/armada_crtc.c | 10 +-
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 6 +-
> drivers/gpu/drm/ast/ast_dp.c | 2 +-
> drivers/gpu/drm/ast/ast_mode.c | 26 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 10 +-
> drivers/gpu/drm/drm_atomic.c | 22 +--
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
> drivers/gpu/drm/drm_atomic_uapi.c | 22 +--
> drivers/gpu/drm/drm_blend.c | 2 +-
> drivers/gpu/drm/drm_color_mgmt.c | 10 +-
> drivers/gpu/drm/drm_crtc.c | 19 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 10 +-
> drivers/gpu/drm/drm_debugfs.c | 2 +-
> drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
> drivers/gpu/drm/drm_fb_helper.c | 6 +-
> drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
> drivers/gpu/drm/drm_plane.c | 2 +-
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
> drivers/gpu/drm/drm_vblank.c | 40 ++---
> drivers/gpu/drm/drm_vblank_work.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 16 +-
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
> drivers/gpu/drm/gma500/gma_display.c | 20 +--
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 +-
> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +-
> drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/psb_irq.c | 6 +-
> drivers/gpu/drm/gud/gud_pipe.c | 6 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 +--
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 6 +-
> drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
> drivers/gpu/drm/i915/display/hsw_ips.c | 16 +-
> drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +-
> drivers/gpu/drm/i915/display/i9xx_wm.c | 40 ++---
> drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +-
> drivers/gpu/drm/i915/display/intel_color.c | 124 +++++++-------
> drivers/gpu/drm/i915/display/intel_crtc.c | 20 +--
> .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 28 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 154 +++++++++---------
> .../gpu/drm/i915/display/intel_display_irq.c | 22 +--
> .../gpu/drm/i915/display/intel_display_rps.c | 2 +-
> .../drm/i915/display/intel_display_trace.h | 12 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dpll.c | 38 ++---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 ++---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_drrs.c | 10 +-
> drivers/gpu/drm/i915/display/intel_dsb.c | 8 +-
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fdi.c | 22 +--
> .../drm/i915/display/intel_fifo_underrun.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> .../drm/i915/display/intel_modeset_setup.c | 22 +--
> .../drm/i915/display/intel_modeset_verify.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.c | 4 +-
> .../gpu/drm/i915/display/intel_pch_display.c | 32 ++--
> .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 10 +-
> .../drm/i915/display/intel_plane_initial.c | 6 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 14 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vblank.c | 24 +--
> drivers/gpu/drm/i915/display/intel_vdsc.c | 18 +-
> drivers/gpu/drm/i915/display/intel_vrr.c | 18 +-
> drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
> .../drm/i915/display/skl_universal_plane.c | 6 +-
> drivers/gpu/drm/i915/display/skl_watermark.c | 42 ++---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
> drivers/gpu/drm/imx/dcss/dcss-crtc.c | 20 +--
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 15 +-
> drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 16 +-
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +-
> drivers/gpu/drm/kmb/kmb_crtc.c | 16 +-
> drivers/gpu/drm/logicvc/logicvc_crtc.c | 14 +-
> drivers/gpu/drm/mcde/mcde_display.c | 18 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 22 +--
> drivers/gpu/drm/meson/meson_crtc.c | 12 +-
> drivers/gpu/drm/mgag200/mgag200_g200.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200eh.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_g200er.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200ev.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200se.c | 6 +-
> drivers/gpu/drm/mgag200/mgag200_g200wb.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 70 ++++----
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 12 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 20 +--
> drivers/gpu/drm/msm/msm_drv.c | 4 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 18 +-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 16 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 58 +++----
> drivers/gpu/drm/nouveau/dispnv04/cursor.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/atom.h | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/crc.c | 30 ++--
> drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc57d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +-
> drivers/gpu/drm/nouveau/dispnv50/head.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv50/head507d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head827d.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/head907d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head917d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 18 +-
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 10 +-
> drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 56 +++----
> drivers/gpu/drm/omapdrm/omap_irq.c | 6 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 +-
> drivers/gpu/drm/pl111/pl111_display.c | 16 +-
> drivers/gpu/drm/qxl/qxl_display.c | 2 +-
> drivers/gpu/drm/radeon/atombios_crtc.c | 54 +++---
> drivers/gpu/drm/radeon/radeon_cursor.c | 14 +-
> drivers/gpu/drm/radeon/radeon_display.c | 28 ++--
> drivers/gpu/drm/radeon/radeon_kms.c | 6 +-
> drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +-
> .../gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 14 +-
> .../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 20 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 15 +-
> drivers/gpu/drm/solomon/ssd130x.c | 2 +-
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 +-
> drivers/gpu/drm/sti/sti_crtc.c | 14 +-
> drivers/gpu/drm/stm/ltdc.c | 12 +-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +-
> drivers/gpu/drm/tegra/dc.c | 12 +-
> drivers/gpu/drm/tidss/tidss_crtc.c | 19 ++-
> drivers/gpu/drm/tidss/tidss_irq.c | 4 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 43 ++---
> drivers/gpu/drm/tiny/bochs.c | 6 +-
> drivers/gpu/drm/tiny/cirrus.c | 2 +-
> drivers/gpu/drm/tiny/gm12u320.c | 4 +-
> drivers/gpu/drm/tiny/hx8357d.c | 4 +-
> drivers/gpu/drm/tiny/ili9163.c | 4 +-
> drivers/gpu/drm/tiny/ili9225.c | 8 +-
> drivers/gpu/drm/tiny/ili9341.c | 4 +-
> drivers/gpu/drm/tiny/ili9486.c | 4 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
> drivers/gpu/drm/tiny/ofdrm.c | 8 +-
> drivers/gpu/drm/tiny/panel-mipi-dbi.c | 6 +-
> drivers/gpu/drm/tiny/repaper.c | 8 +-
> drivers/gpu/drm/tiny/simpledrm.c | 2 +-
> drivers/gpu/drm/tiny/st7586.c | 6 +-
> drivers/gpu/drm/tiny/st7735r.c | 4 +-
> drivers/gpu/drm/tve200/tve200_display.c | 14 +-
> drivers/gpu/drm/udl/udl_modeset.c | 4 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 6 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 38 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 12 +-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
> drivers/gpu/drm/vkms/vkms_crtc.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 10 +-
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 8 +-
> include/drm/drm_atomic_helper.h | 2 +-
> include/drm/drm_crtc.h | 4 +-
> 194 files changed, 1296 insertions(+), 1264 deletions(-)
>
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
` (2 preceding siblings ...)
2023-07-12 10:19 ` Thomas Zimmermann
@ 2023-07-12 10:46 ` Christian König
2023-07-12 11:02 ` Uwe Kleine-König
2023-07-12 14:34 ` Jani Nikula
2023-07-13 7:54 ` [Nouveau] " Thomas Zimmermann
5 siblings, 1 reply; 33+ messages in thread
From: Christian König @ 2023-07-12 10:46 UTC (permalink / raw)
To: Uwe Kleine-König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Alex Deucher,
Pan, Xinhui, Harry Wentland, Leo Li, Rodrigo Siqueira,
Hamza Mahfooz, Javier Martinez Canillas, Guchun Chen,
Srinivasan Shanmugam, Evan Quan, Likun Gao,
Marek Olšák, David Francis, Hawking Zhang,
Graham Sider, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, Jani Nikula, xurui, Laurent Pinchart,
Maíra Canal, André Almeida, Qingqing Zhuo,
Aurabindo Pillai, Hersen Wu, Fangzhi Zuo, Stylon Wang, Alan Liu,
Wayne Lin, Aaron Liu, Melissa Wen, Bhawanpreet Lakha,
David Tadokoro, Wenjing Liu, Jiapeng Chong, Mario Limonciello,
Alexey Kodanev, Roman Li, Joaquín Ignacio Aramendía,
Dave Airlie, Russell King, Liviu Dudau, Joel Stanley,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Stefan Agner, Alison Wang, Patrik Jakobsson,
Noralf Trønnes, Xinliang Liu, Tian Tao, Danilo Krummrich,
Deepak Rawat, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Ville Syrjälä,
Lucas De Marchi, Ankit Nautiyal, Andrzej Hajda, Matt Roper,
Stanislav Lisovskiy, Radhakrishna Sripada, Hans de Goede,
Luca Coelho, Niranjana Vishwanathapura, Kai Vehmanen,
Vinod Govindapillai, Łukasz Bartosik, Anusha Srivatsa,
Chaitanya Kumar Borah, Uma Shankar, Imre Deak, Mitul Golani,
Swati Sharma, Jouni Högander, Mika Kahola,
José Roberto de Souza, Arun R Murthy, Gustavo Sousa,
Khaled Almahallawy, Juha-Pekka Heikkila, Andi Shyti, Nirmoy Das,
Fei Yang, Animesh Manna, Deepak R Varma, Jiri Slaby (SUSE),
Dmitry Baryshkov, Vandita Kulkarni, Suraj Kandpal, Manasi Navare,
Drew Davenport, Laurentiu Palcu, Shawn Guo, Sascha Hauer,
Philipp Zabel, Marian Cichy, Dan Carpenter, Paul Cercueil,
Anitha Chrisanthus, Edmund Dea, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Neil Armstrong, Kevin Hilman,
Rob Clark, Abhinav Kumar, Vinod Polimera, Jiasheng Jiang,
Konrad Dybcio, Jessica Zhang, Liu Shixin, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Emma Anholt, Gerd Hoffmann, Kieran Bingham, Tomi Valkeinen,
Wolfram Sang, Geert Uytterhoeven, Biju Das, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Thierry Reding, Mikko Perttunen,
Jonathan Hunter, Jyri Sarha, David Lechner, Kamlesh Gurudasani,
Rodrigo Siqueira, Melissa Wen, Oleksandr Andrushchenko,
Michal Simek
Cc: Haneen Mohammed, linux-hyperv, linux-aspeed, nouveau, dri-devel,
virtualization, Yongqin Liu, Alim Akhtar, Marijn Suijten,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
amd-gfx, linux-stm32, linux-rockchip, Xinwei Kong,
VMware Graphics Reviewers, NXP Linux Team, spice-devel,
linux-sunxi, Martin Blumenstingl, linux-arm-msm, intel-gfx,
linux-mediatek, xen-devel, linux-tegra, linux-amlogic,
Gurchetan Singh, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-mips,
Chia-I Wu, linux-renesas-soc, kernel, John Stultz, freedreno,
Lucas Stach
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit when these are all renamed to "drm_dev".
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!
>
> Some statistics:
>
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> 1 struct drm_device *adev_to_drm
> 1 struct drm_device *drm_
> 1 struct drm_device *drm_dev
> 1 struct drm_device *drm_dev
> 1 struct drm_device *pdev
> 1 struct drm_device *rdev
> 1 struct drm_device *vdev
> 2 struct drm_device *dcss_drv_dev_to_drm
> 2 struct drm_device **ddev
> 2 struct drm_device *drm_dev_alloc
> 2 struct drm_device *mock
> 2 struct drm_device *p_ddev
> 5 struct drm_device *device
> 9 struct drm_device * dev
> 25 struct drm_device *d
> 95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
> 4190 struct drm_device *dev
>
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.
>
> To make this series a bit easier handleable, I first added an alias for
> drm_crtc::dev, then converted the drivers one after another and the last
> patch drops the "dev" name. This has the advantage of being easier to
> review, and if I should have missed an instance only the last patch must
> be dropped/reverted. Also this series might conflict with other patches,
> in this case the remaining patches can still go in (apart from the last
> one of course). Maybe it also makes sense to delay applying the last
> patch by one development cycle?
When you automatically generate the patch (with cocci for example) I
usually prefer a single patch instead.
Background is that this makes merge conflicts easier to handle and detect.
When you have multiple patches and a merge conflict because of some
added lines using the old field the build breaks only on the last patch
which removes the old field.
In such cases reviewing the patch just means automatically re-generating
it and double checking that you don't see anything funky.
Apart from that I honestly absolutely don't care what the name is.
Cheers,
Christian.
>
> The series was compile tested for arm, arm64, powerpc and amd64 using an
> allmodconfig (though I only build drivers/gpu/).
>
> Best regards
> Uwe
>
> Uwe Kleine-König (52):
> drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
> drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/armada: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/exynos: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gma500: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/meson: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/pl111: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/radeon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/renesas: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/solomon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sun4i: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tegra: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tidss: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tilcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tiny: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/tve200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/udl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vboxvideo: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vc4: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/virtio: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vkms: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vmwgfx: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/xen: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/xlnx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/crtc: Complete renaming struct drm_crtc::dev to drm_dev
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 22 +--
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 26 +--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 8 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 +--
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-
> drivers/gpu/drm/arm/malidp_crtc.c | 7 +-
> drivers/gpu/drm/armada/armada_crtc.c | 10 +-
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 6 +-
> drivers/gpu/drm/ast/ast_dp.c | 2 +-
> drivers/gpu/drm/ast/ast_mode.c | 26 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 10 +-
> drivers/gpu/drm/drm_atomic.c | 22 +--
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
> drivers/gpu/drm/drm_atomic_uapi.c | 22 +--
> drivers/gpu/drm/drm_blend.c | 2 +-
> drivers/gpu/drm/drm_color_mgmt.c | 10 +-
> drivers/gpu/drm/drm_crtc.c | 19 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 10 +-
> drivers/gpu/drm/drm_debugfs.c | 2 +-
> drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
> drivers/gpu/drm/drm_fb_helper.c | 6 +-
> drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
> drivers/gpu/drm/drm_plane.c | 2 +-
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
> drivers/gpu/drm/drm_vblank.c | 40 ++---
> drivers/gpu/drm/drm_vblank_work.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 16 +-
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
> drivers/gpu/drm/gma500/gma_display.c | 20 +--
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 +-
> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +-
> drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/psb_irq.c | 6 +-
> drivers/gpu/drm/gud/gud_pipe.c | 6 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 +--
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 6 +-
> drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
> drivers/gpu/drm/i915/display/hsw_ips.c | 16 +-
> drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +-
> drivers/gpu/drm/i915/display/i9xx_wm.c | 40 ++---
> drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +-
> drivers/gpu/drm/i915/display/intel_color.c | 124 +++++++-------
> drivers/gpu/drm/i915/display/intel_crtc.c | 20 +--
> .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 28 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 154 +++++++++---------
> .../gpu/drm/i915/display/intel_display_irq.c | 22 +--
> .../gpu/drm/i915/display/intel_display_rps.c | 2 +-
> .../drm/i915/display/intel_display_trace.h | 12 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dpll.c | 38 ++---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 ++---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_drrs.c | 10 +-
> drivers/gpu/drm/i915/display/intel_dsb.c | 8 +-
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fdi.c | 22 +--
> .../drm/i915/display/intel_fifo_underrun.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> .../drm/i915/display/intel_modeset_setup.c | 22 +--
> .../drm/i915/display/intel_modeset_verify.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.c | 4 +-
> .../gpu/drm/i915/display/intel_pch_display.c | 32 ++--
> .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 10 +-
> .../drm/i915/display/intel_plane_initial.c | 6 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 14 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vblank.c | 24 +--
> drivers/gpu/drm/i915/display/intel_vdsc.c | 18 +-
> drivers/gpu/drm/i915/display/intel_vrr.c | 18 +-
> drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
> .../drm/i915/display/skl_universal_plane.c | 6 +-
> drivers/gpu/drm/i915/display/skl_watermark.c | 42 ++---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
> drivers/gpu/drm/imx/dcss/dcss-crtc.c | 20 +--
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 15 +-
> drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 16 +-
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +-
> drivers/gpu/drm/kmb/kmb_crtc.c | 16 +-
> drivers/gpu/drm/logicvc/logicvc_crtc.c | 14 +-
> drivers/gpu/drm/mcde/mcde_display.c | 18 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 22 +--
> drivers/gpu/drm/meson/meson_crtc.c | 12 +-
> drivers/gpu/drm/mgag200/mgag200_g200.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200eh.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_g200er.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200ev.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200se.c | 6 +-
> drivers/gpu/drm/mgag200/mgag200_g200wb.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 70 ++++----
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 12 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 20 +--
> drivers/gpu/drm/msm/msm_drv.c | 4 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 18 +-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 16 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 58 +++----
> drivers/gpu/drm/nouveau/dispnv04/cursor.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/atom.h | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/crc.c | 30 ++--
> drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc57d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +-
> drivers/gpu/drm/nouveau/dispnv50/head.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv50/head507d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head827d.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/head907d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head917d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 18 +-
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 10 +-
> drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 56 +++----
> drivers/gpu/drm/omapdrm/omap_irq.c | 6 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 +-
> drivers/gpu/drm/pl111/pl111_display.c | 16 +-
> drivers/gpu/drm/qxl/qxl_display.c | 2 +-
> drivers/gpu/drm/radeon/atombios_crtc.c | 54 +++---
> drivers/gpu/drm/radeon/radeon_cursor.c | 14 +-
> drivers/gpu/drm/radeon/radeon_display.c | 28 ++--
> drivers/gpu/drm/radeon/radeon_kms.c | 6 +-
> drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +-
> .../gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 14 +-
> .../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 20 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 15 +-
> drivers/gpu/drm/solomon/ssd130x.c | 2 +-
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 +-
> drivers/gpu/drm/sti/sti_crtc.c | 14 +-
> drivers/gpu/drm/stm/ltdc.c | 12 +-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +-
> drivers/gpu/drm/tegra/dc.c | 12 +-
> drivers/gpu/drm/tidss/tidss_crtc.c | 19 ++-
> drivers/gpu/drm/tidss/tidss_irq.c | 4 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 43 ++---
> drivers/gpu/drm/tiny/bochs.c | 6 +-
> drivers/gpu/drm/tiny/cirrus.c | 2 +-
> drivers/gpu/drm/tiny/gm12u320.c | 4 +-
> drivers/gpu/drm/tiny/hx8357d.c | 4 +-
> drivers/gpu/drm/tiny/ili9163.c | 4 +-
> drivers/gpu/drm/tiny/ili9225.c | 8 +-
> drivers/gpu/drm/tiny/ili9341.c | 4 +-
> drivers/gpu/drm/tiny/ili9486.c | 4 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
> drivers/gpu/drm/tiny/ofdrm.c | 8 +-
> drivers/gpu/drm/tiny/panel-mipi-dbi.c | 6 +-
> drivers/gpu/drm/tiny/repaper.c | 8 +-
> drivers/gpu/drm/tiny/simpledrm.c | 2 +-
> drivers/gpu/drm/tiny/st7586.c | 6 +-
> drivers/gpu/drm/tiny/st7735r.c | 4 +-
> drivers/gpu/drm/tve200/tve200_display.c | 14 +-
> drivers/gpu/drm/udl/udl_modeset.c | 4 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 6 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 38 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 12 +-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
> drivers/gpu/drm/vkms/vkms_crtc.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 10 +-
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 8 +-
> include/drm/drm_atomic_helper.h | 2 +-
> include/drm/drm_crtc.h | 4 +-
> 194 files changed, 1296 insertions(+), 1264 deletions(-)
>
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 10:19 ` Thomas Zimmermann
@ 2023-07-12 10:54 ` Uwe Kleine-König
0 siblings, 0 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-12 10:54 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Bhawanpreet Lakha,
Wenjing Liu, Javier Martinez Canillas, Stanislav Lisovskiy,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Jani Nikula, Sascha Hauer,
Lucas De Marchi, Inki Dae, Hersen Wu, Jessica Zhang,
Kamlesh Gurudasani, Matt Roper, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Gerd Hoffmann, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Gurchetan Singh, Martin Blumenstingl,
linux-arm-msm, Animesh Manna, linux-renesas-soc, Maxime Ripard,
Jani Nikula, Chaitanya Kumar Borah, Biju Das, linux-amlogic,
Evan Quan, Michal Simek, linux-arm-kernel, Sean Paul,
Neil Armstrong, Kai Vehmanen, Boris Brezillon, Chunyan Zhang,
Qingqing Zhuo, Sandy Huang, Swati Sharma, John Stultz,
Paul Kocialkowski, Kyungmin Park, Drew Davenport, Kevin Hilman,
Hawking Zhang, Haneen Mohammed, Anusha Srivatsa, Dan Carpenter,
Joonas Lahtinen, linux-hyperv, Stefan Agner, Melissa Wen,
Maíra Canal, Luca Coelho, Laurent Pinchart, Andrzej Hajda,
Likun Gao, Sam Ravnborg, Alain Volmat, Xinwei Kong,
Jernej Skrabec, Deepak Rawat, Chen-Yu Tsai, Joel Stanley,
Orson Zhai, Ankit Nautiyal, Harry Wentland, Sumit Semwal,
Alan Liu, Philip Yang, intel-gfx, Alison Wang, Wolfram Sang,
Abhinav Kumar, Gustavo Sousa, Baolin Wang, Rodrigo Vivi,
Mikko Perttunen, Tvrtko Ursulin, Rodrigo Siqueira,
Tomi Valkeinen, Deepak R Varma, Pan, Xinhui, Chia-I Wu,
Konrad Dybcio, Kieran Bingham, Tian Tao, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Leo Li, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, Philipp Zabel,
Vinod Govindapillai, linux-tegra, Marek Olšák,
Maarten Lankhorst, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, David Tadokoro,
AngeloGioacchino Del Regno, Maxime Coquelin, amd-gfx, Jyri Sarha,
Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
Hello Thomas,
On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
>
> If you rename drm_crtc.dev, you should also address *all* other data
> structures.
Yes. Changing drm_crtc::dev was some effort, so I thought to send that
one out before doing the same to
drm_dp_mst_topology_mgr
drm_atomic_state
drm_master
drm_bridge
drm_client_dev
drm_connector
drm_debugfs_entry
drm_encoder
drm_fb_helper
drm_minor
drm_framebuffer
drm_gem_object
drm_plane
drm_property
drm_property_blob
drm_vblank_crtc
when in the end the intention isn't welcome.
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
>
> We've discussed this to death. IIRC 'drm' would be the prefered choice.
"drm" at least has the advantage to be the 2nd most common name. With
Paul Kocialkowski prefering "drm_dev" there is no clear favourite yet.
Maybe all the other people with strong opinions are dead if this was
"discussed to death" before? :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 10:46 ` Christian König
@ 2023-07-12 11:02 ` Uwe Kleine-König
2023-07-12 11:07 ` Julia Lawall
2023-07-12 12:52 ` Maxime Ripard
0 siblings, 2 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-12 11:02 UTC (permalink / raw)
To: Christian König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Bhawanpreet Lakha,
Wenjing Liu, Javier Martinez Canillas, Stanislav Lisovskiy,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Jani Nikula, Sascha Hauer,
Lucas De Marchi, Inki Dae, Hersen Wu, Jessica Zhang,
Kamlesh Gurudasani, Matt Roper, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Gerd Hoffmann, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
David Lechner, Julia Lawall, Juha-Pekka Heikkila,
Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Maxime Coquelin, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Jani Nikula,
Chaitanya Kumar Borah, Biju Das, linux-amlogic, Evan Quan,
Michal Simek, linux-arm-kernel, Sean Paul, Neil Armstrong,
Kai Vehmanen, Boris Brezillon, Chunyan Zhang, Qingqing Zhuo,
Sandy Huang, Swati Sharma, John Stultz, Paul Kocialkowski,
Kyungmin Park, Drew Davenport, Kevin Hilman, Hawking Zhang,
Haneen Mohammed, Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen,
linux-hyperv, Stefan Agner, Melissa Wen, Maíra Canal,
Luca Coelho, Laurent Pinchart, Andrzej Hajda, Likun Gao,
Sam Ravnborg, Alain Volmat, Xinwei Kong, Jernej Skrabec,
Deepak Rawat, Chen-Yu Tsai, Joel Stanley, Philipp Zabel,
Ankit Nautiyal, Harry Wentland, Sumit Semwal, Alan Liu,
Philip Yang, intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Rodrigo Vivi, Mikko Perttunen,
Tvrtko Ursulin, Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma,
Pan, Xinhui, Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao,
Shawn Guo, Khaled Almahallawy, linux-stm32, Emma Anholt,
Chun-Kuang Hu, Imre Deak, Liviu Dudau, Alexandre Torgue,
Roman Li, Paul Cercueil, Rob Clark, Hamza Mahfooz, Marek Vasut,
Jiapeng Chong, xen-devel, Guchun Chen, Oleksandr Andrushchenko,
Raphael Gallais-Pou, Rodrigo Siqueira, Russell King, Leo Li,
Uma Shankar, Mika Kahola, Jiasheng Jiang, Srinivasan Shanmugam,
Vinod Govindapillai, linux-tegra, Marek Olšák,
Maarten Lankhorst, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, David Tadokoro,
AngeloGioacchino Del Regno, Orson Zhai, amd-gfx, Jyri Sarha,
Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> > 1 struct drm_device *adev_to_drm
> > 1 struct drm_device *drm_
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device *pdev
> > 1 struct drm_device *rdev
> > 1 struct drm_device *vdev
> > 2 struct drm_device *dcss_drv_dev_to_drm
> > 2 struct drm_device **ddev
> > 2 struct drm_device *drm_dev_alloc
> > 2 struct drm_device *mock
> > 2 struct drm_device *p_ddev
> > 5 struct drm_device *device
> > 9 struct drm_device * dev
> > 25 struct drm_device *d
> > 95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> > 4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
> >
> > To make this series a bit easier handleable, I first added an alias for
> > drm_crtc::dev, then converted the drivers one after another and the last
> > patch drops the "dev" name. This has the advantage of being easier to
> > review, and if I should have missed an instance only the last patch must
> > be dropped/reverted. Also this series might conflict with other patches,
> > in this case the remaining patches can still go in (apart from the last
> > one of course). Maybe it also makes sense to delay applying the last
> > patch by one development cycle?
>
> When you automatically generate the patch (with cocci for example) I usually
> prefer a single patch instead.
Maybe I'm too stupid, but only parts of this patch were created by
coccinelle. I failed to convert code like
- spin_lock_irq(&crtc->dev->event_lock);
+ spin_lock_irq(&crtc->drm_dev->event_lock);
Added Julia to Cc, maybe she has a hint?!
(Up to now it's only
@@
struct drm_crtc *crtc;
@@
-crtc->dev
+crtc->drm_dev
)
> Background is that this makes merge conflicts easier to handle and detect.
Really? Each file (apart from include/drm/drm_crtc.h) is only touched
once. So unless I'm missing something you don't get less or easier
conflicts by doing it all in a single patch. But you gain the freedom to
drop a patch for one driver without having to drop the rest with it. So
I still like the split version better, but I'm open to a more verbose
reasoning from your side.
> When you have multiple patches and a merge conflict because of some added
> lines using the old field the build breaks only on the last patch which
> removes the old field.
Then you can revert/drop the last patch without having to respin the
whole single patch and thus caring for still more conflicts that arise
until the new version is sent.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 11:02 ` Uwe Kleine-König
@ 2023-07-12 11:07 ` Julia Lawall
2023-07-12 11:13 ` Andrzej Hajda
2023-07-12 12:52 ` Maxime Ripard
1 sibling, 1 reply; 33+ messages in thread
From: Julia Lawall @ 2023-07-12 11:07 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Bhawanpreet Lakha,
Wenjing Liu, Javier Martinez Canillas, Stanislav Lisovskiy,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Jani Nikula, Sascha Hauer,
Lucas De Marchi, Inki Dae, Hersen Wu, Jessica Zhang,
Kamlesh Gurudasani, Matt Roper, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Gerd Hoffmann, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
David Lechner, Julia Lawall, Juha-Pekka Heikkila,
Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Maxime Coquelin, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Jani Nikula,
Chaitanya Kumar Borah, Biju Das, linux-amlogic, Evan Quan,
Michal Simek, linux-arm-kernel, Sean Paul, Neil Armstrong,
Kai Vehmanen, Boris Brezillon, Chunyan Zhang, Qingqing Zhuo,
Sandy Huang, Swati Sharma, John Stultz, Paul Kocialkowski,
Kyungmin Park, Drew Davenport, Kevin Hilman, Hawking Zhang,
Haneen Mohammed, Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen,
linux-hyperv, Stefan Agner, Melissa Wen, Maíra Canal,
Luca Coelho, Laurent Pinchart, Andrzej Hajda, Likun Gao,
Sam Ravnborg, Alain Volmat, Xinwei Kong, Jernej Skrabec,
Deepak Rawat, Chen-Yu Tsai, Joel Stanley, Philipp Zabel,
Ankit Nautiyal, Harry Wentland, Sumit Semwal, Alan Liu,
Philip Yang, intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Rodrigo Vivi, Mikko Perttunen,
Tvrtko Ursulin, Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma,
Pan, Xinhui, Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao,
Shawn Guo, Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Leo Li, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, Vinod Govindapillai,
linux-tegra, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, Orson Zhai, amd-gfx,
Jyri Sarha, Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 4232 bytes --]
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device pointer variables being named "dev"
> > > because with that name I usually expect a struct device pointer.
> > >
> > > I think there is a big benefit when these are all renamed to "drm_dev".
> > > I have no strong preference here though, so "drmdev" or "drm" are fine
> > > for me, too. Let the bikesheding begin!
> > >
> > > Some statistics:
> > >
> > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> > > 1 struct drm_device *adev_to_drm
> > > 1 struct drm_device *drm_
> > > 1 struct drm_device *drm_dev
> > > 1 struct drm_device *drm_dev
> > > 1 struct drm_device *pdev
> > > 1 struct drm_device *rdev
> > > 1 struct drm_device *vdev
> > > 2 struct drm_device *dcss_drv_dev_to_drm
> > > 2 struct drm_device **ddev
> > > 2 struct drm_device *drm_dev_alloc
> > > 2 struct drm_device *mock
> > > 2 struct drm_device *p_ddev
> > > 5 struct drm_device *device
> > > 9 struct drm_device * dev
> > > 25 struct drm_device *d
> > > 95 struct drm_device *
> > > 216 struct drm_device *ddev
> > > 234 struct drm_device *drm_dev
> > > 611 struct drm_device *drm
> > > 4190 struct drm_device *dev
> > >
> > > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > > it's not only me and others like the result of this effort it should be
> > > followed up by adapting the other structs and the individual usages in
> > > the different drivers.
> > >
> > > To make this series a bit easier handleable, I first added an alias for
> > > drm_crtc::dev, then converted the drivers one after another and the last
> > > patch drops the "dev" name. This has the advantage of being easier to
> > > review, and if I should have missed an instance only the last patch must
> > > be dropped/reverted. Also this series might conflict with other patches,
> > > in this case the remaining patches can still go in (apart from the last
> > > one of course). Maybe it also makes sense to delay applying the last
> > > patch by one development cycle?
> >
> > When you automatically generate the patch (with cocci for example) I usually
> > prefer a single patch instead.
>
> Maybe I'm too stupid, but only parts of this patch were created by
> coccinelle. I failed to convert code like
>
> - spin_lock_irq(&crtc->dev->event_lock);
> + spin_lock_irq(&crtc->drm_dev->event_lock);
>
> Added Julia to Cc, maybe she has a hint?!
A priori, I see no reason why the rule below should not apply to the above
code. Is there a parsing problem in the containing function? You can run
spatch --parse-c file.c
If there is a paring problem, please let me know and i will try to fix it
so the while thing can be done automatically.
julia
>
> (Up to now it's only
>
> @@
> struct drm_crtc *crtc;
> @@
> -crtc->dev
> +crtc->drm_dev
>
> )
>
> > Background is that this makes merge conflicts easier to handle and detect.
>
> Really? Each file (apart from include/drm/drm_crtc.h) is only touched
> once. So unless I'm missing something you don't get less or easier
> conflicts by doing it all in a single patch. But you gain the freedom to
> drop a patch for one driver without having to drop the rest with it. So
> I still like the split version better, but I'm open to a more verbose
> reasoning from your side.
>
> > When you have multiple patches and a merge conflict because of some added
> > lines using the old field the build breaks only on the last patch which
> > removes the old field.
>
> Then you can revert/drop the last patch without having to respin the
> whole single patch and thus caring for still more conflicts that arise
> until the new version is sent.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | https://www.pengutronix.de/ |
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 11:07 ` Julia Lawall
@ 2023-07-12 11:13 ` Andrzej Hajda
0 siblings, 0 replies; 33+ messages in thread
From: Andrzej Hajda @ 2023-07-12 11:13 UTC (permalink / raw)
To: Julia Lawall, Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Bhawanpreet Lakha,
Wenjing Liu, Javier Martinez Canillas, Stanislav Lisovskiy,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Jani Nikula, Sascha Hauer,
Lucas De Marchi, Inki Dae, Hersen Wu, Jessica Zhang,
Kamlesh Gurudasani, Matt Roper, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Gerd Hoffmann, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Maxime Coquelin, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Jani Nikula,
Chaitanya Kumar Borah, Biju Das, linux-amlogic, Evan Quan,
Michal Simek, linux-arm-kernel, Sean Paul, Neil Armstrong,
Kai Vehmanen, Boris Brezillon, Chunyan Zhang, Qingqing Zhuo,
Sandy Huang, Swati Sharma, John Stultz, Paul Kocialkowski,
Kyungmin Park, Drew Davenport, Kevin Hilman, Hawking Zhang,
Haneen Mohammed, Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen,
linux-hyperv, Stefan Agner, Melissa Wen, Maíra Canal,
Luca Coelho, Laurent Pinchart, Likun Gao, Sam Ravnborg,
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, Philipp Zabel, Ankit Nautiyal,
Harry Wentland, Sumit Semwal, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Mikko Perttunen, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Leo Li, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, Vinod Govindapillai,
linux-tegra, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, Orson Zhai, amd-gfx,
Jyri Sarha, Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
On 12.07.2023 13:07, Julia Lawall wrote:
>
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
>
>> On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
>>> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
>>>> Hello,
>>>>
>>>> while I debugged an issue in the imx-lcdc driver I was constantly
>>>> irritated about struct drm_device pointer variables being named "dev"
>>>> because with that name I usually expect a struct device pointer.
>>>>
>>>> I think there is a big benefit when these are all renamed to "drm_dev".
>>>> I have no strong preference here though, so "drmdev" or "drm" are fine
>>>> for me, too. Let the bikesheding begin!
>>>>
>>>> Some statistics:
>>>>
>>>> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
>>>> 1 struct drm_device *adev_to_drm
>>>> 1 struct drm_device *drm_
>>>> 1 struct drm_device *drm_dev
>>>> 1 struct drm_device *drm_dev
>>>> 1 struct drm_device *pdev
>>>> 1 struct drm_device *rdev
>>>> 1 struct drm_device *vdev
>>>> 2 struct drm_device *dcss_drv_dev_to_drm
>>>> 2 struct drm_device **ddev
>>>> 2 struct drm_device *drm_dev_alloc
>>>> 2 struct drm_device *mock
>>>> 2 struct drm_device *p_ddev
>>>> 5 struct drm_device *device
>>>> 9 struct drm_device * dev
>>>> 25 struct drm_device *d
>>>> 95 struct drm_device *
>>>> 216 struct drm_device *ddev
>>>> 234 struct drm_device *drm_dev
>>>> 611 struct drm_device *drm
>>>> 4190 struct drm_device *dev
>>>>
>>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>>> it's not only me and others like the result of this effort it should be
>>>> followed up by adapting the other structs and the individual usages in
>>>> the different drivers.
>>>>
>>>> To make this series a bit easier handleable, I first added an alias for
>>>> drm_crtc::dev, then converted the drivers one after another and the last
>>>> patch drops the "dev" name. This has the advantage of being easier to
>>>> review, and if I should have missed an instance only the last patch must
>>>> be dropped/reverted. Also this series might conflict with other patches,
>>>> in this case the remaining patches can still go in (apart from the last
>>>> one of course). Maybe it also makes sense to delay applying the last
>>>> patch by one development cycle?
>>> When you automatically generate the patch (with cocci for example) I usually
>>> prefer a single patch instead.
>> Maybe I'm too stupid, but only parts of this patch were created by
>> coccinelle. I failed to convert code like
>>
>> - spin_lock_irq(&crtc->dev->event_lock);
>> + spin_lock_irq(&crtc->drm_dev->event_lock);
>>
>> Added Julia to Cc, maybe she has a hint?!
> A priori, I see no reason why the rule below should not apply to the above
> code. Is there a parsing problem in the containing function? You can run
>
> spatch --parse-c file.c
>
> If there is a paring problem, please let me know and i will try to fix it
> so the while thing can be done automatically.
I guess some clever macros can fool spatch, at least I observe such
things in i915 which often uses custom iterators.
Regards
Andrzej
>
> julia
>
>> (Up to now it's only
>>
>> @@
>> struct drm_crtc *crtc;
>> @@
>> -crtc->dev
>> +crtc->drm_dev
>>
>> )
>>
>>> Background is that this makes merge conflicts easier to handle and detect.
>> Really? Each file (apart from include/drm/drm_crtc.h) is only touched
>> once. So unless I'm missing something you don't get less or easier
>> conflicts by doing it all in a single patch. But you gain the freedom to
>> drop a patch for one driver without having to drop the rest with it. So
>> I still like the split version better, but I'm open to a more verbose
>> reasoning from your side.
>>
>>> When you have multiple patches and a merge conflict because of some added
>>> lines using the old field the build breaks only on the last patch which
>>> removes the old field.
>> Then you can revert/drop the last patch without having to respin the
>> whole single patch and thus caring for still more conflicts that arise
>> until the new version is sent.
>>
>> Best regards
>> Uwe
>>
>> --
>> Pengutronix e.K. | Uwe Kleine-König |
>> Industrial Linux Solutions | https://www.pengutronix.de/ |
> >
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 11:02 ` Uwe Kleine-König
2023-07-12 11:07 ` Julia Lawall
@ 2023-07-12 12:52 ` Maxime Ripard
2023-07-12 13:38 ` Uwe Kleine-König
1 sibling, 1 reply; 33+ messages in thread
From: Maxime Ripard @ 2023-07-12 12:52 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, linux-sunxi, Tim Huang,
Suraj Kandpal, André Almeida, Andi Shyti, Yifan Zhang,
Jani Nikula, Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu,
Jessica Zhang, Kamlesh Gurudasani, Bhawanpreet Lakha,
Łukasz Bartosik, Radhakrishna Sripada, Andrew Jeffery,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Ville Syrjälä,
David Lechner, Julia Lawall, Juha-Pekka Heikkila,
Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Maxime Coquelin, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Jani Nikula, Chaitanya Kumar Borah, Biju Das,
linux-amlogic, Evan Quan, Michal Simek, linux-arm-kernel,
Sean Paul, Neil Armstrong, Kai Vehmanen, Boris Brezillon,
Chunyan Zhang, Qingqing Zhuo, Sandy Huang, Swati Sharma,
John Stultz, Paul Kocialkowski, Kyungmin Park, Drew Davenport,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Anusha Srivatsa,
Dan Carpenter, Joonas Lahtinen, linux-hyperv, Stefan Agner,
Melissa Wen, Maíra Canal, Luca Coelho, Laurent Pinchart,
Andrzej Hajda, Likun Gao, Sam Ravnborg, Alain Volmat,
Xinwei Kong, Jernej Skrabec, Deepak Rawat, Chen-Yu Tsai,
Joel Stanley, Philipp Zabel, Ankit Nautiyal, Harry Wentland,
Sumit Semwal, Alan Liu, Philip Yang, intel-gfx, Alison Wang,
Wolfram Sang, Abhinav Kumar, Gustavo Sousa, Baolin Wang,
Rodrigo Vivi, Mikko Perttunen, Tvrtko Ursulin, Rodrigo Siqueira,
Tomi Valkeinen, Deepak R Varma, Pan, Xinhui, Chia-I Wu,
Konrad Dybcio, Kieran Bingham, Tian Tao, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Leo Li, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, Vinod Govindapillai,
linux-tegra, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, Orson Zhai, amd-gfx,
Jyri Sarha, Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > Background is that this makes merge conflicts easier to handle and detect.
>
> Really?
FWIW, I agree with Christian here.
> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> unless I'm missing something you don't get less or easier conflicts by
> doing it all in a single patch. But you gain the freedom to drop a
> patch for one driver without having to drop the rest with it.
Not really, because the last patch removed the union anyway. So you have
to revert both the last patch, plus that driver one. And then you need
to add a TODO to remove that union eventually.
> So I still like the split version better, but I'm open to a more
> verbose reasoning from your side.
You're doing only one thing here, really: you change the name of a
structure field. If it was shared between multiple maintainers, then
sure, splitting that up is easier for everyone, but this will go through
drm-misc, so I can't see the benefit it brings.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 12:52 ` Maxime Ripard
@ 2023-07-12 13:38 ` Uwe Kleine-König
2023-07-12 13:53 ` Maxime Ripard
2023-07-12 13:53 ` Christian König
0 siblings, 2 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-12 13:38 UTC (permalink / raw)
To: Maxime Ripard
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Jani Nikula,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Konrad Dybcio, Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Jani Nikula, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Julia Lawall, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, Lang Yu, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Leo Li, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > Background is that this makes merge conflicts easier to handle and detect.
> >
> > Really?
>
> FWIW, I agree with Christian here.
>
> > Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> > unless I'm missing something you don't get less or easier conflicts by
> > doing it all in a single patch. But you gain the freedom to drop a
> > patch for one driver without having to drop the rest with it.
>
> Not really, because the last patch removed the union anyway. So you have
> to revert both the last patch, plus that driver one. And then you need
> to add a TODO to remove that union eventually.
Yes, with a single patch you have only one revert (but 194 files changed,
1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
bigger). (And maybe you get away with just reverting the last patch.)
With a single patch the TODO after a revert is "redo it all again (and
prepare for a different set of conflicts)" while with the split series
it's only "fix that one driver that was forgotten/borked" + reapply that
10 line patch. As the one who gets that TODO, I prefer the latter.
So in sum: If your metric is "small count of reverted commits", you're
right. If however your metric is: Better get 95% of this series' change
in than maybe 0%, the split series is the way to do it.
With me having spend ~3h on this series' changes, it's maybe
understandable that I did it the way I did.
FTR: This series was created on top of v6.5-rc1. If you apply it to
drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
be the responsible maintainer who applies this series, I like being able
to just do git am --skip then.
FTR#2: In drm-misc-next is a new driver
(drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
now might indeed be a good idea.
> > So I still like the split version better, but I'm open to a more
> > verbose reasoning from your side.
>
> You're doing only one thing here, really: you change the name of a
> structure field. If it was shared between multiple maintainers, then
> sure, splitting that up is easier for everyone, but this will go through
> drm-misc, so I can't see the benefit it brings.
I see your argument, but I think mine weights more.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 13:38 ` Uwe Kleine-König
@ 2023-07-12 13:53 ` Maxime Ripard
2023-07-12 13:53 ` Christian König
1 sibling, 0 replies; 33+ messages in thread
From: Maxime Ripard @ 2023-07-12 13:53 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Jani Nikula,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Konrad Dybcio, Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Jani Nikula, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Julia Lawall, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, Lang Yu, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Leo Li, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]
On Wed, Jul 12, 2023 at 03:38:03PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > > Background is that this makes merge conflicts easier to handle and detect.
> > >
> > > Really?
> >
> > FWIW, I agree with Christian here.
> >
> > > Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> > > unless I'm missing something you don't get less or easier conflicts by
> > > doing it all in a single patch. But you gain the freedom to drop a
> > > patch for one driver without having to drop the rest with it.
> >
> > Not really, because the last patch removed the union anyway. So you have
> > to revert both the last patch, plus that driver one. And then you need
> > to add a TODO to remove that union eventually.
>
> Yes, with a single patch you have only one revert (but 194 files changed,
> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
> bigger). (And maybe you get away with just reverting the last patch.)
>
> With a single patch the TODO after a revert is "redo it all again (and
> prepare for a different set of conflicts)" while with the split series
> it's only "fix that one driver that was forgotten/borked" + reapply that
> 10 line patch. As the one who gets that TODO, I prefer the latter.
>
> So in sum: If your metric is "small count of reverted commits", you're
> right. If however your metric is: Better get 95% of this series' change
> in than maybe 0%, the split series is the way to do it.
I guess that's where we disagree: I don't see the point of having 95% of
it, either 0 or 100.
> With me having spend ~3h on this series' changes, it's maybe
> understandable that I did it the way I did.
I'm sorry, but that's never been an argument? I'm sure you and I both
have had series that took much longer dropped because it wasn't the
right approach.
> FTR: This series was created on top of v6.5-rc1. If you apply it to
> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
> be the responsible maintainer who applies this series, I like being able
> to just do git am --skip then.
Or we can ask that the driver is based on drm-misc-next ...
> FTR#2: In drm-misc-next is a new driver
> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
> now might indeed be a good idea.
... which is going to fix that one too.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 13:38 ` Uwe Kleine-König
2023-07-12 13:53 ` Maxime Ripard
@ 2023-07-12 13:53 ` Christian König
2023-07-13 0:06 ` Luben Tuikov
1 sibling, 1 reply; 33+ messages in thread
From: Christian König @ 2023-07-12 13:53 UTC (permalink / raw)
To: Uwe Kleine-König, Maxime Ripard
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Jani Nikula,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Konrad Dybcio, Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Jani Nikula, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Julia Lawall, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Khaled Almahallawy,
linux-stm32, Sam Ravnborg, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Gurchetan Singh, Liu Shixin,
Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, Lang Yu, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Leo Li, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
> Hello Maxime,
>
> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
>>>> Background is that this makes merge conflicts easier to handle and detect.
>>> Really?
>> FWIW, I agree with Christian here.
>>
>>> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
>>> unless I'm missing something you don't get less or easier conflicts by
>>> doing it all in a single patch. But you gain the freedom to drop a
>>> patch for one driver without having to drop the rest with it.
>> Not really, because the last patch removed the union anyway. So you have
>> to revert both the last patch, plus that driver one. And then you need
>> to add a TODO to remove that union eventually.
> Yes, with a single patch you have only one revert (but 194 files changed,
> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
> bigger). (And maybe you get away with just reverting the last patch.)
>
> With a single patch the TODO after a revert is "redo it all again (and
> prepare for a different set of conflicts)" while with the split series
> it's only "fix that one driver that was forgotten/borked" + reapply that
> 10 line patch.
Yeah, but for a maintainer the size of the patches doesn't matter.
That's only interesting if you need to manually review the patch, which
you hopefully doesn't do in case of something auto-generated.
In other words if the patch is auto-generated re-applying it completely
is less work than fixing things up individually.
> As the one who gets that TODO, I prefer the latter.
Yeah, but your personal preferences are not a technical relevant
argument to a maintainer.
At the end of the day Dave or Daniel need to decide, because they need
to live with it.
Regards,
Christian.
>
> So in sum: If your metric is "small count of reverted commits", you're
> right. If however your metric is: Better get 95% of this series' change
> in than maybe 0%, the split series is the way to do it.
>
> With me having spend ~3h on this series' changes, it's maybe
> understandable that I did it the way I did.
>
> FTR: This series was created on top of v6.5-rc1. If you apply it to
> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
> be the responsible maintainer who applies this series, I like being able
> to just do git am --skip then.
>
> FTR#2: In drm-misc-next is a new driver
> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
> now might indeed be a good idea.
>
>>> So I still like the split version better, but I'm open to a more
>>> verbose reasoning from your side.
>> You're doing only one thing here, really: you change the name of a
>> structure field. If it was shared between multiple maintainers, then
>> sure, splitting that up is easier for everyone, but this will go through
>> drm-misc, so I can't see the benefit it brings.
> I see your argument, but I think mine weights more.
>
> Best regards
> Uwe
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
` (3 preceding siblings ...)
2023-07-12 10:46 ` Christian König
@ 2023-07-12 14:34 ` Jani Nikula
2023-07-12 16:10 ` Uwe Kleine-König
2023-07-12 18:31 ` [Nouveau] [Freedreno] " Sean Paul
2023-07-13 7:54 ` [Nouveau] " Thomas Zimmermann
5 siblings, 2 replies; 33+ messages in thread
From: Jani Nikula @ 2023-07-12 14:34 UTC (permalink / raw)
To: Uwe Kleine-König, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Alex Deucher,
Christian König, Pan, Xinhui, Harry Wentland, Leo Li,
Rodrigo Siqueira, Hamza Mahfooz, Javier Martinez Canillas,
Guchun Chen, Srinivasan Shanmugam, Evan Quan, Likun Gao,
Marek Olšák, David Francis, Hawking Zhang,
Graham Sider, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, xurui, Laurent Pinchart,
Maíra Canal, André Almeida, Qingqing Zhuo,
Aurabindo Pillai, Hersen Wu, Fangzhi Zuo, Stylon Wang, Alan Liu,
Wayne Lin, Aaron Liu, Melissa Wen, Bhawanpreet Lakha,
David Tadokoro, Wenjing Liu, Jiapeng Chong, Mario Limonciello,
Alexey Kodanev, Roman Li, Joaquín Ignacio Aramendía,
Dave Airlie, Russell King, Liviu Dudau, Joel Stanley,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Stefan Agner, Alison Wang, Patrik Jakobsson,
Noralf Trønnes, Xinliang Liu, Tian Tao, Danilo Krummrich,
Deepak Rawat, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Ville Syrjälä,
Lucas De Marchi, Ankit Nautiyal, Andrzej Hajda, Matt Roper,
Stanislav Lisovskiy, Radhakrishna Sripada, Hans de Goede,
Luca Coelho, Niranjana Vishwanathapura, Kai Vehmanen,
Vinod Govindapillai, Łukasz Bartosik, Anusha Srivatsa,
Chaitanya Kumar Borah, Uma Shankar, Imre Deak, Mitul Golani,
Swati Sharma, Jouni Högander, Mika Kahola,
José Roberto de Souza, Arun R Murthy, Gustavo Sousa,
Khaled Almahallawy, Juha-Pekka Heikkila, Andi Shyti, Nirmoy Das,
Fei Yang, Animesh Manna, Deepak R Varma, Jiri Slaby (SUSE),
Dmitry Baryshkov, Vandita Kulkarni, Suraj Kandpal, Manasi Navare,
Drew Davenport, Laurentiu Palcu, Shawn Guo, Sascha Hauer,
Philipp Zabel, Marian Cichy, Dan Carpenter, Paul Cercueil,
Anitha Chrisanthus, Edmund Dea, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Neil Armstrong, Kevin Hilman,
Rob Clark, Abhinav Kumar, Vinod Polimera, Jiasheng Jiang,
Konrad Dybcio, Jessica Zhang, Liu Shixin, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Emma Anholt, Gerd Hoffmann, Kieran Bingham, Tomi Valkeinen,
Wolfram Sang, Geert Uytterhoeven, Biju Das, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Thierry Reding, Mikko Perttunen,
Jonathan Hunter, Jyri Sarha, David Lechner, Kamlesh Gurudasani,
Rodrigo Siqueira, Melissa Wen, Oleksandr Andrushchenko,
Michal Simek
Cc: Haneen Mohammed, linux-hyperv, linux-aspeed, nouveau, dri-devel,
virtualization, Yongqin Liu, Alim Akhtar, Marijn Suijten,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
amd-gfx, linux-stm32, linux-rockchip, Xinwei Kong,
VMware Graphics Reviewers, NXP Linux Team, spice-devel,
linux-sunxi, Martin Blumenstingl, linux-arm-msm, intel-gfx,
linux-mediatek, xen-devel, linux-tegra, linux-amlogic,
Gurchetan Singh, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-mips,
Chia-I Wu, linux-renesas-soc, kernel, John Stultz, freedreno,
Lucas Stach
On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit when these are all renamed to "drm_dev".
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!
>
> Some statistics:
>
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> 1 struct drm_device *adev_to_drm
> 1 struct drm_device *drm_
> 1 struct drm_device *drm_dev
> 1 struct drm_device *drm_dev
> 1 struct drm_device *pdev
> 1 struct drm_device *rdev
> 1 struct drm_device *vdev
> 2 struct drm_device *dcss_drv_dev_to_drm
> 2 struct drm_device **ddev
> 2 struct drm_device *drm_dev_alloc
> 2 struct drm_device *mock
> 2 struct drm_device *p_ddev
> 5 struct drm_device *device
> 9 struct drm_device * dev
> 25 struct drm_device *d
> 95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
> 4190 struct drm_device *dev
>
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.
I think this is an unnecessary change. In drm, a dev is usually a drm
device, i.e. struct drm_device *. As shown by the numbers above.
If folks insist on following through with this anyway, I'm firmly in the
camp the name should be "drm" and nothing else.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 14:34 ` Jani Nikula
@ 2023-07-12 16:10 ` Uwe Kleine-König
2023-07-13 6:52 ` Geert Uytterhoeven
` (2 more replies)
2023-07-12 18:31 ` [Nouveau] [Freedreno] " Sean Paul
1 sibling, 3 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-12 16:10 UTC (permalink / raw)
To: Jani Nikula
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, linux-sunxi, Tim Huang,
Suraj Kandpal, André Almeida, Andi Shyti, Yifan Zhang,
Leo Li, Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu,
Jessica Zhang, Kamlesh Gurudasani, Bhawanpreet Lakha,
Łukasz Bartosik, Radhakrishna Sripada, Andrew Jeffery,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Maxime Coquelin, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Chaitanya Kumar Borah,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Chunyan Zhang, Qingqing Zhuo, Sandy Huang,
Swati Sharma, John Stultz, Paul Kocialkowski, Kyungmin Park,
Drew Davenport, Kevin Hilman, Hawking Zhang, Haneen Mohammed,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Laurent Pinchart, Andrzej Hajda, Likun Gao, Sam Ravnborg,
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, Philipp Zabel, Ankit Nautiyal,
Harry Wentland, Sumit Semwal, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Mikko Perttunen, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, Vinod Govindapillai,
linux-tegra, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, Orson Zhai, amd-gfx,
Jyri Sarha, Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> > 1 struct drm_device *adev_to_drm
> > 1 struct drm_device *drm_
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device *pdev
> > 1 struct drm_device *rdev
> > 1 struct drm_device *vdev
> > 2 struct drm_device *dcss_drv_dev_to_drm
> > 2 struct drm_device **ddev
> > 2 struct drm_device *drm_dev_alloc
> > 2 struct drm_device *mock
> > 2 struct drm_device *p_ddev
> > 5 struct drm_device *device
> > 9 struct drm_device * dev
> > 25 struct drm_device *d
> > 95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> > 4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
>
> I think this is an unnecessary change. In drm, a dev is usually a drm
> device, i.e. struct drm_device *.
Well, unless it's not. Prominently there is
struct drm_device {
...
struct device *dev;
...
};
which yields quite a few code locations using dev->dev which is
IMHO unnecessary irritating:
$ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
1633
Also the functions that deal with both a struct device and a struct
drm_device often use "dev" for the struct device and then "ddev" for
the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
> If folks insist on following through with this anyway, I'm firmly in the
> camp the name should be "drm" and nothing else.
Up to now positive feedback is in the majority.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 14:34 ` Jani Nikula
2023-07-12 16:10 ` Uwe Kleine-König
@ 2023-07-12 18:31 ` Sean Paul
2023-07-12 19:22 ` Krzysztof Kozlowski
` (2 more replies)
1 sibling, 3 replies; 33+ messages in thread
From: Sean Paul @ 2023-07-12 18:31 UTC (permalink / raw)
To: Jani Nikula
Cc: Heiko Stübner, Geert Uytterhoeven, Marian Cichy,
Xinliang Liu, Linus Walleij, Tomi Valkeinen, Alexey Kodanev,
dri-devel, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
Uwe Kleine-König, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Leo Li, Sascha Hauer, Lucas De Marchi,
Inki Dae, Hersen Wu, Jessica Zhang, Kamlesh Gurudasani,
Bhawanpreet Lakha, Łukasz Bartosik, Radhakrishna Sripada,
Andrew Jeffery, Seung-Woo Kim, Manasi Navare,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Gerd Hoffmann, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, Edmund Dea,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Graham Sider, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Chaitanya Kumar Borah,
Philipp Zabel, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Chunyan Zhang, Qingqing Zhuo, Sandy Huang,
Swati Sharma, John Stultz, Paul Kocialkowski, Kyungmin Park,
Drew Davenport, Kevin Hilman, Hawking Zhang, Haneen Mohammed,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Laurent Pinchart, Andrzej Hajda, Likun Gao, Sam Ravnborg,
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, xurui, Ankit Nautiyal,
Harry Wentland, Sumit Semwal, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Mikko Perttunen, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Biju Das, Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao,
Shawn Guo, Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Uma Shankar, Mika Kahola,
Maxime Coquelin, Jiasheng Jiang, Srinivasan Shanmugam,
Vinod Govindapillai, linux-tegra, Marek Olšák,
Maarten Lankhorst, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, David Tadokoro,
AngeloGioacchino Del Regno, Orson Zhai, amd-gfx, Jyri Sarha,
Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula <jani.nikula@intel.com> wrote:
>
> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> > 1 struct drm_device *adev_to_drm
> > 1 struct drm_device *drm_
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device *pdev
> > 1 struct drm_device *rdev
> > 1 struct drm_device *vdev
> > 2 struct drm_device *dcss_drv_dev_to_drm
> > 2 struct drm_device **ddev
> > 2 struct drm_device *drm_dev_alloc
> > 2 struct drm_device *mock
> > 2 struct drm_device *p_ddev
> > 5 struct drm_device *device
> > 9 struct drm_device * dev
> > 25 struct drm_device *d
> > 95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> > 4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
>
> I think this is an unnecessary change. In drm, a dev is usually a drm
> device, i.e. struct drm_device *. As shown by the numbers above.
>
I'd really prefer this patch (series or single) is not accepted. This
will cause problems for everyone cherry-picking patches to a
downstream kernel (LTS or distro tree). I usually wouldn't expect
sympathy here, but the questionable benefit does not outweigh the cost
IM[biased]O.
Sean
> If folks insist on following through with this anyway, I'm firmly in the
> camp the name should be "drm" and nothing else.
>
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 18:31 ` [Nouveau] [Freedreno] " Sean Paul
@ 2023-07-12 19:22 ` Krzysztof Kozlowski
2023-07-13 7:48 ` Thomas Zimmermann
2023-07-13 13:03 ` Uwe Kleine-König
2 siblings, 0 replies; 33+ messages in thread
From: Krzysztof Kozlowski @ 2023-07-12 19:22 UTC (permalink / raw)
To: Sean Paul, Jani Nikula
Cc: Heiko Stübner, Geert Uytterhoeven, Marian Cichy,
Xinliang Liu, Linus Walleij, Tomi Valkeinen, Alexey Kodanev,
dri-devel, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
Uwe Kleine-König, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Leo Li, Sascha Hauer, Lucas De Marchi,
Inki Dae, Hersen Wu, Jessica Zhang, Kamlesh Gurudasani,
Bhawanpreet Lakha, Łukasz Bartosik, Radhakrishna Sripada,
Andrew Jeffery, Seung-Woo Kim, Manasi Navare,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Gerd Hoffmann, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, Edmund Dea,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Graham Sider, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Chaitanya Kumar Borah,
Philipp Zabel, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Chunyan Zhang, Qingqing Zhuo, Sandy Huang,
Swati Sharma, John Stultz, Paul Kocialkowski, Kyungmin Park,
Drew Davenport, Kevin Hilman, Hawking Zhang, Haneen Mohammed,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Laurent Pinchart, Andrzej Hajda, Likun Gao, Sam Ravnborg,
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, xurui, Ankit Nautiyal,
Harry Wentland, Sumit Semwal, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Mikko Perttunen, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Biju Das, Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao,
Shawn Guo, Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Hamza Mahfooz,
Marek Vasut, Jiapeng Chong, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Uma Shankar, Mika Kahola, Maxime Coquelin,
Jiasheng Jiang, Srinivasan Shanmugam, Vinod Govindapillai,
linux-tegra, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, Orson Zhai, amd-gfx,
Jyri Sarha, Yannick Fertre, Nicolas Ferre, Rob Clark,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
On 12/07/2023 20:31, Sean Paul wrote:
>>> 216 struct drm_device *ddev
>>> 234 struct drm_device *drm_dev
>>> 611 struct drm_device *drm
>>> 4190 struct drm_device *dev
>>>
>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>> it's not only me and others like the result of this effort it should be
>>> followed up by adapting the other structs and the individual usages in
>>> the different drivers.
>>
>> I think this is an unnecessary change. In drm, a dev is usually a drm
>> device, i.e. struct drm_device *. As shown by the numbers above.
>>
>
> I'd really prefer this patch (series or single) is not accepted. This
> will cause problems for everyone cherry-picking patches to a
> downstream kernel (LTS or distro tree). I usually wouldn't expect
> sympathy here, but the questionable benefit does not outweigh the cost
> IM[biased]O.
You know, every code cleanup and style adjustment is interfering with
backporting. The only argument for a fast-pacing kernel should be
whether the developers of this code find it more readable with such cleanup.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 13:53 ` Christian König
@ 2023-07-13 0:06 ` Luben Tuikov
0 siblings, 0 replies; 33+ messages in thread
From: Luben Tuikov @ 2023-07-13 0:06 UTC (permalink / raw)
To: Christian König, Uwe Kleine-König, Maxime Ripard
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Russell King, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jyri Sarha, Jerome Brunet,
Liu Shixin, linux-samsung-soc, Drew Davenport, Samuel Holland,
Matt Roper, Wenjing Liu, Javier Martinez Canillas,
Stanislav Lisovskiy, NXP Linux Team, spice-devel,
Niranjana Vishwanathapura, Philipp Zabel, linux-sunxi, Tim Huang,
Suraj Kandpal, André Almeida, Andi Shyti, Yifan Zhang,
Jani Nikula, Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu,
Jessica Zhang, Kamlesh Gurudasani, Bhawanpreet Lakha,
Łukasz Bartosik, Radhakrishna Sripada, Andrew Jeffery,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, amd-gfx, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Jiapeng Chong,
Thierry Reding, Yongqin Liu, Mario Limonciello, Fei Yang,
Ville Syrjälä,
Julia Lawall, Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Aaron Liu, Patrik Jakobsson, Vinod Polimera, linux-rockchip,
Fangzhi Zuo, Aurabindo Pillai, VMware Graphics Reviewers,
Ben Skeggs, Sam Ravnborg, Jouni Högander, Dave Airlie,
linux-mips, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Jani Nikula, Chaitanya Kumar Borah, Biju Das, linux-amlogic,
Evan Quan, Michal Simek, linux-arm-kernel, Sean Paul,
Neil Armstrong, Kai Vehmanen, Boris Brezillon, Qingqing Zhuo,
Sandy Huang, Swati Sharma, linux-renesas-soc, Kyungmin Park,
Maxime Coquelin, Kevin Hilman, Hawking Zhang, Sumit Semwal,
Haneen Mohammed, Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen,
linux-hyperv, Stefan Agner, Melissa Wen, Maíra Canal,
Luca Coelho, Laurent Pinchart, Andrzej Hajda, Likun Gao,
Jiri Slaby (SUSE),
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, Orson Zhai, Ankit Nautiyal,
Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Gurchetan Singh, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Konrad Dybcio, Kieran Bingham, Tian Tao, Roman Li, Shawn Guo,
Khaled Almahallawy, linux-stm32, Emma Anholt, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Mikko Perttunen,
Paul Cercueil, Rob Clark, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Krzysztof Kozlowski, Leo Li, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Vinod Govindapillai, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, linux-tegra,
Yannick Fertre, Nicolas Ferre, John Stultz, Philippe Cornu,
Daniel Vetter, Wayne Lin, Dmitry Baryshkov, Nirmoy Das, Lang Yu,
Lucas Stach
On 2023-07-12 09:53, Christian König wrote:
> Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
>> Hello Maxime,
>>
>> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
>>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
>>>>> Background is that this makes merge conflicts easier to handle and detect.
>>>> Really?
>>> FWIW, I agree with Christian here.
>>>
>>>> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
>>>> unless I'm missing something you don't get less or easier conflicts by
>>>> doing it all in a single patch. But you gain the freedom to drop a
>>>> patch for one driver without having to drop the rest with it.
>>> Not really, because the last patch removed the union anyway. So you have
>>> to revert both the last patch, plus that driver one. And then you need
>>> to add a TODO to remove that union eventually.
>> Yes, with a single patch you have only one revert (but 194 files changed,
>> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
>> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
>> bigger). (And maybe you get away with just reverting the last patch.)
>>
>> With a single patch the TODO after a revert is "redo it all again (and
>> prepare for a different set of conflicts)" while with the split series
>> it's only "fix that one driver that was forgotten/borked" + reapply that
>> 10 line patch.
>
> Yeah, but for a maintainer the size of the patches doesn't matter.
> That's only interesting if you need to manually review the patch, which
> you hopefully doesn't do in case of something auto-generated.
>
> In other words if the patch is auto-generated re-applying it completely
> is less work than fixing things up individually.
>
>> As the one who gets that TODO, I prefer the latter.
>
> Yeah, but your personal preferences are not a technical relevant
> argument to a maintainer.
>
> At the end of the day Dave or Daniel need to decide, because they need
> to live with it.
>
> Regards,
> Christian.
>
>>
>> So in sum: If your metric is "small count of reverted commits", you're
>> right. If however your metric is: Better get 95% of this series' change
>> in than maybe 0%, the split series is the way to do it.
>>
>> With me having spend ~3h on this series' changes, it's maybe
>> understandable that I did it the way I did.
>>
>> FTR: This series was created on top of v6.5-rc1. If you apply it to
>> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
>> be the responsible maintainer who applies this series, I like being able
>> to just do git am --skip then.
>>
>> FTR#2: In drm-misc-next is a new driver
>> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
>> now might indeed be a good idea.
>>
>>>> So I still like the split version better, but I'm open to a more
>>>> verbose reasoning from your side.
>>> You're doing only one thing here, really: you change the name of a
>>> structure field. If it was shared between multiple maintainers, then
>>> sure, splitting that up is easier for everyone, but this will go through
>>> drm-misc, so I can't see the benefit it brings.
>> I see your argument, but I think mine weights more.
I'm with Maxime and Christian on this--a single action necessitates a single patch.
One single movement. As Maxime said "either 0 or 100."
As to the name, perhaps "drm_dev" is more descriptive than just "drm".
What is "drm"? Ah it's a "dev", as in "drm dev"... Then why not rename it
to "drm_dev"? You are renaming it from "dev" to something more descriptive
after all. "dev" --> "drm" is no better, but "dev" --> "drm_dev" is just
right.
--
Regards,
Luben
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 16:10 ` Uwe Kleine-König
@ 2023-07-13 6:52 ` Geert Uytterhoeven
2023-07-13 10:03 ` Uwe Kleine-König
2023-07-13 7:47 ` Thomas Zimmermann
2023-07-13 9:03 ` Jani Nikula
2 siblings, 1 reply; 33+ messages in thread
From: Geert Uytterhoeven @ 2023-07-13 6:52 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, linux-sunxi, Tim Huang,
Suraj Kandpal, André Almeida, Andi Shyti, Yifan Zhang,
Leo Li, Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu,
Jessica Zhang, Kamlesh Gurudasani, Bhawanpreet Lakha,
Łukasz Bartosik, Radhakrishna Sripada, Andrew Jeffery,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Maxime Coquelin, Gurchetan Singh,
Martin Blumenstingl, linux-arm-msm, Animesh Manna,
linux-renesas-soc, Maxime Ripard, Chaitanya Kumar Borah,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Chunyan Zhang, Qingqing Zhuo, Sandy Huang,
Swati Sharma, John Stultz, Paul Kocialkowski, Kyungmin Park,
Drew Davenport, Kevin Hilman, Hawking Zhang, Haneen Mohammed,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Laurent Pinchart, Andrzej Hajda, Likun Gao, Sam Ravnborg,
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, Philipp Zabel, Ankit Nautiyal,
Harry Wentland, Sumit Semwal, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Mikko Perttunen, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Jani Nikula, Uma Shankar,
Mika Kahola, Jiasheng Jiang, Srinivasan Shanmugam,
Vinod Govindapillai, linux-tegra, Marek Olšák,
Maarten Lankhorst, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, David Tadokoro,
AngeloGioacchino Del Regno, Orson Zhai, amd-gfx, Jyri Sarha,
Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
Hi Uwe,
Let's add some fuel to keep the thread alive ;-)
On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device pointer variables being named "dev"
> > > because with that name I usually expect a struct device pointer.
> > >
> > > I think there is a big benefit when these are all renamed to "drm_dev".
> > > I have no strong preference here though, so "drmdev" or "drm" are fine
> > > for me, too. Let the bikesheding begin!
> > >
> > > Some statistics:
> > >
> > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> > > 1 struct drm_device *adev_to_drm
> > > 1 struct drm_device *drm_
> > > 1 struct drm_device *drm_dev
> > > 1 struct drm_device *drm_dev
> > > 1 struct drm_device *pdev
> > > 1 struct drm_device *rdev
> > > 1 struct drm_device *vdev
> > > 2 struct drm_device *dcss_drv_dev_to_drm
> > > 2 struct drm_device **ddev
> > > 2 struct drm_device *drm_dev_alloc
> > > 2 struct drm_device *mock
> > > 2 struct drm_device *p_ddev
> > > 5 struct drm_device *device
> > > 9 struct drm_device * dev
> > > 25 struct drm_device *d
> > > 95 struct drm_device *
> > > 216 struct drm_device *ddev
> > > 234 struct drm_device *drm_dev
> > > 611 struct drm_device *drm
> > > 4190 struct drm_device *dev
> > >
> > > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > > it's not only me and others like the result of this effort it should be
> > > followed up by adapting the other structs and the individual usages in
> > > the different drivers.
> >
> > I think this is an unnecessary change. In drm, a dev is usually a drm
> > device, i.e. struct drm_device *.
>
> Well, unless it's not. Prominently there is
>
> struct drm_device {
> ...
> struct device *dev;
> ...
> };
>
> which yields quite a few code locations using dev->dev which is
> IMHO unnecessary irritating:
>
> $ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
> 1633
I find that irritating as well...
Same for e.g. crtc->crtc.
Hence that's why I had sent patches to rename the base members in the
shmob_drm-specific subclasses of drm_{crtc,connector,plane} to "base".
https://lore.kernel.org/dri-devel/b3daca80f82625ba14e3aeaf2fca6dcefa056e47.1687423204.git.geert+renesas@glider.be
> Also the functions that deal with both a struct device and a struct
> drm_device often use "dev" for the struct device and then "ddev" for
> the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
I guess you considered "drm_dev", because it is still a short name?
Code dealing with platform devices usually uses "pdev" and "dev".
Same for PCI drivers (despite "pci_dev" being a short name).
So my personal preference goes to "ddev".
EOF (End-of-Fuel ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 16:10 ` Uwe Kleine-König
2023-07-13 6:52 ` Geert Uytterhoeven
@ 2023-07-13 7:47 ` Thomas Zimmermann
2023-07-13 9:03 ` Jani Nikula
2 siblings, 0 replies; 33+ messages in thread
From: Thomas Zimmermann @ 2023-07-13 7:47 UTC (permalink / raw)
To: Uwe Kleine-König, Jani Nikula
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, linux-sunxi, Tim Huang,
Suraj Kandpal, André Almeida, Andi Shyti, Yifan Zhang,
Leo Li, Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu,
Jessica Zhang, Kamlesh Gurudasani, Bhawanpreet Lakha,
Łukasz Bartosik, Radhakrishna Sripada, Andrew Jeffery,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Ville Syrjälä,
David Lechner, Juha-Pekka Heikkila, Jiri Slaby (SUSE),
David Francis, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Gurchetan Singh, Martin Blumenstingl,
linux-arm-msm, Animesh Manna, linux-renesas-soc, Maxime Ripard,
Chaitanya Kumar Borah, Biju Das, linux-amlogic, Evan Quan,
Michal Simek, linux-arm-kernel, Sean Paul, Neil Armstrong,
Kai Vehmanen, Boris Brezillon, Chunyan Zhang, Qingqing Zhuo,
Sandy Huang, Swati Sharma, John Stultz, Paul Kocialkowski,
Kyungmin Park, Drew Davenport, Kevin Hilman, Hawking Zhang,
Haneen Mohammed, Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen,
linux-hyperv, Stefan Agner, Melissa Wen, Maíra Canal,
Luca Coelho, Laurent Pinchart, Andrzej Hajda, Likun Gao,
Sam Ravnborg, Alain Volmat, Xinwei Kong, Jernej Skrabec,
Deepak Rawat, Chen-Yu Tsai, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Sumit Semwal, Alan Liu,
Philip Yang, intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Rodrigo Vivi, Mikko Perttunen,
Tvrtko Ursulin, Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma,
Pan, Xinhui, Chia-I Wu, Konrad Dybcio, Kieran Bingham, Tian Tao,
Shawn Guo, Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Roman Li, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Jiapeng Chong, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, Philipp Zabel,
Vinod Govindapillai, linux-tegra, Marek Olšák,
Maarten Lankhorst, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, David Tadokoro,
AngeloGioacchino Del Regno, Maxime Coquelin, amd-gfx, Jyri Sarha,
Yannick Fertre, Nicolas Ferre, Krzysztof Kozlowski,
Philippe Cornu, Daniel Vetter, Wayne Lin, Dmitry Baryshkov,
Nirmoy Das, Lang Yu, Lucas Stach
[-- Attachment #1.1: Type: text/plain, Size: 3061 bytes --]
Hi
Am 12.07.23 um 18:10 schrieb Uwe Kleine-König:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>>> Hello,
>>>
>>> while I debugged an issue in the imx-lcdc driver I was constantly
>>> irritated about struct drm_device pointer variables being named "dev"
>>> because with that name I usually expect a struct device pointer.
>>>
>>> I think there is a big benefit when these are all renamed to "drm_dev".
>>> I have no strong preference here though, so "drmdev" or "drm" are fine
>>> for me, too. Let the bikesheding begin!
>>>
>>> Some statistics:
>>>
>>> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
>>> 1 struct drm_device *adev_to_drm
>>> 1 struct drm_device *drm_
>>> 1 struct drm_device *drm_dev
>>> 1 struct drm_device *drm_dev
>>> 1 struct drm_device *pdev
>>> 1 struct drm_device *rdev
>>> 1 struct drm_device *vdev
>>> 2 struct drm_device *dcss_drv_dev_to_drm
>>> 2 struct drm_device **ddev
>>> 2 struct drm_device *drm_dev_alloc
>>> 2 struct drm_device *mock
>>> 2 struct drm_device *p_ddev
>>> 5 struct drm_device *device
>>> 9 struct drm_device * dev
>>> 25 struct drm_device *d
>>> 95 struct drm_device *
>>> 216 struct drm_device *ddev
>>> 234 struct drm_device *drm_dev
>>> 611 struct drm_device *drm
>>> 4190 struct drm_device *dev
>>>
>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>> it's not only me and others like the result of this effort it should be
>>> followed up by adapting the other structs and the individual usages in
>>> the different drivers.
>>
>> I think this is an unnecessary change. In drm, a dev is usually a drm
>> device, i.e. struct drm_device *.
>
> Well, unless it's not. Prominently there is
>
> struct drm_device {
> ...
> struct device *dev;
> ...
> };
Jani's point is that it's only inconvenient at the first time. Everyone
gets use to it.
Best regards
Thomas
>
> which yields quite a few code locations using dev->dev which is
> IMHO unnecessary irritating:
>
> $ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
> 1633
>
> Also the functions that deal with both a struct device and a struct
> drm_device often use "dev" for the struct device and then "ddev" for
> the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
>> If folks insist on following through with this anyway, I'm firmly in the
>> camp the name should be "drm" and nothing else.
>
> Up to now positive feedback is in the majority.
>
> Best regards
> Uwe
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 18:31 ` [Nouveau] [Freedreno] " Sean Paul
2023-07-12 19:22 ` Krzysztof Kozlowski
@ 2023-07-13 7:48 ` Thomas Zimmermann
2023-07-13 13:03 ` Uwe Kleine-König
2 siblings, 0 replies; 33+ messages in thread
From: Thomas Zimmermann @ 2023-07-13 7:48 UTC (permalink / raw)
To: Sean Paul, Jani Nikula
Cc: Geert Uytterhoeven, Marian Cichy, Xinliang Liu, Rodrigo Vivi,
Alexey Kodanev, dri-devel, Vandita Kulkarni, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Arun R Murthy, Jerome Brunet,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
Uwe Kleine-König, spice-devel, Niranjana Vishwanathapura,
Dmitry Baryshkov, linux-sunxi, Matthias Brugger, Tim Huang,
Suraj Kandpal, André Almeida, Mika Kahola, Tvrtko Ursulin,
Leo Li, Sascha Hauer, Lucas De Marchi, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Manasi Navare, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, Edmund Dea,
José Roberto de Souza, virtualization, Thierry Reding,
Yongqin Liu, Mario Limonciello, Fei Yang, Juha-Pekka Heikkila,
Chunyan Zhang, David Francis, Vinod Govindapillai, Aaron Liu,
Vinod Polimera, linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Graham Sider, Martin Blumenstingl, linux-arm-msm,
Animesh Manna, Nicolas Ferre, Maxime Ripard,
Chaitanya Kumar Borah, Tian Tao, Biju Das, linux-amlogic,
Evan Quan, Michal Simek, linux-arm-kernel, Sean Paul,
Neil Armstrong, Kai Vehmanen, Boris Brezillon, Shawn Guo,
Qingqing Zhuo, Sandy Huang, Swati Sharma, linux-renesas-soc,
Kyungmin Park, Maxime Coquelin, Kevin Hilman, Hawking Zhang,
Haneen Mohammed, Paul Cercueil, Anusha Srivatsa, Dan Carpenter,
linux-hyperv, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, xurui, Ankit Nautiyal,
Alan Liu, Philip Yang, intel-gfx, Alison Wang, Wolfram Sang,
Abhinav Kumar, Gustavo Sousa, Baolin Wang, Tomi Valkeinen,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Liviu Dudau, Alexandre Torgue, Gurchetan Singh, Liu Shixin,
Hamza Mahfooz, Marek Vasut, Paul Kocialkowski, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Uma Shankar, Andi Shyti,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Jiapeng Chong, Marek Olšák,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Laurentiu Palcu, linux-tegra, David Tadokoro,
AngeloGioacchino Del Regno, Orson Zhai, amd-gfx, Lang Yu,
Yannick Fertre, linux-mips, Krzysztof Kozlowski, Philippe Cornu,
Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha
[-- Attachment #1.1: Type: text/plain, Size: 2775 bytes --]
Hi
Am 12.07.23 um 20:31 schrieb Sean Paul:
> On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula <jani.nikula@intel.com> wrote:
>>
>> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>>> Hello,
>>>
>>> while I debugged an issue in the imx-lcdc driver I was constantly
>>> irritated about struct drm_device pointer variables being named "dev"
>>> because with that name I usually expect a struct device pointer.
>>>
>>> I think there is a big benefit when these are all renamed to "drm_dev".
>>> I have no strong preference here though, so "drmdev" or "drm" are fine
>>> for me, too. Let the bikesheding begin!
>>>
>>> Some statistics:
>>>
>>> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
>>> 1 struct drm_device *adev_to_drm
>>> 1 struct drm_device *drm_
>>> 1 struct drm_device *drm_dev
>>> 1 struct drm_device *drm_dev
>>> 1 struct drm_device *pdev
>>> 1 struct drm_device *rdev
>>> 1 struct drm_device *vdev
>>> 2 struct drm_device *dcss_drv_dev_to_drm
>>> 2 struct drm_device **ddev
>>> 2 struct drm_device *drm_dev_alloc
>>> 2 struct drm_device *mock
>>> 2 struct drm_device *p_ddev
>>> 5 struct drm_device *device
>>> 9 struct drm_device * dev
>>> 25 struct drm_device *d
>>> 95 struct drm_device *
>>> 216 struct drm_device *ddev
>>> 234 struct drm_device *drm_dev
>>> 611 struct drm_device *drm
>>> 4190 struct drm_device *dev
>>>
>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>> it's not only me and others like the result of this effort it should be
>>> followed up by adapting the other structs and the individual usages in
>>> the different drivers.
>>
>> I think this is an unnecessary change. In drm, a dev is usually a drm
>> device, i.e. struct drm_device *. As shown by the numbers above.
>>
>
> I'd really prefer this patch (series or single) is not accepted. This
> will cause problems for everyone cherry-picking patches to a
> downstream kernel (LTS or distro tree). I usually wouldn't expect
> sympathy here, but the questionable benefit does not outweigh the cost
> IM[biased]O.
I agree.
>
> Sean
>
>> If folks insist on following through with this anyway, I'm firmly in the
>> camp the name should be "drm" and nothing else.
>>
>>
>> BR,
>> Jani.
>>
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
` (4 preceding siblings ...)
2023-07-12 14:34 ` Jani Nikula
@ 2023-07-13 7:54 ` Thomas Zimmermann
5 siblings, 0 replies; 33+ messages in thread
From: Thomas Zimmermann @ 2023-07-13 7:54 UTC (permalink / raw)
To: Uwe Kleine-König, Maarten Lankhorst, Maxime Ripard,
David Airlie, Daniel Vetter, Alex Deucher, Christian König,
Pan, Xinhui, Harry Wentland, Leo Li, Rodrigo Siqueira,
Hamza Mahfooz, Javier Martinez Canillas, Guchun Chen,
Srinivasan Shanmugam, Evan Quan, Likun Gao,
Marek Olšák, David Francis, Hawking Zhang,
Graham Sider, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, Jani Nikula, xurui, Laurent Pinchart,
Maíra Canal, André Almeida, Qingqing Zhuo,
Aurabindo Pillai, Hersen Wu, Fangzhi Zuo, Stylon Wang, Alan Liu,
Wayne Lin, Aaron Liu, Melissa Wen, Bhawanpreet Lakha,
David Tadokoro, Wenjing Liu, Jiapeng Chong, Mario Limonciello,
Alexey Kodanev, Roman Li, Joaquín Ignacio Aramendía,
Dave Airlie, Russell King, Liviu Dudau, Joel Stanley,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Stefan Agner, Alison Wang, Patrik Jakobsson,
Noralf Trønnes, Xinliang Liu, Tian Tao, Danilo Krummrich,
Deepak Rawat, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Ville Syrjälä,
Lucas De Marchi, Ankit Nautiyal, Andrzej Hajda, Matt Roper,
Stanislav Lisovskiy, Radhakrishna Sripada, Hans de Goede,
Luca Coelho, Niranjana Vishwanathapura, Kai Vehmanen,
Vinod Govindapillai, Łukasz Bartosik, Anusha Srivatsa,
Chaitanya Kumar Borah, Uma Shankar, Imre Deak, Mitul Golani,
Swati Sharma, Jouni Högander, Mika Kahola,
José Roberto de Souza, Arun R Murthy, Gustavo Sousa,
Khaled Almahallawy, Juha-Pekka Heikkila, Andi Shyti, Nirmoy Das,
Fei Yang, Animesh Manna, Deepak R Varma, Jiri Slaby (SUSE),
Dmitry Baryshkov, Vandita Kulkarni, Suraj Kandpal, Manasi Navare,
Drew Davenport, Laurentiu Palcu, Shawn Guo, Sascha Hauer,
Philipp Zabel, Marian Cichy, Dan Carpenter, Paul Cercueil,
Anitha Chrisanthus, Edmund Dea, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Neil Armstrong, Kevin Hilman,
Rob Clark, Abhinav Kumar, Vinod Polimera, Jiasheng Jiang,
Konrad Dybcio, Jessica Zhang, Liu Shixin, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Emma Anholt, Gerd Hoffmann, Kieran Bingham, Tomi Valkeinen,
Wolfram Sang, Geert Uytterhoeven, Biju Das, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Thierry Reding, Mikko Perttunen,
Jonathan Hunter, Jyri Sarha, David Lechner, Kamlesh Gurudasani,
Rodrigo Siqueira, Melissa Wen, Oleksandr Andrushchenko,
Michal Simek
Cc: Haneen Mohammed, linux-hyperv, linux-aspeed, nouveau, dri-devel,
virtualization, Yongqin Liu, Alim Akhtar, Marijn Suijten,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
amd-gfx, linux-stm32, linux-rockchip, Xinwei Kong,
VMware Graphics Reviewers, NXP Linux Team, spice-devel,
linux-sunxi, Martin Blumenstingl, linux-arm-msm, intel-gfx,
linux-mediatek, xen-devel, linux-tegra, linux-amlogic,
Gurchetan Singh, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-mips,
Chia-I Wu, linux-renesas-soc, kernel, John Stultz, freedreno,
Lucas Stach
[-- Attachment #1.1: Type: text/plain, Size: 19075 bytes --]
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
Rather than renaming dev in all the DRM structs, did you consider
renaming struct drm_device.dev instead?
Everyone in DRM-land knows that 'dev' is the DRM device. But for struct
drm_device.dev a more expressive name would be helpful. Maybe 'parent'.
(It's also much less churn.)
Best regards
Thomas
>
> I think there is a big benefit when these are all renamed to "drm_dev".
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!
>
> Some statistics:
>
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> 1 struct drm_device *adev_to_drm
> 1 struct drm_device *drm_
> 1 struct drm_device *drm_dev
> 1 struct drm_device *drm_dev
> 1 struct drm_device *pdev
> 1 struct drm_device *rdev
> 1 struct drm_device *vdev
> 2 struct drm_device *dcss_drv_dev_to_drm
> 2 struct drm_device **ddev
> 2 struct drm_device *drm_dev_alloc
> 2 struct drm_device *mock
> 2 struct drm_device *p_ddev
> 5 struct drm_device *device
> 9 struct drm_device * dev
> 25 struct drm_device *d
> 95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
> 4190 struct drm_device *dev
>
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.
>
> To make this series a bit easier handleable, I first added an alias for
> drm_crtc::dev, then converted the drivers one after another and the last
> patch drops the "dev" name. This has the advantage of being easier to
> review, and if I should have missed an instance only the last patch must
> be dropped/reverted. Also this series might conflict with other patches,
> in this case the remaining patches can still go in (apart from the last
> one of course). Maybe it also makes sense to delay applying the last
> patch by one development cycle?
>
> The series was compile tested for arm, arm64, powerpc and amd64 using an
> allmodconfig (though I only build drivers/gpu/).
>
> Best regards
> Uwe
>
> Uwe Kleine-König (52):
> drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
> drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/armada: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/exynos: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gma500: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/meson: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/pl111: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/radeon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/renesas: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/solomon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/sun4i: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tegra: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tidss: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tilcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/tiny: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/tve200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/udl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vboxvideo: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vc4: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/virtio: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/vkms: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/vmwgfx: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
> drm/xen: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/xlnx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
> drm/crtc: Complete renaming struct drm_crtc::dev to drm_dev
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 18 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 22 +--
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 26 +--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 26 +--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 8 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 +-
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 +--
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-
> drivers/gpu/drm/arm/malidp_crtc.c | 7 +-
> drivers/gpu/drm/armada/armada_crtc.c | 10 +-
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 6 +-
> drivers/gpu/drm/ast/ast_dp.c | 2 +-
> drivers/gpu/drm/ast/ast_mode.c | 26 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 10 +-
> drivers/gpu/drm/drm_atomic.c | 22 +--
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
> drivers/gpu/drm/drm_atomic_uapi.c | 22 +--
> drivers/gpu/drm/drm_blend.c | 2 +-
> drivers/gpu/drm/drm_color_mgmt.c | 10 +-
> drivers/gpu/drm/drm_crtc.c | 19 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 10 +-
> drivers/gpu/drm/drm_debugfs.c | 2 +-
> drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
> drivers/gpu/drm/drm_fb_helper.c | 6 +-
> drivers/gpu/drm/drm_mipi_dbi.c | 4 +-
> drivers/gpu/drm/drm_plane.c | 2 +-
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
> drivers/gpu/drm/drm_vblank.c | 40 ++---
> drivers/gpu/drm/drm_vblank_work.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 16 +-
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
> drivers/gpu/drm/gma500/gma_display.c | 20 +--
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 +-
> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +-
> drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/psb_irq.c | 6 +-
> drivers/gpu/drm/gud/gud_pipe.c | 6 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 +--
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +-
> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 6 +-
> drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
> drivers/gpu/drm/i915/display/hsw_ips.c | 16 +-
> drivers/gpu/drm/i915/display/i9xx_plane.c | 4 +-
> drivers/gpu/drm/i915/display/i9xx_wm.c | 40 ++---
> drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +-
> drivers/gpu/drm/i915/display/intel_color.c | 124 +++++++-------
> drivers/gpu/drm/i915/display/intel_crtc.c | 20 +--
> .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 28 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 154 +++++++++---------
> .../gpu/drm/i915/display/intel_display_irq.c | 22 +--
> .../gpu/drm/i915/display/intel_display_rps.c | 2 +-
> .../drm/i915/display/intel_display_trace.h | 12 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dpll.c | 38 ++---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 ++---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_drrs.c | 10 +-
> drivers/gpu/drm/i915/display/intel_dsb.c | 8 +-
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fdi.c | 22 +--
> .../drm/i915/display/intel_fifo_underrun.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> .../drm/i915/display/intel_modeset_setup.c | 22 +--
> .../drm/i915/display/intel_modeset_verify.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.c | 4 +-
> .../gpu/drm/i915/display/intel_pch_display.c | 32 ++--
> .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 10 +-
> .../drm/i915/display/intel_plane_initial.c | 6 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 14 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vblank.c | 24 +--
> drivers/gpu/drm/i915/display/intel_vdsc.c | 18 +-
> drivers/gpu/drm/i915/display/intel_vrr.c | 18 +-
> drivers/gpu/drm/i915/display/skl_scaler.c | 10 +-
> .../drm/i915/display/skl_universal_plane.c | 6 +-
> drivers/gpu/drm/i915/display/skl_watermark.c | 42 ++---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
> drivers/gpu/drm/imx/dcss/dcss-crtc.c | 20 +--
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 15 +-
> drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 16 +-
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +-
> drivers/gpu/drm/kmb/kmb_crtc.c | 16 +-
> drivers/gpu/drm/logicvc/logicvc_crtc.c | 14 +-
> drivers/gpu/drm/mcde/mcde_display.c | 18 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 22 +--
> drivers/gpu/drm/meson/meson_crtc.c | 12 +-
> drivers/gpu/drm/mgag200/mgag200_g200.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200eh.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_g200er.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200ev.c | 4 +-
> drivers/gpu/drm/mgag200/mgag200_g200se.c | 6 +-
> drivers/gpu/drm/mgag200/mgag200_g200wb.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 70 ++++----
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 12 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 20 +--
> drivers/gpu/drm/msm/msm_drv.c | 4 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 18 +-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 16 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 58 +++----
> drivers/gpu/drm/nouveau/dispnv04/cursor.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/atom.h | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/crc.c | 30 ++--
> drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/crcc57d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +-
> drivers/gpu/drm/nouveau/dispnv50/head.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv50/head507d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head827d.c | 10 +-
> drivers/gpu/drm/nouveau/dispnv50/head907d.c | 26 +--
> drivers/gpu/drm/nouveau/dispnv50/head917d.c | 6 +-
> drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 18 +-
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 10 +-
> drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 56 +++----
> drivers/gpu/drm/omapdrm/omap_irq.c | 6 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 +-
> drivers/gpu/drm/pl111/pl111_display.c | 16 +-
> drivers/gpu/drm/qxl/qxl_display.c | 2 +-
> drivers/gpu/drm/radeon/atombios_crtc.c | 54 +++---
> drivers/gpu/drm/radeon/radeon_cursor.c | 14 +-
> drivers/gpu/drm/radeon/radeon_display.c | 28 ++--
> drivers/gpu/drm/radeon/radeon_kms.c | 6 +-
> drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +-
> .../gpu/drm/renesas/rcar-du/rcar_du_crtc.c | 14 +-
> .../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 20 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 15 +-
> drivers/gpu/drm/solomon/ssd130x.c | 2 +-
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 +-
> drivers/gpu/drm/sti/sti_crtc.c | 14 +-
> drivers/gpu/drm/stm/ltdc.c | 12 +-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +-
> drivers/gpu/drm/tegra/dc.c | 12 +-
> drivers/gpu/drm/tidss/tidss_crtc.c | 19 ++-
> drivers/gpu/drm/tidss/tidss_irq.c | 4 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 43 ++---
> drivers/gpu/drm/tiny/bochs.c | 6 +-
> drivers/gpu/drm/tiny/cirrus.c | 2 +-
> drivers/gpu/drm/tiny/gm12u320.c | 4 +-
> drivers/gpu/drm/tiny/hx8357d.c | 4 +-
> drivers/gpu/drm/tiny/ili9163.c | 4 +-
> drivers/gpu/drm/tiny/ili9225.c | 8 +-
> drivers/gpu/drm/tiny/ili9341.c | 4 +-
> drivers/gpu/drm/tiny/ili9486.c | 4 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
> drivers/gpu/drm/tiny/ofdrm.c | 8 +-
> drivers/gpu/drm/tiny/panel-mipi-dbi.c | 6 +-
> drivers/gpu/drm/tiny/repaper.c | 8 +-
> drivers/gpu/drm/tiny/simpledrm.c | 2 +-
> drivers/gpu/drm/tiny/st7586.c | 6 +-
> drivers/gpu/drm/tiny/st7735r.c | 4 +-
> drivers/gpu/drm/tve200/tve200_display.c | 14 +-
> drivers/gpu/drm/udl/udl_modeset.c | 4 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 6 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 38 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 12 +-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
> drivers/gpu/drm/vkms/vkms_crtc.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 10 +-
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 8 +-
> include/drm/drm_atomic_helper.h | 2 +-
> include/drm/drm_crtc.h | 4 +-
> 194 files changed, 1296 insertions(+), 1264 deletions(-)
>
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 16:10 ` Uwe Kleine-König
2023-07-13 6:52 ` Geert Uytterhoeven
2023-07-13 7:47 ` Thomas Zimmermann
@ 2023-07-13 9:03 ` Jani Nikula
2023-07-13 9:29 ` Geert Uytterhoeven
2023-07-13 9:54 ` Uwe Kleine-König
2 siblings, 2 replies; 33+ messages in thread
From: Jani Nikula @ 2023-07-13 9:03 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Geert Uytterhoeven, Xinliang Liu, Rodrigo Vivi, Alexey Kodanev,
dri-devel, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Leo Li,
Sascha Hauer, Lucas De Marchi, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Vinod Polimera, linux-rockchip,
Fangzhi Zuo, Aurabindo Pillai, VMware Graphics Reviewers,
Ben Skeggs, Jouni Högander, Jessica Zhang,
Martin Blumenstingl, linux-arm-msm, Animesh Manna, Nicolas Ferre,
Maxime Ripard, Chaitanya Kumar Borah, Tian Tao, Biju Das,
linux-amlogic, Evan Quan, Michal Simek, linux-arm-kernel,
Sean Paul, Neil Armstrong, Kai Vehmanen, Boris Brezillon,
Shawn Guo, Qingqing Zhuo, Sandy Huang, Swati Sharma,
linux-renesas-soc, Kyungmin Park, Maxime Coquelin, Kevin Hilman,
Hawking Zhang, Haneen Mohammed, Paul Cercueil, Anusha Srivatsa,
Dan Carpenter, linux-hyperv, Melissa Wen, Maíra Canal,
Luca Coelho, Gerd Hoffmann, Andrzej Hajda, Likun Gao,
Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Alan Liu, Philip Yang, intel-gfx, Alison Wang,
Wolfram Sang, Abhinav Kumar, Gustavo Sousa, Baolin Wang,
Tomi Valkeinen, Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira,
Tomi Valkeinen, Deepak R Varma, Pan, Xinhui, Konrad Dybcio,
Kieran Bingham, John Stultz, Roman Li, Sumit Semwal,
Christian König, Khaled Almahallawy, linux-stm32,
Sam Ravnborg, Chun-Kuang Hu, Liviu Dudau, Alexandre Torgue,
Gurchetan Singh, Liu Shixin, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Laurentiu Palcu,
linux-tegra, David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Lang Yu, Yannick Fertre, linux-mips, Krzysztof Kozlowski,
Philippe Cornu, Wayne Lin, Drew Davenport, Nirmoy Das,
Jyri Sarha
On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>> > Hello,
>> >
>> > while I debugged an issue in the imx-lcdc driver I was constantly
>> > irritated about struct drm_device pointer variables being named "dev"
>> > because with that name I usually expect a struct device pointer.
>> >
>> > I think there is a big benefit when these are all renamed to "drm_dev".
>> > I have no strong preference here though, so "drmdev" or "drm" are fine
>> > for me, too. Let the bikesheding begin!
>> >
>> > Some statistics:
>> >
>> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
>> > 1 struct drm_device *adev_to_drm
>> > 1 struct drm_device *drm_
>> > 1 struct drm_device *drm_dev
>> > 1 struct drm_device *drm_dev
>> > 1 struct drm_device *pdev
>> > 1 struct drm_device *rdev
>> > 1 struct drm_device *vdev
>> > 2 struct drm_device *dcss_drv_dev_to_drm
>> > 2 struct drm_device **ddev
>> > 2 struct drm_device *drm_dev_alloc
>> > 2 struct drm_device *mock
>> > 2 struct drm_device *p_ddev
>> > 5 struct drm_device *device
>> > 9 struct drm_device * dev
>> > 25 struct drm_device *d
>> > 95 struct drm_device *
>> > 216 struct drm_device *ddev
>> > 234 struct drm_device *drm_dev
>> > 611 struct drm_device *drm
>> > 4190 struct drm_device *dev
>> >
>> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
>> > it's not only me and others like the result of this effort it should be
>> > followed up by adapting the other structs and the individual usages in
>> > the different drivers.
>>
>> I think this is an unnecessary change. In drm, a dev is usually a drm
>> device, i.e. struct drm_device *.
>
> Well, unless it's not. Prominently there is
>
> struct drm_device {
> ...
> struct device *dev;
> ...
> };
>
> which yields quite a few code locations using dev->dev which is
> IMHO unnecessary irritating:
>
> $ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
> 1633
>
> Also the functions that deal with both a struct device and a struct
> drm_device often use "dev" for the struct device and then "ddev" for
> the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
Why is specifically struct drm_device *dev so irritating to you?
You lead us to believe it's an outlier in kernel, something that goes
against common kernel style, but it's really not:
$ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn | head -20
38494 struct device *dev
16388 struct net_device *dev
4184 struct drm_device *dev
2780 struct pci_dev *dev
1916 struct comedi_device *dev
1510 struct mlx5_core_dev *dev
1057 struct mlx4_dev *dev
894 struct b43_wldev *dev
762 struct input_dev *dev
623 struct usbnet *dev
561 struct mlx5_ib_dev *dev
525 struct mt76_dev *dev
465 struct mt76x02_dev *dev
435 struct platform_device *dev
431 struct usb_device *dev
411 struct mt7915_dev *dev
398 struct cx231xx *dev
378 struct mei_device *dev
363 struct ksz_device *dev
359 struct mthca_dev *dev
A good portion of the above also have a dev member.
Are you planning on changing all of the above too, or are you only
annoyed by drm?
I'm really not convinced at all.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 9:03 ` Jani Nikula
@ 2023-07-13 9:29 ` Geert Uytterhoeven
2023-07-13 9:54 ` Uwe Kleine-König
1 sibling, 0 replies; 33+ messages in thread
From: Geert Uytterhoeven @ 2023-07-13 9:29 UTC (permalink / raw)
To: Jani Nikula
Cc: Xinliang Liu, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
Uwe Kleine-König, spice-devel, Niranjana Vishwanathapura,
Dmitry Baryshkov, linux-sunxi, Matthias Brugger, Tim Huang,
Suraj Kandpal, André Almeida, Mika Kahola, Tvrtko Ursulin,
Leo Li, Sascha Hauer, Lucas De Marchi, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Vinod Polimera, linux-rockchip,
Fangzhi Zuo, Aurabindo Pillai, VMware Graphics Reviewers,
Ben Skeggs, Jouni Högander, Jessica Zhang,
Martin Blumenstingl, linux-arm-msm, Animesh Manna, Nicolas Ferre,
Maxime Ripard, Chaitanya Kumar Borah, Tian Tao, Biju Das,
linux-amlogic, Evan Quan, Michal Simek, linux-arm-kernel,
Sean Paul, Neil Armstrong, Kai Vehmanen, Boris Brezillon,
Shawn Guo, Qingqing Zhuo, Sandy Huang, Swati Sharma,
linux-renesas-soc, Kyungmin Park, Maxime Coquelin, Kevin Hilman,
Hawking Zhang, Haneen Mohammed, Paul Cercueil, Anusha Srivatsa,
Dan Carpenter, linux-hyperv, Melissa Wen, Maíra Canal,
Luca Coelho, Gerd Hoffmann, Andrzej Hajda, Likun Gao,
Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Alan Liu, Philip Yang, intel-gfx, Alison Wang,
Wolfram Sang, Abhinav Kumar, Gustavo Sousa, Baolin Wang,
Tomi Valkeinen, Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira,
Tomi Valkeinen, Deepak R Varma, Pan, Xinhui, Konrad Dybcio,
Kieran Bingham, John Stultz, Roman Li, Sumit Semwal,
Christian König, Khaled Almahallawy, linux-stm32,
Sam Ravnborg, Chun-Kuang Hu, Liviu Dudau, Alexandre Torgue,
Gurchetan Singh, Liu Shixin, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Joaquín Ignacio Aramendía,
Melissa Wen, Hans de Goede, linux-mediatek, Laurentiu Palcu,
linux-tegra, David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Lang Yu, Yannick Fertre, linux-mips, Krzysztof Kozlowski,
Philippe Cornu, Wayne Lin, Drew Davenport, Nirmoy Das,
Jyri Sarha
Hi Jani,
On Thu, Jul 13, 2023 at 11:03 AM Jani Nikula <jani.nikula@intel.com> wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> >> > while I debugged an issue in the imx-lcdc driver I was constantly
> >> > irritated about struct drm_device pointer variables being named "dev"
> >> > because with that name I usually expect a struct device pointer.
> >> >
> >> > I think there is a big benefit when these are all renamed to "drm_dev".
> >> > I have no strong preference here though, so "drmdev" or "drm" are fine
> >> > for me, too. Let the bikesheding begin!
> >> >
> >> > Some statistics:
> >> >
> >> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> >> > 1 struct drm_device *adev_to_drm
> >> > 1 struct drm_device *drm_
> >> > 1 struct drm_device *drm_dev
> >> > 1 struct drm_device *drm_dev
> >> > 1 struct drm_device *pdev
> >> > 1 struct drm_device *rdev
> >> > 1 struct drm_device *vdev
> >> > 2 struct drm_device *dcss_drv_dev_to_drm
> >> > 2 struct drm_device **ddev
> >> > 2 struct drm_device *drm_dev_alloc
> >> > 2 struct drm_device *mock
> >> > 2 struct drm_device *p_ddev
> >> > 5 struct drm_device *device
> >> > 9 struct drm_device * dev
> >> > 25 struct drm_device *d
> >> > 95 struct drm_device *
> >> > 216 struct drm_device *ddev
> >> > 234 struct drm_device *drm_dev
> >> > 611 struct drm_device *drm
> >> > 4190 struct drm_device *dev
> >> >
> >> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> >> > it's not only me and others like the result of this effort it should be
> >> > followed up by adapting the other structs and the individual usages in
> >> > the different drivers.
> >>
> >> I think this is an unnecessary change. In drm, a dev is usually a drm
> >> device, i.e. struct drm_device *.
> >
> > Well, unless it's not. Prominently there is
> >
> > struct drm_device {
> > ...
> > struct device *dev;
> > ...
> > };
> >
> > which yields quite a few code locations using dev->dev which is
> > IMHO unnecessary irritating:
> >
> > $ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
> > 1633
> >
> > Also the functions that deal with both a struct device and a struct
> > drm_device often use "dev" for the struct device and then "ddev" for
> > the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
> Why is specifically struct drm_device *dev so irritating to you?
>
> You lead us to believe it's an outlier in kernel, something that goes
> against common kernel style, but it's really not:
>
> $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn | head -20
> 38494 struct device *dev
> 16388 struct net_device *dev
> 4184 struct drm_device *dev
> 2780 struct pci_dev *dev
> 1916 struct comedi_device *dev
> 1510 struct mlx5_core_dev *dev
> 1057 struct mlx4_dev *dev
> 894 struct b43_wldev *dev
> 762 struct input_dev *dev
> 623 struct usbnet *dev
> 561 struct mlx5_ib_dev *dev
> 525 struct mt76_dev *dev
> 465 struct mt76x02_dev *dev
> 435 struct platform_device *dev
> 431 struct usb_device *dev
> 411 struct mt7915_dev *dev
> 398 struct cx231xx *dev
> 378 struct mei_device *dev
> 363 struct ksz_device *dev
> 359 struct mthca_dev *dev
>
> A good portion of the above also have a dev member.
Not all of them access both the foo_device and the device pointers.
Let's put the number of 435 platform_device pointers named "dev"
into perspective:
10095 struct platform_device *pdev
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 9:03 ` Jani Nikula
2023-07-13 9:29 ` Geert Uytterhoeven
@ 2023-07-13 9:54 ` Uwe Kleine-König
1 sibling, 0 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-13 9:54 UTC (permalink / raw)
To: Jani Nikula
Cc: Geert Uytterhoeven, Xinliang Liu, Tomi Valkeinen, Alexey Kodanev,
dri-devel, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Drew Davenport, Samuel Holland, Matt Roper,
Wenjing Liu, Javier Martinez Canillas, Stanislav Lisovskiy,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Tim Huang, Suraj Kandpal, André Almeida,
Andi Shyti, Yifan Zhang, Leo Li, Sascha Hauer, Lucas De Marchi,
Sam Ravnborg, Hersen Wu, Jessica Zhang, Kamlesh Gurudasani,
Bhawanpreet Lakha, Łukasz Bartosik, Radhakrishna Sripada,
Andrew Jeffery, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Gerd Hoffmann,
Alexandre Belloni, amd-gfx, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Jiapeng Chong,
Thierry Reding, Yongqin Liu, Mario Limonciello, Fei Yang,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis, Aaron Liu,
Vinod Polimera, linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Dave Airlie, linux-mips, Martin Blumenstingl, linux-arm-msm,
Animesh Manna, Maxime Ripard, Chaitanya Kumar Borah, Biju Das,
linux-amlogic, Evan Quan, Michal Simek, linux-arm-kernel,
Sean Paul, Neil Armstrong, Kai Vehmanen, Boris Brezillon,
Qingqing Zhuo, Sandy Huang, Swati Sharma, linux-renesas-soc,
Kyungmin Park, Maxime Coquelin, Kevin Hilman, Hawking Zhang,
Haneen Mohammed, Anusha Srivatsa, Dan Carpenter, linux-hyperv,
Melissa Wen, Maíra Canal, Luca Coelho, Laurent Pinchart,
Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, Orson Zhai, Ankit Nautiyal,
Sumit Semwal, Alan Liu, Philip Yang, intel-gfx, Alison Wang,
Wolfram Sang, Abhinav Kumar, Gustavo Sousa, Baolin Wang,
Rodrigo Vivi, Gurchetan Singh, Tvrtko Ursulin, Rodrigo Siqueira,
Tomi Valkeinen, Deepak R Varma, Pan, Xinhui, Konrad Dybcio,
Kieran Bingham, Tian Tao, Roman Li, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Liviu Dudau, Alexandre Torgue,
Mikko Perttunen, Paul Cercueil, Krzysztof Kozlowski,
Hamza Mahfooz, Marek Vasut, Paul Kocialkowski, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Russell King, Uma Shankar, Mika Kahola,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Vinod Govindapillai, Marek Olšák,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, linux-tegra,
Jyri Sarha, Yannick Fertre, Nicolas Ferre, John Stultz,
Philippe Cornu, Wayne Lin, Dmitry Baryshkov, Nirmoy Das, Lang Yu
[-- Attachment #1: Type: text/plain, Size: 5190 bytes --]
On Thu, Jul 13, 2023 at 12:03:05PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> > Hello Jani,
> >
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> >> > Hello,
> >> >
> >> > while I debugged an issue in the imx-lcdc driver I was constantly
> >> > irritated about struct drm_device pointer variables being named "dev"
> >> > because with that name I usually expect a struct device pointer.
> >> >
> >> > I think there is a big benefit when these are all renamed to "drm_dev".
> >> > I have no strong preference here though, so "drmdev" or "drm" are fine
> >> > for me, too. Let the bikesheding begin!
> >> >
> >> > Some statistics:
> >> >
> >> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n
> >> > 1 struct drm_device *adev_to_drm
> >> > 1 struct drm_device *drm_
> >> > 1 struct drm_device *drm_dev
> >> > 1 struct drm_device *drm_dev
> >> > 1 struct drm_device *pdev
> >> > 1 struct drm_device *rdev
> >> > 1 struct drm_device *vdev
> >> > 2 struct drm_device *dcss_drv_dev_to_drm
> >> > 2 struct drm_device **ddev
> >> > 2 struct drm_device *drm_dev_alloc
> >> > 2 struct drm_device *mock
> >> > 2 struct drm_device *p_ddev
> >> > 5 struct drm_device *device
> >> > 9 struct drm_device * dev
> >> > 25 struct drm_device *d
> >> > 95 struct drm_device *
> >> > 216 struct drm_device *ddev
> >> > 234 struct drm_device *drm_dev
> >> > 611 struct drm_device *drm
> >> > 4190 struct drm_device *dev
> >> >
> >> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> >> > it's not only me and others like the result of this effort it should be
> >> > followed up by adapting the other structs and the individual usages in
> >> > the different drivers.
> >>
> >> I think this is an unnecessary change. In drm, a dev is usually a drm
> >> device, i.e. struct drm_device *.
> >
> > Well, unless it's not. Prominently there is
> >
> > struct drm_device {
> > ...
> > struct device *dev;
> > ...
> > };
> >
> > which yields quite a few code locations using dev->dev which is
> > IMHO unnecessary irritating:
> >
> > $ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
> > 1633
> >
> > Also the functions that deal with both a struct device and a struct
> > drm_device often use "dev" for the struct device and then "ddev" for
> > the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
> Why is specifically struct drm_device *dev so irritating to you?
>
> You lead us to believe it's an outlier in kernel, something that goes
> against common kernel style, but it's really not:
>
> $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn | head -20
> 38494 struct device *dev
> 16388 struct net_device *dev
> 4184 struct drm_device *dev
> 2780 struct pci_dev *dev
> 1916 struct comedi_device *dev
> 1510 struct mlx5_core_dev *dev
> 1057 struct mlx4_dev *dev
> 894 struct b43_wldev *dev
> 762 struct input_dev *dev
> 623 struct usbnet *dev
> 561 struct mlx5_ib_dev *dev
> 525 struct mt76_dev *dev
> 465 struct mt76x02_dev *dev
> 435 struct platform_device *dev
> 431 struct usb_device *dev
> 411 struct mt7915_dev *dev
> 398 struct cx231xx *dev
> 378 struct mei_device *dev
> 363 struct ksz_device *dev
> 359 struct mthca_dev *dev
>
> A good portion of the above also have a dev member.
Yeah, other subsystems and drivers have the same problem. You're lucky
that I noticed drm first and invested some effort to improve it. IMHO
other subsystems being bad shouldn't stop drm to improve here.
And note that for example for pci_dev there are 5794 instances that are
named "pdev" and there are 9971 struct platform_device that are called
"pdev", too. So the majority for these does it better. And agreed,
net_device and others are also inconsistent. If you want an area that is
better, look at the naming of i2c_client or spi_device. (And take into
account that these are spread all over the tree and so are not in
control of a single maintainer team.)
> Are you planning on changing all of the above too, or are you only
> annoyed by drm?
Would you be more welcoming if I promised to tackle some of the above,
too? If so: I might. I hesitate a bit because I didn't suffer from the
others. (Apart from asking ctags for "dev" is a nightmare.)
And regarding the second part of your question: I was annoyed by drm
because that was the one that offended me while researching a problem in
a drm driver. And the variable/struct member name irritated me enough to
believe that with consistent naming I would have found it quicker.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 6:52 ` Geert Uytterhoeven
@ 2023-07-13 10:03 ` Uwe Kleine-König
0 siblings, 0 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-13 10:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Leo Li,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Maxime Ripard, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, Lang Yu, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Jani Nikula, Uma Shankar, Andi Shyti,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Jiapeng Chong, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]
On Thu, Jul 13, 2023 at 08:52:12AM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> Let's add some fuel to keep the thread alive ;-)
>
> On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > > I think this is an unnecessary change. In drm, a dev is usually a drm
> > > device, i.e. struct drm_device *.
> >
> > Well, unless it's not. Prominently there is
> >
> > struct drm_device {
> > ...
> > struct device *dev;
> > ...
> > };
> >
> > which yields quite a few code locations using dev->dev which is
> > IMHO unnecessary irritating:
> >
> > $ git grep '\<dev->dev' v6.5-rc1 drivers/gpu/drm | wc -l
> > 1633
>
> I find that irritating as well...
>
> Same for e.g. crtc->crtc.
>
> Hence that's why I had sent patches to rename the base members in the
> shmob_drm-specific subclasses of drm_{crtc,connector,plane} to "base".
> https://lore.kernel.org/dri-devel/b3daca80f82625ba14e3aeaf2fca6dcefa056e47.1687423204.git.geert+renesas@glider.be
>
> > Also the functions that deal with both a struct device and a struct
> > drm_device often use "dev" for the struct device and then "ddev" for
> > the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
> I guess you considered "drm_dev", because it is still a short name?
I considered drm_dev because it is still moderately short and a good
approximation of "drm_device". Other than that the main driving force to
pick "drm_dev" was that it's unique enough that I could have done
s/\<drm_dev\>/$nameofchoice/ on the initial patch and get it mostly
right.
> Code dealing with platform devices usually uses "pdev" and "dev".
> Same for PCI drivers (despite "pci_dev" being a short name).
pci_dev and platform_device both typlically using pdev already annoyed
me in the past. However less than drm_device *dev because for pci_dev +
platform_device there is little overlap.
> So my personal preference goes to "ddev".
I sticked to "drm" for the new series. I think this provides less fuel.
Best regards and thanks for your thoughts,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-12 18:31 ` [Nouveau] [Freedreno] " Sean Paul
2023-07-12 19:22 ` Krzysztof Kozlowski
2023-07-13 7:48 ` Thomas Zimmermann
@ 2023-07-13 13:03 ` Uwe Kleine-König
2023-07-13 14:41 ` Sean Paul
2 siblings, 1 reply; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-13 13:03 UTC (permalink / raw)
To: Sean Paul
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Leo Li,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Maxime Ripard, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, Lang Yu, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Jani Nikula, Uma Shankar, Andi Shyti,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Jiapeng Chong, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> I'd really prefer this patch (series or single) is not accepted. This
> will cause problems for everyone cherry-picking patches to a
> downstream kernel (LTS or distro tree). I usually wouldn't expect
> sympathy here, but the questionable benefit does not outweigh the cost
> IM[biased]O.
I agree that for backports this isn't so nice. However with the split
approach (that was argumented against here) it's not soo bad. Patch #1
(and similar changes for the other affected structures) could be
trivially backported and with that it doesn't matter if you write dev or
drm (or whatever name is chosen in the end); both work in the same way.
But even with the one-patch-per-rename approach I'd consider the
renaming a net win, because ease of understanding code has a big value.
It's value is not so easy measurable as "conflicts when backporting",
but it also matters in say two years from now, while backporting
shouldn't be an issue then any more.
Thanks for your input, best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 13:03 ` Uwe Kleine-König
@ 2023-07-13 14:41 ` Sean Paul
2023-07-13 15:09 ` Thomas Zimmermann
2023-07-13 15:39 ` Uwe Kleine-König
0 siblings, 2 replies; 33+ messages in thread
From: Sean Paul @ 2023-07-13 14:41 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Leo Li,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Maxime Ripard, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, Lang Yu, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Jani Nikula, Uma Shankar, Andi Shyti,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Jiapeng Chong, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> hello Sean,
>
> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> > I'd really prefer this patch (series or single) is not accepted. This
> > will cause problems for everyone cherry-picking patches to a
> > downstream kernel (LTS or distro tree). I usually wouldn't expect
> > sympathy here, but the questionable benefit does not outweigh the cost
> > IM[biased]O.
>
> I agree that for backports this isn't so nice. However with the split
> approach (that was argumented against here) it's not soo bad. Patch #1
> (and similar changes for the other affected structures) could be
> trivially backported and with that it doesn't matter if you write dev or
> drm (or whatever name is chosen in the end); both work in the same way.
Patch #1 avoids the need to backport the entire set, however every
change occuring after the rename patches will cause conflicts on
future cherry-picks. Downstream kernels will have to backport the
whole set. Backporting the entire set will create an epoch in
downstream kernels where cherry-picking patches preceding this set
will need to undergo conflict resolution as well. As mentioned in my
previous email, I don't expect sympathy here, it's part of maintaining
a downstream kernel, but there is a real cost to kernel consumers.
>
> But even with the one-patch-per-rename approach I'd consider the
> renaming a net win, because ease of understanding code has a big value.
> It's value is not so easy measurable as "conflicts when backporting",
> but it also matters in say two years from now, while backporting
> shouldn't be an issue then any more.
You've rightly identified the conjecture in your statement. I've been
on both sides of the argument, having written/maintained drm code
upstream and cherry-picked changes to a downstream kernel. Perhaps
it's because drm's definition of dev is ingrained in my muscle memory,
or maybe it's because I don't do a lot of upstream development these
days, but I just have a hard time seeing the benefit here.
I appreciate your engagement on the topic, thank you!
Sean
>
> Thanks for your input, best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 14:41 ` Sean Paul
@ 2023-07-13 15:09 ` Thomas Zimmermann
2023-07-13 15:14 ` Tvrtko Ursulin
2023-07-13 15:39 ` Uwe Kleine-König
1 sibling, 1 reply; 33+ messages in thread
From: Thomas Zimmermann @ 2023-07-13 15:09 UTC (permalink / raw)
To: Sean Paul, Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Tvrtko Ursulin, Leo Li,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Maxime Ripard, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Raphael Gallais-Pou, Rodrigo Siqueira,
Russell King, Jani Nikula, Uma Shankar, Andi Shyti,
Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Jiapeng Chong, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx, Lang Yu,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1.1: Type: text/plain, Size: 3248 bytes --]
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
>>
>> hello Sean,
>>
>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
>>> I'd really prefer this patch (series or single) is not accepted. This
>>> will cause problems for everyone cherry-picking patches to a
>>> downstream kernel (LTS or distro tree). I usually wouldn't expect
>>> sympathy here, but the questionable benefit does not outweigh the cost
>>> IM[biased]O.
>>
>> I agree that for backports this isn't so nice. However with the split
>> approach (that was argumented against here) it's not soo bad. Patch #1
>> (and similar changes for the other affected structures) could be
>> trivially backported and with that it doesn't matter if you write dev or
>> drm (or whatever name is chosen in the end); both work in the same way.
>
> Patch #1 avoids the need to backport the entire set, however every
> change occuring after the rename patches will cause conflicts on
> future cherry-picks. Downstream kernels will have to backport the
> whole set. Backporting the entire set will create an epoch in
> downstream kernels where cherry-picking patches preceding this set
> will need to undergo conflict resolution as well. As mentioned in my
> previous email, I don't expect sympathy here, it's part of maintaining
> a downstream kernel, but there is a real cost to kernel consumers.
>
>>
>> But even with the one-patch-per-rename approach I'd consider the
>> renaming a net win, because ease of understanding code has a big value.
>> It's value is not so easy measurable as "conflicts when backporting",
>> but it also matters in say two years from now, while backporting
>> shouldn't be an issue then any more.
>
> You've rightly identified the conjecture in your statement. I've been
> on both sides of the argument, having written/maintained drm code
> upstream and cherry-picked changes to a downstream kernel. Perhaps
> it's because drm's definition of dev is ingrained in my muscle memory,
> or maybe it's because I don't do a lot of upstream development these
> days, but I just have a hard time seeing the benefit here.
I can only second what Sean writes. I've done quite a bit of backporting
of DRM code. It's hard already. And this kind of change is going to to
affect almost every backported DRM patch in the coming years. Not just
for distribution kernels, but also for upstream's stable series. It's
really only possible to do this change over many releases while keeping
compatible with the old name. So the more I think about it, the less I
like this change.
Best regards
Thomas
>
> I appreciate your engagement on the topic, thank you!
>
> Sean
>
>>
>> Thanks for your input, best regards
>> Uwe
>>
>> --
>> Pengutronix e.K. | Uwe Kleine-König |
>> Industrial Linux Solutions | https://www.pengutronix.de/ |
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 15:09 ` Thomas Zimmermann
@ 2023-07-13 15:14 ` Tvrtko Ursulin
2023-07-13 15:30 ` Maxime Ripard
2023-07-14 7:38 ` Thomas Zimmermann
0 siblings, 2 replies; 33+ messages in thread
From: Tvrtko Ursulin @ 2023-07-13 15:14 UTC (permalink / raw)
To: Thomas Zimmermann, Sean Paul, Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Raphael Gallais-Pou, Leo Li,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Maxime Ripard, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Rodrigo Siqueira, Russell King,
Jani Nikula, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx, Lang Yu,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
On 13/07/2023 16:09, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.23 um 16:41 schrieb Sean Paul:
>> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
>> <u.kleine-koenig@pengutronix.de> wrote:
>>>
>>> hello Sean,
>>>
>>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
>>>> I'd really prefer this patch (series or single) is not accepted. This
>>>> will cause problems for everyone cherry-picking patches to a
>>>> downstream kernel (LTS or distro tree). I usually wouldn't expect
>>>> sympathy here, but the questionable benefit does not outweigh the cost
>>>> IM[biased]O.
>>>
>>> I agree that for backports this isn't so nice. However with the split
>>> approach (that was argumented against here) it's not soo bad. Patch #1
>>> (and similar changes for the other affected structures) could be
>>> trivially backported and with that it doesn't matter if you write dev or
>>> drm (or whatever name is chosen in the end); both work in the same way.
>>
>> Patch #1 avoids the need to backport the entire set, however every
>> change occuring after the rename patches will cause conflicts on
>> future cherry-picks. Downstream kernels will have to backport the
>> whole set. Backporting the entire set will create an epoch in
>> downstream kernels where cherry-picking patches preceding this set
>> will need to undergo conflict resolution as well. As mentioned in my
>> previous email, I don't expect sympathy here, it's part of maintaining
>> a downstream kernel, but there is a real cost to kernel consumers.
>>
>>>
>>> But even with the one-patch-per-rename approach I'd consider the
>>> renaming a net win, because ease of understanding code has a big value.
>>> It's value is not so easy measurable as "conflicts when backporting",
>>> but it also matters in say two years from now, while backporting
>>> shouldn't be an issue then any more.
>>
>> You've rightly identified the conjecture in your statement. I've been
>> on both sides of the argument, having written/maintained drm code
>> upstream and cherry-picked changes to a downstream kernel. Perhaps
>> it's because drm's definition of dev is ingrained in my muscle memory,
>> or maybe it's because I don't do a lot of upstream development these
>> days, but I just have a hard time seeing the benefit here.
>
> I can only second what Sean writes. I've done quite a bit of backporting
> of DRM code. It's hard already. And this kind of change is going to to
> affect almost every backported DRM patch in the coming years. Not just
> for distribution kernels, but also for upstream's stable series. It's
> really only possible to do this change over many releases while keeping
> compatible with the old name. So the more I think about it, the less I
> like this change.
I've done my share of backporting, and still am doing it, so I can say I
dislike it as much as anyone, however.. Is this an argument which the
kernel as a wider entity typically accepts? If not could it be a
slippery slope to start a precedent?
It is a honest question - I am not familiar if there were or were not
any similar discussions in the past.
My gut feeling is that *if* there is a consensus that something
_improves_ the code base significantly, backporting pains should
probably not be weighted very heavily as a contra argument.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 15:14 ` Tvrtko Ursulin
@ 2023-07-13 15:30 ` Maxime Ripard
2023-07-14 7:38 ` Thomas Zimmermann
1 sibling, 0 replies; 33+ messages in thread
From: Maxime Ripard @ 2023-07-13 15:30 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
Uwe Kleine-König, spice-devel, Niranjana Vishwanathapura,
Dmitry Baryshkov, linux-sunxi, Matthias Brugger, Tim Huang,
Suraj Kandpal, André Almeida, Mika Kahola,
Raphael Gallais-Pou, Leo Li, Sascha Hauer, Lucas De Marchi,
Inki Dae, Sean Paul, Dave Airlie, Kamlesh Gurudasani,
Bhawanpreet Lakha, Łukasz Bartosik, Radhakrishna Sripada,
Andrew Jeffery, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Zack Rusin,
Laurent Pinchart, Alexandre Belloni, linux-aspeed, nouveau,
Mitul Golani, José Roberto de Souza, virtualization,
Thierry Reding, Yongqin Liu, Mario Limonciello, Fei Yang,
Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Chaitanya Kumar Borah, Tian Tao, Biju Das,
linux-amlogic, Evan Quan, Michal Simek, linux-arm-kernel,
Sean Paul, Neil Armstrong, Kai Vehmanen, Boris Brezillon,
Shawn Guo, Qingqing Zhuo, Sandy Huang, Swati Sharma,
linux-renesas-soc, Kyungmin Park, Maxime Coquelin, Kevin Hilman,
Hawking Zhang, Haneen Mohammed, Paul Cercueil, Anusha Srivatsa,
Dan Carpenter, Joonas Lahtinen, linux-hyperv, Stefan Agner,
Melissa Wen, Maíra Canal, Luca Coelho, Gerd Hoffmann,
Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Philipp Zabel,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Rodrigo Siqueira, Russell King,
Jani Nikula, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, Orson Zhai, amd-gfx,
Lang Yu, Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Wayne Lin, Drew Davenport, Hersen Wu, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 4133 bytes --]
On Thu, Jul 13, 2023 at 04:14:55PM +0100, Tvrtko Ursulin wrote:
>
> On 13/07/2023 16:09, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 13.07.23 um 16:41 schrieb Sean Paul:
> > > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > >
> > > > hello Sean,
> > > >
> > > > On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> > > > > I'd really prefer this patch (series or single) is not accepted. This
> > > > > will cause problems for everyone cherry-picking patches to a
> > > > > downstream kernel (LTS or distro tree). I usually wouldn't expect
> > > > > sympathy here, but the questionable benefit does not outweigh the cost
> > > > > IM[biased]O.
> > > >
> > > > I agree that for backports this isn't so nice. However with the split
> > > > approach (that was argumented against here) it's not soo bad. Patch #1
> > > > (and similar changes for the other affected structures) could be
> > > > trivially backported and with that it doesn't matter if you write dev or
> > > > drm (or whatever name is chosen in the end); both work in the same way.
> > >
> > > Patch #1 avoids the need to backport the entire set, however every
> > > change occuring after the rename patches will cause conflicts on
> > > future cherry-picks. Downstream kernels will have to backport the
> > > whole set. Backporting the entire set will create an epoch in
> > > downstream kernels where cherry-picking patches preceding this set
> > > will need to undergo conflict resolution as well. As mentioned in my
> > > previous email, I don't expect sympathy here, it's part of maintaining
> > > a downstream kernel, but there is a real cost to kernel consumers.
> > >
> > > >
> > > > But even with the one-patch-per-rename approach I'd consider the
> > > > renaming a net win, because ease of understanding code has a big value.
> > > > It's value is not so easy measurable as "conflicts when backporting",
> > > > but it also matters in say two years from now, while backporting
> > > > shouldn't be an issue then any more.
> > >
> > > You've rightly identified the conjecture in your statement. I've been
> > > on both sides of the argument, having written/maintained drm code
> > > upstream and cherry-picked changes to a downstream kernel. Perhaps
> > > it's because drm's definition of dev is ingrained in my muscle memory,
> > > or maybe it's because I don't do a lot of upstream development these
> > > days, but I just have a hard time seeing the benefit here.
> >
> > I can only second what Sean writes. I've done quite a bit of backporting
> > of DRM code. It's hard already. And this kind of change is going to to
> > affect almost every backported DRM patch in the coming years. Not just
> > for distribution kernels, but also for upstream's stable series. It's
> > really only possible to do this change over many releases while keeping
> > compatible with the old name. So the more I think about it, the less I
> > like this change.
>
> I've done my share of backporting, and still am doing it, so I can say I
> dislike it as much as anyone, however.. Is this an argument which the kernel
> as a wider entity typically accepts? If not could it be a slippery slope to
> start a precedent?
>
> It is a honest question - I am not familiar if there were or were not any
> similar discussions in the past.
Eventually, it's a trade-off. There's always pros and cons to merging
every patch, and "backporting pains" is indeed not a very strong con.
But it's definitely the kind of patch where everyone and their mother
will have their opinion, without every reaching a clear consensus, and
there's no clear benefit either (but I might be biaised on that one).
So imo, while that downside is fairly weak, the pros are certainly
weaker.
> My gut feeling is that *if* there is a consensus that something _improves_
> the code base significantly, backporting pains should probably not be
> weighted very heavily as a contra argument.
100% agreed here, but I'm afraid we're far from that point.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 14:41 ` Sean Paul
2023-07-13 15:09 ` Thomas Zimmermann
@ 2023-07-13 15:39 ` Uwe Kleine-König
1 sibling, 0 replies; 33+ messages in thread
From: Uwe Kleine-König @ 2023-07-13 15:39 UTC (permalink / raw)
To: Sean Paul
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Russell King, Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jyri Sarha, Jerome Brunet,
Liu Shixin, linux-samsung-soc, Drew Davenport, Samuel Holland,
Matt Roper, Wenjing Liu, Javier Martinez Canillas,
Stanislav Lisovskiy, NXP Linux Team, spice-devel,
Niranjana Vishwanathapura, Philipp Zabel, linux-sunxi, Tim Huang,
Suraj Kandpal, André Almeida, Andi Shyti, Yifan Zhang,
Leo Li, Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu,
Jessica Zhang, Kamlesh Gurudasani, Bhawanpreet Lakha,
Łukasz Bartosik, Radhakrishna Sripada, Andrew Jeffery,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Zack Rusin, Gerd Hoffmann,
Alexandre Belloni, amd-gfx, linux-aspeed, nouveau, Mitul Golani,
José Roberto de Souza, virtualization, Jiapeng Chong,
Thierry Reding, Yongqin Liu, Mario Limonciello, Fei Yang,
Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis, Aaron Liu,
Patrik Jakobsson, Vinod Polimera, linux-rockchip, Fangzhi Zuo,
Aurabindo Pillai, VMware Graphics Reviewers, Ben Skeggs,
Sam Ravnborg, Jouni Högander, Dave Airlie, linux-mips,
Martin Blumenstingl, linux-arm-msm, Animesh Manna, Maxime Ripard,
Chaitanya Kumar Borah, Biju Das, linux-amlogic, Evan Quan,
Michal Simek, linux-arm-kernel, Sean Paul, Neil Armstrong,
Kai Vehmanen, Boris Brezillon, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Sumit Semwal, Haneen Mohammed,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Laurent Pinchart, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Alain Volmat, Xinwei Kong, Jernej Skrabec, Deepak Rawat,
Chen-Yu Tsai, Joel Stanley, Orson Zhai, Ankit Nautiyal,
Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang, intel-gfx,
Alison Wang, Wolfram Sang, Abhinav Kumar, Gustavo Sousa,
Baolin Wang, Rodrigo Vivi, Gurchetan Singh, Tvrtko Ursulin,
Rodrigo Siqueira, Tomi Valkeinen, Deepak R Varma, Pan, Xinhui,
Konrad Dybcio, Kieran Bingham, Tian Tao, Roman Li, Shawn Guo,
Christian König, Khaled Almahallawy, linux-stm32,
Emma Anholt, Chun-Kuang Hu, Imre Deak, Liviu Dudau,
Alexandre Torgue, Mikko Perttunen, Paul Cercueil, Rob Clark,
Hamza Mahfooz, Marek Vasut, Paul Kocialkowski, xen-devel,
Guchun Chen, Oleksandr Andrushchenko, Raphael Gallais-Pou,
Rodrigo Siqueira, Krzysztof Kozlowski, Jani Nikula, Uma Shankar,
Mika Kahola, Jiasheng Jiang, Srinivasan Shanmugam, David Lechner,
Vinod Govindapillai, Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
David Tadokoro, AngeloGioacchino Del Regno, linux-tegra,
Yannick Fertre, Nicolas Ferre, John Stultz, Philippe Cornu,
Daniel Vetter, Wayne Lin, Dmitry Baryshkov, Nirmoy Das, Lang Yu,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
On Thu, Jul 13, 2023 at 10:41:45AM -0400, Sean Paul wrote:
> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > But even with the one-patch-per-rename approach I'd consider the
> > renaming a net win, because ease of understanding code has a big value.
> > It's value is not so easy measurable as "conflicts when backporting",
> > but it also matters in say two years from now, while backporting
> > shouldn't be an issue then any more.
>
> You've rightly identified the conjecture in your statement. I've been
> on both sides of the argument, having written/maintained drm code
> upstream and cherry-picked changes to a downstream kernel. Perhaps
> it's because drm's definition of dev is ingrained in my muscle memory,
> or maybe it's because I don't do a lot of upstream development these
> days, but I just have a hard time seeing the benefit here.
I see that my change doesn't immediately benefit those who are already
at home in drivers/gpu/drm. So it's quite understandable that someone in
a senior role (long time contributor or maintainer) doesn't see a big
upside.
In contrast I think my change (with its indisputable cost) lowers the
bar for new contributors to drm. IMHO that's something a maintainer has
to have on their radar, too, and that's easily undervalued in my
experience.
Of course in the end it's about weighting the ups and downs.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Nouveau] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
2023-07-13 15:14 ` Tvrtko Ursulin
2023-07-13 15:30 ` Maxime Ripard
@ 2023-07-14 7:38 ` Thomas Zimmermann
1 sibling, 0 replies; 33+ messages in thread
From: Thomas Zimmermann @ 2023-07-14 7:38 UTC (permalink / raw)
To: Tvrtko Ursulin, Sean Paul, Uwe Kleine-König
Cc: Heiko Stübner, Geert Uytterhoeven, Xinliang Liu,
Linus Walleij, Rodrigo Vivi, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Arun R Murthy, Jerome Brunet, linux-samsung-soc,
Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, NXP Linux Team,
spice-devel, Niranjana Vishwanathapura, Dmitry Baryshkov,
linux-sunxi, Matthias Brugger, Tim Huang, Suraj Kandpal,
André Almeida, Mika Kahola, Raphael Gallais-Pou, Leo Li,
Sascha Hauer, Lucas De Marchi, Inki Dae, Hersen Wu, Dave Airlie,
Kamlesh Gurudasani, Bhawanpreet Lakha, Łukasz Bartosik,
Radhakrishna Sripada, Andrew Jeffery, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Zack Rusin, Laurent Pinchart, Alexandre Belloni,
linux-aspeed, nouveau, Mitul Golani, José Roberto de Souza,
virtualization, Thierry Reding, Yongqin Liu, Mario Limonciello,
Fei Yang, Ville Syrjälä,
Juha-Pekka Heikkila, Chunyan Zhang, David Francis,
Vinod Govindapillai, Aaron Liu, Patrik Jakobsson, Vinod Polimera,
linux-rockchip, Fangzhi Zuo, Aurabindo Pillai,
VMware Graphics Reviewers, Ben Skeggs, Jouni Högander,
Jessica Zhang, Martin Blumenstingl, linux-arm-msm, Animesh Manna,
Nicolas Ferre, Maxime Ripard, Chaitanya Kumar Borah, Tian Tao,
Biju Das, linux-amlogic, Evan Quan, Michal Simek,
linux-arm-kernel, Sean Paul, Neil Armstrong, Kai Vehmanen,
Boris Brezillon, Shawn Guo, Qingqing Zhuo, Sandy Huang,
Swati Sharma, linux-renesas-soc, Kyungmin Park, Maxime Coquelin,
Kevin Hilman, Hawking Zhang, Haneen Mohammed, Paul Cercueil,
Anusha Srivatsa, Dan Carpenter, Joonas Lahtinen, linux-hyperv,
Stefan Agner, Melissa Wen, Maíra Canal, Luca Coelho,
Gerd Hoffmann, Andrzej Hajda, Likun Gao, Jiri Slaby (SUSE),
Emma Anholt, Alain Volmat, Chen-Yu Tsai, Jernej Skrabec,
Deepak Rawat, Xinwei Kong, Joel Stanley, Orson Zhai,
Ankit Nautiyal, Harry Wentland, Chia-I Wu, Alan Liu, Philip Yang,
intel-gfx, Alison Wang, Wolfram Sang, Abhinav Kumar,
Gustavo Sousa, Baolin Wang, Tomi Valkeinen, Daniel Vetter,
Mikko Perttunen, Yifan Zhang, Rodrigo Siqueira, Tomi Valkeinen,
Deepak R Varma, Pan, Xinhui, Konrad Dybcio, Kieran Bingham,
John Stultz, Roman Li, Sumit Semwal, Christian König,
Khaled Almahallawy, linux-stm32, Sam Ravnborg, Chun-Kuang Hu,
Imre Deak, Liviu Dudau, Alexandre Torgue, Gurchetan Singh,
Liu Shixin, Krzysztof Kozlowski, Hamza Mahfooz, Marek Vasut,
Paul Kocialkowski, xen-devel, Guchun Chen,
Oleksandr Andrushchenko, Rodrigo Siqueira, Russell King,
Jani Nikula, Uma Shankar, Andi Shyti, Jiasheng Jiang,
Srinivasan Shanmugam, David Lechner, Jiapeng Chong,
Marek Olšák, Maarten Lankhorst,
Joaquín Ignacio Aramendía, Melissa Wen, Hans de Goede,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
David Tadokoro, AngeloGioacchino Del Regno, amd-gfx, Lang Yu,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Philipp Zabel, Wayne Lin, Drew Davenport, Nirmoy Das, Jyri Sarha,
Lucas Stach
[-- Attachment #1.1: Type: text/plain, Size: 4448 bytes --]
Hi
Am 13.07.23 um 17:14 schrieb Tvrtko Ursulin:
>
> On 13/07/2023 16:09, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 13.07.23 um 16:41 schrieb Sean Paul:
>>> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
>>> <u.kleine-koenig@pengutronix.de> wrote:
>>>>
>>>> hello Sean,
>>>>
>>>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
>>>>> I'd really prefer this patch (series or single) is not accepted. This
>>>>> will cause problems for everyone cherry-picking patches to a
>>>>> downstream kernel (LTS or distro tree). I usually wouldn't expect
>>>>> sympathy here, but the questionable benefit does not outweigh the cost
>>>>> IM[biased]O.
>>>>
>>>> I agree that for backports this isn't so nice. However with the split
>>>> approach (that was argumented against here) it's not soo bad. Patch #1
>>>> (and similar changes for the other affected structures) could be
>>>> trivially backported and with that it doesn't matter if you write
>>>> dev or
>>>> drm (or whatever name is chosen in the end); both work in the same way.
>>>
>>> Patch #1 avoids the need to backport the entire set, however every
>>> change occuring after the rename patches will cause conflicts on
>>> future cherry-picks. Downstream kernels will have to backport the
>>> whole set. Backporting the entire set will create an epoch in
>>> downstream kernels where cherry-picking patches preceding this set
>>> will need to undergo conflict resolution as well. As mentioned in my
>>> previous email, I don't expect sympathy here, it's part of maintaining
>>> a downstream kernel, but there is a real cost to kernel consumers.
>>>
>>>>
>>>> But even with the one-patch-per-rename approach I'd consider the
>>>> renaming a net win, because ease of understanding code has a big value.
>>>> It's value is not so easy measurable as "conflicts when backporting",
>>>> but it also matters in say two years from now, while backporting
>>>> shouldn't be an issue then any more.
>>>
>>> You've rightly identified the conjecture in your statement. I've been
>>> on both sides of the argument, having written/maintained drm code
>>> upstream and cherry-picked changes to a downstream kernel. Perhaps
>>> it's because drm's definition of dev is ingrained in my muscle memory,
>>> or maybe it's because I don't do a lot of upstream development these
>>> days, but I just have a hard time seeing the benefit here.
>>
>> I can only second what Sean writes. I've done quite a bit of
>> backporting of DRM code. It's hard already. And this kind of change is
>> going to to affect almost every backported DRM patch in the coming
>> years. Not just for distribution kernels, but also for upstream's
>> stable series. It's really only possible to do this change over many
>> releases while keeping compatible with the old name. So the more I
>> think about it, the less I like this change.
>
> I've done my share of backporting, and still am doing it, so I can say I
> dislike it as much as anyone, however.. Is this an argument which the
> kernel as a wider entity typically accepts? If not could it be a
> slippery slope to start a precedent?
IMHO upstream patches should only be judged by their effect on the
upstream. Backporting, API stability, out-of-tree drivers, etc should
not be a concern. I think that we (the DRM devs) are mostly living up to
that ideal. OTOH if a change has been accepted, it's fair to ask how to
make it in the least intrusive way.
But with this change, it doesn't add up for me. The benefit to Linux is
rather cosmetic. And the possible downsides are significant even if we
ignore downstream distribution kernels. Merging between DRM trees will
be affected, backporting into stable kernels as well, the rename will
mess up git blame with rename commits.
Best regards
Thomas
>
> It is a honest question - I am not familiar if there were or were not
> any similar discussions in the past.
>
> My gut feeling is that *if* there is a consensus that something
> _improves_ the code base significantly, backporting pains should
> probably not be weighted very heavily as a contra argument.
>
> Regards,
>
> Tvrtko
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2023-07-23 9:24 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-12 9:46 [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
2023-07-12 9:46 ` [Nouveau] [PATCH RFC v1 26/52] drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev Uwe Kleine-König
2023-07-12 10:13 ` [Nouveau] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Paul Kocialkowski
2023-07-12 10:19 ` Thomas Zimmermann
2023-07-12 10:54 ` Uwe Kleine-König
2023-07-12 10:46 ` Christian König
2023-07-12 11:02 ` Uwe Kleine-König
2023-07-12 11:07 ` Julia Lawall
2023-07-12 11:13 ` Andrzej Hajda
2023-07-12 12:52 ` Maxime Ripard
2023-07-12 13:38 ` Uwe Kleine-König
2023-07-12 13:53 ` Maxime Ripard
2023-07-12 13:53 ` Christian König
2023-07-13 0:06 ` Luben Tuikov
2023-07-12 14:34 ` Jani Nikula
2023-07-12 16:10 ` Uwe Kleine-König
2023-07-13 6:52 ` Geert Uytterhoeven
2023-07-13 10:03 ` Uwe Kleine-König
2023-07-13 7:47 ` Thomas Zimmermann
2023-07-13 9:03 ` Jani Nikula
2023-07-13 9:29 ` Geert Uytterhoeven
2023-07-13 9:54 ` Uwe Kleine-König
2023-07-12 18:31 ` [Nouveau] [Freedreno] " Sean Paul
2023-07-12 19:22 ` Krzysztof Kozlowski
2023-07-13 7:48 ` Thomas Zimmermann
2023-07-13 13:03 ` Uwe Kleine-König
2023-07-13 14:41 ` Sean Paul
2023-07-13 15:09 ` Thomas Zimmermann
2023-07-13 15:14 ` Tvrtko Ursulin
2023-07-13 15:30 ` Maxime Ripard
2023-07-14 7:38 ` Thomas Zimmermann
2023-07-13 15:39 ` Uwe Kleine-König
2023-07-13 7:54 ` [Nouveau] " Thomas Zimmermann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).