From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Kleiner Subject: Re: [PATCH 1/2] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown" Date: Tue, 14 Jun 2016 16:12:03 +0200 Message-ID: <576010B3.4020904@gmail.com> References: <1464273544-23834-1-git-send-email-mario.kleiner.de@gmail.com> <1464273544-23834-2-git-send-email-mario.kleiner.de@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: stable-owner@vger.kernel.org To: Daniel Vetter Cc: dri-devel , stable , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Mario Kleiner List-Id: dri-devel@lists.freedesktop.org On 06/14/2016 01:05 PM, Daniel Vetter wrote: > On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner > wrote: >> This reverts commit 013dd9e03872 >> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown") >> >> This commit introduced a regression into stable kernels, >> as it reduces output color depth to 6 bpc for any video >> sink connected to a Displayport connector if that sink >> doesn't report a specific color depth via EDID, or if >> our EDID parser doesn't actually recognize the proper >> bpc from EDID. >> >> Affected are active DisplayPort->VGA converters and >> active DisplayPort->DVI converters. Both should be >> able to handle 8 bpc, but are degraded to 6 bpc with >> this patch. >> >> The reverted commit was meant to fix >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=3D105331 >> >> A followup patch implements a fix for that specific bug, >> which is caused by a faulty EDID of the affected DP panel >> by adding a new EDID quirk for that panel. >> >> DP 18 bpp fallback handling and other improvements to >> DP sink bpc detection will be handled for future >> kernels in a separate series of patches. >> >> Please backport to stable. >> >> Signed-off-by: Mario Kleiner >> Acked-by: Jani Nikula >> Cc: stable@vger.kernel.org >> Cc: Ville Syrj=C3=A4l=C3=A4 >> Cc: Daniel Vetter > > I wonder whether we shouldn't just move this into the DP code, and > instead of looking at the edid (which is just pass-through for dp->vg= a > dongles) we should only look at dpcd values? Or maybe only look at th= e > edid value if the sink is native DP, and not when it's a dongle. > > That would probably also avoid the quirk, and that quirk seems a bit = fishy. > -Daniel > This patch is just a simple fix for the color depth regression which=20 affects stable kernels. It can be back-ported easily to affected stable= =20 kernels, as Jani advised me. I wanted to clean up and resubmit that DP helper function which looks a= t=20 dpcd values and might be a bit too much for stable, once this fix is in= =2E -mario