Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 23 Oct 2022 21:02:49 +0700
From:   Bagas Sanjaya <bagasdotme@gmail.com>
To:     Oded Gabbay <ogabbay@kernel.org>
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,
        linux-doc@vger.kernel.org, Jason Gunthorpe <jgg@nvidia.com>,
        John Hubbard <jhubbard@nvidia.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
        Jiho Chu <jiho.chu@samsung.com>,
        Daniel Stone <daniel@fooishbar.org>,
        Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
        Jeffrey Hugo <quic_jhugo@quicinc.com>,
        Christoph Hellwig <hch@infradead.org>,
        Kevin Hilman <khilman@baylibre.com>,
        Jagan Teki <jagan@amarulasolutions.com>,
        Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
        Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
        Jonathan Corbet <corbet@lwn.net>
Subject: Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
Message-ID: <Y1VJieGgVv9BwaO3@debian.me>
References: <20221022214622.18042-1-ogabbay@kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="KFhUQIkYlmhwSi0N"
Content-Disposition: inline
In-Reply-To: <20221022214622.18042-1-ogabbay@kernel.org>
Precedence: bulk


--KFhUQIkYlmhwSi0N
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote:
> In the last couple of months we had a discussion [1] about creating a new
> subsystem for compute accelerator devices in the kernel.
>=20
> After an analysis that was done by DRM maintainers and myself, and follow=
ing
> 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.
>=20
> 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).
>=20
> 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 separ=
ate
> place in the kernel tree (drivers/accel/).
>=20
> 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:
>=20
> device char files - /dev/accel/accel*
> sysfs             - /sys/class/accel/accel*/
> debugfs           - /sys/kernel/debug/accel/accel*/
>=20
> I tried to reuse the existing DRM code as much as possible, while keeping=
 it
> readable and maintainable.
>=20
> 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-s=
et,
> after I will receive feedback from the community.
>=20
> As for drivers, once this series will be accepted (after adding the names=
pace),
> 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 th=
en
> start working on the driver's individual features that will be either add=
ed
> to the accel core code (with or without changes), or will be removed and
> instead the driver will use existing DRM code.
>=20
> In addition, I know of at least 3 or 4 drivers that were submitted for re=
view
> and are good candidates to be included in this new subsystem, instead of =
being
> a drm render node driver or a misc driver.
>=20
> [1] https://lkml.org/lkml/2022/7/31/83
> [2] https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summar=
y.html
>=20

Since this is new subsystem, it should have its own git tree where you
collected accelerator-related patches. By convention, there should be
"next" branch targeting for next kernel release and "fixes" branch for
bugfixes pending for current release. Both branches should be included
into linux-next. The names don't necessarily be that, though.

Also, it had been great if you write short, descriptive documentation
about the subsystem (maintainers handbook).

Cc'ing linux-doc folks.

--=20
An old man doll... just what I always wanted! - Clara

--KFhUQIkYlmhwSi0N
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCY1VJhQAKCRD2uYlJVVFO
o+yTAP0Wq0yPX3TS5HZJ27v0PHGSOWTbOi+nH/lPSH1cS+ol9AD8CHBTzQqZytiP
wolMvwwGEa8J+1fi1Wk5hKbB1ex35g8=
=9xlo
-----END PGP SIGNATURE-----

--KFhUQIkYlmhwSi0N--