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>
Add an IPADataSerializer which implements (de)serialization of built-in
(PODs, vector, map, string) and libcamera data structures. This is
intended to be used by the proxy and the proxy worker in the IPC layer.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ControlSerializer saves all ControlInfoMaps that it has already
(de)serialized, in order to (de)serialize ControlLists that contain the
ControlInfoMaps. Leverage this to cache ControlInfoMaps, such that the
ControlSerializer will not re-(de)serialize a ControlInfoMap that it has
previously (de)serialized.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
It can be difficult to correctly parse the syntax for copy/move and the
associated assignment operators.
Provide helpers as syntactic sugar to facilitate disabling either the
copy constructor, and copy assignment operator, and the move constructor
and move assignment operator in a way which is explicit and clear.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Extensible concept is a generic Class helper. To prepare for
further class helper additions, move the specific extensible
implementation and header to a more generic class header and source.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The meson custom_target() function accepts a 'depend_files' argument to
list additional dependency files. Files already listed in the 'command'
argument are handled automatically, and don't need to be added manually.
Drop them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The meson.build files mix array declarations with and without a space
after the opening and before the closing square bracket. The vast
majority of cases don't use spaces, so standardize on that.
While it it, fix indentation in a few places.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In preparation for fast colour denoise, set the low resolution ISP
output stream (Output1) to a 1/4 resolution of the application requested
stream (Output0). This only happens if the application has not requested
an additional YUV or RGB stream.
We also constrain this 1/4 resolution to at most 1200 pixels in the
largest dimension to avoid being too taxing on memory usage and system
bandwidth.
Also switch the default StreamRole::VideoRecording to YUV420 to allow
fast colour denoise to run.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Buffers dequeued from the ImgU may not be associated with a Request as
they are internal (statistics, parameters and some RAW buffers). Fetch
the request they are used for from the frame information instead.
Fixes: 9708f49fec ("libcamera: ipu3: Share parameter and statistic buffers with IPA")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Commit 7208e70211 ("libcamera: ipu3: Always use sensor full frame size")
changed the CIO2 configuration procedure to always select the full
sensor resolution to work around an ImgU configuration issue, as
reported in the todo item introduced in said commit.
When capturing a RAW stream only and the ImgU is not involved, the CIO2
has to be configured with the requested stream size to avoid adjusting
the stream to the sensor resolution.
As an example, capturing a raw frame smaller than the sensor resolution
with this patch applied results in the stream configuration to be
correctly assigned.
$ cam -c1 -swidth=1056,height=784,role=raw
ipu3.cpp:207 CIO2 configuration: 1056x784-SGRBG10_IPU3
ipu3.cpp:222 Validating stream: 1056x784-SGRBG10_IPU3
ipu3.cpp:233 Assigned 1056x784-SGRBG10_IPU3 to the raw stream
Without this patch the same operation results in the stream resolution
to be adjusted to the sensor resolution.
$ cam -c1 -swidth=1056,height=784,role=raw
ipu3.cpp:201 CIO2 configuration: 4224x3136-SGRBG10_IPU3
ipu3.cpp:216 Validating stream: 1056x784-SGRBG10_IPU3
ipu3.cpp:227 Assigned 4224x3136-SGRBG10_IPU3 to the raw stream
ipu3.cpp:297 Stream 0 configuration adjusted to 4224x3136-SGRBG10_IPU3
Camera configuration adjusted
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Report the crop region for every completed request.
The crop region is initialized as the sensor's analogue crop
rectangle and updated when a Request with a new region completes.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Use the IPU3Frames helper to share parameters and statistics buffers
with the IPA. Track which parameter and statistic buffer is used for
which request and make sure the parameter buffers is filled in by the
IPA before it's needed and that the statistic buffer is consumed and
meta data generated before completing the request.
With this change the IPU3 pipeline is prepared to fully operate with an
IPA component.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add a helper class to aid in associating a parameter and statistic
buffer with each request queued to the pipeline. The helper helps with
tracking the state of the extra buffers and in completing the request
once all extra processing is done.
This change only adds the helper more work is needed to integrate it
with the pipeline and an IPA.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Attach to the IPA and allow it to push V4L2 controls that apply to the
camera sensor. The IPA is not fully integrated in the pipeline as
statistics and parameters buffers are not yet allocated, processed by
the IPA nor queued to the hardware.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
When adding IPA plumbing to the IPU3 pipeline handler it will be needed
to track which raw buffer was queued to the CIO2 for a specific request.
Currently if using an internally allocated raw buffer the FrameBuffer is
not exposed outside the CIO2Device as it was not needed. Prepare for the
IPA by exposing which internal raw buffer is picked for each request,
later changes will associate this with a Request.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add the parameters video device to the data structure of the ImgUDevice.
Even if the video device is configured, prepared to import buffers and
started no buffers are ever queued to it so it does not yet effect the
capture. Nor is does this change hinder the current capture mode to
function.
This is done in preparation to attach an IPA to the IPU3 pipeline.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
There is no reason to expose and call a separate configureStat() when
the statistics video device can be configured with the exact same
parameters as part of configure(). Move the configuration internally to
the ImgUDevice simplifying the interface, there is no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add a utils::reverse() function that creates an adapter wrapping in
iterable, such that range-based iteration over the adapter iterates over
the iterable in reverse order.
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 presence of mandatory and optional controls is checked in
CameraSensor::validateSensorDriver() by trying to retrieve them. This
causes an error message to be printed in the V4L2Device class if an
optional control isn't present, while this isn't an error.
To fix this, use the control idmap reported by the V4L2Device to check
for controls availability. The function can now print the whole list of
missing controls, making debugging easier.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
YUV sensors don't provide the necessary information to fill
CameraSensorInfo, as they include an ISP and provide a higher-level API
that doesn't always expose low-level information. The CameraSensor class
makes low-level V4L2 controls mandatory for all sensors, which prevents
usage of YUV sensors with the simple pipeline handler.
Make CameraSensor::sensorInfo() available for raw sensors only. This
won't introduce any regression in pipeline handlers that currently use
the sensorInfo() function as they all operate with raw sensors, and
won't be a limitation for the simple pipeline handler as well as it
doesn't use sensor info. If part of the sensor info (such as the active
pixel array size for instance) becomes useful to expose for YUV sensors
in the future, the sensorInfo() function can be extended to report that
information only and skip data that is only available for raw sensors.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The Bayer pattern is retrieved based on the media bus formats supported
by the sensor, when registering camera sensor properties. To prepare for
its usage elsewhere in the CameraSensor class, store it in a private
member variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Sensor frame length is made up of active and inactive (blanking) lines.
The minimum and maximum frame length values may be used by pipeline
handlers to limit frame durations based on the sensor mode capabilities.
Store the minimum and maximum allowable frame length values (in lines)
in the CameraSensorInfo structure. These values are computed in
CameraSensor::sensorInfo() by querying the sensor subdevice
V4L2_CID_VBLANK control limits. This in turn means that V4L2_CID_VBLANK
is now a mandatory subdevice control.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fixup logic when handling IPA_RESULT_SENSOR_PARAMS where we must always
overwrite the parameters if provided by IPA. In the current codebase,
this only happens once on startup, so there is no effective functional
difference. But this change allows the option for the IPA to request new
sensor parameters per-mode if required.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To transpose a BayerFormat means to flip it over its main diagonal.
For example:
G B G R
->
R G B G
The main diagonal goes from the top left to the bottom right. This
means, that the only two orders affected by a transpose are GBRG & GRBG.
When a transpose is used in combination with horizontal and/or vertical
flips it is performed after the flips. Therefore add the functionality
by switching GBRG (index 1) with GRBG (index 2), after the flips have
been applied.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Enable to test two Bayer formats for equality by checking if the order
of the color channels, the bit depth of the pattern, and the packing
scheme match. Additionally, add the reverse operation (!=), which negates
the equality test result.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The new `fromV4l2PixelFormat` static member function renders an old
BayerFormat constructor useless, remove it together with the
`v4l2ToBayer` mapping table. The new function searches for a matching
mapped value instead of a matching key, therefore the `bayerToV4l2`
table is sufficient.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add a static member function to get the corresponding BayerFormat from a
given V4L2PixelFormat. The motivation behind this patch is to align the
overall structure of the BayerFormat class with other parts of the code
base, such as the V4L2PixelFormat class.
The downside of this change is a slightly worse time complexity, but
the upside is a smaller codebase and lower memory consumption. As the
function is probably not used very frequently, I tend to favor the
mentioned upsides.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
QUERYBUF doesn't require the memory field to be pre-filled.
Also, V4L2VideoDevice::createBuffer uses dmabuf file descriptors, thus
using V4L2_MEMORY_MMAP makes things confusing, so remove it.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The current logging to track the status of a Request when running the
Android camera HAL provide the following information:
When a Request is queued to libcamera:
HAL camera_device.cpp:1776 '\_SB_.PCI0.I2C2.CAM0': Queueing Request to libcamera with 1 HAL streams
When a Request completes:
Request request.cpp:268 Request has completed - cookie: 138508601719648
The queueing of a Request reports the number of streams it contains
while the completion of a Request reports the address of the associated
cookie.
This makes very hard to keep track of what Requests have completed, as
the logging associated with a queue/complete event does not allow to identify
a Request easily.
Add two more printouts to make it easier to track a Request life cycle.
To make it possible to print the Request cookie in the CameraDevice
class add a method to access it from the CameraRequest class.
The result looks like the following trace:
Request request.cpp:92 Created request - cookie: 140701719392768
HAL camera_device.cpp:1710 '\_SB_.PCI0.I2C2.CAM0': Queueing request 140701719392768 with 1 streams
HAL camera_device.cpp:1747 '\_SB_.PCI0.I2C2.CAM0': 0 - (4160x3104)[0x00000023] -> (4160x3104)[NV12] (direct)
...
Request request.cpp:268 Request has completed - cookie: 140701719392768
HAL camera_device.cpp:1800 '\_SB_.PCI0.I2C2.CAM0': Request 140701719392768 completed with 1 streams..
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
When moving the pipeline away from the Timeline design it was discovered
that the design of queuing the buffers to the device as soon as possible
was not the best idea. The parameter buffers were queued to the device
before the IPA had processed them and this violates the V4L2 API.
Fix this by waiting to queue any buffer to the device until the IPA has
filled in the parameters buffer.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
There are no users left of the Timeline and there is no longer a need to
keep emulating a start of exposure event as the CSI-2 resciver reports
it. Remove the Timeline helper and what's left of it's integration in
the pipeline.
There is no functional change as nothing i the pipeline uses the
Timeline.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In the Timeline approach the idea was to delay queuing buffers to the
device until the IPA had a chance to prepare the parameters buffer. A
check was still added to warn if the IPA queued buffers before the
parameters buffer was filled in.
This check happened much sooner then needed as the parameter buffers
does not have to be ready when the buffer is queued but just before it's
consumed. As the pipeline now has true knowledge of each SOF we can move
the check there and remove the delaying of queuing of buffers.
This change really speeds up the IPA reactions as the delays used in the
Timeline where approximated while with this change they are driven by
events reported by the device.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Instead of setting controls using the RkISP1 local Timeline helper use
the DelayedControls. The result is the same, the controls are applied
with a delay.
The values of the delays are however different between the two methods.
The values used in the Timeline solution were chosen after some
experimentation and the values used in DelayedControls are taken from a
generic sensor. None of the two are a perfect match as the delays can be
different for different sensors used with the pipeline.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
