linux-kernel - Re: [PATCH] drm: arcpgu: Allow some clock deviation in crtc->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] [day] [month] [year] [list]

Date:   Wed, 12 Jul 2017 17:06:05 +0000
From:   Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To:     Jose Abreu <Jose.Abreu@...opsys.com>
CC:     Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
        "airlied@...ux.ie" <airlied@...ux.ie>
Subject: Re: [PATCH] drm: arcpgu: Allow some clock deviation in
 crtc->mode_valid() callback

Hi Jose,

On Tue, 2017-06-27 at 15:36 +0100, Jose Abreu wrote:
> Currently we expect that clock driver produces the exact same value
> as we are requiring. There can, and will, be some deviation however
> so we need to take into account that instead of rejecting the mode.
> 
> According to HDMI spec we have a max of +-0.5% for the pixel clock
> frequency variation. Lets take that into an advantage and use it
> to calculate how much deviation we can support.
> 
> This patch was based on today's drm-misc-next.
> 
> Signed-off-by: Jose Abreu <joabreu@...opsys.com>
> Cc: Carlos Palminha <palminha@...opsys.com>
> Cc: Alexey Brodkin <abrodkin@...opsys.com>
> Cc: Daniel Vetter <daniel.vetter@...ll.ch>
> Cc: Dave Airlie <airlied@...ux.ie>

Finally our problem with EDID-less monitor is fixed
with that patch.

Thus,

Acked-by: Alexey Brodkin <abrodkin@...opsys.com>