linux-kernel - Re: [PATCH v2] drm: tilcdc: add a workaround for failed clk_set

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:   Thu, 29 Sep 2016 15:07:42 +0200
From:   Bartosz Golaszewski <bgolaszewski@...libre.com>
To:     Jyri Sarha <jsarha@...com>
Cc:     Tomi Valkeinen <tomi.valkeinen@...com>,
        David Airlie <airlied@...ux.ie>,
        Kevin Hilman <khilman@...libre.com>,
        Michael Turquette <mturquette@...libre.com>,
        Sekhar Nori <nsekhar@...com>,
        linux-drm <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drm: tilcdc: add a workaround for failed clk_set_rate()

2016-09-29 9:55 GMT+02:00 Jyri Sarha <jsarha@...com>:
> On 09/28/16 15:41, Bartosz Golaszewski wrote:
>> Some architectures don't use the common clock framework and don't
>> implement all the clk interfaces for every clock. This is the case
>> for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
>>
>> Trying to set the clock rate for the LCDC clock results in -EINVAL
>> being returned.
>>
>> As a workaround for that: if the call to clk_set_rate() fails, fall
>> back to adjusting the clock divider instead. Proper divider value is
>> calculated by dividing the current clock rate by the required pixel
>> clock rate in HZ.
>>
>> This code is based on a hack initially developed internally for
>> baylibre by Karl Beldan <kbeldan@...libre.com>.
>>
>> Tested with a da850-lcdk with an LCD display connected over VGA.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
>
> I'd say that a warn with backtrace over kill here (we know quite well
> how we end up here). And it would be helpful to know in actual numbers
> what the clock should have been and how close to it did we get.
>
> Otherwise the patch appears to work fine at least on am335x.
>

Actually there's one more issue - the requested clock rate is in
crtc->mode.clock, not in the rate variable, so that needs fixing too
for the message to be correct.

Best regards,
Bartosz Golaszewski