Commit graph

2829 commits

Author SHA1 Message Date
Naushir Patuck
1be6803924 libcamera: delayed_controls: Add missing documentation for ControlParams
Document struct DelayedControls::ControlParams and its associated
fields.

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>
2021-03-13 21:47:18 +02:00
Marian Cichy
80bebfb64e libcamera: gst: Fix double-free when acquire_buffer fails
If gst_buffer_pool_acquire_buffer in gst_libcamera_task_run fails, the
unique_ptr to the request-object gets reset and hence, its destructor
is called. However, the wrap-object points to the same object and is
still alive at this moment. When the task_run-function is finished, the
destructor of the wrap-object is called, which in return calls the
destructor of the request-object again.

Instead of taking care of both, the request and the wrap-object, we can
move the request to the wrap which will then effectively take care of
the request object automatically.

Signed-off-by: Marian Cichy <m.cichy@pengutronix.de>
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
2021-03-12 22:38:15 +02:00
Naushir Patuck
a940866440 libcamera: delayed_controls: Fix off-by-one error in get()
There was an off-by-one error in DelayedControls::get() when picking
controls from the queue to return back to the pipeline handler.
This is only noticeable as small oscillations in brightness when closely
viewing frame while AGC is running. The old StaggeredCtrl did not show
this error as the startup queuing mechanism has changed in
DelayedControls.

Fix this by indexing to the correct position in the queue.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reported-by: David Plowman <david.plowman@raspberrypi.com>
Fixes: 3d4b7b0059 ("libcamera: delayed_controls: Add helper for controls that apply with a delay")
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-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>
2021-03-12 14:12:55 +00:00
Naushir Patuck
47e27ee93b libcamera: delayed_controls: Remove spurious no-op queued controls
In DelayedControls::applyControls(), the controls queue would be
extended via a no-op control push to fill the intermittent slots with
unchanged control values. This is needed so that we read back unchanged
control values correctly on every frame.

However, there was one additional no-op performed on every frame that is
not required, meaning that any controls queued by the pipeline handler
would have their write delayed by one further frame. The original
StaggeredCtrl did not do this, as it only had one index to manage,
whereas DelayedControls uses two.

Remove this last no-op push so that the pipeline_handler provided
controls would be written on the very next frame if possible. As a
consequence, we must mark the control update as completed within the
DelayedControls::applyControls() loop, otherwise it might get reused
when cycling through the ring buffer.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reported-by: David Plowman <david.plowman@raspberrypi.com>
Fixes: 3d4b7b0059 ("libcamera: delayed_controls: Add helper for controls that apply with a delay")
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-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>
2021-03-12 14:12:55 +00:00
Naushir Patuck
f1569db3fb libcamera: delayed_controls: Remove unneeded write when starting up
On DelayedControls::reset(), the values retrieved from the sensor device
were added to the queues with the updated flag set to true. This would
cause the helper to write out the value to the device again on the first
DelayedControls::applyControls() call. This is unnecessary, as the
controls written are identical to what is stored in the device driver.

Fix this by explicitly setting the update flag to false in
DelayedControls::reset() when adding the controls to the queue.

Additionally, use the Info() constructor when adding items to the queue
for consistency.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Fixes: 3d4b7b0059 ("libcamera: delayed_controls: Add helper for controls that apply with a delay")
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-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>
2021-03-12 14:12:55 +00:00
Naushir Patuck
96c0eb338e libcamera: delayed_controls: Add notion of priority write
If an exposure time change adjusts the vblanking limits, and we set both
VBLANK and EXPOSURE controls through the VIDIOC_S_EXT_CTRLS ioctl, the
latter may fail if the value is outside of the limits calculated by the
old VBLANK value. This is a limitation in V4L2 and cannot be fixed by
setting VBLANK before EXPOSURE in a single VIDIOC_S_EXT_CTRLS ioctl.

The workaround here is to have the DelayedControls object mark the
VBLANK control as "priority write", which then write VBLANK separately
from (and ahead of) any other controls. This way, the sensor driver will
update the EXPOSURE control with new limits before the new values is
presented, and will thus be seen as valid.

