Hi Daniel, Thanks for your clarification! Could you share more info ... > -----Original Message----- > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter > Sent: Saturday, November 02, 2013 12:03 AM > To: Lin, Mengdong > Cc: Daniel Vetter; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
