From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A40B23A9AD for ; Tue, 6 Jan 2026 15:42:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767714124; cv=none; b=kGDoltgTyTthmt+8hCdkB1cY2rmPEli/G5EDfJT3zfyOUgdkQjkDXTv1Z8K9FECVmDv66PWBWjLdWDDFVSGFA7BLhAO3GT5uc9iosxzZSOsEn86unnjh0LUuY/6n7HY+ChLVpJxnUDLlRkbOAoBkP03bRpyTCbGt6fS08xIImF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767714124; c=relaxed/simple; bh=ZyHIVjtaj7HpnU+gARNjSz9uHM0V5SJQC9EL6UP72qc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=RWy37uXmICYvmrQRExNuJVTnWl8aFp1OvaY1aa+003d2lpm6eR7BKAYF5sUvfN2eRhdJ25IIi1h7NXx9FNGz/xplWucUYQ4Pet/2Dh+PtPgfjU3Oyxu12THJsPYGe0tNt2uGbItMh1C6U1rq8vaavmubei+btF778G65S2nvfEs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ndufresne.ca; spf=pass smtp.mailfrom=ndufresne.ca; dkim=pass (2048-bit key) header.d=ndufresne-ca.20230601.gappssmtp.com header.i=@ndufresne-ca.20230601.gappssmtp.com header.b=2ISf0AgZ; arc=none smtp.client-ip=209.85.222.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ndufresne.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ndufresne.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ndufresne-ca.20230601.gappssmtp.com header.i=@ndufresne-ca.20230601.gappssmtp.com header.b="2ISf0AgZ" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-8b2ec756de0so106316485a.3 for ; Tue, 06 Jan 2026 07:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1767714119; x=1768318919; darn=vger.kernel.org; h=mime-version:user-agent:autocrypt:references:in-reply-to:date:cc:to :from:subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ZyHIVjtaj7HpnU+gARNjSz9uHM0V5SJQC9EL6UP72qc=; b=2ISf0AgZNd2FikmqleZOF7zJfem4Vi+KL+2+nsQkwM5B90xD/+uQ+164j+eFwwZtvw 6MLj+lcuVuacGSVYbkxhdYchc3iPDi0nkk5LPw+HULpirWhSk4FPDoEEm8fZO181hBb7 7sypUIcn4N0CiSYjhyt6CGMfTuJnSHjZaBjMfmryqVyzW3ZFA6oAdfBPaVLlkBQsNjh3 0/h5ygbZchB1f14BD8b5sSmKKnGDf0CX51yXP/dsN91r6rNNJSKvpnXbtlf23IKEyAwB HZ8R+wKVfzn3hffBQs9dy7A/nMVAI5+fS7WFpgZQKUr2rauRcxel4ASruXZdLWyi3ADV 8Hkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767714119; x=1768318919; h=mime-version:user-agent:autocrypt:references:in-reply-to:date:cc:to :from:subject:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZyHIVjtaj7HpnU+gARNjSz9uHM0V5SJQC9EL6UP72qc=; b=XSqFnhMs8AQ5VBW/KKEc/Y5eAbYf2EmBkF2LtWJfP+/Yodem4fVcE5cWLPkTbi4E6K +zbtFHl3Vp8ICqCg3w2ZhggmAl75pJIyrJ+ClRX7sITG/71litedcDSssQmvYunBLF3c 79BkJAHcOE6MfTcY6IzkVAup1bEDGiC2wnb1V6D6B9vtGt74HfdKFbZ1PkarWx38CYtg 8E1VE0ZV7WoOKT4+Ip/hp8JqObFSQ2YGrgE/EzEgOmmEn4NX71GERB/8j1eN0P2mu3Up Z0OsJVsvcLTeqcjZ9AUh9NwOJIk+DagMoZ9ihysnGyAogMJGZS2dx9AYAl1LTAVAPAgf w1qw== X-Forwarded-Encrypted: i=1; AJvYcCVD5YtsOWpebGoKedOoHykvQ3RjIEDCybietCAs1cxfR9Nw0NnpwVwosiB5vnG8M5vTslBrkV3dQeKnCfk=@vger.kernel.org X-Gm-Message-State: AOJu0YwruOBFODdodpV3/fX37Ob8RTab5JHeY7Q9cqk1czI1vNi1Ea7Z UOWSkXlE9mtOhQ9JOyWpvWCjf/KY4FPBiOPJOGd5DXhcBqWrSliFn38qOM8CNm9F4ASuQsVaieN VIV9j X-Gm-Gg: AY/fxX6rk5Y85xCax3XA3OFL12momBS8u4BJx2gUEHqUh1eKIIkLiyK21BlvAqMMwhD gUrDUplSi0p32qOOJSmjS54pL7xTNLwHY4QK7NiUlb0vXwhbD8+MFgKv49ByCuMOUYTIjaEzIHf Kusy5zJBSsNPQWOAl6IgWwhb+ct66SoE5ywozh8G9C+tGkbk442UZizqQuDI7sEw0bUPz3650fo osXgkgmKxF5oEqWxGJvzSBEWxN1HcxRNm+EDjBV6GUjWhTqFcU7gdKITYhYoiiuRALua0mWyKTu 8V2Ft7+gvdJmRduqLupfse9GZoR/MJc+hut7Ndd7snuyck+bFsbb3Qoawp1ATn5aPfs5g7jWkkP 3k7NBSx20Kuxe9NMLQZcfNXC5PJ5YDpL0BuJTNPioVg9xpgxg27xdXaU3QxDhiVOC+JfoQTCeEg UF2J6WhI7ACI0+syUu X-Google-Smtp-Source: AGHT+IGOjr7+Fr5tWYcAPd24+dhrl2pCBfmz4dMnYF307/sgHCL4jktrKPsJUTO8WaP3DJTmPx3M7w== X-Received: by 2002:a05:620a:4623:b0:892:a186:6b4f with SMTP id af79cd13be357-8c37ebb50fdmr482415285a.77.1767714118936; Tue, 06 Jan 2026 07:41:58 -0800 (PST) Received: from ?IPv6:2606:6d00:17:7b4b::5ac? ([2606:6d00:17:7b4b::5ac]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c37f540650sm187549385a.47.2026.01.06.07.41.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 07:41:58 -0800 (PST) Message-ID: Subject: Re: [PATCH 1/4] media: dw100: Implement V4L2 requests support From: Nicolas Dufresne To: Laurent Pinchart , Stefan Klug Cc: Xavier Roumegue , Mauro Carvalho Chehab , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Hans Verkuil Date: Tue, 06 Jan 2026 10:41:56 -0500 In-Reply-To: <20260106145354.GB26157@pendragon.ideasonboard.com> References: <20260105-sklug-v6-16-topic-dw100-v3-1-dev-v1-0-65af34d04fd8@ideasonboard.com> <20260105-sklug-v6-16-topic-dw100-v3-1-dev-v1-1-65af34d04fd8@ideasonboard.com> <40dfd12b585681d8edf9641967160c086cc120c3.camel@ndufresne.ca> <20260106003302.GJ10026@pendragon.ideasonboard.com> <176770897731.12184.12302111059048415045@localhost> <20260106145354.GB26157@pendragon.ideasonboard.com> Autocrypt: addr=nicolas@ndufresne.ca; prefer-encrypt=mutual; keydata=mDMEaCN2ixYJKwYBBAHaRw8BAQdAM0EHepTful3JOIzcPv6ekHOenE1u0vDG1gdHFrChD /e0J05pY29sYXMgRHVmcmVzbmUgPG5pY29sYXNAbmR1ZnJlc25lLmNhPoicBBMWCgBEAhsDBQsJCA cCAiICBhUKCQgLAgQWAgMBAh4HAheABQkJZfd1FiEE7w1SgRXEw8IaBG8S2UGUUSlgcvQFAmibrjo CGQEACgkQ2UGUUSlgcvQlQwD/RjpU1SZYcKG6pnfnQ8ivgtTkGDRUJ8gP3fK7+XUjRNIA/iXfhXMN abIWxO2oCXKf3TdD7aQ4070KO6zSxIcxgNQFtDFOaWNvbGFzIER1ZnJlc25lIDxuaWNvbGFzLmR1Z nJlc25lQGNvbGxhYm9yYS5jb20+iJkEExYKAEECGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4 AWIQTvDVKBFcTDwhoEbxLZQZRRKWBy9AUCaCyyxgUJCWX3dQAKCRDZQZRRKWBy9ARJAP96pFmLffZ smBUpkyVBfFAf+zq6BJt769R0al3kHvUKdgD9G7KAHuioxD2v6SX7idpIazjzx8b8rfzwTWyOQWHC AAS0LU5pY29sYXMgRHVmcmVzbmUgPG5pY29sYXMuZHVmcmVzbmVAZ21haWwuY29tPoiZBBMWCgBBF iEE7w1SgRXEw8IaBG8S2UGUUSlgcvQFAmibrGYCGwMFCQll93UFCwkIBwICIgIGFQoJCAsCBBYCAw ECHgcCF4AACgkQ2UGUUSlgcvRObgD/YnQjfi4+L8f4fI7p1pPMTwRTcaRdy6aqkKEmKsCArzQBAK8 bRLv9QjuqsE6oQZra/RB4widZPvphs78H0P6NmpIJ Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-w6Qd9dvsJZkBofCWsLKx" User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 --=-w6Qd9dvsJZkBofCWsLKx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Laurent, Le mardi 06 janvier 2026 =C3=A0 16:53 +0200, Laurent Pinchart a =C3=A9crit= =C2=A0: > CC'ing Hans Verkuil for two questions below. > >=20 [...] > > The docs say "a buffer that was never queued to the driver but is > > associated with a queued request was canceled..." So to my understandin= g > > the only purpose of this function is to mark all controls in the reques= t > > as being handled, so that the request can be finished. >=20 > That doesn't explain why it should be done twice per request. Hans, > could you clarify this ? I explained it in another thread, it is only called if device_run() is not = going to be called, so only once. vb2 does not have access to the the control han= dler, so it can't call the v4l2_ctrl_request_complete() fonction directly. >=20 [...] > > Nicolas, if I go you right you mean that one might be tempted to do > >=20 > > v4l2_ctrl_request_setup() > > v4l2_m2m_buf_done(src) > > v4l2_m2m_buf_done(dst) > > v4l2_ctrl_request_complete() > >=20 > > which feels natural from the names of the functions, but the > > v4l2_m2m_buf_done(src) might complete the request if it has no > > associated controls and therefore the later v4l2_ctrl_request_complete(= ) > > would fail... > >=20 > > I see that the usage of v4l2_m2m_buf_done_and_job_finish() is more > > compact and will use that in v2. For the sake of understanding: The onl= y > > functional issue with my code is that v4l2_m2m_buf_done(src_buf) is > > called before v4l2_m2m_buf_done(dest_buf), right? >=20 > Is that an issue, why would the destination buffer need to be completed > first ? The VB2 media_request_object is being removed from the request once the OUT= PUT (src) buffer is marked done. If this was the last media_request_object, the request will move to completed state, which will signal its FD. If you do that before you mark the CAPTURE (dst) buffer as done, an applica= tion that uses non blocking IOs may endup calling DQBUF(dst) too soon, which wil= l return EBUSY. Since we really want the request FD to be used as the only synchronisation point, we made the rule that the request FD must be signall= ed last. Since its error prone, and its not illegal to synchronise on the devi= ce read/write/pri state, we made a condensed helper for it. Alternatively, the manual request completion is being added for cases this implicit request completion does not work, or when it makes everything too complicated to adhere to this rule. This is the case for dual-stage video decoders (MTK/RPi). Nicolas [...] --=-w6Qd9dvsJZkBofCWsLKx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTvDVKBFcTDwhoEbxLZQZRRKWBy9AUCaV0tRAAKCRDZQZRRKWBy 9I2cAP40X1kizGKniAJpnsxW2HVfKMWON8DejJHlAutRKMtHtQEA9121yKIa29+0 ZM9e4HsunUX7z6c6rzdYPCcV1KvYeAg= =PX6j -----END PGP SIGNATURE----- --=-w6Qd9dvsJZkBofCWsLKx--