[Intel-gfx] [PATCH v2] drm/i915/vlv: enable HDMI audio for Valleyview2

[Lin, Mengdong]

Hi Daniel,

Thanks for your clarification! Could you share more info ...

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Saturday, November 02, 2013 12:03 AM
> To: Lin, Mengdong
> Cc: Daniel Vetter; intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/vlv: enable HDMI audio for
> Valleyview2
> 
> On Fri, Nov 01, 2013 at 03:13:17PM +0000, Lin, Mengdong wrote:
> > > Maybe we could use the port CRC stuff to make sure that audio is
> > > actually working ...
> >
> > Would you please clarify what's port CRC stuff?
> 
> The hw has a bunch of CRC (checksum) functions. We've just enabled it at the
> pipe level, and it's extremely useful to test whether e.g. the cursor is displaying
> properly or whether it's not shown at all. We've had a few bugs where the
> cursor was disabled but shouldnt have been.
> 
> For an example of such a testcase see i-g-t/tests/kms_cursor_crc.c. This is all
> really new, so still in flux.
> 
> Now the hardware also has checksum support for each port, and afaik that
> includes the audio stream. Iirc never platforms even have special CRCs for the
> individual audio streams. My idea for a testcase would be to expose these port
> CRCs. Then check that the CRC is stable for each display frame while no audio is
> playing, and that it changes (and that the right port starts to change) once we
> play an audio stream.

What's 'IIRC never platforms'?
Where can I find more information about port or audio CRC?

In Baytrail b-spec, I saw CRCCtrlRedA-Pipe A CRC Color Channel Control Register can select source:
CRC Source Select:  These bits select the source of the data to put into the CRC logic.  
0000: Pipe A  ....
0110: DisplayPort B 
0111: DisplayPort C
1000: Audio DP (Audio for DisplayPort (pcdclk). Only select when Audio is on DisplayPort on Pipe A)
1001: Audio HDMI (Audio for HDMI (dotclock) Only select when Audio is on HDMI on Pipe A)

But I still cannot understand how to get CRC for both video and audio.
And does the CRC does not change for each display frame, even when a video is playing and pictures content change from frame to frame?
I hope to know more about how HW generates the CRC, so your info or any documentation will be appreciated.

> We can't test sync issues with that, but routing issues (which seems to have
> been the issue here, and I've also seen a few patches for routing issues in the
> past) should be testable. And with an automated testcase we can ensure that no
> regression creps in.

If the audio CRC help to check audio data arrives to the proper pipe and port, it will help to check routing issues.
> 
> The other upside of an automated test like that is that it should be easy to test
> all port combinations. That's more important for desktop platforms where we
> have 3 HDMI/DP ports.
> 
> Anyway I've just thought I'll bring this up as an idea to look into for the next hw
> enabling project. It was a bit an effort to enable pipe CRCs for display testing,
> but I think long-term it will definitely be worth it.
> So maybe poke the audio hw engineers/validation ppl a bit and inquire
> whether/how exactly they use this? We've had a display micro architect help us
> out a bit on the display side.
> 
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch