From: Yang Kuankuan <ykk@rock-chips.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "Daniel Kurtz" <djkurtz@chromium.org>,
"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: Tue, 03 Feb 2015 22:02:14 -0500 [thread overview]
Message-ID: <54D18BB6.7060305@rock-chips.com> (raw)
In-Reply-To: <20150202130920.GC8656@n2100.arm.linux.org.uk>
On 02/02/2015 08:09 AM, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2015 at 07:32:05AM -0500, Yang Kuankuan wrote:
>> On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote:
>>> On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote:
>>>> 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);
>>>> }
>>> Yes, however, I prefer this kind of layout:
>>>
>>> mutex_lock(&hdmi->audio_mutex);
>>> if (!hdmi->audio_enable) {
>>> hdmi->audio_enable = true;
>>> hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>>> HDMI_MC_CLKDIS);
>>> }
>>>
>>> mutex_unlock(&hdmi->audio_mutex);
>>>
>>> but that's a matter of personal opinion. The important thing is that the
>>> testing and setting of the flag are both within the protected region.
>>>
>>> However, there are other bugs here: what if the audio driver is calling
>>> the sample rate setting function at the same time that a mode switch is
>>> occuring. We actually need a mutex to protect more than just the
>>> audio_enable flag.
>> Okay, got it.
>>
>> Thanks. : )
> I've been moving my code closer to what you have posted. I've split up
> your patches into smaller steps so each change can be evaluated on iMX6.
> So far:
>
> drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
>
> This patch _just_ combines the two functions without any other changes.
>
> drm: bridge/dw_hdmi: protect n/cts setting with a mutex
>
> This patch _just_ adds a mutex to protect the calls to
> hdmi_set_clk_regenerator(), since we will need to call that from both
> the DRM and audio drivers.
>
> drm: bridge/dw_hdmi: adjust n/cts setting order
>
> This patch changes the order to:
> - write CTS3 CTS_manual = 0
> - write CTS3 N_shift = 0
> - write CTS3 CTS value
> - write CTS2 CTS value
> - write CTS1 CTS value
> - write N3 N value
> - write N2 N value
> - write N1 N value
> which is broadly what you're doing, but without the initial N3 write
> and without CTS_manual=1. I've asked Freescale whether they can
> clarify what effect adding those would have on their SoCs.
>
> Note: the mutex in my second patch needs to be a spinlock - as it seems
> my new workaround for iMX6 ERR005174 needs to call the CTS/N setting
> functions in an irqs-off region (from the ALSA ->trigger callback.)
> That will need further rework of the CTS/N code to reduce the size of
> the spinlock protected region.
>
> Incidentally, your Synopsis IP indicates that it is the same revision
> as the iMX6's IP revision which suffers from this ERR005174 errata.
> I think you need to check whether this errata applies on your SoC too.
> Seach for "iMX6 ERR005174" in google.
Thank you very much. : )
I will take this order in next v3.
>>>> 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:
>>> There's some rather quirky comments in the driver right now which make
>>> me uneasy about changing things too much.
>>>
>>> My initial idea would be that audio should remain disabled until the
>>> audio driver wants it enabled, and the CTS/N values should either be
>>> left alone, or set to a value which disables them (there is an iMX6
>>> errata which says to set N=0 initially, but as seems common with iMX6
>>> errata, I see no code implementing the method specified in the
>>> documentation - I have found code implementing something similar
>>> though.)
>> I am confused with the way that audio driver realize the display
>> resolution-changing.
>> If audio driver cannot knowing that, then audio clock may be closed
>> permanently ?
> The audio driver shouldn't care about the display resolution. That
> should be the responsibility of the dw_hdmi core - as it is at the
> moment.
Do you mean that we should disable audio clock and deinit
the n/cts values, until we meet the audio enable single like this.
>> static void hdmi_keep_audio_clk_status(struct dw_hdmi *hdmi)
>> {
>> mutex_lock(&hdmi->audio_mutex);
>>
>> if (hdmi->audio_enable)
>> hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>> HDMI_MC_CLKDIS);
>> else
>> hdmi_modb(hdmi, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>> HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
>>
>> mutex_unlock(&hdmi->audio_mutex);
>> }
>>
>> /* HDMI Initialization Step E - Configure audio */
>> hdmi_clk_regenerator_update_pixel_clock(hdmi);
>> hdmi_keep_audio_clk_status(hdmi);
>>
>> keep audio status maybe suitable here.
> What I don't know right now is what triggers this overflow indication in
> HDMI_IH_FC_STAT2, and whether the code I quoted (which fakes the audio
> setup) is actually necessary.
>
> In other words:
> - is it necessary to have the audio clock enabled when video is enabled
> to prevent the overflow indication? We don't know. Therefore, we
> can't say whether it is permitted to disable the audio clock when
> audio is inactive.
> - is it necessary to program a dummy CTS/N value for 74.25MHz/48kHz,
> or can we program a non-zero CTS value and a zero N at initialisation
> until the audio driver comes up? Again, we don't know.
>
> What we do know is that as the driver stands, it works for video output.
> With my changes for AHB audio support on the iMX6 (which includes some
> errata workarounds found in the iMX6 errata documentation to avoid FIFO
> issues), we have working audio there.
>
next prev parent reply other threads:[~2015-02-04 3:03 UTC|newest]
Thread overview: 40+ 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-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:22 ` Yang Kuankuan
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: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: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 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-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 14:34 ` Yang Kuankuan
2015-02-02 4:02 ` Daniel Kurtz
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-03 3:05 ` Yang Kuankuan
2015-02-04 3:02 ` Yang Kuankuan [this message]
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-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:44 ` [PATCH v2 12/12] dt-bindings: Add documentation for Rockchip dw-hdmi-audio Yakir Yang
2015-01-31 11:36 ` Russell King - ARM Linux
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-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=54D18BB6.7060305@rock-chips.com \
--to=ykk@rock-chips.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dbehr@chromoum.org \
--cc=dianders@chromium.org \
--cc=djkurtz@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 \
/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;
as well as URLs for NNTP newsgroup(s).