From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Paulo Zanoni <paulo.r.zanoni@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: use size_t instead of u32 for stolen memory size variables
Date: Fri, 29 Sep 2017 16:11:41 +0300 [thread overview]
Message-ID: <1506690701.4729.91.camel@linux.intel.com> (raw)
In-Reply-To: <150667800136.27384.12327966259676066977@mail.alporthouse.com>
On Fri, 2017-09-29 at 10:40 +0100, Chris Wilson wrote:
> Quoting Joonas Lahtinen (2017-09-29 10:23:10)
> > On Tue, 2017-09-26 at 21:13 +0100, Chris Wilson wrote:
> > > Quoting Paulo Zanoni (2017-09-26 20:29:08)
> > > > Stolen memory pointers are dma_addr_t, which means they can be 64 bit
> > > > things. By using u32 we leave room for bugs in case we ever get huge
> > > > amounts of stolen memory. By using size_t we don't risk running into
> > > > those problems.
> > > >
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > ---
> > > > drivers/char/agp/intel-gtt.c | 10 +++++-----
> > > > drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
> > > > drivers/gpu/drm/i915/i915_gem_gtt.h | 6 +++---
> > > > drivers/gpu/drm/i915/i915_gem_stolen.c | 19 +++++++++----------
> > > > include/drm/intel-gtt.h | 2 +-
> > > > 5 files changed, 19 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> > > > index 9b6b602..a1db230 100644
> > > > --- a/drivers/char/agp/intel-gtt.c
> > > > +++ b/drivers/char/agp/intel-gtt.c
> > > > @@ -80,7 +80,7 @@ static struct _intel_private {
> > > > unsigned int needs_dmar : 1;
> > > > phys_addr_t gma_bus_addr;
> > > > /* Size of memory reserved for graphics by the BIOS */
> > > > - unsigned int stolen_size;
> > > > + size_t stolen_size;
> > >
> > > What is size_t? How does that correspond to a physical or dma addr?
> > > You either meant kernel_size_t or unsigned long, or a proper type for
> > > the address space.
> >
> > We're using phys_addr_t + size_t in early-quirks.c too, so we want to
> > keep both places consistent. If we're using something else than size_t,
> > then we should update both places (it's still on my todo to get rid of
> > the code duplication).
> >
>
> Re duplication: move the discovery into early-quirks and export the
> resource_t ?
Might be an idea, the biggest hurdle is that now early quirks are
__init so if you don't load i915, they have no impact on resident code
size, they get overridden. So pretty much any way will increase either
resident code or data memory size, so I've so far been looking to just
share the codebase some way. Because the code applies to _all_ x86.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-09-29 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-26 19:29 [PATCH 1/2] drm/i915: stolen_reserved_base is also dma_addr_t Paulo Zanoni
2017-09-26 19:29 ` [PATCH 2/2] drm/i915: use size_t instead of u32 for stolen memory size variables Paulo Zanoni
2017-09-26 20:11 ` Chris Wilson
2017-09-26 20:13 ` Chris Wilson
2017-09-29 9:23 ` Joonas Lahtinen
2017-09-29 9:40 ` Chris Wilson
2017-09-29 13:11 ` Joonas Lahtinen [this message]
2017-09-26 20:01 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: stolen_reserved_base is also dma_addr_t Patchwork
2017-09-26 20:10 ` [PATCH 1/2] " Chris Wilson
2017-09-27 5:29 ` ✗ Fi.CI.IGT: failure for series starting with [1/2] " 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=1506690701.4729.91.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox