Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major

From: Dave Airlie <airlied@gmail.com>
To: Jason Gunthorpe <jgg@nvidia.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 06:33:23 +1000	[thread overview]
Message-ID: <CAPM=9twxu3v4voSukrkror1BrajShRLY9CFxYWpL2rwK7fMiKQ@mail.gmail.com> (raw)
In-Reply-To: <Y2kyvswuCsO0x1/2@nvidia.com>

> > >
> > > "drm_minor" is not necessary anymore. Strictly managing minor numbers
> > > lost its value years ago when /dev/ was reorganized. Just use
> > > dynamic minors fully.
> > drm minor is not just about handling minor numbers. It contains the
> > entire code to manage devices that register with drm framework (e.g.
> > supply callbacks to file operations), manage their lifecycle,
> > resources (e.g. automatic free of resources on release), sysfs,
> > debugfs, etc.
>
> This is why you are having such troubles, this is already good library
> code. You don't need DRM to wrapper debugfs APIs, for instance. We
> have devm, though maybe it is not a good idea, etc
>
> Greg already pointed out the sysfs was not being done correctly
> anyhow.
>
> I don't think DRM is improving on these core kernel services. Just use
> the normal stuff directly.

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.

There is no need to an "accel" module, what does that even buy you,
the idea is to have an accel subsystem that allows drivers to use drm
features, not an accel subsystem that refactors drm features, that
would take years. There are already drivers for this subsystem wanting
to use GEM, and I don't think holding them up for a year to refactor
something that we don't have a clear reason or goal behind
refactoring.

If there is a problem with the drm subsystem interactions with the
kernel standard implementations then let's go fix that and accel will
also get fixed, but there's no reason to start going down that road at
the same time as introducing accel.

Also with the idr/xarray stuff, this isn't the patchset to be
introducing a bunch of new and divergent work, if this patchset
identifies deficiencies then let's document them and work on them in
parallel instead of blocking the initial landing in favour of some
future refactors with no in-tree users.

Dave.