From patchwork Tue Oct 4 22:28:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 17523 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 CDF81BD16B for ; Tue, 4 Oct 2022 22:29:09 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id F0D5160AC7; Wed, 5 Oct 2022 00:29:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org; s=mail; t=1664922549; bh=i5Yx/rcgtrX6Aop+AMJaHxVR2CBJz11iNO8CavA/fhI=; h=To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=NmIOCyt0+ASSkD42Z/f74QmZTWz8pvVSt+WAGucbW1AmeIZ+Vm/+uVWjrPieaMIfP NzHfIcUe8Xuws1AeXleQgATfCPooqZ2trzTNl0Hbv1ZjBNFVuO9kCSf/HAlXr6067g 9Kb9Ih0tHTmsFLEGbkhaqrkmR0xgc9jZ3+LA6FHlB0DNd0s3RlBsWe0hACCOJNRzEw jIr3w2kBvmK4fXueFIuG5tw5jhIl+L7LhmIovdxo9frAv/Ml+IsfL5PYT1W0jz0W/8 QlAiC/TAXmdyJDK4Z3ODJvH0cfG/MFtF0XNqpuV1WZ862/K9TNPEHdrzx1TU/L1+Q5 Qg4VEtB4+HgSw== Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 62B7D600E9 for ; Wed, 5 Oct 2022 00:29:07 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="EjFrwCsl"; dkim-atps=neutral Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id B3CC4997; Wed, 5 Oct 2022 00:29:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1664922546; bh=i5Yx/rcgtrX6Aop+AMJaHxVR2CBJz11iNO8CavA/fhI=; h=From:To:Cc:Subject:Date:From; b=EjFrwCsluXqNEZrGkSVh0yfrvwAKK5acuE30U5Mf+9KxkxqwIZtAwC9+IlDjGnKdX UMh+ZWCSX7Li23buPwn5IVfvRt7P+rw6iIrhqr46YCcZvbPJSJbZ3qUZFAUFsW5zbS VQUE8p2+Q2tJ2nRvkZXPa0XvTNqd/iD7Pikis0kY= To: libcamera-devel@lists.libcamera.org Date: Wed, 5 Oct 2022 01:28:59 +0300 Message-Id: <20221004222903.6393-1-laurent.pinchart@ideasonboard.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH v2 0/4] libcamera: Fix kernel deprecation warning with output buffers 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: Laurent Pinchart via libcamera-devel From: Laurent Pinchart Reply-To: Laurent Pinchart Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Hello, This patch series fixes a warning printed by videobuf2. The V4L2 API specification indicates that, for an output video device, the driver will interpret a zero bytesused value as the buffer length (for v4l2_buffer) or the plane length (for v4l2_plane). The videobuf2 framework implements this behaviour, but also considers this case as deprecated and prints a warning: [ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future, [ 54.388026] use the actual size instead. This is triggered by the RkISP1 and IPU3 pipeline handlers, which don't set bytesused for the parameters buffers. As the FrameBuffer metadata is private and only accessible in const form outside of the class (with the exception of V4L2VideoDevice that is listed as a friend), patch 1/4 first makes mutable access to the metadata possible. In order to avoid exposing mutable access to applications, it moves the metadata (and the other remaining private members of the FrameBuffer class) to the FrameBuffer::Private class, and exposes a mutable accessor there. Patches 2/4 and 3/4 then use this new metadata accessor to set the bytesused values in the RkISP1 and IPU3 pipeline handlers. Finally, patch 4/4 prints a warning message in V4L2VideoDevice::queueBuffer() to catch callers that still use the deprecated API. One nice side effect of patch 1/4 is that the V4L2VideoDevice class doesn't need to be listed as a friend of the FrameBuffer class anymore. 2/4 and 3/4 currently hardcode the bytesused value to the size of the parameters buffer structure. This works fine with the RkISP1 and IPU3 pipeline handlers as the parameters buffers have a fixed size, but other devices in the future may use a variable-size buffer which would require the IPA module to pass the data size to the pipeline handler. I was tempted to do the same for RkISP1 and IPU3 for correctness, but decided it was probably not worth it. As far as I can tell, the Raspberry Pi pipeline handler doesn't need any change. Naush, would you be able to test this series to confirm that it doesn't introduce any regression for you ? Laurent Pinchart (4): libcamera: framebuffer: Move remaining private data to Private class pipeline: ipu3: Set bytesused before queuing parameters buffer pipeline: rkisp1: Set bytesused before queuing parameters buffer libcamera: v4l2_videodevice: Warn if bytesused == 0 when queuing output buffer include/libcamera/framebuffer.h | 19 ++---- include/libcamera/internal/framebuffer.h | 10 +++- .../mm/cros_frame_buffer_allocator.cpp | 8 +-- .../mm/generic_frame_buffer_allocator.cpp | 9 +-- src/libcamera/framebuffer.cpp | 58 ++++++++++++------- src/libcamera/pipeline/ipu3/ipu3.cpp | 4 ++ src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 ++ src/libcamera/v4l2_videodevice.cpp | 25 +++++--- 8 files changed, 84 insertions(+), 53 deletions(-) base-commit: 12f4708e35cde15ff9607d59eb053ece1b2bd081 Tested-by: Naushir Patuck