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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20C0CC433FE for ; Mon, 7 Nov 2022 13:25:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231572AbiKGNZN (ORCPT ); Mon, 7 Nov 2022 08:25:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230434AbiKGNZK (ORCPT ); Mon, 7 Nov 2022 08:25:10 -0500 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD097113C for ; Mon, 7 Nov 2022 05:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667827509; x=1699363509; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hlL+DfWEWMRR8orTzyWzhpO4GGMnYRYRp0nALpNPto8=; b=X7qAZPTYfUYF7ZpFotp6VmDpiGkvkYDQId5/CWOWVqRzYgLGQAD6qRcC af20o2zCoAjlqwDDAJZdjdBs/mfrVYzczm3t830BgeGtO+4Msa28dETdx 4nxUuVVn/5BydJrvnlIsudA1GK0r1AMeuFddq8VfKfeIKebit/mL1VEee VlTHANS7wpfnQprnAGQ229iX9/nffruYqbNyT1K/oNO3Mp4c1/cKAuXkO Cv3farN5+PaVuoR+bxRYFZO1PFs5sWSqtiUqWEnSHVSYaNjN+/rD8cJF8 dLk5t0AwjXK3FW73vg2XKSh3Dh8938ckYNGovQAFGfQsT72jE+3PT1uiu Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="297899194" X-IronPort-AV: E=Sophos;i="5.96,145,1665471600"; d="scan'208";a="297899194" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2022 05:25:09 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="761093220" X-IronPort-AV: E=Sophos;i="5.96,145,1665471600"; d="scan'208";a="761093220" Received: from joe-255.igk.intel.com (HELO localhost) ([172.22.229.67]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2022 05:25:05 -0800 Date: Mon, 7 Nov 2022 14:25:03 +0100 From: Stanislaw Gruszka To: Jason Gunthorpe Cc: Oded Gabbay , 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 Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major Message-ID: <20221107132503.GA3590860@linux.intel.com> References: <20221102203405.1797491-1-ogabbay@kernel.org> <20221102203405.1797491-2-ogabbay@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On Mon, Nov 07, 2022 at 09:10:36AM -0400, 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. What do you mean by "struct device notion" ? struct drm_devce ? Regards Stanislaw