The REGISTER_CAMERA_SENSOR_HELPER() macro defines a class type that
inherits from the CameraSensorHelperFactory class, and implements a
constructor and createInstance() function. Replace the code generation
through macro with the C++ equivalent, a class template, as done by the
Algorithm factory.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Avoid naked pointer with memory allocation by returning a unique_ptr
from CameraSensorHelperFactory::createInstance(), in order to increase
memory allocation safety.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The CameraSensorHelperFactory registerType() and createInstance()
functions are called by the CameraSensorHelperFactory class only. Make
them private.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Frame contexts will become the core component of IPA modules, always
available to functions of the algorithms. To indicate and prepare for
this, turn the frame context pointer passed to Algorithm::process() into
a reference.
The RkISP1 IPA module doesn't use frame contexts yet, so pass a dummy
context for now.
While at it, drop an unneeded [[maybe_unused]] from Agc::process() and
add a missing parameter documentation for the frameContext argument to
Awb::process().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
To help attribute messages logged by the Module class to a particular
IPA module, make the class loggable. The logPrefix() function must be
implemented by the IPA module-specific derived class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Add a Module::createAlgorithms() function to instantiate algorithms from
a YamlObject. The instantiated algorithms are stored in a private member
variable list, exposed through the Module::algorithms() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
In order to allow dynamic instantiation of algorithms based on tuning
data files, add a mechanism to register algorithms with the IPA module.
The implementation relies on an AlgorithmFactory class and a
registration macro, similar to the pipeline handler registration
mechanism. The main difference is that the algorithm registration and
instantiation are implemented in the Module class instead of the
AlgorithmFactory class, making the factory an internal implementation
detail.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The libipa.cpp file exists for the sole purpose of documentating the ipa
namespace. As we now have a top-level module.cpp file in libipa, move
the documentation there, and drop libipa.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
libipa defines an abstract Algorithm class template that is specialized
by IPA modules. IPA modules then instantiate and manage algorithms
internally, without help from libipa. With ongoing work on tuning data
support for the RkISP1, and future similar work for the IPU3, more code
duplication for algorithms management is expected.
To address this and share code between multiple IPA modules, introduce a
new Module class template that will define and manage top-level concepts
for the IPA module.
The Module class template needs to be specialized with the same types as
the Algorithm class. To avoid manual specialization of both classes,
store the types in the Module class, and replace the template arguments
of the Algorithm class with a single Module argument from which the
other types are retrieved.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Currently we have a single structure of IPAFrameContext but
subsequently, we shall have a ring buffer (or similar) container
to keep IPAFrameContext structures for each frame.
It would be a hassle to query out the frame context required for
process() (since they will reside in a ring buffer) by the IPA
for each process. Hence, prepare the process() libipa template to
accept a particular IPAFrameContext early on.
As for this patch, we shall pass in the pointer as nullptr, so
that the changes compile and keep working as-is.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The CameraSensorHelper specifies two gain models, linear and
exponential. They are modelled after the MIPI CCS specification. Only
the linear model has been implemented, the exponential model was left
for later.
We now need to support sensors that configure their gain in a hardware
register with a value expressed in dB. This has similarities with the
MIPI CCS exponential gain model, but is only has an exponential factor,
while CCS also allows sensors to support a configurable linear factor.
The full CCS exponential model needs two values (for the linear and
exponential factors) to express a gain, while IPAs use a single linear
gain value internally. However, the exponential gain model example in
the CCS specification has a fixed linear factor, which may indicate that
it could be common for sensors that implement the exponential gain model
to only use the exponential factor. For this reason, implement the
exponential gain model with a fixed linear factor, but with a
sensor-specific coefficient for the exponential factor that allows
expressing the gain in dB (or other logarithmical units) instead of
limiting it to powers of 2 as in the MIPI CCS specification.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
To prepare for other gain models than the linear model, store the gain
constants in a union with per-model members. Due to the lack of
designated initializer support in gcc with C++17, initializing a single
complex structure that includes a union will be difficult. Split the
gain model type to a separate variable to work around this issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The algorithms are using the same function names with specialized
parameters. Instead of duplicating code, introduce a libipa Algorithm
class which implements a base class with template parameters in libipa,
and use it in each IPA.
As we now won't need an algorithm class for each IPA, move the
documentation to libipa, and make it agnostic of the IPA used. While at
it, fix the IPU3::Algorithm::Awb documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Remove the verbose #ifndef/#define/#endif pattern for maintaining
header idempotency, and replace it with a simple #pragma once.
This simplifies the headers, and prevents redundant changes when
header files get moved.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
"weighted", derived from the verb "to weight", comes from Middle English
weight, weiȝte, weght, wight, from Old English wiht, ġewiht, from
Proto-Germanic *wihtiz, from Proto-Indo-European *weǵʰ-. In none of
those does the t come before the h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
The abstract Algorithm class was originally placed in libipa as an
attempt define a generic algorithm container. This was a little
optimistic and pushed a bit far too early.
Move the Algorithm class into the IPU3 which is the only user of the
class, as we adapt it to support modular algorithm components for the
IPU3.
Not documenting the namespace may cause issues with Doxygen in libipa.
The file libipa.cpp is thus created as an empty file for now, but we
can leverage it in the future to add more global libipa documentation,
and possibly code too.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Usage of 'method' to refer to member functions comes from Java. The C++
standard uses the term 'function' only. Replace 'method' with 'function'
or 'member function' through the whole code base and documentation.
While at it, fix two typos (s/backeng/backend/).
The BoundMethod and Object::invokeMethod() are left as-is here, and will
be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Extend the CameraSensorHelper factory with support for the IMX258
sensor found in the Nautilus Chromebook.
The values are read by manually tweaking the IMX258 kernel driver.
The IMX258 kernel driver hints that the sensor may be compatible
with the MIPI CCS specification, as the register set matches.
The values for analog gain constants are obtained by reading the
register indexes, corresponding to the analog gain constants, as
mentioned in MIPI CCS v1.1 specification.
The values have further been confirmed by Dave Stevenson as being
those specified in the datasheet.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Extend the CameraSensorHelper factory with support for an
OV13858 sensor as found in the Soraka Chromebook.
The datasheet states that low 7 bits are fraction bits, so the gain is
calculated as gainCode=128*gain.
According to the formula, it means m0=1 and c1=128.
m1 then has to be 0, and c0=0.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
For various sensor operations, it may be needed to do sensor specific
computations, like analogue gain or vertical blanking.
This commit introduces a new camera sensor helper in libipa which aims
to solve this specific issue.
It is based on the MIPI alliance Specification for Camera Command Set
and implements, for now, only the analogue "Global gain" mode.
Setting analogue gain for a specific sensor is not a straightforward
operation, as one needs to know how the gain is calculated for it.
Three helpers are created in this patch: imx219, ov5670 and ov5693.
Adding a new sensor is pretty straightforward as one only needs to
implement the sub-class for it and register that class to the
CameraSensorHelperFactory.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Headers which must not be exposed as part of the public libcamera API
should include base/private.h.
Any interface which includes the private.h header will only be able to
build if the libcamera_private dependency is used (or the
libcamera_base_private dependency directly).
Build targets which are intended to use the private API's will use the
libcamera_private to handle the automatic definition of the inclusion
guard.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Move the functionality for the following components to the new
base support library:
- BoundMethod
- EventDispatcher
- EventDispatcherPoll
- Log
- Message
- Object
- Signal
- Semaphore
- Thread
- Timer
While it would be preferable to see these split to move one component
per commit, these components are all interdependent upon each other,
which leaves us with one big change performing the move for all of them.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This class will be used at least by AGC algorithm when quantiles are
needed for example. It stores a cumulative frequency histogram. Going from
cumulative frequency back to per-bin values is a single subtraction, while
going the other way is a loop.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Remove everything related to the C API, including ipa_context,
ipa_context_wrapper, and IPAInterfaceWrapper. Also remove relevant
documentation.
ipaCreate() provided by IPA implementations, and createInterface()
provided by IPAModule (wrapper around IPA implementation) both now
return a C++ object IPAInterface instead of struct ipa_context.
Although IPAInterfaceWrapper is the only component of libipa, the
skeleton and build files for libipa are retained.
After converting the C API to the C++-only API, make all pipeline
handlers and IPAs use the new API.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
This is a combination of 21 commits:
---
libcamera: IPAModule: Replace ipa_context with IPAInterface
With the new IPC infrastructure, we no longer need the C interface as
provided by struct ipa_context. Make ipaCreate_() and createInterface()
return IPAInterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: ipa_context_wrapper: Remove ipa_context_wrapper
Since ipa_context has been replaced with custom IPAInterfaces, it is not
longer needed. Remove it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAInterface: remove ipa_context and functions from documentation
Remove all the documentation related to ipa_context and the C IPA API,
as well as the documentation about the functions in the IPAInterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
---
libcamera: IPAInterface: Remove all functions from IPAInterface
Now that all the functions in the IPA interface are defined in the data
definition file and a specialized IPAInterface is generated per pipeline
handler, remove all the functions from the base IPAInterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAInterface: make ipaCreate return IPAInterface
With the new IPC infrastructure, we no longer need the C interface as
provided by struct ipa_context. Make ipaCreate return IPAinterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
---
ipa: remove IPAInterfaceWrapper
As every pipeline has its own proxy, IPAInterfaceWrapper is no
longer necessary. Remove it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
libcamera: IPAProxy: Remove stop() override
Since stop() is part of the IPA interface, and the IPA interface is now
generated based on the data definition file per pipeline, this no longer
needs to be overrided by the base IPAProxy. Remove it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAProxy, IPAManager: Switch to one-proxy-per-pipeline scheme
IPAProxy is changed in two major ways:
- Every pipeline has its own proxy, to support each pipeline's IPA
interface
- IPAProxy implementations always encapsulate IPA modules, and switch
internally for isolation or threaded
The IPAProxy registration mechanism is removed, as each pipeline will
have its own proxy, so the pipeline can pass the specialized class name
of the IPAProxy to the IPAManager for construction.
IPAManager is changed accordingly to support these changes:
- createIPA is a template function that takes an IPAProxy class, and
always returns an IPAProxy
- IPAManager no longer decides on isolation, and simply creates an
IPAProxy instance while passing the isolation flag
Consequently, the old IPAProxy classes (IPAProxyThread and
IPAProxyLinux) are removed. The IPAInterfaceTest is updated to use
the new IPAManager interface, and to construct a ProcessManager as no
single global instance is created anymore.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
---
libcamera: IPAProxy: Add isolate parameter to create()
Since IPAProxy implementations now always encapsulate IPA modules, add a
parameter to create() to signal if the proxy should isolate the IPA or not.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAManager: Fetch IPAProxy corresponding to pipeline
Now that each pipeline handler has its own IPAProxy implementation, make
the IPAManager fetch the IPAProxy based on the pipeline handler name.
Also, since the IPAProxy is used regardless of isolation or no
isolation, remove the isolation check from the proxy selection.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
---
libcamera: IPAManager: add isolation flag to proxy creation
When the IPA proxy is created, it needs to know whether to isolate or
not. Feed the flag at creation of the IPA proxy.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAManager: Make createIPA return proxy directly
Since every pipeline knows the type of the proxy that it needs, and
since all IPAs are to be wrapped in a proxy, IPAManager no longer needs
to search in the factory list to fetch the proxy factory to construct a
factory. Instead, we define createIPA as a template function, and the
pipeline handler can declare the proxy type when it calls createIPA.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAProxy: Remove registration mechanism
Implementations of IPA proxies use a registration mechanism to register
themselves with the main IPA proxy factory. This registration declares
static objects, causing a risk of things being constructed before the
proper libcamera facilities are ready. Since each pipeline handler has
its own IPA proxy and knows the type, it isn't necessary to have a proxy
factory. Remove it to alleviate the risk of early construction.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: proxy: Remove IPAProxyLinux and IPAProxyThread
We have now changed the proxy from per-IPC mechanism to per-pipeline.
The per-IPC mechanism proxies are thus no longer needed; remove them.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
tests: ipa_interface_test: Update to use new createIPA
Update the IPA interface test to use the new createIPA function from
IPAManager. Also create an instance of ProcessManager, as no single
global instance is created automatically anymore. Update meson.build to
to depend on the generated IPA interface headers.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: PipelineHandler: Remove IPA from base class
Since pipeline handlers now have their own IPA interface types, it can no
longer be defined in the base class, and each pipeline handler
implementation must declare it and its type themselves. Remove it from
the base class.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
ipa: raspberrypi: Add mojom data definition file
Add a mojom data definition for raspberrypi pipeline handler's IPAs.
This simplifies the API between the raspberrypi pipeline handler and the
IPA, and is not a direct translation of what was used before with
IPAOperationData.
Also move the enums from raspberrypi.h to raspberrypi.mojom
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: pipeline, ipa: raspberrypi: Use new data definition
Now that we can generate custom functions and data structures with mojo,
switch the raspberrypi pipeline handler and IPA to use the custom data
structures as defined in the mojom data definition file.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: pipeline, ipa: vimc: Support the new IPC mechanism
Add support to vimc pipeline handler and IPA for the new IPC mechanism.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
---
libcamera: pipeline, ipa: rkisp1: Support the new IPC mechanism
Add support to the rkisp1 pipeline handler and IPA for the new IPC
mechanism.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: pipeline, ipa: ipu3: Support the new IPC mechanism
Add support to ipu3 pipeline handler and IPA for the new IPC mechanism.
[Original version]
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
[Fixed commit message and small changes]
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This change allows controls passed into PipelineHandler::start to be
forwarded onto IPAInterface::start(). We also add a return channel if the
pipeline handler must action any of these controls, e.g. setting the
analogue gain or shutter speed in the sensor device.
The IPA interface wrapper isn't addressed as it will soon be replaced by
a new mechanism to handle IPC.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add two new parameters, ipaConfig and result, to the
IPAInterface::configure() function to allow pipeline handlers to pass
custom data to their IPA, and receive data back. Wire this through the
code base. The C API interface will be addressed separately, likely
through automation of the C <-> C++ translation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The IPA headers are installed into $prefix/include/libcamera/ipa/, but
are located in the source tree in include/ipa/. This requires files
within libcamera to include them with
#include <ipa/foo.h>
while a third party IPA would need to use
#include <libcamera/ipa/foo.h>
Not only is this inconsistent, it can create issues later if IPA headers
need to include each other, as the first form of include directive
wouldn't be valid once the headers are installed.
Fix the problem by moving the IPA headers to include/libcamera/ipa/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
