From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
Date: Wed, 6 Mar 2019 16:52:11 +0200 [thread overview]
Message-ID: <20190306145211.GE3888@intel.com> (raw)
In-Reply-To: <155186470363.27405.3077845430175008319@skylake-alporthouse-com>
On Wed, Mar 06, 2019 at 09:31:48AM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-03-05 19:29:05)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > At some point people have started to assume that
> > pipe_offsets[] & co. are only populated for pipes and whatnot
> > that actually exist. That is in fact not currently true, but
> > we can easily make it so.
>
> Any benefits of knock on effect?
What kind of knock on effect we're thinking?
>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 146 +++++++++++++++++++++++---------
> > 1 file changed, 104 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> > index c42c5ccf38fe..9e610e4bdd7d 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -35,7 +35,37 @@
> > #define PLATFORM(x) .platform = (x), .platform_mask = BIT(x)
> > #define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1)
> >
> > -#define GEN_DEFAULT_PIPEOFFSETS \
> > +#define I845_PIPE_OFFSETS \
> > + .pipe_offsets = { \
> > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > + }, \
> > + .trans_offsets = { \
> > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > + }
> > +
> > +#define I9XX_PIPE_OFFSETS \
> > + .pipe_offsets = { \
> > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > + }, \
> > + .trans_offsets = { \
> > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > + }
> > +
> > +#define IVB_PIPE_OFFSETS \
> > + .pipe_offsets = { \
> > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > + [TRANSCODER_C] = PIPE_C_OFFSET, \
> > + }, \
> > + .trans_offsets = { \
> > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > + [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
> > + }
> > +
> > +#define HSW_PIPE_OFFSETS \
> > .pipe_offsets = { \
> > [TRANSCODER_A] = PIPE_A_OFFSET, \
> > [TRANSCODER_B] = PIPE_B_OFFSET, \
> > @@ -49,7 +79,7 @@
> > [TRANSCODER_EDP] = TRANSCODER_EDP_OFFSET, \
> > }
> >
> > -#define GEN_CHV_PIPEOFFSETS \
> > +#define CHV_PIPE_OFFSETS \
> > .pipe_offsets = { \
> > [TRANSCODER_A] = PIPE_A_OFFSET, \
> > [TRANSCODER_B] = PIPE_B_OFFSET, \
> > @@ -61,11 +91,30 @@
> > [TRANSCODER_C] = CHV_TRANSCODER_C_OFFSET, \
> > }
> >
> > -#define CURSOR_OFFSETS \
> > - .cursor_offsets = { CURSOR_A_OFFSET, CURSOR_B_OFFSET, CHV_CURSOR_C_OFFSET }
> > +#define I845_CURSOR_OFFSETS \
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + }
> > +
> > +#define I9XX_CURSOR_OFFSETS \
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + [PIPE_B] = CURSOR_B_OFFSET, \
> > + }
> > +
> > +#define CHV_CURSOR_OFFSETS \
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + [PIPE_B] = CURSOR_B_OFFSET, \
> > + [PIPE_C] = CHV_CURSOR_C_OFFSET, \
> > + }
> >
> > #define IVB_CURSOR_OFFSETS \
> > - .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, IVB_CURSOR_C_OFFSET }
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + [PIPE_B] = IVB_CURSOR_B_OFFSET, \
> > + [PIPE_C] = IVB_CURSOR_C_OFFSET, \
> > + }
>
> Ok, those tables all match up with my understanding and rummaging.
>
> > static const struct intel_device_info intel_i865g_info = {
> > - GEN2_FEATURES,
> > + I845_FEATURES,
>
> Hmm, 865g had dvo in addition to vga (unlike 845g)
845g doesn't have dvo? The docs don't seem to quite agree with that.
I should probably hunt one down just to complete my gen2 collection :)
> so did it have a
> second pipe? Though memory says dual pipe was a luxury of mobile only.
Yeah, single pipe only I'm afraid.
>
> > PLATFORM(INTEL_I865G),
> > };
> > #define G75_FEATURES \
> > @@ -404,6 +465,7 @@ static const struct intel_device_info intel_valleyview_info = {
>
> Grr.
>
> > .display.has_psr = 1, \
> > .display.has_dp_mst = 1, \
> > .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > + HSW_PIPE_OFFSETS, \
>
> Was thinking vlv using HSW? but then realised that diff was misleading.
I rather dislike these template macros for this exact reason.
>
> And the device tables look to be using the correct feature sets.
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Thanks.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-03-06 14:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 19:29 [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately Ville Syrjala
2019-03-05 21:16 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-03-06 1:42 ` ✓ Fi.CI.IGT: " Patchwork
2019-03-06 9:31 ` [PATCH] " Chris Wilson
2019-03-06 14:52 ` Ville Syrjälä [this message]
2019-03-06 14:55 ` Chris Wilson
2019-03-06 15:13 ` Ville Syrjälä
2019-03-06 17:42 ` Lucas De Marchi
2019-03-06 17:55 ` Ville Syrjälä
2019-03-06 17:58 ` Ville Syrjälä
2019-03-06 18:01 ` Ville Syrjälä
2019-03-06 18:58 ` Lucas De Marchi
2019-03-06 18:55 ` Lucas De Marchi
2019-03-06 19:00 ` Ville Syrjälä
2019-03-06 20:25 ` 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=20190306145211.GE3888@intel.com \
--to=ville.syrjala@linux.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.