All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@gmail.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 2/2] drm/i915: Introduce HAS_2PPC.
Date: Wed, 30 Aug 2017 21:40:06 -0700	[thread overview]
Message-ID: <CABVU7+vjyRui=gXiw-88fgR6yRAjuZZBR4gyHm8UYvJyo27BDw@mail.gmail.com> (raw)
In-Reply-To: <1504149563.9172.6.camel@dk-H97M-D3H>

On Wed, Aug 30, 2017 at 7:58 PM, Pandiyan, Dhinakaran
<dhinakaran.pandiyan@intel.com> wrote:
> On Wed, 2017-08-30 at 20:32 +0100, Chris Wilson wrote:
>> Quoting Pandiyan, Dhinakaran (2017-08-30 20:12:52)
>> > On Wed, 2017-08-16 at 17:54 -0700, Rodrigo Vivi wrote:
>> > > Let's make it easier to add platforms that supports 2 pixel per
>> > > clock.
>> > >
>> > > With spread checks per platform it was easy to miss one or
>> > > another spot leading to loose some time on debug.
>> > >
>> > > Hopefully this check would save some cases in the future.
>> > >
>> > > No functional change.
>> > >
>> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
>> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
>> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_drv.h    | 4 ++++
>> > >  drivers/gpu/drm/i915/i915_pci.c    | 2 ++
>> > >  drivers/gpu/drm/i915/intel_cdclk.c | 8 ++++----
>> > >  drivers/gpu/drm/i915/intel_pm.c    | 3 +--
>> > >  4 files changed, 11 insertions(+), 6 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> > > index 6c25c8520c87..94f5e6522e5e 100644
>> > > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > > @@ -748,6 +748,7 @@ struct intel_csr {
>> > >       func(is_lp); \
>> > >       func(is_alpha_support); \
>> > >       /* Keep has_* in alphabetical order */ \
>> > > +     func(has_2ppc); \
>> > >       func(has_64bit_reloc); \
>> > >       func(has_aliasing_ppgtt); \
>> > >       func(has_csr); \
>> > > @@ -3025,6 +3026,9 @@ intel_info(const struct drm_i915_private *dev_priv)
>> > >  #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
>> > >       (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>> > >
>> > > +/* Supports 2 pixel per clock */
>> > > +#define HAS_2PPC(dev_priv) ((dev_priv)->info.has_2ppc)
>> > > +
>> >
>> > How about
>> > #define HAS_2PPC(dev_priv) (IS_GEMINILAKE(dev_priv) ||
>> > INTEL_GEN(dev_priv) >= 10) ?
>> >
>> > I am not clear on what qualifies for a place in device_info, but
>> > defining it this way let's me go to the definition and quickly check
>> > which platform has 2 pixels per clock.

One thing I always wanted was to avoid 2 places to declare features &
capabilities.
Here or on the platform.

>>
>> A couple of rules of thumb for starting with:
>>
>> Use device_info if:
>>
>>  - it fundamentally changes how the device operates, such that knowing
>>    about it in debug logs is a key means of triage

I think on this one 2ppc qualifies

>>
>>  - number of branches x callsites > 8

2 * 5 > 8 in this case?
or I'm getting the number of "branches" incorrectly?

What I was trying to save as well is the addition of any next platform.
When adding the feature it would be easier to search for HAS_2PPC instead of
searching for glk or cnl and analising that individually to see if it
is 2pp before
 see if it applies to that platform.

But the reason that I put this patch on top is that I don't have
strong opinion here so
t would be fine for me to move on without ht.

Thanks,
Rodrigo.

>>    (some estimate of the cost of inclusion inside device_info vs
>>    savings in object code, for a more realistic estimate a branch will
>>    ~12 bytes (depending on the phase of the moon) and cost for device
>>    info will be the addition of a few strings, and a couple of calls
>>    to use those string, so at a guess 100 bytes.)
>
> That's an interesting back-of-the-envelope calculation. I suppose the
> compiler is also more likely to load device_info->gen into a register
> than device_info->has_2ppc.
>
>
>>
>> -Chris
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-08-31  4:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-17  0:54 [PATCH 1/2] drm/i915/cnl: Allow 2 pixel per clock on Cannonlake Rodrigo Vivi
2017-08-17  0:54 ` [PATCH 2/2] drm/i915: Introduce HAS_2PPC Rodrigo Vivi
2017-08-30 19:12   ` Pandiyan, Dhinakaran
2017-08-30 19:32     ` Chris Wilson
2017-08-31  2:58       ` Pandiyan, Dhinakaran
2017-08-31  4:40         ` Rodrigo Vivi [this message]
2017-08-31  7:59           ` Daniel Vetter
2017-08-17  1:28 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/cnl: Allow 2 pixel per clock on Cannonlake Patchwork
2017-08-30 18:14 ` [PATCH 1/2] " Pandiyan, Dhinakaran
2017-08-30 18:59   ` Ville Syrjälä

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='CABVU7+vjyRui=gXiw-88fgR6yRAjuZZBR4gyHm8UYvJyo27BDw@mail.gmail.com' \
    --to=rodrigo.vivi@gmail.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=rodrigo.vivi@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.