[PATCH 01/36] clk: Introduce clk_try_parent()

Thierry Reding thierry.reding at gmail.com
Wed Jan 21 07:12:13 PST 2015


On Tue, Jan 20, 2015 at 01:16:16PM -0500, Rob Clark wrote:
> On Tue, Jan 20, 2015 at 1:02 PM, Mike Turquette <mturquette at linaro.org> wrote:
> > Quoting Thierry Reding (2015-01-20 02:48:20)
> >> From: Thierry Reding <treding at nvidia.com>
> >>
> >> This new function is similar to clk_set_parent(), except that it doesn't
> >> actually change the parent. It merely checks that the given parent clock
> >> can be a parent for the given clock.
> >>
> >> A situation where this is useful is to check that a particular setup is
> >> valid before switching to it. One specific use-case for this is atomic
> >> modesetting in the DRM framework where setting a mode is divided into a
> >> check phase where a given configuration is validated before applying
> >> changes to the hardware.
> >
> > Can you describe why this was needed for your atomic modesetting work?
> > What problem did you hit in the driver that required this new check?
> 
> In particular, for an async atomic update, we need to do everything
> that may potentially fail up front before returning to userspace.
> Additionally there is a 'testonly' flag so that userspace can ask if a
> particular display configuration is possible.

One specific use-case where this is needed is if we want to set a mode
but halfway through the modeset we find out that we can't actually set
it, then we need to somehow rollback the changes, or be stuck with a
mode that doesn't work.

Splitting this into two separate stages allows all the checks to be
performed before making any changes to the hardware. The current mode
will remain active until the changes are committed. Therefore rollback
of a partial modeset is not required.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/f9fcce2d/attachment-0001.sig>


More information about the dri-devel mailing list