From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org,
Mengdong Lin <mengdong.lin@linux.intel.com>,
Vinod Koul <vinod.koul@intel.com>,
intel-gfx@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@intel.com>,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: [PATCH v2 2/9] drm/i915: Add get_eld audio component
Date: Fri, 4 Dec 2015 14:10:01 +0200 [thread overview]
Message-ID: <20151204121001.GT4437@intel.com> (raw)
In-Reply-To: <s5hsi3i32ut.wl-tiwai@suse.de>
On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 11:21:02 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > the audio driver to fetch the current audio status and ELD of the
> > > given HDMI/DP port. It returns the size of expected ELD bytes if it's
> > > valid, zero if no valid ELD is found, or a negative error code. The
> > > current state of audio on/off is stored in the given pointer, too.
> > >
> > > Note that the returned size isn't limited to the given max bytes. If
> > > the size is greater than the max bytes, it means that only a part of
> > > ELD has been copied back.
> > >
> > > A big warning about the usage of this callback is: you must not call
> > > it from eld_notify. The eld_notify itself is called in the modeset
> > > lock, and it leads to a deadlock since get_eld takes the modeset lock,
> > > too. You need to call get_eld in a work, for example, in such a case.
> > > We'll see the actual implementation in the later patch in
> > > sound/pci/hda/patch_hdmi.c.
> > >
> > > For achieving this implementation, a new field audio_enabled is added
> > > to struct intel_digital_port. This is set/reset at each audio
> > > enable/disable call in intel_audio.c. It's protected with the modeset
> > > lock as well.
> > >
> > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > ---
> > > v1->v2:
> > > * Use modeset lock for get_eld lock, drop av mutex
> > > * Return the expected size from get_eld, not the copied size
> > >
> > > drivers/gpu/drm/i915/intel_audio.c | 40 ++++++++++++++++++++++++++++++++++++++
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > include/drm/i915_component.h | 6 ++++++
> > > 3 files changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
> > > index 0c38cc6c82ae..1965a61769ea 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
> > >
> > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> > >
> > > + intel_dig_port->audio_enabled = true;
> > > if (dev_priv->display.audio_codec_enable)
> > > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> > > adjusted_mode);
> > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
> > > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > > enum port port = intel_dig_port->port;
> > >
> > > + intel_dig_port->audio_enabled = false;
> > > if (dev_priv->display.audio_codec_disable)
> > > dev_priv->display.audio_codec_disable(intel_encoder);
> > >
> > > @@ -702,6 +704,43 @@ static int i915_audio_component_sync_audio_rate(struct device *dev,
> > > return 0;
> > > }
> > >
> > > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > > + bool *enabled,
> > > + unsigned char *buf, int max_bytes)
> > > +{
> > > + 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 drm_connector *connector;
> > > + unsigned char *eld;
> > > + int ret = -EINVAL;
> > > +
> > > + drm_modeset_lock_all(drm_dev);
> >
> > This is super expensive and shouldn't ever be used in new code. So either
> > just the connection_mutex or resurrect the av_mutex and just cache what
> > you need under that.
>
> OK, I need to make it harder, then.
>
> > Tbh I prefer the separate lock + cache for such
> > specific things since it completely avoids spreading and entangling
> > locking contexts. We use the same design to get modeset information into
> > the PSR tracking, FBC tracking and other code which sits between KMS and
> > other subsystems.
>
> I didn't want to be involved with the modeset lock, but it has to be.
> This function calls drm_select_eld() and it requires both
> mode_config.mutex and connection_mutex.
drm_select_eld() would seem pointless to me if we cached the
required information somewhere. But we'd still need to actually
get the eld, and that means either caching it again somewhere,
or perhaps it would be better to move the drm_edid_to_eld() call to
happen at modeset audio enable time protected by the av_mutex?
That way connector->eld contents would remain constant as long
as we have a mode set.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-12-04 12:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 16:09 [PATCH v2 0/9] Add get_eld audio component for i915/HD-audio Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 1/9] drm/i915: Remove superfluous NULL check Takashi Iwai
2015-12-04 10:21 ` Daniel Vetter
2015-12-04 12:16 ` Ville Syrjälä
2015-12-04 12:54 ` Takashi Iwai
2015-12-04 13:07 ` Ville Syrjälä
2015-12-04 13:12 ` Takashi Iwai
2015-12-04 14:55 ` Daniel Vetter
2015-12-01 16:09 ` [PATCH v2 2/9] drm/i915: Add get_eld audio component Takashi Iwai
2015-12-04 10:21 ` Daniel Vetter
2015-12-04 10:49 ` Takashi Iwai
2015-12-04 12:10 ` Ville Syrjälä [this message]
2015-12-04 12:50 ` [Intel-gfx] " Takashi Iwai
2015-12-04 15:00 ` Daniel Vetter
2015-12-04 15:15 ` Takashi Iwai
2015-12-04 15:53 ` Daniel Vetter
2015-12-04 16:03 ` Takashi Iwai
2015-12-04 15:54 ` Daniel Vetter
2015-12-04 16:03 ` Takashi Iwai
2015-12-04 16:15 ` Daniel Vetter
2015-12-04 16:20 ` Takashi Iwai
2015-12-04 16:27 ` Takashi Iwai
2015-12-04 16:49 ` Daniel Vetter
2015-12-04 16:52 ` Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 3/9] drm/i915: refactoring audio component functions Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 4/9] drm/i915: Add reverse mapping between port and intel_encoder Takashi Iwai
2015-12-04 14:40 ` Takashi Iwai
2015-12-04 15:02 ` Daniel Vetter
2015-12-04 15:09 ` Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 5/9] ALSA: hda - Split ELD update code from hdmi_present_sense() Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 6/9] ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 7/9] ALSA: hda - Do zero-clear in snd_hdmi_parse_eld() itself Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 8/9] ALSA: hda - Skip ELD notification during PM process Takashi Iwai
2015-12-03 16:44 ` Takashi Iwai
2015-12-01 16:09 ` [PATCH v2 9/9] ALSA: hda - Move audio component accesses to hdac_i915.c Takashi Iwai
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=20151204121001.GT4437@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=daniel.vetter@intel.com \
--cc=david.henningsson@canonical.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mengdong.lin@linux.intel.com \
--cc=tiwai@suse.de \
--cc=vinod.koul@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