From: Daniel Vetter <daniel@ffwll.ch>
To: "Lin, Mengdong" <mengdong.lin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2] drm/i915/vlv: enable HDMI audio for Valleyview2
Date: Fri, 1 Nov 2013 17:02:32 +0100 [thread overview]
Message-ID: <20131101160232.GL4167@phenom.ffwll.local> (raw)
In-Reply-To: <F46914AEC2663F4A9BB62374E5EEF8F8013DFAB8@SHSMSX101.ccr.corp.intel.com>
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.
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.
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
next prev parent reply other threads:[~2013-11-01 16:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-23 23:08 [PATCH v2] drm/i915/vlv: enable HDMI audio for Valleyview2 mengdong.lin
2013-10-27 13:58 ` Daniel Vetter
2013-11-01 15:13 ` Lin, Mengdong
2013-11-01 16:02 ` Daniel Vetter [this message]
2013-11-05 5:34 ` Lin, Mengdong
2013-11-05 6:56 ` 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=20131101160232.GL4167@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mengdong.lin@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