From: Wang Xingchao <xingchao.wang@intel.com>
To: Imre Deak <imre.deak@gmail.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization
Date: Thu, 16 Aug 2012 11:45:32 +0800 [thread overview]
Message-ID: <20120816034532.GA2517@wxc-intel> (raw)
In-Reply-To: <CAMDDuauzDRTmO-U8-qS1TqCwMbcKmacd0KdLiPm03rN9+wiH+A@mail.gmail.com>
On Wed, Aug 15, 2012 at 08:05:14PM +0300, Imre Deak wrote:
> On Wed, Aug 15, 2012 at 6:27 AM, Wang, Xingchao <xingchao.wang@intel.com> wrote:
> > Hi Daniel/Imre,
> >
> > This revised version changelog:
> > - add " Wait for 1 vertical blank" after enable audio output port
> > - configure pipe related transcoder instead of operate all transcoders blindly
>
> Thanks for the explanation. I'd have still a couple of questions inlined:
>
> >
> >> +
> >> + /* Audio output enable */
> >> + DRM_DEBUG_DRIVER("HDMI audio: enable codec\n");
> >> + tmp = I915_READ(aud_cntrl_st2);
> >> + tmp |= (AUDIO_OUTPUT_ENABLE_A | AUDIO_OUTPUT_ENABLE_B |
> >> AUDIO_OUTPUT_ENABLE_C);
>
> The output bits are also transcoder specific, so why don't we enable
> only the required output?
> I.e. similarly as you do below tmp |= AUDIO_OUTPUT_ENABLE_A << (pipe *
> 4);. Otherwise
> this function will leave also unrelated outputs enabled which is not
> that nice power
> management-wise.
Thanks, makes sense. :)
I left the code without change because as the Audio enable sequence
description, there's no particular requirement to set the bit based on which
transcoder would be used. So i just enable *ALL* transcoders. Anyway your
suggestion makes sense, i should only enable the related transcoder. Wil make
that change in next version.
>
> >> + I915_WRITE(aud_cntrl_st2, tmp);
> >> +
> >> + /* Wait for 1 vertical blank */
> >> + intel_wait_for_vblank(dev, pipe);
> >> +
> >> + /* Set ELD valid state */
> >> + tmp = I915_READ(aud_cntrl_st2);
> >> + DRM_DEBUG_DRIVER("HDMI audio: pin eld vld status=0x%8x\n", tmp);
> >> + tmp |= (AUDIO_ELD_VALID_A << (pipe * 4));
> >> + I915_WRITE(aud_cntrl_st2, tmp);
> >> + tmp = I915_READ(aud_cntrl_st2);
> >> + DRM_DEBUG_DRIVER("HDMI audio: eld vld status=0x%8x\n", tmp);
> >> +
> >> + /* Enable HDMI mode */
> >> + tmp = I915_READ(aud_config);
> >> + DRM_DEBUG_DRIVER("HDMI audio: audio conf: 0x%8x\n", tmp);
> >> + /* clear N_programing_enable and N_value_index */
> >> + tmp &= ~(AUD_CONFIG_N_VALUE_INDEX |
> >> AUD_CONFIG_N_PROG_ENABLE);
> >> + I915_WRITE(aud_config, tmp);
> >> +
> >> + DRM_DEBUG_DRIVER("ELD on pipe %c\n", pipe_name(pipe));
> >> +
> >> + i = I915_READ(aud_cntl_st);
> >> + i = (i >> 29) & DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1 =
> >> PortB */
> >> + if (!i) {
> >> + DRM_DEBUG_DRIVER("Audio directed to unknown port\n");
> >> + /* operate blindly on all ports */
> >> + eldv = AUDIO_ELD_VALID_A;
> >> + eldv |= AUDIO_ELD_VALID_B;
> >> + eldv |= AUDIO_ELD_VALID_C;
> >> + } else {
> >> + DRM_DEBUG_DRIVER("ELD on port %c\n", 'A' + i);
> >> + eldv = AUDIO_ELD_VALID_A << ((i - 1) * 4);
> >> + }
>
> Again, if we handle the ELD_VALID bits on a transcoder basis, as above
> when enabling and
> disabling it, why are we doing it here differently, on a port basis?
A bit different. These bits[30:29] reflects which port is used to transmit DIP
data. It's configured in other register, see PIPE_DDI_FUNC_CTL, that
determines which DDI port would be combined with current pipe. I think it's
also transcoder basis. please note aud_cntl_st is also "pipe" based.
> This should read then just
> as above eldv = AUDIO_ELD_VALID_A << (pipe * 4);
>
> As a sidenote I guess at the moment due to the bug you mentioned
> DIP_PORT_SEL will
> always read 0, hence the else branch never runs and we just enable
> blindly all valid bits.
>
> --Imre
next prev parent reply other threads:[~2012-08-16 3:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 3:11 [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization Wang Xingchao
2012-08-15 3:27 ` Wang, Xingchao
2012-08-15 17:05 ` Imre Deak
2012-08-16 3:45 ` Wang Xingchao [this message]
2012-08-16 10:54 ` Imre Deak
2012-08-16 13:23 ` Wang, Xingchao
2012-08-16 13:36 ` Imre Deak
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=20120816034532.GA2517@wxc-intel \
--to=xingchao.wang@intel.com \
--cc=imre.deak@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
/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