All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 4/3] drm/i915: Clarify logic for initial modeset
Date: Wed, 15 Jul 2015 17:16:39 +0200	[thread overview]
Message-ID: <20150715151639.GA6223@phenom.ffwll.local> (raw)
In-Reply-To: <55A65E22.1090608@linux.intel.com>

On Wed, Jul 15, 2015 at 03:20:34PM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 15-07-15 om 14:15 schreef Daniel Vetter:
> > Currently we both set mode->private_flags to some value and also use
> > the pipe_config quirk. But since the pipe_config quirk isn't tied to
> > the lifetime of the mode object we need to check both.
> >
> > Simplify this by only using mode.private_flags and stop using the
> > INHERITED_MODE quirk. Also for clarity add an explicit #define for
> > that driver priavete mode flag.
> >
> > By using crtc_state->mode_changed we can also remove the recalc local
> > variable.
> Those 3 changes look good to me.
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 
> Any objections against this followup patch?
> Or should I wait until I made intel_update_pipe_size atomic?
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> index 7eff33ff84f6..914679ceb200 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -578,9 +578,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
>  	struct intel_crtc *intel_crtc;
>  	unsigned int max_size = 0;
>  
> -	if (!i915.fastboot)
> -		return false;

I tried to digg out from history why we added that check, but never found
it. Original commit says that Jesse added this on his own, but doesn't
explain the reason for that. Reading through the code there doesn't seem
to be anything in there that needs other bits of fastboot (or ever needed
other bits of fastboot). The only effect I can see is that we'll take over
the bpp setting from the firmware, and previously that resulted in
modesets since we used the primary bpp to pick the pipe bpp. But that's
fixed now so no risk for spurious modesets when doing fbcon<->X vt
switches.

Can you please paste the above explanation into a commit message and send
it out with sob and all? I'll pick it up.

Cheers, Daniel
> -
>  	/* Find the largest fb */
>  	for_each_crtc(dev, crtc) {
>  		struct drm_i915_gem_object *obj =
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-07-15 15:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15 12:15 [PATCH 1/3] drm/i915: Unconditionally check gmch pfit state Daniel Vetter
2015-07-15 12:15 ` [PATCH 2/3] drm/i915: Clarify logic for initial modeset Daniel Vetter
2015-07-15 13:20   ` [PATCH 4/3] " Maarten Lankhorst
2015-07-15 15:16     ` Daniel Vetter [this message]
2015-07-15 12:15 ` [PATCH 3/3] drm/i915: Invert fastboot check Daniel Vetter

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=20150715151639.GA6223@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.