Received-SPF: pass (google.com: domain of linux-kernel+bounces-189060-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 24 May 2024 22:46:52 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Jayesh Choudhary <j-choudhary@ti.com>
Cc: linux-kernel@vger.kernel.org, andrzej.hajda@intel.com, 
	neil.armstrong@linaro.org, rfoss@kernel.org, Laurent.pinchart@ideasonboard.com, 
	sam@ravnborg.org, mripard@kernel.org, dri-devel@lists.freedesktop.org, 
	jonas@kwiboo.se, jernej.skrabec@gmail.com, maarten.lankhorst@linux.intel.com, 
	tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch, a-bhatia1@ti.com
Subject: Re: [PATCH v3 1/2] drm/bridge: sii902x: Fix mode_valid hook
Message-ID: <x7i5miguht47wxliioos7npelzzicnwt7g5pfjqjvdztksgzga@c7djvf3lg3kf>
References: <20240524093509.127189-1-j-choudhary@ti.com>
 <20240524093509.127189-2-j-choudhary@ti.com>
 <y6ersd72tp2d6k4i2hja7bg37lahnvye2qion67urxeakw6rju@dher7oomt2ks>
 <4cd64cf5-d2b0-4aa9-b958-6b6fc54f0bf2@ti.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4cd64cf5-d2b0-4aa9-b958-6b6fc54f0bf2@ti.com>

On Fri, May 24, 2024 at 05:54:02PM +0530, Jayesh Choudhary wrote:
> Hello Dmitry,
> 
> On 24/05/24 15:11, Dmitry Baryshkov wrote:
> > On Fri, May 24, 2024 at 03:05:08PM +0530, Jayesh Choudhary wrote:
> > > Currently, mode_valid hook returns all mode as valid and it is
> > > defined only in drm_connector_helper_funcs. With the introduction of
> > > 'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
> > > bridge_attach call for cases when the encoder has this flag enabled.
> > > So add the mode_valid hook in drm_bridge_funcs as well with proper
> > > clock checks for maximum and minimum pixel clock supported by the
> > > bridge.
> > > 
> > > Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> 
> [...]
> 
> > > +
> > >   static enum drm_mode_status sii902x_mode_valid(struct drm_connector *connector,
> > >   					       struct drm_display_mode *mode)
> > >   {
> > > -	/* TODO: check mode */
> > > +	struct sii902x *sii902x = connector_to_sii902x(connector);
> > > +	const struct drm_display_mode *mod = mode;
> > > -	return MODE_OK;
> > > +	return sii902x_validate(sii902x, mod);
> > 
> > There is no need to. The drm_bridge_chain_mode_valid() should take care
> > of calling bridge's mode_valid callback and rejecting the mode if it is
> > not accepted.
> 
> I need some clarity here.
> 
> IIRC, if the bridge does initialize the connector in case
> where the encoder does not attach the bridge with the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR (DBANC) flag (referring to tidss
> encoder before we implemented the DBANC feature), then
> drm_connector_helper_func are called and drm_bridge_funcs
> are NOT called (atleast from what I have seen in detect
> hook for cdns-mhdp-8546 driver which is there in both
> structures).

There are different kinds of bridge_funcs. detect is a part of the
connector-related interface, so it is not called by the drm core. On the
other hand functions like mode_valid, enable/disable, etc. are called
for all bridges.

> I do not have any platform to test non-DBANC encoders.
> And I did not want to break any platform that were still using
> bridge_attach without DBANC flag.
> That is why I kept mode_valid hook in both structures.
> 
> Are you implying that if connector_helper_funcs are not there
> then there will be some sort of fallback to bridge_funcs instead
> of passthrough for mode_valid check? Because that goes against my
> previous observations.

Not quite. See how drm_atomic_heler uses bridge_funcs.

-- 
With best wishes
Dmitry