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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 26 Jun 2019 12:24:32 -0700
From:   Doug Anderson <>
To:     Andrzej Hajda <>
Cc:     Laurent Pinchart <>,
        Sean Paul <>,
        Jernej Skrabec <>,
        Heiko Stübner <>,
        Jonas Karlman <>,
        Maxime Ripard <>,
        Neil Armstrong <>,
        "open list:ARM/Rockchip SoC..." <>,
        Dylan Reid <>,
        Cheng-Yi Chiang <>,
        Jerome Brunet <>,
        Sam Ravnborg <>,
        dri-devel <>,
        LKML <>,
        David Airlie <>,
        Daniel Vetter <>
Subject: Re: [PATCH v2 1/2] drm/bridge/synopsys: dw-hdmi: Handle audio for
 more clock rates


On Wed, Jun 26, 2019 at 2:56 AM Andrzej Hajda <> wrote:
> >   AKA: anyone using auto-CTS won't notice any change
> > at all.  I guess the question is: with Auto-CTS should you pick the
> > "ideal" 6272 or a value that allows CTS to be the closest to integral
> > as possible.  By reading between the lines of the spec, I decided that
> > it was slightly more important to allow for an integral CTS.  If
> > achieving an integral CTS wasn't a goal then the spec wouldn't even
> > have listed special cases for any of the clock rates.  We would just
> > be using the ideal N and Auto-CTS and be done with it.  The whole
> > point of the tables they list is to make CTS integral.
> Specification recommends many contradictory things without explicit
> prioritization, at least I have not found it.
> So we should relay on our intuition.
> I guess that with auto-cts N we should follow recommendation - I guess
> most sinks have been better tested with recommended values.
> So what with non-auto-cts case:
> 1. How many devices do not have auto-cts? how many alternative TMDS
> clocks we have? Maybe it is theoretical problem.
> 2. Alternating CTS in software is possible, but quite
> complicated/annoying, but at least it will follow recommendation :)

It is OK w/ me if we want to drop my patch.  With the auto-CTS patch
it shouldn't matter anymore.  ...but I still wanted to post it to the
list for posterity in case it is ever useful for someone else.


Powered by blists - more mailing lists