- 15 Apr, 2020 9 commits
-
-
Mauro Carvalho Chehab authored
There were some changes at the drivers adding support for more cards. Update cardlists accordingly. Signed-off-by:Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Guillaume Tucker authored
Include test_drivers/Kconfig when MEDIA_TEST_SUPPORT is enabled rather than MEDIA_PLATFORM_SUPPORT. Test drivers should not depend on platform drivers to be enabled. Reported-by:
"kernelci.org bot" <bot@kernelci.org> Fixes: 4b32216a ("media: split test drivers from platform directory") Signed-off-by:
Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Most CEC platform drivers are using VIDEO_*_CEC pattern, some with an _HDMI extension too. Well, they're not related to V4L2 support, and we don't really need those big config names. So drop VIDEO_* from them, remove _HDMI (if present) and move CEC to the start. This way, all platform driver options are now CEC_<driver>. Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
As CEC support doesn't depend on MEDIA_SUPPORT, let's place the platform drivers outside the media menu. As a side effect, instead of depends on USB, drivers just select it. Acked-by:
-
Mauro Carvalho Chehab authored
As CEC support doesn't depend on MEDIA_SUPPORT, let's place the platform drivers outside the media menu. As a side effect, instead of depends on PCI, seco driver can select it (and DMI). Acked-by:
-
Mauro Carvalho Chehab authored
The only item that opens at the CEC Kconfig menu is related to Remote Controller. Also, its support should not depend on media support, so it makes sense to keep both RC and CEC together. After this change, the main media menus that are visible under "Device Drivers" menu are: <*> Remote Controller support ---> [ ] HDMI CEC RC integration (NEW) < > HDMI CEC drivers <M> Multimedia support ---> Acked-by:
-
Mauro Carvalho Chehab authored
In preparation for moving CEC drivers to the CEC directory, move the core to a separate place. Acked-by:
-
Mauro Carvalho Chehab authored
As we reverted changeset 85f7cd3a ("Revert "media: Kconfig: better support hybrid TV devices""), we should add a default to DVB_CORE, as otherwise DVB support won't work. Fixes: 85f7cd3a ("Revert "media: Kconfig: better support hybrid TV devices"") Signed-off-by:
-
Mauro Carvalho Chehab authored
The CEC_CORE symbols are selected by DRM, and should be independent of MEDIA_SUPPORT. Fixes this warning when doing "make multi_v7_defconfig": WARNING: unmet direct dependencies detected for CEC_CORE Depends on [m]: MEDIA_SUPPORT [=m] Selected by [y]: - DRM_TEGRA [=y] && HAS_IOMEM [=y] && (ARCH_TEGRA [=y] || ARM [=y] && COMPILE_TEST [=n]) && COMMON_CLK [=y] && DRM [=y] && OF [=y] && CEC_NOTIFIER [=y] Selected by [m]: - VIDEO_SAMSUNG_S5P_CEC [=m] && MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && CEC_PLATFORM_DRIVERS [=y] && (ARCH_EXYNOS [=y] || COMPILE_TEST [=n]) - DRM_EXYNOS_HDMI [=y] && HAS_IOMEM [=y] && DRM_EXYNOS [=m] && (DRM_EXYNOS_MIXER [=y] || DRM_EXYNOS5433_DECON [=n]) && CEC_NOTIFIER [=y] - DRM_I2C_ADV7511_CEC [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && DRM_I2C_ADV7511 [=m] - DRM_DW_HDMI [=m] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && CEC_NOTIFIER [=y] This reverts commit f1991411. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 14 Apr, 2020 31 commits
-
-
Helen Koike authored
test_drivers/ folder is not being added by media Makefile, so it is not being compiled. Add test_drivers/ folder in Makefile folder's list. Fixes: 4b32216a ("media: split test drivers from platform directory") Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Some media files got moved. Update the corresponding references to the referenced files. Signed-off-by: -
Tomi Valkeinen authored
The stop-state timeout needs to be over 100us as per CSI spec. With the CAL fclk of 266 MHZ on DRA76, with the current value the driver uses, the timeout is 24us. Too small timeout will cause failure to enable the streaming. Also, the fclk can be different on other SoCs, as is the case with AM65x where the fclk is 250 MHz. This patch fixes the timeout by calculating it correctly based on the fclk rate. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Tomi Valkeinen authored
Sometimes there is a timeout when waiting for the Stop-State. Testing shows that sometimes we need to wait more than what the current code does. It is not clear how long this wait can be, but it is based on how quickly the sensor provides a valid clock, and how quickly CAL syncs to it. Change the code to make it more obvious how long we'll wait, and set a wider range for usleep_range. Increase the timeout to 750ms. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Tomi Valkeinen authored
Sometimes there is a timeout when waiting for the 'ComplexIO Reset Done'. Testing shows that sometimes we need to wait more than what the current code does. It is not clear how long this wait can be, but it is based on how quickly the sensor provides a valid clock, and how quickly CAL syncs to it. Change the code to make it more obvious how long we'll wait, and set a wider range for usleep_range. Increase the timeout to 750ms. Signed-off-by:
-
Tomi Valkeinen authored
To make csi2_wait_for_phy() more readable, move code to separate functions. Signed-off-by:
-
Tomi Valkeinen authored
Set DMA max seg size correctly to get rid of warnings on 64 bit platforms: DMA-API: cal 6f03000.cal: mapping sg segment longer than device claims to support [len=720896] [max=65536] Signed-off-by:
-
Tomi Valkeinen authored
CAL_CSI2_CTX register has LINES field, which, according to the documentation, should be programmed to the number of lines transmitted by the camera. If the number of lines is unknown, it can be set to 0. The driver sets the field to 0 for some reason, even if we know the number of lines. This patch sets the number of lines properly, which will allow the HW to discard extra lines (if the sensor would send such for some reason), and, according to documentation: "This leads to regular video timings and avoids potential artifacts". Signed-off-by:
-
Tomi Valkeinen authored
After ComplexIO reset, a dummy read to PHY is needed as per CAL spec to finish the reset. Currently the driver reads a ComplexIO register, not PHY register. Fix this. Signed-off-by:
-
Tomi Valkeinen authored
Move the code to enable and disable ComplexIO power to its own function. Signed-off-by:
-
Tomi Valkeinen authored
Simplify the code by using reg_write_field() where trivially possible. Signed-off-by:
-
Tomi Valkeinen authored
Remove a bunch of IRQ defines, of which only CAL_HL_IRQ_ENABLE and CAL_HL_IRQ_CLEAR are used, and these defines only end up obfuscating code. Signed-off-by:
-
Tomi Valkeinen authored
These macros only obfuscate the code, so drop them. Signed-off-by:
-
Tomi Valkeinen authored
Instead of having identical code block to handle irqs for the two CAL ports, we can have a for loop and a single code block. Signed-off-by:
-
Tomi Valkeinen authored
The driver does not print any errors on ComplexIO reset timeout or when waiting for stop-state, making it difficult to debug and notice problems. Add error prints for these cases. Signed-off-by:
-
Tomi Valkeinen authored
CAL reports various errors via IRQs, which are not handled at all by the current driver. Add code to enable and catch those IRQs and print errors. This will make it much easier to notice and debug issues with sensors. Signed-off-by:
-
Tomi Valkeinen authored
Now that cal_runtime_get and cal_runtime_put are only direct wrappers to pm_runtime_get/put, we can drop cal_runtime_get and cal_runtime_put. Signed-off-by:
-
Tomi Valkeinen authored
We need to do errata handling every time CAL is being enabled. The code is currently in cal_runtime_get(), which is not the correct place for it. Move the code to cal_runtime_resume, which is called every time CAL is enabled. Signed-off-by:
-
Tomi Valkeinen authored
i913_errata() sets a bit to 1 in PHY_REG10, but for some reason uses CAL_CSI2_PHY_REG0_HSCLOCKCONFIG_DISABLE for the bit value. The value of that macro is 1, so it works, but is still wrong. Fix this to 1. Signed-off-by:
-
Tomi Valkeinen authored
IRQENABLE_SET registers are (usually) not meant to be read, only written to. The current driver needlessly uses read-modify-write cycle to enable IRQ bits. The read-modify-write has no bad side effects here, but it's still better to clean this up by only using write. Signed-off-by:
-
Tomi Valkeinen authored
When the CAL driver stops streaming, it will shut everything down without waiting for the current frame to finish. This leaves the CAL DMA in a slightly undefined state, and when CAL DMA is enabled when the stream is started the next time, the old DMA transfer will continue. It is not clear if the old DMA transfer continues with the exact settings of the original transfer, or is it a mix of old and new settings, but in any case the end result is memory corruption as the destination memory address is no longer valid. I could not find any way to ensure that any old DMA transfer would be discarded, except perhaps full CAL reset. But we cannot do a full reset when one port is getting enabled, as that would reset both ports. This patch tries to make sure that the DMA transfer is finished properly when the stream is being stopped. I say "tries", as, as mentioned above, I don't see a way to force the DMA transfer to finish. I believe this fixes the corruptions for normal cases, but if for some reason the DMA of the final frame would stall a lot, resulting in timeout in the code waiting for the DMA to finish, we'll again end up with unfinished DMA transfer. However, I don't know what could cause such a timeout. Signed-off-by:
-
Laurent Pinchart authored
Implement the subdev pad .enum_mbus_code() operation to enumerate media bus codes on the sink and source pads. Signed-off-by:
Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
The imx7-mipi-csis only uses the imx_media_init_mbus_fmt() function from the imx-media-utils helpers. The helpers don't support all the media bus formats used by this driver, and are thus a bad fit. As the MIPI CSIS is a standalone IP core that could be integrated in other SoCs, let's not use the helper. Signed-off-by:
-
Laurent Pinchart authored
Remove unneeded includes, add needed ones, and sort them alphabetically. Signed-off-by:
-
Laurent Pinchart authored
The driver rejects enablement of multiple links on its source pad. This isn't needed, as the CSIS doesn't care. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The register macros at the top of the file have their value not aligned on the same column, hindering readability. Fix it. Signed-off-by:
-
Laurent Pinchart authored
The MIPI_CSIS_ISPCFG_ALIGN_32BIT bit enables output of 32-bit data. The driver sets it based on the select format, but no format uses a 32-bit bus width, so the bit is never set in practice. This isn't likely to change any time soon, as the CSI IP core connected at the output of the CSIS doesn't support 32-bit data width. Hardcode the bit to 0. Signed-off-by:
-
Laurent Pinchart authored
The total number of bits per line needs to be a multiple of 8, which requires aligning the image width based on the format width. The csis_pix_format structure contains a pix_width_alignment field that serves this purpose, but the field is never set. Instead of fixing that, calculate the alignment constraints based on the bus width for the format, and drop the unneeded pix_width_alignment field. Signed-off-by:
-
Laurent Pinchart authored
The csis_pix_format data_alignment field stores the bus width. Rename it accordingly. Signed-off-by:
-
Laurent Pinchart authored
Add support for 10-bit YUV 4:2:2. Signed-off-by:
-
Laurent Pinchart authored
The MEDIA_BUS_FMT_UYVY8_2X8 format reports a data alignment of 16 bits, which isn't correct as it is output on an 8-bit bus. Fix it. Signed-off-by:
-
