| Message ID | E1cttDZ-000671-Q1@rmk-PC.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 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. Best regards, Liviu On Fri, Mar 31, 2017 at 10:51:41AM +0100, Russell King wrote: > The hdlcd crtc is unable to place planes in arbitary positions and sizes > within the active area. Use drm_plane_helper_check_state() to validate > the requested state. > > Suggested-by: Daniel Vetter <daniel@ffwll.ch> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > --- > drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++++++++++++++++++++++----- > 1 file changed, 23 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c > index 7d4e5aa77195..ba68fa2b5701 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -10,6 +10,7 @@ > */ > > #include <drm/drmP.h> > +#include <drm/drm_atomic.h> > #include <drm/drm_atomic_helper.h> > #include <drm/drm_crtc.h> > #include <drm/drm_crtc_helper.h> > @@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = { > static int hdlcd_plane_atomic_check(struct drm_plane *plane, > struct drm_plane_state *state) > { > - u32 src_w, src_h; > + struct drm_crtc_state *crtc_state; > + struct drm_crtc *crtc; > + struct drm_rect clip = { 0 }; > + int ret; > + > + crtc = state->crtc; > + if (!crtc) > + return 0; > > - src_w = state->src_w >> 16; > - src_h = state->src_h >> 16; > + crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc); > + if (!crtc_state->enable) > + return -EINVAL; > + > + clip.x2 = crtc_state->adjusted_mode.hdisplay; > + clip.y2 = crtc_state->adjusted_mode.vdisplay; > + > + ret = drm_plane_helper_check_state(state, &clip, > + DRM_PLANE_HELPER_NO_SCALING, > + DRM_PLANE_HELPER_NO_SCALING, > + false, true); > + if (ret) > + return ret; > > - /* we can't do any scaling of the plane source */ > - if ((src_w != state->crtc_w) || (src_h != state->crtc_h)) > + if (!state->visible) > return -EINVAL; > > return 0; > -- > 2.7.4 >
On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > 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.) > 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.
On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote: > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > > 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.) > > > 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? Best regards, Liviu > > -- > 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.
On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote: > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote: > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > > > 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.) > > > > > 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?
On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote: > On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote: > > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote: > > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > > > > 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.) > > > > > > > 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. Best regards, Liviu > > -- > 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.
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: > > On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote: > > > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote: > > > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > > > > > 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.) > > > > > > > > > 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.
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index 7d4e5aa77195..ba68fa2b5701 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -10,6 +10,7 @@ */ #include <drm/drmP.h> +#include <drm/drm_atomic.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_crtc.h> #include <drm/drm_crtc_helper.h> @@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = { static int hdlcd_plane_atomic_check(struct drm_plane *plane, struct drm_plane_state *state) { - u32 src_w, src_h; + struct drm_crtc_state *crtc_state; + struct drm_crtc *crtc; + struct drm_rect clip = { 0 }; + int ret; + + crtc = state->crtc; + if (!crtc) + return 0; - src_w = state->src_w >> 16; - src_h = state->src_h >> 16; + crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc); + if (!crtc_state->enable) + return -EINVAL; + + clip.x2 = crtc_state->adjusted_mode.hdisplay; + clip.y2 = crtc_state->adjusted_mode.vdisplay; + + ret = drm_plane_helper_check_state(state, &clip, + DRM_PLANE_HELPER_NO_SCALING, + DRM_PLANE_HELPER_NO_SCALING, + false, true); + if (ret) + return ret; - /* we can't do any scaling of the plane source */ - if ((src_w != state->crtc_w) || (src_h != state->crtc_h)) + if (!state->visible) return -EINVAL; return 0;
The hdlcd crtc is unable to place planes in arbitary positions and sizes within the active area. Use drm_plane_helper_check_state() to validate the requested state. Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> --- drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-)