From patchwork Mon Aug 12 11:49:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Milan Zamazal X-Patchwork-Id: 20878 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 984A7C323E for ; Mon, 12 Aug 2024 11:50:33 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 19B53633C8; Mon, 12 Aug 2024 13:50:33 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="FXfaqRP1"; 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 455A9633C3 for ; Mon, 12 Aug 2024 13:50:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1723463428; 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=CPqZkoFnoMEU874j+kZXP8wCNZx/M3NBdrBgOYAhvVY=; b=FXfaqRP1f59yHhasvaV9m7hUOj1saFIzUpPC/MZRwZXxFYvay6jOF6rdvPn3tzlRhWDESc 8vB6nz6mk/oZVwvQNDZJmb4t246VGEuiA7Ztva5qmtmect7fZMUPAjtqbCxfcGA91tTB6+ Y11c5ztDKfNTSGagmk79kR+/8M2kmmo= 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-357-lTtgKFUMMMm7NSo5x9L-jw-1; Mon, 12 Aug 2024 07:50:26 -0400 X-MC-Unique: lTtgKFUMMMm7NSo5x9L-jw-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (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 05A421955D5A for ; Mon, 12 Aug 2024 11:50:26 +0000 (UTC) Received: from nuthatch.redhat.com (unknown [10.45.225.57]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D022219772C4; Mon, 12 Aug 2024 11:50:24 +0000 (UTC) From: Milan Zamazal To: libcamera-devel@lists.libcamera.org Cc: Milan Zamazal Subject: [PATCH 04/16] libcamera: software_isp: Track unused parameters buffers Date: Mon, 12 Aug 2024 13:49:53 +0200 Message-ID: <20240812115009.946036-5-mzamazal@redhat.com> In-Reply-To: <20240812115009.946036-1-mzamazal@redhat.com> References: <20240812115009.946036-1-mzamazal@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 fc9200dd..74f5b952 100644 --- a/include/libcamera/internal/software_isp/software_isp.h +++ b/include/libcamera/internal/software_isp/software_isp.h @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include @@ -95,6 +96,7 @@ private: Thread ispWorkerThread_; SharedMemObject sharedParams_; DebayerParams debayerParams_; + std::queue availableParams_; bool allocateParamsBuffers(); DmaBufAllocator dmaHeap_; diff --git a/src/libcamera/software_isp/software_isp.cpp b/src/libcamera/software_isp/software_isp.cpp index 3f41b71d..a9865398 100644 --- a/src/libcamera/software_isp/software_isp.cpp +++ b/src/libcamera/software_isp/software_isp.cpp @@ -149,6 +149,10 @@ bool SoftwareIsp::allocateParamsBuffers() return false; } + ASSERT(sharedParams_.fd().get() >= 0); + const uint32_t bufferId = sharedParams_.fd().get(); + availableParams_.push(bufferId); + return true; } @@ -360,8 +364,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_->prepare(frame, paramsBufferId); debayer_->invokeMethod(&DebayerCpu::process, ConnectionTypeQueued, frame, paramsBufferId, input, output, debayerParams_); @@ -372,8 +383,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)