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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
