On Mon, 18 Nov 2024, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > On Mon, 18 Nov 2024 at 01:33, Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> >> On Mon, Nov 18, 2024 at 01:22:12AM +0200, Dmitry Baryshkov wrote: >> > On Sun, 17 Nov 2024 at 22:54, Laurent Pinchart wrote: >> > > On Fri, Nov 15, 2024 at 11:09:26PM +0200, Dmitry Baryshkov wrote: >> > > > The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge >> > > > accept const struct drm_display_mode argument. Change the mode_valid >> > > > callback of drm_encoder_slave to also accept const argument. >> > > > >> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> >> > > >> > > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> >> > > >> > > On a side note, there's only two I2C slave encoder drivers left... I >> > > wonder if we could so something about them. The ch7006 and sil164 >> > > drivers seem to be used by nouveau only, could they be moved to >> > > drivers/gpu/drm/nouveau/ ? We would move the whole drm_encoder_slave >> > > implementation there too, and leave it to die (or get taken out of limbo >> > > and fixed) with dispnv04. >> > >> > Or it might be better to switch to drm_bridge. Currently we also have >> > sil164 (sub)drivers in ast and i915 drivers. I don't know if there is >> > any common code to share or not. If there is some, it might be nice to >> > use common framework. >> >> That would require porting nouveau and i915 to drm_bridge. As much as >> I'd love to see that happening, I won't hold my breath. > > Me neither. Probably moving those two and drm_encoder_slave to nouveau > is really the best course for now. Granted, the dvo part of i915 is ugly, but it's also only relevant for the oldest hardware i915 supports. Like 20 years old. Not sure there's much return on investment in big refactoring, more risk that it breaks without nobody noticing. Just let it be in i915? BR, Jani. -- Jani Nikula, Intel