From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 00/19] [RFC] introduce struct intel_pipe_config
Date: Fri, 15 Feb 2013 08:48:16 -0800 [thread overview]
Message-ID: <20130215084816.701ce2b1@jbarnes-desktop> (raw)
In-Reply-To: <20130215100526.GA5813@phenom.ffwll.local>
On Fri, 15 Feb 2013 11:05:26 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Feb 14, 2013 at 02:28:19PM -0800, Jesse Barnes wrote:
> > Well, I think we'll have to punt in quite a few configs due to hw
> > limitations about what can be changed without a full pipe shutdown, but
> > we can definitely do better than we do today, and may be able to take
> > some shortcuts (provided we get lots of testing on the given hw).
>
> Yeah, as discussed on irc my idea (doesn't exists as code yet) is to add a
> few special modes to the pipe_config compare function:
> - strict: Used after a modeset to check whether the new hw state matches
> up with what we wanted to set.
> - modeset: More permissive for fastboot to decide whether the new
> configuration is essentially the same as the old one. Things like fuzzy
> clock matching and things like that would imo fit here.
> - plane-update-only: Even more permissive to figure out whether we only
> have different plane/pfit/whatever settings. For a new fastboot plane
> update mode that everyone seems to dream about.
> - Feel free to go nuts ;-)
On a related note, getting the clock for gen5+ plus is really easy if
you want to get the fitted mode. You can just read the linkm reg. The
problem is that it doesn't tell us what the clock would be for the
native mode which we read from the htotal/vtotal etc regs. However
forcing it to the right value works, even though the pipe m/n values
are wrong for the native mode.
> > > Comments, flames and ideas for the patches themselves, but also for the above
> > > issues in general highly welcome.
> >
> > Overall I like this approach, it should make fastboot state tracking a
> > lot easier.
> >
> > We'll also want to track gamma enable; unfortunately that can only be
> > changed with the plane off (according to docs), but we should check for
> > it regardless.
>
> Hey, that's a new one! I've we're lucky we could subsume this with the
> "update plane only" mode to get rid of the pfit and similar stuff we don't
> want ...
>
> A similar issue is all the various bits&pieces to support hdmi/audio. I
> don't know yet how we should exactly track this. Might be that fastboot
> for external screens is a long way off still.
Well, first step is to track that stuff. We can still fastboot in many
cases but then punt to a full mode set if we find any state we don't
deal with.
--
Jesse Barnes, Intel Open Source Technology Center
prev parent reply other threads:[~2013-02-15 16:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 11:32 [PATCH 00/19] [RFC] introduce struct intel_pipe_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 01/19] drm/i915: introduce struct intel_crtc_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 02/19] drm/i915: compute pipe_config earlier Daniel Vetter
2013-02-13 11:32 ` [PATCH 03/19] drm/i915: add pipe_config->timings_set Daniel Vetter
2013-02-13 11:32 ` [PATCH 04/19] drm/i915: add pipe_config->pixel_multiplier Daniel Vetter
2013-02-13 11:32 ` [PATCH 05/19] drm/i915: add pipe_config->has_pch_encoder Daniel Vetter
2013-02-13 11:32 ` [PATCH 06/19] drm/i915: clear up the fdi/dp set_m_n confusion Daniel Vetter
2013-02-13 11:32 ` [PATCH 07/19] drm/i915: move pipe bpp computation to pipe_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 08/19] drm/i915: clean up plane bpp confusion Daniel Vetter
2013-02-13 11:32 ` [PATCH 09/19] drm/i915: clean up pipe " Daniel Vetter
2013-02-13 11:32 ` [PATCH 10/19] drm/i915: move dp_m_n computation to dp_encoder->compute_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 11/19] drm/i915: track dp target_clock in pipe_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 12/19] drm/i915: rip out superflous is_dp&is_cpu_edp tracking Daniel Vetter
2013-02-13 11:32 ` [PATCH 13/19] drm/i915: add hw state readout/checking for pipe_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 14/19] drm/i915: hw readout support for ->has_pch_encoders Daniel Vetter
2013-02-13 11:32 ` [PATCH 15/19] drm/i915: gen2 has no tv out support Daniel Vetter
2013-02-13 11:32 ` [PATCH 16/19] drm/i915: create pipe_config->dpll for clock state Daniel Vetter
2013-02-13 11:32 ` [PATCH 17/19] drm/i915: move dp clock computations to encoder->compute_config Daniel Vetter
2013-02-13 11:32 ` [PATCH 18/19] drm/i915: add pipe_config->limited_color_range Daniel Vetter
2013-02-13 11:32 ` [PATCH 19/19] drm/i915: use pipe_config for lvds dithering Daniel Vetter
2013-02-13 14:03 ` [PATCH 00/19] [RFC] introduce struct intel_pipe_config Chris Wilson
2013-02-13 15:57 ` Daniel Vetter
2013-02-14 22:28 ` Jesse Barnes
2013-02-15 10:05 ` Daniel Vetter
2013-02-15 16:48 ` Jesse Barnes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130215084816.701ce2b1@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox