On Wed, 02 Sep 2015, "Yang, Libin" <libin.yang@xxxxxxxxx> wrote: > Hi Jani, > >> -----Original Message----- >> From: Jani Nikula [mailto:jani.nikula@xxxxxxxxxxxxxxx] >> Sent: Wednesday, September 02, 2015 3:52 PM >> To: Yang, Libin; alsa-devel@xxxxxxxxxxxxxxxx; tiwai@xxxxxxx; intel- >> gfx@xxxxxxxxxxxxxxxxxxxxx; daniel.vetter@xxxxxxxx; >> ville.syrjala@xxxxxxxxxxxxxxx >> Cc: Yang, Libin >> Subject: Re: [PATCH v6 2/4] drm/i915: implement sync_audio_rate >> callback >> >> On Wed, 02 Sep 2015, libin.yang@xxxxxxxxx wrote: >> > From: Libin Yang <libin.yang@xxxxxxxxx> >> > >> > HDMI audio may not work at some frequencies >> > with the HW provided N/CTS. >> > >> > This patch sets the proper N value for the >> > given audio sample rate at the impacted frequencies. >> > At other frequencies, it will use the N/CTS value >> > which HW provides. >> > >> > Signed-off-by: Libin Yang <libin.yang@xxxxxxxxx> >> >> Okay, so there are a number of questions and comments this patch still >> raises. Please find them inline. >> >> *However*, we should really get this finally moving forward, and I >> don't >> think the issues are or need to be blockers, so this is >> >> Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> >> >> I think we (as in i915 folks) can clean the rest of the bikeshedding up, >> and I don't think we should be NAKing this ad infinitum to teach you to >> become an i915 developer... unless you want to be one. ;) Libin, I suggest taking that R-b now instead of writing a new version of this patch if you want to get things upstreamed! Please focus on patch 4. BR, Jani. >> >> > --- >> > drivers/gpu/drm/i915/i915_dma.c | 1 + >> > drivers/gpu/drm/i915/i915_drv.h | 5 ++ >> > drivers/gpu/drm/i915/intel_audio.c | 138 >> +++++++++++++++++++++++++++++++++++++ >> > 3 files changed, 144 insertions(+) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_dma.c >> b/drivers/gpu/drm/i915/i915_dma.c >> > index 097d4ba..8ffb5dc 100644 >> > --- a/drivers/gpu/drm/i915/i915_dma.c >> > +++ b/drivers/gpu/drm/i915/i915_dma.c >> > @@ -858,6 +858,7 @@ int i915_driver_load(struct drm_device *dev, >> unsigned long flags) >> > mutex_init(&dev_priv->sb_lock); >> > mutex_init(&dev_priv->modeset_restore_lock); >> > mutex_init(&dev_priv->csr_lock); >> > + mutex_init(&dev_priv->av_mutex); >> > >> > intel_pm_setup(dev); >> > >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h >> b/drivers/gpu/drm/i915/i915_drv.h >> > index 05ffd5a..2c6b76f 100644 >> > --- a/drivers/gpu/drm/i915/i915_drv.h >> > +++ b/drivers/gpu/drm/i915/i915_drv.h >> > @@ -1882,6 +1882,11 @@ struct drm_i915_private { >> > >> > /* hda/i915 audio component */ >> > bool audio_component_registered; >> > + /** >> > + * av_mutex - mutex for audio/video sync >> > + * >> > + */ >> > + struct mutex av_mutex; >> > >> > uint32_t hw_context_size; >> > struct list_head context_list; >> > diff --git a/drivers/gpu/drm/i915/intel_audio.c >> b/drivers/gpu/drm/i915/intel_audio.c >> > index dc32cf4..a021720 100644 >> > --- a/drivers/gpu/drm/i915/intel_audio.c >> > +++ b/drivers/gpu/drm/i915/intel_audio.c >> > @@ -68,6 +68,31 @@ static const struct { >> > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 }, >> > }; >> > >> > +/* HDMI N/CTS table */ >> > +#define TMDS_297M 297000 >> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001) >> > +static const struct { >> > + int sample_rate; >> > + int clock; >> > + int n; >> > + int cts; >> > +} aud_ncts[] = { >> > + { 44100, TMDS_296M, 4459, 234375 }, >> > + { 44100, TMDS_297M, 4704, 247500 }, >> > + { 48000, TMDS_296M, 5824, 281250 }, >> > + { 48000, TMDS_297M, 5120, 247500 }, >> > + { 32000, TMDS_296M, 5824, 421875 }, >> > + { 32000, TMDS_297M, 3072, 222750 }, >> > + { 88200, TMDS_296M, 8918, 234375 }, >> > + { 88200, TMDS_297M, 9408, 247500 }, >> > + { 96000, TMDS_296M, 11648, 281250 }, >> > + { 96000, TMDS_297M, 10240, 247500 }, >> > + { 176400, TMDS_296M, 17836, 234375 }, >> > + { 176400, TMDS_297M, 18816, 247500 }, >> > + { 192000, TMDS_296M, 23296, 281250 }, >> > + { 192000, TMDS_297M, 20480, 247500 }, >> > +}; >> >> Okay, I admit, I did not look these up in the spec. *blush*. I'm sure >> Ville has/will. ;) >> >> > + >> > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */ >> > static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode >> *mode) >> > { >> > @@ -90,6 +115,31 @@ static u32 >> audio_config_hdmi_pixel_clock(struct drm_display_mode *mode) >> > return hdmi_audio_clock[i].config; >> > } >> > >> > +static int audio_config_get_n(const struct drm_display_mode >> *mode, int rate) >> > +{ >> > + int i; >> > + >> > + for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) { >> > + if ((rate == aud_ncts[i].sample_rate) && >> > + (mode->clock == aud_ncts[i].clock)) { >> > + return aud_ncts[i].n; >> > + } >> > + } >> > + return 0; >> > +} >> > + >> > +/* check whether N/CTS/M need be set manually */ >> > +static bool audio_rate_need_prog(struct intel_crtc *crtc, >> > + struct drm_display_mode >> *mode) >> > +{ >> > + if (((mode->clock == TMDS_297M) || >> > + (mode->clock == TMDS_296M)) && >> > + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI)) >> > + return true; >> > + else >> > + return false; >> > +} >> > + >> > static bool intel_eld_uptodate(struct drm_connector *connector, >> > int reg_eldv, uint32_t bits_eldv, >> > int reg_elda, uint32_t bits_elda, >> > @@ -184,6 +234,8 @@ static void hsw_audio_codec_disable(struct >> intel_encoder *encoder) >> > >> > DRM_DEBUG_KMS("Disable audio codec on pipe %c\n", >> pipe_name(pipe)); >> > >> > + mutex_lock(&dev_priv->av_mutex); >> > + >> >> Bikeshed. We should think about moving the locking to >> intel_audio_codec_enable and intel_audio_codec_disable for >> consistency. We'll be adding new platform hooks eventually anyway, >> no >> need to duplicate the locking everywhere. > > Yes, at first, I want to add the mutex in intel_audio_codec_enable, > but after a second thought, we don't need it for ilk_xxx and g4x_xxx, > so I moved the lock in the hsw specific function for efficiency. > > I will move it to intel_audio_codec_enable in next version. > >> >> > /* Disable timestamps */ >> > tmp = I915_READ(HSW_AUD_CFG(pipe)); >> > tmp &= ~AUD_CONFIG_N_VALUE_INDEX; >> > @@ -199,6 +251,8 @@ static void hsw_audio_codec_disable(struct >> intel_encoder *encoder) >> > tmp &= ~AUDIO_ELD_VALID(pipe); >> > tmp &= ~AUDIO_OUTPUT_ENABLE(pipe); >> > I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp); >> > + >> > + mutex_unlock(&dev_priv->av_mutex); >> > } >> > >> > static void hsw_audio_codec_enable(struct drm_connector >> *connector, >> > @@ -215,6 +269,8 @@ static void hsw_audio_codec_enable(struct >> drm_connector *connector, >> > DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes >> ELD\n", >> > pipe_name(pipe), drm_eld_size(eld)); >> > >> > + mutex_lock(&dev_priv->av_mutex); >> > + >> > /* Enable audio presence detect, invalidate ELD */ >> > tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD); >> > tmp |= AUDIO_OUTPUT_ENABLE(pipe); >> > @@ -253,6 +309,8 @@ static void hsw_audio_codec_enable(struct >> drm_connector *connector, >> > else >> > tmp |= audio_config_hdmi_pixel_clock(mode); >> > I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> > + >> > + mutex_unlock(&dev_priv->av_mutex); >> > } >> > >> > static void ilk_audio_codec_disable(struct intel_encoder *encoder) >> > @@ -514,12 +572,92 @@ static int >> i915_audio_component_get_cdclk_freq(struct device *dev) >> > return ret; >> > } >> > >> > +static int i915_audio_component_sync_audio_rate(struct device >> *dev, >> > + int port, int rate) >> > +{ >> > + struct drm_i915_private *dev_priv = dev_to_i915(dev); >> > + struct drm_device *drm_dev = dev_priv->dev; >> > + struct intel_encoder *intel_encoder; >> > + struct intel_digital_port *intel_dig_port; >> > + struct intel_crtc *crtc; >> > + struct drm_display_mode *mode; >> > + enum pipe pipe = -1; >> >> Nitpick. Initialize to INVALID_PIPE. > > Oh, yes, I will change it. > >> >> > + u32 tmp; >> > + int n_low, n_up, n; >> > + >> > + /* HSW, BDW SKL need this fix */ >> > + if (!IS_SKYLAKE(dev_priv) && >> > + !IS_BROADWELL(dev_priv) && >> > + !IS_HASWELL(dev_priv)) >> > + return 0; >> >> Nitpick. We should elaborate that a bit more. Is it basically that only >> the above platforms support HDMI mode and audio sample rate >> combinations >> that the automatic mode in hardware can't support? In other words, >> would >> audio_rate_need_prog() always return false on other platforms than >> hsw/bdw/skl? And if so, why do we have this check? Perhaps we >> should >> take care to make audio_rate_need_prog() do the right thing, and do >> that >> as the first thing here. > > I add this judgement because the platforms are filed in our > internal document. Besides, the next gen may have such > issue and may not (the doc said MAY have such issue). > For easily extension, I add such judgement. > > audio_rate_need_prog() means the specified clock need > such setting. But I'm not sure whether other old platforms > support such clock. If yes, the audio_rate_need_prog() > may be not enough. Although I think doing the setting > should be OK even on the platforms not listed in the doc. > But I have no platform to do the test, so I didn't include > other platform this time. > >> >> > + >> > + mutex_lock(&dev_priv->av_mutex); >> > + /* 1. get the pipe */ >> > + for_each_intel_encoder(drm_dev, intel_encoder) { >> > + if (intel_encoder->type != INTEL_OUTPUT_HDMI) >> > + continue; >> > + intel_dig_port = enc_to_dig_port(&intel_encoder- >> >base); >> > + if (port == intel_dig_port->port) { >> > + crtc = to_intel_crtc(intel_encoder->base.crtc); >> > + if (!crtc) { >> > + DRM_DEBUG_KMS("%s: crtc is >> NULL\n", __func__); >> >> DRM_DEBUG_KMS includes __func__ already. > > I will change it in next version. Thanks. >> >> > + continue; >> > + } >> > + pipe = crtc->pipe; >> > + break; >> > + } >> > + } >> > + >> > + if (pipe == INVALID_PIPE) { >> > + DRM_DEBUG_KMS("no pipe for the port %c\n", >> port_name(port)); >> > + mutex_unlock(&dev_priv->av_mutex); >> > + return -ENODEV; >> >> Nitpick. I am not fond of early returns when cleanup like mutex unlock >> is required. The function should have goto labels at the end with >> cleanup. (OTOH if we move locking to higher level this problem goes >> away.) > > OK, so it seems to move the lock in upper function is an easy > way. I will move the lock in the upper function. > >> >> > + } >> > + DRM_DEBUG_KMS("pipe %c connects port %c\n", >> > + pipe_name(pipe), port_name(port)); >> > + mode = &crtc->config->base.adjusted_mode; >> > + >> > + /* 2. check whether to set the N/CTS/M manually or not */ >> > + if (!audio_rate_need_prog(crtc, mode)) { >> > + tmp = I915_READ(HSW_AUD_CFG(pipe)); >> > + tmp &= ~AUD_CONFIG_N_PROG_ENABLE; >> > + I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> > + mutex_unlock(&dev_priv->av_mutex); >> > + return 0; >> >> Nitpick. Same here, you could have an auto: label at the end with the >> auto programming... >> >> > + } >> > + >> > + n = audio_config_get_n(mode, rate); >> > + if (n == 0) { >> > + DRM_DEBUG_KMS("Using automatic mode for N value >> on port %c\n", >> > + port_name(port)); >> > + tmp = I915_READ(HSW_AUD_CFG(pipe)); >> > + tmp &= ~AUD_CONFIG_N_PROG_ENABLE; >> > + I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> > + mutex_unlock(&dev_priv->av_mutex); >> > + return 0; >> >> ...especially because this bit is duplicated for no good reason. >> >> Fallback to auto mode if the mode isn't in the list is, I think, a good >> thing. Maybe it would deserve a DRM_ERROR, because clearly that >> shouldn't happen. > > OK, I will add auto label for it. And I will use DRM_ERROR in next > version. > >> >> But it's actually the !audio_rate_need_prog case that makes me >> wonder. I >> think we've confirmed with the silicon folks that we can change N on >> the >> fly... but I'm actually not sure if we've confirmed that we can switch >> between automatic and manual modes on the fly. I think I've said it >> before, but I think I'd prefer it if we always used the manual mode >> anyway to reduce the complexity and have only one code path to >> debug, >> and that would also cover the somewhat of a corner case (but still real >> case) of switching between automatic/manual modes on the fly. And >> of >> course, this conflicts with what I said about the platform support check >> above, so needs thought. > > I will check with silicon team. Based on our stress test, it seems > to be OK change mode on the fly. > > We don't set for all the frequencies because there are so many > frequencies and platforms to do the stress test. We may need > a lot time to do the test. If the silicon team says we can't > change mode on the fly, I will change it in next version. If silicon > team says we can do it, I will use the HW auto mode for other > frequencies. What do you think? > > Regards, > Libin > >> >> > + } >> > + n_low = n & 0xfff; >> > + n_up = (n >> 12) & 0xff; >> > + >> > + /* 4. set the N/CTS/M */ >> > + tmp = I915_READ(HSW_AUD_CFG(pipe)); >> > + tmp &= ~(AUD_CONFIG_UPPER_N_MASK | >> AUD_CONFIG_LOWER_N_MASK); >> > + tmp |= ((n_up << AUD_CONFIG_UPPER_N_SHIFT) | >> > + (n_low << AUD_CONFIG_LOWER_N_SHIFT) | >> > + AUD_CONFIG_N_PROG_ENABLE); >> > + I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> > + >> > + mutex_unlock(&dev_priv->av_mutex); >> > + return 0; >> > +} >> > + >> > static const struct i915_audio_component_ops >> i915_audio_component_ops = { >> > .owner = THIS_MODULE, >> > .get_power = i915_audio_component_get_power, >> > .put_power = i915_audio_component_put_power, >> > .codec_wake_override = >> i915_audio_component_codec_wake_override, >> > .get_cdclk_freq = i915_audio_component_get_cdclk_freq, >> > + .sync_audio_rate = i915_audio_component_sync_audio_rate, >> > }; >> > >> > static int i915_audio_component_bind(struct device *i915_dev, >> > -- >> > 1.9.1 >> > >> >> -- >> Jani Nikula, Intel Open Source Technology Center -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
