On Fri, Mar 31, 2017 at 12:41:30PM +0100, Liviu Dudau wrote:

On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote:

quoted

On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:

quoted

On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:

quoted

On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:

quoted

Hi Russell,

You were Cc-ed in a patch from March 8th that did all this:

https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html

I'm aware of that (you may notice that this was threaded to that patch.)

quoted

I have not received any response from you, so I have already pushed the
patch in my public repo:

git://linux-arm.org/linux-ld.git for-upstream/hdlcd

It has been included into linux-next for at least a couple of weeks now.

I've not had a chance to test any of this, but I believe that your
patch does not fully address the issue, due to bits missing from
the validation path.

Care to point out which bits were missing from my patch that are in yours?

The visible check?

A plane's ->atomic_check() hook can be called with TEST_ONLY to figure out from
userspace if the given configuration is a valid one that can be accepted by
the hardware. There should be no error if the plane will not be visible, as we
are not programming anything yet.

I would also argue that the test that you remove and replace with state->visible
is important. We can't do *any* scaling, while with your patch we could accept
src_w != crtc_w as long as it is visible. Hardware is not capable of handling that.

That's what the "DRM_PLANE_HELPER_NO_SCALING" arguments to
drm_plane_helper_check_state() are doing:

	drm_plane_helper_check_state()
		drm_rect_calc_hscale()

		        if (hscale < min_hscale || hscale > max_hscale)
                		return -ERANGE;

		drm_rect_calc_vscale()

		        if (vscale < min_vscale || vscale > max_vscale)
                		return -ERANGE;

where DRM_PLANE_HELPER_NO_SCALING is 1.0 in 16:16 format.  So, this
ensures that the scaling factor is 1.0, returning -ERANGE if it isn't.

If this lets through a scaled source, then there's a bug that needs
fixing in the helper.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.