All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kurtz <djkurtz@chromium.org>
To: Yang Kuankuan <ykk@rock-chips.com>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"David Airlie" <airlied@linux.ie>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Fabio Estevam" <fabio.estevam@freescale.com>,
	"Shawn Guo" <shawn.guo@linaro.org>,
	"Rob Clark" <robdclark@gmail.com>,
	"Mark Yao" <mark.yao@rock-chips.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dbehr@chromoum.org, "Heiko Stübner" <mmind00@googlemail.com>,
	"Douglas Anderson" <dianders@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	rockchip-discuss <rockchip-discuss@chromium.org>
Subject: Re: [PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces
Date: Mon, 2 Feb 2015 12:02:50 +0800	[thread overview]
Message-ID: <CAGS+omDMhxE5qRk51w2aDOCqWVTM5TtwO+cAws_OVXaMEw=vHg@mail.gmail.com> (raw)
In-Reply-To: <54CCE7EF.5040706@rock-chips.com>

Hi ykk,

On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan <ykk@rock-chips.com> wrote:
>
> On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote:
>>
>>> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
>>> +{
>>> +       if (hdmi->audio_enable)
>>> +               return;
>>> +
>>> +       mutex_lock(&hdmi->audio_mutex);
>>> +       hdmi->audio_enable = true;
>>> +       hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>>> HDMI_MC_CLKDIS);
>>> +       mutex_unlock(&hdmi->audio_mutex);
>>
>> This is racy.  The test needs to be within the mutex-protected region.
>
> This function will be called by other driver (dw-hdmi-audio), both modify
> the variable "hdmi->audio_enable", so i add the mutex-protected.

>From your comment it isn't clear whether you understand what Russell meant.
He is say you should do the following:

{
       mutex_lock(&hdmi->audio_mutex);

       if (hdmi->audio_enable) {
              mutex_unlock(&hdmi->audio_mutex);
              return;
       }
       hdmi->audio_enable = true;
       hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);

       mutex_unlock(&hdmi->audio_mutex);
}

By the way, it doesn't matter that the function is called from another driver.
What matters is that this function can be called concurrently on
multiple different threads of execution to change the hdmi audio
enable state.
>From DRM land, it is called with DRM lock held when enabling/disabling
hdmi audio (mode_set / DPMS).
It is also called from audio land, when enabling/disabling audio in
response to some audio events (userspace ioctls?).  I'm not sure
exactly how the audio side works, or what locks are involved, but this
mutex synchronizes calls from these two worlds to ensure that
"hdmi->audio_enable" field always matches the current (intended)
status of the hdmi audio clock.  This would be useful, for example, if
you needed to temporarily disable all HDMI clocks during a mode set,
and then restore the audio clock to its pre-mode_set state:

  // temporarily disable hdmi audio clk
  dw_hdmi_audio_clk_disable(hdmi);
  // do mode_set ...
  dw_hdmi_audio_clk_reenable(hdmi);

 static void dw_hdmi_audio_clk_reenable()
 {
    mutex_lock()
    if (hdmi->audio_enable)
      dw_hdmi_audio_clk_enable(hdmi)
    mutex_unlock()
  }

However, AFAICT, the "hdmi->audio_enable" field is never actually used
like this here or in later patches, so it and the mutex do not seem to
actually be doing anything useful.  In this patch it is probably
better to just drop the mutex and audio_enable, and add them as a
preparatory patch in the patch set where they will actually be used.

-Dan

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Kurtz <djkurtz@chromium.org>
To: Yang Kuankuan <ykk@rock-chips.com>
Cc: "Fabio Estevam" <fabio.estevam@freescale.com>,
	"Heiko Stübner" <mmind00@googlemail.com>,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	dbehr@chromoum.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Douglas Anderson" <dianders@chromium.org>,
	rockchip-discuss <rockchip-discuss@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Mark Yao" <mark.yao@rock-chips.com>
