When the clock setups were added for the alternate external clocks,
the settings for 2 lane 720p and 4 lane 1080p were transposed.
2 lane 720p still worked, but 4 lane 1080p didn't.
Correct the assignments.
Fixes: 6b0c094a5b (media: i2c: imx290: Add support for 74.25MHz clock")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Whilst the datasheet lists the link frequency changing between
1080p and 720p modes, reality is that with the default blanking
we have
(1920 + 280) * (1080 + 45) * 60fps = 148.5MPix/s
and
(1280 + 2020) * (720 + 30) * 60fps = 148.5MPix/s
and this reflects reality whether in 10 or 12 bit readout modes.
How this relates to link frequency is unclear as it differs
from the datasheet, but all exposure and frame rate calcs need
the pixel rate to be correct, so make it so.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Commit "97589ad61c73 media: i2c: imx290: Add support for 2 data lanes"
added support for running in two lane mode (instead of 4), but
without changing the link frequency that resulted in a max of 30fps.
Commit "98e0500eadb7 media: i2c: imx290: Add configurable link frequency
and pixel rate" then doubled the link frequency when in 2 lane mode,
but didn't undo the correction for running at only 30fps, just extending
horizontal blanking instead.
It also didn't update the CSI timing registers in accordance with the
datasheet.
Remove the 30fps limit on 2 lane by correcting the register config
in accordance with the datasheet for 60fps operation over 2 lanes.
Frame rate control (via V4L2_CID_VBLANK or HBLANK) can still reduce
the frame rate on 2 lanes back to 30fps.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Do not scale IMX477_EXPOSURE_OFFSET with the long exposure factor during
the limit calculations. This allows larger exposure times, and does seem to be
what the sensor is doing internally.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Fix stream on & off such that failures leave the driver in the correct
state. Ensure that the clock is on when we are streaming and off when
all contexts attached to this device have stopped streaming.
Signed-off-by: John Cox <jc@kynesim.co.uk>
Due to overheads in assembling controls and requests it is worth having
the slice assembly phase separate from the h/w pass1 processing. Create
a queue to service pass1 rather than have the pass1 finished callback
trigger the next slice job.
This requires a rework of the logic that splits up the buffer and
request done events. This code contains two ways of doing that, we use
Ezequiel Garcias <ezequiel@collabora.com> solution, but expect that
in the future this will be handled by the framework in a cleaner manner.
Fix up the handling of some of the memory exhaustion crashes uncovered
in the process of writing this code.
Signed-off-by: John Cox <jc@kynesim.co.uk>
This is probably not the API we will want to add, but it
should show what semantics are needed by drivers.
The goal is to allow the OUTPUT (aka source) buffer and the
controls associated to a request to be released from the request,
and in particular return the OUTPUT buffer back to userspace,
without signalling the media request fd.
This is useful for devices that are able to pre-process
the OUTPUT buffer, therefore able to release it before
the decoding is finished. These drivers should signal
the media request fd only after the CAPTURE buffer is done.
Tested-by: John Cox <jc@kynesim.co.uk>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Add an enable count to the irq Q structures to allow the irq logic to
block further callbacks if resources associated with the irq are not
yet available.
Signed-off-by: John Cox <jc@kynesim.co.uk>
Use multi-planar interface rather than single plane interface. This
allows dmabufs holding compressed data to be resized.
Signed-off-by: John Cox <jc@kynesim.co.uk>
VAAPI H265 has num entry points but never sets it. Allow a VAAPI
shim to work without requiring rewriting the VAAPI driver.
num_entry_points can be calculated from the slice_segment_addr
of the next slice so delay processing until we have that.
Also includes some minor cosmetics.
Signed-off-by: John Cox <jc@kynesim.co.uk>
Fixes the following v4l2-compliance failure:
fail: v4l2-test-controls.cpp(871): subscribe event for control 'User Controls' failed test
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Trial and error reveals that the minimum vblank value appears to be 24
(the OV5647 data sheet does not give any clues). This fixes streaming
lock-ups in full resolution mode.
Fixes: 9b5a5ebedc ("media: i2c: ov5647: Add support for V4L2_CID_VBLANK")
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
The top offset in the pixel array is actually 6 (see page 3-1 of the
OV5647 data sheet).
Fixes: f2f7ad5ce5 ("media: i2c: ov5647: Selection compliance fixes")
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Keeping a copy of the old poweroff handler allows it to be restored
should this module be unloaded, but also provides a fallback if the
power hasn't been removed when the timeout elapses.
See: https://github.com/raspberrypi/rpi-eeprom/issues/330
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The result of dividing a u32 by a size_t is an unsigned int on arm32
and a long unsigned int on arm64. Use "%zu" (the size_t format) to
remove the build warning for 64-bit builds.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
During decode, setting the CAPTURE queue format was setting the crop
rectangle to the requested height before aligning up the format to
cater for simple clients that weren't expecting to deal with cropping
and the SELECTION API.
This caused problems on some resolution change events if the client
didn't also then use the selection API.
Disable the crop update after a resolution change.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Whilst the hardware can't achieve the limits of level 4.2 under
all situations, it can exceed level 4.0.
Allow selection of levels 4.1 and 4.2.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
MMAL has the flag MMAL_BUFFER_HEADER_FLAG_CORRUPTED but that
wasn't being passed through, so add it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Video decode supports YUV and RGB formats. YUV needs to report SMPTE170M
or REC709 appropriately, whilst RGB should report SRGB.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The driver said it supported H264 levels 4.1 and 4.2, but
was missing the V4L2 to MMAL mappings.
Add in those mappings.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The current code will first dereference the req pointer and then test if
it's NULL, resulting in a NULL pointer dereference if req is indeed
NULL. Reorder the test and derefence to avoid the issue
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
There is no reason why the control GPIOs for the panel can not
be connected to I2C or similar GPIO interfaces that may need to
sleep, therefore switch from gpiod_set_value to
gpiod_set_value_cansleep calls to configure them.
Without that you get complaints from gpiolib every time the state
is changed.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Replace an undeclared variable used by DWC_DEBUGPL with the real endpoint address. DWC_DEBUGPL does nothing with DEBUG undefined so it did not go wrong before.
Signed-off-by: Zixuan Wang <wangzixuan@sjtu.edu.cn>
It's not unusual to find clocks being shared across multiple devices
that need to change the rate depending on what the device is doing at a
given time.
The SoC found on the RaspberryPi4 (BCM2711) is in such a situation
between its two HDMI controllers that share a clock that needs to be
raised depending on the output resolution of each controller.
The current clk_set_rate API doesn't really allow to support that case
since there's really no synchronisation between multiple users, it's
essentially a fire-and-forget solution.
clk_set_min_rate does allow for such a synchronisation, but has another
drawback: it doesn't allow to reduce the clock rate once the work is
over.
In our previous example, this means that if we were to raise the
resolution of one HDMI controller to the largest resolution and then
changing for a smaller one, we would still have the clock running at the
largest resolution rate resulting in a poor power-efficiency.
In order to address both issues, let's create an API that allows user to
create temporary requests to increase the rate to a minimum, before
going back to the initial rate once the request is done.
This introduces mainly two side-effects:
* There's an interaction between clk_set_rate and requests. This has
been addressed by having clk_set_rate increasing the rate if it's
greater than what the requests asked for, and in any case changing
the rate the clock will return to once all the requests are done.
* Similarly, clk_round_rate has been adjusted to take the requests
into account and return a rate that will be greater or equal to the
requested rates.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
be suspended
Webcams with microphones are composite devices, and autosuspend is set
at the device level. If uvcvideo is probed after snd-usb-audio, the effect
of the quirk applied by snd-usb-audio is undone by uvcvideo's global
application of autosuspend.
Incrementing the interface's PM refcount in such cases prevents runtime PM
from happening, thus the device is left active.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
These devices use a type of Sonix chipset that produces broken microphone
data if suspended/resumed.
They also don't support readback of the sample rate.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
When importing there was a missing call to detach the buffer,
so each import leaked the sg table entry.
Actually the release process for both locally allocated and
imported buffers is identical, so fix them to both use the same
function.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
warning: address of array 'desc->wMaxPacketSize' will always evaluate to 'true'
The wMaxPacketSize field is actually a two element array which content should
be accessed via the UGETW macro.
The Adafruit Mini-PiTFT13 display needs offsets applying when rotated,
so use the "variant" mechanism to select a custom set_addr_win method
using a dedicated compatible string of "fbtft,minipitft13".
See: https://github.com/raspberrypi/firmware/issues/1524
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
DMABUFs are all handled by videobuf2, so there is no reason not
to enable support for them.
Note that this driver is still using the vmalloc allocator, so
the buffers it allocates will not be compatible with the codec
or ISP driver that require contiguous buffers. However this
driver should be able to import the buffers allocated by them.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Parse device properties and register controls for them using the V4L2
fwnode properties helpers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Previously they were returning positive non-zero codes for success,
which were getting passed up the call stack. Since release 4.19,
do_dentry_open (fs/open.c) has been catching these and flagging an
error. (So this driver has been broken since that date.)
Fixes: 3c2472a [media] media: i2c: Add support for OV5647 sensor
Signed-off-by: David Plowman <david.plowman@raspberrypi.org>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Breaks out common register set and adds the different registers
for 1280x720 (cropped) and 640x480 (skipped) modes
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
