From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74DED3D9DD7 for ; Mon, 30 Mar 2026 14:27:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774880844; cv=none; b=DxM9/roIQw+OQh1QSz9oSet/xD2F1u+s+WXAV+AikZXaX1koCz11vl1NZ1S9wDwr7yJO5pl1gR0pIL4LYe7yMf64T8HvXOtSRpl8c75CT6tz1UtZTDMMW+F76Mgpgh5Vwb4843DR0lHJJhUkGqX4SzrYxm0QoHiIwG/YdjPASLQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774880844; c=relaxed/simple; bh=9Y+yFJJexfP19jMN/Su+gP3NHoI3tkPOa2xag5BKfL4=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=QhEBE7+GJr/iNKfdOX29wxvlumKRmMCWf5Qm5R5JZ16h1venZpux3h4GRgw0+X1hgL++rpLvr/XInjedCwkUEcmH+mjz0EXCVZaByFTD+GH63Fl7Rq4gBORogkUAvosmB4ohCVP6iUGTXU83TNNPoYAUc5RUL/KN+zIaLmH3BAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=m5EMU2Zz; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Jqzj8bF8; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="m5EMU2Zz"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Jqzj8bF8" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62UDdKE32458308 for ; Mon, 30 Mar 2026 14:27:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= Rds9SJnq9SG6ycLbiiJRTFHpUactXCCMN4gZ0ERDYj8=; b=m5EMU2Zz+XeFpE7d P/6trP/hHs2jGhkVuRJ8Q7vW/NjI/1+0WA51UxXI7uRIyqmSK/8YYkL9N/SDVOMF EEuT7b9CK6yneZ0+ezCAYQW25rKxyU0h1RsTiPfYQuvcZZmS4Hyl6l7oRmyheimf JoOxRs+rDPB4JSWKqOOQLVdr5eDHm5mntk7hqsQEP4sfKzYA4FwJMrGM6aHgeqNm yT+0LmTFCw81Ji0P8IhX5WCW1orILnrupyB6WUsXyn11OHrVbvjo+5+zNF50It7M HtG8G5tGmJWhUXAA5QlWFyPvRFLLqM4527Tbe2YGX6kz8gtFkNVqZODq8Ogm8qhU XPhOSQ== Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4d7nnmsg60-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 30 Mar 2026 14:27:22 +0000 (GMT) Received: by mail-vs1-f69.google.com with SMTP id ada2fe7eead31-60521f54387so496379137.1 for ; Mon, 30 Mar 2026 07:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1774880842; x=1775485642; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=Rds9SJnq9SG6ycLbiiJRTFHpUactXCCMN4gZ0ERDYj8=; b=Jqzj8bF8/nFy8i9vHWWOVf2t2O6AEKEbtcFRQYt1ddCOUz8jF5j1JDb/kLNBYV/eku CFPG6hHGMr3LGvJLdGFW/wf53/jTUPGGmrD28QG0SwGincuhWEbmJ3z9Q94x/Ps9r8aJ Y7nPD/WzHZZEtOeuUs1e7TvRWroNKXNTIUhgJrllKEVGnlNzqD6ZMMaaftugPxRlXMEv XCkue417QfqYyQUerOTjpUBjL0JyQm08rY1M9OmT7eL03T2ROJkNkeQOdyNkYxPsCcUq DzHp7ZaJiWW6dJnqUJb2u/wXXeGJMh+YdEoFkCNrOgJvZLXFlaeTeCM2fGW44CEj2eO/ r9Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774880842; x=1775485642; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Rds9SJnq9SG6ycLbiiJRTFHpUactXCCMN4gZ0ERDYj8=; b=iGvCDFcaJzSbnjKUaMGdN6B+O9OSBvaIf/SAgsq9BmrWTvTZwIVr+E4rtSNfLxExY0 nhkt7LR7H+mIIS7mqlfzn6DIysJo6xebHp9n2KjDPtcZRqF2weBaUldnY9hfPxSq2LSY iJEnM0zzf42rLoRpgoaaSLOI51zuhjZ2YV9fu6dv1+l9SNbuoRs7JOuQ49fXZpek8dye R8yshNUnXSNigtSZYeiL0su1FNzpuy7aHlDVQbrrFPlnku+7/qs3gkokno4n6mcbH4ca 3XAC5T8KLAV78eG1aIHmTFvCV9SV0IMrWloLOuT3xsOzYaqxkGgs8WoOEiSsnLqz5MW7 Y5vA== X-Forwarded-Encrypted: i=1; AJvYcCX2ipGlSIA0nBPar2FSCHeFV8iXLt+0fchkv7n6gJCiQDPZX1320p3bd6v2suY+nHNBRN8E5rrsiYt3Hp4=@vger.kernel.org X-Gm-Message-State: AOJu0YxDuSLeW0Y1xoxGusy4tBRrhhNl5G5rRPmRJvnHgSIXNETf9Yz4 iQQ1FOjVjrq8zwaWCVVm9gOZmsemx4jiTPixgyl1NBOmqZfX+M+YoBJpgCP0IibKpZXzgpPuO3o D8JBXIO2/+AAtAHvdnti3r22aLZkPaa2/fVnNvhOQ3r137p9H6G74wVnQsJ2jjxQs3NU= X-Gm-Gg: ATEYQzyQ9F4KjlP6aw7VoIJPS4+IspUESuOY+P/xFXC5eoecdm6A2DSUMfqhwPEUJI/ k8GNNsPnO6FR1uMJ5qxLcs8p/LSM6LeMMUWGHhaOfN298eO2PQoW90mys7ej5nFC0sMWXkvOtHC IllKCvOZHW4rmgQmvnKHcA86pxSaw0PGbUW0C00/zAHajCsJqs71paQh3ycucKKYvg1UkgbruqV NErG+EA+nWcImd7ZaRcrd4xk/TCOb+/vlIb0FCEzZiH38AEacMShTMUYRGiqJujyPFcqE0Hv2Fe g9f3aDRq+vRDXN0V8Lvh3oIhuuTz0Mna+VdfL308ji3U2KDgDrEN0D6yw4WJh97JJWHPeX9D/eC gIKUAk6MiEZgLe/EyzuIMY8Gr9wEDdFTbfyrHkdVagVSxzSYYnicvA2aADYHCte6Hqktw+xEz90 gM/rPMqB+H/h7YNy8QsDOtm2PeRztllzL1EoNLKCvjtFABnZI5l2FA6q4IUEMc1gD2v0KUzPTPM mN6qGBmIwNaAWx4 X-Received: by 2002:a05:6102:560b:b0:5ff:d1c8:a85e with SMTP id ada2fe7eead31-604f930a02dmr4164995137.32.1774880841465; Mon, 30 Mar 2026 07:27:21 -0700 (PDT) X-Received: by 2002:a05:6102:560b:b0:5ff:d1c8:a85e with SMTP id ada2fe7eead31-604f930a02dmr4164980137.32.1774880840968; Mon, 30 Mar 2026 07:27:20 -0700 (PDT) Received: from ?IPV6:2001:1c00:c32:7800:5bfa:a036:83f0:f9ec? (2001-1c00-0c32-7800-5bfa-a036-83f0-f9ec.cable.dynamic.v6.ziggo.nl. [2001:1c00:c32:7800:5bfa:a036:83f0:f9ec]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-66b7275ff3esm2667651a12.3.2026.03.30.07.27.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2026 07:27:19 -0700 (PDT) Message-ID: <2e4c4641-f631-48fa-b5dd-6efd70110dd6@oss.qualcomm.com> Date: Mon, 30 Mar 2026 16:27:18 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: johannes.goede@oss.qualcomm.com Subject: Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver To: Bryan O'Donoghue , Dmitry Baryshkov Cc: Loic Poulain , vladimir.zapolskiy@linaro.org, laurent.pinchart@ideasonboard.com, kieran.bingham@ideasonboard.com, robh@kernel.org, krzk+dt@kernel.org, andersson@kernel.org, konradybcio@kernel.org, linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mchehab@kernel.org References: <20260323125824.211615-1-loic.poulain@oss.qualcomm.com> <20260323125824.211615-3-loic.poulain@oss.qualcomm.com> <1ba54ec0-be51-4694-a79b-f272e76303d2@kernel.org> <12194cc0-0960-486c-be7e-1a22d95de340@kernel.org> <7fc31426-3157-49c7-a30d-dcd7b181fcc6@oss.qualcomm.com> <8DTHyPLaUjGKd83PvBsisjn_SnpUnvkateTtwz9P6CChP9VGfDyQmJa4Rfd5KwOBOLhtGFJPDzfHrXC4zvV-Fg==@protonmail.internalid> <0330f63f-7137-4484-954a-fc0776a9b052@oss.qualcomm.com> <0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org> Content-Language: en-US, nl In-Reply-To: <0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzMwMDExMyBTYWx0ZWRfXwVv8Z5naAXLq zMn7A3nIhsuWk0xSgWjN3gmCsBDw8nqm8xmWacBa3AR2pc1crgQBNX4uz4eHJyM5xAmdqq3ZeMP 1scqw7horTO4uLM0cNeHRnD9YdCGi5ztjKS2p43ameMPyI+dVTakhCrKleFhf5OOMSJT2AGUyBq 5wregVySFougmV6vv8mnHNKMNJJSKN8EgoXQ3uQppQT/Ld2/2zEuiFmutU3uZIXSERoxfHNT+rN 0DT0pn0r70FbWXerrfU+RFgmvsLIlibjhawqP1C4cK2bld1rd0MyYopGI7FYLBy2ppoPxXwWTFJ CDKfN3e/Esu1JnplgNtKBWrPE7c8Nj+xRg4z2UBhZWMLvCAR6vHQUuUI37mD5IEg0mDBJRtIb0n PUyx0y+c91GujQ8JiZTXJtBiFxvB5+SVEs0O7GMjdXYIaNHZw2+6B291qGrsCub/mX6D1lptZA7 GjKh/Fwr05PdvpjQtQg== X-Authority-Analysis: v=2.4 cv=M4FA6iws c=1 sm=1 tr=0 ts=69ca884a cx=c_pps a=5HAIKLe1ejAbszaTRHs9Ug==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=EUspDBNiAAAA:8 a=0fAIJR1rb9fCs4FPyLUA:9 a=QEXdDO2ut3YA:10 a=gYDTvv6II1OnSo0itH1n:22 X-Proofpoint-GUID: kytCHjdsVEUSSbjUjdaUmxOB8aws0U0d X-Proofpoint-ORIG-GUID: kytCHjdsVEUSSbjUjdaUmxOB8aws0U0d X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-29_05,2026-03-28_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 malwarescore=0 adultscore=0 impostorscore=0 bulkscore=0 clxscore=1015 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603300113 Hi, On 30-Mar-26 16:11, Bryan O'Donoghue wrote: > On 30/03/2026 14:46, johannes.goede@oss.qualcomm.com wrote: >>>> And then your CCMv1 or CCMv2 helper will get called with >>>> the matching parameter-data. >>> This leads to userspace having to know exact format for each hardware >>> version, which is not nice. At the very least it should be possible to >>> accept CCMv1 buffers and covert them to CCMv2 when required. >> Yes, but a new ISP may also have a different pipeline altogether >> with e.g. more then one preview/viewfinder output vs one viewfinder >> output for current hw, etc. > > My scoping on HFI shows that the IQ structures between Kona and later versions have pretty stable data-structures. > > It might be worthwhile for the non-HFI version to implement those structures. Maybe, it depends on if they are really 100% the same various IQ parameters are in various different fixed-point formats. I don't think we want to be converting from one precision fixed-point to another precision fixed-point in the kernel. > I keep mentioning CDM. Its also possible to construct the buffer in the format the CDM would require and hand that from user-space into the kernel. I believe the CDM take register addresses + values to setup the OPE for the next stripe to process ? Directly exporting a format which takes register addresses + values to userspace does not sound like a good idea. If you look at the current structure of the OPE driver it already keeps tracks if per stripe settings, only atm it programs those directly on the stripe completion IRQ rather then setting up the CDM. Generating the CDM settings from that data should be straight forward. I really do not believe that such low-level details belong in the userspace API in any way. If anything whether we are using the CDM or directly doing the next stripe programming from the IRQ handler should be completely transparent to userspace. > > That would save alot of overhead translating from one format to another. > > That's another reason I bring up CDM again and again. We probably don't want to fix to the wrong format for OPE, introduce the CDM and then find we have to map from one format to another for large and complex data over and over again for each frame or every N frames. CDM is a much lower-level API then what is expected from a media-controller centric V4L2 driver. Basically the OPE driver will export: * media-controller node * bunch of subdevs + routing between them * /dev/video# videobuffer queue for raw input frames * /dev/video# parameter queue for extensible generic v4l2 ISP parameters buffers (with qcom specific contents) * /dev/video# videobuffer "video" output queue for processed frames * /dev/video# videobuffer "viewfinder" output queue for "extra" downscaled processed frames No statistics since these come from the CSI2 bits (VFE PIX) on Agetti. This is is basically the current consensus what a modern hardware camera ISP driver should look like to userspace. Anything lower level then this should be abstracted by the kernel. Note both output nodes can probably downscale, but the viewfinder one can do an extra downscaling step on top in case userspace wants 2 streams one higher res to record and a lower-res to show on screen. Regards, Hans