Subject: Re: [PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces
Date: Mon, 2 Feb 2015 12:02:50 +0800	[thread overview]
Message-ID: <CAGS+omDMhxE5qRk51w2aDOCqWVTM5TtwO+cAws_OVXaMEw=vHg@mail.gmail.com> (raw)
In-Reply-To: <54CCE7EF.5040706@rock-chips.com>

Hi ykk,

On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan <ykk@rock-chips.com> wrote:
>
> On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote:
>>
>>> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
>>> +{
>>> +       if (hdmi->audio_enable)
>>> +               return;
>>> +
>>> +       mutex_lock(&hdmi->audio_mutex);
>>> +       hdmi->audio_enable = true;
>>> +       hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>>> HDMI_MC_CLKDIS);
>>> +       mutex_unlock(&hdmi->audio_mutex);
>>
>> This is racy.  The test needs to be within the mutex-protected region.
>
> This function will be called by other driver (dw-hdmi-audio), both modify
> the variable "hdmi->audio_enable", so i add the mutex-protected.

From your comment it isn't clear whether you understand what Russell meant.
He is say you should do the following:

{
       mutex_lock(&hdmi->audio_mutex);

       if (hdmi->audio_enable) {
              mutex_unlock(&hdmi->audio_mutex);
              return;
       }
       hdmi->audio_enable = true;
       hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);

       mutex_unlock(&hdmi->audio_mutex);
}

By the way, it doesn't matter that the function is called from another driver.
What matters is that this function can be called concurrently on
multiple different threads of execution to change the hdmi audio
enable state.
From DRM land, it is called with DRM lock held when enabling/disabling
hdmi audio (mode_set / DPMS).
It is also called from audio land, when enabling/disabling audio in
response to some audio events (userspace ioctls?).  I'm not sure
exactly how the audio side works, or what locks are involved, but this
mutex synchronizes calls from these two worlds to ensure that
"hdmi->audio_enable" field always matches the current (intended)
status of the hdmi audio clock.  This would be useful, for example, if
you needed to temporarily disable all HDMI clocks during a mode set,
and then restore the audio clock to its pre-mode_set state:

  // temporarily disable hdmi audio clk
  dw_hdmi_audio_clk_disable(hdmi);
  // do mode_set ...
  dw_hdmi_audio_clk_reenable(hdmi);

 static void dw_hdmi_audio_clk_reenable()
 {
    mutex_lock()
    if (hdmi->audio_enable)
      dw_hdmi_audio_clk_enable(hdmi)
    mutex_unlock()
  }

However, AFAICT, the "hdmi->audio_enable" field is never actually used
like this here or in later patches, so it and the mutex do not seem to
actually be doing anything useful.  In this patch it is probably
better to just drop the mutex and audio_enable, and add them as a
preparatory patch in the patch set where they will actually be used.

