- 04 May, 2018 40 commits
-
-
Daniel Scheller authored
Introduce the ddb_msi_exit() helper to be used for cleaning up previously allocated MSI IRQ vectors. Deduplicates code and makes things look cleaner as for all cleanup work the CONFIG_PCI_MSI ifdeffery is only needed in the helper now. Also, replace the call to the deprecated pci_disable_msi() function with pci_free_irq_vectors(). Picked up from the upstream dddvb-0.9.33 release. Signed-off-by:
Daniel Scheller <d.scheller@gmx.net> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Daniel Scheller authored
Move the ddbridge module initialisation and cleanup code to ddbridge-core and set up the ddb_wq workqueue there, and create and destroy the ddb device class there aswell. Due to this, the prototypes for ddb_wq, ddb_class_create() and ddb_class_destroy() aren't required in ddbridge.h anymore, so remove them. Also, declare ddb_wq and the ddb_class_*() functions static. Picked up from the upstream dddvb-0.9.33 release. Signed-off-by:
-
Daniel Scheller authored
Besides the 'msi' module option, all options are used from within ddbridge-core only, so move them over from ddbridge-main, and declare the associated variables static. Since the prototypes in ddbridge.h aren't necessary anymore now, remove them. As a side effect, this has the benefit of aligning things more with the dddvb upstream. Signed-off-by:
-
Daniel Scheller authored
The CNR value determined in read_snr() is reported via the wrong variable. It uses FE_SCALE_DECIBEL, which implies the value to be reported in svalue instead of uvalue. Fix this accordingly. Picked up from the upstream dddvb-0.9.33 release. Signed-off-by:
-
Daniel Scheller authored
The TSINSDEL registers were lacking initialisation in the stv0910 demod driver. Initialise them (both demods) in the probe() function. Picked up from the upstream dddvb-0.9.33 release. Signed-off-by:
-
Mauro Carvalho Chehab authored
After adding this driver, gcc complains with: drivers/media/i2c/video-i2c.c:55:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration] const static struct v4l2_fmtdesc amg88xx_format = { ^~~~~ drivers/media/i2c/video-i2c.c:59:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration] const static struct v4l2_frmsize_discrete amg88xx_size = { ^~~~~ Signed-off-by: -
Mauro Carvalho Chehab authored
Now that FB_OMAP has stubs, the omap2 media drivers can be built on ARM with COMPILE_TEST && DRM_OMAP. Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'. That allows building such driver(s) with COMPILE_TEST. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Despite depending on ACPI, this driver builds fine on non-x86 archtecture with COMPILE_TEST, as it doesn't depend on ACPI-specific functions/structs. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
The pnp header already provide enough stub to build those drivers with COMPILE_TEST on non-x86 archs. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
This driver doesn't use any weird API. So, allow building it with COMPILE_TEST. Signed-off-by:
-
Mauro Carvalho Chehab authored
Several radio devices only build on i386, because they depend on ISA. Allow them to build on other archs by adding a COMPILE_TEST check. Signed-off-by:
-
Mauro Carvalho Chehab authored
Coverity complains about werid stuff at the debug logic: CID 113542 (#1 of 1): Out-of-bounds access (ARRAY_VS_SINGLETON)10. callee_ptr_arith: Passing buf to function flexcop_i2c_write4 which uses it as an array. This might corrupt or misinterpret adjacent memory locations. Instead of directly addressing the issue there, let's rework at the logic there. On newer kernels, KERN_CONT does nothing, as the previous message won't wait for a continuation. Also, both flexcop_i2c_read4() and flexcop_i2c_write4(), called by it, will print stuff if (debug &4). So, the way it is is too buggy. There are two kinds of debug stuff there: deb_i2c() and a code hidden under #ifdef DUMP_I2C_MESSAGES, with can't be selected without touching the source code. Also, if both debug & 0x4 and DUMP_I2C_MESSAGES, flexcop_i2c_request() will emit two debug messages per call with different data, with sounds messy. Simplify it by getting rid of DUMP_I2C_MESSAGES and adding a new flag to debug (0x40), and making the debug logic there more consistent. Signed-off-by:
-
Mauro Carvalho Chehab authored
As warned by Coverity: CID 1415211 (#1 of 1): Unused value (UNUSED_VALUE)assigned_value: Assigning value -22 to ret here, but that stored value is overwritten before it can be used. On all cases where the there's a goto 'unlock_out' or 'streamof', ret was filled with a non-sero value. It toesn't make sense to override such error code with a videobuf_streamoff() error. Signed-off-by:
-
Mauro Carvalho Chehab authored
Changeset be7fd3c3 ("media: em28xx: Hauppauge DualHD second tuner functionality") introduced a potential NULL pointer dereference, as pointed by Coverity: CID 1434731 (#1 of 1): Dereference after null check (FORWARD_NULL)16. var_deref_op: Dereferencing null pointer ops->resume. var_compare_op: Comparing ops->resume to null implies that ops->resume might be null. 1174 if (ops->resume) 1175 ops->resume(dev); 1176 if (dev->dev_next) 1177 ops->resume(dev->dev_next); Fixes: be7fd3c3 ("media: em28xx: Hauppauge DualHD second tuner functionality") Signed-off-by:
-
Mauro Carvalho Chehab authored
Building this driver on arm64 gives this warning: drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error: return expression in void function Signed-off-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Right now, at siano driver, all places where devpath is defined has sizeof(devpath) == 32. So, there's no practical risc of going past devpath array anywhere. Still, code changes might cause troubles. It also confuses Coverity: CID 139059 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 9. fixed_size_dest: You might overrun the 32-character fixed-size string entry->devpath by copying devpath without checking the length. 10. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. So, explicitly limit strcmp() and strcpy() to ensure that the devpath size (32) will be respected. Signed-off-by:
-
Mauro Carvalho Chehab authored
Those are all false-positives that appear with smatch when building for arm: drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32 drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16 drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16 Get rid of them by adding explicit forced casts. Signed-off-by:
-
Anders Roxell authored
Commit 7378f114 ("media: omap2: omapfb: allow building it with COMPILE_TEST") broke compilation without CONFIG_OF selected. CC drivers/video/fbdev/core/fbmem.o drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c: In function ‘omapdss_update_prop’: drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c:68:2: error: implicit declaration of function ‘of_update_property’; did you mean ‘of_get_property’? [-Werror=implicit-function-declaration] of_update_property(node, prop); ^~~~~~~~~~~~~~~~~~ of_get_property cc1: some warnings being treated as errors scripts/Makefile.build:312: recipe for target 'drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o' failed make[7]: *** [drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o] Error 1 scripts/Makefile.build:559: recipe for target 'drivers/video/fbdev/omap2/omapfb/dss' failed make[6]: *** [drivers/video/fbdev/omap2/omapfb/dss] Error 2 make[6]: *** Waiting for unfinished jobs.... Add OF dependency in order to make all configurations work again. of_update_property() has no inline stub, and that that could be added as an alternative. Signed-off-by:
Anders Roxell <anders.roxell@linaro.org> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by:
-
Sean Young authored
Both Hauppauge WinTV 44981 (bt878) and the HVR 1110 (saa7134) have a Zilog Z8F0811. The transmitter was not probed. Receive and transmit tested on both cards. Signed-off-by:
-
Sean Young authored
The iMON PAD controller has a analog stick, which can be switched to keyboard mode (cursor keys) or work as a crappy mouse. Signed-off-by:
-
Sean Young authored
The raw_register function exists to create input devices associated with that IR protocol. If the mce_kbd module is loaded, then every rc device will have mce_kbd input devices, even if the protocol is not enabled. Change this to call the register function to when the protocol is enabled. Signed-off-by:
-
Laurent Pinchart authored
Some VSP instances have two blending units named BRU (Blend/ROP Unit) and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU with only two inputs, but otherwise offers similar features and offers the same register interface. The BRU and BRS can be used exchangeably in VSP pipelines (provided no more than two inputs are needed). Due to historical reasons, the VSP1 driver implements support for both the BRU and BRS through objects named vsp1_bru. The code uses the name BRU to refer to either the BRU or the BRS, except in a few places where noted explicitly. This creates confusion. In an effort to avoid confusion, rename the vsp1_bru object and the corresponding API to vsp1_brx, and use BRx to refer to blend unit instances regardless of their type. The names BRU and BRS are retained where reference to a particular blend unit type is needed, as well as in hardware registers to stay close to the datasheet. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
Dynamic assignment of the BRU and BRS to pipelines is prone to regressions, add messages to make debugging easier. Keep it as a separate commit to ease removal of those messages once the code will deem to be completely stable. Signed-off-by:
-
Laurent Pinchart authored
The VSPDL variant drives two DU channels through two LIF and two blenders, BRU and BRS. The DU channels thus share the five available VSPDL inputs and expose them as five KMS planes. The current implementation assigns the BRS to the second LIF and thus artificially limits the number of planes for the second display channel to two at most. Lift this artificial limitation by assigning the BRU and BRS to the display pipelines on demand based on the number of planes used by each pipeline. When a display pipeline needs more than two inputs and the BRU is already in use by the other pipeline, this requires reconfiguring the other pipeline to free the BRU before processing, which can result in frame drop on both pipelines. Signed-off-by:
-
Laurent Pinchart authored
When disabling a DRM plane, the corresponding RPF is only marked as removed from the pipeline in the atomic update handler, with the actual removal happening when configuring the pipeline at atomic commit time. This is required as the RPF has to be disabled in the hardware, which can't be done from the atomic update handler. The current implementation is RPF-specific. Make it independent of the entity type by using the entity's pipe pointer to mark removal from the pipeline. This will allow using the mechanism to remove BRU instances. Signed-off-by:
-
Laurent Pinchart authored
Display list completion is already reported to the frame end handler, but that mechanism is global to all display lists. In order to implement BRU and BRS reassignment in DRM pipelines we will need to commit a display list and wait for its completion internally, without reporting it to the DRM driver. Extend the display list API to support such an internal use of the display list. Signed-off-by:
-
Laurent Pinchart authored
We will soon need to return more than a boolean completion status from the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a bitfield to prepare for that. No functional change is introduced here. Signed-off-by:
-
Laurent Pinchart authored
In order to make the vsp1_du_setup_lif() easier to read, and for symmetry with the DRM pipeline input setup, move the pipeline output setup code to a separate function. Signed-off-by:
-
Laurent Pinchart authored
The vsp1_du_setup_lif() function sets up the DRM pipeline input manually. This duplicates the code from the vsp1_du_pipeline_setup_inputs() function. Replace the manual implementation by a call to the function. As the pipeline has no enabled input in vsp1_du_setup_lif(), the vsp1_du_pipeline_setup_inputs() function will not setup any RPF, and will thus not setup formats on the BRU sink pads. This isn't a problem as all inputs are disabled, and the BRU sink pads will be reconfigured from the atomic commit handler when inputs will be enabled. Signed-off-by:
-
Laurent Pinchart authored
To implement fully dynamic plane assignment to pipelines, we need to reassign the BRU and BRS to the DRM pipelines in the atomic commit handler. In preparation for this setup factor out the BRU source pad code and call it both at LIF setup and atomic commit time. Signed-off-by:
-
Laurent Pinchart authored
The DRM pipeline setup code used at atomic commit time is similar to the setup code used when enabling the pipeline. Move it to a separate function in order to share it. Signed-off-by:
-
Laurent Pinchart authored
Move the duplicated DRM pipeline configuration code to a function and call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush(). Signed-off-by:
-
Laurent Pinchart authored
The DRM pipeline handling code uses the entity's pipe list head to check whether the entity is already included in a pipeline. This method is a bit fragile in the sense that it uses list_empty() on a list_head that is a list member. Replace it by a simpler check for the entity pipe pointer. Signed-off-by:
-
Laurent Pinchart authored
Various types of objects subclassing vsp1_entity currently store a pointer to the pipeline. Move the pointer to vsp1_entity to simplify the code and avoid storing the pipeline in more entity subclasses later. Signed-off-by:
-
Laurent Pinchart authored
The vsp1_drm_pipeline enabled field is set but never used. Remove it. Signed-off-by:
-
Laurent Pinchart authored
The DRM support code manages a pipeline of VSP entities, each backed by a media entity. When starting or stopping the pipeline, it starts and stops the media pipeline through the media API in order to store the pipeline pointer in every entity. The driver doesn't use the pipe pointer in media entities, neither does it rely on the other effects of the media_pipeline_start() and media_pipeline_stop() functions. Furthermore, as the media links for the DRM pipeline are never set up correctly, and as the pipeline can be modified dynamically when enabling or disabling planes, the current implementation is not correct. Remove the incorrect and unneeded code. While at it remove the outdated comment that states that entities are not started when the LIF is setup, as they now are. Signed-off-by:
-
Hugo Grostabussiat authored
Use the USBTV_TV_STD define instead of repeating ourselves. Signed-off-by:
Hugo Grostabussiat <bonstra@bonstra.fr.eu.org> Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Hugo Grostabussiat authored
Depending on the chosen standard, configure the decoder to use the appropriate color encoding standard (PAL-like, NTSC-like or SECAM). Until now, the decoder was not configured for a specific color standard, making it autodetect the color encoding. While this may sound fine, it potentially causes the wrong image tuning parameters to be applied (e.g. tuning parameters for NTSC are applied to a PAL source), and may confuse users about what the actual standard is in use. This commit explicitly configures the color standard the decoder will use, making it visually obvious if a wrong standard was chosen. Signed-off-by:
-
Hugo Grostabussiat authored
The user-supplied norm value gets overwritten by the generic .norm member from the norm_params. That way, we lose the specific norm the user may want to set. For instance, if the user specifies V4L2_STD_PAL_60, the value actually used will be V4L2_STD_525_60, which in the end will be as if the user had specified V4L2_STD_NTSC, since this is always the first bitfield we match the norm value against before configuring the hardware. The norm_params array is only there to match a norm with an output resolution. The norm value itself should not be changed. Signed-off-by:
-
