All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
To: "chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 10/18] drm/i915: introduce is_active/activate/deactivate to the FBC terminology
Date: Wed, 21 Oct 2015 17:45:33 +0000	[thread overview]
Message-ID: <1445449533.2522.61.camel@intel.com> (raw)
In-Reply-To: <20151021123420.GM2551@nuc-i3427.alporthouse.com>

Em Qua, 2015-10-21 às 13:34 +0100, Chris Wilson escreveu:
> On Tue, Oct 20, 2015 at 11:49:56AM -0200, Paulo Zanoni wrote:
> > The long term goal is to have enable/disable as the higher level
> > functions and activate/deactivate as the lower level functions,
> > just
> > like we do for PSR and for the CRTC. Let's start this by renaming
> > the
> > functions that touch the hardware state and their wrappers.
> 
> So enable() calls activate() and disable() calls deactivate(). So
> what's the
> benefit? 

I explained each individual change on its own patch, but I guess I
should have put a higher level description here. Will fix this in v2.

With just this patch there's really no benefit. The main benefit is patch 12, when we actually have separate enable/disable and activate/deactivate functions.

One of the main points is that enable/disable are called once per modeset, while update/activate/deactivate can be called tons of times during normal operation, so moving code to enable() when possible makes sure it is not ran over and over again unnecessarily.


> What mistakes and confusion are made right now 

The confusion right now is that we don't have the real higher level
enable/disable that we get on patch 12.

> and is the
> mismatch between low/high worth it? This is your chance to justify
> the
> churn and sell us on the new naming scheme, and explain your long
> term
> vision in making the driver consistent everywhere.

Maybe I should just redirect users to patch 12 on the commit, since
this patch does not add any value by itself. I could have squashed this
and 12, but I don't like huge patches: they're not easy to review and
are a pain to rebase.

Anyway, v2 will hopefully have a better commit message.

> -Chris
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-10-21 17:45 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 13:49 [PATCH 00/18] Yet another FBC series Paulo Zanoni
2015-10-20 13:49 ` [PATCH 01/18] drm/i915: change no_fbc_reason from enum to string Paulo Zanoni
2015-10-21  6:52   ` Daniel Vetter
2015-10-20 13:49 ` [PATCH 02/18] drm/i915: don't stop+start FBC at every flip Paulo Zanoni
2015-10-21  7:04   ` Daniel Vetter
2015-10-21  7:12     ` Ville Syrjälä
2015-10-21  7:40       ` Ville Syrjälä
2015-10-20 13:49 ` [PATCH 03/18] drm/i915: only nuke FBC when a drawing operation triggers a flush Paulo Zanoni
2015-10-20 15:59   ` Chris Wilson
2015-10-21 17:08     ` Zanoni, Paulo R
2015-10-21 17:31       ` chris
2015-10-21 17:51         ` Zanoni, Paulo R
2015-10-20 13:49 ` [PATCH 04/18] drm/i915: extract crtc_is_valid() on the FBC code Paulo Zanoni
2015-10-20 15:52   ` Chris Wilson
2015-10-21 17:16     ` Zanoni, Paulo R
2015-10-21 17:28       ` chris
2015-10-22  7:52   ` Maarten Lankhorst
2015-10-22 19:26     ` Zanoni, Paulo R
2015-10-22 19:42       ` Ville Syrjälä
2015-10-20 13:49 ` [PATCH 05/18] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work Paulo Zanoni
2015-10-20 16:03   ` Chris Wilson
2015-10-21 17:27     ` Zanoni, Paulo R
2015-10-21 18:15       ` chris
2015-10-20 13:49 ` [PATCH 06/18] drm/i915: use struct intel_crtc *crtc at __intel_fbc_update() Paulo Zanoni
2015-10-20 13:49 ` [PATCH 07/18] drm/i915: fix the __intel_fbc_update() comments Paulo Zanoni
2015-10-21 12:37   ` Chris Wilson
2015-10-21 17:32     ` Zanoni, Paulo R
2015-10-21 17:38       ` chris
2015-10-22 20:15         ` Zanoni, Paulo R
2015-10-20 13:49 ` [PATCH 08/18] drm/i915: pass the crtc as an argument to intel_fbc_update() Paulo Zanoni
2015-10-20 13:49 ` [PATCH 09/18] drm/i915: don't disable_fbc() if FBC is already disabled Paulo Zanoni
2015-10-20 13:49 ` [PATCH 10/18] drm/i915: introduce is_active/activate/deactivate to the FBC terminology Paulo Zanoni
2015-10-21 12:34   ` Chris Wilson
2015-10-21 17:45     ` Zanoni, Paulo R [this message]
2015-10-21 17:55       ` chris
2015-10-20 13:49 ` [PATCH 11/18] drm/i915: refactor FBC deactivation at init Paulo Zanoni
2015-10-21 12:59   ` Chris Wilson
2015-10-20 13:49 ` [PATCH 12/18] drm/i915: introduce intel_fbc_{enable, disable} Paulo Zanoni
2015-10-20 15:55   ` Chris Wilson
2015-10-20 13:49 ` [PATCH 13/18] drm/i915: remove too-frequent FBC debug message Paulo Zanoni
2015-10-21 13:01   ` Chris Wilson
2015-10-21 18:19     ` Zanoni, Paulo R
2015-10-22 19:52       ` chris
2015-10-20 13:50 ` [PATCH 14/18] drm/i915: fix the CFB size check Paulo Zanoni
2015-10-20 13:50 ` [PATCH 15/18] drm/i915: alloc/free the FBC CFB during enable/disable Paulo Zanoni
2015-10-21  7:11   ` Daniel Vetter
2015-10-21  7:20     ` Ville Syrjälä
2015-10-21  7:24       ` Daniel Vetter
2015-10-21 18:30         ` Zanoni, Paulo R
2015-10-22  7:59           ` Daniel Vetter
2015-10-20 13:50 ` [PATCH 16/18] drm/i915: move adjusted_mode checks from fbc_update to fbc_enable Paulo Zanoni
2015-10-20 13:50 ` [PATCH 17/18] drm/i915: move clock frequency " Paulo Zanoni
2015-10-20 13:50 ` [PATCH 18/18] drm/i915: check for FBC planes in the same place as the pipes Paulo Zanoni
2015-10-20 21:22 ` [PATCH igt 1/4] kms_frontbuffer_tracking: unset crtcs after getting the base blue CRC Paulo Zanoni
2015-10-20 21:22   ` [PATCH igt 2/4] kms_frontbuffer_tracking: add flag to not assert feature status Paulo Zanoni
2015-10-20 21:22   ` [PATCH igt 3/4] kms_frontbuffer_tracking: add stridechange subtest Paulo Zanoni
2015-10-20 21:22   ` [PATCH igt 4/4] kms_frontbuffer_tracking: remove opt.only_feature Paulo Zanoni

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=1445449533.2522.61.camel@intel.com \
    --to=paulo.r.zanoni@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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 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.