linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jason Gunthorpe <jgg@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
	Jeffrey Hugo <quic_jhugo@quicinc.com>,
	Jiho Chu <jiho.chu@samsung.com>,
	Christoph Hellwig <hch@infradead.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Kevin Hilman <khilman@baylibre.com>,
	Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
	Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
	Jagan Teki <jagan@amarulasolutions.com>
Subject: Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
Date: Mon, 24 Oct 2022 17:41:02 +0300	[thread overview]
Message-ID: <CAFCwf11CPvW8uqbDs8-qyMVMbPhw1tPF9ddfjee1MvKthRQb+g@mail.gmail.com> (raw)
In-Reply-To: <CADnq5_PwNwsSUeyhXDkoy-y1JXFrTj99AgVV02oHX0a29QUXpQ@mail.gmail.com>

On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay <ogabbay@kernel.org> wrote:
> >
> > In the last couple of months we had a discussion [1] about creating a new
> > subsystem for compute accelerator devices in the kernel.
> >
> > After an analysis that was done by DRM maintainers and myself, and following
> > a BOF session at the Linux Plumbers conference a few weeks ago [2], we
> > decided to create a new subsystem that will use the DRM subsystem's code and
> > functionality. i.e. the accel core code will be part of the DRM subsystem.
> >
> > This will allow us to leverage the extensive DRM code-base and
> > collaborate with DRM developers that have experience with this type of
> > devices. In addition, new features that will be added for the accelerator
> > drivers can be of use to GPU drivers as well (e.g. RAS).
> >
> > As agreed in the BOF session, the accelerator devices will be exposed to
> > user-space with a new, dedicated device char files and a dedicated major
> > number (261), to clearly separate them from graphic cards and the graphic
> > user-space s/w stack. Furthermore, the drivers will be located in a separate
> > place in the kernel tree (drivers/accel/).
> >
> > This series of patches is the first step in this direction as it adds the
> > necessary infrastructure for accelerator devices to DRM. The new devices will
> > be exposed with the following convention:
> >
> > device char files - /dev/accel/accel*
> > sysfs             - /sys/class/accel/accel*/
> > debugfs           - /sys/kernel/debug/accel/accel*/
> >
> > I tried to reuse the existing DRM code as much as possible, while keeping it
> > readable and maintainable.
>
> Wouldn't something like this:
> https://patchwork.freedesktop.org/series/109575/
> Be simpler and provide better backwards compatibility for existing
> non-gfx devices in the drm subsystem as well as newer devices?

As Greg said, see the summary. The consensus in the LPC session was
that we need to clearly separate accel devices from existing gpu
devices (whether they use primary and/or render nodes). That is the
main guideline according to which I wrote the patches. I don't think I
want to change this decision.

Also, there was never any intention to provide backward compatibility
for existing non-gfx devices. Why would we want that ? We are mainly
talking about drivers that are currently trying to get upstream, and
the habana driver.

