linux-kernel - Re: [linux-sunxi] Re: [PATCH 0/4] clk: sunxi-ng: Fix issues with fractional mode

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, 31 Jul 2017 18:50:11 +0200
From:   Jernej Škrabec <jernej.skrabec@...l.net>
To:     linux-sunxi@...glegroups.com, wens@...e.org
Cc:     Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Mike Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] Re: [PATCH 0/4] clk: sunxi-ng: Fix issues with fractional mode

Hi Chen-Yu,

Dne ponedeljek, 31. julij 2017 ob 07:13:34 CEST je Chen-Yu Tsai napisal(a):
> Hi Jernej,
> 
> On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec
> 
> <jernej.skrabec@...l.net> wrote:
> > During development of H3 HDMI driver, I found some issues with
> > setting video clock rate. It turned out that clock driver decided
> > to use fractional mode and selected right frequency, but it didn't
> > enable it. Additionally, fractional helpers don't wait on lock.
> 
> What kind of resolution were you testing to actually hit this?

1920x1080p @ 60Hz

> 
> AFAIK the fractional mode is either 297 or 270 MHz. Even Full HD
> 1080p60 dot clocks aren't that high. And the clk drivers should
> try to request a matching parent clk rate. So the PLL wouldn't
> go that high. Are you testing 4k @ 30fps?

No, it is a bit more complicated than that. H3's HDMI PHY is proprietary and 
register meanings are not known well. Because of that, I'm using values found 
in BSP driver. Those values include pixel clock divider. BSP driver always use 
297 MHz as a base and uses dividers in PHY to prepare right pixel clock. So 
the case for 1080p is 297 MHz / 2 = 148.5 MHz.

> 
> As it stands, I don't think any of the existing display support
> can go that high, so I think we're safe as far as old kernels
> go, i.e. we don't need to Cc stable for these.

Ok.

Regards,
Jernej