Devicetree
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bod@kernel.org>
To: Atanas Filipov <atanas.filipov@oss.qualcomm.com>,
	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
Subject: Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
Date: Sun, 14 Jun 2026 02:13:15 +0100	[thread overview]
Message-ID: <f862ff70-c42d-4be5-a7aa-3d0470106aef@kernel.org> (raw)
In-Reply-To: <9fab1877-976b-4495-86de-a8c853b9ba24@oss.qualcomm.com>

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.

> afilipov
> 
> On 6/13/2026 12:52 PM, Bryan O'Donoghue wrote:
>> On 13/06/2026 10:24, Atanas Filipov wrote:

Honestly - please quit top-posting. I'll be ignoring further top-posted 
email.

 > And please no top posting !
 >
 > ---
 > bod
 >



  reply	other threads:[~2026-06-14  1:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12 19:44 [PATCH v1 0/4] This series adds support for the Qualcomm JPEG V4L2 mem2mem encoder Atanas Filipov
2026-06-12 19:44 ` [PATCH v1 1/4] dt-bindings: media: qcom: Add JPEG encoder binding Atanas Filipov
2026-06-12 19:57   ` sashiko-bot
2026-06-12 20:42   ` Frank Li
2026-06-12 23:17   ` Bryan O'Donoghue
2026-06-12 23:38   ` Bryan O'Donoghue
2026-06-13 18:42   ` Krzysztof Kozlowski
2026-06-12 19:44 ` [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node Atanas Filipov
2026-06-12 20:06   ` sashiko-bot
2026-06-12 23:14   ` Bryan O'Donoghue
2026-06-13  9:24     ` Atanas Filipov
2026-06-13  9:52       ` Bryan O'Donoghue
2026-06-13 11:16         ` Atanas Filipov
2026-06-14  1:13           ` Bryan O'Donoghue [this message]
2026-06-12 23:52   ` Bryan O'Donoghue
2026-06-13 16:05     ` Atanas Filipov
2026-06-14  0:53       ` Bryan O'Donoghue
2026-06-12 19:44 ` [PATCH v1 3/4] arm64: dts: qcom: sm8250: " Atanas Filipov
2026-06-12 19:44 ` [PATCH v1 4/4] media: qcom: jpeg: Add Qualcomm JPEG V4L2 encoder Atanas Filipov
2026-06-12 20:23   ` sashiko-bot
2026-06-12 20:53   ` Frank Li
2026-06-13 18:43   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f862ff70-c42d-4be5-a7aa-3d0470106aef@kernel.org \
    --to=bod@kernel.org \
    --cc=andersson@kernel.org \
    --cc=atanas.filipov@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox