Thomas Zimmermann
2020-Mar-06 15:18 UTC
[PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Laurent Am 06.03.20 um 15:22 schrieb Laurent Pinchart:> Hi Thomas, > > Thank you for the patch. > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: >> A call to drm_simple_encoder_init() initializes an encoder without >> further functionality. It only provides the destroy callback to >> cleanup the encoder's state. Only few drivers implement more >> sophisticated encoders than that. Most drivers implement such a >> simple encoder and can use drm_simple_encoder_init() instead. >> >> The patchset converts drivers where the encoder's instance is >> embedded in a larger data structure. The driver releases the >> memory during cleanup. Each patch replaces drm_encoder_init() with >> drm_simple_encoder_init() and removes the (now unused) driver's >> encoder functions. >> >> While the patchset is fairly large, the indiviual patches are self- >> contained and can be merged independently from each other. The >> simple-encoder functionality is currently in drm-misc-next, where >> these patches could go as well. > > I've reviewed the whole series, including verifying that the few > instances of struct drm_encoder_funcs that were not declared const were > not modified somewhere to add more function pointers. > > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>Thanks for the detailed review.> > for all the patches. > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > misnommer here. Several of the encoders in those drivers to implement > additional functionality. They just expose them through > drm_encoder_helper_funcs, not drm_encoder_funcs.True. It's called 'simple encoder' for the lack of a better name. It's part of the simple KMS helpers, so the name's at least consistent. OTOH I always find drm_simple_display_pipe a bad name. We can still rename the simple-encoder function without much effort. I'm open for suggestions. Best regards Thomas> >> Future directions: There's another common case where the driver >> calls kzalloc() plus drm_encoder_init(). Such drivers are not >> handled by this patchset. The plan here is to use a simple encoder >> with either managed memory allocation (once it's merged), or embed >> the encoder in a larger data structure and drop kzalloc() entirely. > > I think an even more interesting future enhancement would be to add > encoder support to the newly added drm_bridge_connector_init(), for > drivers that are fully based on bridges and don't implement any encoder > operation, neither through drm_encoder_funcs nor through > drm_encoder_helper_funcs. > >> The patchset has been compile-tested on x86-64, aarch64 and arm. >> >> Thomas Zimmermann (22): >> drm/arc: Use simple encoder >> drm/atmel-hlcdc: Use simple encoder >> drm/exynos: Use simple encoder >> drm/fsl-dcu: Use simple encoder >> drm/gma500: Use simple encoder >> drm/hisilicon/kirin: Use simple encoder >> drm/i2c/tda998x: Use simple encoder >> drm/imx: Use simple encoder >> drm/ingenic: Use simple encoder >> drm/mediatek: Use simple encoder >> drm/rcar-du: Use simple encoder >> drm/rockchip: Use simple encoder >> drm/shmobile: Use simple encoder >> drm/sun4i: Use simple encoder >> drm/tegra: Use simple encoder >> drm/tidss: Use simple encoder >> drm/tilcdc: Use simple encoder >> drm/vc4: Use simple encoder >> drm/virtgpu: Use simple encoder >> drm/vkms: Use simple encoder >> drm/writeback: Use simple encoder >> drm/zte: Use simple encoder >> >> drivers/gpu/drm/arc/arcpgu_hdmi.c | 10 +++------- >> drivers/gpu/drm/arc/arcpgu_sim.c | 8 ++------ >> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 ++++-------- >> drivers/gpu/drm/drm_writeback.c | 10 +++------- >> drivers/gpu/drm/exynos/exynos_dp.c | 8 ++------ >> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++------ >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++------ >> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 ++------ >> drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++------ >> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 +++----------- >> drivers/gpu/drm/gma500/cdv_intel_crt.c | 14 +++----------- >> drivers/gpu/drm/gma500/cdv_intel_dp.c | 16 +++------------- >> drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 4 ++-- >> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 17 +++-------------- >> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 7 +++---- >> drivers/gpu/drm/gma500/mdfld_output.h | 1 - >> drivers/gpu/drm/gma500/mdfld_tmd_vid.c | 6 ------ >> drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 6 ------ >> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 14 ++------------ >> drivers/gpu/drm/gma500/oaktrail_lvds.c | 5 +++-- >> drivers/gpu/drm/gma500/psb_intel_drv.h | 1 - >> drivers/gpu/drm/gma500/psb_intel_lvds.c | 18 +++--------------- >> drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 5 ----- >> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 8 ++------ >> drivers/gpu/drm/i2c/tda998x_drv.c | 14 +++----------- >> drivers/gpu/drm/imx/dw_hdmi-imx.c | 8 ++------ >> drivers/gpu/drm/imx/imx-drm-core.c | 6 ------ >> drivers/gpu/drm/imx/imx-drm.h | 1 - >> drivers/gpu/drm/imx/imx-ldb.c | 8 ++------ >> drivers/gpu/drm/imx/imx-tve.c | 8 ++------ >> drivers/gpu/drm/imx/parallel-display.c | 8 ++------ >> drivers/gpu/drm/ingenic/ingenic-drm.c | 9 +++------ >> drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++----------- >> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++----------- >> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 14 +++----------- >> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++------ >> drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +++------ >> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 ++------ >> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 8 ++------ >> drivers/gpu/drm/rockchip/inno_hdmi.c | 8 ++------ >> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++------ >> drivers/gpu/drm/rockchip/rockchip_lvds.c | 10 +++------- >> drivers/gpu/drm/rockchip/rockchip_rgb.c | 8 ++------ >> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 14 +++----------- >> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 +++--------- >> drivers/gpu/drm/sun4i/sun4i_lvds.c | 12 +++--------- >> drivers/gpu/drm/sun4i/sun4i_rgb.c | 17 +++-------------- >> drivers/gpu/drm/sun4i/sun4i_tv.c | 17 +++-------------- >> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++--------- >> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 8 ++------ >> drivers/gpu/drm/tegra/drm.h | 2 -- >> drivers/gpu/drm/tegra/dsi.c | 10 +++------- >> drivers/gpu/drm/tegra/hdmi.c | 9 +++------ >> drivers/gpu/drm/tegra/output.c | 6 +----- >> drivers/gpu/drm/tegra/rgb.c | 8 ++------ >> drivers/gpu/drm/tegra/sor.c | 8 ++------ >> drivers/gpu/drm/tidss/tidss_encoder.c | 10 +++------- >> drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 +++------- >> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 8 ++------ >> drivers/gpu/drm/vc4/vc4_dpi.c | 8 ++------ >> drivers/gpu/drm/vc4/vc4_dsi.c | 15 +++------------ >> drivers/gpu/drm/vc4/vc4_hdmi.c | 17 ++++------------- >> drivers/gpu/drm/vc4/vc4_vec.c | 8 ++------ >> drivers/gpu/drm/virtio/virtgpu_display.c | 8 ++------ >> drivers/gpu/drm/vkms/vkms_output.c | 8 ++------ >> drivers/gpu/drm/zte/zx_hdmi.c | 8 ++------ >> drivers/gpu/drm/zte/zx_tvenc.c | 8 ++------ >> drivers/gpu/drm/zte/zx_vga.c | 8 ++------ >> 68 files changed, 151 insertions(+), 488 deletions(-) >-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N?rnberg, Germany (HRB 36809, AG N?rnberg) Gesch?ftsf?hrer: Felix Imend?rffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20200306/deb770be/attachment-0001.sig>
Sam Ravnborg
2020-Mar-07 20:08 UTC
[PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Thomas. On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote:> Hi Laurent > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > Hi Thomas, > > > > Thank you for the patch. > > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > >> A call to drm_simple_encoder_init() initializes an encoder without > >> further functionality. It only provides the destroy callback to > >> cleanup the encoder's state. Only few drivers implement more > >> sophisticated encoders than that. Most drivers implement such a > >> simple encoder and can use drm_simple_encoder_init() instead. > >> > >> The patchset converts drivers where the encoder's instance is > >> embedded in a larger data structure. The driver releases the > >> memory during cleanup. Each patch replaces drm_encoder_init() with > >> drm_simple_encoder_init() and removes the (now unused) driver's > >> encoder functions. > >> > >> While the patchset is fairly large, the indiviual patches are self- > >> contained and can be merged independently from each other. The > >> simple-encoder functionality is currently in drm-misc-next, where > >> these patches could go as well. > > > > I've reviewed the whole series, including verifying that the few > > instances of struct drm_encoder_funcs that were not declared const were > > not modified somewhere to add more function pointers. > > > > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com> > > Thanks for the detailed review. > > > > > for all the patches. > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > misnommer here. Several of the encoders in those drivers to implement > > additional functionality. They just expose them through > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > True. It's called 'simple encoder' for the lack of a better name. It's > part of the simple KMS helpers, so the name's at least consistent. OTOH > I always find drm_simple_display_pipe a bad name. > > We can still rename the simple-encoder function without much effort. I'm > open for suggestions.IMO this does not belong in drm_simple_kms - but in drm_encoder. This only occurs to me after looking a bit more on the patches, you would have loved to get this feedback earlier. Most users do not need their owm drm_encoder_funcs definition, and would be happy with the default as provided by drm_simple_* As the cleanup is handled automatically when the drm device is teared down (in mode_config_rest()) I considered if we could here use the drmm_ namespace - but that felt wrong. My proposal is the following: - Move the implementation to drm_encoder.c - Name it drm_encoder_init_nofuncs() The patches posted in this thread would be a little simpler as they would loose the added include file. And the three drivers using the current infrastructure would need a small update. I you decide to keep the current approach where the functions are in drm_simple_* then the full series is: Acked-by: Sam Ravnborg <sam at ravnborg.org> But I think moving it to drm_encoder.c would be the approach that would make it simpler to understand/follow. So that get my (biased) vote. Sam
Laurent Pinchart
2020-Mar-07 20:34 UTC
[PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Sam, On Sat, Mar 07, 2020 at 09:08:13PM +0100, Sam Ravnborg wrote:> On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: > > >> A call to drm_simple_encoder_init() initializes an encoder without > > >> further functionality. It only provides the destroy callback to > > >> cleanup the encoder's state. Only few drivers implement more > > >> sophisticated encoders than that. Most drivers implement such a > > >> simple encoder and can use drm_simple_encoder_init() instead. > > >> > > >> The patchset converts drivers where the encoder's instance is > > >> embedded in a larger data structure. The driver releases the > > >> memory during cleanup. Each patch replaces drm_encoder_init() with > > >> drm_simple_encoder_init() and removes the (now unused) driver's > > >> encoder functions. > > >> > > >> While the patchset is fairly large, the indiviual patches are self- > > >> contained and can be merged independently from each other. The > > >> simple-encoder functionality is currently in drm-misc-next, where > > >> these patches could go as well. > > > > > > I've reviewed the whole series, including verifying that the few > > > instances of struct drm_encoder_funcs that were not declared const were > > > not modified somewhere to add more function pointers. > > > > > > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com> > > > > Thanks for the detailed review. > > > > > for all the patches. > > > > > > However, I'd like to note that drm_simple_encoder_init() is a bit of a > > > misnommer here. Several of the encoders in those drivers to implement > > > additional functionality. They just expose them through > > > drm_encoder_helper_funcs, not drm_encoder_funcs. > > > > True. It's called 'simple encoder' for the lack of a better name. It's > > part of the simple KMS helpers, so the name's at least consistent. OTOH > > I always find drm_simple_display_pipe a bad name. > > > > We can still rename the simple-encoder function without much effort. I'm > > open for suggestions. > > IMO this does not belong in drm_simple_kms - but in drm_encoder. > This only occurs to me after looking a bit more on the patches, > you would have loved to get this feedback earlier. > > Most users do not need their owm drm_encoder_funcs definition, > and would be happy with the default as provided by drm_simple_* > > As the cleanup is handled automatically when the drm device > is teared down (in mode_config_rest()) I considered if we could here > use the drmm_ namespace - but that felt wrong. > > My proposal is the following: > - Move the implementation to drm_encoder.c > - Name it drm_encoder_init_nofuncs()Or better, rename the existing drm_encoder_init() to drm_encoder_init_funcs(), and rename drm_simple_encoder_init() to drm_encoder_init() ? It's the common case.> The patches posted in this thread would be a little simpler > as they would loose the added include file. > And the three drivers using the current infrastructure would need a > small update. > > I you decide to keep the current approach where the > functions are in drm_simple_* then the full series is: > Acked-by: Sam Ravnborg <sam at ravnborg.org> > > But I think moving it to drm_encoder.c would be the approach that would > make it simpler to understand/follow. So that get my (biased) vote.-- Regards, Laurent Pinchart
Thomas Zimmermann
2020-Mar-09 07:24 UTC
[PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
Hi Sam Am 07.03.20 um 21:08 schrieb Sam Ravnborg:> Hi Thomas. > > On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote: >> Hi Laurent >> >> Am 06.03.20 um 15:22 schrieb Laurent Pinchart: >>> Hi Thomas, >>> >>> Thank you for the patch. >>> >>> On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: >>>> A call to drm_simple_encoder_init() initializes an encoder without >>>> further functionality. It only provides the destroy callback to >>>> cleanup the encoder's state. Only few drivers implement more >>>> sophisticated encoders than that. Most drivers implement such a >>>> simple encoder and can use drm_simple_encoder_init() instead. >>>> >>>> The patchset converts drivers where the encoder's instance is >>>> embedded in a larger data structure. The driver releases the >>>> memory during cleanup. Each patch replaces drm_encoder_init() with >>>> drm_simple_encoder_init() and removes the (now unused) driver's >>>> encoder functions. >>>> >>>> While the patchset is fairly large, the indiviual patches are self- >>>> contained and can be merged independently from each other. The >>>> simple-encoder functionality is currently in drm-misc-next, where >>>> these patches could go as well. >>> >>> I've reviewed the whole series, including verifying that the few >>> instances of struct drm_encoder_funcs that were not declared const were >>> not modified somewhere to add more function pointers. >>> >>> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com> >> >> Thanks for the detailed review. >> >>> >>> for all the patches. >>> >>> However, I'd like to note that drm_simple_encoder_init() is a bit of a >>> misnommer here. Several of the encoders in those drivers to implement >>> additional functionality. They just expose them through >>> drm_encoder_helper_funcs, not drm_encoder_funcs. >> >> True. It's called 'simple encoder' for the lack of a better name. It's >> part of the simple KMS helpers, so the name's at least consistent. OTOH >> I always find drm_simple_display_pipe a bad name. >> >> We can still rename the simple-encoder function without much effort. I'm >> open for suggestions. > > IMO this does not belong in drm_simple_kms - but in drm_encoder. > This only occurs to me after looking a bit more on the patches, > you would have loved to get this feedback earlier.Well, the simple-encoder functionality used to be located in the encoder code, but Daniel mentioned this is more of a helper and asked me to move it out of the core. [1] So it ended up with the simple-KMS helpers. Best regards Thomas [1] https://patchwork.freedesktop.org/patch/352370/?series=73130&rev=1> > Most users do not need their owm drm_encoder_funcs definition, > and would be happy with the default as provided by drm_simple_* > > As the cleanup is handled automatically when the drm device > is teared down (in mode_config_rest()) I considered if we could here > use the drmm_ namespace - but that felt wrong. > > My proposal is the following: > - Move the implementation to drm_encoder.c > - Name it drm_encoder_init_nofuncs() > > The patches posted in this thread would be a little simpler > as they would loose the added include file. > And the three drivers using the current infrastructure would need a > small update. > > I you decide to keep the current approach where the > functions are in drm_simple_* then the full series is: > Acked-by: Sam Ravnborg <sam at ravnborg.org> > > But I think moving it to drm_encoder.c would be the approach that would > make it simpler to understand/follow. So that get my (biased) vote. > > Sam > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N?rnberg, Germany (HRB 36809, AG N?rnberg) Gesch?ftsf?hrer: Felix Imend?rffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20200309/8a7b4a7d/attachment.sig>
Apparently Analagous Threads
- [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
- [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
- [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
- [PATCH 05/22] drm/gma500: Use simple encoder
- [PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()