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 26BB8C54EAA for ; Fri, 27 Jan 2023 10:17:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233438AbjA0KR1 (ORCPT ); Fri, 27 Jan 2023 05:17:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233452AbjA0KRU (ORCPT ); Fri, 27 Jan 2023 05:17:20 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1154134016 for ; Fri, 27 Jan 2023 02:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674814637; x=1706350637; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=55TvKFgIeJ9Ccx613u9iCST4aYVD68p4Vcl3AOnOUm8=; b=VsmSZlqWcUxZDE2BvDMUeHPlC8adRTlIbYN0KKVpMz6qYsgLxE7Wqjjd pyafs8pFw05caHluDOJFAWVnkBEwmXdAZMXBRrwdOEyHcjEbhuCYqFklg YOmzl/5Lv/dtxmgq6CrE4D725lyiT/QQUwr2zNAnZt0ZIZpgJxdbHAVuz IfFpbL0NYn1xcXdgFB1Wfh/wVT1CLQNtew+JFWisuLwPse7D/q8CdOkNF 43LwdBnxnyqWZSmaUPwKKQjDBeodDxG6MT484I9mpNrvpNH67RAObHi0S Lic+uJUWc6TE2+3hyVgwrvtek4LHgssdxUaCoxJL5Rc1hq3GidS63DbBk A==; X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="329184899" X-IronPort-AV: E=Sophos;i="5.97,250,1669104000"; d="scan'208";a="329184899" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2023 02:17:05 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="663213467" X-IronPort-AV: E=Sophos;i="5.97,250,1669104000"; d="scan'208";a="663213467" Received: from joe-255.igk.intel.com (HELO localhost) ([10.91.220.57]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2023 02:17:03 -0800 Date: Fri, 27 Jan 2023 11:17:01 +0100 From: Stanislaw Gruszka To: Arnd Bergmann Cc: Oded Gabbay , Jeffrey Hugo , Jacek Lawrynowicz , Dave Airlie , Thomas Zimmermann , Melissa Wen , Daniel Vetter , dri-devel@lists.freedesktop.org, Arnd Bergmann , linux-kernel@vger.kernel.org Subject: Re: [PATCH] accel: work around DRM_ACCEL dependencies Message-ID: <20230127101701.GA1416485@linux.intel.com> References: <20230127093631.2132187-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230127093631.2132187-1-arnd@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On Fri, Jan 27, 2023 at 10:36:20AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > At the moment, accel drivers can be built-in even with CONFIG_DRM=m, > but this causes a link failure: > > x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init': > ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc' > x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to `drmm_kmalloc' > x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove': > ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister' > x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe': > ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc' Ehh, this should not happen. > This could be avoided by making DRM_ACCEL a tristate symbol, which > would mean that every ACCEL driver is guarantee to be able to link > against DRM as well. However, having both as =m causes another link > failure because the DRM core code also links against the accel driver: > > x86_64-linux-ld: drivers/gpu/drm/drm_drv.o: in function `drm_minor_register': > drm_drv.c:(.text+0x259): undefined reference to `accel_debugfs_init' > x86_64-linux-ld: drm_drv.c:(.text+0x298): undefined reference to `accel_minor_replace' > > I think it will be necessary to establish a link hierarchy between drm.ko > and drm_accel.ko to avoid circular dependencies like this, but until then > the only way that both can be used is to have both subsystems built into > the kernel. Enforce this using a Kconfig dependency. Hmm, it was discussed a bit before and conclusion was that accel will be compiled in drm.ko to avoid circular dependencies. There should be no drm_accel.ko module. > Fixes: 8bf4889762a8 ("drivers/accel: define kconfig and register a new major") > Signed-off-by: Arnd Bergmann > --- > drivers/accel/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig > index 834863902e16..dd18d3b2028c 100644 > --- a/drivers/accel/Kconfig > +++ b/drivers/accel/Kconfig > @@ -8,7 +8,7 @@ > # > menuconfig DRM_ACCEL > bool "Compute Acceleration Framework" > - depends on DRM > + depends on DRM=y Would making ivpu Kconfig: depends on DRM select DRM_ACCEL solve the problem and still allow to drm to be build as module ? Regards Stanislaw