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@xxxxxxxxxx> wrote: > > Quoting Thierry Reding (2015-01-20 02:48:20) > >> From: Thierry Reding <treding@xxxxxxxxxx> > >> > >> 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
Attachment:
pgpCWWFt63uX8.pgp
Description: PGP signature
