On Wed, 14 Feb 2024 at 21:39, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote: > > On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä > > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote: > > > > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote: > > > > > The helper drm_atomic_helper_check_plane_state() runs several checks on > > > > > plane src and dst rectangles, including the check whether required > > > > > scaling fits into the required margins. The msm driver would benefit > > > > > from having a function that does all these checks except the scaling > > > > > one. Split them into a new helper called > > > > > drm_atomic_helper_check_plane_noscale(). > > > > > > > > What's the point in eliminating a nop scaling check? > > > > > > Actually, what are you even doing in there? Are you saying that > > > the hardware has absolutely no limits on how much it can scale > > > in either direction? > > > > No, I'm just saying that the scaling ability depends on the rotation > > and other plane properties. So I had to separate the basic plane > > checks and the scaling check. > > Basic (noscale) plane check source and destination rectangles, etc. > > After that the driver identifies possible hardware pipe usage and > > after that it can perform a scaling check. > > Hmm. We have sport of similar situation in i915 where we pick a scaler > much later and so don't know the exact scaling limits at the time when > we do this check. But we opted to pass the lower/upper bounds of the > scaling limits instead. That will guarantee that at least completely > illegal values are rejected as early as possible, and so we don't have > to worry about running into them later on. Ack, I'll follow this approach then. -- With best wishes Dmitry