To support this, a new struct DelayedControls::ControlParams is used in
the constructor to provide the control delay value as well as the
priority write flag.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Fix up trivial comments, merge conflicts]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-12 14:12:32 +00:00
Nicolas Dufresne
6795ffe67f gst: pool: Fix GstBuffer leak on error
We borrowed a GstBuffer from the pool, if preparing the buffer failed,
we need to push it back to avoid leaking it.

Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-12 00:46:07 +02:00
Nicolas Dufresne
488bbe40a9 gst: provider: Fix crash in finalize
Both the DeviceProvider and Device classes had the same mistake,
calling G_OBJECT_GET_CLASS() instead of G_OBJECT_CLASS() when
chaining their finalize call to their base class. This would
crash at destruction, which was causing gst-device-monitor-1.0
tool to crash and application using that API to crash too.

Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-12 00:40:05 +02:00
Dafna Hirschfeld
e32d33b11d ipa: rkisp1: Fail on init if hw revision is not RKISP1_V10
In kernel 5.11 the rkisp1 uapi had changed to support different hardware
revisions. Currently only revision 10 is supported by the rkisp1 IPA and
therefore 'init' should fail if the revision is not 10.

This changes depends on the kernel driver reporting the hardware
revision, and thus requires the rkisp1 driver from v5.11 or newer.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-11 02:13:28 +02:00
Dafna Hirschfeld
f4fe8cf588 ipa: rkisp1: Return error from IPA's configure method if it fails
The IPA of rkisp1 relies on some of the camera's controls.
Therefore it can't work if those controls are not given.
Return -EINVAL from 'configure' in that case.
Also return error from the pipeline's 'configure' method
if the IPA configure fails.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.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>
2021-03-11 02:13:28 +02:00
Dafna Hirschfeld
3b338aa5e7 libcamera: media_device: Add hwRevision method
Add a method 'hwRevision' to return the
info.hw_version reported by the driver.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.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>
2021-03-11 02:13:27 +02:00
Paul Elder
d3cf0fed3e android: jpeg: exif: change GPS method encoding from ASCII to NoEncoding
According to the EXIF specification, the GPS method should be UNDEFINED,
and the first 8 bytes will designate the type. However, CTS expects the
first 8 bytes to be part of the data. Remove the 8-byte encoding
designator by changing the encoding to NoEncoding to appease CTS.

This is part of the fix that allows the following CTS test to pass:
- android.hardware.cts.CameraTest#testJpegExif

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-10 12:30:51 +09:00
Paul Elder
a3c9718cfc android: jpeg: exif: Fix setGPSLocation longitude
There was a copy-paste error that caused the latitude to be set twice and
the longitude never. Fix this.

This is part of the fix that allows the following CTS test to pass:
- android.hardware.cts.CameraTest#testJpegExif

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-10 12:30:42 +09:00
Paul Elder
4c0b6c6bd1 android: jpeg: exif: Simplify setGPSDateTimestamp and setGPSDMS
Now that setRational() supports setting multiple rational values, use
that in setGPSDateTimestamp and setGPSDMS which previously set every
rational manually.

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-10 12:30:23 +09:00
Paul Elder
fd3faf7b60 android: jpeg: exif: Fix and expand setRational
setRational was not working properly for EXIF tags in the GPS IFD due to
libexif not supporting those tags in exif_entry_initialize().  Manually
specify the size of the EXIF entry to fix this. While at it, add support
for setting multiple rationals, as that is a common use case for
rational EXIF tags.

As Rational types are no longer initialized by libexif directly, the
EXIF_TAG_{X,Y}_RESOLUTION exif tags will not have their default values
populated.

This allows the GPS altitude to be set properly, and is part of the fix
to allow the following CTS test to pass:
- android.hardware.cts.CameraTest#testJpegExif

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-10 12:30:23 +09:00
Jacopo Mondi
eb5a9d822f android: camera_device: Generate template for Video
The capture request template for video recording use cases requires
a fixed FPS range. Generate the request templates for the VIDEO_RECORD
and VIDEO_SNAPSHOT capture intents using the preview template and
updating the supported FPS range.

This change fixes the CTS tests
android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceRecordingTemplate

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 09:00:23 +01:00
Jacopo Mondi
f179616ec7 android: camera_device: Fail template on no FPS range
The camera supported FPS range is crucial to distinguish between
capture templates for preview and video recording. If the pipeline
handler did not specify an available FPS range by registering the
controls::FrameDurations property so far the control was simply not
added to the generated capture template.

In order to prepare to generate templates for video recording which
require a fixed FPS range, fail earlier in generating any template at
all if the available FPS range is not provided by the Camera.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:59:25 +01:00
Jacopo Mondi
2c34991d16 android: camera_device: Refuse unsupported templates
The current implementation of constructDefaultRequestSettings()
returns the same capture template for all the capture intent.

As the correctness of the generated template is verified by CTS it
is better to return an error for unsupported capture use cases.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:59:02 +01:00
Jacopo Mondi
d150860129 android: camera_device: Return AE FPS range
The result metadata reports an arbitrary {30, 30} FPS range for the
AE algorithm.

The actual FPS range should be returned in the Request::metadata, but
as libcamera currently does not support that feature temporarily work
around the issue and return the FPS range requested by the camera
framework.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:57:53 +01:00
Jacopo Mondi
238fb27911 android: camera_device: Use AE FPS range in template
The request template returned by requestTemplatePreview() uses an
arbitrary {15, 30} Auto-Exposure algorithm FPS range. Use the one
calculated at static metadata creation time, which is consistent with
the camera limits.

Once template generation will be performed inspecting the requested
capture intent, the FPS range over which the AE algorithm can range
shall be tuned accordingly.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:57:36 +01:00
Jacopo Mondi
edd4b1dab2 android: camera_device: Compute frame durations
Use the FrameDuration control reported by pipeline handlers to register
the Auto-Exposure routine FPS range, the minimum stream frame durations
and the sensor maximum frame duration.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:57:09 +01:00
Jacopo Mondi
02a1186536 libcamera: ipu3: Register FrameDurations control
Register the FrameDurations control in the IPU3 pipeline handler
computed using the vertical blanking limits and the sensor
pixel rate as parameters.

The FrameDurations control limits should be updated everytime a new
configuration is applied to the sensor.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:54:54 +01:00
Jacopo Mondi
cbd4617a09 libcamera: ipu3: Initialize controls using sensor resolution
The controls' limits initialized by the IPU3 pipeline handler depend
on the sensor configuration. In order to compute controls using a known
state apply to the sensor a configuration equal to its own resolution.

Move the \todo note regarding the controls' limits dependency on the
sensor configuration at the beginning of the function and remove the
other redundant ones in the function body.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09 08:53:39 +01:00
Paul Elder
45ebe9a209 ipa: raspberrypi: Use direct return value for configure()
Now that we support returning int directly in addition to other output
parameters, improve the configure() function in the raspberrypi IPA
interface.

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-09 11:49:23 +09:00
David Plowman
3a59555414 ipa: raspberrypi: Rename vblank field in SensorConfig to vblankDelay
The name vblankDelay is clearer.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-09 00:55:18 +02:00
David Plowman
8f3a54ae6a ipa: raspberrypi: Add support for imx290/imx327 sensors
imx290 and imx327 share the same kernel driver (imx290.c) and are
therefore both recognised here as "imx290". We add the necessary
CamHelper for these sensors, as well as a camera tuning file.

The tuning was done with an Innomaker STARVIS IMX327LQR module. These
have no IR cut filter so there is no proper colour tuning. However,
you should obtain reasonable results for most modules using this
sensor. Specific tunings for further modules can always be added
subsequently.

To use this sensor on the Raspberry Pi platform, please add

dtoverlay=imx290,clock-frequency=74250000

into your /boot/config.txt file.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-09 00:54:23 +02:00
David Plowman
18691c538b ipa: raspberrypi: Make CamHelpers return the frame delay for vblanking
For some sensors (e.g. imx477) we need to update the vblanking on the
frame before the exposure. For this reason the GetDelays method must
also return the number of frame delays for the vblanking control.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-09 00:50:42 +02:00
Jacopo Mondi
f484857994 libcamera: camera_sensor: Cap resolution to max frame size
Since commit 96aecfe365 ("libcamera: camera_sensor: Use active area
size as resolution") the CameraSensor::resolution() method returned the
sensor's active pixel area size.

As the CameraSensor::resolution() method is widely used in the library
code base to retrieve the maximum frame size the sensor can produce,
in case it is smaller than the pixel area size the returned size cannot
be used to configure the sensor correctly.

Fix this by returning the maximum frame resolution the sensor can
produce, or the pixel area size in case the sensor embeds and ISP that
can upscale and the supported maximum frame size is thus larger that
the pixel array size.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-08 16:21:13 +01:00
Kieran Bingham
2fac95b400 libcamera: pipeline: ipu3: Ensure that IPU3Frames::info is not used after delete
When the IPU3Frames completes, it deletes the internal info storage.

This storage contains the pointer to the Request, but in some cases the
pointer was being accessed after the info structure was removed.

Ensure that the Request is obtained before attempting to complete to
obtain a valid pointer.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-08 12:08:10 +00:00
Kieran Bingham
49667ad8e5 libcamera: pipeline: ipu3: Fix spelling error
Fix trivial spelling mistake.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-08 12:03:38 +00:00
Kieran Bingham
a36cde7834 tracing: pipeline_handler: Queue Requests
Add tracing to the base pipeline handler class to track when requests are queued.

Tracing is already available for other Request operations, but queuing a Request
is not an operation handled by the Request itself.

Add the tracepoint to the PipelineHandler::queueRequest() so the lifetime of a
Request can be viewed when tracing.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-08 11:52:10 +00:00
Kieran Bingham
8c81ab298e libcamera: pipeline_handler: Update request usage comment
When a pipeline handler completes a request, the request itself is not
deleted by libcamera, and the application regains control over the
object. It may choose to delete the Request, or re-use it.

Clarify this in the comment by removing the declaration that the Request
is deleted, but state that it is no longer managed by the pipeline
handler and must not be accessed further after this function returns.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-08 11:51:21 +00:00
Kieran Bingham
2cf0c87511 libcamera: Request: validate state on complete
Requests should only be completed from the RequestPending state.

Requests which are completed from the RequestCancelled, or RequestComplete
state, will indicate that a double-complete has been called on the Request,
or that it has been used internally after it has been given back to the
application.

Ensure that this can be caught early if it occurs by enforcing the state
required with an assert.

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-08 11:51:16 +00:00
Laurent Pinchart
de1b994bba android: camera_device: Update gralloc usage flags for streams
When configuring streams, the camera HAL is supposed to update the
gralloc usage flags to reflect the operations it will need to do on the
stream buffers. Failure to do so leads to incorrect format selection by
gralloc for the HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format, as
gralloc will not take into consideration the need of the camera to
access the buffers.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-05 22:22:47 +02:00
Laurent Pinchart
38f7c2af27 libcamera: media_device: Fix typo
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-05 01:45:52 +02:00
Laurent Pinchart
43f0511962 libcamera: pipeline: simple: Support camera sensors that contain an ISP
Camera sensors can include an ISP. For instance, the AP1302 external ISP
can be connected to up to two raw camera sensors, and the combination of
the sensors and ISP is considered as a (smart) camera sensor from
libcamera's point of view.

The CameraSensor class has limited support for this already. Extend the
simple pipeline handler to support such sensors, by using the media
entity corresponding to the ISP instead of the raw camera sensor's
entity.

We don't need to handle the case where an entity in the SoC would expose
the MEDIA_ENT_F_PROC_VIDEO_ISP function, as pipeline containing an ISP
would have a dedicated pipeline handler.

The implementation is limited as it won't support other multi-entity
camera sensors (such as CCS). While this would be worth supporting, we
don't have a test platform with a CCS-compatible sensor at this point,
so let's not over-engineer the solution. Extending support to CCS (and
possibly other sensor topologies) will likely involve helpers that can
be used by other pipeline handlers (such as generic graph walk helpers
for instance) and extensions to the CameraSensor class.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-04 22:29:18 +02:00
Dafna Hirschfeld
62c456e1cb libcamera: pipeline: simple: Walk the pipeline by following the first link
When walking the pipeline, follow the first link of each source pad.
This patch removes a redundant condition for choosing the link:

