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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D604DC04A6A for ; Thu, 3 Aug 2023 17:34:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63ED0280287; Thu, 3 Aug 2023 13:34:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EE8928022C; Thu, 3 Aug 2023 13:34:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B658280287; Thu, 3 Aug 2023 13:34:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3B73C28022C for ; Thu, 3 Aug 2023 13:34:18 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 01AEA1A07FB for ; Thu, 3 Aug 2023 17:34:17 +0000 (UTC) X-FDA: 81083492196.23.CE6A8FB Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by imf15.hostedemail.com (Postfix) with ESMTP id 12803A0021 for ; Thu, 3 Aug 2023 17:34:14 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ieYA6bVx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of pintu.ping@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=pintu.ping@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691084055; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s8Xa9pYsN9q26Cy2OfWksmVuBviyVuvzRMdasYi4RPE=; b=U0UUi2+k4MjkEw5qIO7pHlegrWN8QY+ejo94pZ1GRSl+yekiChEY4SDph75Tso+c7NII0k YxlRQpNbkEadGAZVLzz+l/70iR0Sv+fjICr2LiiEsrlk17U8IwtMVxtwHXXrdWYn4/4sA3 myBM2rEpEsun9upM50LxuxMotfB28X0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ieYA6bVx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of pintu.ping@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=pintu.ping@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691084055; a=rsa-sha256; cv=none; b=bLdnRG3M7EhPY+UEAhfBydXXkAeHf93lUEY5w7RwIgEI3GgcAsNL/fjNVKa2txTAYoY0X1 V2Lk9NDZNed7364VOmzytjrkXbsjOFDdVIIBnKP+deXPFMtaWY/1ozSn98aaTs3v5eEa8k JpnznGL1Aojc6UxEcYVr7qxo/n/xGEw= Received: by mail-vs1-f49.google.com with SMTP id ada2fe7eead31-447d04c6d58so206741137.0 for ; Thu, 03 Aug 2023 10:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691084054; x=1691688854; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=s8Xa9pYsN9q26Cy2OfWksmVuBviyVuvzRMdasYi4RPE=; b=ieYA6bVxf1lbXkgHAn+hXhVfxzKe711nmI2r+8a2Pkje45GQmKLftZmaLt0qar82gg SFBl/K1845mX6+FAqPkGcjyrpBXYikncS74nQOppvoyKSHXe0rCclfsEAXrPauDBdjLV e25KI/Uu6/whFSVJCUzOwGJkV3uYaP9OmOzDMNjjkk1ts8gnSQW1ex6gNo+0kzwO65XL HyypX83EJT7/21befwOJ9uRlgd3lhXqtj1LN6iNBdvKWKSCrS9QQZFXiZGxHkCMMLy82 +seRRUC93Y1mRKPJn8r746QD8Gi1bfCC2+B+iopA0nXA09o5X8xylmqFAP/A/rLnnA0P /oIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691084054; x=1691688854; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=s8Xa9pYsN9q26Cy2OfWksmVuBviyVuvzRMdasYi4RPE=; b=mC+IHtlMtLLJCJZtDxhmmoP4xvnj8W0fsjXR7x6hzJvKn6VFmJ7/wG6S0btwNKFhdT 6irL0GcxC1LaXodzIEokijz9TraV9ojA2zzTP6u00qgyzEQ9oSFxbDL4srkL/ynGnNiL xu4ZroK3F0Q48GIJkIw4ZKEuNL9Pojhzf6FK/nkF5ZM1EQK9SWXRMNd8IkjOnEWZSjkB 3LRnMYKIxgvFRPDP8ESLWt6tkrIKm0gfm4ZbkJU58Hy+SO8CcWLtnh+8oo2qykdaqK8A d9sBsj3S22Xrs6+JTBlCTWDZ60VHeTE2EPoKRlqcQDdbZtYbCqsfa4eJgFA5FcNTsYZp e6qw== X-Gm-Message-State: ABy/qLbVnCqKBvOdDDQRluiV0NIsMYYMOrISwPh/wwrhWoBaydVoB5KY TR69oPVf6BsHNw0GtIpEcWcgl52VlcgSIK7XjwA= X-Google-Smtp-Source: APBJJlG6pjOoG0q6RAsawh+9qeUBUHt8XE1GKbQlIBPYmQFLRffHoU6WGPDLy5lU6fh2CQ1SS4cFWeU/BvylteONzOI= X-Received: by 2002:a05:6102:d8a:b0:443:5524:8f8b with SMTP id d10-20020a0561020d8a00b0044355248f8bmr4828038vst.4.1691084054017; Thu, 03 Aug 2023 10:34:14 -0700 (PDT) MIME-Version: 1.0 References: <1690598115-26287-1-git-send-email-quic_pintu@quicinc.com> <20230731112155.GA3662@lst.de> <20230801171838.GA14599@lst.de> <20230802094725.GA28241@lst.de> In-Reply-To: <20230802094725.GA28241@lst.de> From: Pintu Agarwal Date: Thu, 3 Aug 2023 23:04:02 +0530 Message-ID: Subject: Re: [PATCH v2] dma-contiguous: define proper name for global cma region To: Christoph Hellwig Cc: John Stultz , Pintu Kumar , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux.dev, Sumit Semwal , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , =?UTF-8?Q?Christian_K=C3=B6nig?= , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 12803A0021 X-Stat-Signature: joemowkephairr8jowkfgdn8wzembg4n X-Rspam-User: X-HE-Tag: 1691084054-941027 X-HE-Meta: U2FsdGVkX1/Q9bXDFkV7pru42X4tMCAiUV2dRKGjab+uF/xN2QPoXisiEusO/VmH+liJmUnvlIWVH3a5Q579+26UAj88ICE8lvdokU2SzK3Lm+Kl7crQHSlq2oSgMyZcQtMBBNkJ1Om0roguqTU8GEXvhHa/yJQuc1QzfCLa0SwPCcc1L82VplxbtMeW2bU1vcucKOE6SxDbcVPISf/mGIMxG0KjqliiwqEIYIigrIAtHeKxYX4G1pDdbvY2XivS4U/blHE1FEMLA3l+nUv4gTu/+upNP+qhxxS4upaHquHqdoDcH9aWxGca0kocDpVGoav5I06hu1kJAtUoJQFaLJOBMQcBKyY4JwP/Mmxb7lOln1yIFxIm7iZtWkVKijvTSEYhbwwGvdrEttAThWxv3od72DTDATdDXBmkth1+D3UfwA5kpj8yod8jjQNE+Ztr82/NurGQI3uDep3CPprHFCyM46DE85+1wwuyTtDPMVKSabJ8D1czIDqG3o0cJbmfjpUZFgN2I+lW+liQqHiyIxBD8DhHg6G1FO5OQa99lSJfYoMy+BlncWaw1Oyun2r5GK7elog6AMi00rkb2+1Z4EG+s9/+ZIE3R5HjWX4bZ+8NcQUBAcOigM+7UGrJRHcq/qOUaSpNAYkaVIS9gzaa9oaP8dZ6QJ1w7qaBwm/AbDIDHo0NIRbTGii94XLC+3QGp14GhBMYUuoBJiq3wd9s81g+u9aKy9AXvDtW7vy/25bpjMvHj37y4u/15LtvHAIdjtFmKUk3MPjIDZYCNLA0ua4Nkt1xULeIKmO1MvN2jyQ5Oi0R1F2pk4ObqohG1walaid1PwxXDv+4pGc7VZa0O8PAtvYQXS26bkfW91qX0iOISOsWlhLDAcfI6YmGnedf8waEJoySpEjECXYCTQe9V1OCBXoT9GAF0wx4bPx5RUqHr+bLkZknamsOqMDnQywqQsb7y6EgEN6aALBEs55 J3SbOZQW XRJ0CLXo905Gd633dWgjRHP9A0nEQ2OzkorXzMg6cw45e+bYQJ0U0NuxGxZ3pvGtzxrsM9e6Eqk5JViQ8CYpLQV7XC2CCxMtIReBLUpqNZFOirJXNG9LhR+b9AUKnnT1L+WkQ1Ej/fC6W7gmfKSuEDLLt3aTlp0xFwsqlTiT5Gq2f6jMGojwiclAq/KmD+k9xNPnsbl2w8JaGXkQVwMEocdEFN1LTXlC5zhwukJ4p64Y/oiDHfNJtrhWd+OZte9MjtkkV+dukA93yMDEq/8oTuZqgEfZUszIptCyK1EKobBWBIKsZwTyDgRAc7B2KoYD2pt3QyIcyguFU4zD4kVG22ztY+FzmNa3LPYlKJOMMY96EMCU7qHka0MMTVij7XZfwTcv1 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: Hi, On Wed, 2 Aug 2023 at 15:17, Christoph Hellwig wrote: > > On Tue, Aug 01, 2023 at 10:39:04PM -0700, John Stultz wrote: > > So, forgive me, I've not had a chance to look into this, but my > > recollection was "reserved" is the name we see on x86, but other names > > are possibly provided via the dts node? > No, I think "reserved" is the name hard-coded (for all arch) in Kernel for global-cma. So, I don't think this is x86 specific. I am checking on arm32 itself. When we can dma_alloc_coherent we see these in the logs (if dts region is not present). cma: cma_alloc(cma (ptrval), name: reserved, count 64, align 6) Now, with this change we will see this: cma: cma_alloc(cma (ptrval), name: global-cma-region, count 64, align 6) > Indeed, dma_contiguous_default_area can also be set through > rmem_cma_setup, which then takes the name from DT. > I think this is a different case. If DT entry is present we get this: Reserved memory: created CMA memory pool at 0x98000000, name: name: linux,cma, size 128 MiB cma: cma_alloc(cma (ptrval), name: linux,cma, count 64, align 6) Here we are talking about the default hard-coded name in Kernel code if DT is not defined. So, in one of the boards, this DT entry was not present and it shows as "reserved". > > I believe on the hikey board its "linux,cma" is the name, so forcing > > it to reserved would break that. > > Yes, everywhere in the DT it's defined as "linux,cma". You mean this also should be changed to "linux,cma-global-region" everywhere with this change ? > > Maybe instead add a compat config option to force the cma name (so x86 > > can set it to "default" if needed)? > Yes, having it in config is also a good option instead of hard-coding in Ke= rnel. > > I think we'll just need to leave it as-is. I with dma-heaps had never > exposed the name to userspace, but we'll have to l=D1=96ve with it now. Can you point me to the userspace utility we are talking about here ? I think we should not worry much about userspace name exposure. I guess it should fetch whatever is declared in Kernel or DTS, right ?