Re: drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:18: error: too many arguments to function 'horus3a_attach'

Hello, On Sun, Sep 20, 2015 at 10:56 AM, kbuild test robot wrote: > Hi Kozlov, > > FYI, the error/warning still remains. You may either fix it or ask me to > silently ignore in future. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >

Re: drivers/media/dvb-frontends/lnbh25.h:46:15: error: unknown type name 'dvb_frontend'

Hello, On Sun, Sep 20, 2015 at 5:17 AM, kbuild test robot wrote: > Hi Kozlov, > > FYI, the error/warning still remains. You may either fix it or ask me to > silently ignore in future. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >

[PATCH 5/5] media: atmel-isi: support RGB565 output when sensor output YUV formats

This patch enable Atmel ISI preview path to convert the YUV to RGB format. Signed-off-by: Josh Wu --- drivers/media/platform/soc_camera/atmel-isi.c | 38 --- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git

[PATCH 1/5] media: atmel-isi: correct yuv swap according to different sensor outputs

we need to configure the YCC_SWAP bits in ISI_CFG2 according to current sensor output and Atmel ISI output format. Current there are two cases Atmel ISI supported: 1. Atmel ISI outputs YUYV format. This case we need to setup YCC_SWAP according to sensor output format. 2. Atmel ISI

[PATCH 0/5] media: atmel-isi: enable preview path to output RGB565 format

This series will enable preview path support in atmel-isi. Which can make atmel-isi convert the YUV format (from sensor) to RGB565 format. Josh Wu (5): media: atmel-isi: correct yuv swap according to different sensor outputs media: atmel-isi: prepare for the support of preview path

[PATCH 4/5] media: atmel-isi: setup YCC_SWAP correctly when using preview path

The preview path only can convert UYVY format to RGB data. To make preview path work correctly, we need to set up YCC_SWAP according to sensor output and convert them to UYVY. Signed-off-by: Josh Wu --- drivers/media/platform/soc_camera/atmel-isi.c | 16 1

[PATCH 3/5] media: atmel-isi: add code to setup correct resolution for preview path

Not like codec path, preview path can do downsampling, so we should setup a extra preview width, height for it. This patch add preview resolution setup without down sampling. So currently preview path will output same size as sensor output size. Signed-off-by: Josh Wu ---

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

Hi Mauro, On 21/09/15 13:41, Mauro Carvalho Chehab wrote: > Btw, I just got a Samsung TM1 device, with seems to be using an arm64 > SoC. Is this driver providing support for its camera? The TM1 device (Z3) is based on a Qualcomm 64-bit SoC. The $subject patch adds support for a standalone JPEG

Re: [PATCH] [media] tvp5150: add support for asynchronous probing

Javier Martinez Canillas wrote: > Allow the subdevice to be probed asynchronously. > > Signed-off-by: Javier Martinez Canillas Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@linux.intel.com -- To unsubscribe from this list: send the

[RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device

vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return. But in dma_sync_sg_for_device, it use lengths of each SG entries before dma_map_sg_attrs. dma_map_sg_attrs will concatenate SGs until dma length > dma seg bundary. sgt->nents will less than sgt->orig_nents. Using SG entries after

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

Hi Mauro, W dniu 21.09.2015 o 13:41, Mauro Carvalho Chehab pisze: I think the media subsystem can take patches 1-3 and whoever does DT patches can take this patch, right? The cover letter explains that the series is rebased onto Mauro's master with Kukjin's branch merged. The latter does

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

Em Mon, 21 Sep 2015 11:59:27 +0200 Andrzej Pietrasiewicz escreveu: > Hi Hans, > > W dniu 21.09.2015 o 11:50, Hans Verkuil pisze: > > On 18-09-15 16:21, Andrzej Pietrasiewicz wrote: > >> From: Marek Szyprowski > >> > >> Add Exynos 5433 jpeg h/w

Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types

Andrzej Hajda wrote: > Semantic patch finds comparisons of types: > unsigned < 0 > unsigned >= 0 > The former is always false, the latter is always true. > Such comparisons are useless, so theoretically they could be > safely removed, but their presence quite often

[PATCH] [media] tvp5150: add support for asynchronous probing

Allow the subdevice to be probed asynchronously. Signed-off-by: Javier Martinez Canillas --- drivers/media/i2c/tvp5150.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c index

Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device

Hi Tiffany! On 21-09-15 14:26, Tiffany Lin wrote: > vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return. > But in dma_sync_sg_for_device, it use lengths of each SG entries > before dma_map_sg_attrs. dma_map_sg_attrs will concatenate > SGs until dma length > dma seg bundary.

cron job: media_tree daily build: OK

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Sep 22 04:00:16 CEST 2015 git branch: test git hash: 9ddf9071ea17b83954358b2dac42b34e5857a9af gcc

[PATCH 2/5] media: atmel-isi: prepare for the support of preview path

Atmel ISI support a preview path which can output RGB data. So this patch introduces a bool variable to choose which path is enabled currently. And also we need setup corresponding path registers. By default the preview path is disabled. We only use Codec path. Signed-off-by: Josh Wu

[PATCH 15/17] ir-hix5hd2: drop the use of IRQF_NO_SUSPEND

This driver doesn't claim the IR transmitter to be wakeup source. It even disables the clock and the IR during suspend-resume cycle. This patch removes yet another misuse of IRQF_NO_SUSPEND. Cc: Mauro Carvalho Chehab Cc: Zhangfei Gao Cc:

[PATCH 14/17] media: st-rc: remove misuse of IRQF_NO_SUSPEND flag

The device is set as wakeup capable using proper wakeup API but the driver misuses IRQF_NO_SUSPEND to set the interrupt as wakeup source which is incorrect. This patch removes the use of IRQF_NO_SUSPEND flags replacing it with enable_irq_wake instead. Cc: Srinivas Kandagatla

[PATCH] [media] cx25821, cx88, tm6000: use SNDRV_DEFAULT_ENABLE_PNP

Instead of manually initializing the bool array enable, use the SNDRV_DEFAULT_ENABLE_PNP macro. As most drivers do. Signed-off-by: Luis de Bethencourt --- Hi, I don't see any good reason to use = 1 instead of = SNDRV_DEFAULT_ENABLE_PNP. Semantically it is the same, and

[Patch v2] media: v4l2-ctrls: Fix 64bit support in get_ctrl()

When trying to use v4l2_ctrl_g_ctrl_int64() to retrieve a V4L2_CTRL_TYPE_INTEGER64 type value the internal helper function get_ctrl() would prematurely exits because for this control type the 'is_int' flag is not set. This would result in v4l2_ctrl_g_ctrl_int64 always returning 0. Also

RFC: ov5640 kernel driver.

Hi, we want to a v4l2 driver for the ov5640 sensor from Omnivision. AFAIK, there was an attempt in the past to mainline that driver [1] but it didn't make it in the end. Some people were asking for the code for the ov5640 and the ov5642 to be merged [2] as well but IMHO both sensors are not

[PATCH] cobalt: fix Kconfig dependency

The cobalt driver should depend on VIDEO_V4L2_SUBDEV_API. This fixes this kbuild error: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 99bc7215bc60f6cd414cf1b85cd9d52cc596cccb commit: 85756a069c55e0315ac5990806899cfb607b987f [media] cobalt: add new

[PATCH 1/2] v4l2-ctrls: arrays are also considered compound controls

From: Hans Verkuil Array controls weren't skipped when only V4L2_CTRL_FLAG_NEXT_CTRL was provided (so no V4L2_CTRL_FLAG_NEXT_COMPOUND was set). This is wrong since arrays are also considered compound controls (i.e. with more than one value), and applications that do not

[PATCH 2/2] DocBook/media: clarify control documentation

From: Hans Verkuil - Add missing V4L2_CTRL_TYPE_U32 documentation - Remove 'which are actually different on the hardware' sentence which is confusing. I think the idea was to let the user know that the step can be different for different hardware, but that's obvious

[PATCH 0/2] v4l2-ctrls: fix NEXT_COMPOUND support

This patch series is identical to the original RFC patch (see here: https://patchwork.linuxtv.org/patch/31423/), but it is now split up in two patches and the actual code fix now has a CC to stable to patch up kernels 3.17 and up. Regards, Hans -- To unsubscribe from this list: send the

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

On 18-09-15 16:21, Andrzej Pietrasiewicz wrote: > From: Marek Szyprowski > > Add Exynos 5433 jpeg h/w codec node. > > Signed-off-by: Marek Szyprowski > Signed-off-by: Andrzej Pietrasiewicz > --- >

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

Hi Hans, W dniu 21.09.2015 o 11:50, Hans Verkuil pisze: On 18-09-15 16:21, Andrzej Pietrasiewicz wrote: From: Marek Szyprowski Add Exynos 5433 jpeg h/w codec node. Signed-off-by: Marek Szyprowski Signed-off-by: Andrzej Pietrasiewicz

[GIT PULL FOR v4.4] Fixes, enhancements, etc.

This pull request is a pile of fixes and enhancements. The main changes are a new colorspace and a new transfer function and a cleaned up saa7164 (now passes v4l2-compliance). Arnd also did some preparation to simplify future y2038 work. Regards, Hans The following changes since

Re: RFC: ov5640 kernel driver.

Hi Javier, On Mon, 21 Sep 2015, Javier Martin wrote: > Hi, > we want to a v4l2 driver for the ov5640 sensor from Omnivision. > > AFAIK, there was an attempt in the past to mainline that driver [1] but it > didn't make it in the end. > > Some people were asking for the code for the ov5640 and

3.5%loan offer

3.5% WONGA.pdf Description: Adobe PDF document

[PATCH 25/38] staging: media: davinci_vpfe: fix ipipe_mode type

The variable can take negative values. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 Signed-off-by: Andrzej Hajda ---

[Patch v2 1/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

The Camera Adaptation Layer (CAL) is a block which consists of a dual port CSI2/MIPI camera capture engine. Port #0 can handle CSI2 camera connected to up to 4 data lanes. Port #1 can handle CSI2 camera connected to up to 2 data lanes. The driver implements the required API/ioctls to be V4L2

[Patch v2 0/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

The Camera Adaptation Layer (CAL) is a block which consists of a dual port CSI2/MIPI camera capture engine. This camera engine is currently found on DRA72xx family of devices. Port #0 can handle CSI2 camera connected to up to 4 data lanes. Port #1 can handle CSI2 camera connected to up to 2 data

[Patch v2 2/2] media: v4l: ti-vpe: Document CAL driver

Device Tree bindings for the Camera Adaptation Layer (CAL) driver Signed-off-by: Benoit Parrot --- Documentation/devicetree/bindings/media/ti-cal.txt | 70 ++ 1 file changed, 70 insertions(+) create mode 100644

[PATCH 0/3 RFC v3] media: platform: add NVIDIA Tegra VI driver

This patchset add and enable V4L2 driver for latest NVIDIA Tegra Video Input hardware controller. It's based on the staging/work branch of Thierry Reding Tegra upstream kernel github repo, which is based on 4.2-rc1. (https://github.com/thierryreding/linux/tree/staging/work) v3: - rework on

[PATCH 2/3] ARM64: add tegra-vi support in T210 device-tree

Following device tree support for Tegra VI now: - "vi" node which might have 6 ports/endpoints - in TPG mode, "vi" node don't need to define any ports/endpoints - ports/endpoints defines the link between VI and external sensors. Signed-off-by: Bryan Wu ---

[PATCH 3/3] Documentation: DT bindings: add VI and CSI bindings

Signed-off-by: Bryan Wu --- .../bindings/gpu/nvidia,tegra20-host1x.txt | 211 - 1 file changed, 205 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt

[PATCH 1/3] [media] v4l: tegra: Add NVIDIA Tegra VI driver

NVIDIA Tegra processor contains a powerful Video Input (VI) hardware controller which can support up to 6 MIPI CSI camera sensors. This patch adds a V4L2 media controller and capture driver to support Tegra VI hardware. It's verified with Tegra built-in test pattern generator. Signed-off-by:

[PATCH V2 0/2] rc: Add timeout support to gpio-ir-recv

Add timeout support to the gpio-ir-recv driver as discussed in this original patch: https://patchwork.ozlabs.org/patch/516827/ V2 uses the timeout field of the rcdev instead of a device tree field to set the timeout value as suggested by Sean Young. Eric Nelson (2): rc-core: define a

Re: [PATCH 1/3] [media] v4l: tegra: Add NVIDIA Tegra VI driver

On 09/16/2015 02:13 AM, Hans Verkuil wrote: Hi Bryan, Thanks for this patch series! The switch to a kthread helps a lot, but I still have a number of comments about it, primarily locking related. On 09/16/2015 03:35 AM, Bryan Wu wrote: NVIDIA Tegra processor contains a powerful Video Input

[PATCH V2 1/2] rc-core: define a default timeout for drivers

A default timeout value of 100ms is workable for most decoders. Declare a constant to help standardize its' use. Signed-off-by: Eric Nelson --- include/media/rc-core.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/rc-core.h b/include/media/rc-core.h index

[PATCH V2 0/2] rc: Add timeout support to gpio-ir-recv

Add timeout support to the gpio-ir-recv driver as discussed in this original patch: https://patchwork.ozlabs.org/patch/516827/ V2 uses the timeout field of the rcdev instead of a device tree field to set the timeout value as suggested by Sean Young. Eric Nelson (2): rc-core: define a

[PATCH V2 2/2] rc: gpio-ir-recv: add timeout on idle

Many decoders require a trailing space (period without IR illumination) to be delivered before completing a decode. Since the gpio-ir-recv driver only delivers events on gpio transitions, a single IR symbol (caused by a quick touch on an IR remote) will not be properly decoded without the use of

[PATCH] vivid: add 10 and 12 bit Bayer formats

Add support for 10 and 12 bit Bayer formats to the test pattern generator and the vivid driver. Signed-off-by: Hans Verkuil --- drivers/media/platform/vivid/vivid-tpg.c| 91 + drivers/media/platform/vivid/vivid-vid-common.c | 56