]> git.karo-electronics.de Git - linux-beck.git/commit
drm/i915: move dp clock computations to encoder->compute_config
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Fri, 19 Apr 2013 09:14:33 +0000 (11:14 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Thu, 25 Apr 2013 19:21:00 +0000 (21:21 +0200)
commitc6bb353815c30c3f8a33b436314926706f4b6360
tree260531f41d56439be0b748302e614877b2b3636c
parent7429e9d4bfcfd08a00ed7b760386bd81a60e91d6
drm/i915: move dp clock computations to encoder->compute_config

With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).

v2: Ville asked me to elaborate a bit more on the longer-term goals
wrt dpll settings computation:

So ultimately my idea is that in the compute config stage first the crtc
code puts the default platform pll limits into the pipe_config. Then
encoders can either overwrite that limit structure with their own special
stuff (mostly for lvds madness). Or they can pick some or all of the
parameters (e.g. just the p2 switchover on hdmi, or all the clock
parameters for dp/sdvo tv).

Once that's done then the generic crtc code can fill out any missing bits
(using the find_best_pll code) and then try to assign which pll to use (if
it's a platform with shared plls). In the end the modeset could should
simply write the computed stuff into registers and never be able to fail.

Of course there's still a lot of data to be moved into pipe_config to make
this all happen, hence some of the temporary ugliness.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c