linux-kernel - Re: [PATCH 0/3] clk: meson: fix mpll jitter

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]

Date:   Mon, 01 Apr 2019 10:40:26 +0200
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     Neil Armstrong <narmstrong@...libre.com>,
        linux-amlogic@...ts.infradead.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] clk: meson: fix mpll jitter

On Sat, 2019-03-30 at 16:58 +0100, Martin Blumenstingl wrote:
> On Fri, Mar 29, 2019 at 4:34 PM Jerome Brunet <jbrunet@...libre.com> wrote:
> > As reported on this [0] mpll series, We are observing a lot of jitter
> > on the MPLL outputs of the g12a. No such jitter is seen on gx family.
> > On the axg family, only MPLL2 seems affected.
> > 
> > The jitter can be as high as +/- 4%.
> > 
> > This is a problem for audio application. This may cause distortion on
> > i2s and completely break SPDIF.
> > 
> > After exchanging with Amlogic, it seems he have activated (by mistake)
> > the 'spread spectrum' feature.
> > 
> > This patchset properly set the bit responsible for the spread spectrum
> > in the mpll driver and add the required correction in the related clock
> > controllers.
> > 
> > Jerome Brunet (3):
> >   clk: meson: mpll: properly handle spread spectrum
> this depends on a patch from your other series "clk: meson: fixup g12a
> mpll": [0]
> personally I would base the other series on this one because this one
> contains a "Fixes" that (meaning that the patch will get backported
> and that's easier if there aren't any conflicts)

1) The other series [0] had been submitted before we knew about the fix which
is why this one is based on it.
2) Considering the amount of work that went through since the fixed commit, I
doubt it makes much of a difference.

I might do it if both series require a resend.

> 
> 
> Regards
> Martin
> 
> 
> [0] https://patchwork.kernel.org/patch/10868837/