dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: "Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>, dri-devel@lists.freedesktop.org
Subject: userptr support in drm drivers
Date: Tue, 16 Feb 2016 20:58:15 +0100	[thread overview]
Message-ID: <20160216205815.28ac3080@endymion> (raw)

Hi all,

While checking the openSUSE kernel configuration, I noticed a couple
oddities regarding userptr support in the i915, radeon and amdgpu drm
drivers. I'll like to discuss the current situation and come up with an
agreement on how this could be cleaned up.

Firstly, i915. This driver has userptr code under #if
defined(CONFIG_MMU_NOTIFIER), however it neither selects this option nor
depends on it. Given that CONFIG_MMU_NOTIFIER is not a user-visible
option (it can only be selected by other kernel configuration options),
it means that you get full userptr support or not depending on other
unrelated kernel options. This isn't good.

Secondly, radeon and amdgpu. They are slightly better in that they have
Kconfig options selecting CONFIG_MMU_NOTIFIER (DRM_RADEON_USERPTR and
DRM_AMDGPU_USERPTR respectively.) However I still find it confusing
that full userptr support is under #if defined(CONFIG_MMU_NOTIFIER),
and not under #if defined(CONFIG_RADEON_USERPTR), resp. #if
defined(CONFIG_AMDGPU_USERPTR). It means that full userptr support may
be included even if these options are disabled.

I am not too familiar with MMU and this userptr stuff, but from where I
stand, only two approaches make sense:

* Either there is a good reason why people may want to disable full
  userptr support. In this case options CONFIG_RADEON_USERPTR and
  CONFIG_AMDGPU_USERPTR should really enable the code in question, it
  should not be built without these options. And a similar option
  should be introduced for the i915 driver to the same effect. Or
  alternatively a single option for the whole DRM subsystem may make
  more sense, as I doubt anyone would want to enable support in one
  driver and disable it in another.

* Or there is no specific reason why people would want to disable full
  userptr support, in which case options CONFIG_RADEON_USERPTR and
  CONFIG_AMDGPU_USERPTR should be removed and all 3 drivers should
  unconditionally select CONFIG_MMU_NOTIFIER.

If the sole purpose of these these settings is for development or
debugging purposes, I'd go for option 1 with a run-time option to
disable full userptr (drm.userptr=ro or some such.)

As a general rule, fewer configuration options is better.

Once a decision is made, I volunteer to write the patches.

Thanks,
-- 
Jean Delvare
SUSE L3 Support
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2016-02-16 19:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 19:58 Jean Delvare [this message]
2016-02-16 20:33 ` userptr support in drm drivers Christian König
2016-02-16 21:14   ` Daniel Vetter
2016-02-18  8:59     ` Jean Delvare
2016-02-18  9:48       ` Christian König
2016-02-19 14:11         ` Jean Delvare
2016-02-19 14:58           ` Christian König
2016-02-29 15:35             ` Daniel Vetter
2016-02-18  8:49   ` Jean Delvare

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=20160216205815.28ac3080@endymion \
    --to=jdelvare@suse.de \
    --cc=alexander.deucher@amd.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@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 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).