From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH] drm/i915: Simplify has_sagv
Date: Wed, 24 Oct 2018 10:23:08 -0700 [thread overview]
Message-ID: <20181024172308.GC3942@intel.com> (raw)
In-Reply-To: <87h8hbd540.fsf@intel.com>
On Wed, Oct 24, 2018 at 01:13:51PM +0300, Jani Nikula wrote:
> On Tue, 23 Oct 2018, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > But I thought while doing this I could consolidade it along with all
> > the other has_feature cases.
> >
> > I believe we should either have everything as info.has_feature or everything
> > as has_feature().
> >
> > for instance if we end up ever having 2 platforms of same gen where
> > one has_sagv and the other doesn't we would have that in the platform
> > definition while making us to define another codename and add it here
> > or even worse if we don't have a codename available like CNL_WITH_PORT_F :/
>
> If that is to be in device info, it doesn't require an extra codename,
> it requires an extra device info with the flag.
>
> This ties to the goal of making dev_priv->info a pointer to the static
> const data in i915_pci.c i.e. making ->info truly const. There's three
> categories of info:
>
> 1) immutable device properties
> 2) properties set once during probe, immutable afterwards
> 3) runtime
>
> Currently we more or less happily conflate these, along with some module
> parameters too. The mkwrite_device_info() use has profilerated much
> wider than it was ever intended; we need to nuke that.
>
> We also have HAS_FOO() and IS_FOO() macros that do checks on pci id or
> gen or platform or a combination of them. It's a mess, and it's not
> getting better without conscious effort.
I agree with all that you said.
We probably just disagree on how to make HAS_FOO(dev_priv) IS_FOO(dev_priv)
better.
In my opinion we should move towards adding all immutable device
properties that describe and differentiate the platforms inside
device info. With that consolidated there:
- code gets uniform
- minimize gen and platform checks spread all over the code
- it gets easier to add platforms
But nevermind, I won't insist on this path ;)
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> _______________________________________________
> 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
next prev parent reply other threads:[~2018-10-24 17:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 17:20 [PATCH] drm/i915: Simplify has_sagv Rodrigo Vivi
2018-10-22 6:28 ` Jani Nikula
2018-10-22 16:57 ` Rodrigo Vivi
2018-10-22 23:48 ` Paulo Zanoni
2018-10-23 0:06 ` Rodrigo Vivi
2018-10-23 0:32 ` Paulo Zanoni
2018-10-23 7:23 ` Jani Nikula
2018-10-23 19:05 ` Rodrigo Vivi
2018-10-24 10:13 ` Jani Nikula
2018-10-24 17:23 ` Rodrigo Vivi [this message]
2018-10-26 20:03 ` [PATCH] drm/i915: Simplify has_sagv function Rodrigo Vivi
2018-10-29 10:08 ` Jani Nikula
2018-10-29 18:58 ` Rodrigo Vivi
2018-10-22 13:13 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Simplify has_sagv Patchwork
2018-10-22 13:14 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-10-22 13:37 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-22 16:46 ` ✓ Fi.CI.IGT: " Patchwork
2018-10-22 17:20 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Simplify has_sagv (rev2) Patchwork
2018-10-22 17:37 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-22 20:42 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-10-26 21:21 ` ✗ Fi.CI.BAT: failure for drm/i915: Simplify has_sagv (rev3) Patchwork
2018-10-29 15:59 ` ✓ Fi.CI.BAT: success " Patchwork
2018-10-29 18:10 ` ✓ Fi.CI.IGT: " Patchwork
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=20181024172308.GC3942@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=lucas.demarchi@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.