"(link->flags() & MEDIA_LNK_FL_ENABLED) ||
 !(link->flags() & MEDIA_LNK_FL_IMMUTABLE)"

since it always returns true.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-03-04 10:39:01 +02:00
Laurent Pinchart
aaaa2e833b libcamera: v4l2_videodevice: Print fd value in log prefix
When opening a V4L2VideoDevice multiple times, for instance to run
multiple jobs on a M2M device, it's useful to attribute log messages to
a particular instance. Include the device fd in the log prefix.

This turns the existing output

[1:43:01.958321522] [277] DEBUG V4L2 v4l2_videodevice.cpp:1440 /dev/video0[cap]: Queueing buffer 0
[1:43:01.958350060] [277] DEBUG V4L2 v4l2_videodevice.cpp:1440 /dev/video0[cap]: Queueing buffer 1
[1:43:01.958365137] [277] DEBUG V4L2 v4l2_videodevice.cpp:1440 /dev/video0[cap]: Queueing buffer 2

into

[1:43:01.958321522] [277] DEBUG V4L2 v4l2_videodevice.cpp:1440 /dev/video0[14:cap]: Queueing buffer 0
[1:43:01.958350060] [277] DEBUG V4L2 v4l2_videodevice.cpp:1440 /dev/video0[14:cap]: Queueing buffer 1
[1:43:01.958365137] [277] DEBUG V4L2 v4l2_videodevice.cpp:1440 /dev/video0[14:cap]: Queueing buffer 2

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-03-04 10:05:47 +02:00
Naushir Patuck
a52eebed20 pipeline: raspberrypi: Only enable embedded stream when available
The pipeline handler would enable and use the Unicam embedded data stream
even if the sensor did not support it. This was to allow a means to
pass exposure and gain values for the frame to the IPA in a synchronised
way.

The recent changes to get the pipeline handler to pass a ControlList
with exposure and gain values means this is no longer required. Disable
the use of the embedded data stream when a sensor does not support it.

This change also removes the mappedEmbeddedBuffers_ map as it is no
longer used.

Signed-off-by: Naushir Patuck <naush@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>
2021-03-04 04:15:07 +02:00
Naushir Patuck
9d4431d621 ipa: raspberrypi: Remove MdParserRPi
With the recent change to pass a ControlList to the IPA with exposure
and gain values used for a frame, RPiController::MdParserRPi is not
needed any more. Remove all traces of it.

The derived CamHelper objects now pass nullptr values for the parser to
the base CamHelper class when sensors do not use metadata.

Signed-off-by: Naushir Patuck <naush@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>
2021-03-04 04:15:02 +02:00
Naushir Patuck
cd07b604ba pipeline: ipa: raspberrypi: Pass exposure/gain values to IPA though controls
When running with sensors that had no embedded data, the pipeline handler
would fill a dummy embedded data buffer with gain/exposure values, and
pass this buffer to the IPA together with the bayer buffer. The IPA would
extract these values for use in the controller algorithms.

Rework this logic entirely by having a new RPiCameraData::BayerFrame
queue to replace the existing bayer queue. In addition to storing the
FrameBuffer pointer, this also stores all the controls tracked by
DelayedControls for that frame in a ControlList. This includes include
exposure and gain values. On signalling RPi::IPA_EVENT_SIGNAL_ISP_PREPARE
IPA event, the pipeline handler now passes this ControlList from the
RPiCameraData::BayerFrame queue.

