On Fri, Feb 07, 2020 at 06:34:47PM +0200, Ville Syrjälä wrote: > On Fri, Feb 07, 2020 at 05:27:51PM +0100, Daniel Vetter wrote: > > On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote: > > > On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote: > > > > Hi > > > > > > > > Am 07.02.20 um 14:59 schrieb Ville Syrjala: > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > The docs say possible_clones should always include the encoder itself. > > > > > Since most drivers don't want to deal with the complexities of cloning > > > > > let's allow them to set possible_clones=0 and instead we'll fix that > > > > > up in the core. > > > > > > > > > > We can't put this special case into drm_encoder_init() because drivers > > > > > will have to fill up possible_clones after adding all the relevant > > > > > encoders. Otherwise they wouldn't know the proper encoder indexes to > > > > > use. So we'll just do it just before registering the encoders. > > > > > > > > > > TODO: Should we do something similar for possible_crtcs==0? > > > > > > > > > > Cc: Thomas Zimmermann <tzimmermann@xxxxxxx> > > > > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > May this fixup function should warn iff possible_clones was set to non-0 > > > > by the driver, but the encoder itself is missing. > > > > > > Yeah, I guess we could do that. > > > > +1 on that, should catch some bugs at least. > > > > Also can you pls fix up the kerneldoc for drm_encoder.possible_clones, > > defacto this now means that 0 is a totally fine setting. > > Sure. > > And for possible_crtcs I was thinking similar concept: > > for_each_encoder() > if (possible_crtc == 0) > possible_crtcs = all_crtc_mask; A quick grep shows that I think we can risk enforcing this. If that turns out to be a misconception we can always go back to the fixup approach if possible_crtcs is 0. But unlike possible_clones I think for possible_crtcs the fixup-less approach looks possible at least. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
