linux-kernel - Re: [PATCH v3 5/6] drm: atmel-hlcdc: prefer a lower pixel-clock than requested

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: <64902ae8-ef5a-a94a-8edf-05159699b72c@microchip.com>
Date:   Mon, 6 Jan 2020 09:24:52 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <sam@...nborg.org>
CC:     <boris.brezillon@...tlin.com>, <airlied@...ux.ie>,
        <Nicolas.Ferre@...rochip.com>, <alexandre.belloni@...tlin.com>,
        <lee.jones@...aro.org>, <peda@...ntia.se>,
        <dri-devel@...ts.freedesktop.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 5/6] drm: atmel-hlcdc: prefer a lower pixel-clock than
 requested



On 02.01.2020 11:08, Sam Ravnborg wrote:
> On Wed, Dec 18, 2019 at 02:28:28PM +0200, Claudiu Beznea wrote:
>> From: Peter Rosin <peda@...ntia.se>
>>
>> The intention was to only select a higher pixel-clock rate than the
>> requested, if a slight overclocking would result in a rate significantly
>> closer to the requested rate than if the conservative lower pixel-clock
>> rate is selected. The fixed patch has the logic the other way around and
>> actually prefers the higher frequency. Fix that.
>>
>> Fixes: f6f7ad323461 ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
> The id is wrong here - the right one is: 9946a3a9dbedaaacef8b7e94f6ac144f1daaf1de

Right! Sorry for this one! Thank you for fixing it up.

Claudiu Beznea

> The wrong id above was used before - so I think it is a copy'n'paste
> thing.
> 
> Hint: try "dim fixes 9946a3a9dbedaaacef8b7e94f6ac144f1daaf1de"
> 
> If I get a quick response from Lee I can fix it up while applying.
> 
>         Sam
> 
>> Reported-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
>> Tested-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
>> Signed-off-by: Peter Rosin <peda@...ntia.se>
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index 721fa88bf71d..10985134ce0b 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -121,8 +121,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
>>               int div_low = prate / mode_rate;
>>
>>               if (div_low >= 2 &&
>> -                 ((prate / div_low - mode_rate) <
>> -                  10 * (mode_rate - prate / div)))
>> +                 (10 * (prate / div_low - mode_rate) <
>> +                  (mode_rate - prate / div)))
>>                       /*
>>                        * At least 10 times better when using a higher
>>                        * frequency than requested, instead of a lower.
>> --
>> 2.7.4
>