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 1F517C433FE for ; Mon, 7 Nov 2022 14:02:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 768D210E19D; Mon, 7 Nov 2022 14:02:33 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3E08910E19D for ; Mon, 7 Nov 2022 14:02:31 +0000 (UTC) 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 dfw.source.kernel.org (Postfix) with ESMTPS id B8385610A3 for ; Mon, 7 Nov 2022 14:02:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FC74C43141 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-f172.google.com with SMTP id z192so13753481yba.0 for ; Mon, 07 Nov 2022 06:02:29 -0800 (PST) X-Gm-Message-State: ACrzQf31JNfstB7spb9njNGeHw2fdCbhK5mrycfZfftn3MFdk6R/9b2k 59q4NQ3UrJcvVlEU4wx18NpPn8jTjdoxYhwBu04= X-Google-Smtp-Source: AMsMyM5LwoynkPx1YgLfmCY0hq4wGMOnnRu54M0d8kjmNIi1lWDudU/pHVKjj0vORMrz7+eEz3Io0Wz53F1fu2OMj3E= 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 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 , linux-kernel@vger.kernel.org, Thomas Zimmermann , Alex Deucher Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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