Re: [PATCH 2/2] drm/i915/dsi: Add audio reference in dsi encoder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Friday 19 February 2016 02:53 PM, Jani Nikula wrote:
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.
Jani,

sorry somehow missed this thread.
I was referring to on board audio which is not attached to any display encoder. This patch is trying to fix a audio bug, which is disclosed when COS related bug was fixed.

This has to be debugged from the audio perspective why the power well is not requested
for at this modified code sequence.

We can drop this patch as this wont be the correct way and place to fix.

--
Thanks,
--Ram



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:

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux