From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sharma, Shashank" Subject: Re: [PATCH 2/2] drm/i915: Support for HDMI complaince HPD Date: Wed, 13 Aug 2014 11:34:02 +0530 Message-ID: <53EAFFD2.8000004@intel.com> References: <1407847101-21654-1-git-send-email-shashank.sharma@intel.com> <1407847101-21654-3-git-send-email-shashank.sharma@intel.com> <20140812124741.GB21668@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id DAB586E52A for ; Tue, 12 Aug 2014 23:04:07 -0700 (PDT) In-Reply-To: <20140812124741.GB21668@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , intel-gfx@lists.freedesktop.org, daniel.vetter@intel.com, shobhit.kumar@intel.com List-Id: intel-gfx@lists.freedesktop.org > I know. That is orthogonal to the tweaks I was suggesting. Also if you > feel you need to add details to your rationale, then your changelog is > incomplete. > -Chris Thanks Chris, Please find my comments inline to your previous mail, with suggestions. On 8/12/2014 6:17 PM, Chris Wilson wrote: > On Tue, Aug 12, 2014 at 06:08:21PM +0530, shashank.sharma@intel.com wrote: >> From: Shashank Sharma >> >> During the HDMI complaince tests, most of the HDMI analyzers >> issue a soft HPD, to automate the tests. This process keeps >> the HDMI cable connected, and DDC chhanel alive. >> >> HDMI detect() logic relies on EDID readability, to decide if >> its a HDMI connect or disconnect event. But in this case, the >> EDID is always readable, as HDMI cable is physically connected >> and DDC channel is UP, so detect() always reports a HDMI connect >> even if its intended to be a HDMI disconnect call. >> >> So if HDMI compliance is enabled, we should rely on the live status >> register, than EDID availability. This patch adds: >> 1. One kernel command line parameter for i915 module, which indicates >> if we want to support HDMI compliance, for this platform. > > I would rather have this as an output property. In fact, I would like > the hotplug detection method exposed (and even selectable, but other > than this compliance testing, I can't think of a scenario where the > kernel shouldn't be able to figure things out for itself). Considering the history of the case, can you please elaborate this suggestion ? I dont think I am getting it right. > >> 2. A new function to read EDID, which gets called only in case of >> HDMI compliance support is required. This function reads EDID only >> if live status register is up. The normal code flow doesn't get effected >> if kernel command line parameter is not enabled. >> 3. After various experiments on VLV2 board, with various HDMI monitors >> we have seen that, with few monitors, the live status register gets >> set after a slight delay, and then stays reliably. To support such >> monitors, there is a busy-loop added, with a max delay upto 50ms, >> with a status check after every 10ms. Please see the comment in >> intel_hdmi_get_edid. > > Wouldn't a tidier solution be to delay the hpd by 50-100ms after the > hotplug interrupt? That may overcome the issue with the live status for > all connectors... > -Chris > There would be few problems in this case: 1. We dont want this scenario to come into picture for DP, as DP HPD pulse can be as small as 2ms. 2. Not all the HDMI monitors show this problem, but a significant subset of popular monitors do. 3. In HDCP compliance testing, we send a HPD pulse train of UP and Down, where down pulse can be as small as 100ms. If we increase the delay by 100ms, we will definitely miss the HPD down pulse. 4. The method what we are using is a busy waiting check, where we delay the pulse for 50ms, but take a sample of live_status per 10ms, so if the live status is up with a delay of 20ms, we needn't to waste another 30. 5. We want this code routine only to be executed for commercial (like android) platforms, whereas others get the routine code. @ Danvet: Do you want to add something here ? Regards Shashank