public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
From: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: airlied@redhat.com, daniel@ffwll.ch, jonathanh@nvidia.com,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 0/2] drm/tegra: handle implicit scanout modifiers
Date: Mon, 30 Jan 2023 14:49:09 +0000	[thread overview]
Message-ID: <20230130144909.d5iauozyvh5fk446@wslaptop> (raw)
In-Reply-To: <Y8/qRSBm715P3EnB@orome>

On Tue, Jan 24, 2023 at 03:25:09PM +0100, Thierry Reding wrote:
> On Fri, Jan 20, 2023 at 10:58:56AM +0000, Diogo Ivo wrote:
> > Hello!
> > 
> > This patch series adds support for correctly displaying tiled
> > framebuffers when no modifiers are reported by userspace.
> > 
> > Patch 1 adds the sector_layout parameter to the SET/GET_TILING
> > IOCTLs so that userspace can set this field appropriately.
> > 
> > Patch 2 adds handling of the case where the buffer object
> > passed to create a framebuffer is allocated with non-linear
> > tiling but no modifier is reported.
> > 
> > Diogo Ivo (2):
> >   drm/tegra: add sector layout to SET/GET_TILING IOCTLs
> >   drm/tegra: add scanout support for implicit tiling parameters
> > 
> >  drivers/gpu/drm/tegra/drm.c  | 29 ++++++++++++++++++
> >  drivers/gpu/drm/tegra/fb.c   | 59 ++++++++++++++++++++++++++++++++++--
> >  include/uapi/drm/tegra_drm.h | 16 ++++++----
> >  3 files changed, 96 insertions(+), 8 deletions(-)
> 
> We really don't want to use SET_TILING and GET_TILING IOCTLs anymore.
> These only exist for backwards compatibility with very old userspace.
> New code should use standard DRM/KMS mechanisms to deal with
> framebuffer modifiers.

Hello,

Thank you for your review! This implementation is basically a copy of
what vc4 already does when importing resources with no modifiers
specified by userspace.

I looked into the DRM/KMS infrastructure and did not find a mechanism
to do this, but perhaps I am missing something; if this is the case,
I would be happy to submit a more fitting implementation, since handling
these implicit modifiers allows us to lift the restriction of linear
scanout buffers.

Best regards,
Diogo

      reply	other threads:[~2023-01-30 14:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 10:58 [PATCH 0/2] drm/tegra: handle implicit scanout modifiers Diogo Ivo
2023-01-20 10:58 ` [PATCH 1/2] drm/tegra: add sector layout to SET/GET_TILING IOCTLs Diogo Ivo
2023-01-20 10:58 ` [PATCH 2/2] drm/tegra: add scanout support for implicit tiling parameters Diogo Ivo
2023-01-30 19:43   ` kernel test robot
2023-01-24 14:25 ` [PATCH 0/2] drm/tegra: handle implicit scanout modifiers Thierry Reding
2023-01-30 14:49   ` Diogo Ivo [this message]

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=20230130144909.d5iauozyvh5fk446@wslaptop \
    --to=diogo.ivo@tecnico.ulisboa.pt \
    --cc=airlied@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.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