The set pixelformat field of struct v4l2_pix_format structure was
wrongly converted to PixelFormat by calling v4l2ToDrm(), with an already
converted 'format' argument.
Fix this by calling the right drmToV4l2() conversion function.
Fixes: 0ce8f2390b ("v4l2: v4l2_compat: Add V4L2 compatibility layer")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Commit 29c5508075 ("v4l2: camera_proxy: Create format info array")
introduced usage of the std::array template class, but didn't include
the corresponding header. This may cause a compilation breakage in the
future if the indirect include of <array> disappears due to unrelated
changes. Fix it.
Fixed: 29c5508075 ("v4l2: camera_proxy: Create format info array")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Create a PixelFormatInfo structure to store information about a format,
and add a global array of format info for all the formats currently
supported. Move the format helpers to use the information from the
array.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
To clarify code, adopt the following rules for format helpers:
- All variables representing V4L2 pixel formats shall use uint32_t
- All variables representing DRM pixel formats shall use PixelFormat
- Functions returning positive values only shall not have a signed
return type
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Create a new FileOperations structure to hold all the dynamically-loaded
C library file operations. The file operations are now exposed publicly,
to prepare for usage of mmap in the V4L2CameraProxy.
A new template helper function is added to retrieve a symbol with
dlsym() with proper casting to simplify the V4L2CompatManager
constructor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Now that Object::invokeMethod() supports returning a value, use it and
drop the return value method argument.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Test that a signal can be connected to non-void static and member slots.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Test that Object::invokeMethod() can be used to invoke a non-void
method. Verify that the return value is correctly propagated to the
caller.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Most of the bound method classes are named with a BoundMethod prefix,
except for BoundMemberMethod and BoundStaticMethod. Rename them to
BoundMethodMember and BoundMethodStatic respectively to make the code
more coherent.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Propagate the return value of the bound method all the way to the caller
of activate(). The value is stored in the arguments pack for indirect
invocation.
As C++ doesn't allow instantiating a variable of type void, we need to
specialize the template class BoundMethodPack for methods returning
void. This in turn requires template specialization for the
BoundMethodArgs class in order to store the return value in the pack,
and for the BoundMemberMethod class to extract the return value from the
pack.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The bound method arguments pack will need to be accessed by the method
invoker in order to retrieve the method return value when using a
blocking connection type. We thus can't delete the pack unconditionally
in the bound method target thread. We also can't delete it
unconditionally in the invoker's thread, as for queued connections the
pack will be used in the target thread after the invoker completes.
This shows that ownership of the arguments pack is shared between two
contexts. As a result, manage it using std::shared_ptr<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The bound method implementation is restricted to binding to void methods
as return values are not supported. This complicates usage of bound
methods, as non-void methods used a slots or Object::invokeMethod()
targets need to be wrapped in a void method. Simplify this by supporting
arbitrary return types and ignoring the return value.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Create a new BoundMethodPack class to replace the PackType type alias.
This will allow adding additional fields to the arguments pack, when
adding support for propagation of bound method return values.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The sequence and generator member types of BoundMethodArgs are not
dependent on the template arguments of BoundMethodArgs. To prepare for
template specialization of BoundMethodArgs and avoid code duplication,
move them to the BoundMethodBase class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The BoundMethodBase::connectionType() method isn't used, drop it. While
it at make the connectionType_ member private as it is only used by the
class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Mark the activate() and invoke() methods with the override keyword where
appropriate.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When BoundMethodBase::activatePack() is called with the connection type
set to ConnectionTypeDirect, the method isn't deleted even if
deleteMethod is true, as is the case when called from
Object::invokeMethod(). This causes a memory leak. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Test the ConnectionTypeDirect type when the object lives in a different
thread. This test passes but generates a memory leak.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The checkstyle script expects hunks to be declared with a start line and
line count, however the unified diff format [0] declares that a single
line hunk will only have the start line:
> If a hunk contains just one line, only its start line number appears.
> Otherwise its line numbers look like ‘start,count’. An empty hunk is
> considered to start at the line that follows the hunk.
[0] https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html#Detailed-Unified
Attempting to parse a single line hunk results in the following error:
File "./utils/checkstyle.py", line 110, in __init__
raise RuntimeError("Malformed diff hunk header '%s'" % line)
RuntimeError: Malformed diff hunk header '@@ -1 +1,2 @@
The DiffHunk class only makes use of the start line, and does not
utilise the line count, thus update the regex to make the unused
groups optional.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The checkstyle.py patch has a fault which it identified in itself when
updating the regex string.
--- utils/checkstyle.py
+++ utils/checkstyle.py
#105: : W605 invalid escape sequence '\+'
+ diff_header_regex = re.compile('@@ -([0-9]+)(,[0-9]+)? \+([0-9]+)(,?[0-9]+)? @@')
---
1 potential style issue detected, please review
This is documented further at:
https://www.flake8rules.com/rules/W605.html
Update the string literal prefix to declare a raw byte string for the
regex parser.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The ControlSerializer::serial_ member variable isn't initialized. Add a
constructor to the class to initialize it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
IPCUnixSocket::send() sends a IPCUnixSocket::Header allocated on the
stack. All the fields of the header are initialized, but the padding
bytes are not. This results in random data being sent over the UNIX
socket, potentially leaking information.
Fix this by initializing the whole header to 0.
Fixes: 13dd7a01ec ("libcamera: ipc: unix: Add a IPC mechanism based on Unix sockets")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The __open_2() and __openat_2() functions are defined by glibc as taking
2 and 3 arguments respectively, with variadic arguments for the file
mode as open() and openat() do. The V4L2 compatibility layer defines
them as aliases for open() and openat(), which results in compilation
failures with gcc:
../../src/v4l2/v4l2_compat.cpp: In function ‘int __openat_2(int, const char*, int)’:
../../src/v4l2/v4l2_compat.cpp:58:14: error: invalid conversion from ‘int’ to ‘const char*’ [-fpermissive]
58 | return open(dirfd, path, oflag);
| ^~~~~
| |
| int
../../src/v4l2/v4l2_compat.cpp:31:39: note: initializing argument 1 of ‘int open(const char*, int, ...)’
31 | LIBCAMERA_PUBLIC int open(const char *path, int oflag, ...)
| ~~~~~~~~~~~~^~~~
../../src/v4l2/v4l2_compat.cpp:58:21: error: invalid conversion from ‘const char*’ to ‘int’ [-fpermissive]
58 | return open(dirfd, path, oflag);
| ^~~~
| |
| const char*
../../src/v4l2/v4l2_compat.cpp:31:49: note: initializing argument 2 of ‘int open(const char*, int, ...)’
31 | LIBCAMERA_PUBLIC int open(const char *path, int oflag, ...)
|
Fix this by defining the two functions as wrappers around open() and
openat() without variadic arguments.
Fixes: 0ce8f2390b ("v4l2: v4l2_compat: Add V4L2 compatibility layer")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add libcamera V4L2 compatibility layer.
This initial implementation supports the minimal set of V4L2 operations,
which allows getting, setting, and enumerating formats, and streaming
frames from a video device. Some data about the wrapped V4L2 video
device are hardcoded.
Add a build option named 'v4l2' and adjust the build system to
selectively compile the V4L2 compatibility layer.
For now we match the V4L2 device node to a libcamera camera based on a
devnum that a pipeline handler may optionally map to a libcamera
camera.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Register all UVC Cameras along with their device numbers, to eventually
allow the V4L2 compatibility layer to match against it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The V4L2 compatibility layer will need a way to map device numbers to
libcamera Camera instances. Expose a method in the camera manager to
retrieve Camera instances by devnum. The mapping from device numbers to
Camera instances is optionally declared by pipeline handlers when they
register cameras with the camera manager.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We are preparing to integrate the V4L2 adaptation layer, which will
intercept open() calls (among others) via LD_PRELOAD. To prevent
libcamera's own open() calls from being intercepted, replace them with a
direct syscall.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
strlcpy is available in libbsd, bionic, musl, and ulibc, but not in glibc.
Instead of checking for strlcpy availability and modifying dependencies,
implement it in utils, as a wrapper around strncpy.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Invoking a method that takes a reference argument with
Object::invokeMethod() results in a compilation error:
../test/object-invoke.cpp:131:11: error: no matching member function for call to 'invokeMethod'
object_.invokeMethod(&InvokedObject::methodWithReference,
~~~~~~~~^~~~~~~~~~~~
../include/libcamera/object.h:33:7: note: candidate template ignored: deduced conflicting types for parameter 'Args' (<const int &> vs. <int>)
void invokeMethod(void (T::*func)(Args...), ConnectionType type, Args... args)
This is due to the fact that implicit type conversions (from value to
reference in this case) takes place after template argument type
deduction, during overload resolution. A similar issue would occur if
T::func took a long argument and invokeMethod() was called with an in
argument.
Fix this by specifying to sets of argument types in the invokeMethod()
template, one for the arguments to the invoked method, and one for the
arguments to invokeMethod() itself. The compiler can then first perform
type deduction separately, and implicit conversion in a second step.
Reported-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Object::invokeMethod() fails with a compilation error when the invoked
method takes a reference argument. Add a test case for this issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The buffer index is a V4L2 concept that will be hidden from users with
the introduction of a new FrameBuffer class. In preparation for this,
remove the index from log messages.
Keep and move one debug log message where the index is available as the
V4L2 buffer is being dequeued for the video device and it's useful when
debugging.
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>
Expecting pipeline handler implementations of queueRequest() to call
the base class queueRequest() at the correct point have led to different
behaviors between the pipelines.
Fix this by splitting queueRequest() into a base class implementation
which handles the bookkeeping and a new queueRequestDevice() that is
to be implemented by pipeline handlers and only deals with committing the
request to the device.
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>
Object instances receive messages dispatched from the event loop of the
thread they belong to. Deleting an object from a different thread is
thus dangerous, unless the caller ensures that no message delivery is in
progress. Document this in the Object class documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When the Linux headers were updated to v5.2, the version announced in
the README was not, so update it.
Fixes: 4984973679 ("include: linux: Update headers to Linux v5.2")
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The InvokeObject instance is created on the stack in the run() method,
and is thus destroyed before the thread the object is bound to
terminates. This creates a race condition as the object message handler
could be running when the object is deleted. Fix this by moving the
InvokeObject to a member field.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The Object class stores the number of pending messages that have been
posted for it, while the actual messages are stored in a per-thread list
in the ThreadData class. When dispatching messages, the message is
removed from the list, passed to the receiver, and the number of pending
messages is updated.
In order to avoid too much contention on the list lock, the lock is
dropped to pass the message to the receiver and then taken again. This
creates a race condition window with Thread::removeMessages(), as the
number of pending messages for a receiver is briefly out of sync with
the pending messages list. The assertion at the end of removeMessages()
thus sometimes fails.
Fix this by decrementing the pending messages counter before releasing
the lock in Thread::dispatchMessages(). This fixes the slow message
receiver test in MessageTest.
Fixes: 01b930964a ("libcamera: thread: Add a messaging passing API")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
There's a race in the message delivery against object deletion. Add a
test that triggers it reliably. This test is expected to fail with an
assertion error.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Forward messages that we don't handle to the base Object class, to avoid
both blocking the ThreadMove message and mistaking it as the test
message.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When moving an Object to a Thread, messages posted for the object are
move to the target thread's message queue. This requires locking the
message queues of the current and target threads, as the target thread
may (and is usually) running. The implementation is faulty as it locks
the thread data instead of the message queue. This creates a race
condition with a tiny but exploitable time window.
The issue was noticed by the event-thread test rarely but reproducibly
failing with the following assertion error:
[1:39:33.850878042]FATAL default thread.cpp:440 assertion "data_ == receiver->thread()->data_" failed
The issue only occurred when libcamera was compiled in release mode,
further hinting of a race condition.
Fixes: 01b930964a ("libcamera: thread: Add a messaging passing API")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When a fatal error occurs the program aborts, and all the logger
provides is the location of the line that caused the error. Extend this
with a full backtrace to help debugging.
The backtrace is generated using the backtrace() call, a GNU extension
to the C library. It is available in glibc and uClibc but not in musl.
Test for availability of the function to condition compilation of the
backtrace printing. Implementing backtrace support with musl is an
exercise left to the reader if desired.
The LogOutput class is extended to support writing string messages
directly to the output. Strings written directly will be considered as
LogDebug messages when written to the Syslog.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
gcc 8 and 9 complain about the OptionValue::integer_ member being
possibly used initialized when compiled in release mode. I haven't been
able to find where this could be the case, and the compiler error
message isn't helpful:
In file included from ../../src/cam/options.cpp:14:
../../src/cam/options.h: In member function ‘bool OptionsBase<T>::parseValue(const T&, const Option&, const char*) [with T = std::__cxx11::basic_string<char>]’:
../../src/cam/options.h:84:7: error: ‘<anonymous>.OptionValue::integer_’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
class OptionValue
^~~~~~~~~~~
../../src/cam/options.h: In member function ‘bool OptionsBase<T>::parseValue(const T&, const Option&, const char*) [with T = int]’:
../../src/cam/options.h:84:7: error: ‘<anonymous>.OptionValue::integer_’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
class OptionValue
^~~~~~~~~~~
Furthermore valgrind doesn't report any issue. This is likely a false
positive, but fix it nonetheless as the fix is cheap.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Since commit fac471e812 ("test: Extract CameraTest class out of camera
tests to libtest") the control_list is a subclass of CameraTest, and the
status returned by the base class init() operation should be inspected
to avoid accessing uninitialized fields during the run() operation
execution.
If the VIMC test module is not loaded, executing the test results in a
segfault. Fix this by adding the init() operation where to status_ flag
is checked for errors.
Fixes: fac471e812 ("test: Extract CameraTest class out of camera tests to libtest")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Commit 965c5bf7fb ("meson: Define _FORTIFY_SOURCE for optimised
builds") tried to define _FORTIFY_SOURCE for optimised builds with
clang, but updated the common_arguments after it was used. This resulted
in the _FORTIFY_SOURCE option not being applied. Fix it.
Fixes: 965c5bf7fb ("meson: Define _FORTIFY_SOURCE for optimised builds")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Wrap an IPAInterface in an IPAInterfaceWrapper in an IPAContextWrapper,
and verify that the translation between C and C++ APIs work correctly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When an IPA module is loaded without isolation and implements the
IPAInterface internally, going through ipa_context_ops is a waste of
time. Add an operation to retrieve the IPAInterface, and use it directly
in the IPAContextWrapper.
For debugging purpose, make it possible to forcing usage of the C API by
defining the LIBCAMERA_IPA_FORCE_C_API environment variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
IPA modules have to implement a public ipaCreate() function, but its
prototype isn't declared in any header file. This allows for modules to
get the prototype wrong without being warned by the compiler. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Switch IPA communication to the plain C API. As the IPAInterface class
is easier to use for pipeline handlers than a plain C API, retain it and
add an IPAContextWrapper that translate between the C++ and the C APIs.
On the IPA module side usage of IPAInterface may be desired for IPAs
implemented in C++ that want to link to libcamera. For those IPAs, a new
IPAInterfaceWrapper helper class is introduced to wrap the IPAInterface
implemented internally by the IPA module into an ipa_context,
ipa_context_ops and ipa_callback_ops.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
