- Jan 28, 2021
-
-
popcornmix authored
-
Dave Stevenson authored
The sensor supports 8 bit mode as well as 10bit, so add the relevant code to allow selection of this. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Fix commit "media: tc358743: Return an appropriate colorspace from tc358743_set_fmt" to ensure that the format passed in to set_fmt is checked to be valid, and reset to the current format if not. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Pi 0&1 pass all ARM accesses through the VPU L2 cache, therefore the dma-ranges property sets the cache alias bits to other than the direct alias, hence this WARN was firing. It was overprotective coding, so assume that everything is OK with the dma-ranges, and remove the WARN. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Hristo Venev authored
MEDIA_CONTROLLER_REQUEST_API is a hidden option. If rpivid depends on it, the user would need to first enable another driver that selects MEDIA_CONTROLLER_REQUEST_API, and only then rpivid would become available. By selecting it instead of depending on it, it becomes possible to enable rpivid without having to enable other potentially unnecessary drivers. Signed-off-by: Hristo Venev <hristo@venev.name>
-
Hristo Venev authored
That is what almost all other drivers appear to be doing. Signed-off-by: Hristo Venev <hristo@venev.name>
-
Phil Elwell authored
In an attempt to prevent the problem of CPUn not starting, explicitly misalign the scratch space used to save registers acros the cache invalidation. Notes: At this stage in the boot process the core is running with its cache disabled. Before enabling the cache its contents must be explicitly invalidated, a process that requires quite a few registers that the caller must preserve. Evidence suggests that something is writing a block of zeroes over that space at a time when all other cores should be idle, possibly some kind of write-combiner, and the misalignment is designed to disrupt any write-coalescing. In truth, I don't understand why this patch works, and when the failure is so random it is hard to be certain that this isn't just rolling the dice again. One interesting test would be to change the "addeq r12, #4"s to "addeq r12, #0"s determine see if the offset itself is significant or just the additional code. See: https://github.com/Hexxeh/rpi-firmware/issues/232 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
Unless the DMA mask is set wider than 32 bits, DMA mapping will use a bounce buffer. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
Although it is no longer necessary for vchiq's children to have a different DMA configuration to the parent, they do still need to explicitly to have their DMA configuration set - to be that of the parent. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The actpwr trigger is a meta trigger that cycles between an inverted mmc0 and default-on. It is written in a way that could fairly easily be generalised to support alternative sets of source triggers. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Laurent Pinchart authored
Parse device properties and register controls for them using the V4L2 fwnode properties helpers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Naushir Patuck authored
Update the documentation to reflect the new "VPU" clock needed by the bcm2835-unicam driver. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
When streaming with Unicam, the VPU must have a clock frequency of at least 250Mhz. Otherwise, the input fifos could overrun, causing image corruption. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Dave Stevenson authored
[g|s]_selection pass in a buffer type that needs to be validated before passing on to the sensor subdev. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
v4l2-compliance throws a failure if the device doesn't advertise V4L2_CAP_READWRITE but allows read or write operations. We do support read, so reinstate the flag. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The colorspace fields were left untouched in imx290_set_fmt which lead to a v4l2-compliance failure. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Userspace needs to know the cropping arrangements for each mode, so expose this through g_selection. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
__v4l2_ctrl_modify_range only updates the current value should it be invalid within the new range. That can leave modes producing odd frame rates. Explicitly update the HBLANK and VBLANK values so that on mode change we revert to the default frame rate for the mode. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Vision Components have made an OV9281 module which blocks reading back the majority of registers to comply with NDAs, and in doing so doesn't allow auto-increment register reading as used when reading the chip ID. Use two reads and manually combine the results. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The Rockchip driver was based on a 4.4 kernel, and had several custom Rockchip parts. Update to 5.4 kernel APIs, with the relevant controls required by libcamera, and remove custom Rockchip parts. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Adds the ov9281 parts of the Rockchip patch adding enum_frame_interval to a large number of drivers. Change-Id: I03344cd6cf278dd7c18fce8e97479089ef185a5c Signed-off-by: Zefa Chen <zefa.chen@rock-chips.com>
-
Dave Stevenson authored
Takes the ov9281 part only from the Rockchip's patch. Change-Id: I30e833baf2c1bb07d6d87ddb3b00759ab45a90e4 Signed-off-by: Zefa Chen <zefa.chen@rock-chips.com>
-
Zefa Chen authored
Change-Id: I7b77250bbc56d2f861450cf77271ad15f9b88ab1 Signed-off-by: Zefa Chen <zefa.chen@rock-chips.com>
-
Phil Elwell authored
Use bit 27 of the dreq value (the second cell of the DT DMA descriptor) to request that the WAIT_RESP bit is not set. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
Now that the 14bit non-packed Bayer formats are defined, add them into the supported formats lookup table. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Now that V4L2_PIX_FMT_Y14 and V4L2_PIX_FMT_Y14P are defined, allow passing 14bit mono data through the peripheral. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Now that V4L2_PIX_FMT_Y12P is defined, allow passing raw 12bit mono packed data through the peripheral. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
This is the format used by monochrome 14bit image sensors. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
This is the format used by monochrome 12bit image sensors. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/3700 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
imx290_set_hmax was using two independent writes to set up hmax, when all other multi-register writes were using imx290_write_buffered_reg which claims the group hold first. Switch imx290_set_hmax to using imx290_write_buffered_reg too. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The IMX290 module is available as either mono or colour (Bayer). Update the driver so that it can advertise the correct mono formats instead of the colour ones. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The IMX290 module is available as either monochrome or colour and the variant is not detectable at runtime. Add a new compatible string for the monochrome version. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The sensor supports horizontal and vertical flips, so support them through V4L2_CID_HFLIP and V4L2_CID_VFLIP. This sensor does NOT change the Bayer order when changing the direction of readout, therefore no special handling is required for that. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Adds support for V4L2_CID_EXPOSURE so that userspace can control the sensor exposure time. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
In order to calculate framerate and durations userspace needs the vertical blanking information. This can be configurable, and indeed the datasheet lists different values for VBLANK for the 1080p and 720p modes. Add the new control, and adopt the datasheet values for each mode. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Userspace needs to know HBLANK if it is to work out exposure times and frame rates, therefore convert it to map onto V4L2_CID_HBLANK Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The datasheet lists the gain as being 0.0 to 72.0dB in 0.3dB steps, which makes 238 steps total. Correct the 0-72 range defined in the driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The existing driver only supported a clock of 37.125MHz, but the sensor also supports 74.25MHz. Add the relevant register modifications to support this alternate clock frequency. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Andrey Konovalov authored
Commit d46cfdc8 upstream. With the current driver 'media-ctl -p' issued right after the imx290 driver is loaded prints: pad0: Source [fmt:unknown/0x0] The format value of zero is due to the current_format field of the imx290 struct not being initialized yet. As imx290_entity_init_cfg() calls imx290_set_fmt(), the current_mode field is also initialized, so the line which set current_mode to a default value in driver's probe() function is no longer needed. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-