[PATCH v2 00/30] omapdrm: Allocate objects dynamically

[Laurent Pinchart]

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