[{"id":33999,"web_url":"https://patchwork.libcamera.org/comment/33999/","msgid":"<20250422222231.GT17813@pendragon.ideasonboard.com>","date":"2025-04-22T22:22:31","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Bryan,\n\nThank you for the patch.\n\nOn Tue, Apr 22, 2025 at 10:58:56PM +0100, Bryan O'Donoghue wrote:\n> When /dev/dma_heap/linux,cma or /dev/dma_heap/system exist currently we\n> favour allocation from this type of heap over /dev/udmabuf.\n> \n> We ought to favour udmabuf though\n> \n> - udmabuf is the preferred method by various distros for security reasons\n> - Contiguous memory is a scarce resource\n> \n> Change the ordering of the allocator lookup so that the udmabuf lookup\n> comes first.\n\nThis means that on a system where CMA allocation is possible from\nuserspace, the buffers allocated by libcamera for the virtual pipeline\nhandler and ISP won't be shareable without copies with a consumer that\nrequires contiguous memory (e.g. most KMS devices on Arm platforms).\nIsn't that an issue ? It seems to even count as a regression.\n\n> Fixes: ea4baaacc325 (\"libcamera: DmaBufAllocator: Support allocating from /dev/udmabuf\")\n> Signed-off-by: Bryan O'Donoghue \n> ---\n> src/libcamera/dma_buf_allocator.cpp | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/src/libcamera/dma_buf_allocator.cpp b/src/libcamera/dma_buf_allocator.cpp\n> index d8c62dd6..722ffd46 100644\n> --- a/src/libcamera/dma_buf_allocator.cpp\n> +++ b/src/libcamera/dma_buf_allocator.cpp\n> @@ -45,10 +45,10 @@ static constexpr std::array providerInfos = { {\n> \t * /dev/dma_heap/linux,cma is the CMA dma-heap. When the cma heap size is\n> \t * specified on the kernel command line, this gets renamed to \"reserved\".\n> \t */\n> +\t{ DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> \t{ DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/linux,cma\" },\n> \t{ DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/reserved\" },\n> \t{ DmaBufAllocator::DmaBufAllocatorFlag::SystemHeap, \"/dev/dma_heap/system\" },\n> -\t{ DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> } };\n> \n> LOG_DEFINE_CATEGORY(DmaBufAllocator)","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C23B3BE08B\n\tfor ;\n\tTue, 22 Apr 2025 22:22:37 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0238168ACD;\n\tWed, 23 Apr 2025 00:22:37 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A42A568AC5\n\tfor ;\n\tWed, 23 Apr 2025 00:22:34 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 1743516A;\n\tWed, 23 Apr 2025 00:22:33 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"aOQm0HIt\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1745360553;\n\tbh=NdqPeqin/PRbTOpQfGztA/tgLC0Mv8fQ75Y0/u2UQoY=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=aOQm0HItZzDqBXz99lMLnlljWTUTUAirCn6UZSImqtet70UcMeZjXa7RO0tXbcgBH\n\tPR7PiodFc02QmJocH3QGqagh3Bn/dEgAkAIxZnowpv5CdNVPEZNXJMN6hi3nKY0XFQ\n\tnYz0FZ6KmtROlhC3J1clBXDucj6Ut7s56mQSpxVA=","Date":"Wed, 23 Apr 2025 01:22:31 +0300","From":"Laurent Pinchart ","To":"Bryan O'Donoghue ","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com, bod.linux@nxsw.ie","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","Message-ID":"<20250422222231.GT17813@pendragon.ideasonboard.com>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20250422215920.4297-4-bryan.odonoghue@linaro.org>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34011,"web_url":"https://patchwork.libcamera.org/comment/34011/","msgid":"<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>","date":"2025-04-23T09:36:57","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Quoting Laurent Pinchart (2025-04-22 23:22:31)\n> Hi Bryan,\n> \n> Thank you for the patch.\n> \n> On Tue, Apr 22, 2025 at 10:58:56PM +0100, Bryan O'Donoghue wrote:\n> > When /dev/dma_heap/linux,cma or /dev/dma_heap/system exist currently we\n> > favour allocation from this type of heap over /dev/udmabuf.\n> > \n> > We ought to favour udmabuf though\n> > \n> > - udmabuf is the preferred method by various distros for security reasons\n> > - Contiguous memory is a scarce resource\n> > \n> > Change the ordering of the allocator lookup so that the udmabuf lookup\n> > comes first.\n> \n> This means that on a system where CMA allocation is possible from\n> userspace, the buffers allocated by libcamera for the virtual pipeline\n> handler and ISP won't be shareable without copies with a consumer that\n> requires contiguous memory (e.g. most KMS devices on Arm platforms).\n> Isn't that an issue ? It seems to even count as a regression.\n> \n\nOn my X13s, everything works better for me on udmabuf. If we try to use\nthe cma allocator things fail.\n\nThat /could/ be a separate topic/issue - but at least might explain some\nof the rationale behind this.\n\nI usually end up with something like this on my system.\n\n\n> > Fixes: ea4baaacc325 (\"libcamera: DmaBufAllocator: Support allocating from /dev/udmabuf\")\n> > Signed-off-by: Bryan O'Donoghue \n> > ---\n> > src/libcamera/dma_buf_allocator.cpp | 2 +-\n> > 1 file changed, 1 insertion(+), 1 deletion(-)\n> > \n> > diff --git a/src/libcamera/dma_buf_allocator.cpp b/src/libcamera/dma_buf_allocator.cpp\n> > index d8c62dd6..722ffd46 100644\n> > --- a/src/libcamera/dma_buf_allocator.cpp\n> > +++ b/src/libcamera/dma_buf_allocator.cpp\n> > @@ -45,10 +45,10 @@ static constexpr std::array providerInfos = { {\n> > * /dev/dma_heap/linux,cma is the CMA dma-heap. When the cma heap size is\n> > * specified on the kernel command line, this gets renamed to \"reserved\".\n> > */\n> > + { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/linux,cma\" },\n> > { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/reserved\" },\n> > { DmaBufAllocator::DmaBufAllocatorFlag::SystemHeap, \"/dev/dma_heap/system\" },\n> > - { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > } };\n> > \n> > LOG_DEFINE_CATEGORY(DmaBufAllocator)\n> \n> -- \n> Regards,\n> \n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 80BD8C327D\n\tfor ;\n\tWed, 23 Apr 2025 09:37:01 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 10F4F68ACB;\n\tWed, 23 Apr 2025 11:37:01 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 35664617E5\n\tfor ;\n\tWed, 23 Apr 2025 11:37:00 +0200 (CEST)","from pendragon.ideasonboard.com\n\t(cpc89244-aztw30-2-0-cust6594.18-1.cable.virginm.net [86.31.185.195])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id D127522A;\n\tWed, 23 Apr 2025 11:36:58 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"E8NCq//o\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1745401018;\n\tbh=kT0sP3RVVKrLJ0AYUqHJ/uXCQ8vCuKiHlhxr/qgmLxk=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=E8NCq//oGXm7Colkpvn9A8OlTPrHixwvwwvI1wI5VJQtfh8KV9143Lhw849uhdYAe\n\tabSWpRzsC/T6ZbgdHm4q4xuAhgaGMpVdy1MFVhbKYbdmXJI9IBj6pXh1l5TXANHzmb\n\t7eSmOvFEhEpzQSUtbibPDGToJxeiT2disCWcUlUc=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"<20250422222231.GT17813@pendragon.ideasonboard.com>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Kieran Bingham ","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com, bod.linux@nxsw.ie","To":"Bryan O'Donoghue ,\n\tLaurent Pinchart ","Date":"Wed, 23 Apr 2025 10:36:57 +0100","Message-ID":"<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>","User-Agent":"alot/0.10","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34014,"web_url":"https://patchwork.libcamera.org/comment/34014/","msgid":"","date":"2025-04-23T12:50:03","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le mercredi 23 avril 2025 à 10:36 +0100, Kieran Bingham a écrit :\n> Quoting Laurent Pinchart (2025-04-22 23:22:31)\n> > Hi Bryan,\n> > \n> > Thank you for the patch.\n> > \n> > On Tue, Apr 22, 2025 at 10:58:56PM +0100, Bryan O'Donoghue wrote:\n> > > When /dev/dma_heap/linux,cma or /dev/dma_heap/system exist currently we\n> > > favour allocation from this type of heap over /dev/udmabuf.\n> > > \n> > > We ought to favour udmabuf though\n> > > \n> > > - udmabuf is the preferred method by various distros for security reasons\n> > > - Contiguous memory is a scarce resource\n> > > \n> > > Change the ordering of the allocator lookup so that the udmabuf lookup\n> > > comes first.\n> > \n> > This means that on a system where CMA allocation is possible from\n> > userspace, the buffers allocated by libcamera for the virtual pipeline\n> > handler and ISP won't be shareable without copies with a consumer that\n> > requires contiguous memory (e.g. most KMS devices on Arm platforms).\n> > Isn't that an issue ? It seems to even count as a regression.\n> > \n> \n> On my X13s, everything works better for me on udmabuf. If we try to use\n> the cma allocator things fail.\n> \n> That /could/ be a separate topic/issue - but at least might explain some\n> of the rationale behind this.\n> \n> I usually end up with something like this on my system.\n\nDid you mean to add a link ? I'm quite curious, since here on Meteor\nLake GPU, passing over anything that has been touched by the CPU\nresults in a big mess. This used to only happen when passing these to\nthe display controller, now the GPU also does not handle the CPU\ncoherent memory properly.\n\nNicolas\n\n> \n> \n> > > Fixes: ea4baaacc325 (\"libcamera: DmaBufAllocator: Support allocating from /dev/udmabuf\")\n> > > Signed-off-by: Bryan O'Donoghue \n> > > ---\n> > >  src/libcamera/dma_buf_allocator.cpp | 2 +-\n> > >  1 file changed, 1 insertion(+), 1 deletion(-)\n> > > \n> > > diff --git a/src/libcamera/dma_buf_allocator.cpp b/src/libcamera/dma_buf_allocator.cpp\n> > > index d8c62dd6..722ffd46 100644\n> > > --- a/src/libcamera/dma_buf_allocator.cpp\n> > > +++ b/src/libcamera/dma_buf_allocator.cpp\n> > > @@ -45,10 +45,10 @@ static constexpr std::array providerInfos = { {\n> > >        * /dev/dma_heap/linux,cma is the CMA dma-heap. When the cma heap size is\n> > >        * specified on the kernel command line, this gets renamed to \"reserved\".\n> > >        */\n> > > +     { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > >       { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/linux,cma\" },\n> > >       { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/reserved\" },\n> > >       { DmaBufAllocator::DmaBufAllocatorFlag::SystemHeap, \"/dev/dma_heap/system\" },\n> > > -     { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > >  } };\n> > >  \n> > >  LOG_DEFINE_CATEGORY(DmaBufAllocator)\n> > \n> > -- \n> > Regards,\n> > \n> > Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id D7A78BE08B\n\tfor ;\n\tWed, 23 Apr 2025 12:50:08 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id BBC6868ACD;\n\tWed, 23 Apr 2025 14:50:07 +0200 (CEST)","from mail-qt1-x829.google.com (mail-qt1-x829.google.com\n\t[IPv6:2607:f8b0:4864:20::829])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 50DAD68AC6\n\tfor ;\n\tWed, 23 Apr 2025 14:50:06 +0200 (CEST)","by mail-qt1-x829.google.com with SMTP id\n\td75a77b69052e-476f4e9cf92so47436011cf.3\n\tfor ;\n\tWed, 23 Apr 2025 05:50:06 -0700 (PDT)","from ?IPv6:2606:6d00:15:9913::5ac? ([2606:6d00:15:9913::5ac])\n\tby smtp.gmail.com with ESMTPSA id\n\td75a77b69052e-47ae9c3b5c3sm68227081cf.21.2025.04.23.05.50.03\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tWed, 23 Apr 2025 05:50:04 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=ndufresne-ca.20230601.gappssmtp.com\n\theader.i=@ndufresne-ca.20230601.gappssmtp.com\n\theader.b=\"gSZ2J6JW\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1745412605;\n\tx=1746017405; darn=lists.libcamera.org; \n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=cuXmZEGZm7ySxmfsn9YvJbvwxU58QM5nAOjW/OCTPes=;\n\tb=gSZ2J6JWMW08ogX/IR7IPQwZcRyGad/TPTL+wHgZElW4D+unzRqW+BNI4FmvjvZ5qm\n\t9AP51OaQDYosqMGh/NEZV+f0BE0OGx1tzxcbWc44FuLcSOO8S0bbBzPEMcLCXEBz5mK0\n\tAciOgM08Rlxs7dt5svqBrh1FTweEkX0GxXsdisRyEUNOS2KkqzXcJDnCvaY3cTU4WyxG\n\tMJq7O7e03hxdgITGxp0MnfyxYmggmZTLJSI7nObkfe+xShsme8UOxUOplWm1bPsXI9Ao\n\tKK6cyV9Ezku+BmFO8KcHVc5n6+zlL4W+89KgB8aYTeXuAtUqdtcsGF9VbHH6QcraLXwW\n\t6piw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1745412605; x=1746017405;\n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state\n\t:from:to:cc:subject:date:message-id:reply-to;\n\tbh=cuXmZEGZm7ySxmfsn9YvJbvwxU58QM5nAOjW/OCTPes=;\n\tb=tg5BDLNJPYp/tiXLedMI+PSHlWtScG71QxObFb0zZ33rDcsLnbEmQB76Sh2GlEJDya\n\tBvGo6bXT+RJDeEWQwcpFZbIX5Mku2uk9aLS/3k3g/wvzY+BW6bla3vB9OhnQ2+mZxU7o\n\tll1Hy98n2PSFxUfig1UfpuCBZstgobMtIS6apLEaYF7NSD14p7ca7RjHJeEzjcDTuFu2\n\tJnyItuHdgNZVCsJ8QkcEQUjOP7/hXqlBjr/POjFdyK3YtYYICbMpcgNNlVERkg2VB04S\n\t35nw5+Kif6j4ei9Mh5vM3m8XIlAwdG847j7hERxmYbd9srOvwMU+ZyxTywu0kz9QS3R1\n\t4NaQ==","X-Gm-Message-State":"AOJu0Yya/CXYZcYPJeI3YDqNjYWVGM9sYK2zW7htmBSqawhznxeUEm6r\n\t+trwNHXLeMZeBAJFlcEh7WOS/Iscy+B7A05e2o9ziJTNVTfS8jPhBe488WQN0qT6COjYYmnvxYb\n\tEeKo=","X-Gm-Gg":"ASbGncs6PEm6OG2iB1vwMeUC8Iki6H6fqj1IxCeF6NMFUPCDRfLwrJGe/gh6VQu5drX\n\tetAg+x5PFwy8gwoKBWwQrud8A+qncHoMcC3GyzSpcQS/ClmcH0pqxfo2VYJyghgbZRyj016XEt2\n\tUBr5twBotPLyhnLe9InEeCl2WgJljuNll0xbMlSd0zUyZ3GQxAPgOaGteJtpkd2QLs5o52VAknc\n\twTAJfaxQ9DQLVLpa2LfOR8HlDAED5jEZIEfxWGicA8CNVKVqDePAq1R0s60zRHiR4ix6abwibAW\n\tg163G4rwEQWJetW5mW76ZntP4Q2sdknWHziXKM+ZKf/DGA==","X-Google-Smtp-Source":"AGHT+IHdPVcO7O0z/PMSz1Br1vAcyaXMCO1wEyJnI4dW1Tcs9qhSGyjrlXeb9Ttx/kaLWF9VSe2+3g==","X-Received":"by 2002:a05:622a:1a92:b0:47a:e81b:ccbb with SMTP id\n\td75a77b69052e-47aec3761cdmr259452541cf.7.1745412605014; \n\tWed, 23 Apr 2025 05:50:05 -0700 (PDT)","Message-ID":"","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Nicolas Dufresne ","To":"Kieran Bingham , Bryan O'Donoghue\n\t, Laurent Pinchart\n\t","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com, \n\tmzamazal@redhat.com, bod.linux@nxsw.ie","Date":"Wed, 23 Apr 2025 08:50:03 -0400","In-Reply-To":"<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.56.0 (3.56.0-1.fc42) ","MIME-Version":"1.0","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34018,"web_url":"https://patchwork.libcamera.org/comment/34018/","msgid":"<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>","date":"2025-04-23T13:07:54","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Quoting Nicolas Dufresne (2025-04-23 13:50:03)\n> Le mercredi 23 avril 2025 à 10:36 +0100, Kieran Bingham a écrit :\n> > Quoting Laurent Pinchart (2025-04-22 23:22:31)\n> > > Hi Bryan,\n> > > \n> > > Thank you for the patch.\n> > > \n> > > On Tue, Apr 22, 2025 at 10:58:56PM +0100, Bryan O'Donoghue wrote:\n> > > > When /dev/dma_heap/linux,cma or /dev/dma_heap/system exist currently we\n> > > > favour allocation from this type of heap over /dev/udmabuf.\n> > > > \n> > > > We ought to favour udmabuf though\n> > > > \n> > > > - udmabuf is the preferred method by various distros for security reasons\n> > > > - Contiguous memory is a scarce resource\n> > > > \n> > > > Change the ordering of the allocator lookup so that the udmabuf lookup\n> > > > comes first.\n> > > \n> > > This means that on a system where CMA allocation is possible from\n> > > userspace, the buffers allocated by libcamera for the virtual pipeline\n> > > handler and ISP won't be shareable without copies with a consumer that\n> > > requires contiguous memory (e.g. most KMS devices on Arm platforms).\n> > > Isn't that an issue ? It seems to even count as a regression.\n> > > \n> > \n> > On my X13s, everything works better for me on udmabuf. If we try to use\n> > the cma allocator things fail.\n> > \n> > That /could/ be a separate topic/issue - but at least might explain some\n> > of the rationale behind this.\n> > \n> > I usually end up with something like this on my system.\n> \n> Did you mean to add a link ? I'm quite curious, since here on Meteor\n\nNo, sorry - In the text above, I meant \"I usually end up with something\nlike ... 'this patch' ... on my system\". Meaning I configure my x13s to\nprefer udmabuf over cma because cma allocations frequently fail for me.\n\nIt's not clear if it's a resource leak, or indeterminate usage by other\ncomponents - (hence might be something else to look into) but udmabuf\nalways works on softisp for x13s so far, so just use it.\n\n\n> Lake GPU, passing over anything that has been touched by the CPU\n> results in a big mess. This used to only happen when passing these to\n> the display controller, now the GPU also does not handle the CPU\n> coherent memory properly.\n\neven if the CPU only 'reads' the data ?\n\nFor GPU ISP - the only access the CPU should do is read the data to\ngenerate some statistics. And even that - I would hope in the future\nwill be turned into operations performed by the GPU ...\n\n--\nKiran\n\n\n> \n> Nicolas\n> \n> > \n> > \n> > > > Fixes: ea4baaacc325 (\"libcamera: DmaBufAllocator: Support allocating from /dev/udmabuf\")\n> > > > Signed-off-by: Bryan O'Donoghue \n> > > > ---\n> > > >  src/libcamera/dma_buf_allocator.cpp | 2 +-\n> > > >  1 file changed, 1 insertion(+), 1 deletion(-)\n> > > > \n> > > > diff --git a/src/libcamera/dma_buf_allocator.cpp b/src/libcamera/dma_buf_allocator.cpp\n> > > > index d8c62dd6..722ffd46 100644\n> > > > --- a/src/libcamera/dma_buf_allocator.cpp\n> > > > +++ b/src/libcamera/dma_buf_allocator.cpp\n> > > > @@ -45,10 +45,10 @@ static constexpr std::array providerInfos = { {\n> > > >        * /dev/dma_heap/linux,cma is the CMA dma-heap. When the cma heap size is\n> > > >        * specified on the kernel command line, this gets renamed to \"reserved\".\n> > > >        */\n> > > > +     { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > > >       { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/linux,cma\" },\n> > > >       { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/reserved\" },\n> > > >       { DmaBufAllocator::DmaBufAllocatorFlag::SystemHeap, \"/dev/dma_heap/system\" },\n> > > > -     { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > > >  } };\n> > > >  \n> > > >  LOG_DEFINE_CATEGORY(DmaBufAllocator)\n> > > \n> > > -- \n> > > Regards,\n> > > \n> > > Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 614DDC327D\n\tfor ;\n\tWed, 23 Apr 2025 13:07:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id A053168AC7;\n\tWed, 23 Apr 2025 15:07:58 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id BB59768AC6\n\tfor ;\n\tWed, 23 Apr 2025 15:07:57 +0200 (CEST)","from pendragon.ideasonboard.com\n\t(cpc89244-aztw30-2-0-cust6594.18-1.cable.virginm.net [86.31.185.195])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 4D38516A;\n\tWed, 23 Apr 2025 15:07:56 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"nUM/3mBn\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1745413676;\n\tbh=tjnt3sneMYxjVUjTuwq/BfJ43nPQJPx33zbjEkzdqEY=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=nUM/3mBnGiOC8FSvei45HUbBSIdLeRXA11iGqQ4zSqVLVUUJ76u9YHIMOZoU1ikf7\n\t3TtnoXasXzPM1Fr2DtGAtBmLLWUFEW6QsCzDJDfqOjFdj9jEDuTBDFc28xEUqaPBUI\n\tGi7dtf/iihPaPHdGcUoZ3p2tEESi5oRtuaniRSJM=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Kieran Bingham ","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com, bod.linux@nxsw.ie","To":"Bryan O'Donoghue ,\n\tLaurent Pinchart ,\n\tNicolas Dufresne ","Date":"Wed, 23 Apr 2025 14:07:54 +0100","Message-ID":"<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>","User-Agent":"alot/0.10","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34029,"web_url":"https://patchwork.libcamera.org/comment/34029/","msgid":"","date":"2025-04-24T13:17:48","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le mercredi 23 avril 2025 à 14:07 +0100, Kieran Bingham a écrit :\n> Quoting Nicolas Dufresne (2025-04-23 13:50:03)\n> > Le mercredi 23 avril 2025 à 10:36 +0100, Kieran Bingham a écrit :\n> > > Quoting Laurent Pinchart (2025-04-22 23:22:31)\n> > > > Hi Bryan,\n> > > > \n> > > > Thank you for the patch.\n> > > > \n> > > > On Tue, Apr 22, 2025 at 10:58:56PM +0100, Bryan O'Donoghue wrote:\n> > > > > When /dev/dma_heap/linux,cma or /dev/dma_heap/system exist currently we\n> > > > > favour allocation from this type of heap over /dev/udmabuf.\n> > > > > \n> > > > > We ought to favour udmabuf though\n> > > > > \n> > > > > - udmabuf is the preferred method by various distros for security reasons\n> > > > > - Contiguous memory is a scarce resource\n> > > > > \n> > > > > Change the ordering of the allocator lookup so that the udmabuf lookup\n> > > > > comes first.\n> > > > \n> > > > This means that on a system where CMA allocation is possible from\n> > > > userspace, the buffers allocated by libcamera for the virtual pipeline\n> > > > handler and ISP won't be shareable without copies with a consumer that\n> > > > requires contiguous memory (e.g. most KMS devices on Arm platforms).\n> > > > Isn't that an issue ? It seems to even count as a regression.\n> > > > \n> > > \n> > > On my X13s, everything works better for me on udmabuf. If we try to use\n> > > the cma allocator things fail.\n> > > \n> > > That /could/ be a separate topic/issue - but at least might explain some\n> > > of the rationale behind this.\n> > > \n> > > I usually end up with something like this on my system.\n> > \n> > Did you mean to add a link ? I'm quite curious, since here on Meteor\n> \n> No, sorry - In the text above, I meant \"I usually end up with something\n> like ... 'this patch' ... on my system\". Meaning I configure my x13s to\n> prefer udmabuf over cma because cma allocations frequently fail for me.\n> \n> It's not clear if it's a resource leak, or indeterminate usage by other\n> components - (hence might be something else to look into) but udmabuf\n> always works on softisp for x13s so far, so just use it.\n> \n> \n> > Lake GPU, passing over anything that has been touched by the CPU\n> > results in a big mess. This used to only happen when passing these to\n> > the display controller, now the GPU also does not handle the CPU\n> > coherent memory properly.\n> \n> even if the CPU only 'reads' the data ?\n\nIts any CPU write -> GPU that in serious trouble on recent Intel. That\nbeing said, if nothing either flush or invalidate the cache, if you\nread before, write with GPU, and read again after that same buffer, the\ndata you'll read may be from old cache. In practice, GPU don't do\nanything in-place, so that is non-issue here.\n\n> \n> For GPU ISP - the only access the CPU should do is read the data to\n> generate some statistics. And even that - I would hope in the future\n> will be turned into operations performed by the GPU ...\n\nSo read bayer, process in GPU, output YUV should just work. Thanks for\nclarification, running out of CMA is pretty common, defaults CMA\nreservation is usually very small. Appart from the buggy drivers,\nvirtual memory is a much better choice, and this is mostly what this\npatch is about here.\n\nNicolas\n\n> \n> --\n> Kiran\n> \n> \n> > \n> > Nicolas\n> > \n> > > \n> > > \n> > > > > Fixes: ea4baaacc325 (\"libcamera: DmaBufAllocator: Support allocating from /dev/udmabuf\")\n> > > > > Signed-off-by: Bryan O'Donoghue \n> > > > > ---\n> > > > >  src/libcamera/dma_buf_allocator.cpp | 2 +-\n> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)\n> > > > > \n> > > > > diff --git a/src/libcamera/dma_buf_allocator.cpp b/src/libcamera/dma_buf_allocator.cpp\n> > > > > index d8c62dd6..722ffd46 100644\n> > > > > --- a/src/libcamera/dma_buf_allocator.cpp\n> > > > > +++ b/src/libcamera/dma_buf_allocator.cpp\n> > > > > @@ -45,10 +45,10 @@ static constexpr std::array providerInfos = { {\n> > > > >        * /dev/dma_heap/linux,cma is the CMA dma-heap. When the cma heap size is\n> > > > >        * specified on the kernel command line, this gets renamed to \"reserved\".\n> > > > >        */\n> > > > > +     { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > > > >       { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/linux,cma\" },\n> > > > >       { DmaBufAllocator::DmaBufAllocatorFlag::CmaHeap, \"/dev/dma_heap/reserved\" },\n> > > > >       { DmaBufAllocator::DmaBufAllocatorFlag::SystemHeap, \"/dev/dma_heap/system\" },\n> > > > > -     { DmaBufAllocator::DmaBufAllocatorFlag::UDmaBuf, \"/dev/udmabuf\" },\n> > > > >  } };\n> > > > >  \n> > > > >  LOG_DEFINE_CATEGORY(DmaBufAllocator)\n> > > > \n> > > > -- \n> > > > Regards,\n> > > > \n> > > > Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 0923EBE08B\n\tfor ;\n\tThu, 24 Apr 2025 13:17:55 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id AEF1368ACD;\n\tThu, 24 Apr 2025 15:17:53 +0200 (CEST)","from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com\n\t[IPv6:2607:f8b0:4864:20::72e])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 2545D68AC5\n\tfor ;\n\tThu, 24 Apr 2025 15:17:52 +0200 (CEST)","by mail-qk1-x72e.google.com with SMTP id\n\taf79cd13be357-7c5e1b40f68so107546885a.1\n\tfor ;\n\tThu, 24 Apr 2025 06:17:52 -0700 (PDT)","from ?IPv6:2606:6d00:15:9913::5ac? ([2606:6d00:15:9913::5ac])\n\tby smtp.gmail.com with ESMTPSA id\n\taf79cd13be357-7c958c92078sm86484585a.16.2025.04.24.06.17.49\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tThu, 24 Apr 2025 06:17:50 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=ndufresne-ca.20230601.gappssmtp.com\n\theader.i=@ndufresne-ca.20230601.gappssmtp.com\n\theader.b=\"JjiO8QUu\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1745500671;\n\tx=1746105471; darn=lists.libcamera.org; \n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=Z5W7tLdsScENJX1gTAU+AHkhVvy8890gaW6g1nVkRYU=;\n\tb=JjiO8QUuUVhvy5CYXIMQYlvptWPczxTounpqvw5+d8iJLayVDr+CYFH8ChppVyF1xD\n\tSb9rFgaLQjx2GU53Vk/fQSIfbID0UjVWT1pd29KX1aP3xg29MggbK4LkVPcAsSh1gQ5Y\n\tjF4FNluy8oojJfoxGjuXCjTgpxJM/JKBI1dEhiwtmuYU/SmsBBjrVRKExAAemJIBaxqB\n\te6uuBeqYhx6KpMGm13Ae0d8EsbkT/CKQ2tLNQAotVUTMp5Jfb1H14ycLSBw8/RGmkG6l\n\t5Dd3hX8YDmovpbBjwVtqOgv5/ubcUGO9yFpmdxaKx5Ey05cHxdQw/TTFBAzZT5kmyU3v\n\tkLpQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1745500671; x=1746105471;\n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state\n\t:from:to:cc:subject:date:message-id:reply-to;\n\tbh=Z5W7tLdsScENJX1gTAU+AHkhVvy8890gaW6g1nVkRYU=;\n\tb=tTBYSnfSv9Z7Xb+zFPhjrMaoe9wsjk5AtjhJnB6d1TSTeCdpW99a8GPShMdbCcBZUf\n\t6usSXoa6eL4JAMFYCsZaDpvAWURnDD88iHX6+2cCO9OVEUNPzlcjT00rO3uEMlwdZuGD\n\tq8TRnVHe4chN6UgsMeT6m6XJ8k6Qw5kZg4mET6zM2SqS+kclH086Z4q9A2L2nWvPNJW2\n\tdjU0+U0DFz4w2nbcFI6BbmwBJM1MgowZRUzkLP4cje4xdnS/cAxGdGemA3AaXaTPP03J\n\t9vaQT3PO+Xg0RiY98NPOmNIIfFrqED5wNZvQMcrQAKaWsByJqMNdh5QZ5uOMTSaz7RRb\n\tIXkw==","X-Gm-Message-State":"AOJu0YxmkBLNlBmXcHkVUC8yXC4Ts5KzGSirSYIUhcj6LPWHB7v3oorn\n\tjHxb3rtVW3RE6bVaaH6AQKihZklmFHt3ViNnNvuVd+LMs0H9GDr4s392IrMB0Z8=","X-Gm-Gg":"ASbGncucCTw7FRfA6T2B/D0jEqe8xY+XDmeFft3mt20DEu7ZjuptNCXjqj+vzLlYt3P\n\tY7pyMi0hlkIunf8ZPwun5T5nNuvaoxJPFioDR/4u8tzK9YKTUCszXQ5mGt9DJDhCAQYMxotA4SS\n\tKlKG0MGkFZPrMRWLjRyp79yaNofW6O5FztVh6BzwHSUvOQF14Y1HvG//90W92Po5kjGB1/BkCtG\n\tAy0MMQ/lY1u5m4006dfj9N1ImJmfRIDShys3IdzeX8HzYeJck6T+J0MkxydzqqckaRG10gdCeSd\n\teTcKyGp6azeMdw814lDPTaPvr7SItYk0ZnlH0XBrv/ZqsA==","X-Google-Smtp-Source":"AGHT+IGIu2QaszK/rt641kBHhO4ewuacZJKaAwiN+iRDajCpPz8pHiaQbUrYfI5gsMLXpvWWU7Kzlg==","X-Received":"by 2002:a05:620a:2801:b0:7c5:50cc:51b3 with SMTP id\n\taf79cd13be357-7c956eda6d5mr411919285a.33.1745500671015; \n\tThu, 24 Apr 2025 06:17:51 -0700 (PDT)","Message-ID":"","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Nicolas Dufresne ","To":"Kieran Bingham , Bryan O'Donoghue\n\t, Laurent Pinchart\n\t","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com, \n\tmzamazal@redhat.com, bod.linux@nxsw.ie","Date":"Thu, 24 Apr 2025 09:17:48 -0400","In-Reply-To":"<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.56.1 (3.56.1-1.fc42) ","MIME-Version":"1.0","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34030,"web_url":"https://patchwork.libcamera.org/comment/34030/","msgid":"","date":"2025-04-24T13:51:42","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":175,"url":"https://patchwork.libcamera.org/api/people/175/","name":"Bryan O'Donoghue","email":"bryan.odonoghue@linaro.org"},"content":"On 24/04/2025 14:17, Nicolas Dufresne wrote:\n>> even if the CPU only 'reads' the data ?\n> Its any CPU write -> GPU that in serious trouble on recent Intel. That\n> being said, if nothing either flush or invalidate the cache, if you\n> read before, write with GPU, and read again after that same buffer, the\n> data you'll read may be from old cache. In practice, GPU don't do\n> anything in-place, so that is non-issue here.\n\nWell we have the GPU write to its own frame buffer and currently then \nget a GBM pointer to that surface and memcpy() out into the libcamera \nbuffer be that CMA or UDMABuf.\n\n+\tgbm_surface_lock_front_buffer(gbm_surface_);\n+\n+\tsync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n+\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n+\n+\tif (data_len > framesize_) {\n+\t\tLOG(GBM, Error) << \"Invalid read size \" << data_len << \" max is \" << \nframesize_;\n+\t\treturn -EINVAL;\n+\t}\n+\n+\tmemcpy(data, map_, data_len);\n+\n+\tsync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n+\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n+\n+\tgbm_surface_release_buffer(gbm_surface_, gbm_bo_);\n+\n\nThat I believe should be cache-coherent for both CMA and UDMAbuf across \narchitectures.\n\nWe had an interesting discussion on how render-to-texture would work - \nif you created the render texture using eglCreateImageKHR.\n\n// render to texture\n\ndmabuf_handle = handle to CMA or UDMABuf buffer.\n\nEGLint attrs[] = {\n\tEGL_DMA_BUF_PLANE0_FD_EXT, dmabuf_handle\n};\n\nmytexture-output = glCreateImageKHR(display, context,\n EGL_LINUX_DMA_BUF_EXT,\n NULL, attrs);\n\nglBindFramebuffer(GL_FRAMBUFFER, someframebuffer);\nglFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,\n GL_TEXTURE_2D, mytexture-output);\n\n\nif dmabuf_handle points to CMA heap - who is responsible to flush the \ncache before the CPU accessess the content of the DMA buf handle..\n\nactually as I type that, I think the answer is that it is always the \nresponsibility of the CPU side to manage its own cache so..\n\nglDraw();\n\nsync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\nioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n\nsync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\nioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n\nsomething like that ..\n\n>> For GPU ISP - the only access the CPU should do is read the data to\n>> generate some statistics. And even that - I would hope in the future\n>> will be turned into operations performed by the GPU ...\n> So read bayer, process in GPU, output YUV should just work. Thanks for\n> clarification, running out of CMA is pretty common, defaults CMA\n> reservation is usually very small. Appart from the buggy drivers,\n> virtual memory is a much better choice, and this is mostly what this\n> patch is about here.\nThinking about this patch.\n\nA user on a system such as imx/hantro is free to configure the system to \nsupport CMA and UDMABuf.\n\nIf you never pass that buffer to the video encoder - where the encoder \nrequires phys contig/cma heap memory - then you probably want udmabuf.\n\nThe reverse is also true.\n\nIts almost use-case specific. If you want the encoder you need CMA and \nif you just want to say - display the output in cheese you want UDMAbuf.\n\nProbably the right thing to do is to leave CMA heap as default and leave \nit to the system designer to configure the system as they wish.\n\nIn my case, switching off the CMA heap or perhaps a libcamera config/env \nvariable to specify which to use...\n\n---\nbod","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 03628C327D\n\tfor ;\n\tThu, 24 Apr 2025 13:51:46 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id BD8CA68AC7;\n\tThu, 24 Apr 2025 15:51:45 +0200 (CEST)","from mail-wm1-x336.google.com (mail-wm1-x336.google.com\n\t[IPv6:2a00:1450:4864:20::336])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4002B68AC5\n\tfor ;\n\tThu, 24 Apr 2025 15:51:44 +0200 (CEST)","by mail-wm1-x336.google.com with SMTP id\n\t5b1f17b1804b1-43cfe574976so7444285e9.1\n\tfor ;\n\tThu, 24 Apr 2025 06:51:44 -0700 (PDT)","from [192.168.0.35] (188-141-3-146.dynamic.upc.ie. [188.141.3.146])\n\tby smtp.gmail.com with ESMTPSA id\n\tffacd0b85a97d-3a06d4a8144sm2239651f8f.19.2025.04.24.06.51.42\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 24 Apr 2025 06:51:43 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"F5/BnKXk\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=linaro.org; s=google; t=1745502704; x=1746107504;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:in-reply-to:from:content-language\n\t:references:cc:to:subject:user-agent:mime-version:date:message-id\n\t:from:to:cc:subject:date:message-id:reply-to;\n\tbh=4QAYboL50TsK00K0gHqZ5NcE2oUEalhyeCJjs5b1H14=;\n\tb=F5/BnKXkadeavSb6nfgh90FG43BnsQ6c9Z5js66UVFOASgcQMEaCwoXQ7BwNjXtXHU\n\tqXE+Xt1ufDNkZX0xkKjfrEtuRrsEAM2cjVQeFpMQmM21ag6bd1JScUJbxzFv8IMxRTo0\n\ttvM53Nje8RZbmKH/tIhdu6tA1yvx0N1tTpvIt2l4GfO/nJKGMWX/a0N/dePSoHbCSPwR\n\tm61kp560zDrbcUIuQsSmrBBCBnUGmYiI1cKV3BVxX+z5rW/48HlIImeVl3Vr2TBSmamd\n\t/3SIEExfaS0cZkhrX7AW6fojSxdy8sd8xBGnjnkAumd26altmGs7aqBKtAAkxI+dvPNT\n\tvAfQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1745502704; x=1746107504;\n\th=content-transfer-encoding:in-reply-to:from:content-language\n\t:references:cc:to:subject:user-agent:mime-version:date:message-id\n\t:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n\tbh=4QAYboL50TsK00K0gHqZ5NcE2oUEalhyeCJjs5b1H14=;\n\tb=ttHcI1553SW/fjECjpaShoqhSqx+KsbblIYZEOC9WK2zIlj8szi+9yhjCvrPTP61B2\n\tbze5upg42HBSN4aBmybmweGEmhH0ttxxYrDd4iA7p4XshX1wLOoVaYwAI3TVwwZR6dyR\n\tNQ1HoioX0oeu/BI3swnrrFkiZoYI1NfmY1Db9PpwFgLa4aKOSSID3Yp8W5iSAbdvCyy2\n\tVakjynOsOXRR9mckEr4OT/5f93zhzhuBuzbgsEle8nQfmlg6fajPOx23cocRIpnX0Rx3\n\tTSTjmUlnJLZcnWxDDi5cwFRXH1b8RN5bVUvO/uY+RuaorGL5yysxfhzIsNF9cjqMZ9Xy\n\tsWfg==","X-Gm-Message-State":"AOJu0Yy+nh0M+VxnX3NsNCpkQCh+XNhR2UE93nxi5D4DUL2edcUVyV5h\n\t2TQSH3hjYU7FGC3Xebp1SmqT17il+8W11UqvPC5rUV7CNrXop28MxEyUykM6ELE=","X-Gm-Gg":"ASbGncsun9XG125ZJBNfNEgp9vC/pIdM2tJoUVQ7wNxaIvRYN4LhFooU+4XmO9D6gek\n\tKsr1gO9cML6tF+SfFH84YAdH0jhjLwNQNS3vtCngNZrCUiNvA+wlkJF5OWY/6t+nj0DLaLe9v0y\n\tanVRg8JYMR3hcRo7LePJKGFa01N0E6CLuMx9avWtT8Fe+EyYIuN0M7q8ugqYb7FntZSExTLYAJ1\n\t6NVTp/B3NiPP3FvajwtUCkZzLf+mJ84rDmPOWHcG3AKgi9iH5TvQZcm/aJNiWk1molcIkkTY94F\n\t6oMfoTHPJqwoTXSZtZxaCBQjnaruHdxvseOf25Bv23ejSMKMKTpEACvnKHeCUCU7LNyIRbUWS/G\n\tPHNIM/Q==","X-Google-Smtp-Source":"AGHT+IElq11nGZP4ddcf+sHZPMy9v92cVUJfB2G+4DXlwbI8UwoVWgIypEM2t+tg2PNZv8BzNMOqTA==","X-Received":"by 2002:a5d:47af:0:b0:3a0:6aca:88c5 with SMTP id\n\tffacd0b85a97d-3a06cf524f2mr2199948f8f.11.1745502703636; \n\tThu, 24 Apr 2025 06:51:43 -0700 (PDT)","Message-ID":"","Date":"Thu, 24 Apr 2025 14:51:42 +0100","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","To":"Nicolas Dufresne ,\n\tKieran Bingham ,\n\tBryan O'Donoghue ,\n\tLaurent Pinchart ","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t","Content-Language":"en-US","From":"Bryan O'Donoghue ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34045,"web_url":"https://patchwork.libcamera.org/comment/34045/","msgid":"<4d21e03c971ab29d4701031388f980890c67e780.camel@ndufresne.ca>","date":"2025-04-25T13:01:33","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le jeudi 24 avril 2025 à 17:14 +0300, Laurent Pinchart a écrit :\n> On Thu, Apr 24, 2025 at 02:51:42PM +0100, Bryan O'Donoghue wrote:\n> > On 24/04/2025 14:17, Nicolas Dufresne wrote:\n> > > > even if the CPU only 'reads' the data ?\n> > > Its any CPU write -> GPU that in serious trouble on recent Intel. That\n> > > being said, if nothing either flush or invalidate the cache, if you\n> > > read before, write with GPU, and read again after that same buffer, the\n> > > data you'll read may be from old cache. In practice, GPU don't do\n> > > anything in-place, so that is non-issue here.\n> > \n> > Well we have the GPU write to its own frame buffer and currently then \n> > get a GBM pointer to that surface and memcpy() out into the libcamera \n> > buffer be that CMA or UDMABuf.\n> > \n> > +\tgbm_surface_lock_front_buffer(gbm_surface_);\n> > +\n> > +\tsync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n> > +\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n> > +\n> > +\tif (data_len > framesize_) {\n> > +\t\tLOG(GBM, Error) << \"Invalid read size \" << data_len << \" max is \" << framesize_;\n> > +\t\treturn -EINVAL;\n> > +\t}\n> > +\n> > +\tmemcpy(data, map_, data_len);\n> > +\n> > +\tsync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n> > +\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n> > +\n> > +\tgbm_surface_release_buffer(gbm_surface_, gbm_bo_);\n> > +\n> > \n> > That I believe should be cache-coherent for both CMA and UDMAbuf across \n> > architectures.\n> > \n> > We had an interesting discussion on how render-to-texture would work - \n> > if you created the render texture using eglCreateImageKHR.\n> > \n> > // render to texture\n> > \n> > dmabuf_handle = handle to CMA or UDMABuf buffer.\n> > \n> > EGLint attrs[] = {\n> > \tEGL_DMA_BUF_PLANE0_FD_EXT, dmabuf_handle\n> > };\n> > \n> > mytexture-output = glCreateImageKHR(display, context,\n> >                                      EGL_LINUX_DMA_BUF_EXT,\n> >                                      NULL, attrs);\n> > \n> > glBindFramebuffer(GL_FRAMBUFFER, someframebuffer);\n> > glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,\n> >                         GL_TEXTURE_2D, mytexture-output);\n> > \n> > \n> > if dmabuf_handle points to CMA heap - who is responsible to flush the \n> > cache before the CPU accessess the content of the DMA buf handle..\n> > \n> > actually as I type that, I think the answer is that it is always the \n> > responsibility of the CPU side to manage its own cache so..\n> > \n> > glDraw();\n> > \n> > sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n> > ioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n> > \n> > sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n> > ioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n> > \n> > something like that ..\n> > \n> > > > For GPU ISP - the only access the CPU should do is read the data to\n> > > > generate some statistics. And even that - I would hope in the future\n> > > > will be turned into operations performed by the GPU ...\n> > > So read bayer, process in GPU, output YUV should just work. Thanks for\n> > > clarification, running out of CMA is pretty common, defaults CMA\n> > > reservation is usually very small. Appart from the buggy drivers,\n> > > virtual memory is a much better choice, and this is mostly what this\n> > > patch is about here.\n> > \n> > Thinking about this patch.\n> > \n> > A user on a system such as imx/hantro is free to configure the system to \n> > support CMA and UDMABuf.\n> > \n> > If you never pass that buffer to the video encoder - where the encoder \n> > requires phys contig/cma heap memory - then you probably want udmabuf.\n> \n> Add the display controller here, it's not just the video encoder.\n> \n> Have you tried displaying images with cam (using the -D flag) on a\n> system without an IOMMU, with this patch applied ? Does it still work ?\n\nIn this case glCreateImageKHR() is expected to fail once it discover\nthat the memory is scattered. In my experience, this part is well\nhandled. What's missing sometimes is verification that memory\nallocation have happened with CPU cached enabled. Without the mmu,\nthere is nothing to handle cached pages. Recent Intel graphics happily\nsucceed, resulting in a funny mess on screen.\n\nI assume the code here is just for example, and that there is failure\nand fallback in place.\n\n> \n> > The reverse is also true.\n> > \n> > Its almost use-case specific. If you want the encoder you need CMA and \n> > if you just want to say - display the output in cheese you want UDMAbuf.\n> > \n> > Probably the right thing to do is to leave CMA heap as default and leave \n> > it to the system designer to configure the system as they wish.\n> > \n> > In my case, switching off the CMA heap or perhaps a libcamera config/env \n> > variable to specify which to use...","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 74A69C327D\n\tfor ;\n\tFri, 25 Apr 2025 13:01:39 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8987968AD0;\n\tFri, 25 Apr 2025 15:01:38 +0200 (CEST)","from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com\n\t[IPv6:2607:f8b0:4864:20::f2b])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4AF4B617E4\n\tfor ;\n\tFri, 25 Apr 2025 15:01:36 +0200 (CEST)","by mail-qv1-xf2b.google.com with SMTP id\n\t6a1803df08f44-6e8fd49b85eso39771776d6.0\n\tfor ;\n\tFri, 25 Apr 2025 06:01:36 -0700 (PDT)","from ?IPv6:2606:6d00:15:9913::c41? ([2606:6d00:15:9913::c41])\n\tby smtp.gmail.com with ESMTPSA id\n\t6a1803df08f44-6f4c0aaf904sm21803726d6.101.2025.04.25.06.01.33\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tFri, 25 Apr 2025 06:01:34 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=ndufresne-ca.20230601.gappssmtp.com\n\theader.i=@ndufresne-ca.20230601.gappssmtp.com\n\theader.b=\"z/xSCAV5\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1745586095;\n\tx=1746190895; darn=lists.libcamera.org; \n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=97dE6qOpL/WiPE8FSAxS0UFLsgYOIiZPudtUKFdIMzE=;\n\tb=z/xSCAV5hnKRd8s0pbz3LYSGkjANYW4QJZs8+pwZsFS8XBbtWeD2T+dYouANJfUDTI\n\tk2gmZ3x7+jLNxKgb8JSW7glg38WZecK6C1SmlIk4q0Alfifvp/SPcZtQ48TKGH9hWRV3\n\tyb9g5XjWQO5EkqWgkLppppDw9/43eDv9MScKBYPIQibcz6idGiV9uQiOFNJzfG0omBIC\n\t6maT+njDLhYaUSKKv+VOgFn7eoSYhpSwJoGOpmuISmrr4CrQ3Q64FYQ4g521ffnM32ZE\n\t8gHHnALHi6V/MRPvfU9Iwm2EWLM0o0hxVtO2hPJGZnFNp24IxYqGsEsf6qEyFtKlo0xI\n\tmaJw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1745586095; x=1746190895;\n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state\n\t:from:to:cc:subject:date:message-id:reply-to;\n\tbh=97dE6qOpL/WiPE8FSAxS0UFLsgYOIiZPudtUKFdIMzE=;\n\tb=o+njunf86J1koeJp4L3Pk8ILmYWa2UM9OneEQSg0aHdeI0+ONA0E+p7W3QNNHOm6wf\n\tPHSQwyCEn6GqUikciSgFjF57Zdi/95bixDk0SpIJwxkA1TBzfFUCV//9227pvY8+HH6U\n\tngo0twPuU25alKhs1N3ob2fHYB5gwoQKUVea69D/g9nXqhxW9CReE/ygqSuXm7OmnKX9\n\tIBVJeS2ksVmJ9Vqcywr2BBKNsJO0xeUdDpcH4bq48JjRZZdU7wiZ5nJWTq41DAHHcTbl\n\tMm7D2v6akzKU+ZhiYHHRUF+Jsj+m/SuZVmAxnSjL64/0rdLfjmdUl0wJqADduq4jKsh6\n\tfIwg==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCUtE2RusZZI2oEVi0w4O+DqMiaovxRUODy84+o8HDVDEIcMEc0t/X0Wvm+uajKAZ1mnKkq9J2Zz8flJpov6mFI=@lists.libcamera.org","X-Gm-Message-State":"AOJu0YxCU3SnPxHJ8h5DOk1fClw48AcEeedOJzPnmC6pcvp8n+9k9RD/\n\tcYcow2Se5PLeXXSV4jq8MXPNgdzp4Gm9Rr1dG4Rv7hqSBJKk/TkcUARM4kYBcQI=","X-Gm-Gg":"ASbGnctpiMMVDdW+oGUn5u3T5ufOu7xV05tAB3Rbu7wE7NHxFN+Y3B5riZwbfYFlYGe\n\tdZZGnmV1DDPOqHxgb3kO7Hp6Vvgt4qGHJF1KI4jMw7dig3S27/zRcjupRO4hXp5+Oz22fJOOANj\n\tIXF584yQPrL92D6nDBkTNRGN5gqavYG5B6EoQ+Ny9pBVsR3hWwEDCIPyQ9nQ7VEg1j0JyKf/H9V\n\t9BCuTb5U1F8Sgtv0N8NhgkIXaC9Ev52fT/zknpWqsu3nLE8aXVZyGuHqBFXk11b3OTN+GcUjWkz\n\tlzbKlsbz1HH775H5Ga8+6LB4oI22Jl1qtQ8igue+SFwYWg==","X-Google-Smtp-Source":"AGHT+IFg5fUr70vhM2ygibOyN7W3k0Gqkdx+druRG9s5x4634vcleTaJ/aDXmcU6t5617xjwxg/pIw==","X-Received":"by 2002:a05:6214:2689:b0:6ea:d40e:2bc5 with SMTP id\n\t6a1803df08f44-6f4cb9ae468mr35434566d6.9.1745586094884; \n\tFri, 25 Apr 2025 06:01:34 -0700 (PDT)","Message-ID":"<4d21e03c971ab29d4701031388f980890c67e780.camel@ndufresne.ca>","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Nicolas Dufresne ","To":"Laurent Pinchart , Bryan O'Donoghue\n\t","Cc":"Kieran Bingham , \n\tlibcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com","Date":"Fri, 25 Apr 2025 09:01:33 -0400","In-Reply-To":"<20250424141454.GG18085@pendragon.ideasonboard.com>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t\n\t\n\t<20250424141454.GG18085@pendragon.ideasonboard.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.56.1 (3.56.1-1.fc42) ","MIME-Version":"1.0","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34046,"web_url":"https://patchwork.libcamera.org/comment/34046/","msgid":"<646f8b8f5139dc6678bbd9825a742b13c656e053.camel@ndufresne.ca>","date":"2025-04-25T13:07:46","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le jeudi 24 avril 2025 à 14:51 +0100, Bryan O'Donoghue a écrit :\n> Thinking about this patch.\n> \n> A user on a system such as imx/hantro is free to configure the system to \n> support CMA and UDMABuf.\n> \n> If you never pass that buffer to the video encoder - where the encoder \n> requires phys contig/cma heap memory - then you probably want udmabuf.\n> \n> The reverse is also true.\n> \n> Its almost use-case specific. If you want the encoder you need CMA and \n> if you just want to say - display the output in cheese you want UDMAbuf.\n\nThat is hardware specific. There is some encoders with an iommu that\ncan emit page fault on CPU cached pages, and so can handle UDMABuf\nfully in hardware. i.MX8 series, not so much.\n\n> \n> Probably the right thing to do is to leave CMA heap as default and leave \n> it to the system designer to configure the system as they wish.\n> \n> In my case, switching off the CMA heap or perhaps a libcamera config/env \n> variable to specify which to use...\n\nAs we target \"Desktop like\" with the software ISP, there is no system\ndesigner in that process. Unless you consider the user to be as such.\nThat being said, you can quirk it based on which CSI receiver brand in\nuse if you don't want to try one and cascade to the other if one fails.\n\nNicolas","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A5883BE08B\n\tfor ;\n\tFri, 25 Apr 2025 13:07:52 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 5582768ACD;\n\tFri, 25 Apr 2025 15:07:51 +0200 (CEST)","from mail-qt1-x832.google.com (mail-qt1-x832.google.com\n\t[IPv6:2607:f8b0:4864:20::832])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 0949C617E4\n\tfor ;\n\tFri, 25 Apr 2025 15:07:49 +0200 (CEST)","by mail-qt1-x832.google.com with SMTP id\n\td75a77b69052e-4769b16d4fbso14383281cf.2\n\tfor ;\n\tFri, 25 Apr 2025 06:07:48 -0700 (PDT)","from ?IPv6:2606:6d00:15:9913::c41? ([2606:6d00:15:9913::c41])\n\tby smtp.gmail.com with ESMTPSA id\n\td75a77b69052e-47ea1693378sm25261861cf.64.2025.04.25.06.07.46\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tFri, 25 Apr 2025 06:07:47 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=ndufresne-ca.20230601.gappssmtp.com\n\theader.i=@ndufresne-ca.20230601.gappssmtp.com\n\theader.b=\"n983frp8\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1745586468;\n\tx=1746191268; darn=lists.libcamera.org; \n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=INaJ0RPagI+PCP4KZVTlqL0g8/jdFHL7OmgjHgRvy98=;\n\tb=n983frp828N9ak9R9rwrUtjQ4WWLEofOFyvVeuvDQup8/dq69ubYlBS+Zn7s3vTvow\n\t3jqg8QNqDWqXL5wOxIoQMYdBSpc6q6CvMDUCNFdzPy8HvTnEKmO48QSMPznYP9cQDa9y\n\tfsfcVC+szQv1O7BwAntVpLpwhZwUflZCRiMcAIBzq7MXfydLmoMz5FkC0et+U/n0Vf4P\n\tq+8xnZ9DIkTRWv2gXl/aE5C6dRc9Wl0ly0192vIkwu1EpJHSU4POy1MGlOouw1gd0QhP\n\th30v72PB6YY+ILT84X8UbLoovNTA+B91JTIQHNbhR5dFpBX0DIviqoyEcS+1SqPRQ1ce\n\tAOqw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1745586468; x=1746191268;\n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state\n\t:from:to:cc:subject:date:message-id:reply-to;\n\tbh=INaJ0RPagI+PCP4KZVTlqL0g8/jdFHL7OmgjHgRvy98=;\n\tb=NZU/ioHH6TqEDmLObnCQo6JNj+cyVUXhatGGjuu5KF/Lx92bsHNfpa4T0nvQzNwCSD\n\t94FZ6GtvB52Rhe0EIfoFILnrmh6VjbFGnsO/zokwCAE9hyI5NQGyeU6FH39dCKk4K1q9\n\t3XcRoB31uIOWci/YRW6CShOlrHns2ymCkCpmR4bEafBeCwdGYv9bKIgDc5/Qn7I8t1+I\n\tgj3anIXcL3pbmE/9/Qi7nXpndptBIQ0VhJVXHEte+PrZt2eEqO8cVjiYhtWM2s/enhYy\n\t/ZWN04MmMHVLqdZ08R73IsuJIEN0YrZoVDJ3RMv7tuE2ZF0TfpqY0YaWALqHVVe7ljJP\n\taFsQ==","X-Gm-Message-State":"AOJu0Yxxkh0qEevZi2u2vdMapsTqZl6SN3QP6KXMhwf6rJZm/O44wXn1\n\t6vX0nFWuqPha/WE1wDvYckAN7B/uHutG+Tc1XnXIpFzCYV0muaKnxcERqJmdPcY=","X-Gm-Gg":"ASbGncslqIh83Hy+27zua68//cOi0T2W/RWw53detXsAqcAdz4y4Yo/7JYzSuxVzg5P\n\tVb9cURkeknUvSWrCurCUV2mUlEU3P64BwJ+7KDJgioze64/RFrNVD0ZLanLpU7ALuPNHK3rjmC7\n\tQdk41btGqp/ZX4M2nvHfpHwUND0xjfsuIF/yC8ta4Dik7wxIer9BZP+rmDoTyE5Q8dfsY8Z/dAj\n\t4AcOwW+t2U3mZoSp7OMLMfjnOAEua4k9upSOqb33ORkglaK/b/FK9k3iZFrOIxvYV5gt+rHUhRR\n\te1cO8lExXVSacii1Elz/as6gwqaBUS0fQHKuF2FPa8n/xw==","X-Google-Smtp-Source":"AGHT+IEYMlLkz1tbnDM5+osBnfjCoUpbid8Ce6GUOCucpJ9rvDmBO1Mju69OO2y/efc7taWKyzuBqQ==","X-Received":"by 2002:ac8:5a85:0:b0:47b:3a2:ff14 with SMTP id\n\td75a77b69052e-4801ce540a2mr30484471cf.25.1745586467675; \n\tFri, 25 Apr 2025 06:07:47 -0700 (PDT)","Message-ID":"<646f8b8f5139dc6678bbd9825a742b13c656e053.camel@ndufresne.ca>","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Nicolas Dufresne ","To":"Bryan O'Donoghue , Kieran Bingham\n\t, Laurent Pinchart\n\t","Cc":"libcamera-devel@lists.libcamera.org, hdegoede@redhat.com, \n\tmzamazal@redhat.com","Date":"Fri, 25 Apr 2025 09:07:46 -0400","In-Reply-To":"","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t\n\t","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.56.1 (3.56.1-1.fc42) ","MIME-Version":"1.0","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34047,"web_url":"https://patchwork.libcamera.org/comment/34047/","msgid":"<20250425143711.GE24730@pendragon.ideasonboard.com>","date":"2025-04-25T14:37:11","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Fri, Apr 25, 2025 at 09:07:46AM -0400, Nicolas Dufresne wrote:\n> Le jeudi 24 avril 2025 à 14:51 +0100, Bryan O'Donoghue a écrit :\n> > Thinking about this patch.\n> > \n> > A user on a system such as imx/hantro is free to configure the system to \n> > support CMA and UDMABuf.\n> > \n> > If you never pass that buffer to the video encoder - where the encoder \n> > requires phys contig/cma heap memory - then you probably want udmabuf.\n> > \n> > The reverse is also true.\n> > \n> > Its almost use-case specific. If you want the encoder you need CMA and \n> > if you just want to say - display the output in cheese you want UDMAbuf.\n> \n> That is hardware specific. There is some encoders with an iommu that\n> can emit page fault on CPU cached pages, and so can handle UDMABuf\n> fully in hardware. i.MX8 series, not so much.\n\nIs that on IOMMU that can clean dirty cache entries (with support from\nthe OS, through a fault) ? I wasn't aware of such hardware. It's\ninteresting (at least in theory, I wonder what performance you can get\nout of that). Is there any example you can give ?\n\n> > Probably the right thing to do is to leave CMA heap as default and leave \n> > it to the system designer to configure the system as they wish.\n> > \n> > In my case, switching off the CMA heap or perhaps a libcamera config/env \n> > variable to specify which to use...\n> \n> As we target \"Desktop like\" with the software ISP, there is no system\n> designer in that process. Unless you consider the user to be as such.\n> That being said, you can quirk it based on which CSI receiver brand in\n> use if you don't want to try one and cascade to the other if one fails.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id D0AA3C327D\n\tfor ;\n\tFri, 25 Apr 2025 14:37:17 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C0668617E5;\n\tFri, 25 Apr 2025 16:37:16 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 39E8E617E4\n\tfor ;\n\tFri, 25 Apr 2025 16:37:15 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 9535182E;\n\tFri, 25 Apr 2025 16:37:11 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"AOl8BxVe\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1745591831;\n\tbh=On3fw2cjVpMIO0AGa20JVTLWSDNhBSYmvxPEZ+I9r8c=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=AOl8BxVexeCGqalnOTVIhfWb8L1h85mKravPZ3rMCv8vE9YMWXyP9WnZITrKotUsY\n\tlB+yiU2Qiq/SN0H8tVoqLLfgTvUJBg9fzMhKUfs9Lb8sn5Gt2I1QvV/1AwOGN8eoHs\n\t6AuGWpBURuclCsYSxxsgAQNO9kVtFtjtSgiL/jb8=","Date":"Fri, 25 Apr 2025 17:37:11 +0300","From":"Laurent Pinchart ","To":"Nicolas Dufresne ","Cc":"Bryan O'Donoghue ,\n\tKieran Bingham ,\n\tlibcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","Message-ID":"<20250425143711.GE24730@pendragon.ideasonboard.com>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t\n\t\n\t<646f8b8f5139dc6678bbd9825a742b13c656e053.camel@ndufresne.ca>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<646f8b8f5139dc6678bbd9825a742b13c656e053.camel@ndufresne.ca>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34050,"web_url":"https://patchwork.libcamera.org/comment/34050/","msgid":"<20250425150701.GA26250@pendragon.ideasonboard.com>","date":"2025-04-25T15:07:01","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Fri, Apr 25, 2025 at 09:01:33AM -0400, Nicolas Dufresne wrote:\n> Le jeudi 24 avril 2025 à 17:14 +0300, Laurent Pinchart a écrit :\n> > On Thu, Apr 24, 2025 at 02:51:42PM +0100, Bryan O'Donoghue wrote:\n> > > On 24/04/2025 14:17, Nicolas Dufresne wrote:\n> > > > > even if the CPU only 'reads' the data ?\n> > > > Its any CPU write -> GPU that in serious trouble on recent Intel. That\n> > > > being said, if nothing either flush or invalidate the cache, if you\n> > > > read before, write with GPU, and read again after that same buffer, the\n> > > > data you'll read may be from old cache. In practice, GPU don't do\n> > > > anything in-place, so that is non-issue here.\n> > > \n> > > Well we have the GPU write to its own frame buffer and currently then \n> > > get a GBM pointer to that surface and memcpy() out into the libcamera \n> > > buffer be that CMA or UDMABuf.\n> > > \n> > > +\tgbm_surface_lock_front_buffer(gbm_surface_);\n> > > +\n> > > +\tsync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n> > > +\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n> > > +\n> > > +\tif (data_len > framesize_) {\n> > > +\t\tLOG(GBM, Error) << \"Invalid read size \" << data_len << \" max is \" << framesize_;\n> > > +\t\treturn -EINVAL;\n> > > +\t}\n> > > +\n> > > +\tmemcpy(data, map_, data_len);\n> > > +\n> > > +\tsync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n> > > +\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n> > > +\n> > > +\tgbm_surface_release_buffer(gbm_surface_, gbm_bo_);\n> > > +\n> > > \n> > > That I believe should be cache-coherent for both CMA and UDMAbuf across \n> > > architectures.\n> > > \n> > > We had an interesting discussion on how render-to-texture would work - \n> > > if you created the render texture using eglCreateImageKHR.\n> > > \n> > > // render to texture\n> > > \n> > > dmabuf_handle = handle to CMA or UDMABuf buffer.\n> > > \n> > > EGLint attrs[] = {\n> > > \tEGL_DMA_BUF_PLANE0_FD_EXT, dmabuf_handle\n> > > };\n> > > \n> > > mytexture-output = glCreateImageKHR(display, context,\n> > >                                      EGL_LINUX_DMA_BUF_EXT,\n> > >                                      NULL, attrs);\n> > > \n> > > glBindFramebuffer(GL_FRAMBUFFER, someframebuffer);\n> > > glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,\n> > >                         GL_TEXTURE_2D, mytexture-output);\n> > > \n> > > \n> > > if dmabuf_handle points to CMA heap - who is responsible to flush the \n> > > cache before the CPU accessess the content of the DMA buf handle..\n> > > \n> > > actually as I type that, I think the answer is that it is always the \n> > > responsibility of the CPU side to manage its own cache so..\n> > > \n> > > glDraw();\n> > > \n> > > sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n> > > ioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n> > > \n> > > sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n> > > ioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n> > > \n> > > something like that ..\n> > > \n> > > > > For GPU ISP - the only access the CPU should do is read the data to\n> > > > > generate some statistics. And even that - I would hope in the future\n> > > > > will be turned into operations performed by the GPU ...\n> > > > So read bayer, process in GPU, output YUV should just work. Thanks for\n> > > > clarification, running out of CMA is pretty common, defaults CMA\n> > > > reservation is usually very small. Appart from the buggy drivers,\n> > > > virtual memory is a much better choice, and this is mostly what this\n> > > > patch is about here.\n> > > \n> > > Thinking about this patch.\n> > > \n> > > A user on a system such as imx/hantro is free to configure the system to \n> > > support CMA and UDMABuf.\n> > > \n> > > If you never pass that buffer to the video encoder - where the encoder \n> > > requires phys contig/cma heap memory - then you probably want udmabuf.\n> > \n> > Add the display controller here, it's not just the video encoder.\n> > \n> > Have you tried displaying images with cam (using the -D flag) on a\n> > system without an IOMMU, with this patch applied ? Does it still work ?\n> \n> In this case glCreateImageKHR() is expected to fail once it discover\n> that the memory is scattered. In my experience, this part is well\n> handled.\n\nIt will only fail if the GPU has no IOMMU, right ? What if the GPU has\nan IOMMU, but the display controller doesn't ?\n\n> What's missing sometimes is verification that memory\n> allocation have happened with CPU cached enabled. Without the mmu,\n> there is nothing to handle cached pages. Recent Intel graphics happily\n> succeed, resulting in a funny mess on screen.\n> \n> I assume the code here is just for example, and that there is failure\n> and fallback in place.\n> \n> > > The reverse is also true.\n> > > \n> > > Its almost use-case specific. If you want the encoder you need CMA and \n> > > if you just want to say - display the output in cheese you want UDMAbuf.\n> > > \n> > > Probably the right thing to do is to leave CMA heap as default and leave \n> > > it to the system designer to configure the system as they wish.\n> > > \n> > > In my case, switching off the CMA heap or perhaps a libcamera config/env \n> > > variable to specify which to use...","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 07AB6C327D\n\tfor ;\n\tFri, 25 Apr 2025 15:07:09 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 138DD617E5;\n\tFri, 25 Apr 2025 17:07:08 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A92DA617E4\n\tfor ;\n\tFri, 25 Apr 2025 17:07:05 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 746E4605;\n\tFri, 25 Apr 2025 17:07:02 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"XO4pL2q6\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1745593622;\n\tbh=VDtC/6KGvjeVM9v4KGAd7avIUbkL0/0/+kbBhXwRHEQ=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=XO4pL2q6aFSi2JzhV0siPGzF0pCMgoChVvvrSWfXh6Mlcwf0ZvLmPg4t7UQwRWlJO\n\taSIGAz4TKfd62TJroT/YOPVHybtzsPRbvkcnnptCgUBO1bYwLjIcI96DSdJx0jYjMD\n\tGg+bbEDsF+wMrh8vgcsDKm5ZPOKZ4MQHbkd7pGI4=","Date":"Fri, 25 Apr 2025 18:07:01 +0300","From":"Laurent Pinchart ","To":"Nicolas Dufresne ","Cc":"Bryan O'Donoghue ,\n\tKieran Bingham ,\n\tlibcamera-devel@lists.libcamera.org, hdegoede@redhat.com,\n\tmzamazal@redhat.com","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","Message-ID":"<20250425150701.GA26250@pendragon.ideasonboard.com>","References":"<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t\n\t\n\t<20250424141454.GG18085@pendragon.ideasonboard.com>\n\t<4d21e03c971ab29d4701031388f980890c67e780.camel@ndufresne.ca>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<4d21e03c971ab29d4701031388f980890c67e780.camel@ndufresne.ca>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34053,"web_url":"https://patchwork.libcamera.org/comment/34053/","msgid":"<9009624c-b3b1-42ed-a5f5-31e94d49847a@collabora.com>","date":"2025-04-25T15:40:19","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":140,"url":"https://patchwork.libcamera.org/api/people/140/","name":"Robert Mader","email":"robert.mader@collabora.com"},"content":"On 25.04.25 17:07, Laurent Pinchart wrote:\n> On Fri, Apr 25, 2025 at 09:01:33AM -0400, Nicolas Dufresne wrote:\n>> Le jeudi 24 avril 2025 à 17:14 +0300, Laurent Pinchart a écrit :\n>>> On Thu, Apr 24, 2025 at 02:51:42PM +0100, Bryan O'Donoghue wrote:\n>>>> On 24/04/2025 14:17, Nicolas Dufresne wrote:\n>>>>>> even if the CPU only 'reads' the data ?\n>>>>> Its any CPU write -> GPU that in serious trouble on recent Intel. That\n>>>>> being said, if nothing either flush or invalidate the cache, if you\n>>>>> read before, write with GPU, and read again after that same buffer, the\n>>>>> data you'll read may be from old cache. In practice, GPU don't do\n>>>>> anything in-place, so that is non-issue here.\n>>>> Well we have the GPU write to its own frame buffer and currently then\n>>>> get a GBM pointer to that surface and memcpy() out into the libcamera\n>>>> buffer be that CMA or UDMABuf.\n>>>>\n>>>> +\tgbm_surface_lock_front_buffer(gbm_surface_);\n>>>> +\n>>>> +\tsync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n>>>> +\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n>>>> +\n>>>> +\tif (data_len > framesize_) {\n>>>> +\t\tLOG(GBM, Error) << \"Invalid read size \" << data_len << \" max is \" << framesize_;\n>>>> +\t\treturn -EINVAL;\n>>>> +\t}\n>>>> +\n>>>> +\tmemcpy(data, map_, data_len);\n>>>> +\n>>>> +\tsync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n>>>> +\tioctl(bo_fd_, DMA_BUF_IOCTL_SYNC, &sync);\n>>>> +\n>>>> +\tgbm_surface_release_buffer(gbm_surface_, gbm_bo_);\n>>>> +\n>>>>\n>>>> That I believe should be cache-coherent for both CMA and UDMAbuf across\n>>>> architectures.\n>>>>\n>>>> We had an interesting discussion on how render-to-texture would work -\n>>>> if you created the render texture using eglCreateImageKHR.\n>>>>\n>>>> // render to texture\n>>>>\n>>>> dmabuf_handle = handle to CMA or UDMABuf buffer.\n>>>>\n>>>> EGLint attrs[] = {\n>>>> \tEGL_DMA_BUF_PLANE0_FD_EXT, dmabuf_handle\n>>>> };\n>>>>\n>>>> mytexture-output = glCreateImageKHR(display, context,\n>>>>                                      EGL_LINUX_DMA_BUF_EXT,\n>>>>                                      NULL, attrs);\n>>>>\n>>>> glBindFramebuffer(GL_FRAMBUFFER, someframebuffer);\n>>>> glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,\n>>>>                         GL_TEXTURE_2D, mytexture-output);\n>>>>\n>>>>\n>>>> if dmabuf_handle points to CMA heap - who is responsible to flush the\n>>>> cache before the CPU accessess the content of the DMA buf handle..\n>>>>\n>>>> actually as I type that, I think the answer is that it is always the\n>>>> responsibility of the CPU side to manage its own cache so..\n>>>>\n>>>> glDraw();\n>>>>\n>>>> sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ;\n>>>> ioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n>>>>\n>>>> sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ;\n>>>> ioctl(dmabuf_handle, DMA_BUF_IOCTL_SYNC, &sync);\n>>>>\n>>>> something like that ..\n>>>>\n>>>>>> For GPU ISP - the only access the CPU should do is read the data to\n>>>>>> generate some statistics. And even that - I would hope in the future\n>>>>>> will be turned into operations performed by the GPU ...\n>>>>> So read bayer, process in GPU, output YUV should just work. Thanks for\n>>>>> clarification, running out of CMA is pretty common, defaults CMA\n>>>>> reservation is usually very small. Appart from the buggy drivers,\n>>>>> virtual memory is a much better choice, and this is mostly what this\n>>>>> patch is about here.\n>>>> Thinking about this patch.\n>>>>\n>>>> A user on a system such as imx/hantro is free to configure the system to\n>>>> support CMA and UDMABuf.\n>>>>\n>>>> If you never pass that buffer to the video encoder - where the encoder\n>>>> requires phys contig/cma heap memory - then you probably want udmabuf.\n>>> Add the display controller here, it's not just the video encoder.\n>>>\n>>> Have you tried displaying images with cam (using the -D flag) on a\n>>> system without an IOMMU, with this patch applied ? Does it still work ?\n>> In this case glCreateImageKHR() is expected to fail once it discover\n>> that the memory is scattered. In my experience, this part is well\n>> handled.\n> It will only fail if the GPU has no IOMMU, right ? What if the GPU has\n> an IOMMU, but the display controller doesn't ?\n\nThis would be the RPi4 case (on the RPi5 the DC has an IOMMU). I've been \ntesting this quite a bit in the context of \nhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8540 \n- using udmabuf with software video decoders in order to reuse dmabuf \nfastpaths and avoid copies.\n\nThe DC in question supports DRM_FORMAT_YUV420, which is the native \nformat used by most SW decoders (dav1d, ffpmeg, vpx, openh264, ...) for \n8-bit 420 content. So far the case has been handled perfectly as \nexpected - import to GPU (including in Wayland compositors) works but \nKMS offloading fails in the test commit on the RPi4, while succeeding on \nRPi5.\n\nI've also tested several other devices and have yet to hit a case where \nthings blow up because some component requiring CMA tries to import an \nudmabuf. The concern that it could happen has been rased by RPi devs as \nwell though \n(https://github.com/raspberrypi/linux/issues/6706#issuecomment-2706283848).\n\n---\n\nEither way, do we agree that the commit in question should have its own \nseries for further discussion as it's only semi-related to the gpuISP?\n\n>> What's missing sometimes is verification that memory\n>> allocation have happened with CPU cached enabled. Without the mmu,\n>> there is nothing to handle cached pages. Recent Intel graphics happily\n>> succeed, resulting in a funny mess on screen.\n>>\n>> I assume the code here is just for example, and that there is failure\n>> and fallback in place.\n>>\n>>>> The reverse is also true.\n>>>>\n>>>> Its almost use-case specific. If you want the encoder you need CMA and\n>>>> if you just want to say - display the output in cheese you want UDMAbuf.\n>>>>\n>>>> Probably the right thing to do is to leave CMA heap as default and leave\n>>>> it to the system designer to configure the system as they wish.\n>>>>\n>>>> In my case, switching off the CMA heap or perhaps a libcamera config/env\n>>>> variable to specify which to use...","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 3E26ABE08B\n\tfor ;\n\tFri, 25 Apr 2025 15:40:30 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4E64268ACD;\n\tFri, 25 Apr 2025 17:40:29 +0200 (CEST)","from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com\n\t[136.143.188.12])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4ACFD617E4\n\tfor ;\n\tFri, 25 Apr 2025 17:40:27 +0200 (CEST)","by mx.zohomail.com with SMTPS id 17455956224741006.0934828467803; \n\tFri, 25 Apr 2025 08:40:22 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=collabora.com\n\theader.i=robert.mader@collabora.com header.b=\"N3ge+qQw\"; \n\tdkim-atps=neutral","ARC-Seal":"i=1; a=rsa-sha256; t=1745595624; cv=none; \n\td=zohomail.com; s=zohoarc; \n\tb=EI+qN7TViRFGJJLdO4EHMqQ0mZberPNTdfFmZyGauwNAMw/LmKMkITTELYYxjVxZloW3bAm7MZDCDBBtH4T+TeCzljEl8EgOPwAMe7Mf118kz0qH33nM65+vrOoG9qGvLSvqcStRmRbcZLweeHmZBxoNyYbMMp0+qJDjQ0S9UBg=","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; \n\ts=zohoarc; t=1745595624;\n\th=Content-Type:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc;\n\tbh=yYZ+BqOy2QfvnZEYTNq52GVUYlhY7szUZX0xPY2BRqE=; \n\tb=lE44P+p1SQe+Dm/tCZF5rZAlSBMaJF6O/Vgg4v95kf31xK524iQhg9NuLU04khIgBGTHinn+giYIe5h7PPbeue4yQNQCCKmxQK6bJ5N07MYslGgScjg1TFy/Oe9C0WUgrSurpdNyjUqPBRYs6dzDuI6o+L1c5kbZDEettTUvzMw=","ARC-Authentication-Results":"i=1; mx.zohomail.com;\n\tdkim=pass header.i=collabora.com;\n\tspf=pass smtp.mailfrom=robert.mader@collabora.com;\n\tdmarc=pass header.from=","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1745595624;\n\ts=zohomail; d=collabora.com; i=robert.mader@collabora.com;\n\th=Content-Type:Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Message-Id:Reply-To:Cc;\n\tbh=yYZ+BqOy2QfvnZEYTNq52GVUYlhY7szUZX0xPY2BRqE=;\n\tb=N3ge+qQwwg4PzuTBaErjMx/guKbqPE47Fj0vx+SVsGIjxVZ2Uxb70W1zgdErzrfk\n\t7uCVoW3QvD2/wE8cBEKbsPV/qWD+Cc4MR3uC5jVz8iRTeoObSTnDYhnpc/5qk7vytbb\n\tVVk1kBMMNdrQ83Vw71fqwW+JgM7Ja1hV9WZsgCFg=","Content-Type":"multipart/alternative;\n\tboundary=\"------------UyJJdnDns13EoNUPEiG0f0kW\"","Message-ID":"<9009624c-b3b1-42ed-a5f5-31e94d49847a@collabora.com>","Date":"Fri, 25 Apr 2025 17:40:19 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","To":"libcamera-devel@lists.libcamera.org","References":"<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t\n\t\n\t<20250424141454.GG18085@pendragon.ideasonboard.com>\n\t<4d21e03c971ab29d4701031388f980890c67e780.camel@ndufresne.ca>\n\t<20250425150701.GA26250@pendragon.ideasonboard.com>","Content-Language":"en-US, de-DE, en-GB","From":"Robert Mader ","In-Reply-To":"<20250425150701.GA26250@pendragon.ideasonboard.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34054,"web_url":"https://patchwork.libcamera.org/comment/34054/","msgid":"","date":"2025-04-25T19:16:40","subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le vendredi 25 avril 2025 à 17:37 +0300, Laurent Pinchart a écrit :\n> On Fri, Apr 25, 2025 at 09:07:46AM -0400, Nicolas Dufresne wrote:\n> > Le jeudi 24 avril 2025 à 14:51 +0100, Bryan O'Donoghue a écrit :\n> > > Thinking about this patch.\n> > > \n> > > A user on a system such as imx/hantro is free to configure the system to \n> > > support CMA and UDMABuf.\n> > > \n> > > If you never pass that buffer to the video encoder - where the encoder \n> > > requires phys contig/cma heap memory - then you probably want udmabuf.\n> > > \n> > > The reverse is also true.\n> > > \n> > > Its almost use-case specific. If you want the encoder you need CMA and \n> > > if you just want to say - display the output in cheese you want UDMAbuf.\n> > \n> > That is hardware specific. There is some encoders with an iommu that\n> > can emit page fault on CPU cached pages, and so can handle UDMABuf\n> > fully in hardware. i.MX8 series, not so much.\n> \n> Is that on IOMMU that can clean dirty cache entries (with support from\n> the OS, through a fault) ? I wasn't aware of such hardware. It's\n> interesting (at least in theory, I wonder what performance you can get\n> out of that). Is there any example you can give ?\n\nIf its a page fault, its not fully HW right ? That is my understanding,\nhopefully not too off though. In short, this works with integrated GPU\nencoders. The performance would be atrocious if it was simply flushing\nahead time.\n\n> \n> > > Probably the right thing to do is to leave CMA heap as default and leave \n> > > it to the system designer to configure the system as they wish.\n> > > \n> > > In my case, switching off the CMA heap or perhaps a libcamera config/env \n> > > variable to specify which to use...\n> > \n> > As we target \"Desktop like\" with the software ISP, there is no system\n> > designer in that process. Unless you consider the user to be as such.\n> > That being said, you can quirk it based on which CSI receiver brand in\n> > use if you don't want to try one and cascade to the other if one fails.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 736DEC327D\n\tfor ;\n\tFri, 25 Apr 2025 19:16:45 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8142E68ACD;\n\tFri, 25 Apr 2025 21:16:44 +0200 (CEST)","from mail-qt1-x832.google.com (mail-qt1-x832.google.com\n\t[IPv6:2607:f8b0:4864:20::832])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id CCDC5617E4\n\tfor ;\n\tFri, 25 Apr 2025 21:16:42 +0200 (CEST)","by mail-qt1-x832.google.com with SMTP id\n\td75a77b69052e-476a304a8edso32309951cf.3\n\tfor ;\n\tFri, 25 Apr 2025 12:16:42 -0700 (PDT)","from ?IPv6:2606:6d00:15:9913::c41? ([2606:6d00:15:9913::c41])\n\tby smtp.gmail.com with ESMTPSA id\n\td75a77b69052e-47ea16932a8sm28684621cf.58.2025.04.25.12.16.40\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tFri, 25 Apr 2025 12:16:41 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=ndufresne-ca.20230601.gappssmtp.com\n\theader.i=@ndufresne-ca.20230601.gappssmtp.com\n\theader.b=\"p4ZWLM3S\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1745608601;\n\tx=1746213401; darn=lists.libcamera.org; \n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n\t:date:message-id:reply-to;\n\tbh=CK6qshR8RFRa/7VHX10utHLHaY2KM1R+Z1gizg1G5IE=;\n\tb=p4ZWLM3Sg8LvxN+7SX9f9rYcs0VlZgZiXwlkefV4erjYjVAVtE0V9OJ3ao4Oj4NNO7\n\tPCMWLLEztQZ101GRzNFJ58d7F48PtxCfnuBAtSCsIKQcvR8QxPUQ61sNoIgHleyh0KiW\n\tt1vpyP+gN3Z2zBbGVjw40jB8G9wzpMjhgelhZWPdu8kJ/xTbGwuCH2Vfw9Aw7gi8S+sz\n\tz6qFDzpSscRFDGIiN3p/JVx7sbSJZv1A5Fdo1HTVS7V5+gE0PkRym6gdHj1tZztFk6Qs\n\tPZVj6yGvNdO4kucF6PrHFEbhO5A+J7vaiIDXUtwneI9OJNORTl9TPs2penKRr1SK5TPu\n\t7Tkg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1745608601; x=1746213401;\n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state\n\t:from:to:cc:subject:date:message-id:reply-to;\n\tbh=CK6qshR8RFRa/7VHX10utHLHaY2KM1R+Z1gizg1G5IE=;\n\tb=a/zT/ZZkbhblT1mV/nF+b26vSPGse1MX0sfBLBZ8GofZFAs2rBouFUbLeZLwEzPzrf\n\t9QaZWrwnfhrqqTnFxt1ybXyIbsovtut4x3ZxqX/lQKvcUOxavJV0+SWRIXsOpFqtq0dr\n\tuQ0fOUxPOsit+DwpdhvvLeGxyKJcE1jbKnN4Sr9n3fPt8EDFqWfIsA2CLwgliNIO/ke0\n\tsVH0choeGYj5wdhSeIfgxLDJMSYagUtWXAMZ4fcAH6+qJLX1IliEy82gNBZLqUW2TNW7\n\tkU5PPA8Q4YnVrF9QkGzFFDjJAjnhUIXsXhWBIswGS4++T7GV+uISZM++OcN0O/zh5Sf2\n\tQtpA==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCXQGZmXEzqThVjhTNHcHvzQ+DJoTbDOKDSlzZpKjk8PxBxqIsl9NTctd5/2VkJrIyYGcQAqr5DQANWoxQjK8fw=@lists.libcamera.org","X-Gm-Message-State":"AOJu0Yw+NuVxNtf4xhNTqrFYyfGNunDdwsaGcoD5cuFz8lVPIvx7BUdc\n\t/yUsK0GlLqttJTThzIgTslWKbseC8S/v56h0n4TNrH3ymmUYWPr2PAJ0QEtqXyg=","X-Gm-Gg":"ASbGnctpuND484i1aXuVS6j198cPrUBz5chA/dKnwd6sY9v2jVlT7co8qf0sz522XJj\n\tgPZtcROLl3BL/IKHZsXtn3PlBHgbomPrdxZsd6wguXAVFSREXkvwzYTWYa9oeaeqVDzQqEGTnqN\n\t66li+FL5nU9RLJbueJqlyyURbxk7jPeU/gzvTYI+ggfD3DOwhCpfWqkA98OuNrMt1oA3ClIJnqm\n\thjF7kCgC+URCdEh4tPnQk70Vhgal7b5bV1qoVOSPMFUFd96Kh+cA50qzd3qwLSk+Amv+0QPqFHN\n\tOUrOKHC7S6ferckaJfCmiAx886vDi+07U2tqxVxFfBfPjA==","X-Google-Smtp-Source":"AGHT+IEsmhTUWcmIFCdd9QGi4+QcwkmhpAyZ2w28YUV8AzSGEPHLLxYX4BBOOiKjh/+eW2gPGfXoqQ==","X-Received":"by 2002:ac8:574e:0:b0:476:6215:eafc with SMTP id\n\td75a77b69052e-4801c88b8eemr51473901cf.22.1745608601600; \n\tFri, 25 Apr 2025 12:16:41 -0700 (PDT)","Message-ID":"","Subject":"Re: [PATCH 03/27] libcamera: dma_buf_allocator: Favour udmabuf over\n\tcma heap allocations","From":"Nicolas Dufresne ","To":"Laurent Pinchart ","Cc":"Bryan O'Donoghue , Kieran Bingham\n\t, libcamera-devel@lists.libcamera.org,\n\thdegoede@redhat.com, mzamazal@redhat.com","Date":"Fri, 25 Apr 2025 15:16:40 -0400","In-Reply-To":"<20250425143711.GE24730@pendragon.ideasonboard.com>","References":"<20250422215920.4297-1-bryan.odonoghue@linaro.org>\n\t<20250422215920.4297-4-bryan.odonoghue@linaro.org>\n\t<20250422222231.GT17813@pendragon.ideasonboard.com>\n\t<174540101739.2882969.13876021428761049571@ping.linuxembedded.co.uk>\n\t\n\t<174541367461.2882969.15854209249428584063@ping.linuxembedded.co.uk>\n\t\n\t\n\t\n\t<646f8b8f5139dc6678bbd9825a742b13c656e053.camel@ndufresne.ca>\n\t<20250425143711.GE24730@pendragon.ideasonboard.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.56.1 (3.56.1-1.fc42) ","MIME-Version":"1.0","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]