- 25 Nov, 2022 40 commits
-
-
Jacopo Mondi authored
Refuse unsupported controls by returning -EINVAL in the s_ctrl operation. While at it, remove a the default switch case in the first switch as it effectively is now a no-op. Signed-off-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Jacopo Mondi authored
Rework the PLL computation procedure to take into account the currently configured format bpp and the number of data lanes. Comment the PLL configuration procedure with information provided by the sensor chip manual and remove the hardcoded divider from the pixel clock calculation. Signed-off-by:
-
Jacopo Mondi authored
Change the largest visibile resolution to 2592x1944, which corresponds to the active pixel array area size. Take into account the horizontal and vertical limits when programming the visible sizes to skip dummy/inactive pixels. Signed-off-by:
-
Jacopo Mondi authored
Add support for V4L2_CID_ANALOG_GAIN. The control programs the global gain register which applies to all color channels. Signed-off-by:
-
Jacopo Mondi authored
Implement the enum_frame_size pad operation. The sensor supports a continuous size range of resolutions. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
Marek Vasut authored
The MT9P006 sensor driver sporadically fails to probe because the sensor responds with a NACK condition to I2C address on the bus during an attempt to read the sensor MT9P031_CHIP_VERSION register in mt9p031_registered(). Neither the MT9P006 nor MT9P031 datasheets are clear on reset signal timing. Older MT9M034 [1] datasheet provides those timing figures in Appendix-A and indicates it is necessary to wait 850000 EXTCLK cycles before starting any I2C communication. Add such a delay, which does make the sporadic I2C NACK go away, so it is likely similar constraint applies to this sensor. [1] https://www.onsemi.com/pdf/datasheet/mt9m034-d.pdfSigned-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
Now that a header exists with macros for the media interface bus-type values, replace hardcoding numerical constants with the corresponding macros in the DT binding examples. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Laurent Pinchart authored
Add a new dt-bindings/media/video-interfaces.h header that defines macros corresponding to the bus types from media/video-interfaces.yaml. This allows avoiding hardcoded constants in device tree sources. Signed-off-by:
Paul Elder <paul.elder@ideasonboard.com> Signed-off-by:
-
Marek Vasut authored
The mt9p031_init_cfg() already calls __mt9p031_get_pad_crop(), which correctly calls v4l2_subdev_get_try_crop() on V4L2_SUBDEV_FORMAT_TRY or returns &mt9p031->crop on V4L2_SUBDEV_FORMAT_ACTIVE. No need to call v4l2_subdev_get_try_crop() in mt9p031_init_cfg() again in case of both V4L2_SUBDEV_FORMAT_TRY and V4L2_SUBDEV_FORMAT_ACTIVE. This also fixes a splat generated by this call since commit 2ba3e385 ("media: v4l: subdev: Fail graciously when getting try data for NULL state") because v4l2_subdev_get_try_crop() is called with sd_state = NULL in mt9p031_init_cfg(). Fixes: 69681cd0 ("media: mt9p031: Move open subdev op init code into init_cfg") Signed-off-by:
-
Dave Stevenson authored
The sensor takes 3 supply rails - AVDD, DVDD, and DOVDD. Add hooks into the regulator framework for each of these regulators. Signed-off-by:
-
Dave Stevenson authored
The OV9282 image sensor takes 3 voltage supplies, so define the relevant regulators. Signed-off-by:
-
Benjamin Mugnier authored
Previously regulators were enabled on probe and never again. However, as regulators are disabled on power off. After a second power off the regulator counter will underflow. Plus regulators are not required for probing the sensor, but for streaming. Fix this by enabling regulators on power on to balance regulator counter properly. Signed-off-by:
Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of 'if (!ret)' switch to "check for the error first" rule. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
Add missed \n to the end of the messages. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Andy Shevchenko authored
Switch to use dev_err_probe() to simpify error path and unify message template. While at it, add missed \n to the end of the messages. Signed-off-by:
-
Andy Shevchenko authored
In some cases it might hide real bugs, in most cases here it's just redundant as it's being reassigned immediately after initial assignment. Signed-off-by:
-
Andy Shevchenko authored
fwnode API does proper checks and returns correct codes, no need to repeat it in the caller. Signed-off-by:
-
Andy Shevchenko authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less heavier for builds than the use of __maybe_unused attributes. Signed-off-by:
-
Andy Shevchenko authored
The struct i2c_client pointer is used only to get driver data, associated with a struct device or print messages on behalf. Moreover, the very same pointer to a struct device is already assigned by a regmap and can be retrieved from there. No need to keep a duplicative pointer. Signed-off-by:
-
Marco Felsch authored
Still there are archs/platforms which do not support the common clk framework. If such a platform is used in combination with the module enabled the compiler will throw an error. Since the clock has stubs if not selected we can drop it, so it is up to the arch/platform to select the correct clock framework. Fixes: 80a21da3 ("media: tc358746: add Toshiba TC358746 Parallel to CSI-2 bridge driver") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Christophe JAILLET authored
<linux/lcm.h> is not needed for this driver. Remove the corresponding #include. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Ian Cowan authored
The cacheflush import is never used, so it is safe to remove it as an import. Signed-off-by:
Ian Cowan <ian@linux.cowan.aero> Signed-off-by:
-
Laurent Pinchart authored
The imx7-media-csi driver, currently in staging, is ready for prime-time. The staging TODO file lists a few items specific to that driver, that are already addressed (the "all of the above" part) or can be addressed later: - The frame interval monitoring support is a software mechanism to monitor the device for unexpected stalls, and should be part of the V4L2 core if desired. - Restricting the support media bus formats based on the SoC integration only aims at reducing userspace confusion by not enumerating options that are known not to be possible, it won't cause regressions if handled later. Move the description of the media bus format restriction TODO item to the driver, drop the other TODO items, and move the driver out of staging. Signed-off-by:
Rui Miguel Silva <rmfrfs@gmail.com> Tested-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
Laurent Pinchart authored
The imx8mq-mipi-csi2 driver targets SoCs that also run the imx7-media-csi driver, but they are distinct. Decouple them in Kconfig to prepare for destaging of the imx7-media-csi driver. Signed-off-by:
-
Laurent Pinchart authored
Commit 9babbbaa ("media: imx: imx7-media-csi: Use dual sampling for YUV 1X16") set BIT_MIPI_DOUBLE_CMPNT in the CR18 register for 16-bit YUV formats in imx7_csi_configure(). The CR18 register is always updated with read-modify-write cycles, so if a 16-bit YUV format is selected, the bit will stay set forever, even if the format is changed. Fix it by clearing the bit at the beginning of the imx7_csi_configure() function. While at it, swap two of the bits being cleared to match the MSB to LSB order. This doesn't cause any functional change. Fixes: 9babbbaa ("media: imx: imx7-media-csi: Use dual sampling for YUV 1X16") Signed-off-by:
-
Laurent Pinchart authored
All the phys variables and structure fields store a DMA address, not a physical address. Even if the two are effectively identical on all platforms where this driver is used due to the lack of IOMMU, rename the variables to dma_addr to make their usage clearer. Signed-off-by:
-
Laurent Pinchart authored
The phys variable is only used as a local loop variable in imx7_csi_setup_vb2_buf(), with each entry in the array being used in the corresponding iteration of the loop only. Move it to loop scope, simplifying the array to a single variable. Signed-off-by:
-
Paul Elder authored
The CSI hardware compatible with this driver handles buffers using a ping-pong mechanism with two sets of destination addresses. Normally, when an interrupt comes in to signal the completion of one buffer, say FB1, it assigns the next buffer in the queue to the next FB1, and the hardware starts to capture into FB2 in the meantime. In a buffer underrun situation, in the above example without loss of generality, if a new buffer is queued before the interrupt for FB1 comes in, we can program the buffer into FB2 (which is programmed with a dummy buffer, as there is a buffer underrun). This of course races with the interrupt that signals FB1 completion, as once that interrupt comes in, we are no longer guaranteed that the programming of FB2 was in time and must assume it was too late. This race is resolved partly by locking the programming of FB2. If it came after the interrupt for FB1, then the variable that is used to determine which FB to program would have been swapped by the interrupt handler. This alone isn't sufficient, however, because the interrupt could still be generated (thus the hardware starts capturing into the other fb) while the fast-tracking routine has the irq lock. Thus, after programming the fb register to fast-track the buffer, the isr also must be checked to confirm that an interrupt didn't come in the meantime. If it has, we must assume that programming the register for the fast-tracked buffer was not in time, and queue the buffer normally. Signed-off-by:
-
Christophe JAILLET authored
<linux/gcd.h> is not needed for this driver. Remove the corresponding #include. Signed-off-by:
-
git://linuxtv.org/hverkuil/media_treeMauro Carvalho Chehab authored
Tag branch * tag 'br-v6.2f' of git://linuxtv.org/hverkuil/media_tree: (26 commits) media: atmel: atmel-isc: move to staging media: microchip: microchip-isc: move media_pipeline_* to (un)prepare cb media: microchip: microchip-isc: implement media controller media: microchip: microchip-isc: prepare for media controller support media: microchip: add ISC driver as Microchip ISC media: atmel: move microchip_csi2dc to dedicated microchip platform vb2/au0828: move the v4l_vb2q_enable_media_source to the au0828 driver vb2: add (un)prepare_streaming queue ops media: admin-guide: cec.rst staging: media: sunxi: cedrus: make vb2_ops struct definition const media: amphion: Fix error handling in vpu_driver_init() media: platform: exynos4-is: Fix error handling in fimc_md_init() media: mtk-jpegdec: add missing destroy_workqueue() media: aspeed: Use v4l2_dbg to replace v4l2_warn to avoid log spam media: solo6x10: fix possible memory leak in solo_sysfs_init() media: cedrus: Relax HEVC SPS restrictions media: cedrus: h265: Support decoding 10-bit frames media: cedrus: Adjust buffer size based on codec media: s5p-mfc: Optimisation of code to remove error message media: s5p-mfc:fix usage of Block comment alignment ... Signed-off-by:
-
Andy Shevchenko authored
The list contains the Bayer scale index, and rational fraction of it. The struct u32_fract is suitable type to hold that. Convert the driver to use latter instead of former. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
The ov2680_720p_30fps register init list used for the 1296x736 resolution sets the hsize register to 1296 and the vsize register to 736. This is actually the right thing to do when combined with the atomISP2 because the ISP requires 16 bytes padding leaving userspace to see 1280x720. But the resolution list entries for this was incorrectly reporting the resolution being send to the ISP as already being 1280x720, leaving usespace to see 1274x704 as resolution. Worse then userspace seeing a weird resolution selecting the 1280x720 sensor resolution (which in reality is sending 1296x736) to the ISP was causing the ISP to hang on Cherry Trail based tablets (Bay Trail works fine for some reason). This commit also adds a bunch of comments annotating what the various register writes the init lists are doing. Reviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
-
Hans de Goede authored
atomisp_ospm_dphy_up() is an empty function now and atomisp_ospm_dphy_down() contains a couple of checks + goto done statements which don't matter since the function always ends up at the done label regardless and then it does 1 pci-config write. Move the single pci-config write directly to atomisp_power_off() and remove the atomisp_ospm_dphy_up()/_down() functions. Reviewed-by:
-
Hans de Goede authored
The only thing which atomisp_ospm_dphy_down() does is disable the CSI pins, but if we failed to probe the ISP then these will never have been enabled (because the ISP never started streaming). So the atomisp_ospm_dphy_down() call in the probe error path is unnecessary, remove it. Reviewed-by:
-
Hans de Goede authored
atomisp_css_init() is always called after calling atomisp_power_on() either directly or through getting a runtime-pm reference. Likewise atomisp_css_uninit() is always called after calling atomisp_power_off(). Move the call site of these 2 functions to inside atomisp_power_on() / atomisp_power_off() to make this more explicit. Note this makes atomisp_reset() also set isp_fatal_error on atomisp_power_on() errors, where as before it only did this on atomisp_css_init() errors. This behavior change is for the better, since power-on failing is pretty fatal too. Reviewed-by:
-
Hans de Goede authored
atomisp_suspend() contains a 1:1 copy of atomisp_runtime_suspend() and the same goes for the resume() functions. Rename the runtime functions to atomisp_power_on()/_off() and use these as runtime-pm handlers as well as helper in other places to remove the code duplication. Reviewed-by:
-
Hans de Goede authored
Remove the unnecessary sw_contex.power_state checks: 1. atomisp_freq_scaling() and atomisp_stop_streaming() only run when the ISP is powered up through runtime-pm, so the checks are not necessary 2. atomisp_mrfld_pre_power_down() and atomisp_runtime_resume() are only called through the driver-core pm handling code which already guarantees they are not called when already powered down / up. 3. atomisp_isr() also checks isp->css_initialized which only gets set by atomisp_css_init() which runs *after* powering up the ISP and which gets cleared by atomisp_css_uninit() *before* powering down the ISP. So all the checks are unnecessary, remove them as well as the sw_contex.power_state field itself. Reviewed-by:
-
Hans de Goede authored
atomisp_css_suspend() is a 1:1 copy of atomisp_css_uninit() and atomisp_css_resume() is a 1:1 copy of atomisp_css_init(). Remove the 2 copies and have their one caller just call atomisp_css_uninit() / atomisp_css_init() instead. Reviewed-by:
-
Hans de Goede authored
atomisp_css_uninit() only runs when all streams are stopped and atomisp_css_stop() already clears the config, so the clearing of the config can be dropped from atomisp_css_uninit(). Reviewed-by:
-
Hans de Goede authored
atomisp_mrfld_power_down()/_up() are unnecessary wrappers around atomisp_mrfld_power() remove them and just call atomisp_mrfld_power() directly. Reviewed-by:
-
