[Intel-gfx] [PATCH 0/3] HDMI optimization series

[Sharma, Shashank]

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

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.

Regards
Shashank 
-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of Daniel Vetter
Sent: Tuesday, August 11, 2015 3:12 PM
To: Jindal, Sonika
Cc: intel-gfx at 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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx