Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically
On 13/02/18 14:00, Laurent Pinchart wrote: > Hello, > > Most of this series has previously been posted as part of "[PATCH 00/48] > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm: > Miscellaneous fixes and cleanups" posted and merged a few days ago, it > completes the rework of the omapdrm and omapdss drivers to replace most > global variables with dynamically-allocated objects. The actual merge of > the omapdrm and omapdss drivers has been left out for now as it still > suffers from unresolved issues. > > As with the previous series I have other pending patches based on top of this, > as passing driver objects around explicitly helps not relying on more global > variables that would hinder the effort to move to the DRM bridge and DRM panel > APIs. > > Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen > significant changes and I have thus dropped the Reviewed-by tag from > Sebastian. All other patches have been rebased and reordered, thus sometimes > modified to resolve conflicts, but have otherwise seen only minor changes. > > The series is based on top of the omapdrm-next branch from > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git. > > Tomi, as the series has been stripped of its controversial patches, I think > it's now ready to be merged (pending review of the patches mentioned above of > course). I have tested it on both a Panda board and an AM57xx EVM without any > issues (and this time I made sure to try with the drivers compiled as > modules). Thanks, I have pushed this to my omapdrm-next. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically
On 14/02/18 17:39, Laurent Pinchart wrote: >> I have to admit I didn't go through every line of the patches, but >> overall I think this looks good. The only problem is the support for >> DSS6, which I mentioned in the other mail. >> >> We don't have DSS6 support in mainline, but it's a critical thing for TI >> to support. If it helps, we can upstream the current DSS6 driver (which >> is not very big), so that these can be reworked with DSS6 included. Or >> we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6 >> driver working on top of these (which, afaics, is not possible at the >> moment). > > Following up our discussion in reply to another e-mail in this thread, would > switching to struct device pointers for DSS and DISPC objects in the public > API help ? Is there anything else preventing DSS6 from working on top of this I think using struct device pointers should be enough to get DSS6 working, but we need to try it out. And, as you pointed out, the structs are opaque to omapdrm, so if we're sure they don't leak to omapdrm and don't mix up between dss2-5 and dss6 drivers, we could even use the same struct. But I think that's rather messy, so if we do that it should be just a temporary measure. > series ? I would personally prefer getting the cleanups and reworks > (including > the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in > mainline, as the problem is already complex enough. I agree, but then, I've been pushing the upstreaming of DSS6 driver forward for a very long time already. And, it does create these kind of issue, making it very laborious to carry in TI's tree. So, I'm fine with waiting still a bit longer, but if the bridge/panel work gets delayed, I'd rather push DSS6. I made a quick branch on top of drm-next which contains the DSS6: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 4.17/omapdrm-dss6-test The first three patches have already been posted for review, and the last three and not that relevant here. It's essentially a simplified version of the old DSS, with slightly different registers. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically
Hi Tomi, On Wednesday, 14 February 2018 15:24:53 EET Tomi Valkeinen wrote: > Hi, > > On 13/02/18 14:00, Laurent Pinchart wrote: > > Hello, > > > > Most of this series has previously been posted as part of "[PATCH 00/48] > > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm: > > Miscellaneous fixes and cleanups" posted and merged a few days ago, it > > completes the rework of the omapdrm and omapdss drivers to replace most > > global variables with dynamically-allocated objects. The actual merge of > > the omapdrm and omapdss drivers has been left out for now as it still > > suffers from unresolved issues. > > > > As with the previous series I have other pending patches based on top of > > this, as passing driver objects around explicitly helps not relying on > > more global variables that would hinder the effort to move to the DRM > > bridge and DRM panel APIs. > > > > Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen > > significant changes and I have thus dropped the Reviewed-by tag from > > Sebastian. All other patches have been rebased and reordered, thus > > sometimes modified to resolve conflicts, but have otherwise seen only > > minor changes. > > > > The series is based on top of the omapdrm-next branch from > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git. > > > > Tomi, as the series has been stripped of its controversial patches, I > > think it's now ready to be merged (pending review of the patches mentioned > > above of course). I have tested it on both a Panda board and an AM57xx EVM > > without any issues (and this time I made sure to try with the drivers > > compiled as modules). > > I have to admit I didn't go through every line of the patches, but > overall I think this looks good. The only problem is the support for > DSS6, which I mentioned in the other mail. > > We don't have DSS6 support in mainline, but it's a critical thing for TI > to support. If it helps, we can upstream the current DSS6 driver (which > is not very big), so that these can be reworked with DSS6 included. Or > we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6 > driver working on top of these (which, afaics, is not possible at the > moment). Following up our discussion in reply to another e-mail in this thread, would switching to struct device pointers for DSS and DISPC objects in the public API help ? Is there anything else preventing DSS6 from working on top of this series ? I would personally prefer getting the cleanups and reworks (including the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in mainline, as the problem is already complex enough. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically
Hi, On 13/02/18 14:00, Laurent Pinchart wrote: > Hello, > > Most of this series has previously been posted as part of "[PATCH 00/48] > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm: > Miscellaneous fixes and cleanups" posted and merged a few days ago, it > completes the rework of the omapdrm and omapdss drivers to replace most > global variables with dynamically-allocated objects. The actual merge of > the omapdrm and omapdss drivers has been left out for now as it still > suffers from unresolved issues. > > As with the previous series I have other pending patches based on top of this, > as passing driver objects around explicitly helps not relying on more global > variables that would hinder the effort to move to the DRM bridge and DRM panel > APIs. > > Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen > significant changes and I have thus dropped the Reviewed-by tag from > Sebastian. All other patches have been rebased and reordered, thus sometimes > modified to resolve conflicts, but have otherwise seen only minor changes. > > The series is based on top of the omapdrm-next branch from > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git. > > Tomi, as the series has been stripped of its controversial patches, I think > it's now ready to be merged (pending review of the patches mentioned above of > course). I have tested it on both a Panda board and an AM57xx EVM without any > issues (and this time I made sure to try with the drivers compiled as > modules). I have to admit I didn't go through every line of the patches, but overall I think this looks good. The only problem is the support for DSS6, which I mentioned in the other mail. We don't have DSS6 support in mainline, but it's a critical thing for TI to support. If it helps, we can upstream the current DSS6 driver (which is not very big), so that these can be reworked with DSS6 included. Or we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6 driver working on top of these (which, afaics, is not possible at the moment). Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/30] omapdrm: Allocate objects dynamically
Hello, Most of this series has previously been posted as part of "[PATCH 00/48] omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm: Miscellaneous fixes and cleanups" posted and merged a few days ago, it completes the rework of the omapdrm and omapdss drivers to replace most global variables with dynamically-allocated objects. The actual merge of the omapdrm and omapdss drivers has been left out for now as it still suffers from unresolved issues. As with the previous series I have other pending patches based on top of this, as passing driver objects around explicitly helps not relying on more global variables that would hinder the effort to move to the DRM bridge and DRM panel APIs. Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen significant changes and I have thus dropped the Reviewed-by tag from Sebastian. All other patches have been rebased and reordered, thus sometimes modified to resolve conflicts, but have otherwise seen only minor changes. The series is based on top of the omapdrm-next branch from git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git. Tomi, as the series has been stripped of its controversial patches, I think it's now ready to be merged (pending review of the patches mentioned above of course). I have tested it on both a Panda board and an AM57xx EVM without any issues (and this time I made sure to try with the drivers compiled as modules). Laurent Pinchart (30): drm: omapdrm: Split init and cleanup from probe and remove functions drm: omapdrm: dss: Expose DSS data in a dss_device structure drm: omapdrm: dss: Pass DSS private structure to runtime PM functions drm: omapdrm: dss: Pass PLL pointer to dss_ctrl_pll_enable() drm: omapdrm: dss: Pass DSS pointer to dss_sdi_*() functions drm: omapdrm: dss: Pass DSS pointer to dss_ops operations drm: omapdrm: dss: Pass DSS pointer to dss_get_*_clk_source() drm: omapdrm: dss: Pass DSS pointer to dss clock functions drm: omapdrm: dss: Pass DSS pointer to remaining dss functions drm: omapdrm: dss: Allocate the DSS private data structure dynamically drm: omapdrm: dss: Support passing private data to debugfs show handlers drm: omapdrm: dss: Store the registered plls array in struct dss_device drm: omapdrm: dss: Store the debugfs root directory in struct dss_device drm: omapdrm: dss: Don't unnecessarily cast to dev to pdev and back drm: omapdrm: dsi: Pass the dsi_data pointer to internal functions drm: omapdrm: dsi: Combine two commonly used inline functions drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function drm: omapdrm: dsi: Store the struct device pointer in struct dsi_data drm: omapdrm: dsi: Don't pass channel to dispc init/uninit functions drm: omapdrm: dss: Pass omap_dss_device pointer to dss_mgr_*() functions drm: omapdrm: dss: Pass omap_drm_private pointer to dss_mgr_ops drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data drm: omapdrm: dss: Store dispc ops in dss_device structure drm: omapdrm: dispc: Pass DISPC pointer to dispc_ops operations drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions drm: omapdrm: dispc: Allocate the dispc private data structure dynamically drm: omapdrm: hdmi4: Allocate the omap_hdmi data structure dynamically drm: omapdrm: hdmi5: Allocate the omap_hdmi data structure dynamically drm: omapdrm: sdi: Allocate the sdi private data structure dynamically drm: omapdrm: venc: Allocate the venc private data structure dynamically drivers/gpu/drm/omapdrm/dss/base.c | 27 +- drivers/gpu/drm/omapdrm/dss/dispc.c | 2183 -- drivers/gpu/drm/omapdrm/dss/dpi.c| 89 +- drivers/gpu/drm/omapdrm/dss/dsi.c| 1466 ++-- drivers/gpu/drm/omapdrm/dss/dss.c| 668 - drivers/gpu/drm/omapdrm/dss/dss.h| 229 ++-- drivers/gpu/drm/omapdrm/dss/hdmi.h | 11 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 371 ++--- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c |4 +- drivers/gpu/drm/omapdrm/dss/hdmi4_core.h |4 +- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 379 +++--- drivers/gpu/drm/omapdrm/dss/hdmi_pll.c | 15 +- drivers/gpu/drm/omapdrm/dss/omapdss.h| 171 ++- drivers/gpu/drm/omapdrm/dss/output.c | 52 +- drivers/gpu/drm/omapdrm/dss/pll.c| 40 +- drivers/gpu/drm/omapdrm/dss/sdi.c| 162 ++- drivers/gpu/drm/omapdrm/dss/venc.c | 453 --- drivers/gpu/drm/omapdrm/dss/video-pll.c | 19 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 62 +- drivers/gpu/drm/omapdrm/omap_crtc.h |2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 102 +- drivers/gpu/drm/omapdrm/omap_drv.h |4 + drivers/gpu/drm/omapdrm/omap_irq.c | 32 +- drivers/gpu/drm/omapdrm/omap_plane.c | 12 +- 24 files changed, 3484 insertions(+), 3073 deletions(-) -- Regards, Laurent Pinchart
