- 10 Jan, 2022 2 commits
-
-
Robert Schlabbach authored
Commit 98c65a3d ("media: si2157: add support for 1.7MHz and 6.1 MHz") introduced two bugs: The 6.1MHz setting was always used for any bandwidth less than 7MHz due to missing "else" keywords, and then the setting was not specified as decimal 10, but as hexadecimal 0x10, which makes the tuner refuse the tune command. In sum, it is not possible to tune to any channels of less than 7MHz bandwidth anymore. Add the missing "else" keywords and convert all bandwidth settings to decimal to avoid any future decimal vs. hexadecimal confusion. Remove the use of the undefined bandwidth setting 0x0f for bandwidths greater than 8MHz, which is also refused by the tune command, in favour of using the default bandwidth setting 8 for any bandwidths greater than 7MHz. Link: https://lore.kernel.org/linux-media/trinity-d0015ea1-1da5-4c7d-a75b-781fb26dc339-1641509387112@3c-app-gmx-bap68 Fixes: 98c65a3d ("media: si2157: add support for 1.7MHz and 6.1 MHz") Reported-by: Robert Schlabbach <robert_s@gmx.net> Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
-
Nathan Chancellor authored
When CONFIG_VIDEO_ATOMISP_ISP2401 is disabled, clang warns: ./drivers/staging/media/atomisp//pci/isp2400_input_system_local.h:32:40: error: redefinition of typedef 'input_system_cfg2400_t' is a C11 feature [-Werror,-Wtypedef-redefinition] typedef struct input_system_cfg2400_s input_system_cfg2400_t; ^ ./drivers/staging/media/atomisp//pci/input_system_local.h:22:40: note: previous definition is here typedef struct input_system_cfg2400_s input_system_cfg2400_t; ^ 1 error generated. input_system_cfg2400_t's typedef was copied from isp2400_input_system_local.h to input_system_local.h, rather than moved. Remove the one in isp2400_input_system_local.h so that there is no more warning, which can break the build under -Werror. Link: https://github.com/ClangBuiltLinux/linux/issues/1557 Link: https://lore.kernel.org/linux-media/20211227164243.2329724-1-nathan@kernel.org Fixes: 4005ecee ("media: atomisp: shift some structs from input_system_local") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
-
- 16 Dec, 2021 23 commits
-
-
Hans de Goede authored
Some sensors come with a variable-focus lens where the lens focus is controller by a VCM (Voice Coil Motor). If there is a VCM for the lens-focus, and if so which one, is described on the vcm_type field of the ACPI SSDB table. These VCMs are a second I2C device listed as an extra I2cSerialBusV2 resource in the same ACPI device as the sensor. The i2c-core-acpi.c code only instantiates an i2c-client for the first I2cSerialBusV2 resource. Add support for instantiating an i2c-client for the VCM with the type of the i2c-client set based on the SSDB vcm_type field. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans de Goede authored
Since cio2_bridge_init() may now return -EPROBE_DEFER it is best to call it before anything else. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans de Goede authored
On devices where things are not fully describe in devicetree (1) and where the code thus falls back to calling cio2_bridge_init(), the i2c-clients for any VCMs also need to be instantiated manually. The VCM can be probed by its driver as soon as the code instantiates the i2c-client and this probing must not happen before the PMIC is fully setup. Make cio2_bridge_init() return -EPROBE_DEFER when the PMIC is not fully-setup, deferring the probe of the ipu3-cio2 driver. This is a preparation patch for adding VCM enumeration support to the ipu3-cio2-bridge code. 1) Through embedding of devicetree info in the ACPI tables Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
-
Jernej Skrabec authored
Allwinner H6 has a Hantro G2 core used for VP9 decoding. It's not clear at this time if HEVC is also supported or not. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
Allwinner H6 contains older Hantro G2 core, primarly used for VP9 video decoding. It's unclear for now if HEVC is also supported. Describe its binding. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
It turns out that imx8m_vpu_g2_irq() doesn't depend on any platform specifics and can be used with other G2 platform drivers too. Move it to common code. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
Older G2 cores, like that in Allwinner H6, seem to have issue with latching postproc register values if this is first thing done in job. Moving that to the end solves the issue. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
Some older G2 cores uses slightly different register set for HEVC and VP9. Since vast majority of registers and logic is the same, it doesn't make sense to introduce another drivers. Add legacy_regs quirk and implement only VP9 changes for now. HEVC changes will be introduced later, if needed. Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
Some G2 variants need double buffering to be enabled in order to work correctly, like that found in Allwinner H6 SoC. Add platform quirk for that. Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
Some SoCs like Allwinner H6 use reset lines for resetting Hantro G2. Add support for them. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
If clocks for some reason couldn't be enabled, probe function returns immediately, without disabling PM. This obviously leaves PM ref counters unbalanced. Fix that by jumping to appropriate error path, so effects of PM functions are reversed. Fixes: 775fec69 ("media: add Rockchip VPU JPEG encoder driver") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Martin Kepplinger authored
In cases like this when controlling regulators and clocks the suspend() and resume() functions are meant to be called balanced toggling the behaviour. It's wrong to use the same suspend function for runtime and system suspend in this case and leads to errors like [ 77.718890] Failed to disable vddd: -EIO Use pm_runtime_force_* helpers in order to support system suspend properly when runtime pm is already implemented and fix this. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Martin Kepplinger authored
regulator_bulk_disable can fail and thus suspend() can. Handle that error gracefully. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bingbu Cao authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Kao, Arec <arec.kao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bingbu Cao authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bingbu Cao authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bingbu Cao authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bingbu Cao authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
If powering on the sensor failed, the entire power-off sequence was run independently of how far the power-on sequence proceeded before the error. This lead to disabling regulators and/or clock that was not enabled. Fix this by disabling only clocks and regulators that were enabled previously. Fixes: 11c0d8fd ("media: i2c: Add support for the OV8865 image sensor") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jean-Michel Hautbois authored
While parsing the RAW AWB metadata, the AWB layout was missing to fully understand which byte corresponds to which feature. Make the field names and usage explicit, as it is used by the userspace applications. [Sakari Ailus: Changed wording of sat_ratio field as per review comments, fixed a whitespace issue.] Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Hyungwoo's e-mail no longer works so I presume he's left the company. Drop Hyungwoo as maintainer on ov5670 driver and remove his e-mail from other sensor drivers. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Merge tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into media_tree Signed tag for the immutable platform-drivers-x86-int3472 branch This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data and INT3472 driver patches. * tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: int3472: Deal with probe ordering issues platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell platform/x86: int3472: Add get_sensor_adev_and_name() helper platform/x86: int3472: Split into 2 drivers platform_data: Add linux/platform_data/tps68470.h file i2c: acpi: Add i2c_acpi_new_device_by_fwnode() function i2c: acpi: Use acpi_dev_ready_for_enumeration() helper ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
-
- 14 Dec, 2021 15 commits
-
-
Mauro Carvalho Chehab authored
This device also supports ATV, as it has the same API for setting analog TV tuning parameters. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Some tuners allow setting the bandwidth filter to 1.7MHz and 6.1 MHz. Add support for it upstream, as the narrower is the bandwidth filter, the better. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Those two delivery systems are supported by some of the si2146 tuners, but the current code is missing the setup for those. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
The driver should be capable of autodetecting its type, so no need to pass it via device driver's data. While here, improve documentation of some of the part_id specific code. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Each chip at the si21xx TER family seems to have a different firmware, with seems to actually be a patch against the ROM code. Rework the code in order to use different firmware files depending on the chip ID and rom ID. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Loading a firmware file should not be mandatory, as devices could work with an eeprom firmware, if available. Yet, using the eeprom firmware could lead into unpredictable results, so the best is to warn about that. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Robert Schlabbach authored
The Si2157 (A30) is functional with the ROM firmware 3.0.5, but can also be patched at runtime, e.g. to firmware 3.1.3. However, although a firmware filename for its firmware patch exists, that has only been used for the Si2177 (A30) so far (which indeed takes the binary identical firmware patch). Add support for downloading firmware patches into the Si2157 (A30), but make it optional, so that initialization can succeed with and without a firmware patch being available. Keep the use of request_firmware() for this purpose rather than firmware_request_nowarn(), so that the warning in the log makes users aware that it is possible to provide a firmware for this tuner. The firmware patch is probably also optional for other (if not all) tuners supported by the driver, but since I do not have the others available to test, they are kept mandatory for now to avoid regressions. Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Split the firmware load code from si2157_init, in order to help to add further changes at the way firmware is handled on this device. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
gushengxian authored
On some places, there's a missing whitespace. Link: https://lore.kernel.org/linux-media/20210526075527.302903-1-13145886936@163.com Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, gushengxian <gushengxian@yulong.com> Signed-off-by: gushengxian <gushengxian@yulong.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jason Wang authored
Static variables do not need to be initialised to 0, because compiler will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Link: https://lore.kernel.org/linux-media/20211212070918.289617-1-wangborong@cdjrlc.comSigned-off-by: Jason Wang <wangborong@cdjrlc.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andy Shevchenko authored
There is no evidence we need kernel.h inclusion in certain headers. Drop unneeded <linux/kernel.h> inclusion from other headers. Link: https://lore.kernel.org/linux-media/20211210120201.35635-1-andriy.shevchenko@linux.intel.comSigned-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Minghao Chi authored
return value form directly instead of taking this in another redundant variable. Link: https://lore.kernel.org/linux-media/20211210024721.425145-1-chi.minghao@zte.com.cnReported-by: Zeal Robot <zealci@zte.com.cm> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
chiminghao authored
return value form directly instead of taking this in another redundant variable. Link: https://lore.kernel.org/linux-media/20211209015009.409428-1-chi.minghao@zte.com.cnReported-by: Zeal Robot <zealci@zte.com.cm> Signed-off-by: chiminghao <chi.minghao@zte.com.cn> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Niklas Söderlund authored
Use the dev_err_probe() helper, instead of open-coding the same operation. While at it retrieve the error once and use it from 'ret' instead of retrieving it twice. Link: https://lore.kernel.org/linux-media/20211208121756.3051565-1-niklas.soderlund+renesas@ragnatech.seSuggested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Niklas S\xF6derlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dan Carpenter authored
The configure_channels() function has a double free because configure_memdma_and_inputblock() calls free_input_block() and then it's called again in the error handling code. Link: https://lore.kernel.org/linux-media/20211208073544.GA22020@kili Fixes: c5f5d0f9 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-