From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 C1A4331AA87 for ; Mon, 20 Jul 2026 23:50:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784591442; cv=none; b=pogkpDu9H17siNJYzRJVqPD91TxULM4/fIipz2vIzrS/3rzEw0YfEwOJmGtyTe9XxKKwjbZKzMpsdnFUcml5fiiFgIkjlcMbQMGoAcToveSUJgupGeaE02N3uHM6xuUM7jrnPtbvkSpj2qlDnTIi6HN3i5LkmLayVBK3c7o2RcI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784591442; c=relaxed/simple; bh=TMQAMi41haTFShdYhwA9ecIk62BAQJyNMAjn2zRy9C0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tx9T8Xnfa8bL7tEuU0HwTpOXk2J9JO5xkiC0MrfcYNzykRS3QTPQ1WB0wvXnaP+vTEQXyjsKkHbjWT52tcIBt/ooKomn4ytCAlQlVKOKwI2buFYYxs4RaOzfh9Gy4KSOZ2VUuInmxrm9pS7vVor8fP3Xw4ZaaNvsFENRL4RFM8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Q60gXTSd; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q60gXTSd" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4953de5be0aso35329615e9.0 for ; Mon, 20 Jul 2026 16:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784591438; x=1785196238; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=TMQAMi41haTFShdYhwA9ecIk62BAQJyNMAjn2zRy9C0=; b=Q60gXTSdJqTJOWHPD+NmvlLK8mHHVfV3dyc2vo9QPfWUIC9Oaxjj7x/dWLc8Gyd/eY 2Jv8QmhhbwCn06AjE6FThlLndkCLcCW5WiSe+a75Vglh3qs66Zv56PYWlH0cryGxGk/E 1P2eCSGfNZIfQK/+aXlmcOFq4OyKA/WUr2lNZtwfOZTE656YTBk52Ods3QjYAP8C2OfN V+vMWRMXlDWQ9F2hQg5/DEcs1yu6hKqiIlByAhi96Z++9tezlBUd0KqdnuQ1LR8Zw5zK 2bzgN+sDEAv7yIdIud/G89+7p78bJwur9LxkCICVKTwpMj2QuscJij2b7lNVcQnyIukj /RNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784591438; x=1785196238; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=TMQAMi41haTFShdYhwA9ecIk62BAQJyNMAjn2zRy9C0=; b=X23lvOY5Vz5tyUIESyIzmWBWK930cfPhX0YZhN5kKYIn5pztLTAkBC9dI3zf1B8f5O uYCMycJUfDyb2SH3/d72OEMJVQ7pfaZYDQDUmH8sRiK1rO3sRmDjeTH8aIePQ3YQzoXB S0X2yi59vm4wcch9sM1HmWoSBdTFsQUlT5WAiqcSrYwBU4JwlTgWcj14ibN3RujOF0RE zpYuPiT6f6MD53jsC7UJOLM7pn+0HQ64sp4z+d8KpTQSel+/KEfbbTAir86gDfmeMZz+ vt0yYJwVSgxOu1sO2L60kL9xPaQyyUeIg43T9oZPIhMWoU0vFQnrfGL8wdH4Glr5JN4b 2kMw== X-Forwarded-Encrypted: i=1; AHgh+RpW5s2ggioK2yr77s33HMX8jYrI0uZavHaXdBIusGDqPVgF6l2uiMXose0AK8f4eHxVTIX/Qe9XSebF+s4=@vger.kernel.org X-Gm-Message-State: AOJu0YwC4jxTWTGwptYK6KGl6Hymch6u4N+DBtrnZOooECeUSvGNHsSq 7EZTuBUg0YPnnLiAOPh93SgEw6O4YzHUuPX0tvi3MPR7qJuN5I4cxiEg X-Gm-Gg: AfdE7cnWm7sBVq84AdBLayknMYMVm+4Z6UgBqjgrPTaeYVQ0Z53UJBjxdafdY9YZnH5 YJC07ejIaW+RSAUDjWp5j+iRaywPp2OhVBPDaQtlSh0bI4BQ25A/88T+tjVD5MvYsr3oDmBX13T VBiCqULk3ia5ZG4zCQyM+3lxTJcT648goD2kP+X9Q82Zw2Qh5sAJPk3I6j/h55W41nAi6FhHn5C qmObob+rlxxVbmQuGlWlzHgk1e4ku1aiskzOM5SBIE8qzenX0EwYm8Fsz7NmbOmvJMnAFpra228 cqrTjRTJnXPLIcT/15ud/dbSSlVH8Ug3hm+oGq7T+6I7L9iHzPYzLdoq2szvdc/Jq3XlUpOoWyz vWkoIWaTfjeKAFQQvOd4L5CjUoTZjNwgMIYC55wZaKR3KRhS4XPfGn6aOolOM2PNTX5mNTHTxOK 6+F4TYSaQhAab8K73RpW8wfc+iq8ZAw1CAAmpUQw== X-Received: by 2002:a7b:c054:0:b0:495:5172:661f with SMTP id 5b1f17b1804b1-49551726896mr92898095e9.19.1784591437637; Mon, 20 Jul 2026 16:50:37 -0700 (PDT) Received: from localhost.localdomain ([2001:b07:5d3a:fe75:62ef:2bbc:fc2a:fef4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49558cb8433sm109324555e9.2.2026.07.20.16.50.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 16:50:36 -0700 (PDT) From: Fernando Rimoli To: Dan Scally , Sakari Ailus , linux-media@vger.kernel.org Cc: Fernando Rimoli , Mauro Carvalho Chehab , Arsalan Naeem , Jakob Berg Jespersen , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 4/4] media: ipu-bridge: Request non-continuous clock for ov5693 on IPU6 Date: Tue, 21 Jul 2026 01:50:17 +0200 Message-ID: <20260720235018.11077-1-fernandorimoli11@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <13d6659f-4b51-4041-8aff-70b991ac306e@ideasonboard.com> References: <20260717132021.18034-1-fernandorimoli11@gmail.com> <20260720163819.104130-1-fernandorimoli11@gmail.com> <20260720163819.104130-5-fernandorimoli11@gmail.com> <13d6659f-4b51-4041-8aff-70b991ac306e@ideasonboard.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Dan, Thanks for the reviews on 1-3. You're right that keying on both the PCI ID and the sensor is a bit awkward. My reasoning for scoping it that tightly was caution rather than a known IPU3 failure: I only have IPU6 hardware (Surface Pro 9), so I couldn't confirm that gating the ov5693's clock lane is safe on the IPU3 CSI-2 receiver, and I didn't want to risk regressing the existing cio2 + ov5693 users (the INT33BE Surface Pro/Book devices) that work today with the free-running default. For what it's worth, from the receiver side IPU3 looks agnostic to the flag: ipu3-cio2 only consumes bus.mipi_csi2.num_data_lanes from the parsed endpoint and programs its D-PHY Rx timing (clk_termen/clk_settle) the same way regardless of V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK, it never looks at that flag. So the open question is purely sensor-side: whether the ov5693 idling its clock lane in LP11 (bit 5) upsets the cio2 D-PHY's lock. I can't answer that without IPU3 hardware. If your test tomorrow shows cio2 + ov5693 still streams fine with clock-noncontinuous set, I'm happy to drop the ipu6_pci_tbl check entirely and just request the property for the ov5693 unconditionally in v4 which removes the PCI quirk and is much cleaner. (The sensor-driver side already no-ops when the flag is absent, so nothing else needs to change.) If it turns out IPU3 doesn't like it, then the PCI gate is doing real work and I'd keep it, but I can add a comment making that rationale explicit. Either way I'll respin once we know. Thanks a lot for offering to test on IPU3, that's the one platform I can't cover. Thanks, Fernando