On Wed, 03 Feb 2016, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > On Wed, 03 Feb 2016, Ramalingam C <ramalingam.c@xxxxxxxxx> wrote: >> On Wednesday 03 February 2016 02:27 PM, Jani Nikula wrote: >>> On Tue, 02 Feb 2016, Ramalingam C <ramalingam.c@xxxxxxxxx> wrote: >>>> From: "Kumar, Mahesh" <mahesh1.kumar@xxxxxxxxx> >>>> >>>> We are re-using Mipi encoder enabled by GOP driver, but not incrementing >>>> reference count for Audio Power domain, so audio was not working. This >>>> patch increments the reference count during DSI init and Adds get/put in >>>> DSI enable/disable functions as well so audio power domain will be on >>>> when mipi is in use. >>> Confused. DSI does not have HD audio. The codec enable calls are no-ops >>> because DSI does not have EDID and therefore no ELD either. Hopefully >>> the codec disable calls don't mess up things by accident. We don't need >>> or want those calls in DSI. >>> >>> IMO the DSI encoder should not get/put the audio power domain either, >>> because DSI simply does not use that. >>> >>> The question remains, *what* audio was failing? DP/HDMI audio? >> Since HDMI and DP has the audio we are handling the audio power well. >> For MIPI since we dont have the audio with encoder, we need not get the >> power well on. >> In such scenario, power well use count is not incrementing (Means no one >> is enabling >> the powerwell for board audio) and hence Board audio is not working. >>> >>> We may have problems in the power domain setup code, failing to take DSI >>> into account or something. But I don't think this is the place to fix >>> it. >> Possibly this is not the place. But Either DSI code or audio code has to >> handle it, >> to make the board audio to work on BXT. Share your view on that. > > I'm not aware of what board audio is, but based on your description I > understand it has nothing to do with HDMI, DP, DSI - or our driver in > general. Correct me if I'm wrong. > > Which driver handles board audio? > > Sounds like the right approach is to have that driver use the i915 > component API to get/put the power well. I did not get a reply to my question here. Is there an upstream driver for the audio? Does using the component API sound like the right thing to do? If it isn't clear, this patch is not acceptable. BR, Jani. > > See sound/hda/hdac_i915.c for how HDA binds to the component API, and > how it calls the ->get_power() and ->put_power() hooks as > needed. Without that, HDA would lose all the registers in audio power > well during mode set. I expect the same for board audio. > > The modeset for HDMI/DP need to get/put the power wells just because > those encoders do the codec enable/disable sequence, actually touching > registers in the power well. > > BR, > Jani. > > > >> >>> >>> Cc Imre and Patrik. >>> >>> >>> BR, >>> Jani. >>> >>> >>> >>> >>>> Signed-off-by: Kumar, Mahesh <mahesh1.kumar@xxxxxxxxx> >>>> Signed-off-by: Uma Shankar <uma.shankar@xxxxxxxxx> >>>> Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx> >>>> --- >>>> drivers/gpu/drm/i915/intel_dsi.c | 13 +++++++++++++ >>>> 1 file changed, 13 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c >>>> index 91cef35..8b43ef6 100644 >>>> --- a/drivers/gpu/drm/i915/intel_dsi.c >>>> +++ b/drivers/gpu/drm/i915/intel_dsi.c >>>> @@ -461,6 +461,9 @@ static void intel_dsi_enable(struct intel_encoder *encoder) >>>> intel_dsi_port_enable(encoder); >>>> } >>>> >>>> + intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO); >>>> + intel_audio_codec_enable(encoder); >>>> + >>>> intel_panel_enable_backlight(intel_dsi->attached_connector); >>>> } >>>> >>>> @@ -531,11 +534,16 @@ static void intel_dsi_enable_nop(struct intel_encoder *encoder) >>>> >>>> static void intel_dsi_pre_disable(struct intel_encoder *encoder) >>>> { >>>> + struct drm_device *dev = encoder->base.dev; >>>> + struct drm_i915_private *dev_priv = dev->dev_private; >>>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base); >>>> enum port port; >>>> >>>> DRM_DEBUG_KMS("\n"); >>>> >>>> + intel_audio_codec_disable(encoder); >>>> + intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO); >>>> + >>>> intel_panel_disable_backlight(intel_dsi->attached_connector); >>>> >>>> if (is_vid_mode(intel_dsi)) { >>>> @@ -1236,6 +1244,11 @@ void intel_dsi_init(struct drm_device *dev) >>>> intel_panel_init(&intel_connector->panel, fixed_mode, NULL); >>>> intel_panel_setup_backlight(connector, INVALID_PIPE); >>>> >>>> + /* Enable Audio Power to fix use-count state machine */ >>>> + port = (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) ? PORT_A : PORT_C; >>>> + if (I915_READ(BXT_MIPI_PORT_CTRL(port)) & DPI_ENABLE) >>>> + intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO); >>>> + >>>> return; >>>> >>>> err: -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx