From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Date: Wed, 15 Nov 2017 17:30:56 +0200 Message-ID: <20171115153056.GH10981@intel.com> References: <20171108152504.12596-1-ville.syrjala@linux.intel.com> <87k1z0bk4n.fsf@anholt.net> <20171108204523.GJ10981@intel.com> <87zi7ws97v.fsf@anholt.net> <20171109082612.kefdoxrr6c2dpq22@phenom.ffwll.local> <874lq3l3md.fsf@anholt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org To: neil k Cc: Eric Anholt , Daniel Vetter , Jani Nikula , intel-gfx@lists.freedesktop.org, stable@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, Nov 14, 2017 at 06:38:11PM -0500, neil k wrote: > I tested the patch from Ville Syrjälä's email and it works fine on top of > 4.14 for me. Thanks for confirming. Patch pushed to drm-misc-fixes. > > Thanks, > Neil > > On Thu, Nov 9, 2017 at 1:16 PM, Eric Anholt wrote: > > > Daniel Vetter writes: > > > > > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote: > > >> Ville Syrjälä writes: > > >> > > >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: > > >> >> Ville Syrjala writes: > > >> >> > > >> >> > From: Ville Syrjälä > > >> >> > > > >> >> > Apparently some sinks look at the YQ bits even when receiving RGB, > > >> >> > and they get somehow confused when they see a non-zero YQ value. > > >> >> > So we can't just blindly follow CEA-861-F and set YQ to match the > > >> >> > RGB range. > > >> >> > > > >> >> > Unfortunately there is no good way to tell whether the sink > > >> >> > designer claims to have read CEA-861-F. The CEA extension block > > >> >> > revision number has generally been stuck at 3 since forever, > > >> >> > and even a very recently manufactured sink might be based on > > >> >> > an old design so the manufacturing date doesn't seem like > > >> >> > something we can use. In lieu of better information let's > > >> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is > > >> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. > > >> >> > > > >> >> > The alternative would of course be to always set YQ=0. And if > > >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what > > >> >> > we'll probably have to do. > > >> >> > > >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an > > HDMI1.4 > > >> >> source? > > >> > > > >> > As long as you stick to < 340 MHz modes you shouldn't have to do > > >> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features. > > >> > > > >> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up > > >> > to bridges/encoders to filter out most things that aren't supported? > > >> > > >> I had a patch for that at > > >> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run > > >> into trouble with 4k monitors. > > > > > > Ack on the clock limiting patch, silly that it's stuck. No idea about > > CEC, > > > better for Hans/Boris I guess. > > > > Thanks! > > -- Ville Syrjälä Intel OTC