- Jul 03, 2020
-
-
Dave Stevenson authored
Adds the mainline IMX290 sensor driver (with extra features) to the default configs. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Adds an overlay to configure the IMX290 image sensor. Signed-off-by: Dave Stevenson <dave.stevenson@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 a2706758 upstream. The bus_type field of v4l2_fwnode_endpoint structure passed as the argument to v4l2_fwnode_endpoint_alloc_parse() function must be initiaized. Set it to V4L2_MBUS_CSI2_DPHY, and check for -ENXIO which is returned when the requested media bus type doesn't match the fwnode. Also remove v4l2_fwnode_endpoint field from struct imx290 as it is only needed in the probe function: use the local variable for this purpose. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Commit 6544af9b upstream. The 10ms settle time is needed only at the end of all consecutive register writes. So move the delay to outside of the for loop of imx290_set_register_array(). Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Commit 3b867fb6 upstream. Add support to enumerate all frame sizes supported by IMX290. This is required for using with userspace tools such as libcamera. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Commit c566ac01 upstream. IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and 12 bit formats. Since the driver already supports RAW10 mode, let's add the missing RAW12 mode as well. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Commit a58df1f9 upstream. Add support for generating following test patterns by IMX290: * Sequence Pattern 1 * Horizontal Color-bar Chart * Vertical Color-bar Chart * Sequence Pattern 2 * Gradation Pattern 1 * Gradation Pattern 2 * 000/555h Toggle Pattern Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Commit 98e0500e upstream. IMX290 operates with multiple link frequency and pixel rate combinations. The initial driver used a single setting for both but since we now have the lane count support in place, let's add configurable link frequency and pixel rate. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Commit 97589ad6 upstream. The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit adds support for 2 lane mode in addition to the 4 lane and also configuring the data lane settings in the driver based on system configuration. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
Commit 3909a92d upstream. According to https://www.kernel.org/doc/Documentation/gpio/consumer.txt , - all of the gpiod_set_value_xxx() functions operate with the *logical* value. So in imx290_power_on() the reset signal should be cleared (de-asserted) with gpiod_set_value_cansleep(imx290->rst_gpio, 0), and in imx290_power_off() the value of 1 must be used to apply/assert the reset to the sensor. In the device tree the reset pin is described as GPIO_ACTIVE_LOW, and gpiod_set_value_xxx() functions take this into account, - when devm_gpiod_get_optional() is called with GPIOD_ASIS, the GPIO is not initialized, and the direction must be set later; using a GPIO without setting its direction first is illegal and will result in undefined behavior. Fix this by using GPIOD_OUT_HIGH instead of GPIOD_ASIS (this asserts the reset signal to the sensor initially). 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>
-
Andrey Konovalov authored
Commit 8d2d1bed upstream. The macro is defined as SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn), so imx290_power_off must be the 1st arg, and imx290_power_on the 2nd. 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>
-
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>
-
Dave Stevenson authored
Older gcc versions object to = { 0 } initialisation if the first elemtn in the structure is a substructure. Use = { } to avoid this compiler warning. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The upstreamed Unicam driver uses a dt property to denote how many lanes are supported by the receiver peripheral, independent of the number of lanes that the sensor wants to use. It also doesn't check the remote endpoint config for the number of lanes as that isn't the accepted way of doing things. Update the base DT for the brcm,num-data-lanes property, and the overlays to define the desired number of lanes at both ends of the link. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Use the get_mbus_config pad subdev call to allow a source to use fewer than the number of CSI2 lanes defined in device tree. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Upsstream are renaming VFL_TYPE_GRABBER to VFL_TYPE_VIDEO. To make backporting the upstream Unicam driver easier, add an extra enum entry (same as VFL_TYPE_GRABBER) to match that. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Naushir Patuck authored
Add a driver for the Unicam camera receiver block on BCM283x processors. Compared to the bcm2835-camera driver present in staging, this driver handles the Unicam block only (CSI-2 receiver), and doesn't depend on the VC4 firmware running on the VPU. The commit is made up of a series of changes cherry-picked from the rpi-5.4.y branch of https://github.com/raspberrypi/linux/ with additional enhancements, forward-ported to the mainline kernel. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reported-by: kbuild test robot <lkp@intel.com>
-
Dave Stevenson authored
About to be replaced by the upstream version. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64675/ Use the newly introduced get_mbus_config() subdevice pad operation to retrieve the remote subdevice MIPI CSI-2 bus configuration and configure the number of active data lanes accordingly. In order to be able to call the remote subdevice operation cache the index of the remote pad connected to the single CSI-2 input port. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64676/ Implement the newly introduced get_mbus_config operation to report the number of currently used data lanes on the MIPI CSI-2 interface. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64673/ When outputting SD-Core output through the TXA MIPI CSI-2 interface, the number of enabled data lanes should be reduced in order to guarantee that the two video formats produced by the SD-Core (480i and 576i) generate a MIPI CSI-2 link clock frequency compatible with the MIPI D-PHY specifications. Limit the number of enabled data lanes to 2, which is guaranteed to support 480i and 576i formats. Cache the number of enabled data lanes to be able to report it through the new get_mbus_config operation. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64672/ Update the TODO entry that mentioned a potential use case for the now removed g_mbus_config video operation. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64670/ With all sensor and platform drivers now converted to use the new get_mbus_config and set_mbus_config pad operations, remove the deprecated video operations g_mbus_config and s_mbus_config. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64671/ Move the PXA camera driver to use the new set_mbus_config pad operation. For this platform the change is not only cosmetic, as the pxa driver is currently the only driver in mainline to make use of the g_mbus_config and s_mbus_config video operations. The existing driver semantic is the following: - Collect all supported mbus config flags from the remote end - Match them with the supported PXA mbus configuration flags - If the remote subdevice allows multiple options for for VSYNC, HSYNC and PCLK polarity, use platform data requested settings The semantic of the new get_mbus_config and set_mbus_config differs from the corresponding video ops, particularly in the fact get_mbus_config reports the current mbus configuration and not the set of supported configuration options, with set_mbus_config always reporting the actual mbus configuration applied to the remote subdevice. Adapt the driver to perform the following - Set the remote subdevice mbus configuration according to the PXA platform data preferences. - If the applied configuration differs from the requested one (i.e. the remote subdevice does not allow changing one setting) make sure that - The remote end does not claim for DATA_ACTIVE_LOW, which seems not supported by the platform - The bus mastering roles match While at there remove a few checks performed on the media bus configuration at get_format() time as they do not belong there. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64674/ Use the new get_mbus_config and set_mbus_config pad operations in place of the video operations currently in use. Compared to other drivers where the same conversion has been performed, ov6650 proved to be a bit more tricky, as the existing g_mbus_config implementation did not report the currently applied configuration but the set of all possible configuration options. Adapt the driver to support the semantic of the two newly introduced operations: - get_mbus_config reports the current media bus configuration - set_mbus_config applies only changes explicitly requested and updates the provided cfg parameter to report what has actually been applied to the hardware. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64669/ Move the existing users of the g_mbus_config video operation to use the newly introduced get_mbus_config pad operations. All the ported drivers report a static media bus configuration and do no support s_mbus_config so the operation implementation has not changed. Bridge drivers needs to call the new pad operation and will receive an -ENOICTLCMD when calling the old g_mbus_config video operation Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64669/ Introduce two new pad operations to allow retrieving and configuring the media bus parameters on a subdevice pad. The newly introduced operations aims to replace the s/g_mbus_config video operations, which have been on their way for deprecation since a long time. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Phil Elwell authored
Allow the nvram file to set a default ccode (regulatory domain) without overriding one set in OTP. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
- Jul 01, 2020
-
-
Maxim Mikityanskiy authored
Add device tree nodes for Bluetooth on supported Raspberry Pi boards. It's disabled by default and can be enabled by `krnbt=on` dtparam. It's an alternative way of configuring Bluetooth, as compared to hciattach or btattach. When the dtparam is enabled, the Bluetooth driver is probed automatically and doesn't require any additional bring-up scripts. Note that Raspberry Pi 3 B rev 1.2 doesn't have the required hardware flow control pins of UART0 connected to the Bluetooth module, so the user should decrease the baudrate by passing `krnbt_baudrate=921600` dtparam to make it more stable. It resembles the behavior of the btuart script from Raspbian. The miniuart-bt overlay was modified to support Bluetooth probing with device tree, too. It's disabled by default and can be enabled by `krnbt=on` parameter of the miniuart-bt overlay. Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
-
Maxim Mikityanskiy authored
The next patch adds a device tree overlay for Bluetooth. The Bluetooth device node is a child of uart0 (pl011). The children of pl011 are not registered as platform devices by of_platform_bus_create, because they fall into `of_device_is_compatible(bus, "arm,primecell")` check. These children are registered by of_serdev_register_devices, called through this chain of calls: - uart_add_one_port (drivers/tty/serial/amba-pl011.c) - tty_port_register_device_attr_serdev - serdev_tty_port_register - serdev_controller_add - of_serdev_register_devices serdev_tty_port_register depends on CONFIG_SERIAL_DEV_CTRL_TTYPORT, which in turn depends on CONFIG_SERIAL_DEV_BUS=y. This patch modifies the defconfigs of Raspberry Pi devices to set these options and allow to bind drivers to subnodes of UART devices that can be added by device tree overlays. Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
-
- Jun 24, 2020
-
-
Maxim Mikityanskiy authored
Commit 8353fe6f ("Revert "staging: bcm2835-audio: Drop DT dependency"") reverts the upstream change and makes bcm2835-audio use device tree again, however, it also removes the MODULE_ALIAS for the platform device. This MODULE_ALIAS is needed, because VCHIQ registers bcm2835-audio as a child platform device since commit 25c7597a ("staging: vchiq_arm: Register a platform device for audio"), and this mechanism is adopted also in the downstream kernel. This commit puts back that MODULE_ALIAS to make bcm2835-audio autoprobing work again. The rest of VCHIQ children have their MODULE_ALIASes in place. Fixes: 8353fe6f ("Revert "staging: bcm2835-audio: Drop DT dependency"") Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
-