From patchwork Mon Feb 16 20:30:23 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Milan Zamazal X-Patchwork-Id: 26173 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 6A551C0DA4 for ; Mon, 16 Feb 2026 20:30:54 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 33E6462217; Mon, 16 Feb 2026 21:30:54 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="OvLrocve"; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 016BB62217 for ; Mon, 16 Feb 2026 21:30:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771273850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kIWpIUzUQXN9/tCaqd8lQIkAEIvvGtlhVkYtCxSXG4I=; b=OvLrocvekkyOrqXemH1ycQlD+soe7NLVf6ej5vmcONYqcrJKiol3ymqS+QKuRlGueptwwW W961Yje2fqQWcBtMxJ6FXHGHLH+AKqIj4orpgeSYXjH5TQr93xq+talzfnzN/Cl6QfBOHo G2SufLmV5G2W/+o04RM7+8Gp9puwV74= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-523-K96L4ck-OPSqiy_AJxfJaQ-1; Mon, 16 Feb 2026 15:30:49 -0500 X-MC-Unique: K96L4ck-OPSqiy_AJxfJaQ-1 X-Mimecast-MFC-AGG-ID: K96L4ck-OPSqiy_AJxfJaQ_1771273848 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 300EB195608A for ; Mon, 16 Feb 2026 20:30:48 +0000 (UTC) Received: from mzamazal-thinkpadp1gen7.tpbc.com (unknown [10.44.32.25]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1ED7F18004AD; Mon, 16 Feb 2026 20:30:46 +0000 (UTC) From: Milan Zamazal To: libcamera-devel@lists.libcamera.org Cc: Milan Zamazal Subject: [RFC PATCH v2 04/14] libcamera: software_isp: Track unused parameters buffers Date: Mon, 16 Feb 2026 21:30:23 +0100 Message-ID: <20260216203034.27558-5-mzamazal@redhat.com> In-Reply-To: <20260216203034.27558-1-mzamazal@redhat.com> References: <20260216203034.27558-1-mzamazal@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3YGvVjDv_XonIG37-O1du6YIbftcCgLdh-5gb9tuPrs_1771273848 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" As a preparation for introducing a ring of parameters buffers, this patch introduces tracking of parameters buffers available for use. SofwareIsp::availableParams_ is a queue of ids of the buffers available for use. When a fresh parameter buffer is needed, its id is retrieved from there and once the buffer is no longer needed, it's put back there, in a method invoked by a signal. This is similar to what the hardware pipelines do. If a parameters buffer is requested but there is no free available, it is an erroneous situation. To recover from it, we have currently no better mechanism than to wait for an available buffer. Simply returning from the processing would mean the finishing signals are not called, resulting in e.g. the input buffer not being returned. This is different from the hardware pipelines, which are structured somewhat differently. We use buffers' file descriptors as buffer ids. The parameters buffers will be shared with the IPA and debayering and we need their common identification everywhere. The buffer file descriptors are shared unchanged so they can be used for the purpose, avoiding a need to pass a special id->buffer mapping to the IPA and debayering on initialization. Note that the parameters buffer id is still actually unused and the only buffer currently used is still copied when passed to debayering. This patch is just preparation for followup patches that will introduce multiple buffers. Signed-off-by: Milan Zamazal --- .../internal/software_isp/software_isp.h | 2 ++ src/libcamera/software_isp/software_isp.cpp | 18 +++++++++++++++--- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/include/libcamera/internal/software_isp/software_isp.h b/include/libcamera/internal/software_isp/software_isp.h index dc6b6f7c1..a8b7b1eb1 100644 --- a/include/libcamera/internal/software_isp/software_isp.h +++ b/include/libcamera/internal/software_isp/software_isp.h @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -98,6 +99,7 @@ private: Thread ispWorkerThread_; SharedMemObject sharedParams_; DebayerParams debayerParams_; + std::queue availableParams_; bool allocateParamsBuffers(); DmaBufAllocator dmaHeap_; bool ccmEnabled_; diff --git a/src/libcamera/software_isp/software_isp.cpp b/src/libcamera/software_isp/software_isp.cpp index dc0a8eb84..adf2a03ab 100644 --- a/src/libcamera/software_isp/software_isp.cpp +++ b/src/libcamera/software_isp/software_isp.cpp @@ -180,6 +180,10 @@ bool SoftwareIsp::allocateParamsBuffers() return false; } + ASSERT(sharedParams_.fd().get() >= 0); + const uint32_t bufferId = sharedParams_.fd().get(); + availableParams_.push(bufferId); + return true; } @@ -404,8 +408,15 @@ void SoftwareIsp::stop() */ void SoftwareIsp::process(uint32_t frame, FrameBuffer *input, FrameBuffer *output) { - /* \todo Provide a real value */ - constexpr uint32_t paramsBufferId = 0; + if (availableParams_.empty()) { + LOG(SoftwareIsp, Error) << "Parameters buffer underrun"; + /* Well, busy loop, but this situation shouldn't normally happen. */ + while (availableParams_.empty()) + ; + } + + const uint32_t paramsBufferId = availableParams_.front(); + availableParams_.pop(); ipa_->computeParams(frame, paramsBufferId); debayer_->invokeMethod(&Debayer::process, ConnectionTypeQueued, frame, paramsBufferId, input, output, debayerParams_); @@ -416,8 +427,9 @@ void SoftwareIsp::saveIspParams([[maybe_unused]] uint32_t paramsBufferId) debayerParams_ = *sharedParams_; } -void SoftwareIsp::releaseIspParams([[maybe_unused]] uint32_t paramsBufferId) +void SoftwareIsp::releaseIspParams(uint32_t paramsBufferId) { + availableParams_.push(paramsBufferId); } void SoftwareIsp::setSensorCtrls(const ControlList &sensorControls)