Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1827922rwb; Mon, 7 Nov 2022 06:18:43 -0800 (PST) X-Google-Smtp-Source: AMsMyM5MERpKltNfn407JrbNLv8YubewAsiRQRCGVnlWDsPm4ec+NkYAKtDmfBV/jcM8nU2x7z9c X-Received: by 2002:a17:906:cc4e:b0:7ae:3f78:c8b8 with SMTP id mm14-20020a170906cc4e00b007ae3f78c8b8mr15149509ejb.394.1667830723576; Mon, 07 Nov 2022 06:18:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667830723; cv=none; d=google.com; s=arc-20160816; b=I8lpq7YboeS/Uxs7P8yswslLbSTAmfTvzDTTF7fSPG4hKeWFWnDcGOQjjVwE2/Y1Tm GaKHaB6CEj9XUD8RVc3b4dWEcCmffNblfkPmAA0KS1Z5nFx/ZSi4Mz+YtTnvLw5VjU4E kE13+EyHMEIvlZnpM9zLn9v8MSG/3sQ7xQrXJcnRKt+nQo/78ml5OSKOsDDE1RF+uUbr K0w/HhBOq/lS26E7WkHay9PsEJwtYXTLrweZwTj3RD1/j8pu1Wy/5RQfXY5Fl0UugZNW g3e81p5pO23odcGTNmzgQ0Wy284WowJYyR+mtD9S+VkloGC74cUGk5b2i8zaaOcb0+Cg gqeA== 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=zpEewj5MVZ9bJoL7Xyycxj043AlHeiHMJ1ICTR3y2NY=; b=zuapNYoMwmkcZShe1JHRcaiTFWIZmPp4v2p8AYkhyKpLmBgOBRYs1eAagS7OlnCPQK btQt1h/M7sUcw/4TfYpVJaFeVVfGow/Aj1M5L8f1brlSk9NB3xacgghazs/9y8s1aTsU HOCmvoFt9F/C4L3h2N72uX7RAgQE9D/kijchIYbkAX+FCqE19CpoYjHwH4YBbtOwkqj9 1invLJVuHxu6f3nP+czYT6TrklPvEO2WmOJIQrD+k1G14kbA36/CpBUQLXeTQL6HTD8U J4xAf+V+SrksB+G8xVMXOl7wWnjKRiF/JOuiDqr60oBZRZnEJbr8L4yLmdJr7DMTghbP /pVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pRZyW4UC; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s14-20020a508d0e000000b00462f85ee700si9078808eds.65.2022.11.07.06.18.20; Mon, 07 Nov 2022 06:18:43 -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=@kernel.org header.s=k20201202 header.b=pRZyW4UC; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231789AbiKGOCg (ORCPT + 93 others); Mon, 7 Nov 2022 09:02:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229638AbiKGOCd (ORCPT ); Mon, 7 Nov 2022 09:02:33 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 539562D5 for ; Mon, 7 Nov 2022 06:02:32 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C6B14B811B3 for ; Mon, 7 Nov 2022 14:02:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71C66C4314A for ; Mon, 7 Nov 2022 14:02:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667829749; bh=zpEewj5MVZ9bJoL7Xyycxj043AlHeiHMJ1ICTR3y2NY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=pRZyW4UC7Ll6EfhjsbK2sIj0ikxPuum4Ko0AFlkCmugkQ/nuOe3IuDU6f8P+OSUl1 Z8bM1GtcXmd2J73yD5qM7pUd6iRXB47W7Tp5xThpcYEqXk/z9x6cMA/Mq0DsO8wl36 K8M8aejSY+kOhw+CpvJxPU0mvKr/Hu+19q2RNLZT+5psj5nyMiBZ398WhfplP2vVFx F0xfAzys7foBtOXggxlJGKl+wysv6IG/oXVvftlVaU8EZgH6KDRCVsl771ZkyumRL1 IhpH68FqqTqCVe4dDG0j4MQfJAcCrmJ0RuxatsKsd4tbn1dR7/NpKkEBwPh5kj3jst eDGd0comBLbyg== Received: by mail-yb1-f177.google.com with SMTP id g127so13693562ybg.8 for ; Mon, 07 Nov 2022 06:02:29 -0800 (PST) X-Gm-Message-State: ACrzQf1Br9o11MeGKew0XabNFl+SVHv0E/wyBCrvnKn2dIW1zJh/dDm7 ec7KxSAagMfuVtmnQK2DvgET/LRbUgbC7OKiWyE= X-Received: by 2002:a05:6902:152:b0:6ca:8fa:105b with SMTP id p18-20020a056902015200b006ca08fa105bmr49184993ybh.550.1667829748282; Mon, 07 Nov 2022 06:02:28 -0800 (PST) MIME-Version: 1.0 References: <20221102203405.1797491-1-ogabbay@kernel.org> <20221102203405.1797491-2-ogabbay@kernel.org> In-Reply-To: From: Oded Gabbay Date: Mon, 7 Nov 2022 16:02:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major To: Jason Gunthorpe Cc: Greg Kroah-Hartman , David Airlie , 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=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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, Nov 7, 2022 at 3:10 PM Jason Gunthorpe 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 ? How will accel device leverage, for example, the GEM code without being a drm_minor ? Librarizing parts of DRM sounds nice in theory but the reality is that everything there is interconnected, all the structures are interdependent. I would have to re-write the entire DRM library to make such a thing work. I don't think this was the intention. The current design makes the accel device an integral part of drm, with very minimal code duplication and without re-writing DRM. Oded