All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 37/37] drm/i915: Implement .get_format_info() hook for CCS
Date: Mon, 21 Nov 2016 16:37:50 +0200	[thread overview]
Message-ID: <20161121143750.GX31595@intel.com> (raw)
In-Reply-To: <20161118233146.GA24038@mail.bwidawsk.net>

On Fri, Nov 18, 2016 at 03:31:48PM -0800, Ben Widawsky wrote:
> On 16-11-18 21:53:13, Ville Syrjälä wrote:
> >From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> >By providing our own format information for the CCS formats, we should
> >be able to make framebuffer_check() do the right thing for the CCS
> >surface as well.
> >
> 
> I was hoping to see that patch as well :-). If you're adding the new fb
> modifiers, I think it'd make sense to make it part of this series.
> Alternatively, I can take 36, and 37 and make it part of my series, then
> integrate that last bit. It's up to you.
> 
> >Note that we'll return the same format info for both Y and Yf tiled
> >format as that's what happens with the non-CCS Y vs. Yf as well. If
> >desired, we could potentially return a unique pointer for each
> >pixel_format+tiling+ccs combination, in which case we immediately be
> >able to tell if any of that stuff changed by just comparing the
> >pointers. But that does sound a bit wasteful space wise.
> >
> >Cc: Ben Widawsky <ben@bwidawsk.net>
> >Cc: intel-gfx@lists.freedesktop.org
> >Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> I have a comment below however, you can consider it:
> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
> 
> >---
> > drivers/gpu/drm/i915/intel_display.c | 37 ++++++++++++++++++++++++++++++++++++
> > include/uapi/drm/drm_fourcc.h        |  3 +++
> > 2 files changed, 40 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >index 7b7135be3b9e..de6909770c68 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -2488,6 +2488,42 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t fb_modifier)
> > 	}
> > }
> >
> >+static const struct drm_format_info ccs_formats[] = {
> >+	{ .format = DRM_FORMAT_XRGB8888, .depth = 24, .num_planes = 2, .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> >+	{ .format = DRM_FORMAT_XBGR8888, .depth = 24, .num_planes = 2, .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> >+	{ .format = DRM_FORMAT_ARGB8888, .depth = 32, .num_planes = 2, .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> >+	{ .format = DRM_FORMAT_ABGR8888, .depth = 32, .num_planes = 2, .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> >+};
> >+
> >+static const struct drm_format_info *
> >+lookup_format_info(const struct drm_format_info formats[],
> >+		   int num_formats, u32 format)
> >+{
> >+	int i;
> >+
> >+	for (i = 0; i < num_formats; i++) {
> >+		if (formats[i].format == format)
> >+			return &formats[i];
> >+	}
> >+
> >+	return NULL;
> >+}
> >+
> >+static const struct drm_format_info *
> >+intel_get_format_info(struct drm_device *dev,
> >+		      const struct drm_mode_fb_cmd2 *cmd)
> >+{
> >+	switch (cmd->modifier[0]) {
> >+	case I915_FORMAT_MOD_Y_TILED_CCS:
> >+	case I915_FORMAT_MOD_Yf_TILED_CCS:
> >+		return lookup_format_info(ccs_formats,
> >+					  ARRAY_SIZE(ccs_formats),
> >+					  cmd->pixel_format);
> >+	default:
> >+		return NULL;
> >+	}
> >+}
> >+
> 
> It sort of seems like somewhat of a waste to provide this if implementations are
> allowed to return NULL. It's like saying, "DRM core will check stuff for you if
> you provide the info, but you don't have to do it if you don't want to."

The core will check the stuff anyway. The NULL just means "I don't have
any special requirements, so the core format info will be sufficient".

> If
> that's the case you may as well provide a driver hook to just do the check, ie.
> s/mod_funcs->get_format_info/mode_functs->check_format/

Drivers already have to do a bunch of checks in .fb_create(). In
addition the core does some basic sanity checks before the driver
even sees the mode_cmd (except for the new .get_format_info() hook
that is). I don't want every driver to have to duplicate all of these
basic sanity checks.

One alternative to this scheme would be have a helper function that
every driver would call in .fb_create() that would do these basic sanity
checks. That way we wouldn't need the extra hook, with a slight risk
that driver would forget to call the helper.

> 
> > static int
> > intel_fill_fb_info(struct drm_i915_private *dev_priv,
> > 		   struct drm_framebuffer *fb)
> >@@ -15922,6 +15958,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
> >
> > static const struct drm_mode_config_funcs intel_mode_funcs = {
> > 	.fb_create = intel_user_framebuffer_create,
> >+	.get_format_info = intel_get_format_info,
> > 	.output_poll_changed = intel_fbdev_output_poll_changed,
> > 	.atomic_check = intel_atomic_check,
> > 	.atomic_commit = intel_atomic_commit,
> >diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >index a5890bf44c0a..2926d916f199 100644
> >--- a/include/uapi/drm/drm_fourcc.h
> >+++ b/include/uapi/drm/drm_fourcc.h
> >@@ -218,6 +218,9 @@ extern "C" {
> >  */
> > #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> >
> >+#define I915_FORMAT_MOD_Y_TILED_CCS	fourcc_mod_code(INTEL, 4)
> >+#define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
> >+
> > /*
> >  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> >  *
> 
> -- 
> Ben Widawsky, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-11-21 14:37 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-18 19:52 [PATCH v2 00/37] drm: Deduplicate fb format information (v2) ville.syrjala
2016-11-18 19:52 ` [PATCH 01/37] drm/i915: Add local 'fb' variables ville.syrjala
2016-11-30 14:44   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 02/37] drm/radeon: " ville.syrjala
2016-11-18 19:52 ` [PATCH 03/37] drm/radeon: Use DIV_ROUND_UP() ville.syrjala
2016-11-18 19:52 ` [PATCH 04/37] drm/mgag200: Add local 'fb' variable ville.syrjala
2016-11-30 14:45   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 05/37] drm/ast: Add local 'fb' variables ville.syrjala
2016-11-30 14:47   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 06/37] drm/gma500: Add some " ville.syrjala
2016-11-30 14:49   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 07/37] drm/cirrus: " ville.syrjala
2016-11-30 14:50   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 08/37] drm/arcpgu: Add " ville.syrjala
2016-11-21 15:30   ` Alexey Brodkin
2016-11-23 16:00   ` Alexey Brodkin
2016-11-18 19:52 ` [PATCH 09/37] drm/arm: " ville.syrjala
2016-11-18 20:30   ` Brian Starkey
2016-11-21 11:51   ` Liviu Dudau
2016-11-22 13:48     ` Ville Syrjälä
2016-11-22 13:57       ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 10/37] drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail ville.syrjala
2016-11-30 14:56   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 11/37] drm/nouveau: Add local 'fb' variables ville.syrjala
2016-11-30 14:57   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 12/37] drm/vmwgfx: Populate fb->dev before drm_framebuffer_init() ville.syrjala
2016-11-21 17:10   ` Sinclair Yeh
2016-11-22 13:53   ` [PATCH v2 " ville.syrjala
2016-11-18 19:52 ` [PATCH 13/37] drm: Pass 'dev' to drm_helper_mode_fill_fb_struct() ville.syrjala
2016-12-14 20:48   ` [PATCH v2 " ville.syrjala
2016-11-18 19:52 ` [PATCH 14/37] drm/vmwgfx: Populate fb->pixel_format ville.syrjala
2016-11-21 17:10   ` Sinclair Yeh
2016-11-18 19:52 ` [PATCH 15/37] drm/qxl: Call drm_helper_mode_fill_fb_struct() before drm_framebuffer_init() ville.syrjala
2016-11-18 19:52 ` [PATCH 16/37] drm/virtio: " ville.syrjala
2016-11-30 15:32   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 17/37] drm/i915: Set fb->dev early on for inherited fbs ville.syrjala
2016-11-30 15:36   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH v2 18/37] drm: Populate fb->dev from drm_helper_mode_fill_fb_struct() ville.syrjala
2016-11-18 19:52 ` [PATCH v2 19/37] drm: Store a pointer to drm_format_info under drm_framebuffer ville.syrjala
2016-11-19  2:33   ` Laurent Pinchart
2016-11-18 19:52 ` [PATCH 20/37] drm/vmwgfx: Populate fb->format correctly ville.syrjala
2016-11-30 15:40   ` Daniel Vetter
2016-11-30 16:03     ` Ville Syrjälä
2016-11-30 16:09       ` Laurent Pinchart
2016-11-30 17:22         ` Daniel Vetter
2016-11-30 15:52   ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 21/37] drm/i915: Populate fb->format early for inherited fbs ville.syrjala
2016-11-30 15:42   ` Daniel Vetter
2016-11-30 15:57     ` Ville Syrjälä
2016-11-30 16:09     ` Daniel Vetter
2016-11-18 19:52 ` [PATCH 22/37] drm: Reject fbs w/o format info in drm_framebuffer_init() ville.syrjala
2016-11-19  2:36   ` Laurent Pinchart
2016-11-18 19:52 ` [PATCH 23/37] drm: Replace drm_format_num_planes() with fb->format->num_planes ville.syrjala
2016-11-19  2:41   ` Laurent Pinchart
2016-12-14 21:30   ` [PATCH v2 " ville.syrjala
2016-11-18 19:53 ` [PATCH 24/37] drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm code ville.syrjala
2016-11-30 15:51   ` [Intel-gfx] " Daniel Vetter
2016-11-30 15:59     ` Ville Syrjälä
2016-11-18 19:53 ` [PATCH 25/37] drm: Replace drm_format_plane_cpp() with fb->format->cpp[] ville.syrjala
2016-11-19  2:44   ` Laurent Pinchart
2016-12-14 21:30   ` [PATCH v2 " ville.syrjala
2016-11-18 19:53 ` [PATCH 26/37] drm/fb_cma_helper: Replace drm_format_info() with fb->format ville.syrjala
2016-11-18 19:53 ` [PATCH 27/37] drm/nouveau: Use fb->format rather than drm_format_info() ville.syrjala
2016-11-30 15:59   ` Daniel Vetter
2016-11-18 19:53 ` [PATCH 28/37] drm/i915: Store a pointer to the pixel format info for fbc ville.syrjala
2016-11-30 16:07   ` [Intel-gfx] " Daniel Vetter
2016-11-18 19:53 ` [PATCH 29/37] drm: Add drm_framebuffer_plane_{width,height}() ville.syrjala
2016-11-18 19:53 ` [PATCH 30/37] drm/i915: Use drm_framebuffer_plane_{width, height}() where possible ville.syrjala
2016-11-30 16:04   ` Daniel Vetter
2016-11-30 16:06   ` [Intel-gfx] " Daniel Vetter
2016-11-18 19:53 ` [PATCH 31/37] drm: Nuke fb->depth ville.syrjala
2016-11-30 16:01   ` Daniel Vetter
2016-12-14 21:31   ` [PATCH v2 " ville.syrjala
2016-11-18 19:53 ` [PATCH v2 32/37] drm: Nuke fb->bits_per_pixel ville.syrjala
2016-12-14 21:32   ` [PATCH v3 " ville.syrjala
2016-11-18 19:53 ` [PATCH v2 33/37] drm: Nuke fb->pixel_format ville.syrjala
2016-11-19  2:55   ` Laurent Pinchart
2016-12-14 21:32   ` [PATCH v3 " ville.syrjala
2016-11-18 19:53 ` [PATCH 34/37] drm: Replace 'format->format' comparisons to just 'format' comparisons ville.syrjala
2016-11-19  2:56   ` Laurent Pinchart
2016-11-18 19:53 ` [PATCH 35/37] drm: Eliminate the useless "non-RGB fb" debug message ville.syrjala
2016-11-19  2:57   ` Laurent Pinchart
2016-11-18 19:53 ` [PATCH 36/37] drm: Add mode_config .get_format_info() hook ville.syrjala
2016-11-20  8:13   ` Laurent Pinchart
2016-11-21 13:18     ` Ville Syrjälä
2016-11-21 13:23       ` Laurent Pinchart
2016-11-21 13:31         ` Ville Syrjälä
2016-11-21 13:42           ` Laurent Pinchart
2016-11-21 14:25             ` Ville Syrjälä
2016-11-22 13:41   ` [PATCH v2 " ville.syrjala
2016-11-18 19:53 ` [PATCH 37/37] drm/i915: Implement .get_format_info() hook for CCS ville.syrjala
2016-11-18 23:31   ` Ben Widawsky
2016-11-21 14:37     ` Ville Syrjälä [this message]
2016-11-21  8:42   ` [Intel-gfx] " Tvrtko Ursulin
2016-11-21 13:27     ` Ville Syrjälä
2016-11-21 14:04       ` Tvrtko Ursulin
2016-11-21 11:18 ` [PATCH v2 00/37] drm: Deduplicate fb format information (v2) Christian König
2016-12-14 21:37 ` Ville Syrjälä
2016-12-15 13:41   ` 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=20161121143750.GX31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=ben@bwidawsk.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.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.