On Wednesday, 14 February 2018 15:24:53 EET Tomi Valkeinen wrote:
> 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
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.
dri-devel mailing list