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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22353C433ED for ; Mon, 12 Apr 2021 13:12:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8AF996134F for ; Mon, 12 Apr 2021 13:12:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AF996134F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 141326B0036; Mon, 12 Apr 2021 09:12:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F18C6B006C; Mon, 12 Apr 2021 09:12:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAD216B006E; Mon, 12 Apr 2021 09:12:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id C8B636B0036 for ; Mon, 12 Apr 2021 09:12:33 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 667666D80 for ; Mon, 12 Apr 2021 13:12:33 +0000 (UTC) X-FDA: 78023754186.19.80F0465 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf09.hostedemail.com (Postfix) with ESMTP id E6E0E600010B for ; Mon, 12 Apr 2021 13:12:29 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CFAFD1063; Mon, 12 Apr 2021 06:12:31 -0700 (PDT) Received: from [10.57.58.164] (unknown [10.57.58.164]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1FDDA3F73B; Mon, 12 Apr 2021 06:12:27 -0700 (PDT) Subject: Re: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA To: David Hildenbrand , Arnd Bergmann Cc: Linux Fbdev development list , linux-aspeed , David Airlie , Linus Walleij , dri-devel , "open list:BROADCOM NVRAM DRIVER" , Paul Cercueil , Eric Anholt , Christoph Hellwig , Masahiro Yamada , Michal Simek , Jason Gunthorpe , Joel Stanley , Russell King , Thomas Zimmermann , Bartlomiej Zolnierkiewicz , Maarten Lankhorst , The etnaviv authors , Maxime Ripard , Christian Gmeiner , Peter Collingbourne , Linux ARM , "Alexander A. Klimov" , Linux-MM , Andrew Jeffery , Linux Kernel Mailing List , "open list:IOMMU DRIVERS" , Daniel Vetter , Andrew Morton , Mike Rapoport , Lucas Stach References: <20210409112035.27221-1-david@redhat.com> <53ec94ac-ffe3-d0bc-d081-3489fa03daa1@redhat.com> From: Robin Murphy Message-ID: <34350446-0e0e-6947-40bd-fabdccdc835f@arm.com> Date: Mon, 12 Apr 2021 14:12:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <53ec94ac-ffe3-d0bc-d081-3489fa03daa1@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E6E0E600010B X-Stat-Signature: k47gjatiow9q7r5og9fihciwgnrcbom9 Received-SPF: none (arm.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=foss.arm.com; client-ip=217.140.110.172 X-HE-DKIM-Result: none/none X-HE-Tag: 1618233149-978899 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021-04-09 14:39, David Hildenbrand wrote: > On 09.04.21 15:35, Arnd Bergmann wrote: >> On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand =20 >> wrote: >>> >>> Random drivers should not override a user configuration of core knobs >>> (e.g., CONFIG_DMA_CMA=3Dn). Applicable drivers would like to use DMA_= CMA, >>> which depends on CMA, if possible; however, these drivers also have t= o >>> tolerate if DMA_CMA is not available/functioning, for example, if no = CMA >>> area for DMA_CMA use has been setup via "cma=3DX". In the worst case,= the >>> driver cannot do it's job properly in some configurations. >>> >>> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and=20 >>> DMA_CMA if >>> available") documents >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 While this is no bui= ld dependency, etnaviv will only work=20 >>> correctly >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on most systems if C= MA and DMA_CMA are enabled. Select both=20 >>> options >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if available to avoi= d users ending up with a non-working GPU=20 >>> due to >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a lacking kernel con= fig. >>> So etnaviv really wants to have DMA_CMA, however, can deal with some=20 >>> cases >>> where it is not available. >>> >>> Let's introduce WANT_DMA_CMA and use it in most cases where drivers >>> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA beca= use >>> of recursive dependency issues). >>> >>> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or >>> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible. >>> >>> With this change, distributions can disable CONFIG_CMA or >>> CONFIG_DMA_CMA, without it silently getting enabled again by random >>> drivers. Also, we'll now automatically try to enabled both, CONFIG_CM= A >>> and CONFIG_DMA_CMA if they are unspecified and any driver is around t= hat >>> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or >>> DRM_KMS_CMA_HELPER. >>> >>> For example, if any driver selects WANT_DMA_CMA and we do a >>> "make olddefconfig": >>> >>> 1. With "# CONFIG_CMA is not set" and no specification of >>> =C2=A0=C2=A0=C2=A0 "CONFIG_DMA_CMA" >>> >>> -> CONFIG_DMA_CMA won't be part of .config >>> >>> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA >>> >>> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW) >>> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW) >>> >>> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set" >>> >>> -> CONFIG_DMA_CMA will be removed from .config >>> >>> Note: drivers/remoteproc seems to be special; commit c51e882cd711 >>> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains=20 >>> that >>> there is a real dependency to DMA_CMA for it to work; leave that=20 >>> dependency >>> in place and don't convert it to a soft dependency. >> >> I don't think this dependency is fundamentally different from the othe= rs, >> though davinci machines tend to have less memory than a lot of the >> other machines, so it's more likely to fail without CMA. >> >=20 > I was also unsure - and Lucas had similar thoughts. If you want, I can=20 > send a v4 also taking care of this. TBH I think it should all just be removed. DMA_CMA is effectively an=20 internal feature of the DMA API, and drivers which simply use the DMA=20 API shouldn't really be trying to assume *how* things might be allocated=20 at runtime - CMA is hardly the only way. Platform-level assumptions=20 about the presence or not of IOMMUs, memory carveouts, etc., and whether=20 it even matters - e.g. a device with a tiny LCD may only need display=20 buffers which still fit in a regular MAX_ORDER allocation - could go in=20 platform-specific configs, but I really don't think they belong at the=20 generic subsystem level. We already have various examples like I2S drivers that won't even probe=20 without a dmaengine provider being present, or host controller drivers=20 which are useless without their corresponding phy driver (and I'm=20 guessing you can probably also do higher-level things like include the=20 block layer but omit all filesystem drivers). I don't believe it's=20 Kconfig's job to try to guess whether a given configuration is *useful*,=20 only to enforce that's it's valid to build. Robin.