-Dan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-02-02  4:03 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30 11:23 [PATCH v2 0/12] Those patches is used for dw_hdmi audio support Yakir Yang
2015-01-30 11:25 ` [PATCH v2 01/12] drm: bridge/dw_hdmi: adjust n/cts setting order Yakir Yang
2015-01-31 11:07   ` Russell King - ARM Linux
2015-01-31 11:07     ` Russell King - ARM Linux
2015-02-02 13:02     ` Yang Kuankuan
2015-01-30 11:27 ` [PATCH v2 02/12] drm: bridge/dw_hdmi: add audio sample channel status setting Yakir Yang
2015-01-31 11:08   ` Russell King - ARM Linux
2015-01-31 11:08     ` Russell King - ARM Linux
2015-01-31 11:22     ` Yang Kuankuan
2015-01-31 11:30       ` Russell King - ARM Linux
2015-01-31 11:30         ` Russell King - ARM Linux
2015-01-30 11:28 ` [PATCH v2 03/12] drm: bridge/dw_hdmi: add irq control to suspend/resume Yakir Yang
2015-01-31 11:11   ` Russell King - ARM Linux
2015-01-31 11:11     ` Russell King - ARM Linux
2015-01-31 11:18     ` Yang Kuankuan
2015-01-30 11:28 ` [PATCH v2 04/12] drm: rockchip/dw_hdmi_rockchip: add resume/suspend support Yakir Yang
2015-01-31 11:13   ` Russell King - ARM Linux
2015-01-31 12:30     ` Yang Kuankuan
2015-01-30 11:29 ` [PATCH v2 05/12] drm: rockchip/vop: filter interlace display mode Yakir Yang
2015-02-02  8:00   ` Daniel Kurtz
2015-02-02  8:00     ` Daniel Kurtz
2015-02-02  8:28     ` Yang Kuankuan
2015-01-30 11:30 ` [PATCH v2 06/12] drm: bridge/dw_hdmi: add audio support for more display resolutions Yakir Yang
2015-01-31 11:20   ` Russell King - ARM Linux
2015-01-31 11:20     ` Russell King - ARM Linux
2015-01-31 13:28     ` Yang Kuankuan
2015-01-30 11:31 ` [PATCH v2 07/12] drm: bridge/dw_hdmi: enable audio support for No-CEA " Yakir Yang
2015-01-31 11:41   ` Russell King - ARM Linux
2015-01-31 11:41     ` Russell King - ARM Linux
2015-01-30 11:32 ` [PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces Yakir Yang
2015-01-31 11:48   ` Russell King - ARM Linux
2015-01-31 11:48     ` Russell King - ARM Linux
2015-01-31 14:34     ` Yang Kuankuan
2015-02-02  4:02       ` Daniel Kurtz [this message]
2015-02-02  4:02         ` Daniel Kurtz
2015-02-02 11:53         ` Russell King - ARM Linux
2015-02-02 11:53           ` Russell King - ARM Linux
2015-02-02 12:32           ` Yang Kuankuan
2015-02-02 13:09             ` Russell King - ARM Linux
2015-02-02 13:09               ` Russell King - ARM Linux
2015-02-03  3:05               ` Yang Kuankuan
2015-02-04  3:02               ` Yang Kuankuan
2015-01-30 11:33 ` [PATCH v2 09/12] drm: bridge/dw_hdmi: creat dw-hdmi-audio platform device Yakir Yang
2015-01-30 11:41 ` [PATCH v2 10/12] ASoC: dw-hdmi-audio: add codec driver for dw hdmi audio Yakir Yang
2015-01-30 11:41   ` Yakir Yang
2015-01-31 11:39   ` Russell King - ARM Linux
2015-01-31 11:39     ` Russell King - ARM Linux
2015-01-31 11:39     ` Russell King - ARM Linux
2015-01-30 11:43 ` [PATCH v2 11/12] ASoC: rockchip-hdmi-audio: add sound driver for " Yakir Yang
2015-01-30 11:43   ` Yakir Yang
2015-01-30 11:43   ` Yakir Yang
2015-01-30 11:44 ` [PATCH v2 12/12] dt-bindings: Add documentation for Rockchip dw-hdmi-audio Yakir Yang
2015-01-30 11:44   ` Yakir Yang
2015-01-31 11:36   ` Russell King - ARM Linux
2015-01-31 11:36     ` Russell King - ARM Linux
2015-01-31 11:36     ` Russell King - ARM Linux
2015-01-31 13:51     ` Yang Kuankuan
2015-01-31 13:51       ` Yang Kuankuan
2015-01-31 13:51       ` Yang Kuankuan
2015-01-31 12:00 ` [PATCH v2 0/12] Those patches is used for dw_hdmi audio support Russell King - ARM Linux
2015-01-31 12:00   ` Russell King - ARM Linux
2015-02-02 13:02   ` Yang Kuankuan

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='CAGS+omDMhxE5qRk51w2aDOCqWVTM5TtwO+cAws_OVXaMEw=vHg@mail.gmail.com' \
    --to=djkurtz@chromium.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dbehr@chromoum.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabio.estevam@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marcheu@chromium.org \
    --cc=mark.yao@rock-chips.com \
    --cc=mmind00@googlemail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robdclark@gmail.com \
    --cc=rockchip-discuss@chromium.org \
    --cc=shawn.guo@linaro.org \
    --cc=ykk@rock-chips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.