From: Daniel Vetter <daniel@ffwll.ch>
To: "Sharma, Shashank" <shashank.sharma@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/3] HDMI optimization series
Date: Wed, 12 Aug 2015 14:25:25 +0200 [thread overview]
Message-ID: <20150812122524.GC17734@phenom.ffwll.local> (raw)
In-Reply-To: <FF3DDC77922A8A4BB08A3BC48A1EA8CB099D3667@BGSMSX101.gar.corp.intel.com>
On Tue, Aug 11, 2015 at 11:03:54AM +0000, Sharma, Shashank wrote:
> HI Daniel,
>
> Looks like we are not getting an IVB machine here. I think instead of blocking the patch set for the whole series, we can just block it for the platforms we don’t get success for.
> We are shipping many VLV/CHV systems with these patches applied, and they are passing all Android test suits and test benches, so we don’t doubt the solution as such.
>
> We have done testing for following platforms (gen 9 is tested by Imre also):
> 1. CHV / BSW
> 2. SKL
> 3. BXT
> 4. BDW
I know that it works on piles of other platforms too. The problem is
figuring out why it doesn't work on some and what we're doing wrong.
> Why don’t we go ahead with this solution for gen 8 onwards, and keep the
> rest of the code un touched, this will serve both the purpose.
I guess we can, but if we get a regression report on bdw because of this
I'll be furious.
-Daniel
>
> Regards
> Shashank
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Daniel Vetter
> Sent: Tuesday, August 11, 2015 3:12 PM
> To: Jindal, Sonika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series
>
> On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote:
> >
> >
> > On 8/10/2015 1:38 PM, Daniel Vetter wrote:
> > >On Mon, Aug 10, 2015 at 04:50:37AM +0000, Jindal, Sonika wrote:
> > >>Hi Daniel,
> > >>
> > >>That patch was already merged:
> > >>http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.htm
> > >>l
> > >>
> > >>For SKL, the above patch helped in getting the correct ISR bits set.
> > >>One option is to enable the HDMI optimization from VLV onwards.
> > >>I don't have an ivb machine to try out the issue.
> > >
> > >ivb is simple the machine I have here, but when we tried this the
> > >last time around we had reports for all platforms (your patch still
> > >doesn't cite the relevant sha1 btw). I think there are 3 possible explanations:
> > >
> > Yes, I don't know which were those patches and how to find them..
>
> git blame (recursively) and git log on intel_hdmi.c will tell you the story. I require all these extensive git commit messages because I dig them out daily. Also git log --pickaxe (well I use the equivalent in the gitk gui). If these tools are generally unknown in the vpg display team then we absolutely need to do a training session about them, they're extremely powerful and useful to dig out the history of the i915 code.
>
> > >a) we do something wrong with hpd handling on these platforms. That
> > >seems to be the explanation you favour (with the gen >= 7 checks and
> > >all that), but I think it's very unlikely: On each platform where we
> > >had reports of hpd being broken there was also machines where hpd works perfectly fine.
> > >
> > Not sure, I will find one ivb system and try on that.
> >
> > >b) There's broken HDMI (or DVI) sinks out there. If that's the case
> > >we can never merge your patch.
> > I doubt this because we have tested these patches with many sinks in
> > the past with VLV/CHV.
> > >
> > >c) There's something in vbt or somewhere else that tells the windows
> > >driver whether using hpd or not is ok (and the hpd problem is
> > >actually an issue with certain OEM machines ...).
> > >
> > No, nothing like that.
> >
> > >I hoped that with your hpd handling fix we'd have some indication
> > >that our hpd troubles are of type a). But since I tested with your
> > >patch that didn't work out.
> > >
> > >And until we have some evidence that our hpd troubles aren't type b)
> > >I really don't want to merge any patch which relies upon hpd bits for hdmi.
> > >-Daniel
> > >
> > I will try on ivb.
>
> I don't think it's ivb specific, since we do have ivb machines where hpd works perfectly fine. Same for every other platform. The only thing which seems common is that DP+ connectors work, but some of the hdmi-only connectors fail. That's why I wondered whether there's something i915 does different than the windows driver. In case you can get hold of one, the broken laptop I have here is an Asus UX31A with ivb.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-08-12 12:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 11:51 [PATCH 0/3] HDMI optimization series Sonika Jindal
2015-07-14 11:51 ` [PATCH 1/3] drm/i915: add attached connector to hdmi container Sonika Jindal
2015-07-14 11:51 ` [PATCH 2/3] drm/i915: Add HDMI probe function Sonika Jindal
2015-07-14 11:51 ` [PATCH 3/3] drm/i915: Check live status before reading edid Sonika Jindal
2015-07-14 14:29 ` Imre Deak
2015-07-15 3:55 ` Jindal, Sonika
2015-08-05 10:02 ` Imre Deak
2015-08-10 5:44 ` Sivakumar Thulasimani
2015-08-17 5:39 ` Jindal, Sonika
2015-08-07 13:23 ` [PATCH 0/3] HDMI optimization series Daniel Vetter
2015-08-10 4:50 ` Jindal, Sonika
2015-08-10 8:08 ` Daniel Vetter
2015-08-10 8:35 ` Jindal, Sonika
2015-08-11 9:41 ` Daniel Vetter
2015-08-11 11:03 ` Sharma, Shashank
2015-08-12 12:25 ` Daniel Vetter [this message]
2015-08-12 12:34 ` Sharma, Shashank
2015-08-12 12:40 ` Daniel Vetter
2015-08-12 12:46 ` Sharma, Shashank
2015-08-12 11:55 ` David Weinehall
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=20150812122524.GC17734@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=shashank.sharma@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