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:   Mon, 7 Nov 2022 10:10:07 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Oded Gabbay <ogabbay@kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>, Arnd Bergmann <arnd@arndb.de>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        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>,
        stanislaw.gruszka@intel.com
Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a
 new major
Message-ID: <Y2kRvyR8VrZrO/1H@nvidia.com>
References: <20221102203405.1797491-1-ogabbay@kernel.org>
 <20221102203405.1797491-2-ogabbay@kernel.org>
 <Y2MMCIe5wND2XPqE@kroah.com>
 <CAFCwf13uLj=P6u6FAcY8M5qAXoaBdb+Ha-TYj0j2FAZnFAPFYg@mail.gmail.com>
 <CAFCwf12yRUG4593ozJMEwaaJBKyWqXTTCjef9O_fzWdQBxVrtw@mail.gmail.com>
 <Y2kAcCu4z2LUMN7u@nvidia.com>
 <CAFCwf10K-dTu455QfOK8i6thismY-FUN2Rws830EGiqOcGWFgA@mail.gmail.com>
 <Y2kDzPswkKyZyRpS@nvidia.com>
 <CAFCwf10A=-bj2nR8WasNxyQQ07D24Je04tzKxqv2X_XnA0BUSQ@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFCwf10A=-bj2nR8WasNxyQQ07D24Je04tzKxqv2X_XnA0BUSQ@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HSFWLMD865ZpUs4QTDiqUX6+PiXmRSWJDXheGHOMRnaZt/8zDEczgjqw3mfb?=
 =?us-ascii?Q?1mPQTWk2frqodzMvH8VyP8jj4pJlaBZfrNV1oQdG10C3pTeWxcP7/mMx81HY?=
 =?us-ascii?Q?ROLlxpo9KOjcyNhlsX2c5RpRG2i+NaNrL9iBh+rFJLyBrGTG7o2CeTR2pHKu?=
 =?us-ascii?Q?uS4cscwWXO4yPTlXuxB9aOUn3/6z9DxMxtuQSyNLYg06Aj1nbH1i5d20GAhM?=
 =?us-ascii?Q?eGO0CB/dfq86IFiDuH5zdjRvFlHAu0EdufH/2YoWK8xnH+/vwy4b6L903v36?=
 =?us-ascii?Q?prEtRep7pZtnxoH+SDt9ugUrUmojaI/gXg41tZoMYbrz/T5GKf55d7J2Dqht?=
 =?us-ascii?Q?/ejGMF58ckP3xnIR/Fv+gyMUqAKLFvv96RSgtsQlucrbBSPrpS1VeCPDfUsK?=
 =?us-ascii?Q?jVp8/ICa7EJ2sINid+H24HsEOLtm6OljURSWgu1fCDker6WzB8DEy0e4jRfz?=
 =?us-ascii?Q?OQ/SzyJKnNadRorpD100EGkIoxA7PkDgxBrxYnIgoIyIKWG9FJH02kIc+k8a?=
 =?us-ascii?Q?A0FEYZgrHwjMijwBS0AxssS7DTBxqku1B8Q+OwsPgm0Whb8FyX/VYD0CI4Wk?=
 =?us-ascii?Q?TmkpoJZ/2XHUucqU7TdDjy6K6TRFJL9H+f6CtklC++aO+XTvoRtIIYUIf4jp?=
 =?us-ascii?Q?W2l+jsJ1cqp0cxBvaPah8GBRGLJfk4nq53AnsL2rgGdB/IGergG2z88AYB6Z?=
 =?us-ascii?Q?zJpnMC1ZcmjbPaY9Lh5JqeKInd63sStIfqSa+hRgNKaR25gyyS90MbhghLhK?=
 =?us-ascii?Q?OA5c6WaNc5t23fJ3SxXlE1QWrRUF4JAqldB2dDH4dD4dw+HP+P43sjKX3oPf?=
 =?us-ascii?Q?znfPp0y6l8Br5xvJLET4SY5C4T8YK+F18+JzorpJbXNRq5P7EGEd0a50wxie?=
 =?us-ascii?Q?UBjLhY563Pv2DlQRyqkXuNyaxFarhSPwqU8UurUvBETJN1A1Hb5kBDRXxrX6?=
 =?us-ascii?Q?vk+p9SkCiFuAtnenA8TmUvgZo3wv/jeKyXJg01XnYk8M7m6Xw5KZBZPN4fmx?=
 =?us-ascii?Q?wJimm0l/svUl8JNW63uH5xfvMX6wfK4aORYtuEGXrCP8/YWBVSXzc+ktY5SM?=
 =?us-ascii?Q?Oe+aSTfWywT+MO31ZUuZMmMKew6MNoYYbNZAmmLrzP+lVdXjx8CUUszxQIQQ?=
 =?us-ascii?Q?n2KxAWHEtxGLDXDB3jkAtCF1+7RLaeOMuJN594Ps5wAlGJjjY6hQr7iFM5Pq?=
 =?us-ascii?Q?maj4kUFVTjLyFbyZobqsxojkwsc0pOO7zSYLES5BQq4QNqjB78vQ7tiJYJ8p?=
 =?us-ascii?Q?YGeS0eCIKmtrReK0N6m7JTcGT1d1IAgk0mR9Zcg1C0rOVW3TNo7nrJWgzB8R?=
 =?us-ascii?Q?a7o8O54nPeVMCkmdha6WgG9TPK+TXFfr34Tk8g+WC6OAKP7PPEuMGzojbeb+?=
 =?us-ascii?Q?CXpLdUjql6d6LQTfwAlp1CqoLi2Js1E2UsK5bAChS7patL/+maTlq8LHTho6?=
 =?us-ascii?Q?WN2Tc8KfIKGh5EINje9KlFFSucK/3G29zGd/jrwGhPG38FtdVxaNRzFaeAhK?=
 =?us-ascii?Q?B/Kgwh6biQBw5YCFudnr/6KrpmWes4L7gFp5gD5OoDMLpu4a5n8WWUYWnV6/?=
 =?us-ascii?Q?k7YTi53kbXHLhHpavuw=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d379051-9c31-4b3a-a2fd-08dac0c9c6c2
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2022 14:10:08.4137
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: c+D31yd3dJMnsxmfSPDVft06CviDAroKvRRkrRZ+3gecCB56NA8KCui1B7AgD2YK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4293
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Nov 07, 2022 at 04:02:01PM +0200, Oded Gabbay wrote:
> On Mon, Nov 7, 2022 at 3:10 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > On Mon, Nov 07, 2022 at 03:01:08PM +0200, Oded Gabbay wrote:
> > > I don't agree with your statement that it should be "a layer over top of DRM".
> > > Anything on top of DRM is a device driver.
> > > Accel is not a device driver, it is a new type of drm minor / drm driver.
> >
> > Yeah, I still think this is not the right way, you are getting almost
> > nothing from DRM and making everything more complicated in the
> > process.
> >
> > > The only alternative imo to that is to abandon the idea of reusing
> > > drm, and just make an independant accel core code.
> >
> > Not quite really, layer it properly and librarize parts of DRM into
> > things accel can re-use so they are not intimately tied to the DRM
> > struct device notion.
> >
> > IMHO this is much better, because accel has very little need of DRM to
> > manage a struct device/cdev in the first place.
> >
> > Jason
> I'm not following. How can an accel device be a new type of drm_minor,
> if it doesn't have access to all its functions and members ?

"drm_minor" is not necessary anymore. Strictly managing minor numbers
lost its value years ago when /dev/ was reorganized. Just use
dynamic minors fully.

> How will accel device leverage, for example, the GEM code without
> being a drm_minor ?

Split GEM into a library so it doesn't require that.

> Librarizing parts of DRM sounds nice in theory but the reality is that
> everything there is interconnected, all the structures are
> interdependent.

Yes, the kernel is full of stuff that needs improving. Let's not take
shortcuts.

> I would have to re-write the entire DRM library to make such a thing
> work. I don't think this was the intention.

Not necessarily you, whoever someday needs GEM would have to do some
work.

> The current design makes the accel device an integral part of drm,
> with very minimal code duplication and without re-writing DRM.

And it smells bad, you can't even make it into a proper module. Who
knows what other problems will come.

Jason