From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (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 66EF43AC0CE for ; Fri, 19 Jun 2026 14:57:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781881069; cv=none; b=ODgj+2uJQg/2UCR4ETltw5NybyMJsYLQnt2Mxb3QsSdPZjZzlZF9JF1lC1K69afC4UblBne6mU3MgBw/FAgWHnQO7eoo8iyd72zF3AUWYXNuBuy0tmJOFQRRPIht1b59KvKV6UQY7gIBaOYg38UEOBxQd7a0VAmgxPMtncuwZmw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781881069; c=relaxed/simple; bh=r+Vx8bE9bzuOFwGqKWOBdk/pvY5QcwTgaH/iYD/LprU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ndWFnM0LcpwV5Oq2mTxJ7RPINuD5CEyLwgEgQhLW5jykogsOXo9y4IQ+aLL9iqVJNdre+U4rt41zG+O9kyxQPfs93A+Z9VO9M4HecQYyBNsyIf+VM0F/pk0Zu3ki9Gu7e0Yxv2jiewos2ln95pcwYxI76DfaAXoCUjf6fSOzXwU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=q9N/eMvJ; arc=none smtp.client-ip=209.85.208.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="q9N/eMvJ" Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-3967701fc3cso3640131fa.0 for ; Fri, 19 Jun 2026 07:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1781881067; x=1782485867; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=wqar4JczNNOg75V9/pJCCBRYnOJd819Em91TzN50JyI=; b=q9N/eMvJq5hm3/IJqOlwRwwlWEAXsvlFvpfcry2qK+FEUoywHH+SbJ+5/PC/2ku2lO vC0d4EYHVqqnYqudzShfT45J+oJ14P6sYGsHaOvPQrhcRrg6EaHD9rcz0svEe/QG3Xvw bTFSQZN+8Yqe/nGCWbia6/H6Ie9nx5/Us5xtBwMLSQVd4CoZGmGYMPOhjiyxc1eIxOr9 QaoH/sgWr/uGZ2vjWXmLCcLDmBrPAinv00gQGBWG74A4tPdk+3Xa3PPTPiPoIW8FF0gh W5PdMGXS4kbTpTthcDkRNOEhMTvuuWvkCKBW/7tE+5JMToJnbldD6eV+qmIsy2ub6dz3 h/mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781881067; x=1782485867; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wqar4JczNNOg75V9/pJCCBRYnOJd819Em91TzN50JyI=; b=imyWB+dyDmge76/5qjvVKKn+1Y9kJTxLJwC9pRGXOMv3DyNUR9AWen3mv257ZV7xkA 5afH+itMW4cy4kMxyrvDTEQK/0CYOk6khjDmJvU/Vhth1Pc1tx6SSTuwiSjPbocDGt29 8mq0W8fVbTm0h4lOEdFM3sGAkumXP1zDwBufuDilVB592ZG5AEPympAxrdZXFFOVUIhQ ZRvh6H1t0YuuwV4mGIqXmsdilnbcI+e3ui0vdYb5tMik+hcKrXCuwZ3KLIkJN7Unic54 2J9eguub0Sm0zd72laWOFmIUz9a2Z+lrNTvOpY145PEuoGutVp+2HRGCmEpKjihlugKq xsUA== X-Forwarded-Encrypted: i=1; AFNElJ+BGqjqiUexcfI1R+VEzSehZx2BARPpPIT7Pr7RGOJmYru7u9uquC0BiQ1wyp/kgFG7LFWf0/+teNWPXyA=@vger.kernel.org X-Gm-Message-State: AOJu0YzPSpOoK8cbfvjkuaCBqCuhzfqMTbD8FUbU8kGIQ/W05J9FQNNz GRPQsc1nvJ0haWdhd4+7We741lK6R1C40KlDue4tP49Ihy8Q1XE7Ca1R/4JGp6yiVJo= X-Gm-Gg: AfdE7ckEVFy2RxRjDnfjN4MDcyMi8AF4QfizqWJvwcpyqdKaOU68wHL9rLI+Ieb6ib+ Jwa7uXAWXA5/1c26SPa7RXH5K0O05G1xZA+5F/UueviCaGaaLzuxz/nKqGIXSVoaLruJgzKdeiJ OYPH4+mhtymzoNxT3irMM34FG9d8OePTlTYVZCPERO4TJNGd+IdaRXFKWj+/UiUuAUvTdw/OaIt 9vxOTwe1dUWzu49lpcJlMD/eKrwASv0hKrS9hn+hLU6djTSwnoQ5kHXtQFZtr7qb4NDYTTaX2H9 FlafmwkrMYZfO3izD+9XBmpWs276kHjLjTUvlRXsikhkkMF7O3TMJW065XddyYDrnmFrsHKrFwV 6qPxl+FCtSo3W+SxK9dTA4y9Xx1qEuhLNWXRC2/Rhrbnnj9FT/tdoHJlxR6LjJfEoZ4/aEQU6CQ Bi0f8jDVsaHyP4XNpzAEh4axa2E+JNmegSF+EkCNAt1d31pVOOYdDCfzs9LSkS0yzjj6I= X-Received: by 2002:a2e:a884:0:b0:396:8d4f:573d with SMTP id 38308e7fff4ca-3998a306993mr5773511fa.4.1781881066524; Fri, 19 Jun 2026 07:57:46 -0700 (PDT) Received: from [192.168.1.100] (91-159-24-186.elisa-laajakaista.fi. [91.159.24.186]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3998bec969esm5732211fa.6.2026.06.19.07.57.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2026 07:57:45 -0700 (PDT) Message-ID: <45a4b138-0fbd-4c55-bccd-83858d95df5d@linaro.org> Date: Fri, 19 Jun 2026 17:57:44 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node To: Konrad Dybcio , Bryan O'Donoghue , Atanas Filipov , linux-media@vger.kernel.org Cc: mchehab@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, andersson@kernel.org, konradybcio@kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260612194417.1737009-1-atanas.filipov@oss.qualcomm.com> <20260612194417.1737009-3-atanas.filipov@oss.qualcomm.com> <8d230cca-2023-4a13-876f-d5db8eb200a1@kernel.org> <3d4e0147-8e62-4872-b881-1452f5e09e85@oss.qualcomm.com> <9fab1877-976b-4495-86de-a8c853b9ba24@oss.qualcomm.com> From: Vladimir Zapolskiy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/19/26 17:38, Konrad Dybcio wrote: > On 6/14/26 3:13 AM, Bryan O'Donoghue wrote: >> On 13/06/2026 12:16, Atanas Filipov wrote: >>> Thank you for the detailed explanation. Let me share my understanding of >>> the shared upper-level blocks. They are exactly the reason we have >>> frameworks like ICC with aggregate bandwidth voting, reference counting >>> in the clock framework, and so on — the same applies to power domains. I >>> do not think using shared resources is a problem when the drivers are >>> correctly designed. >>> >>> We have actually validated this: we got CAMSS working alongside the >>> Qualcomm downstream camera stack after fixing the shared resource >>> management — something everyone considered nearly impossible at the time. >>> >>> On the CAMNOC and CPAS concern: if that coordination becomes necessary, >>> the right fix is to address the resource management in both drivers >>> independently, using the aggregate capabilities of the existing >>> frameworks — not to introduce a >>> hierarchical dependency between them. Moving JPEG under CAMSS does not >>> solve the CAMNOC, clock and power domain coordination problems, it just >>> papers over them. >>> >>> IMO the problem you are pointing at is more general than just CAMNOC — I >>> would add priorities, QoS and other shared resources to the list as >>> well. The answer to all of them is the same: correct use of the existing >>> frameworks, not driver >>> merging. >>> >>> On the idea of putting JPEG inside CAMSS with an external API: >> >> I haven't remotely suggested that. >> >>> no engine or pipeline that produces YUV output, which is what the JPEG >>> encoder needs as input. If JPEG moves into CAMSS without an external >>> API, it becomes >>> inaccessible to userspace. If it does expose one, we end up with a >>> standalone interface anyway, just with an extra layer of indirection on top. >> >> This is a very long winded way of saying no without acknowledging the core point that the DT should scribe the hardware the way it really is, as opposed to following software architecture preference. >> >> It is the case JPEG lives inside of CAMSS. This is a fact of the hardware, the DT should express those facts not software preferences. > > That's also precisely what the "Tree" part is about - CAMSS is essentially > a bus (as evidenced by the existence of a set of resources, like the > AHB/CPAS clocks, the TITAN_TOP GDSC and the interconnect paths that gate > access to everything on it), just like MDSS essentially is a bus. The JPEG I also agree that CAMSS should be thought as a bus, and therefore a child IP shall both a) be described as a subnode, b) get shared resources on parent's side like PDs and clocks avoiding unnecessary repeated description in its own node. I believe this general notice should be applicable to all CAMSS IPs, and I repeat it here, because there was a disagreement about it somewhere else. > encoder, just like all the other blocks are then devices on that bus, > logically belonging to the CAMSS node > -- Best wishes, Vladimir