From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 38ECCC4332F for ; Mon, 7 Nov 2022 20:33:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6E4F210E495; Mon, 7 Nov 2022 20:33:43 +0000 (UTC) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by gabe.freedesktop.org (Postfix) with ESMTPS id 15BA510E45F for ; Mon, 7 Nov 2022 20:33:36 +0000 (UTC) Received: by mail-qk1-x730.google.com with SMTP id s20so7931237qkg.5 for ; Mon, 07 Nov 2022 12:33:36 -0800 (PST) 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=tQ12e4GxkKyFcKEY5nkb37j7G30vKsrEMR9/r8hrDJ0=; b=qOA73a9Bu14wWQY9g3t4J1/QCrXaAC0kVgEP7vGn7s/hrSLZK1U5lSJdfg2csQ6fAK WwKqBdSf89jpNfxi2VzukRNviRsgtuVPSIMhup7OeZHHqpG5OSPrl0DXf4dSSli7uiim 1ggrG3Hq8LIxqvz5HH/ip0y8FBKwNlk3dMGK1cun8A4sMzX7BcASPDkxk6Hv40GJeJKZ DOcJVRMK545RBtSxA+LQdBLupe342yB1UI515gfRhUBaglQQy2nwZvBfUqR91ayy8M3G Tu5CcIwxmd643GZbxFCoCcwmyLvUtWsgpSCNRPmH9VR8qa7ZtAhGUPAO7GhyZU8nkYmk ctpA== 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=tQ12e4GxkKyFcKEY5nkb37j7G30vKsrEMR9/r8hrDJ0=; b=dAL/vRIafzmtODYudhcV/DNNAD8tQiAr3M6ATjH3yTFjgcbfzhxSQxkYb1FIrl+zPP Y4Tmgp24/HhDT9H0yp5ZNQRGONeZkMUy5IR9w5QwwoNBSjSPOOCTp+VbGF9Nx58ao/tD C4XPsPaTfYKfCMgNPuIJEF2rhROnBJs8uKzIL7h+yU53jARuhX4YaQ0ab45ZgUcYh1mU McQ3wWrbpGqbJWricGWGjr8WRQ3t/IInmKjzL6n8E9MdYptCofoYTtbTiJQgQ6PMMJw7 hVND830C2+pFwLk1mZTuLQyPL6bUsGGj74UL5gIvQ8TslM+N9scSmCsa2sGfzIsdCMW2 WS8A== X-Gm-Message-State: ACrzQf0nlsPzKtk7XPTsB63BK71LPksatc++5RilhZ9phU4LPRztc6WB MgDd0Hf/ZFo1Oc5/fyBH+Oc6uQEYM+uqZ5GxItI= X-Google-Smtp-Source: AMsMyM6W0Bmt/046gPuBut+yT3A+X2p6Q2Q0RhxhI78tSZHtV+jn2n9Nhb0DbPX1ACdKiqOWowMD95Cq0zllpC3GhtI= X-Received: by 2002:a05:620a:1009:b0:6fa:1245:ce4 with SMTP id z9-20020a05620a100900b006fa12450ce4mr37596615qkj.483.1667853215067; Mon, 07 Nov 2022 12:33:35 -0800 (PST) MIME-Version: 1.0 References: <20221102203405.1797491-2-ogabbay@kernel.org> In-Reply-To: From: Dave Airlie Date: Tue, 8 Nov 2022 06:33:23 +1000 Message-ID: Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major To: Jason Gunthorpe Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org, Maciej Kwapulinski , Kevin Hilman , Christoph Hellwig , Jagan Teki , John Hubbard , stanislaw.gruszka@intel.com, Jeffrey Hugo , Arnd Bergmann , Jiho Chu , Jacek Lawrynowicz , Yuji Ishikawa , Tvrtko Ursulin , Greg Kroah-Hartman , Oded Gabbay , linux-kernel@vger.kernel.org, Thomas Zimmermann , Alex Deucher Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > > > > > > "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.