dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org,
	Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Christoph Hellwig <hch@infradead.org>,
	Jagan Teki <jagan@amarulasolutions.com>,
	John Hubbard <jhubbard@nvidia.com>,
	stanislaw.gruszka@intel.com,
	Jeffrey Hugo <quic_jhugo@quicinc.com>,
	Arnd Bergmann <arnd@arndb.de>, Jiho Chu <jiho.chu@samsung.com>,
	Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
	Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oded Gabbay <ogabbay@kernel.org>,
	linux-kernel@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major
Date: Tue, 8 Nov 2022 08:28:19 -0400	[thread overview]
Message-ID: <Y2pLYxW8p0QeiV+3@nvidia.com> (raw)
In-Reply-To: <CAPM=9twxu3v4voSukrkror1BrajShRLY9CFxYWpL2rwK7fMiKQ@mail.gmail.com>

On Tue, Nov 08, 2022 at 06:33:23AM +1000, Dave Airlie wrote:

> At plumbers we decided a direction, I think the direction is good, if
> there is refactoring to be done, I'd rather it was done in tree with a
> clear direction.
> 
> Coming in now and saying we should go down a different path isn't
> really helpful. We need to get rolling on this, we have drivers that
> want to land somewhere now, which means we need to just get a
> framework in place, leveraging drm code is the way to do it.

It is not a different path, at plumbers we decided accel should try to
re-use parts of DRM that make sense. I think that should be done by
making those DRM parts into libraries that can be re-used, not by
trying to twist DRM into something weird.

If this thing needs special major/minor numbers, it's own class, its
own debufs, sysfs, etc, then it should not be abusing the DRM struct
device infrastructure to create that very basic kernel infrastructure.

Somehow we ended up with the worst of both worlds. If you want to to
be DRM then it should just be DRM and we shouldn't see all this core
infrastructue code for debugfs/sysfs/cdevs/etc in thes patches at all.

Jason

  reply	other threads:[~2022-11-08 12:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02 20:34 [RFC PATCH v2 0/3] new subsystem for compute accelerator devices Oded Gabbay
2022-11-02 20:34 ` [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major Oded Gabbay
2022-11-02 21:04   ` Jeffrey Hugo
2022-11-03 13:28     ` Oded Gabbay
2022-11-02 22:58   ` Randy Dunlap
2022-11-03 13:29     ` Oded Gabbay
2022-11-03  0:32   ` Greg Kroah-Hartman
2022-11-03 13:31     ` Oded Gabbay
2022-11-03 20:39       ` Oded Gabbay
2022-11-03 23:01         ` Randy Dunlap
2022-11-04  7:23           ` Stanislaw Gruszka
2022-11-07 12:56         ` Jason Gunthorpe
2022-11-07 13:01           ` Oded Gabbay
2022-11-07 13:10             ` Jason Gunthorpe
2022-11-07 13:25               ` Stanislaw Gruszka
2022-11-07 14:02               ` Oded Gabbay
2022-11-07 14:10                 ` Jason Gunthorpe
2022-11-07 15:53                   ` Oded Gabbay
2022-11-07 16:30                     ` Jason Gunthorpe
2022-11-07 19:27                       ` Oded Gabbay
2022-11-07 20:33                       ` Dave Airlie
2022-11-08 12:28                         ` Jason Gunthorpe [this message]
2022-11-09  7:22                           ` Dave Airlie
2022-11-07 20:18               ` Dave Airlie
2022-11-02 20:34 ` [RFC PATCH v2 2/3] accel: add dedicated minor for accelerator devices Oded Gabbay
2022-11-02 21:17   ` Jeffrey Hugo
2022-11-06 10:51     ` Oded Gabbay
2022-11-03  5:25   ` Jiho Chu
2022-11-06 10:54     ` Oded Gabbay
2022-11-06 14:15       ` Oded Gabbay
2022-11-02 20:34 ` [RFC PATCH v2 3/3] drm: initialize accel framework Oded Gabbay
2022-11-02 21:30   ` Jeffrey Hugo
2022-11-06 10:55     ` Oded Gabbay

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=Y2pLYxW8p0QeiV+3@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jacek.lawrynowicz@linux.intel.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jhubbard@nvidia.com \
    --cc=jiho.chu@samsung.com \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.kwapulinski@linux.intel.com \
    --cc=ogabbay@kernel.org \
    --cc=quic_jhugo@quicinc.com \
    --cc=stanislaw.gruszka@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    --cc=yuji2.ishikawa@toshiba.co.jp \
    /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).