All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable
Date: Mon, 10 Feb 2014 16:17:10 +0200	[thread overview]
Message-ID: <20140210141709.GO3891@intel.com> (raw)
In-Reply-To: <20140210140616.GD9282@strange.amr.corp.intel.com>

On Mon, Feb 10, 2014 at 02:06:16PM +0000, Damien Lespiau wrote:
> On Mon, Feb 10, 2014 at 02:53:29PM +0200, Ville Syrjälä wrote:
> > > Since every access should now go through the macro I think it'd be good to
> > > give this a __ prefix to make it clear that users better think twice
> > > before using it. Maybe as a patch on top of all this?
> > 
> > No. Everyone having to use the macro was a requirement of the v2 patch.
> > With v3 that requirement was lifted since the const is right there on
> > the struct itself. I think that was the whole point of v3.
> 
> The "everyone should now go through the macro" is not for the const.
> There's a new idea floating around to replace the macros by hardcoded
> values to be able to compile the driver for a specific platform and use
> the compiler dead code elimiation pass(es) to reduce the text size.
> 
> There may be more cunning ways to reduce the driver size, haven't
> thought much about it.

One easy thing to do would be just dropping the unused output types
from the driver when doing the special build. I'd be surprised if
the compiler is smart enough to figure that stuff out with the
function pointer indirections we do there. Not sure how much we'd
save though.

Or just make kernel memory swappable ;)

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-02-10 14:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 19:12 Supporting fused display configurations v5 Damien Lespiau
2014-02-07 19:12 ` [PATCH 1/8] drm/i915: Always use INTEL_INFO() to access the device_info structure Damien Lespiau
2014-02-07 19:12 ` [PATCH 2/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable Damien Lespiau
2014-02-10  9:09   ` Daniel Vetter
2014-02-10 12:49     ` Jani Nikula
2014-02-10 12:53     ` Ville Syrjälä
2014-02-10 14:06       ` Damien Lespiau
2014-02-10 14:17         ` Ville Syrjälä [this message]
2014-02-10 16:54           ` Daniel Vetter
2014-02-10 16:55       ` Daniel Vetter
2014-02-07 19:12 ` [PATCH 3/8] drm/i915: Move num_plane to the intel_device_info structure Damien Lespiau
2014-02-07 19:12 ` [PATCH 4/8] drm/i915: Consolidate FUSE_STRAP in one set of defines Damien Lespiau
2014-02-07 19:12 ` [PATCH 5/8] drm/i915: Disable display when fused off Damien Lespiau
2014-02-10  9:12   ` Daniel Vetter
2014-02-10 17:19     ` [PATCH 5/8 v5] " Damien Lespiau
2014-02-07 19:12 ` [PATCH 6/8] drm/i915: Use I915_MAX_PIPES in the pipe/plane_to_crtc_mapping definitions Damien Lespiau
2014-02-07 19:12 ` [PATCH 7/8] drm/i915: Reorder i915_params fields to not create holes Damien Lespiau
2014-02-07 19:12 ` [PATCH 8/8] drm/i915: Provide a command line option to disable display Damien Lespiau
2014-02-10  9:13   ` Daniel Vetter
2014-02-10 17:20     ` [PATCH 8/8 v2] " Damien Lespiau
2014-02-10 18:24       ` 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=20140210141709.GO3891@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=damien.lespiau@intel.com \
    --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.