All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Bryan O'Donoghue <bod@kernel.org>,
	johannes.goede@oss.qualcomm.com,
	Loic Poulain <loic.poulain@oss.qualcomm.com>,
	vladimir.zapolskiy@linaro.org, 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: Sun, 5 Apr 2026 23:14:39 +0300	[thread overview]
Message-ID: <20260405201439.GC1213462@killaraus.ideasonboard.com> (raw)
In-Reply-To: <4hasliun3wkook2pvfkntjlzs7elu67ine5q7nd7ptjthx5qvw@rntvb7lnajpc>

On Mon, Mar 30, 2026 at 09:55:23PM +0300, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 03:11:58PM +0100, Bryan O'Donoghue wrote:
> > 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 ?
> 
> This sounds like the most horrible idea: letting userspace directly
> program any registers in a way that is not visible to the kernel.

ISP hardware is typically not designed to make this safe, so I would be
really, really careful about going in that direction. It also seems a
dangerous idea to me.

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

-- 
Regards,

Laurent Pinchart

  parent reply	other threads:[~2026-04-05 20:14 UTC|newest]

Thread overview: 50+ 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
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 [this message]
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-25 17:08     ` kernel test robot
2026-03-25 18:10     ` kernel test robot
2026-03-25 21:08     ` kernel test robot
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=20260405201439.GC1213462@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=andersson@kernel.org \
    --cc=bod@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.