In raw mode the number of configurations is actively limited to 1. It is
therefore safe to move isRaw up one level to simplify the code and
prepare for later use.
During that rework it was noticed that the old code actually has a bug
in that it reduces the number of configurations to 1 in case a raw
config is found, but it doesn't reduce the config vector to that raw
config, but the first config.
Change that behavior to check the first config and either remove all
remaining configs if the first is raw or drop all raw configs if the
first is non-raw.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The dewarper integration into the rkisp1 pipeline is quite complicated.
Simplify that by switching to the now available ConverterDW100Module. As
there is no other known converter in combination with the rkisp1 ISP this
is a safe step to do.
This change also paves the way to implement dw100 specific features later.
The input crop implemented in the dw100 kernel driver is quite limited
in that it doesn't allow arbitrary crop rectangles but only scale
factors quantized to the underlying fixed point representation and only
aspect ratio preserving crops.
The vertex map based implementation allows for pixel perfect crops. The
only downside is that ScalerCrop can no longer be set dynamically on
older kernels. A corresponding warning is already implemented in the
converter module.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When the dewarper is used, an addition buffer loop with
kRkISP1MinBufferCount buffers is created between ISP and dewarper. When
the dewarper is configured, it stores the bufferCount value of the
requested stream configurations. This number of buffers is then imported
when the dewarper is started.
On the input stream of the dewarper the bufferCount is currently left
unchanged, meaning it carries the bufferCount as supplied by the user
instead of the bufferCount of the additional loop. Fix that by setting
the bufferCount to kRkISP1MinBufferCount.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In order to allow digital zooming, scale down in the dewarper instead of
the resizer. That means forwarding the full sensor size data to the
dewarper. The ScalerCrop rectangle will also be applied at the dewarper.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The decision if the dewarper shall be used is not per pipeline but per
camera and per configuration (raw streams can't use it). Move the
corresponding flag into the camera data class. Rename the flag to
"usesDewarper" which is easier understand when we later add the ability
to enable/disable the dewarper on a per camera basis which will be
expressed using a "canUseDewarper" flag.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In case the buffer returned from the ISP was canceled, the upstream
buffer was not correctly marked as canceled. Move the cancel
functionality into an own helper function and correctly cancel the
upstream buffers. Add missing cancellation in case queuing to the
dewarper fails.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
With the upcoming addition of V4L2 requests support, the converters need
to keep a handle to the corresponding media device.
Prepare for that by changing the constructor parameter from a raw
pointer to a shared pointer.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Adapt the PipelineHandler::acquireMediaDevice() support function to
return a shared pointer instead of the underlying raw pointer.
Propagate this update to all pipeline handlers that use the MediaDevice
and store a std::shared_ptr<MediaDevice> accordingly.
This is required to support media devices that are potentially shared
among multiple pipeline handlers, like a dewarper implemented as v4l2
m2m device.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Virtual pipeline handler should provide colorSpace in
generateConfiguration() and validate the colorspace in validate().
It is mandatory for a pipeline handler to set the colorspace if it
is unset in the stream configuration, during validate().
For choosing the colorspace for the generated NV12 frames, following
points have been taken into account:
- The transfer function should be Rec.709 for NV12
- The YCbCr encoding has been chosen Rec.709 as it is the most common
than Rec.601/Rec.2020
- Range should be 'Limited' as with the NV12 pixel format.
Hence, the closest colorspace match is ColorSpace::Rec709 which is
set for the virtual pipeline handler.
Signed-off-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Robert Mader <robert.mader@collabora.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Bayer pattern on the sensor can change while configuring it with the
intended capture format. This is due to the transform being applied on
the sensor which supports [v/h]flips.
During configure(), the simple pipeline handler does not detect any
bayer pattern changes that can arise due to the transformations being
applied via SimpleCameraData:setupFormats(). In such cases, the video
node will be configured in-correctly, without realising the bayer
pattern has changed on the sensor, for the given capture format.
This patch detects the bayer pattern change after the sensor has
been configured and retrieves the corresponding V4L2 pixel format
to correctly configure the video node and the input to converter or
Soft-ISP.
Signed-off-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Tested-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
StreamConfiguration's should have colorSpace set. This is not the case
in the simple pipeline. Let's set it there. This also fixes a crash in
`cam' due to accessing an unset colorSpace.
We set the colour spaces according to the pixel format. This is not
completely correct because pixel formats and colour spaces are
different, although not completely independent, things. But for the
lack of a better practical option to determine the colour space, we use
this.
Closes: https://gitlab.freedesktop.org/camera/libcamera/-/issues/294
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Simple Pipeline is designed to support a wide variety of pipeline
configurations and attached devices and will enumerate the pixel formats
of the connected sensors to map these to libcamera formats where
available.
In fixed pipelines, where the pixel format is not mapped correctly it is
a desired behaviour to express this warning so that the pixelformat can
be added, while in the simple-pipeline case we do not expect warnings
for every discovered pixel format which is not supported by libcamera.
This currently manifests itself as very highly verbose warnings about
unsupported pixel formats are not desired when there are working formats
that have already been enumerated.
Fortunately in commit 434edb7b44 ("libcamera: formats: Fix warning for
unknown V4L2 pixfmt") we have a mechanism to disable the warning for
occasions where we wish to ignore unsupported formats.
Use this feature to disable the warning in the core V4L2PixelFormat and
instead report only a debug level print from the simple pipeline
handler.
On devices such as the Pinephone, this removes overly verbose warnings
for tiled YUV formats:
[0:06:39.291083146] [1922] ERROR SimplePipeline simple.cpp:1600 No valid pipeline for sensor 'gc2145 0-003c', skipping
[0:06:39.302229740] [1922] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format HM12
[0:06:39.302779117] [1922] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format HM12
[0:06:39.303417578] [1922] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format HM12
[0:06:39.303928998] [1922] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format HM12
[0:06:39.304615751] [1922] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format HM12
Closes: https://gitlab.freedesktop.org/camera/libcamera/-/issues/291
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Fixes behavior when calling 'cam -l' during a live stream from a camera
in another process.
Issue is that multiple process should be able to list (match procedure)
the camera supported. But only the unique process that lock the media
devices in order to be able to configure then start the pipeline should
setup the routes, graphs, etc.
Thus, the setRouting() is to be moved to a PipelineHandlerISI::acquireDevice()
implementation to override the default Pipeline::acquireDevice() function.
Fixes: 92df79112f ("pipeline: imx8-isi: Add multicamera support")
Signed-off-by: Andrei Gansari <andrei.gansari@nxp.com>
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
For debugging purposes, threads can be assigned a name, which eases
distinguishing between them in e.g. htop or gdb. This uses a
Linux-specific API for now which is limited to 15 characters (+ null
terminator), so truncation is done and names for existing thread
instantiations were chosen to be consise.
[Kieran: Apply checkstyle suggestions, rebase on proxy rework]
Signed-off-by: Schulz, Andreas <andreas.schulz2@karlstorz.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The DelayedControls class works around a limitation of the V4L2 controls
API by assigning to controls that modify the limits of other controls a
'priority' flag.
'Priority' controls are written to the device before others to make sure
the limits of dependent controls are correctly updated.
A typical example of a priority control is VBLANK, whose value changes the
limits of the EXPOSURE control. This doesn't apply to a specific hardware
platform but to all V4L2 sensors.
The RkISP1 pipeline handler doesn't mark VBLANK as a priority control, an
issue which might result in the exposure being clamped to an outdated frame
length.
Fix the rkisp1 pipeline by marking VBLANK as a priority control.
Fixes: f72c76eb6e ("rkisp1: Honor the FrameDurationLimits control")
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
When a converter or the software ISP is used, output sizes do not equal
input sizes - they notably can be smaller.
Previous to this patch only capture sizes were considered, in some cases
resulting in configs with too small maximum output sizes being selected,
such as 1912x1080 for stream sizes of 1920x1080.
Check that the maximum output sizes are big enough instead, while continuing
to minimize capture sizes.
Closes: https://gitlab.freedesktop.org/camera/libcamera/-/issues/236
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Acked-by: Umang Jain <uajain@igalia.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Using auto variables for simple types reduces readability. Spell out
unsigned int explicitly here, and replace the <= 0 check with a zero
check now that the explicit type shows the value can't be negative.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
While a default value of 4 buffers appears to be a good default that is
used by other pipelines as well, allowing both higher and lower values
can be desirable, notably for:
1. Video encoding, e.g. encoding multiple buffers in parallel.
2. Clients requesting a single buffer - e.g. in multi-stream scenarios.
Thus allow buffer counts between 1 and 32 buffers - following the default
maximum from vb2 core - while keeping the default to the previous 4.
While on it mark the config as adjusted when appropriate.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Simple Pipeline handler supports a variety of hardware with
different capabilities and performances.
To improve performance and reliability of the cameras across the
supported range, increase the number of internal buffers to 4.
This allows lower performance devices more opportunity to process the
frames and increases stability.
Align the Simple Pipeline handler and Soft ISP buffering with the other
hardware based platforms and use 4 internal buffers.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Currently the virtual pipeline generates the images synchronously. This is not
ideal because it blocks the camera manager's internal thread, and because its
behaviour is different from other existing pipeline handlers, all of which
complete requests asynchronously.
So move the image generation to a separate thread by deriving `VirtualCameraData`
from `Thread`, as well as `Object` and using the existing asynchronous signal
and method call mechanism.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch allows enabling or disabling software ISP via config file in
addition to compile time. This can be useful for software ISP testing
on various platforms as well as for overriding the defaults in case the
defaults don't work well (e.g. hardware ISP may or may not work on
i.MX8MP depending on the kernel and libcamera patches present in the
given system).
The configuration is specified as follows:
configuration:
pipelines:
simple:
supported_devices:
- driver: DRIVER-NAME
software_isp: BOOLEAN
- ...
For example:
configuration:
pipelines:
simple:
supported_devices:
- driver: mxc-isi
software_isp: true
The overall configuration of enabling or disabling software ISP may get
dropped in future but this patch is still useful in the meantime.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Query the params device for RKISP1_CID_SUPPORTED_PARAMS_BLOCKS and
inject the information into the IPA hardware context for use by the
algorithms.
To be able to modify the hardware configuration at runtime, replace the
pointer with an instance and create a copy of the static hardware
specific data.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When the extensible parameters queued to the kernel contain an unknown
block type it fails with -EINVAL. This should not happen as user land is
supposed to check for the supported parameter types. But it took a while
to figure out where things went wrong. Add a error statement when
queuing of the parameter buffer fails for whatever reason.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In current implementation, the sink pad counter of the crossbar is not
incremented if the pad is not connected to any subdevice. This would lead
to incorrect routing and format configuration if CSI is not connected
to first sink pad.
To avoid such issue, every sink pads must be taken into account. Then if
CSI and sensor are present, current counter is used for routing at match(),
and stored in camera data to be reused during configure().
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Tested-by: Pavel Löbl <pavel@loebl.cz>
Tested-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
There is no reason to allocate the frame info objects dynamically,
and then store raw pointers in the `std::map` in the rkisp1
and ipu3 pipeline handler.
Instead, store the objects directly in the map. This removes
the need for manually calling new/delete, simplifies the code,
and eliminates one memory allocation per frame.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Top-level `const` qualifiers are not useful, so avoid them. This is done
either by simply removing the top-level `const`, or making the function
return a reference to const where that is appropriate.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Header comment blocks used to contain the file name. Considered as
useless information, the names have been removed, with the last ones
supposed to be dropped in commit d3bf27180e ("libcamera: Drop
remaining file names from header comment blocks"). A few have however
been forgotten, and more crept back since. Remove them.
While at it, fix one typo in a header comment block by replacing
'MaliC55 with Mali-C55', and add a missing blank line in
src/ipa/rpi/pisp/pisp.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
The match() function currently reports that it is not possible to create
any cameras if it encounters an empty media graph.
Fix this by looping over all media graphs and only returning false when
all of them fail to create a camera.
It is worth noting that an issue does exist when on a partial match that
ends in an invalid match, any media devices that were acquired will stay
acquired. This is not a new issue though, as any acquired media devices
in general are not released until pipeline handler deconstruction. This
requires a rework of how we do matching and pipeline handler
construction, so it is captured in a comment.
In the meantime, this fix fixes a problem without increasing the net
number of problems.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Hui Fang <hui.fang@nxp.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
ISI can be used to support multiple cameras at the same time in the media
device. A dedicated pad is assigned to each camera by HW (dts). We then
assign one (or more) source pad(s) depending on ISI constraints in the SoC.
Since ISI may have different number of pipes depending on SoC, the number
of cameras is computed _before_ going through all pipeline's components,
to limit number of pipes that could be assigned to a camera.
For instance, 3 is targeted as maximum amount of streams per camera as
defined by 'kNumStreams' constant. If 2 cameras are connected, with
only 5 ISI pipes, this target cannot be achieved. In such case, 2 streams
are assigned to each camera.
On the other hand, if ISI has 8 source pads (from index 6 to 13) and 2
cameras, first three source pads [6:8] are assigned to first camera, and
the three next source pads [9:11] are assigned to the second camera. All
these pads (sink and sources) must have same format to prevent configuration
mismatch during start.
However, since ISI routing must be performed _before_ any stream becomes
active, 'setRouting' is now executed during the 'match' step, instead of
'configure'. Indeed, it is up to the application to decide when a camera
'start' is executed: this could happen before or after the other camera
configuration is executed. Moving routing into the 'match' step makes sure
the routing is correctly applied before any 'start' is executed.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch adds number of streams per camera as constructor parameter, and
limits stream count to 3. Some applications may need up to 3 streams for
preview + capture + video record. Currently, imx8-isi pipeline only supports
up to 2. Increase constant parameter to 3 to match these applications'
requirements.
Minimum value between default value 3, and total amount of ISI's pipes is
now applied. For SOCs which only have 1 ISI pipe (ie i.MX93), available
stream count becomes 1.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The mali-c55 pipeline handler currently looks for a media entity with
the function MEDIA_ENT_F_IO_V4L to recognise a memory input subdevice.
This is apparently intended for video device entities, and we should
be looking for MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER. Correct the
entity function that the pipeline handler looks for.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
At the moment the mali-c55 pipeline handler sets bytesused for a
buffer to be the maximum possible size (i.e. the size of a struct
mali_c55_params_buffer). This is not really in keeping with the goal
of the extensible parameters formats, and will not work with the new
framework for those formats. Update the IPA module and pipeline
handler to set bytesused to the size of the parameters that were
actually supplied rather than the maximum possible size.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Currently the rkisp1 pipeline handler relies on bufferCount to decide on
the number of parameter and statistics buffers to allocate internally.
Instead, the number of internal buffers should be the minimum required
by the pipeline to keep the requests flowing, in order to avoid wasting
memory.
Stop relying on bufferCount for these numbers and instead set them to
kRkISP1MinBufferCount.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
The StreamConfiguration::bufferCount is reset to a hardcoded value of 4
in RkISP1Path::validate(). Keep the minimum value of 4 but do not reset
it, if it was set to a larger value. This allows the user to set
bufferCount to an arbitrary number of buffers which then can be
allocated for example by the FrameBufferAllocator. If the bufferCount is
set to a smaller value it gets reset to kRkISP1MinBufferCount again and
the configuration is marked as adjusted.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Tested-by: Sven Püschel <s.pueschel@pengutronix.de>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
To keep the regulation of the algorithms as fast as possible and at the
same time allow more buffers to be allocated, limit the amount of
buffers that get queued into the device to the pipeline depth plus a
tiny margin.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Sven Püschel <s.pueschel@pengutronix.de>
Reviewed-by: Umang Jain <uajain@igalia.com>
Since 6cf9c4d34f ("pipeline: ipa: rpi: Split RPiCameraData::dropFrameCount_")
the initial n frames are not dropped anymore. So clearing the request metadata
should not be necessary anymore, remove it.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
`SensorTimestamp` and `FrameWallClock` should always be available. However,
if that ever changes or they are not available for some unforeseen reason,
setting them to 0 is not ideal. That makes it more complicated for the
application to detect these cases (since they have to check the existence
either way), and if an application blindly assumes e.g. that `SensorTimestamp`
is monotonically increasing, then receiving a timestamp of 0 will likely
cause issues.
So simply omit them from the request metadata if they are not available.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Use nanoseconds for the FrameWallClock control to match the units for
other timestamp controls, including SensorTimestamp.
Update the RPi pipeline handlers to match the new nanoseconds units when
converting from SensorTimestamp to FrameWallClock.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Stefan Klug
Kieran Bingham
Umang Jain
Milan Zamazal
Barnabás Pőcze
Andrei Gansari
Schulz, Andreas
Jacopo Mondi
Robert Mader
Laurent Pinchart
Hans de Goede
Antoine Bouyer
Paul Elder
Daniel Scally
Nícolas F. R. A. Prado
Naushir Patuck