- 09 Aug, 2017 18 commits
-
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by:
-
Hans Verkuil authored
If cec_debug >= 1 then log why the requested mode returned -EINVAL. It can be hard to debug this since -EINVAL can be returned for many reasons. So this should help. Signed-off-by:
-
Hans Verkuil authored
The description of how messages are processed by the core was not always very clear. Reword it to improve this. In particular for the USER_CONTROL_* messages a critical bit was missing in that the core also checks for the CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU flag. This was confusing. Signed-off-by:
-
Hans Verkuil authored
`CEC_LOG_ADDRS_FL_CDC_ONLY` should be ``CEC_LOG_ADDRS_FL_CDC_ONLY``. Signed-off-by:
-
Hans Verkuil authored
Use the new CEC_CAP_DEFAULTS define in the adv, vivid, pulse8 and rainshadow CEC drivers. Signed-off-by:
-
Hans Verkuil authored
The CEC_CAP_LOG_ADDRS, CEC_CAP_TRANSMIT, CEC_CAP_PASSTHROUGH and CEC_CAP_RC capabilities are normally always present. Add a CEC_CAP_DEFAULTS define that ORs these four caps to simplify drivers. Signed-off-by:
-
Hans Verkuil authored
gcc can get confused by this code and it thinks dev_features can be returned uninitialized. So initialize to NULL at the beginning to shut up the warning. Signed-off-by:
-
- 08 Aug, 2017 22 commits
-
-
Hans Verkuil authored
The SMPTE-2084 transfer functions maps to the luminance range of 0-10000 cd/m^2. Other transfer functions use the traditional range of 0-100 cd/m^2. I didn't take this into account so the luminance was off by a factor of 100. Since qv4l2 made the same mistake in reverse I never noticed this until I tested with actual SMPTE-2084 video. Signed-off-by:
-
Jan Luebbe authored
The on-chip SRAM of i.MX6S is only 128 KiB. 4 KiB of that are allocated for suspend to RAM since commit df595746 ("ARM: imx: add suspend in ocram support for i.mx6q"). Reduce the requested IRAM size to 124 KiB to avoid an allocation failure that causes the coda driver to not use the SRAM at all. Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
coda_command_sync calls coda_command_async, which writes the bit_stream_param context variable into the BIT_STREAM_PARAM register, overwriting the previously set value during coda_start_decoding. Instead of writing to the register, set bit_stream_param to ensure that the decoder sequence init command is executed with the escape flag set. Signed-off-by:
-
Arnd Bergmann authored
While looking at a compiler warning, I noticed the use of IS_ERR_OR_NULL, which is generally a sign of a bad API design and should be avoided. In this driver, this is fairly easy, we can simply stop storing error pointers in persistent structures, and change the two functions that might return either a NULL pointer or an error code to consistently return error pointers when failing. of_parse_subdev() now separates the error code and the pointer it looks up, to clarify the interface. There are two cases where this function originally returns 'NULL', and I have changed that to '0' for success to keep the current behavior, though returning an error would also make sense there. Fixes: e1302912 ("[media] media: Add i.MX media core driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Steve Longerbeam <steve_longerbeam@mentor.com> Tested-by:
-
kbuild test robot authored
drivers/media/i2c/ov5670.c:2033:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Hirokazu Honda authored
Some debug output whose log level is set 1 flooded the log. Their log level is lowered to find the important log easily. Signed-off-by:
Hirokazu Honda <hiroh@chromium.org> Signed-off-by:
-
Hans Verkuil authored
Various references to open() et al were wrong. Fix this so following the link will get you to the correct place. Signed-off-by:
-
Arnd Bergmann authored
Passing uninitialized flags into device_prep_interleaved_dma is clearly a bad idea, and we get a compiler warning for it: drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_prepare_vrfb': drivers/media/platform/omap/omap_vout_vrfb.c:273:5: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized] It seems that the OMAP dmaengine ignores the flags, but we should pick the right ones anyway. This sets the flags I guessed based on what other drivers used, and Peter confirmed that they are the right ones. Fixes: 6a1560ec ("media: v4l: omap_vout: vrfb: Convert to dmaengine") Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Arnd Bergmann authored
__WARN() cannot be used in portable code, since it is only available on some architectures and configurations: drivers/media/platform/pxa_camera.c: In function 'pxa_mbus_config_compatible': drivers/media/platform/pxa_camera.c:642:3: error: implicit declaration of function '__WARN'; did you mean '__WALL'? [-Werror=implicit-function-declaration] The common way to express an unconditional warning is WARN_ON(1), so let's use that here. Fixes: 97bbdf02 ("media: v4l: Add support for CSI-1 and CCP2 busses") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Arnd Bergmann authored
The new ov5670 driver fails to build when VIDEO_V4L2_SUBDEV_API or MEDIA_CONTROLLER are disabled: drivers/media/i2c/ov5670.c: In function 'ov5670_open': drivers/media/i2c/ov5670.c:1917:5: error: implicit declaration of function 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'? [-Werror=implicit-function-declaration] v4l2_subdev_get_try_format(sd, fh->pad, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~ v4l2_subdev_notify_event drivers/media/i2c/ov5670.c:1917:38: error: 'struct v4l2_subdev_fh' has no member named 'pad' v4l2_subdev_get_try_format(sd, fh->pad, 0); ^~ drivers/media/i2c/ov5670.c: In function 'ov5670_do_get_pad_format': drivers/media/i2c/ov5670.c:2198:17: error: invalid type argument of unary '*' (have 'int') fmt->format = *v4l2_subdev_get_try_format(&ov5670->sd, cfg, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fmt->pad); ~~~~~~~~~ drivers/media/i2c/ov5670.c: At top level: drivers/media/i2c/ov5670.c:2444:19: error: 'v4l2_subdev_link_validate' undeclared here (not in a function); did you mean 'v4l2_subdev_init'? .link_validate = v4l2_subdev_link_validate, ^~~~~~~~~~~~~~~~~~~~~~~~~ v4l2_subdev_init drivers/media/i2c/ov5670.c: In function 'ov5670_probe': drivers/media/i2c/ov5670.c:2492:12: error: 'struct v4l2_subdev' has no member named 'entity' This adds both to the Kconfig entry. Fixes: 5de35c9b ("media: i2c: Add Omnivision OV5670 5M sensor support") Signed-off-by: -
Kuninori Morimoto authored
Now, we can use of_graph_get_remote_endpoint(). Let's use it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Acked-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
JB Van Puyvelde authored
Add static keywords to fix this kind of sparse warnings: warning: symbol 'imx_t_vcm_timing' was not declared. Should it be static? Signed-off-by:
JB Van Puyvelde <jbvanpuyvelde@gmail.com> Signed-off-by:
-
Steve Longerbeam authored
For the write channels with 4:2:0 subsampled YUV formats, avoid chroma overdraw by only writing chroma for even lines. Reduces necessary write memory bandwidth by at least 25% (more with rotation enabled). Signed-off-by:
-
Arnd Bergmann authored
Without this, I get a build error: drivers/staging/media/imx/imx-media-vdic.c: In function '__vdic_get_fmt': drivers/staging/media/imx/imx-media-vdic.c:554:10: error: implicit declaration of function 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'? [-Werror=implicit-function-declaration] Fixes: e1302912 ("[media] media: Add i.MX media core driver") Signed-off-by:
-
Arnd Bergmann authored
Without this header, we get a build error in some configurations: drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_setup_vrfb_bufs': drivers/media/platform/omap/omap_vout_vrfb.c:143:26: error: implicit declaration of function 'kzalloc'; did you mean 'vzalloc'? [-Werror=implicit-function-declaration] Fixes: 6a1560ec ("media: v4l: omap_vout: vrfb: Convert to dmaengine") Signed-off-by:
-
Hugues Fruchet authored
Fix missing mutex_destroy() when probe fails and when driver is removed. Signed-off-by:
Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by:
-
Hugues Fruchet authored
Fix a bunch of coding style issues detected by checkpatch --strict. Signed-off-by:
-
Philipp Zabel authored
Commit a53e35db ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit API call so the temporary transition helpers can be removed. No functional changes. Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Tiffany Lin authored
Fix The camera has a blurry screen phenomenon when we video chat with apprtc using vp9 codec Signed-off-by:
Tiffany Lin <tiffany.lin@mediatek.com> Reviewed-by:
Wu-Cheng Li <wuchengli@chromium.org> Tested-by:
-
Fabio Estevam authored
clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Fabio Estevam authored
When devm_clk_get() fails the real error code should be propagated, instead of always returning -EPROBE_DEFER. Signed-off-by:
-
Hans Verkuil authored
My eye fell on this wrong coefficient in the bt2020_full matrix. The bt2020 matrix (limited range) is OK. Signed-off-by:
-
