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 97659C433FE for ; Wed, 9 Nov 2022 07:22:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6EDA310E07D; Wed, 9 Nov 2022 07:22:37 +0000 (UTC) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by gabe.freedesktop.org (Postfix) with ESMTPS id B512D10E07D for ; Wed, 9 Nov 2022 07:22:36 +0000 (UTC) Received: by mail-qt1-x829.google.com with SMTP id e15so9957543qts.1 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=02A4LHyB2S8WGhfxrU0dCMB4y0IUVGX43Qo33DUWjm0HONJwMT3C5+4RdiZVV+4G8h deRAQISdtMrg5tdSXiBQZFhAsz/QBbamGp1HNOrqGdtmlBteJ9qmaFqsiIBpUKUUMuGr uXiWNjsuVhvbRpmjZAZnQxbGtaYx+s7ffsFmAFdX5Ypcy4IV0/Bma3GEoFBJjHHd45+8 ruYgO2kOCIBATEjezksbVWdYaARqbO1KKjyeXnfGC4yfk9ocZgpdEpKg3EEa9DM2aY82 1NCefOs/Fj3++1HwwNrUddf3B8XlUAbIMkTjAbHqHaJLDilHZjsyeVPP/LU5NpAr4kaD ay9w== X-Gm-Message-State: ANoB5pkJYgiqKewwSMmFqAibPzFGDFYOwsADkHXMXhKOf9UXQYh/74vR nGuBp9GiDJpJlE973CFXnMAwWTIMR3PI7Mo7y7s= X-Google-Smtp-Source: AA0mqf6Bq8H/a3oW2aQP8DBJuI2chSLhNJPP2yxLmIgM74bfU6Pjkdnd+5hWjTC1pyJUbXghNArbOOXfk94hIxvDdgA= 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 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" 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.