The IPA now extracts the gain and exposure values from the ControlList
instead of using RPiController::MdParserRPi to parse the embedded data
buffer.

Signed-off-by: Naushir Patuck <naush@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>
2021-03-04 04:14:54 +02:00
Laurent Pinchart
f490a87fd3 libcamera: camera_sensor: Accept entities exposing the ISP function
Camera sensors can include an ISP, which may be reported as a separate
entity from the pixel array in the media graph.

Support such sensors by accepting MEDIA_ENT_F_PROC_VIDEO_ISP as a valid
entity type. This allows using sensors that can be fully (or at least
meaningfully) configured through the ISP's source pad only. Sensors that
require further configuration, on the ISP sink pad and/or on the pixel
array's source pad, will require further extension to the CameraSensor
class.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
2021-03-03 22:52:04 +02:00
Laurent Pinchart
96aecfe365 libcamera: camera_sensor: Use active area size as resolution
When a sensor can upscale the image, the native sensor resolution isn't
equal to the largest size reported by the sensor. Use the active area
size instead, and default it to the largest enumerated size if the crop
rectangle targets are not supported.

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>
2021-03-03 22:52:00 +02:00
Laurent Pinchart
87194982eb ipa: rkisp1: Update to kernel header changes
The rkisp1 driver has received support for newer ISP versions, which
changes its userspace API and ABI. Adapt to the API change. This
requires kernel v5.11 or newer, or backporting the corresponding rkisp1
changes to older kernels.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-03-03 19:41:48 +02:00
Paul Elder
09b0801fdb cros: Support the new cros camera API with set_up and tear_down
Implement and expose the symbol and functions that the new cros camera
API requires. Since we don't actually need them, leave them empty.
Update meson accordingly.

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03 19:05:12 +09:00
Jacopo Mondi
d8d6a78f22 android: Introduce Chromium OS buffer manager
Introduce the CameraBuffer backend for the Chromium OS operating system
and the associated meson option.

The Chromium OS CameraBuffer implementation uses the
cros::CameraBufferManager class to perform mapping of 1 plane and multiplane
buffers and to retrieve size information.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03 09:50:44 +01:00
Jacopo Mondi
1427d124e8 android: mm: Provide helper macro for PIMPL
Each memory backend has to declare a CameraBuffer class implementation
that bridges the API calls to each CameraBuffer::Private implementation.

As the code is likely the same for most (if not all) backends, provide
a convenience macro that expands to the CameraBuffer class declaration.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03 09:50:44 +01:00
Jacopo Mondi
00fec7d5ed android: jpeg: Use CameraBuffer::jpegBufferSize()
Use the newly introduced function to retrieve the size of
the JPEG encoding destination buffer, in order to calculate where
the JPEG_BLOB_ID should be placed.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03 09:50:38 +01:00
Jacopo Mondi
1223da76a2 android: camera_buffer: Add method to get the JPEG blob size
To maintain compatibility with platforms that do not provide a memory
backend implementation add a method to be return the size of the buffer
used for JPEG encoding capped to a maximum size.

Platforms that implement a memory backend will always calculate the
correct buffer size.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03 09:50:28 +01:00
Jacopo Mondi
eba862b0e3 android: post_processor: Use CameraBuffer API
Use the newly introduced CameraBuffer class as the type for the
destination buffer in the PostProcessor class hierarchy in place of the
libcamera::MappedFrameBuffer one and use its API to retrieve the length
and the location of the CameraBuffer plane allocated for JPEG
post-processing.

Remove all the assumption on the underlying memory storage and only go
through the CameraBuffer API when dealing with memory buffers. To do so
rework the Encoder interface to use a raw pointer and an explicit size
to remove access to the Span<uint8_t> maps that serve as memory storage
for the current implementation but might not be ideal for other memory
backend.

Now that the whole PostProcessor hierarchy has been converted to use
the CameraBuffer API remove libcamera::MappedBuffer as base class
of the CameraBuffer interface and only reply on its interface.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03 09:50:13 +01:00