linux-kernel - Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202cd871-eb1c-d8f4-62d6-bed479f0eece@collabora.com>
Date:   Fri, 10 Mar 2017 11:58:19 +0100
From:   Romain Perier <romain.perier@...labora.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Archit Taneja <architt@...eaurora.org>,
        David Airlie <airlied@...ux.ie>,
        Heiko Stuebner <heiko@...ech.de>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        linux-rockchip@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the
 enablement functions

Hello,


Le 10/03/2017 à 11:27, Russell King - ARM Linux a écrit :
> On Fri, Mar 10, 2017 at 11:21:53AM +0100, Romain Perier wrote:
>> Hello,
>>
>> Le 10/03/2017 à 10:46, Russell King - ARM Linux a écrit :
>>> On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote:
>>>> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
>>>> step E. and is kept enabled for later use. This clock should be enabled
>>>> and disabled along with the actual audio stream and not always on (that
>>>> is bad for PM). Futhermore, this might cause sound glitches with some
>>>> HDMI devices, as the CTS+N is forced to zero when the stream is disabled
>>>> while the audio clock is still running.
>>>>
>>>> This commit adds a parameter to hdmi_audio_enable_clk() that controls
>>>> when the audio sample clock must be enabled or disabled. Then, it moves
>>>> the call to this function into dw_hdmi_audio_enable() and
>>>> dw_hdmi_audio_disable().
>>> How does this interact with the workaround given in my commit introducing
>>> these functions?  (Commit b90120a96608).
>>>
>>> Setting N=0 is a work-around for iMX6, and we need the audio FIFO to be
>>> loaded with data prior to setting N non-zero.  If disabling the audio
>>> clock prevents the audio FIFO being loaded, your patch will break iMX6.
>>>
>> Mhhh, the fact is I have no IMX6 devices here (only Rockchip). So
>> I only tested on Rockchip devices. An approach might be to introduce an
>> option for handling this errata, because that's platform specific and
>> other platforms (like Rockchip) are in conflict with this.

> or are you saying
> that the I2S driver was never functionally tested as working?

No ^^

>
> I also would not think that it's platform specific - remember that
> this is Designware IP, and it's likely that other platforms with
> exactly the same IP would suffer from the same problem.  It's
> probably revision specific, but we need Synopsis' input on that.
>
> However, I do believe that your patch probably doesn't have much
> merit in any case: on a mode set, you enable the audio clock, and
> it will remain enabled until the audio device is first opened and
> then closed.  If another mode set comes along, then exactly the
> same situation happens again.  So, really it isn't achieving all
> that much.
>
The fact is we still have sound glitches caused by this workaround on
Rockchip, we probably have a revision
of the IP without this issue. If CTS+N is not forced to zero we no
longer have the glitches :/ (with or without touching the clock)

Romain