On Sun, Jun 25, 2023 at 10:58:17AM +0200, Geert Uytterhoeven wrote: > On Fri, Jun 23, 2023 at 8:50 PM Laurent Pinchart wrote: > > On Fri, Jun 23, 2023 at 07:55:22PM +0200, Geert Uytterhoeven wrote: > > > On Fri, Jun 23, 2023 at 6:50 PM Laurent Pinchart wrote: > > > > On Thu, Jun 22, 2023 at 11:21:36AM +0200, Geert Uytterhoeven wrote: > > > > > Unify primary and overlay plane allocation: > > > > > - Enhance shmob_drm_plane_create() so it can be used to create the > > > > > primary plane, too, > > > > > - Move overlay plane creation next to primary plane creation. > > > > > > > > > > As overlay plane index zero now means the primary plane, this requires > > > > > shifting all overlay plane indices by one. > > > > > > > > Do you use index zero to identify the primary plane just for > > > > shmob_drm_plane_create(), or somewhere else too ? If it's just to create > > > > the plane, you could instead pass the plane type to the function. > > > > > > Index zero is just used for the creation. > > > I guess this sort of goes together with my question below... > > > > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > > > > --- > > > > > Perhaps it would be better to not use dynamic allocation, but store > > > > > "struct drm_plane primary" and "struct shmob_drm_plane planes[5]" in > > > > > struct drm_shmob_device instead, like is done for the crtc and encoder? > > > > > > ... as embedding separate primary and planes[] would also get rid of > > > the need to adjust the plane indices when converting from logical to physical > > > overlay plane indices. > > > > Do they need to be embedded for that, or could you simple keep the index > > as it is ? > > If the plane type would be passed explicitly, they would not need to be > embedded for that. > > Then the question becomes: does it make sense to unify primary and > overlay plane handling? Good point. I don't mind much either way, it depends on how much code duplication it would remove I suppose. -- Regards, Laurent Pinchart
