linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Eric Anholt <eric@anholt.net>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>,
	Eben Upton <eben@raspberrypi.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2 1/2] drm/file: Rehabilitate the firstopen hook for non-legacy drivers
Date: Thu, 21 Mar 2019 16:27:06 +0100	[thread overview]
Message-ID: <82618ee8c2a2380a62b1fb894e5c35c602e20f3d.camel@bootlin.com> (raw)
In-Reply-To: <87zhpph4c2.fsf@anholt.net>

Hi,

Le mercredi 20 mars 2019 à 09:56 -0700, Eric Anholt a écrit :
> Paul Kocialkowski <paul.kocialkowski@bootlin.com> writes:
> 
> > The firstopen DRM driver hook was initially used to perform hardware
> > initialization, which is now considered legacy. Only a single user of
> > firstopen remains at this point (savage).
> > 
> > In some specific cases, non-legacy drivers may also need to implement
> > these hooks. For instance on VC4, we need to allocate a 16 MiB buffer
> > for the GPU. Because it's not required for fbcon, it's a waste to
> > allocate it before userspace starts using the DRM device.
> > 
> > Using firstopen and lastclose for this allocation seems like the best
> > fit, so re-habilitate the hook to allow it to be called for non-legacy
> > drivers.
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> >  drivers/gpu/drm/drm_file.c | 3 +--
> >  include/drm/drm_drv.h      | 2 +-
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index b1838a41ad43..c011b5cbfb6b 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -266,8 +266,7 @@ static int drm_setup(struct drm_device * dev)
> >  {
> >  	int ret;
> >  
> > -	if (dev->driver->firstopen &&
> > -	    drm_core_check_feature(dev, DRIVER_LEGACY)) {
> > +	if (dev->driver->firstopen) {
> >  		ret = dev->driver->firstopen(dev);
> >  		if (ret != 0)
> >  			return ret;
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index ca46a45a9cce..aa14607e54d4 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -236,7 +236,7 @@ struct drm_driver {
> >  	 * to set/unset the VT into raw mode.
> >  	 *
> >  	 * Legacy drivers initialize the hardware in the @firstopen callback,
> > -	 * which isn't even called for modern drivers.
> > +	 * modern drivers can use it for other purposes only.
> >  	 */
> >  	void (*lastclose) (struct drm_device *);
> 
> Our usage in vc4 is not very different from what we called "hardware
> initialization" in other devices.  I would rather just delete this
> sentence entirely.

Sounds good to me!

> The only alternative I can think of to using a firstopen/lastclose-style
> allocation for this would be to allocate the bin bo on the first
> (non-dumb?) V3D BO allocation and refcount those to free the binner.

I don't see other options either, and using firstclose/lastopen feels
overall more readable in the driver code.

I'm not sure there is such a big overhead associated with allocating
the binner BO (it seems that the current implementation tries to alloc
until the specific memory constraints for the buffer are met, so
perhaps that can take time). But if there is, I suppose it's best to
have that when starting up rather than delaying the first render
operation.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


  reply	other threads:[~2019-03-21 15:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 15:48 [PATCH v2 0/2] drm/vc4: Binner BO management improvements Paul Kocialkowski
2019-03-20 15:48 ` [PATCH v2 1/2] drm/file: Rehabilitate the firstopen hook for non-legacy drivers Paul Kocialkowski
2019-03-20 16:56   ` Eric Anholt
2019-03-21 15:27     ` Paul Kocialkowski [this message]
2019-03-21 23:12       ` Eric Anholt
2019-03-28 18:53       ` Daniel Vetter
2019-03-29  9:09         ` Daniel Stone
2019-03-29 15:02           ` Paul Kocialkowski
2019-03-29 15:25             ` Daniel Vetter
2019-03-29 15:49               ` Paul Kocialkowski
2019-03-29 18:14                 ` Eric Anholt
2019-03-29 18:42                   ` Daniel Stone
2019-03-29 20:21                     ` Paul Kocialkowski
2019-03-29 15:07         ` Paul Kocialkowski
2019-03-20 15:48 ` [PATCH v2 2/2] drm/vc4: Allocated/liberate the binner BO at firstopen/lastclose Paul Kocialkowski
2019-03-20 16:58   ` Eric Anholt
2019-03-21 15:58     ` Paul Kocialkowski
2019-03-21 16:20       ` Eric Anholt

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=82618ee8c2a2380a62b1fb894e5c35c602e20f3d.camel@bootlin.com \
    --to=paul.kocialkowski@bootlin.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eben@raspberrypi.org \
    --cc=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=sean@poorly.run \
    --cc=thomas.petazzoni@bootlin.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;
as well as URLs for NNTP newsgroup(s).