[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200602125227.fe3mt5jnqd6u4pft@gilmour>
Date: Tue, 2 Jun 2020 14:52:27 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Eric Anholt <eric@...olt.net>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
DRI Development <dri-devel@...ts.freedesktop.org>,
linux-rpi-kernel@...ts.infradead.org,
bcm-kernel-feedback-list@...adcom.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
Tim Gover <tim.gover@...pberrypi.com>,
Phil Elwell <phil@...pberrypi.com>
Subject: Re: [PATCH v3 015/105] drm/vc4: hvs: Boost the core clock during
modeset
Hi Eric,
On Wed, May 27, 2020 at 09:33:44AM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:49 AM Maxime Ripard <maxime@...no.tech> wrote:
> >
> > In order to prevent timeouts and stalls in the pipeline, the core clock
> > needs to be maxed at 500MHz during a modeset on the BCM2711.
>
> Like, the whole system's core clock?
Yep, unfortunately...
> How is it reasonable for some device driver to crank the system's core
> clock up and back down to some fixed-in-the-driver frequency? Sounds
> like you need some sort of opp thing here.
That frequency is the minimum rate of that clock. However, since other
devices have similar requirements (unicam in particular) with different
minimum requirements, we will switch to setting a minimum rate instead
of enforcing a particular rate, so that patch would be essentially
s/clk_set_rate/clk_set_min_rate/.
Would that work for you?
>
> Patch 13,14 r-b.
Thanks!
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists