[Intel-gfx] [PATCH 04/11] drm/i915: Factor out i9xx_compute_clocks() like ironlake_compute_clocks()
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed Oct 31 18:04:29 CET 2012
On Wed, Oct 31, 2012 at 05:28:40PM +0100, Daniel Vetter wrote:
> On Wed, Oct 31, 2012 at 05:50:17PM +0200, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > Split the i9xx clock stuff out from i9xx_compute_clocks().
> >
> > Only compile tested!
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
> I'm working on a massive overhaul of the clock computation madness, so
> that we do all that stuff before we start to touch the hw (and so would
> finally have a reasonable chance at getting global bw issues right).
I was sure that the compute_clock() funcs already satisfied that.
Perhaps I didn't look hard enough.
The reason for this patch actually was that I'm already using that
approach in the atomic modeset code. Ie. I call compute_clock() for
all modified CRTCs before touching the hardware.
Or is the problem simply that multiple calls to compute_clock() would
depend on some bit of state that is changed somewhere later in
crtc_mode_set()? So that when doing a multi-CRTC modeset, the final
state is never seen by any of the compute_clock() funcs when used this
way?
--
Ville Syrjälä
Intel OTC
More information about the Intel-gfx
mailing list