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@linux.intel.com
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@suse.de Cc: Daniel Vetter daniel@ffwll.ch Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com
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