From patchwork Fri Oct 28 09:42:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Naushir Patuck X-Patchwork-Id: 17723 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 4728FBD16B for ; Fri, 28 Oct 2022 09:43:14 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 0D67162FC8; Fri, 28 Oct 2022 11:43:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org; s=mail; t=1666950194; bh=wO5BlERyLgQTRFmBHLXMmg9G2zPmv9c5ynZsWI94kcM=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=2uprzRMab76iI/FKJtk1C5jnht6y2E0mICEfMCKOzeQMvxUugTGZW/LLdMuzcXSn0 NhQknBAQ46YOZpNO5tYPojTl2u8pIJCZkAE1KGhSYMCwsgURcjjjRAwTZj+sDELc/O alyv+/lQjCGXbUBrvYT04ewb90MRAY5Ni2a6RAKwKAhlnC5sa5DUt9I1eT797Ajv4L KQ4U4ivYBYd+fgqAELKElQ9lB4sb3ClcgKvNuM1X7g1Cx0PkmUTCKmukoZbT0MJyKJ 2tXn/CCa4Rp3yqRaGimwG+I9CeP1oCayS5lCiJjHo6Y6FEWCnkRBZV6nvB5JBrkieI oIJmDHPbCl1ww== Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 76C6162F41 for ; Fri, 28 Oct 2022 11:43:12 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (2048-bit key; unprotected) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="Q+c0tMlF"; dkim-atps=neutral Received: by mail-qk1-x734.google.com with SMTP id a5so3055452qkl.6 for ; Fri, 28 Oct 2022 02:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MD8w3bY6M8ZvGwJqgy10et6Dbi6tuH3rGkEypNntNk4=; b=Q+c0tMlFJb+N7WWxzMfZgmFCf5Q/zozBGQBeiK0WURMGb2ce4TqDyL4Wwe6PMKgEt6 Q9ME2UiyvWP4w/dueaW/dm5HunKRIZuDvOFf93qpxmh4HnvtPHpkYpWwPYtZ0ytVWHzW dP6rlwrjDQ9Dss684S5BVtVpAm1jOZQ9infsWsv6CrpDGTdLgzTZUzq6yuMvGB8KthAG A7R1REekYzj7ypsfnfwbBxDuTsYkrXZDNhGiTfCd/kZhY05TJZPOqAja3/nLrz/VQHIO VwCqavsOcelXnQ5NN/KyvXXwykfK7ize3G2DMXmhmeCzIrEQ87snhMJqCh3Ui3eLCf0e Ms5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MD8w3bY6M8ZvGwJqgy10et6Dbi6tuH3rGkEypNntNk4=; b=5X8vkxZiKAXo7l4+dfFfITnRKFt6cP6J8xvUOfCY9BdonuNM3IBxXnSOdJDKVnVGRS R4LYhkc1Y41774jvOyvpcJqHpvWo/H/kl/oZha+tU3BZocoKFhblhi6UdkjqYgXIonV5 zMZzR968RgNPEVge8/NWvEjNn0x32NYl6Mg9drDSCMdvmkmyDINrn2ZbBVWnlmRktDVg bnvtone9G0tG1NhQ9l+yJSKNe1Z1/giDiEsj3kSK6+dK0EZ+jTEuxxYXpwz/8RnKMhDf T5rQqM7kjhCLRjUXQpBJwfnQt09ksjfb2BM+1v826IBBAXfjpyr5gKFyLqaxn3o/PIFU aqaQ== X-Gm-Message-State: ACrzQf2d51bx0YXT6qieL1G+G/fVP1s0BCBelGr7NoGunsIoc6pQb/w2 88SN4Y4DScgtiUvI+0sWJKU3rWtaO8ul8aoLwqRMSncKTGEI4w== X-Google-Smtp-Source: AMsMyM4ynG0aeZcvSIt4k/Tzh1Sy5gazSPvN2jvkFVVelnXhE9nuHpCbjii+pJZGGicS9NCOyzPjfVuaB4ukdwFhgZw= X-Received: by 2002:a37:407:0:b0:6f9:6a80:14b1 with SMTP id 7-20020a370407000000b006f96a8014b1mr8325329qke.198.1666950191032; Fri, 28 Oct 2022 02:43:11 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 28 Oct 2022 10:42:55 +0100 Message-ID: To: libcamera devel Subject: [libcamera-devel] Concurrent camera usage in libcamera 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: , X-Patchwork-Original-From: Naushir Patuck via libcamera-devel From: Naushir Patuck Reply-To: Naushir Patuck Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Hi all, I wonder if I could get some thoughts regarding a problem we are seeing with running multiple cameras in separate libcamera processes on Raspberry Pi (this probably affects any/all platforms though). In my scenario, I have libcamera process 1 running "cam -c 1 -C" and streaming from imx477 using the Raspberry Pi pipeline handler. In process 2, I have "cam -c 2 -C" running streaming from a USB camera using the uvcvideo pipeline handler. If I exit process 2, I get the following error messages: [0:01:33.155169911] [1392] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video2[16:cap]: Unable to request 0 buffers: Device or resource busy [0:01:33.155359910] [1392] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video3[17:cap]: Unable to request 0 buffers: Device or resource busy [0:01:33.155460595] [1392] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video13[18:out]: Unable to request 0 buffers: Device or resource busy [0:01:33.155564354] [1392] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video14[19:cap]: Unable to request 0 buffers: Device or resource busy [0:01:33.155664150] [1392] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video15[20:cap]: Unable to request 0 buffers: Device or resource busy [0:01:33.155763483] [1392] ERROR V4L2 v4l2_videodevice.cpp:1241 /dev/video16[21:cap]: Unable to request 0 buffers: Device or resource busy These errors come up because the V4L2VideoDevice destructor in process 2 is indirectly calling ioctl(REQBUFS, 0) on all the Unicam and ISP device nodes while the device driver buffer queues are actively owned and used by process 1. This does not actively interfere with process 1 running, it continues happily enough. The error here stems from the fact that the RPi pipeline handler PipelineHandler::match() opens all the device nodes for every Camera object registered through PipelineHandler::registerCamera(). So even if the Camera was never used by a process, when terminating the V4L2VideoDevice destructor will call ioctl(REQBUFS, 0) for every single device. This behavior is exactly the same for the ipu3 and rkisp1 pipeline handlers. So the question is how to fix this and avoid the error messages? 1) The V4L2VideoDevice destructor should not call ioctl(REQBUFS, 0) if it has not allocated buffers for the device: PipelineHandler::match(), and defer this call to when configure() gets called. Option 2 is not trivial, as (at least in the RPi pipeline handler) a bunch of validation occurs in PipelineHandler::match() that needs the device nodes to be open. In my opinion, option 1 seems to be the correct thing to do. Any other suggestions or thoughts? Regards, Naush diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp index e30858c9fa02..108e60f035ab 100644 --- a/src/libcamera/v4l2_videodevice.cpp +++ b/src/libcamera/v4l2_videodevice.cpp @@ -758,7 +758,8 @@ void V4L2VideoDevice::close() if (!isOpen()) return; - releaseBuffers(); + if (cache_) + releaseBuffers(); delete fdBufferNotifier_; 2) All pipeline handlers need to change and avoid calling device open() in