* Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Sean Paul @ 2023-07-12 18:31 UTC (permalink / raw)
To: Jani Nikula
Cc: 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,
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
In-Reply-To: <87fs5tgpvv.fsf@intel.com>
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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Uwe Kleine-König @ 2023-07-12 16:10 UTC (permalink / raw)
To: Jani Nikula
Cc: 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, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, 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, Drew Davenport,
Laurentiu Palcu, Shawn Guo, Sascha Hauer, Philipp Zabel,
Dan Carpenter, Paul Cercueil, Anitha Chrisanthus,
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, 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
In-Reply-To: <87fs5tgpvv.fsf@intel.com>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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: dri-devel, kernel, amd-gfx, Andrew Jeffery, linux-aspeed,
linux-arm-kernel, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-hyperv, intel-gfx,
Lucas Stach, Fabio Estevam, NXP Linux Team, linux-mips,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, Marijn Suijten,
linux-arm-msm, freedreno, nouveau, virtualization, spice-devel,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra, Gurchetan Singh, Chia-I Wu, Haneen Mohammed,
VMware Graphics Reviewers, xen-devel
In-Reply-To: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de>
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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Jonathan Hunter, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, Danilo Krummrich,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Stylon Wang, 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, Karol Herbst,
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, Lyude Paul, 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, David Airlie, 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,
Thomas Zimmermann, 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
In-Reply-To: <20230712133803.rf26cbg5wz7wsmgl@pengutronix.de>
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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Jonathan Hunter, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, Danilo Krummrich,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Stylon Wang, 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, Karol Herbst,
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, Lyude Paul, 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, David Airlie, 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,
Thomas Zimmermann, 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
In-Reply-To: <20230712133803.rf26cbg5wz7wsmgl@pengutronix.de>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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, Tomi Valkeinen, Alexey Kodanev, dri-devel,
Vandita Kulkarni, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Jonathan Hunter, Arun R Murthy, Jerome Brunet, Liu Shixin,
linux-samsung-soc, Samuel Holland, Matt Roper, Wenjing Liu,
Javier Martinez Canillas, Stanislav Lisovskiy, Danilo Krummrich,
NXP Linux Team, spice-devel, Niranjana Vishwanathapura,
linux-sunxi, Stylon Wang, 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, Karol Herbst,
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, Lyude Paul, 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, David Airlie, 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,
Thomas Zimmermann, 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
In-Reply-To: <o3dc4q27ap6rajsvpfwfvs3z3afekkwbhnclvswkaietciy2kc@unjf67gz5tur>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Maxime Ripard @ 2023-07-12 12:52 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christian König, Maarten Lankhorst, 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, Lang Yu, Philip Yang, Yifan Zhang, Tim Huang,
Zack Rusin, Sam Ravnborg, Jani Nikula, 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, Drew Davenport,
Laurentiu Palcu, Shawn Guo, Sascha Hauer, Philipp Zabel,
Dan Carpenter, Paul Cercueil, Anitha Chrisanthus,
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, 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,
Julia Lawall
In-Reply-To: <20230712110253.paoyrmcbvlhpfxbf@pengutronix.de>
[-- 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
* [PATCH] clocksource: Fix warnings in mshyperv.h
From: huzhi001 @ 2023-07-12 11:23 UTC (permalink / raw)
To: mingo, bp, dave.hansen, x86, tglx, kys, haiyangz, wei.liu, decui
Cc: hpa, linux-hyperv, linux-kernel
In-Reply-To: <tencent_7A4BAF2CDEE6AC56AB5ABBCE9CA1C2FE5205@qq.com>
The following checkpatch warnings are removed:
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
Signed-off-by: ZhiHu <huzhi001@208suo.com>
---
arch/x86/include/asm/mshyperv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mshyperv.h
b/arch/x86/include/asm/mshyperv.h
index 88d9ef98e087..fa83d88e4c99 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -5,7 +5,7 @@
#include <linux/types.h>
#include <linux/nmi.h>
#include <linux/msi.h>
-#include <asm/io.h>
+#include <linux/io.h>
#include <asm/hyperv-tlfs.h>
#include <asm/nospec-branch.h>
#include <asm/paravirt.h>
^ permalink raw reply related
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Andrzej Hajda @ 2023-07-12 11:13 UTC (permalink / raw)
To: Julia Lawall, Uwe Kleine-König
Cc: Christian 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, Lang Yu, Philip Yang, Yifan Zhang,
Tim Huang, Zack Rusin, Sam Ravnborg, Jani Nikula,
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, 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, Drew Davenport,
Laurentiu Palcu, Shawn Guo, Sascha Hauer, Philipp Zabel,
Dan Carpenter, Paul Cercueil, Anitha Chrisanthus,
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, 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
In-Reply-To: <acd7913-3c42-7354-434-a826b6c8718@inria.fr>
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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Julia Lawall @ 2023-07-12 11:07 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christian 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, Lang Yu, Philip Yang, Yifan Zhang,
Tim Huang, Zack Rusin, Sam Ravnborg, Jani Nikula,
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, Drew Davenport,
Laurentiu Palcu, Shawn Guo, Sascha Hauer, Philipp Zabel,
Dan Carpenter, Paul Cercueil, Anitha Chrisanthus,
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, 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,
Julia Lawall
In-Reply-To: <20230712110253.paoyrmcbvlhpfxbf@pengutronix.de>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Uwe Kleine-König @ 2023-07-12 11:02 UTC (permalink / raw)
To: Christian König
Cc: 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, Lang Yu,
Philip Yang, Yifan Zhang, Tim Huang, Zack Rusin, Sam Ravnborg,
Jani Nikula, 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, Drew Davenport,
Laurentiu Palcu, Shawn Guo, Sascha Hauer, Philipp Zabel,
Dan Carpenter, Paul Cercueil, Anitha Chrisanthus,
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, 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,
Julia Lawall
In-Reply-To: <94eb6e4d-9384-152f-351b-ebb217411da9@amd.com>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Uwe Kleine-König @ 2023-07-12 10:54 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: 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, Lang Yu,
Philip Yang, Yifan Zhang, Tim Huang, Zack Rusin, Sam Ravnborg,
Jani Nikula, 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, Drew Davenport,
Laurentiu Palcu, Shawn Guo, Sascha Hauer, Philipp Zabel,
Dan Carpenter, Paul Cercueil, Anitha Chrisanthus,
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, 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
In-Reply-To: <abf26a82-4f17-51f2-5753-785f8516a81a@suse.de>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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: dri-devel, kernel, amd-gfx, Andrew Jeffery, linux-aspeed,
linux-arm-kernel, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-hyperv, intel-gfx,
Lucas Stach, Fabio Estevam, NXP Linux Team, linux-mips,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, Marijn Suijten,
linux-arm-msm, freedreno, nouveau, virtualization, spice-devel,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra, Gurchetan Singh, Chia-I Wu, Haneen Mohammed,
VMware Graphics Reviewers, xen-devel
In-Reply-To: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de>
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
* Re: [PATCH 10/17] hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver
From: Bruno Prémont @ 2023-07-12 9:43 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, javierm, linux-sh, dri-devel, linux-kernel, amd-gfx,
linux-input, linux-media, linux-fbdev, linux-staging,
linux-arm-kernel, linux-geode, linux-nvidia, linux-hyperv,
linux-omap, linuxppc-dev, kvm, Jiri Kosina, Benjamin Tissoires
In-Reply-To: <20230710130113.14563-11-tzimmermann@suse.de>
On Mon, 10 Jul 2023 14:50:14 +0200 Thomas Zimmermann wrote:
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
>
> Flags should signal differences from the default values. After cleaning
> up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
Cheers,
Bruno
> ---
> drivers/hid/hid-picolcd_fb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
> index dabcd054dad9..d726aaafb146 100644
> --- a/drivers/hid/hid-picolcd_fb.c
> +++ b/drivers/hid/hid-picolcd_fb.c
> @@ -527,7 +527,6 @@ int picolcd_init_framebuffer(struct picolcd_data *data)
> info->var = picolcdfb_var;
> info->fix = picolcdfb_fix;
> info->fix.smem_len = PICOLCDFB_SIZE*8;
> - info->flags = FBINFO_FLAG_DEFAULT;
>
> fbdata = info->par;
> spin_lock_init(&fbdata->lock);
^ permalink raw reply
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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: dri-devel, kernel, amd-gfx, Andrew Jeffery, linux-aspeed,
linux-arm-kernel, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-hyperv, intel-gfx,
Lucas Stach, Fabio Estevam, NXP Linux Team, linux-mips,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, Marijn Suijten,
linux-arm-msm, freedreno, nouveau, virtualization, spice-devel,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra, Gurchetan Singh, Chia-I Wu, Haneen Mohammed,
VMware Graphics Reviewers, xen-devel
In-Reply-To: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de>
[-- 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
* Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
From: Paul Kocialkowski @ 2023-07-12 10:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: 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, 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, dri-devel, kernel, amd-gfx,
Andrew Jeffery, linux-aspeed, linux-arm-kernel, Alim Akhtar,
linux-samsung-soc, Xinwei Kong, Sumit Semwal, Yongqin Liu,
John Stultz, linux-hyperv, intel-gfx, Lucas Stach, Fabio Estevam,
NXP Linux Team, linux-mips, AngeloGioacchino Del Regno,
linux-mediatek, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
Sean Paul, Marijn Suijten, linux-arm-msm, freedreno, nouveau,
virtualization, spice-devel, linux-renesas-soc, linux-rockchip,
linux-stm32, linux-sunxi, linux-tegra, Gurchetan Singh, Chia-I Wu,
Haneen Mohammed, VMware Graphics Reviewers, xen-devel
In-Reply-To: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de>
[-- 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
* [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
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: dri-devel, kernel, amd-gfx, Andrew Jeffery, linux-aspeed,
linux-arm-kernel, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-hyperv, intel-gfx,
Lucas Stach, Fabio Estevam, NXP Linux Team, linux-mips,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, Marijn Suijten,
linux-arm-msm, freedreno, nouveau, virtualization, spice-devel,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra, Gurchetan Singh, Chia-I Wu, Haneen Mohammed,
VMware Graphics Reviewers, xen-devel
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
* [PATCH RFC v1 14/52] drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
From: Uwe Kleine-König @ 2023-07-12 9:46 UTC (permalink / raw)
To: Deepak Rawat, David Airlie, Daniel Vetter; +Cc: linux-hyperv, dri-devel, kernel
In-Reply-To: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de>
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/hyperv/hyperv_drm_modeset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
index 6c6b57298797..07ccc3cdc515 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c
@@ -102,7 +102,7 @@ static void hyperv_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
- struct hyperv_drm_device *hv = to_hv(pipe->crtc.dev);
+ struct hyperv_drm_device *hv = to_hv(pipe->crtc.drm_dev);
struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(plane_state);
hyperv_hide_hw_ptr(hv->hdev);
@@ -117,7 +117,7 @@ static int hyperv_pipe_check(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state,
struct drm_crtc_state *crtc_state)
{
- struct hyperv_drm_device *hv = to_hv(pipe->crtc.dev);
+ struct hyperv_drm_device *hv = to_hv(pipe->crtc.drm_dev);
struct drm_framebuffer *fb = plane_state->fb;
if (fb->format->format != DRM_FORMAT_XRGB8888)
@@ -135,7 +135,7 @@ static int hyperv_pipe_check(struct drm_simple_display_pipe *pipe,
static void hyperv_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *old_state)
{
- struct hyperv_drm_device *hv = to_hv(pipe->crtc.dev);
+ struct hyperv_drm_device *hv = to_hv(pipe->crtc.drm_dev);
struct drm_plane_state *state = pipe->plane.state;
struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(state);
struct drm_rect rect;
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v3] hv/hv_kvp_daemon: Add support for keyfile config based connection profile in NM
From: Ani Sinha @ 2023-07-12 7:02 UTC (permalink / raw)
To: Shradha Gupta
Cc: Wei Liu, Olaf Hering, linux-kernel, linux-hyperv,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Dexuan Cui,
Long Li, Michael Kelley
In-Reply-To: <20230523053627.GA10913@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
> On 23-May-2023, at 11:06 AM, Shradha Gupta <shradhagupta@linux.microsoft.com> wrote:
>
> On Mon, May 08, 2023 at 05:16:19PM +0000, Wei Liu wrote:
>> On Mon, May 08, 2023 at 07:12:46PM +0200, Olaf Hering wrote:
>>> Mon, 8 May 2023 16:47:54 +0000 Wei Liu <wei.liu@kernel.org>:
>>>
>>>> Olaf, is this a reviewed-by from you? :-)
>>>
>>> Sorry, I did not review the new functionality, just tried to make sure there will be no regression for existing consumers.
>>
>> Okay, this is fine, too. Thank you for looking into this.
>>
>>
>>>
>>> Olaf
>>
>
> Gentle reminder.
>
I have a comment about the following change:
+ error = fprintf(nmfile, "\n[ipv4]\n");
+ if (error < 0)
+ goto setval_error;
+
+ if (new_val->dhcp_enabled) {
+ error = kvp_write_file(nmfile, "method", "", "auto");
+ if (error < 0)
+ goto setval_error;
+ } else {
+ error = kvp_write_file(nmfile, "method", "", "manual");
+ if (error < 0)
+ goto setval_error;
+ }
I think the method equally would apply for ipv6 as it applies for ipv4.
We can use https://www.golinuxcloud.com/nmcli-command-examples-cheatsheet-centos-rhel/#18_Disable_IPv6_Address_for_ethernet_connection_IPV6INIT as a reference.
So setting the method should be common to both ipv4 and ipv6.
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Thomas Zimmermann @ 2023-07-12 6:44 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-arm-kernel, linux-hyperv, kvm, linux-sh, deller,
linux-staging, javierm, amd-gfx, linux-kernel, dri-devel,
linux-fbdev, linux-input, linux-nvidia, linux-omap, linuxppc-dev,
linux-geode, linux-media
In-Reply-To: <20230711144744.GA117276@ravnborg.org>
[-- Attachment #1.1: Type: text/plain, Size: 2411 bytes --]
Am 11.07.23 um 16:47 schrieb Sam Ravnborg:
> Hi Thomas,
>
> On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
>> Hi Sam
>>
>> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
>>> Hi Thomas,
>>>
>>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
>>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
>>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
>>>> useful when fbdev had special handling for driver modules. With
>>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
>>>> and have no further effect.
>>>>
>>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
>>>> split this by the way the fb_info struct is being allocated. All flags
>>>> are cleared to zero during the allocation.
>>>>
>>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
>>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
>>>> which is unrelated.
>>>>
>>>> Patch 17 removes both flag constants from <linux/fb.h>
>>>
>>> We have a few more flags that are unused - should they be nuked too?
>>> FBINFO_HWACCEL_FILLRECT
>>> FBINFO_HWACCEL_ROTATE
>>> FBINFO_HWACCEL_XPAN
>>
>> It seems those are there for completeness. Nothing sets _ROTATE, the others
>> are simply never checked. According to the comments, some are required, some
>> are optional. I don't know what that means.
>>
>> IIRC there were complains about performance when Daniel tried to remove
>> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>>
>> Leaving them in for reference/completeness might be an option; or not. I
>> have no strong feelings about those flags.
>>
>>>
>>> Unused as in no references from fbdev/core/*
>>>
>>> I would rather see one series nuke all unused FBINFO flags in one go.
>>> Assuming my quick grep are right and the above can be dropped.
>>
>> I would not want to extend this series. I'm removing _DEFAULT as it's
>> absolutely pointless and confusing.
>
> OK, makes sense and thanks for the explanation.
>
> The series is:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
Thanks a lot.
>
--
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
* Re: [PATCH 1/1] scsi: storvsc: Handle SRB status value 0x30
From: Martin K. Petersen @ 2023-07-11 19:34 UTC (permalink / raw)
To: Michael Kelley
Cc: kys, martin.petersen, longli, wei.liu, decui, jejb, linux-hyperv,
linux-kernel, linux-scsi
In-Reply-To: <1688788886-94279-1-git-send-email-mikelley@microsoft.com>
Michael,
> In response to a disk I/O request, Hyper-V has been observed to return
> SRB status value 0x30. This indicates the request was not processed by
> Hyper-V because low memory conditions on the host caused an internal
> error. The 0x30 status is not recognized by storvsc, so the I/O
> operation is not flagged as an error. The request is treated as if it
> completed normally but with zero data transferred, causing a flood of
> retries.
Applied to 6.5/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: (subset) [PATCH v2 00/24] use vmalloc_array and vcalloc
From: Martin K. Petersen @ 2023-07-11 16:31 UTC (permalink / raw)
To: linux-hyperv, Julia Lawall
Cc: Martin K . Petersen, kernel-janitors, keescook,
christophe.jaillet, kuba, kasan-dev, Andrey Konovalov,
Dmitry Vyukov, iommu, linux-tegra, Robin Murphy, Krishna Reddy,
virtualization, Xuan Zhuo, linux-scsi, linaro-mm-sig, linux-media,
John Stultz, Brian Starkey, Laura Abbott, Liam Mark,
Benjamin Gaignard, dri-devel, linux-kernel, netdev,
Shailend Chand, linux-rdma, mhi, linux-arm-msm, linux-btrfs,
intel-gvt-dev, intel-gfx, Dave Hansen, H. Peter Anvin, linux-sgx
In-Reply-To: <20230627144339.144478-1-Julia.Lawall@inria.fr>
On Tue, 27 Jun 2023 16:43:15 +0200, Julia Lawall wrote:
> The functions vmalloc_array and vcalloc were introduced in
>
> commit a8749a35c399 ("mm: vmalloc: introduce array allocation functions")
>
> but are not used much yet. This series introduces uses of
> these functions, to protect against multiplication overflows.
>
> [...]
Applied to 6.5/scsi-fixes, thanks!
[07/24] scsi: fnic: use vmalloc_array and vcalloc
https://git.kernel.org/mkp/scsi/c/b34c7dcaf311
[24/24] scsi: qla2xxx: use vmalloc_array and vcalloc
https://git.kernel.org/mkp/scsi/c/04d91b783acf
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Geert Uytterhoeven @ 2023-07-11 16:04 UTC (permalink / raw)
To: Helge Deller
Cc: Sam Ravnborg, Thomas Zimmermann, javierm, linux-fbdev, kvm,
linux-hyperv, linux-sh, linux-staging, linux-kernel, amd-gfx,
linux-geode, dri-devel, linux-input, linux-nvidia, linux-omap,
linuxppc-dev, linux-arm-kernel, linux-media
In-Reply-To: <bf439387-6b13-0fd9-f61b-1a5cbf731187@gmx.de>
Hi Helge,
On Tue, Jul 11, 2023 at 5:26 PM Helge Deller <deller@gmx.de> wrote:
> On 7/11/23 16:47, Sam Ravnborg wrote:
> > On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
> >> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
> >>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> >>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> >>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> >>>> useful when fbdev had special handling for driver modules. With
> >>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
> >>>> and have no further effect.
> >>>>
> >>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
> >>>> split this by the way the fb_info struct is being allocated. All flags
> >>>> are cleared to zero during the allocation.
> >>>>
> >>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
> >>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
> >>>> which is unrelated.
> >>>>
> >>>> Patch 17 removes both flag constants from <linux/fb.h>
> >>>
> >>> We have a few more flags that are unused - should they be nuked too?
> >>> FBINFO_HWACCEL_FILLRECT
> >>> FBINFO_HWACCEL_ROTATE
> >>> FBINFO_HWACCEL_XPAN
> >>
> >> It seems those are there for completeness. Nothing sets _ROTATE,
>
> I think some fbdev drivers had hardware acceleration for ROTATE in the
> past. HWACCEL_XPAN is still in some drivers.
>
> >> the others are simply never checked. According to the comments,
> >> some are required, some are optional. I don't know what that
> >> means.
>
> I think it's OK if you remove those flags which aren't used anywhere,
> e.g. FBINFO_HWACCEL_ROTATE.
Indeed.
> >> IIRC there were complains about performance when Daniel tried to remove
> >> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>
> Correct. I think COPYAREA and FILLRECT are the bare minimum to accelerate
> fbcon, IMAGEBLIT is for showing the tux penguin (?),
> XPAN/YPAN and YWRAP for some hardware screen panning needed by some drivers
> (not sure if this is still used as I don't have such hardware, Geert?).
Yes, they are used. Anything that is handled in drivers/video/fbdev/core/
is used:
$ git grep HWACCEL_ -- drivers/video/fbdev/core/
drivers/video/fbdev/core/fbcon.c: if ((info->flags &
FBINFO_HWACCEL_COPYAREA) &&
drivers/video/fbdev/core/fbcon.c: !(info->flags &
FBINFO_HWACCEL_DISABLED))
drivers/video/fbdev/core/fbcon.c: int good_pan = (cap &
FBINFO_HWACCEL_YPAN) &&
drivers/video/fbdev/core/fbcon.c: int good_wrap = (cap &
FBINFO_HWACCEL_YWRAP) &&
drivers/video/fbdev/core/fbcon.c: int fast_copyarea = (cap &
FBINFO_HWACCEL_COPYAREA) &&
drivers/video/fbdev/core/fbcon.c: !(cap &
FBINFO_HWACCEL_DISABLED);
drivers/video/fbdev/core/fbcon.c: int fast_imageblit = (cap &
FBINFO_HWACCEL_IMAGEBLIT) &&
drivers/video/fbdev/core/fbcon.c: !(cap &
FBINFO_HWACCEL_DISABLED);
BTW, I'm surprised FBINFO_HWACCEL_FILLRECT is not handled.
But looking at the full history, it never was...
> >> Leaving them in for reference/completeness might be an option; or not. I
> >> have no strong feelings about those flags.
>
> I'd say drop FBINFO_HWACCEL_ROTATE at least ?
Agreed.
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
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Helge Deller @ 2023-07-11 15:24 UTC (permalink / raw)
To: Sam Ravnborg, Thomas Zimmermann
Cc: javierm, linux-fbdev, kvm, linux-hyperv, linux-sh, linux-staging,
linux-kernel, amd-gfx, linux-geode, dri-devel, linux-input,
linux-nvidia, linux-omap, linuxppc-dev, linux-arm-kernel,
linux-media
In-Reply-To: <20230711144744.GA117276@ravnborg.org>
On 7/11/23 16:47, Sam Ravnborg wrote:
> Hi Thomas,
>
> On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
>> Hi Sam
>>
>> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
>>> Hi Thomas,
>>>
>>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
>>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
>>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
>>>> useful when fbdev had special handling for driver modules. With
>>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
>>>> and have no further effect.
>>>>
>>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
>>>> split this by the way the fb_info struct is being allocated. All flags
>>>> are cleared to zero during the allocation.
>>>>
>>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
>>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
>>>> which is unrelated.
>>>>
>>>> Patch 17 removes both flag constants from <linux/fb.h>
>>>
>>> We have a few more flags that are unused - should they be nuked too?
>>> FBINFO_HWACCEL_FILLRECT
>>> FBINFO_HWACCEL_ROTATE
>>> FBINFO_HWACCEL_XPAN
>>
>> It seems those are there for completeness. Nothing sets _ROTATE,
I think some fbdev drivers had hardware acceleration for ROTATE in the
past. HWACCEL_XPAN is still in some drivers.
>> the others are simply never checked. According to the comments,
>> some are required, some are optional. I don't know what that
>> means.
I think it's OK if you remove those flags which aren't used anywhere,
e.g. FBINFO_HWACCEL_ROTATE.
>> IIRC there were complains about performance when Daniel tried to remove
>> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
Correct. I think COPYAREA and FILLRECT are the bare minimum to accelerate
fbcon, IMAGEBLIT is for showing the tux penguin (?),
XPAN/YPAN and YWRAP for some hardware screen panning needed by some drivers
(not sure if this is still used as I don't have such hardware, Geert?).
>> Leaving them in for reference/completeness might be an option; or not. I
>> have no strong feelings about those flags.
I'd say drop FBINFO_HWACCEL_ROTATE at least ?
>>> Unused as in no references from fbdev/core/*
>>>
>>> I would rather see one series nuke all unused FBINFO flags in one go.
>>> Assuming my quick grep are right and the above can be dropped.
>>
>> I would not want to extend this series. I'm removing _DEFAULT as it's
>> absolutely pointless and confusing.
Yes, Ok.
Helge
^ permalink raw reply
* Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags
From: Sam Ravnborg @ 2023-07-11 14:47 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: deller, javierm, linux-fbdev, kvm, linux-hyperv, linux-sh,
linux-staging, linux-kernel, amd-gfx, linux-geode, dri-devel,
linux-input, linux-nvidia, linux-omap, linuxppc-dev,
linux-arm-kernel, linux-media
In-Reply-To: <ab92f8d9-36ab-06bc-b85b-d52b7a1bfe9a@suse.de>
Hi Thomas,
On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> > > Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> > > fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> > > useful when fbdev had special handling for driver modules. With
> > > commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
> > > and have no further effect.
> > >
> > > Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
> > > split this by the way the fb_info struct is being allocated. All flags
> > > are cleared to zero during the allocation.
> > >
> > > Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
> > > an actual bug in how arch/sh uses the tokne for struct fb_videomode,
> > > which is unrelated.
> > >
> > > Patch 17 removes both flag constants from <linux/fb.h>
> >
> > We have a few more flags that are unused - should they be nuked too?
> > FBINFO_HWACCEL_FILLRECT
> > FBINFO_HWACCEL_ROTATE
> > FBINFO_HWACCEL_XPAN
>
> It seems those are there for completeness. Nothing sets _ROTATE, the others
> are simply never checked. According to the comments, some are required, some
> are optional. I don't know what that means.
>
> IIRC there were complains about performance when Daniel tried to remove
> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>
> Leaving them in for reference/completeness might be an option; or not. I
> have no strong feelings about those flags.
>
> >
> > Unused as in no references from fbdev/core/*
> >
> > I would rather see one series nuke all unused FBINFO flags in one go.
> > Assuming my quick grep are right and the above can be dropped.
>
> I would not want to extend this series. I'm removing _DEFAULT as it's
> absolutely pointless and confusing.
OK, makes sense and thanks for the explanation.
The series is:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox