From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org, daniel.vetter@intel.com,
shobhit.kumar@intel.com
Subject: Re: [PATCH 2/2] drm/i915: Support for HDMI complaince HPD
Date: Tue, 12 Aug 2014 20:56:44 +0530 [thread overview]
Message-ID: <53EA3234.9000109@intel.com> (raw)
In-Reply-To: <20140812124741.GB21668@nuc-i3427.alporthouse.com>
Hello Chris,
Thanks for your time and comments.
I would like to give a brief history of the patch.
We tried to apply this optimization by default, and check all the EDID
read based on the live status. But not all developers agreed to have
this by default, with following reasons:
1. live_status was not very reliable for all platforms, so live_status
based solution shouldn't be added.
2. they dint want EDID caching to be by default, as few old platforms
were not even HPD capable.
So we came up with this intermediate solution to have:
1. Timeout based EDID caching, where cached EDID will be cleared after
one minute.
2. An alternative code flow to support HDMI compliance (will be based
on the live_status check, and will be only enabled for commercial
platforms like android) which need HDMI compliance support. So the
kernel command line parameter is to support the need to add this
alternative EDID read method.
Please le me know your opinion about this, considering the background.
Regards
Shashank
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 <shashank.sharma@intel.com>
>>
>> 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).
>
>> 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
>
next prev parent reply other threads:[~2014-08-12 15:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 12:38 [PATCH 0/2] HDMI detect optimization and support for HDMI compliance shashank.sharma
2014-08-12 12:38 ` [PATCH 1/2] drm/i915: Optimize HDMI EDID reads shashank.sharma
2014-08-13 12:14 ` Daniel Vetter
2014-08-14 6:15 ` Sharma, Shashank
2014-08-14 8:28 ` Daniel Vetter
2014-08-14 9:23 ` Sharma, Shashank
2014-08-14 11:57 ` Daniel Vetter
2014-08-18 3:00 ` Sharma, Shashank
2014-08-12 12:38 ` [PATCH 2/2] drm/i915: Support for HDMI complaince HPD shashank.sharma
2014-08-12 12:47 ` Chris Wilson
2014-08-12 15:26 ` Sharma, Shashank [this message]
2014-08-12 15:39 ` Chris Wilson
2014-08-13 6:04 ` Sharma, Shashank
2014-08-13 6:16 ` Chris Wilson
2014-08-13 7:42 ` Sharma, Shashank
2014-08-13 12:13 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53EA3234.9000109@intel.com \
--to=shashank.sharma@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=shobhit.kumar@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox