Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp7104447rwi; Mon, 24 Oct 2022 09:52:17 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5y3OhncCLSJ3GjB8R3GcDa7MR4kqwdt4CDIwJjBiSF8HGoAnCIHIg36mL8W/8OIf1XPZm7 X-Received: by 2002:a05:6a00:2906:b0:52a:bc7f:f801 with SMTP id cg6-20020a056a00290600b0052abc7ff801mr35175705pfb.49.1666630337531; Mon, 24 Oct 2022 09:52:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666630337; cv=none; d=google.com; s=arc-20160816; b=i/qsGAWK5n9+GnqroHiUYlgeWlJUVj3nccG3v5T7aE8GD6WuUgOMLeeIH7pey1Nkpd 77pv4/tRNvc+ooIFFfsZcsSCPJ73+pY4yLSDDYXp/W+N7PrTbQV+kICFNH4NEIapOPD4 K2+L0GHF1a+rano0alKHTpPWYlHjQrtW+j8zYpvS3AdjWnFIvyKig7Bl1gYg+33onE4L Y9/DTUIUan2uaHk2iyt0njOGJPOhpJ60uN9QuRlO/7lDW0kuf7iYRqAZ5iO0mSB8MgxH vIkuF+xL1mEbXkrcSkhOaqCPmMG++h1x+XkPbbxQcyXDi6UOk8QyjzS/sLMPM2dyG16/ cr6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3u6vBok7fkMUG4gQWkOOT25X5n6LqbLhBS964rQOfgo=; b=qqILpUWZXgL4N7iJNxLlczyMA9w7YhrPcggZ/qmt+WMxfCVDnhjDNofZohCp9h72TO srw1HLHDxB1cIfAvvFVLptJ3449YEod5YYaZkgsj5eyCD1fa++X+AepdjwNfXD7GAMi9 vWUqkBsMA+Fgt3COuJnD2zJSTg8CuUP8JxybSbOXtyzs/NSsSshcXbdGnDNB2s4ACC6W u7YIRor+stSSfpnlicHFWAA1cKB2rT04AAh+dIZiGAMEfsfpBQ0QnFxUybo5nSXucKgC 6+/Rz8V8pAPJh34tdtl+WOHS8iMokei0HQl1KAyy5o3UQXxNjGMhYOqufx8jFp2BRhbm kN3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="Kz+/GLpa"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u7-20020a627907000000b0056bedcfac12si107340pfc.333.2022.10.24.09.52.05; Mon, 24 Oct 2022 09:52:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="Kz+/GLpa"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233895AbiJXQjr (ORCPT + 99 others); Mon, 24 Oct 2022 12:39:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233948AbiJXQjR (ORCPT ); Mon, 24 Oct 2022 12:39:17 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9CFB220EF for ; Mon, 24 Oct 2022 08:26:44 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id c24so8714100pls.9 for ; Mon, 24 Oct 2022 08:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3u6vBok7fkMUG4gQWkOOT25X5n6LqbLhBS964rQOfgo=; b=Kz+/GLpa/rMZEKMRFCEZyGkW+wQIX+WLtvg3AqAFKkv7GxVd9S5MEc9DNnBkxkki6d APip50piSLHmTJSariD3lrJhc1qzkkNwNkXfF6wjhyBxIhu9E2ICsEOoXQu5Bfc0PqPu M0xJ/K4Zbe6P5QWU15D3awM4jBuK+Uv5EL8n93jX5bqnOgql9u8HYWupBuhjQrZjLug+ uz9cApNtOQ38jVejrBNX+nYdYdf12xnZrlPNUrfAHx6SbeN9iTmyDJumfinVFz54vXXS t3YjyHKmsIsC6kZjxCR+kZDB2gCG6R1AHuHDN7+BJW032blVD8B58y2NzU2JOraDV3aU 5mbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3u6vBok7fkMUG4gQWkOOT25X5n6LqbLhBS964rQOfgo=; b=3uCCGtx4JLEpHG2Bunl+S0QcQIBJetuwyk4AijZQRdtxeZersOL0jCdP5E++y8UDJC JBvBFPSEtVfi3VK41MJCcW3BIG/AwZv1BOxRyeV5I5O5Ns5cg4xKLYRvaWMrNFbxmWNA CUpNbGBZ7/vtuK9KJDbAuUgWkS1Vcu9vyA3/1ypheChGofFKqOVr+lQxpS57IF6u7cGs K/HNSy+XR5CliuuVNK7keeyUC8oJlDdapCv5VM0oFpC1SLWPFuCq+2tdYJ+vFOsdm63O eR/IqwqLOPMvj+/Iu1gnAW6jWJiyiNiAbtPNkb8DA+bI12S1TlBmUfgAhK0w0hULpPqX aYhQ== X-Gm-Message-State: ACrzQf36cgCDd+1j0xyRrWZBev7y0BIq4+3JE62wtqA7r7cBtFw/smBx XKlev5EbC8rPaSVUTX9ncZWMwsPMf4jI/tDnYQd5p8Jf X-Received: by 2002:a05:6102:224d:b0:3a7:68fc:9163 with SMTP id e13-20020a056102224d00b003a768fc9163mr17650095vsb.74.1666624238228; Mon, 24 Oct 2022 08:10:38 -0700 (PDT) MIME-Version: 1.0 References: <20221022214622.18042-1-ogabbay@kernel.org> In-Reply-To: From: Alex Deucher Date: Mon, 24 Oct 2022 11:10:25 -0400 Message-ID: Subject: Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices To: Oded Gabbay Cc: David Airlie , Daniel Vetter , Arnd Bergmann , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Jason Gunthorpe , John Hubbard , Alex Deucher , Tvrtko Ursulin , Jacek Lawrynowicz , Jeffrey Hugo , Jiho Chu , Christoph Hellwig , Thomas Zimmermann , Kevin Hilman , Yuji Ishikawa , Maciej Kwapulinski , Jagan Teki Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 24, 2022 at 10:41 AM Oded Gabbay wrote: > > On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote: > > > > On Sat, Oct 22, 2022 at 5:46 PM 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. > > > > > > 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. If someone already has a non-gfx device which uses the drm subsystem, should they be converted to the new accel stuff? What about new devices that utilize the same driver? SHould they use accel or continue to use drm? For the sake of the rest of the stack drm would make more sense, but if accel grows a bunch of stuff that all accel drivers should be using what do we do? Also using render nodes also makes the devices compatible with all of the existing user space tools that use the existing drm device nodes like libdrm, etc. I'm failing to see what advantage accel brings other than requiring userspace to support two very similar device nodes. Alex > > 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 > > >