From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/7] drm: Don't overwrite UNVERFIED mode status to OK Date: Fri, 4 Dec 2015 09:17:28 +0100 Message-ID: <20151204081728.GX10243@phenom.ffwll.local> References: <1449177255-9515-1-git-send-email-ville.syrjala@linux.intel.com> <1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com> Sender: stable-owner@vger.kernel.org To: ville.syrjala@linux.intel.com Cc: dri-devel@lists.freedesktop.org, stable@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On Thu, Dec 03, 2015 at 11:14:09PM +0200, ville.syrjala@linux.intel.com= wrote: > From: Ville Syrj=E4l=E4 >=20 > The way the mode probing works is this: > 1. All modes currently on the mode list are marked as UNVERIFIED > 2. New modes are on the probed_modes list (they start with > status OK) > 3. Modes are moved from the probed_modes list to the actual > mode list. If a mode already on the mode list is deemed > to match one of the probed modes, the duplicate is dropped > and the mode status updated to OK. After this the > probed_modes list will be empty. > 4. All modes on the mode list are verified to not violate any > constraints. Any that do are marked as such. > 5. Any mode left with a non-OK status is pruned from the list, > with an appropriate debug message. This would look really pretty as a kerneldoc addition to probe_single_connector(). And with asciidoc we can even do pretty order= ed lists like these. Can you please follow-up with a patch for that? >=20 > What all this means is that any mode on the original list that > didn't have a duplicate on the probed_modes list, should be left > with status UNVERFIED (or previously could have been left with > some other status, but never OK). >=20 > I broke that in > commit 05acaec334fc ("drm: Reorganize probed mode validation") > by always assigning something to the mode->status during the validati= on > step. So any mode from the old list that still passed the validation > would be left on the list with status OK in the end. >=20 > Fix this by not doing the basic mode validation unless the mode > already has status OK (meaning it came from the probed_modes list, > or at least a duplicate of it was on that list). This way we will > correctly prune away any mode from the old mode list that didn't > appear on the probed_modes list. >=20 > Cc: stable@vger.kernel.org > Cc: Adam Jackson > Fixes: 05acaec334fc ("drm: Reorganize probed mode validation") > Signed-off-by: Ville Syrj=E4l=E4 Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_probe_helper.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm= _probe_helper.c > index 94ba39e34299..b9b3bd9349ff 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -229,7 +229,8 @@ static int drm_helper_probe_single_connector_mode= s_merge_bits(struct drm_connect > mode_flags |=3D DRM_MODE_FLAG_3D_MASK; > =20 > list_for_each_entry(mode, &connector->modes, head) { > - mode->status =3D drm_mode_validate_basic(mode); > + if (mode->status =3D=3D MODE_OK) > + mode->status =3D drm_mode_validate_basic(mode); > =20 > if (mode->status =3D=3D MODE_OK) > mode->status =3D drm_mode_validate_size(mode, maxX, maxY); > --=20 > 2.4.10 >=20 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch