Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp128763rwb; Tue, 8 Nov 2022 23:34:30 -0800 (PST) X-Google-Smtp-Source: AMsMyM56nrWp1wja7Oq2z1BOwCQq79aJybL7xdOnxcPfLc8bLR5Z5Di777XhW6Fb5YewLB93k6rK X-Received: by 2002:a17:90b:4a09:b0:213:9911:5f07 with SMTP id kk9-20020a17090b4a0900b0021399115f07mr62059627pjb.160.1667979270072; Tue, 08 Nov 2022 23:34:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667979270; cv=none; d=google.com; s=arc-20160816; b=KOZCFDOnthA1LkPbo3iAIA+2Me3evjEc3jBOaFHXZxFeCiExUmut6QsUw4ItJNuF4q YCyT66oCnWvsJnyTXPGc/3Yum0+g2J4YpBuJT6dRjbooljfvfSqsFQRTJjakSoMsa5uB ghyXb8YfkjG+HegddC8OxfGxCNu/LL8BW2B0fViABGdIROdwjb9pVXuU62ZDHDwWpMPB pZxUS6KKGbwjJu7pb1SPqGWobME5CVpiPD5mbDfbwmHHCucKgU2eoq2Bd+4lPPD6vUr6 dMyFcOvnvCnPXXNzNwc/XmX2lNjdJVTTgtFGG6xLXqLaZrwoUrk7/PJNzcXcx1pzyry8 QSlg== 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=EA4gK75UEv7H68JgXPxHNB0fDjmSTaahOFdjo3XrFNA=; b=i3CoFcHiuC/gPToT00xOEXeUNkGY3ibkeMdtoCXQ5hyNRpKVhbhNPzmp11SlfO2pq/ qlOuX6/KbpAF15K6yC7ke7/OYtwXzMpIbs4YtLndbAs72O7VLfmmt6drq5oACpolRsFU e85nsjAWpyk3jtvY9V/awMfyuYZR6RMkHC7S0J4+T5xNQf3vS4WX5+4fBb4q02QNtWJx DbUoQx61W+/VR31JipctckBeNoa6Mbp/IZt/nhExh3vgasjXykq55FUW697N0koDZapi bHc1XXibL304hVCVMIVyohkdSKoINnhBISkN1s/fccZ7QPkXeVd0qhShjZG10uiLSoQT 7mSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=g3l5uvyA; 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 e4-20020a17090301c400b00177f35ce11fsi18112668plh.22.2022.11.08.23.34.17; Tue, 08 Nov 2022 23:34:30 -0800 (PST) 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=g3l5uvyA; 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 S229865AbiKIHWl (ORCPT + 93 others); Wed, 9 Nov 2022 02:22:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229846AbiKIHWi (ORCPT ); Wed, 9 Nov 2022 02:22:38 -0500 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B34591D658 for ; Tue, 8 Nov 2022 23:22:36 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id fz10so9956545qtb.3 for ; Tue, 08 Nov 2022 23:22: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=EA4gK75UEv7H68JgXPxHNB0fDjmSTaahOFdjo3XrFNA=; b=g3l5uvyAvcAJvLdmk27RhvDggwIp0i4mpHA/5oGRdOk8dIqPnK10UtRDF3VF6a/HDv 8n8QVq7TfTxz5eDCoTeARxhY+OOopb8sA1iJES6/XJs0df3Mo1Zi2dpUoEIhUZaZYM8P fr+gcQkDlWxXtm1dyGddsvP6lPISBFMtzx1hV8VqFED0sJoosNw/f3URUv2UCp4WHlyd raC7J5PNcgYp07SusQWOMS+7Slih5X9Ls6k6qum/6tNp5mRhi/Kfwh6CBNIjgQc1bYey nnHcBdKMP10EaGiNqY4M4LPOf+AhydaWSPpApsgILduFC2aRAdA4nEZBDSCKvZhRcdCR Aorw== 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=EA4gK75UEv7H68JgXPxHNB0fDjmSTaahOFdjo3XrFNA=; b=5sORK0iHW0pvYxMJInb618PfeIBWUycMKm4ITDCyVI6UlADlmskY1c5x9ekR2vEQ+V Qm5H1QynLC7hN6j4a7DhavazEDx4SDgAyR0gazPpWimeTW3Z3HNgGCwZkEGwn8QsGmVn 1kvZOLywNO2goU4zs50HrbuRlATUzuagxCgv1TBLwl8gj99VrfEX/QoR+EKhRiW7ir2h Oj9BkpwTcLXzrDcK3jrO3o9QGarGr5KzK9JkhFrhuOPyO2Dv8jfeIinFUP0MPQpVvl1L XV5lSNhc9tMtF9PUd7LO1Fi5UmPmyPxSN1JNAm6nFyqw7NApu3Qx23C3i4XOZdOxKr6J OFmg== X-Gm-Message-State: ANoB5pkIIE4xkk/5nLyju6nsoo+HU21LnG5NfKzIG0fEFeEyr6h4UkcO vnU7xtGK2CRMy4IPO5ZRaqONicNo6rk/eDUhXuU= X-Received: by 2002:a05:622a:1c1:b0:3a5:8416:690d with SMTP id t1-20020a05622a01c100b003a58416690dmr12974134qtw.61.1667978555763; Tue, 08 Nov 2022 23:22:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Airlie Date: Wed, 9 Nov 2022 17:22:23 +1000 Message-ID: Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major To: Jason Gunthorpe Cc: Oded Gabbay , Greg Kroah-Hartman , Daniel Vetter , Arnd Bergmann , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, John Hubbard , Alex Deucher , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Yuji Ishikawa , Jiho Chu , Daniel Stone , Tvrtko Ursulin , Jeffrey Hugo , Christoph Hellwig , Kevin Hilman , Jagan Teki , Jacek Lawrynowicz , Maciej Kwapulinski , stanislaw.gruszka@intel.com 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 Tue, 8 Nov 2022 at 22:28, Jason Gunthorpe wrote: > > On Tue, Nov 08, 2022 at 06:33:23AM +1000, Dave Airlie wrote: > > > 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. > > It is not a different path, at plumbers we decided accel should try to > re-use parts of DRM that make sense. I think that should be done by > making those DRM parts into libraries that can be re-used, not by > trying to twist DRM into something weird. There isn't much twisting here, the thing is this is just the code for sharing, there isn't going to be mountains more. This code gives accel drivers access to a lot of things. Refactoring it out will take a year or so, and I don't think buys us anything. > > If this thing needs special major/minor numbers, it's own class, its > own debufs, sysfs, etc, then it should not be abusing the DRM struct > device infrastructure to create that very basic kernel infrastructure. > > Somehow we ended up with the worst of both worlds. If you want to to > be DRM then it should just be DRM and we shouldn't see all this core > infrastructue code for debugfs/sysfs/cdevs/etc in thes patches at all. We can refactor this out even clearer in the long run if it needs to, but you are overly focusing on the small picture of these patches and not the larger sharing this enables. At this point I'm going to be merging close to what we have here, so we can move forward with getting some drivers lined up. Dave.