From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C26C71922F8; Mon, 18 Nov 2024 09:26:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731921992; cv=none; b=stbM27wlpF5WH31R93KNKKVVanEMJClQM3FoCh6Uz7MgNjsoxw1RsLrSTHO9QreT+9vnEbkNWYREtspbbt4+ExOaqJ2gamxv1ZsN0tl5a3CF0c/Wj7YlNBYBx6kpA33oDvfC2QqHGMF8Vixg5hhXL976MarBWiLHbsq9lcf9nqk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731921992; c=relaxed/simple; bh=7y8SBkGv/+YxRzHcRFNsbkKg4SWkg6W8LTweSUKKcPY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IXGl6xclJ0y47wXHScZdqBoiB5iwRMS/XqJPeLhMfTSGmUmUoRgAyoZDWcnHfuR8OoW4FM0n/JWgCWt5yvOlbNo+SjZWRo/Mzs9aJKBWpq1deC0F/+U31K4/9Z27LZ+mUVmur7FQyTGrlWkVc4WPmC5fPMSgPxj03EPFCEzOsDs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Q6LqlZAK; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Q6LqlZAK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1731921991; x=1763457991; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=7y8SBkGv/+YxRzHcRFNsbkKg4SWkg6W8LTweSUKKcPY=; b=Q6LqlZAK3GrpWoAyb1IuFLpkjP83NebArx2N1iDVYp2lKRDkvvNBFNec LRMf0p0u9iyaC/4PrVWi9UoqbfNwxCUv33IWtUZK3LQ6UbxqoSfdvLDnT qq+qR/kL7L2Wtjsd2epxmjYJbpCOyTWDoPSJvsBQ1Dvg4BEkFLcXg0iVx Q25lhrSflWPkH/1OoUvvRb1q93sqyzGe86kFOgtrWGCOQwuqUk6h21hkP ZwXJybv7VqI70oAsqlmAwRytvEfTNhe2/FXR8SFq5XdBXNrtRv3QUHMWz r9A9D/lQusn74rbkA4IbdCp+gmv8Us2GrE9y3mQ7ciUTwpgc0z0WPxTtM g==; X-CSE-ConnectionGUID: OTbemUNQTmaZLP4qq92ucQ== X-CSE-MsgGUID: ro4G9MMQQ7WpFCOs67TZWA== X-IronPort-AV: E=McAfee;i="6700,10204,11259"; a="31794410" X-IronPort-AV: E=Sophos;i="6.12,163,1728975600"; d="scan'208";a="31794410" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2024 01:26:30 -0800 X-CSE-ConnectionGUID: MgkHwhaoTQqCebQt/Ozq/g== X-CSE-MsgGUID: HhCNlcMdTpy5FLhWGx+s5w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,163,1728975600"; d="scan'208";a="89572008" Received: from jkrzyszt-mobl2.ger.corp.intel.com (HELO localhost) ([10.245.246.148]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2024 01:26:07 -0800 From: Jani Nikula To: Dmitry Baryshkov , Laurent Pinchart Cc: Rodrigo Vivi , Joonas Lahtinen , Tvrtko Ursulin , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Karol Herbst , Lyude Paul , Danilo Krummrich , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= , Xinhui Pan , Alain Volmat , Raphael Gallais-Pou , Liviu Dudau , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Peter Senna Tschudin , Ian Ray , Martyn Welch , Inki Dae , Seung-Woo Kim , Kyungmin Park , Krzysztof Kozlowski , Alim Akhtar , Stefan Agner , Alison Wang , Patrik Jakobsson , Philipp Zabel , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Rob Clark , Abhinav Kumar , Sean Paul , Marijn Suijten , Dave Airlie , Gerd Hoffmann , Sandy Huang , Heiko =?utf-8?Q?St=C3=BCbner?= , Andy Yan , Chen-Yu Tsai , Samuel Holland , Thierry Reding , Mikko Perttunen , Jonathan Hunter , Dave Stevenson , =?utf-8?Q?Ma=C3=ADra?= Canal , Raspberry Pi Kernel Maintenance , Gurchetan Singh , Chia-I Wu , Zack Rusin , Broadcom internal kernel review list , intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, imx@lists.linux.dev, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org Subject: Re: [PATCH 1/5] drm/encoder_slave: make mode_valid accept const struct drm_display_mode In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20241115-drm-connector-mode-valid-const-v1-0-b1b523156f71@linaro.org> <20241115-drm-connector-mode-valid-const-v1-1-b1b523156f71@linaro.org> <20241117205426.GE12409@pendragon.ideasonboard.com> <20241117233250.GK12409@pendragon.ideasonboard.com> Date: Mon, 18 Nov 2024 11:26:03 +0200 Message-ID: <87plms51w4.fsf@intel.com> Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, 18 Nov 2024, Dmitry Baryshkov wrote: > On Mon, 18 Nov 2024 at 01:33, Laurent Pinchart > 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 >> > > >> > > Reviewed-by: Laurent Pinchart >> > > >> > > 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