[PATCH 14/42] drm/omap, omapfb: move exported dispc function declarations to omapdrm/omapfb

Laurent Pinchart laurent.pinchart at ideasonboard.com
Mon Mar 7 09:53:55 UTC 2016


Hi Tomi,

On Monday 07 March 2016 10:54:05 Tomi Valkeinen wrote:
> On 07/03/16 10:42, Laurent Pinchart wrote:
> > On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote:
> >> omapdrm and omapfb still share the same include/video/omapdss.h. We need
> >> to change that so that we can proceed with omapdrm work.
> >> 
> >> However, it's not trivial to make separate omapfb and omapdrm versions
> >> of omapdss.h, as that file is also included in other places like arch
> >> code, audio code and omap_vout code. So we'll do it piece by piece.
> >> 
> >> This patch makes private versions of all the dispc function declarations
> >> that are in omapdss.h. For omapdrm we create a new file,
> >> drivers/gpu/drm/omapdrm/dss/omapdss.h, which will contain headers meant
> >> to be visible outside omapdss.
> >> 
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> > 
> > This looks good to me, but I would squash patches 14/42 to 16/42 together,
> > as it will make it easier to review them and make sure everything
> > relevant has been moved.
> > 
> > Could you also confirm that the idea is to move anything that is not
> > needed by arch/ code away from include/video/omapdss.h ?
> 
> My aim is to move/restructure everything shared by omapfb and omapdss so
> that they would be fully independent. But at the moment we've got
> structs used between arch/, omapfb and omapdrm, so there are some
> challenges there.
> 
> include/video/omapdss.h was needed as a public omapdss header as we had
> multiple users for omapdss. Now on the omapdrm side we no longer need a
> public header at all, so in theory all that we need in omapdss.h (from
> omapdrm's perspective) are the parts used from arch/.
> 
> But, of course, as omapfb and omap_vout still need support from
> omapdss.h, I can't remove them just like that.
> 
> Probably I should create a new header for omapfb. Or maybe a new one for
> the parts used from arch/.

Given that some of the infrastructure is shared between omapfb and omap_vout, 
I believe it would make sense to do both. 

-- 
Regards,

Laurent Pinchart



More information about the dri-devel mailing list