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: <4026156.d8uMWWFJnt@jernej-laptop>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