public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bod@kernel.org>
To: johannes.goede@oss.qualcomm.com,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Loic Poulain <loic.poulain@oss.qualcomm.com>,
	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
Subject: Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
Date: Mon, 30 Mar 2026 15:11:58 +0100	[thread overview]
Message-ID: <0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org> (raw)
In-Reply-To: <0330f63f-7137-4484-954a-fc0776a9b052@oss.qualcomm.com>

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.

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.

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.

TBH I think the CDM should happen for this system and in that vein is 
there any reason not to pack the data in the order the CDM will want ?

So probably in fact IQ structs are not the right thing for OPE+IFE.

---
bod

  reply	other threads:[~2026-03-30 14:12 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <xy6TKmdveRx4cMshSHEUGZ7s3lbsurWcsc2vq05A7_N4bCialR7EelZitouugtZDkpFCAghjqY4NDdSQEIPprw==@protonmail.internalid>
2026-03-23 12:58 ` [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support Loic Poulain
2026-03-23 12:58   ` [RFC PATCH 1/3] dt-bindings: media: qcom: Add CAMSS Offline Processing Engine (OPE) Loic Poulain
2026-03-23 13:03     ` Krzysztof Kozlowski
2026-03-23 16:03       ` Loic Poulain
2026-03-23 16:10         ` Krzysztof Kozlowski
2026-03-23 13:03     ` Bryan O'Donoghue
2026-03-23 12:58   ` [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver Loic Poulain
2026-03-23 13:43     ` Bryan O'Donoghue
2026-03-23 15:31       ` Loic Poulain
2026-03-24 11:00         ` Bryan O'Donoghue
2026-03-24 15:57           ` Loic Poulain
2026-03-24 21:27           ` Dmitry Baryshkov
2026-03-26 12:06             ` johannes.goede
2026-03-30 11:37               ` Dmitry Baryshkov
2026-03-30 13:46                 ` johannes.goede
2026-03-30 14:11                   ` Bryan O'Donoghue [this message]
2026-03-30 14:27                     ` johannes.goede
2026-03-30 14:32                       ` Bryan O'Donoghue
2026-03-30 18:59                         ` Dmitry Baryshkov
2026-03-30 19:07                         ` Loic Poulain
2026-04-05 20:23                           ` Laurent Pinchart
2026-03-30 18:55                     ` Dmitry Baryshkov
2026-03-30 22:51                       ` Bryan O'Donoghue
2026-03-31  8:11                         ` Konrad Dybcio
2026-04-05 20:14                       ` Laurent Pinchart
2026-03-25  9:30           ` Konrad Dybcio
2026-04-05 20:11           ` Laurent Pinchart
2026-04-05 20:15             ` Bryan O'Donoghue
2026-04-05 20:24               ` Laurent Pinchart
2026-04-05 20:28                 ` Bryan O'Donoghue
2026-03-23 12:58   ` [RFC PATCH 3/3] arm64: dts: qcom: qcm2290: Add CAMSS OPE node Loic Poulain
2026-03-23 13:03     ` Bryan O'Donoghue
2026-03-23 13:24     ` Konrad Dybcio
2026-03-23 13:33       ` Bryan O'Donoghue
2026-03-23 16:15         ` Krzysztof Kozlowski
2026-03-24 10:30           ` Bryan O'Donoghue
2026-03-23 16:31       ` Loic Poulain
2026-03-24 10:43         ` Konrad Dybcio
2026-03-24 12:54   ` [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support Bryan O'Donoghue
2026-03-24 16:16     ` Loic Poulain
2026-04-05 19:48       ` Laurent Pinchart
2026-04-05 19:55         ` Bryan O'Donoghue
2026-04-05 20:47           ` Laurent Pinchart
2026-04-05 21:29             ` Bryan O'Donoghue
2026-04-05 23:02             ` Bryan O'Donoghue
2026-04-06 13:22         ` Loic Poulain
2026-04-05 19:57   ` Laurent Pinchart

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=0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org \
    --to=bod@kernel.org \
    --cc=andersson@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=johannes.goede@oss.qualcomm.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=mchehab@kernel.org \
    --cc=robh@kernel.org \
    --cc=vladimir.zapolskiy@linaro.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