Oded
>
> Alex
>
> >
> > One thing that is missing from this series is defining a namespace for the
> > new accel subsystem, while I'll add in the next iteration of this patch-set,
> > after I will receive feedback from the community.
> >
> > As for drivers, once this series will be accepted (after adding the namespace),
> > I will start working on migrating the habanalabs driver to the new accel
> > subsystem. I have talked about it with Dave and we agreed that it will be
> > a good start to simply move the driver as-is with minimal changes, and then
> > start working on the driver's individual features that will be either added
> > to the accel core code (with or without changes), or will be removed and
> > instead the driver will use existing DRM code.
> >
> > In addition, I know of at least 3 or 4 drivers that were submitted for review
> > and are good candidates to be included in this new subsystem, instead of being
> > a drm render node driver or a misc driver.
> >
> > [1] https://lkml.org/lkml/2022/7/31/83
> > [2] https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summary.html
> >
> > Thanks,
> > Oded
> >
> > Oded Gabbay (3):
> >   drivers/accel: add new kconfig and update MAINTAINERS
> >   drm: define new accel major and register it
> >   drm: add dedicated minor for accelerator devices
> >
> >  Documentation/admin-guide/devices.txt |   5 +
> >  MAINTAINERS                           |   8 +
> >  drivers/Kconfig                       |   2 +
> >  drivers/accel/Kconfig                 |  24 +++
> >  drivers/gpu/drm/drm_drv.c             | 214 +++++++++++++++++++++-----
> >  drivers/gpu/drm/drm_file.c            |  69 ++++++---
> >  drivers/gpu/drm/drm_internal.h        |   5 +-
> >  drivers/gpu/drm/drm_sysfs.c           |  81 +++++++++-
> >  include/drm/drm_device.h              |   3 +
> >  include/drm/drm_drv.h                 |   8 +
> >  include/drm/drm_file.h                |  21 ++-
> >  include/drm/drm_ioctl.h               |   1 +
> >  12 files changed, 374 insertions(+), 67 deletions(-)
> >  create mode 100644 drivers/accel/Kconfig
> >
> > --
> > 2.34.1
> >

  reply	other threads:[~2022-10-24 16:05 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-22 21:46 [RFC PATCH 0/3] new subsystem for compute accelerator devices Oded Gabbay
2022-10-22 21:46 ` [RFC PATCH 1/3] drivers/accel: add new kconfig and update MAINTAINERS Oded Gabbay
2022-10-23 12:40   ` Greg Kroah-Hartman
2022-10-24  7:19     ` Oded Gabbay
2022-10-24 15:01   ` Jeffrey Hugo
2022-10-22 21:46 ` [RFC PATCH 2/3] drm: define new accel major and register it Oded Gabbay
2022-10-23 12:40   ` Greg Kroah-Hartman
2022-10-24  7:23     ` Oded Gabbay
2022-10-24  7:52       ` Dave Airlie
2022-10-24 15:08         ` Jeffrey Hugo
2022-10-22 21:46 ` [RFC PATCH 3/3] drm: add dedicated minor for accelerator devices Oded Gabbay
2022-10-23 12:41   ` Greg Kroah-Hartman
2022-10-24  7:23     ` Oded Gabbay
2022-10-24 15:21   ` Jeffrey Hugo
2022-10-24 17:43     ` Oded Gabbay
2022-10-25 13:26       ` Michał Winiarski
2022-10-26  6:38         ` Oded Gabbay
2022-10-25  6:43   ` Jiho Chu
2022-10-26  6:38     ` Oded Gabbay
2022-10-28  6:56       ` Jiho Chu
2022-10-23 14:02 ` [RFC PATCH 0/3] new subsystem for compute " Bagas Sanjaya
2022-10-23 14:14   ` Greg Kroah-Hartman
2022-10-24 11:55 ` Thomas Zimmermann
2022-10-24 12:35   ` Greg Kroah-Hartman
2022-10-24 12:43   ` Oded Gabbay
2022-10-25  2:21     ` John Hubbard
2022-10-25  2:27       ` Dave Airlie
2022-10-25 11:15         ` Jason Gunthorpe
2022-10-25 14:21           ` Alex Deucher
2022-10-25 14:34             ` Jason Gunthorpe
2022-10-25 14:43               ` Alex Deucher
2022-10-24 13:55 ` Alex Deucher
2022-10-24 14:41   ` Oded Gabbay [this message]
2022-10-24 15:10     ` Alex Deucher
2022-10-26  6:10       ` 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=CAFCwf11CPvW8uqbDs8-qyMVMbPhw1tPF9ddfjee1MvKthRQb+g@mail.gmail.com \
    --to=ogabbay@kernel.org \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=arnd@arndb.de \
    --cc=daniel@ffwll.ch \
    --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=jgg@nvidia.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=quic_jhugo@quicinc.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).