Re: [PATCH 4/6] MAINTAINERS: Update solo6x10 patterns

[Hans Verkuil]

Repost, this time with the linux-media ml included.

On 07/30/2014 09:02 AM, Hans Verkuil wrote:
> On 07/30/2014 05:38 AM, Joe Perches wrote:
>> commit 28cae868cd24 ("[media] solo6x10: move out of staging into
>> drivers/media/pci") moved the files, update the patterns.
>>
>> Signed-off-by: Joe Perches 
>> cc: Ismael Luceno 
>> cc: Hans Verkuil 
> 
> Acked-By: Hans Verkuil 
> 
> I'll pull this one in through our linux-media repo.
> 
> Thanks,
> 
>   Hans
> 
>> ---
>>  MAINTAINERS | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 3960ba8..8ed337c 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8403,6 +8403,12 @@ M:Chris Boot 
>>  S:  Maintained
>>  F:  drivers/leds/leds-net48xx.c
>>  
>> +SOFTLOGIC 6x10 MPEG CODEC
>> +M:  Ismael Luceno 
>> +L:  linux-media@vger.kernel.org
>> +S:  Supported
>> +F:  drivers/media/pci/solo6x10/
>> +
>>  SOFTWARE RAID (Multiple Disks) SUPPORT
>>  M:  Neil Brown 
>>  L:  linux-r...@vger.kernel.org
>> @@ -8666,11 +8672,6 @@ M:Christopher Harrer 
>>  S:  Odd Fixes
>>  F:  drivers/staging/slicoss/
>>  
>> -STAGING - SOFTLOGIC 6x10 MPEG CODEC
>> -M:  Ismael Luceno 
>> -S:  Supported
>> -F:  drivers/staging/media/solo6x10/
>> -
>>  STAGING - SPEAKUP CONSOLE SPEECH DRIVER
>>  M:  William Hubbs 
>>  M:  Chris Brannon 
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] MAINTAINERS: Update go7007 pattern

[Hans Verkuil]

On 07/30/2014 05:38 AM, Joe Perches wrote:
> Commit 7955f03d18d1 ("[media] go7007: move out of staging into
> drivers/media/usb") moved the files, update the pattern.
> 
> Signed-off-by: Joe Perches 
> cc: Hans Verkuil 

Acked-By: Hans Verkuil 

Thanks, I forgot about that one.

I'll pull this in through our media subsystem repo.

Hans

> ---
>  MAINTAINERS | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6033aaf..3960ba8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3997,6 +3997,12 @@ F: Documentation/isdn/README.gigaset
>  F:   drivers/isdn/gigaset/
>  F:   include/uapi/linux/gigaset_dev.h
>  
> +GO7007 MPEG CODEC
> +M:   Hans Verkuil 
> +L:   linux-media@vger.kernel.org
> +S:   Maintained
> +F:   drivers/media/usb/go7007/
> +
>  GPIO SUBSYSTEM
>  M:   Linus Walleij 
>  M:   Alexandre Courbot 
> @@ -8603,11 +8609,6 @@ M: Marek Belisko 
>  S:   Odd Fixes
>  F:   drivers/staging/ft1000/
>  
> -STAGING - GO7007 MPEG CODEC
> -M:   Hans Verkuil 
> -S:   Maintained
> -F:   drivers/staging/media/go7007/
> -
>  STAGING - INDUSTRIAL IO
>  M:   Jonathan Cameron 
>  L:   linux-...@vger.kernel.org
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v3.17] Fix MAINTAINERS file and one sparse fix

[Hans Verkuil]

Hi Mauro,

I forgot to update the MAINTAINERS file when I moved the solo6x10 and go7007
drivers out of staging. Thanks to Joe for making a patch for this.

I also added a trivial sparse fix from Wei Yongjun for the radio-miropcm20 
driver.

Regards,

Hans

The following changes since commit 7f196789b3ffee243b681d3e7dab8890038db856:

  si2135: Declare the structs even if frontend is not enabled (2014-07-28 
10:37:08 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v3.17h

for you to fetch changes up to 2f5fdc4fc55f3c0ba4a05995e27126b72edfe840:

  radio-miropcm20: fix sparse NULL pointer warning (2014-07-30 10:10:51 +0200)


Joe Perches (2):
  MAINTAINERS: Update solo6x10 patterns
  MAINTAINERS: Update go7007 pattern

Wei Yongjun (1):
  radio-miropcm20: fix sparse NULL pointer warning

 MAINTAINERS   | 22 --
 drivers/media/radio/radio-miropcm20.c |  2 +-
 2 files changed, 13 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: v4l2: make allocation algorithm more robust and flexible

[Sachin Kamat]

Hi Zhaowei,

On Wed, Jul 30, 2014 at 9:39 AM, Zhaowei Yuan  wrote:
> Current algorithm relies on the fact that caller will align the
> size to PAGE_SIZE, otherwise order will be decreased to negative
> when remain size is less than PAGE_SIZE, it makes the function
> hard to be migrated.
> This patch sloves the hidden problem.
>
> Signed-off-by: Zhaowei Yuan 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> index adefc31..40d18aa 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
> @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf 
> *buf,
>
> order = get_order(size);
> /* Dont over allocate*/
> -   if ((PAGE_SIZE << order) > size)
> +   if (order > 0 && (PAGE_SIZE << order) > size)
> order--;

If size is not page aligned, then wouldn't decrementing the order
under-allocate the memory?

-- 
Regards,
Sachin.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/32] [media] coda: Add encoder/decoder support for CODA960

[Shawn Guo]

On Tue, Jul 29, 2014 at 07:06:25PM +0200, Philipp Zabel wrote:
> > I followed the step to generate the firmware v4l-coda960-imx6q, and
> > tested it on next-20140725 with patch 'ARM: dts: imx6qdl: Enable CODA960
> > VPU' applied on top of it.  But I got the error of 'Wrong firmwarel' as
> > below.
> >
> > [2.582837] coda 204.vpu: requesting firmware 
> > 'v4l-coda960-imx6q.bin' for CODA960
> > [2.593344] coda 204.vpu: Firmware code revision: 0
> > [2.598649] coda 204.vpu: Wrong firmware. Hw: CODA960, Fw: (0x), 
> > Version: 0.0.0
> 
> I just tried with the same kernel, and the above download, converted
> with the program in the referenced mail, and I get this:
> 
> coda 204.vpu: Firmware code revision: 36350
> coda 204.vpu: Initialized CODA960.
> coda 204.vpu: Unsupported firmware version: 2.1.9
> coda 204.vpu: codec registered as /dev/video0

Okay, the reason I'm running into the issue is that I'm using the FSL
U-Boot which turns off VDDPU at initialization.

Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/32] [media] coda: Add encoder/decoder support for CODA960

[Philipp Zabel]

Am Mittwoch, den 30.07.2014, 20:16 +0800 schrieb Shawn Guo:
> On Tue, Jul 29, 2014 at 07:06:25PM +0200, Philipp Zabel wrote:
> > > I followed the step to generate the firmware v4l-coda960-imx6q, and
> > > tested it on next-20140725 with patch 'ARM: dts: imx6qdl: Enable CODA960
> > > VPU' applied on top of it.  But I got the error of 'Wrong firmwarel' as
> > > below.
> > >
> > > [2.582837] coda 204.vpu: requesting firmware 
> > > 'v4l-coda960-imx6q.bin' for CODA960
> > > [2.593344] coda 204.vpu: Firmware code revision: 0
> > > [2.598649] coda 204.vpu: Wrong firmware. Hw: CODA960, Fw: 
> > > (0x), Version: 0.0.0
> > 
> > I just tried with the same kernel, and the above download, converted
> > with the program in the referenced mail, and I get this:
> > 
> > coda 204.vpu: Firmware code revision: 36350
> > coda 204.vpu: Initialized CODA960.
> > coda 204.vpu: Unsupported firmware version: 2.1.9
> > coda 204.vpu: codec registered as /dev/video0
> 
> Okay, the reason I'm running into the issue is that I'm using the FSL
> U-Boot which turns off VDDPU at initialization.

In that case you need to also apply the "Generic Device Tree based power
domain look-up" and "i.MX6 PU power domain support series". I'll have to
check the current state of that.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock

[Tero Kristo]

On 07/16/2014 03:29 AM, Laurent Pinchart wrote:

Hi Stefan,

Thank you for the patch.

On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:

Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).

Signed-off-by: Stefan Herbrechtsmeier 
Cc: Laurent Pinchart 
Cc: Tony Lindgren 
Cc: Tero Kristo 
Cc: 
Cc: 


Acked-by: Laurent Pinchart 

Tero, could you please process it for v3.17 if time still permits ?


This is too late for 3.17 merge window as I was on holiday last few 
weeks. Queued for 3.17-rc early fixes though.


-Tero




---
  arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = <0x1e>;
reg = <0x0d00>;
ti,set-bit-to-disable;
+   ti,set-rate-parent;
};

dpll4_m6_ck: dpll4_m6_ck {




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock

[Laurent Pinchart]

On Wednesday 30 July 2014 15:40:33 Tero Kristo wrote:
> On 07/16/2014 03:29 AM, Laurent Pinchart wrote:
> > On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:
> >> Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
> >> is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
> >> clock rate configuration on OMAP34xx, which needs the rate to be
> >> propagated properly to the divider node (dpll4_m5_ck).
> >> 
> >> Signed-off-by: Stefan Herbrechtsmeier 
> >> Cc: Laurent Pinchart 
> >> Cc: Tony Lindgren 
> >> Cc: Tero Kristo 
> >> Cc: 
> >> Cc: 
> > 
> > Acked-by: Laurent Pinchart 
> > 
> > Tero, could you please process it for v3.17 if time still permits ?
> 
> This is too late for 3.17 merge window as I was on holiday last few
> weeks. Queued for 3.17-rc early fixes though.

Kiitos.

> >> ---
> >> 
> >>   arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
> >>   1 file changed, 1 insertion(+)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> >> b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
> >> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> >> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> >> @@ -467,6 +467,7 @@
> >>ti,bit-shift = <0x1e>;
> >>reg = <0x0d00>;
> >>ti,set-bit-to-disable;
> >> +  ti,set-rate-parent;
> >>};
> >>
> >>dpll4_m6_ck: dpll4_m6_ck {

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Antti Palosaari]

On 07/30/2014 08:13 AM, Bjoern wrote:

Hello Rudy

I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 
3.13.0-32-generic. Support for this card was not build into the kernel and I 
had to compile it myself. I had to use media_build_experimental from Mr. 
Endriss.

http://linuxtv.org/hg/~endriss/media_build_experimental

Your card should be supported with this version.

Regards, Thomas


Hi Rudy,

What Thomas writes is absolutely correct...

This is unfortunately the worst situation I've ever run across in
Linux... There was a kernel driver that worked and was supported by
Digital Devices. Then, from what I read, changes to how the V4L drivers
have to be written was changed - Digital Devices doesn't like that and
they force users to use "experimental" builds which are the "old
style".

This is total rubbish imo - if this is how it was decided that the
drivers have to be nowadays then adjust them. Why am I paying such a lot
of money others right, these DD cards are really not cheap?

Some attempts have been made by people active here to adapt the drivers
and make them work in newer kernels, but so far no one has succeeded.
Last attempt was in Jan 2014 iirc, since then - silence.

I wish I could help out, I can code but Linux is well just a bit more
"difficult" I guess ;-)


I have one of such device too, but I have been too busy all the time 
with other drivers...


Basically these DTV drivers should be developed in a order, bridge 
driver first, then demod and tuner - for one single device. After it is 
committed in tree, you could start adding new devices and drivers. If 
you try implement too big bunch of things as a once, you will likely 
fail endless reviews and so.


I don't know what is change in development process which causes these 
problems. What I remember there has been only few big changes in recent 
years, change from Mercurial to Git and reorganization of directories/files.


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: v4l2: make alloction alogthim more robust and flexible

[Andreas Färber]

Hi,

A few trivial typos:

s/alloction/allocation/

s/alogthim/algorithm/

Am 30.07.2014 05:55, schrieb Zhaowei Yuan:
> Current algothim relies on the fact that caller will align the

s/algothim/algorithm/

> size to PAGE_SIZE, otherwise order will be decreased to negative
> when remain size is less than PAGE_SIZE, it makes the function

s/remain/remaining/

> hard to be migrated.
> This patch sloves the hidden problem.

s/sloves/solves/

> 
> Signed-off-by: Zhaowei Yuan 

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[next:master 8790/9825] tuner-core.c:undefined reference to `tda829x_attach'

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   fcf6395d41087217d4b88d5b2ad7a1ce66ca6ced
commit: f5b44da1ac4146e06147a5df3058f4c265c932ec [8790/9825] [media] Kconfig: 
fix tuners build warnings
config: i386-randconfig-ib1-07302105 (attached as .config)

All error/warnings:

   drivers/built-in.o: In function `set_type':
>> tuner-core.c:(.text+0x340ee6): undefined reference to `tda829x_attach'
>> tuner-core.c:(.text+0x340fac): undefined reference to `xc2028_attach'
>> tuner-core.c:(.text+0x34103e): undefined reference to `tda18271_attach'
>> tuner-core.c:(.text+0x34106e): undefined reference to `xc4000_attach'
   drivers/built-in.o: In function `tuner_probe':
>> tuner-core.c:(.text+0x341484): undefined reference to `tda829x_probe'

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.16.0-rc6 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_TREE_RCU_TRACE=y
# CONFIG_RCU_BOOST is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_NONE=y
# CONFIG_RCU_NOCB_CPU_ZERO is not set
# CONFIG_RCU_NOCB_CPU_ALL is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# 

[PATCHv1 01/12] vb2: fix multiplanar read() with non-zero data_offset

[Hans Verkuil]

From: Hans Verkuil 

If this is a multiplanar buf_type and the plane we want to read has a
non-zero data_offset, then that data_offset was not taken into account.

Note that read() or write() for formats with more than one plane is currently
not allowed, hence the use of 'planes[0]' since this is only relevant for a
single-plane format.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index c359006..0e3d927 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2959,6 +2959,12 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
buf->queued = 0;
buf->size = read ? vb2_get_plane_payload(q->bufs[index], 0)
 : vb2_plane_size(q->bufs[index], 0);
+   /* Compensate for data_offset on read in the multiplanar case. 
*/
+   if (is_multiplanar && read &&
+   fileio->b.m.planes[0].data_offset < buf->size) {
+   buf->pos = fileio->b.m.planes[0].data_offset;
+   buf->size -= buf->pos;
+   }
} else {
buf = &fileio->bufs[index];
}
-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv1 00/12] vivid: Virtual Video Test Driver

[Hans Verkuil]

Earlier this month I posted a 'vivi, the next generation' patch series:

https://www.mail-archive.com/linux-media@vger.kernel.org/msg76758.html

However, since that time I realized that rather than building on top of the
old vivi, it would be much better to create a new, much more generic driver.
This vivid test driver no longer emulates just video capture, but also
video output, vbi capture/output, radio receivers/transmitters and SDR capture.
There is even support for testing capture and output overlays.

Up to 64 vivid instances can be created, each with up to 16 inputs and 16 
outputs.

Each input can be a webcam, TV capture device, S-Video capture device or an HDMI
capture device. Each output can be an S-Video output device or an HDMI output
device.

These inputs and outputs act exactly as a real hardware device would behave. 
This
allows you to use this driver as a test input for application development, since
you can test the various features without requiring special hardware.

Some of the features supported by this driver are:

- Support for read()/write(), MMAP, USERPTR and DMABUF streaming I/O.
- A large list of test patterns and variations thereof
- Working brightness, contrast, saturation and hue controls
- Support for the alpha color component
- Full colorspace support, including limited/full RGB range
- All possible control types are present
- Support for various pixel aspect ratios and video aspect ratios
- Error injection to test what happens if errors occur
- Supports crop/compose/scale in any combination for both input and output
- Can emulate up to 4K resolutions
- All Field settings are supported for testing interlaced capturing
- Supports all standard YUV and RGB formats, including two multiplanar YUV 
formats
- Raw and Sliced VBI capture and output support
- Radio receiver and transmitter support, including RDS support
- Software defined radio (SDR) support
- Capture and output overlay support

This driver is big, but I believe that for the most part I managed to keep
the code clean (I'm biased, though). I've split it up in several parts to
make reviewing easier. The first patch is a vb2 fix I posted earlier, but
patchwork failed to pick it up (probably because it was missing a Signed-of-by
line), so I'm posting it again. The second patch is an extensive document
that describes the features currently implemented. After that the driver code
is posted and in the last patch the driver is hooked into Kconfig/Makefile.

This goal is for this to go in for 3.18, so I expect I'll likely to a v2 at
least since I am still improving the driver and it will be a while before
we can merge code for v3.18.

As far as I am concerned the vivi driver can be removed once this driver is
merged.

Two questions which I am sure will be raised by reviewers:

1) Why add support for capture and output overlays? Isn't that obsolete?

First of all, we have drivers that support it and it is really nice to be
able to test whether it still works. I found several issues, some in the core,
when it comes to overlay support, so at the very least it will help to
prevent regressions until the time comes that we actually remove this API.

Secondly, this driver was created not just to help applications to test their
code, but also to help in understanding and verifying the API. In order to do
that you need to be able to test it. Which is difficult since hardware that
supports this is rare.

I have mentioned in the documentation that the overlay support is there
primarily for API testing and that its use in new drivers is questionable.

2) Why add video loop support, doesn't that make abuse possible?

I think video loop support is a great feature as it allows you to test
video output since without it you have no idea what the video you give to
the driver actually looks like. So just from the perspective of testing your
application I believe this is an essential feature.

There are a few reasons why I think that this is unlikely to lead to abuse:

- the video loop functionality has to be enabled explicitly via a control of
  the video output device.
- the video capture and output resolution and formats have to match exactly
- by default the OSD text will be placed over the looped video. This can be
  turned off via a control of the video capture device.
- the number of resolutions is currently fixed to SDTV and the CEA-861 and
  VESA DMT timings. So 'random' resolutions are not supported. Although to
  be fair, this is something I intend to add. However, if I do that then I
  will require that the configured DV timings of the input and output are
  identical before the video loop is possible.

Taken altogether I do not think this is something that lends itself easily
for abuse since this won't work out-of-the-box.

A final note: this driver will be used to demonstrate application testing
during my LinuxCon presentation next month. See:

http://events.linuxfoundation.org/events/linuxcon-north-america/program/schedule

Regards

[PATCHv1 05/12] vivid: add the video capture and output parts

[Hans Verkuil]

From: Hans Verkuil 

This adds the ioctl and vb2 queue support for video capture and output.
Part of this is common to both, so that is placed in a vid-common source.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-vid-cap.c| 1719 +++
 drivers/media/platform/vivid/vivid-vid-cap.h|   71 +
 drivers/media/platform/vivid/vivid-vid-common.c |  571 
 drivers/media/platform/vivid/vivid-vid-common.h |   61 +
 drivers/media/platform/vivid/vivid-vid-out.c| 1194 
 drivers/media/platform/vivid/vivid-vid-out.h|   57 +
 6 files changed, 3673 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-vid-cap.c
 create mode 100644 drivers/media/platform/vivid/vivid-vid-cap.h
 create mode 100644 drivers/media/platform/vivid/vivid-vid-common.c
 create mode 100644 drivers/media/platform/vivid/vivid-vid-common.h
 create mode 100644 drivers/media/platform/vivid/vivid-vid-out.c
 create mode 100644 drivers/media/platform/vivid/vivid-vid-out.h

diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c 
b/drivers/media/platform/vivid/vivid-vid-cap.c
new file mode 100644
index 000..7fb4777
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -0,0 +1,1719 @@
+/*
+ * vivid-vid-cap.c - video capture support functions.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-vid-common.h"
+#include "vivid-kthread-cap.h"
+#include "vivid-vid-cap.h"
+
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+   tpf_min = {.numerator = 1,  .denominator = FPS_MAX},
+   tpf_max = {.numerator = FPS_MAX,.denominator = 1},
+   tpf_default = {.numerator = 1,  .denominator = 30};
+
+static const struct vivid_fmt formats_ovl[] = {
+   {
+   .name = "RGB565 (LE)",
+   .fourcc   = V4L2_PIX_FMT_RGB565, /* gggb rggg */
+   .depth= 16,
+   .planes   = 1,
+   },
+   {
+   .name = "XRGB555 (LE)",
+   .fourcc   = V4L2_PIX_FMT_XRGB555, /* gggb argg */
+   .depth= 16,
+   .planes   = 1,
+   },
+   {
+   .name = "ARGB555 (LE)",
+   .fourcc   = V4L2_PIX_FMT_ARGB555, /* gggb argg */
+   .depth= 16,
+   .planes   = 1,
+   },
+};
+
+/* The number of discrete webcam framesizes */
+#define VIVID_WEBCAM_SIZES 3
+/* The number of discrete webcam frameintervals */
+#define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
+
+/* Sizes must be in increasing order */
+static const struct v4l2_frmsize_discrete webcam_sizes[VIVID_WEBCAM_SIZES] = {
+   {  320, 180 },
+   {  640, 360 },
+   { 1280, 720 },
+};
+
+/*
+ * Intervals must be in increasing order and there must be twice as many
+ * elements in this array as there are in webcam_sizes.
+ */
+static const struct v4l2_fract webcam_intervals[VIVID_WEBCAM_IVALS] = {
+   {  1, 10 },
+   {  1, 15 },
+   {  1, 25 },
+   {  1, 30 },
+   {  1, 50 },
+   {  1, 60 },
+};
+
+static const struct v4l2_discrete_probe webcam_probe = {
+   webcam_sizes,
+   VIVID_WEBCAM_SIZES
+};
+
+static int vid_cap_queue_setup(struct vb2_queue *vq, const struct v4l2_format 
*fmt,
+  unsigned *nbuffers, unsigned *nplanes,
+  unsigned sizes[], void *alloc_ctxs[])
+{
+   struct vivid_dev *dev = vb2_get_drv_priv(vq);
+   unsigned planes = tpg_g_planes(&dev->tpg);
+   unsigned h = dev->fmt_cap_rect.height;
+   unsigned p;
+
+   if (dev->field_cap == V4L2_FIELD_ALTERNATE) {
+   /*
+* You cannot use read() with FIELD_ALTERNATE since the field
+* information (TOP/BOTTOM) cannot be passed back to the user.
+*/
+   if (vb2_fileio_is_active(vq))
+   return -EINVAL;
+   }
+
+   if (dev->queue_setup_error) {
+   /*
+* Error injection: test what happens if queue_setup() returns
+* an er

[PATCHv1 12/12] vivid: enable the vivid driver

[Hans Verkuil]

From: Hans Verkuil 

Update the Kconfig and Makefile files so this driver can be compiled.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig|  5 -
 drivers/media/platform/Makefile   |  2 ++
 drivers/media/platform/vivid/Kconfig  | 19 +++
 drivers/media/platform/vivid/Makefile |  6 ++
 4 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/vivid/Kconfig
 create mode 100644 drivers/media/platform/vivid/Makefile

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 433f0bf..b408532 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -242,8 +242,11 @@ menuconfig V4L_TEST_DRIVERS
depends on MEDIA_CAMERA_SUPPORT
 
 if V4L_TEST_DRIVERS
+
+source "drivers/media/platform/vivid/Kconfig"
+
 config VIDEO_VIVI
-   tristate "Virtual Video Driver"
+   tristate "Old Virtual Video Driver"
depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index e5269da..dfdc216 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -15,8 +15,10 @@ obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
 obj-$(CONFIG_VIDEO_OMAP3)  += omap3isp/
 
 obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
+
 obj-$(CONFIG_VIDEO_VIVI) += vivi.o
 
+obj-$(CONFIG_VIDEO_VIVID)  += vivid/
 obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
 
 obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
diff --git a/drivers/media/platform/vivid/Kconfig 
b/drivers/media/platform/vivid/Kconfig
new file mode 100644
index 000..d71139a
--- /dev/null
+++ b/drivers/media/platform/vivid/Kconfig
@@ -0,0 +1,19 @@
+config VIDEO_VIVID
+   tristate "Virtual Video Test Driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64
+   select FONT_SUPPORT
+   select FONT_8x16
+   select VIDEOBUF2_VMALLOC
+   default n
+   ---help---
+ Enables a virtual video driver. This driver emulates a webcam,
+ TV, S-Video and HDMI capture hardware, including VBI support for
+ the SDTV inputs. Also video output, VBI output, radio receivers,
+ transmitters and software defined radio capture is emulated.
+
+ It is highly configurable and is ideal for testing applications.
+ Error injection is supported to test rare errors that are hard
+ to reproduce in real hardware.
+
+ Say Y here if you want to test video apps or debug V4L devices.
+ When in doubt, say N.
diff --git a/drivers/media/platform/vivid/Makefile 
b/drivers/media/platform/vivid/Makefile
new file mode 100644
index 000..756fc12
--- /dev/null
+++ b/drivers/media/platform/vivid/Makefile
@@ -0,0 +1,6 @@
+vivid-objs := vivid-core.o vivid-ctrls.o vivid-vid-common.o vivid-vbi-gen.o \
+   vivid-vid-cap.o vivid-vid-out.o vivid-kthread-cap.o 
vivid-kthread-out.o \
+   vivid-radio-rx.o vivid-radio-tx.o vivid-radio-common.o \
+   vivid-rds-gen.o vivid-sdr-cap.o vivid-vbi-cap.o vivid-vbi-out.o 
\
+   vivid-osd.o vivid-tpg.o vivid-tpg-colors.o
+obj-$(CONFIG_VIDEO_VIVID) += vivid.o
-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv1 08/12] vivid: add a simple framebuffer device for overlay testing

[Hans Verkuil]

From: Hans Verkuil 

In order to test capture and output overlays a simple framebuffer
device is created. It's bare bone, but it does the job.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-osd.c | 405 +++
 drivers/media/platform/vivid/vivid-osd.h |  27 +++
 2 files changed, 432 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-osd.c
 create mode 100644 drivers/media/platform/vivid/vivid-osd.h

diff --git a/drivers/media/platform/vivid/vivid-osd.c 
b/drivers/media/platform/vivid/vivid-osd.c
new file mode 100644
index 000..34f16ce
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-osd.c
@@ -0,0 +1,405 @@
+/*
+ * vivid-osd.c - osd support for testing overlays.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-osd.h"
+
+#define MAX_OSD_WIDTH  720
+#define MAX_OSD_HEIGHT 576
+
+/*
+ * Order: white, yellow, cyan, green, magenta, red, blue, black,
+ * and same again with the alpha bit set (if any)
+ */
+static const u16 rgb555[16] = {
+   0x7fff, 0x7fe0, 0x03ff, 0x03e0, 0x7c1f, 0x7c00, 0x001f, 0x,
+   0x, 0xffe0, 0x83ff, 0x83e0, 0xfc1f, 0xfc00, 0x801f, 0x8000
+};
+
+static const u16 rgb565[16] = {
+   0x, 0xffe0, 0x07ff, 0x07e0, 0xf81f, 0xf800, 0x001f, 0x,
+   0x, 0xffe0, 0x07ff, 0x07e0, 0xf81f, 0xf800, 0x001f, 0x
+};
+
+void vivid_clear_fb(struct vivid_dev *dev)
+{
+   void *p = dev->video_vbase;
+   const u16 *rgb = rgb555;
+   unsigned x, y;
+
+   if (dev->fb_defined.green.length == 6)
+   rgb = rgb565;
+
+   for (y = 0; y < dev->display_height; y++) {
+   u16 *d = p;
+
+   for (x = 0; x < dev->display_width; x++)
+   d[x] = rgb[(y / 16 + x / 16) % 16];
+   p += dev->display_byte_stride;
+   }
+}
+
+/* - */
+
+static int vivid_fb_ioctl(struct fb_info *info, unsigned cmd, unsigned long 
arg)
+{
+   struct vivid_dev *dev = (struct vivid_dev *)info->par;
+
+   switch (cmd) {
+   case FBIOGET_VBLANK: {
+   struct fb_vblank vblank;
+
+   vblank.flags = FB_VBLANK_HAVE_COUNT | FB_VBLANK_HAVE_VCOUNT |
+   FB_VBLANK_HAVE_VSYNC;
+   vblank.count = 0;
+   vblank.vcount = 0;
+   vblank.hcount = 0;
+   if (copy_to_user((void __user *)arg, &vblank, sizeof(vblank)))
+   return -EFAULT;
+   return 0;
+   }
+
+   default:
+   dprintk(dev, 1, "Unknown ioctl %08x\n", cmd);
+   return -EINVAL;
+   }
+   return 0;
+}
+
+/* Framebuffer device handling */
+
+static int vivid_fb_set_var(struct vivid_dev *dev, struct fb_var_screeninfo 
*var)
+{
+   dprintk(dev, 1, "vivid_fb_set_var\n");
+
+   if (var->bits_per_pixel != 16) {
+   dprintk(dev, 1, "vivid_fb_set_var - Invalid bpp\n");
+   return -EINVAL;
+   }
+   dev->display_byte_stride = var->xres * dev->bytes_per_pixel;
+
+   return 0;
+}
+
+static int vivid_fb_get_fix(struct vivid_dev *dev, struct fb_fix_screeninfo 
*fix)
+{
+   dprintk(dev, 1, "vivid_fb_get_fix\n");
+   memset(fix, 0, sizeof(struct fb_fix_screeninfo));
+   strlcpy(fix->id, "vioverlay fb", sizeof(fix->id));
+   fix->smem_start = dev->video_pbase;
+   fix->smem_len = dev->video_buffer_size;
+   fix->type = FB_TYPE_PACKED_PIXELS;
+   fix->visual = FB_VISUAL_TRUECOLOR;
+   fix->xpanstep = 1;
+   fix->ypanstep = 1;
+   fix->ywrapstep = 0;
+   fix->line_length = dev->display_byte_stride;
+   fix->accel = FB_ACCEL_NONE;
+   return 0;
+}
+
+/* Check the requested display mode, returning -EINVAL if we can't
+   handle it. */
+
+static int _vivid_fb_check_var(struct fb_var_screeninfo *var, struct vivid_dev 
*dev)
+{
+   dprintk(dev, 1, "vivid_fb_check_var\n");
+
+   var->bits_per_pixel = 16;

[PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

[Hans Verkuil]

From: Hans Verkuil 

The vivid Virtual Video Test Driver helps testing V4L2 applications
and can emulate V4L2 hardware. Add the documentation for this driver
first.

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/vivid.txt | 1108 +++
 1 file changed, 1108 insertions(+)
 create mode 100644 Documentation/video4linux/vivid.txt

diff --git a/Documentation/video4linux/vivid.txt 
b/Documentation/video4linux/vivid.txt
new file mode 100644
index 000..2dc7354
--- /dev/null
+++ b/Documentation/video4linux/vivid.txt
@@ -0,0 +1,1108 @@
+vivid: Virtual Video Test Driver
+
+
+This driver emulates video4linux hardware of various types: video capture, 
video
+output, vbi capture and output, radio receivers and transmitters and a software
+defined radio receiver. In addition a simple framebuffer device is available 
for
+testing capture and output overlays.
+
+Up to 64 vivid instances can be created, each with up to 16 inputs and 16 
outputs.
+
+Each input can be a webcam, TV capture device, S-Video capture device or an 
HDMI
+capture device. Each output can be an S-Video output device or an HDMI output
+device.
+
+These inputs and outputs act exactly as a real hardware device would behave. 
This
+allows you to use this driver as a test input for application development, 
since
+you can test the various features without requiring special hardware.
+
+This document describes the features implemented by this driver:
+
+- Support for read()/write(), MMAP, USERPTR and DMABUF streaming I/O.
+- A large list of test patterns and variations thereof
+- Working brightness, contrast, saturation and hue controls
+- Support for the alpha color component
+- Full colorspace support, including limited/full RGB range
+- All possible control types are present
+- Support for various pixel aspect ratios and video aspect ratios
+- Error injection to test what happens if errors occur
+- Supports crop/compose/scale in any combination for both input and output
+- Can emulate up to 4K resolutions
+- All Field settings are supported for testing interlaced capturing
+- Supports all standard YUV and RGB formats, including two multiplanar YUV 
formats
+- Raw and Sliced VBI capture and output support
+- Radio receiver and transmitter support, including RDS support
+- Software defined radio (SDR) support
+- Capture and output overlay support
+
+These features will be described in more detail below.
+
+
+Table of Contents
+-
+
+Section 1: Configuring the driver
+Section 2: Video Capture
+Section 2.1: Webcam Input
+Section 2.2: TV and S-Video Inputs
+Section 2.3: HDMI Input
+Section 3: Video Output
+Section 3.1: S-Video Output
+Section 3.2: HDMI Output
+Section 4: VBI Capture
+Section 5: VBI Output
+Section 6: Radio Receiver
+Section 7: Radio Transmitter
+Section 8: Software Defined Radio Receiver
+Section 9: Controls
+Section 9.1: User Controls - Test Controls
+Section 9.2: User Controls - Video Capture
+Section 9.3: User Controls - Audio
+Section 9.4: Image Processing Controls
+Section 9.4.1: Test Pattern Controls
+Section 9.4.2: Capture Feature Selection Controls
+Section 9.4.3: Output Feature Selection Controls
+Section 9.4.4: Error Injection Controls
+Section 9.4.5: VBI Raw Capture Controls
+Section 9.5: Digital Video Controls
+Section 9.6: FM Radio Receiver Controls
+Section 9.7: FM Radio Modulator
+Section 10: Video, VBI and RDS Looping
+Section 10.1: Video and Sliced VBI looping
+Section 10.2: Radio & RDS Looping
+Section 11: Cropping, Composing, Scaling
+Section 12: Formats
+Section 13: Capture Overlay
+Section 14: Output Overlay
+Section 15: Some Future Improvements
+
+
+Section 1: Configuring the driver
+-
+
+By default the driver will create a single instance that has a video capture
+device with webcam, TV, S-Video and HDMI inputs, a video output device with
+S-Video and HDMI outputs, one vbi capture device, one vbi output device, one
+radio receiver device, one radio transmitter device and one SDR device.
+
+The number of instances, devices, video inputs and outputs and their types are
+all configurable using the following module options:
+
+n_devs: number of driver instances to create. By default set to 1. Up to 64
+   instances can be created.
+
+node_types: which devices should each driver instance create. An array of
+   hexadecimal values, one for each instance. The default is 0x1d3d.
+   Each value is a bitmask with the following meaning:
+   bit 0: Video Capture node
+   bit 2-3: VBI Capture node: 0 = none, 1 = raw vbi, 2 = sliced 
vbi, 3 = both
+   bit 4: Radio Receiver node
+   bit 5: Software Defined Radio Receiver node
+   bit 8: Video Output node
+   bit 10-11: VBI Output node: 0 = none, 1 = raw vbi, 2 = sliced 
vbi, 3 = both
+   bit 12: Radio Transmitter node
+   bit 16: Framebuffer for testing o

[PATCHv1 09/12] vivid: add the Test Pattern Generator

[Hans Verkuil]

From: Hans Verkuil 

The test patterns for video capture are generated by this code. All patterns
are precalculated taking into account colorspace information, pixel and video
aspect ratios and scaling information.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-tpg-colors.c |  310 +
 drivers/media/platform/vivid/vivid-tpg-colors.h |   64 +
 drivers/media/platform/vivid/vivid-tpg.c| 1420 +++
 drivers/media/platform/vivid/vivid-tpg.h|  437 +++
 4 files changed, 2231 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-tpg-colors.c
 create mode 100644 drivers/media/platform/vivid/vivid-tpg-colors.h
 create mode 100644 drivers/media/platform/vivid/vivid-tpg.c
 create mode 100644 drivers/media/platform/vivid/vivid-tpg.h

diff --git a/drivers/media/platform/vivid/vivid-tpg-colors.c 
b/drivers/media/platform/vivid/vivid-tpg-colors.c
new file mode 100644
index 000..2adddc0
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-tpg-colors.c
@@ -0,0 +1,310 @@
+/*
+ * vivid-color.c - A table that converts colors to various colorspaces
+ *
+ * The test pattern generator uses the tpg_colors for its test patterns.
+ * For testing colorspaces the first 8 colors of that table need to be
+ * converted to their equivalent in the target colorspace.
+ *
+ * The tpg_csc_colors[] table is the result of that conversion and since
+ * it is precalculated the colorspace conversion is just a simple table
+ * lookup.
+ *
+ * This source also contains the code used to generate the tpg_csc_colors
+ * table. Run the following command to compile it:
+ *
+ * gcc vivid-colors.c -DCOMPILE_APP -o gen-colors -lm
+ *
+ * and run the utility.
+ *
+ * Note that the converted colors are in the range 0x000-0xff0 (so times 16)
+ * in order to preserve precision.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+
+#include "vivid-tpg-colors.h"
+
+/* sRGB colors with range [0-255] */
+const struct color tpg_colors[TPG_COLOR_MAX] = {
+   /*
+* Colors to test colorspace conversion: converting these colors
+* to other colorspaces will never lead to out-of-gamut colors.
+*/
+   { 191, 191, 191 }, /* TPG_COLOR_CSC_WHITE */
+   { 191, 191,  50 }, /* TPG_COLOR_CSC_YELLOW */
+   {  50, 191, 191 }, /* TPG_COLOR_CSC_CYAN */
+   {  50, 191,  50 }, /* TPG_COLOR_CSC_GREEN */
+   { 191,  50, 191 }, /* TPG_COLOR_CSC_MAGENTA */
+   { 191,  50,  50 }, /* TPG_COLOR_CSC_RED */
+   {  50,  50, 191 }, /* TPG_COLOR_CSC_BLUE */
+   {  50,  50,  50 }, /* TPG_COLOR_CSC_BLACK */
+
+   /* 75% colors */
+   { 191, 191,   0 }, /* TPG_COLOR_75_YELLOW */
+   {   0, 191, 191 }, /* TPG_COLOR_75_CYAN */
+   {   0, 191,   0 }, /* TPG_COLOR_75_GREEN */
+   { 191,   0, 191 }, /* TPG_COLOR_75_MAGENTA */
+   { 191,   0,   0 }, /* TPG_COLOR_75_RED */
+   {   0,   0, 191 }, /* TPG_COLOR_75_BLUE */
+
+   /* 100% colors */
+   { 255, 255, 255 }, /* TPG_COLOR_100_WHITE */
+   { 255, 255,   0 }, /* TPG_COLOR_100_YELLOW */
+   {   0, 255, 255 }, /* TPG_COLOR_100_CYAN */
+   {   0, 255,   0 }, /* TPG_COLOR_100_GREEN */
+   { 255,   0, 255 }, /* TPG_COLOR_100_MAGENTA */
+   { 255,   0,   0 }, /* TPG_COLOR_100_RED */
+   {   0,   0, 255 }, /* TPG_COLOR_100_BLUE */
+   {   0,   0,   0 }, /* TPG_COLOR_100_BLACK */
+
+   {   0,   0,   0 }, /* TPG_COLOR_RANDOM placeholder */
+};
+
+#ifndef COMPILE_APP
+
+/* Generated table */
+const struct color16 tpg_csc_colors[V4L2_COLORSPACE_SRGB + 
1][TPG_COLOR_CSC_BLACK + 1] = {
+   [V4L2_COLORSPACE_SMPTE170M][0] = { 2953, 2939, 2939 },
+   [V4L2_COLORSPACE_SMPTE170M][1] = { 2954, 2963, 585 },
+   [V4L2_COLORSPACE_SMPTE170M][2] = { 84, 2967, 2937 },
+   [V4L2_COLORSPACE_SMPTE170M][3] = { 93, 2990, 575 },
+   [V4L2_COLORSPACE_SMPTE170M][4] = { 3030, 259, 2933 },
+   [V4L2_COLORSPACE_SMPTE170M][5] = { 3031, 406, 557 },
+   [V4L2_COLORSPACE_SMPTE170M][6] = { 544, 428, 2931 },
+   [V4L2_COLORSPACE_SMPTE170M][7] = { 551, 547, 547 },
+   [V4L2_COLORSPACE_SMPTE240M][0] = { 2926, 2926, 2926 },
+   [V4L2_COLORSPACE_SMPTE240M][1] = { 2926, 2926, 857 },
+   [V4L2_COLO

[PATCHv1 06/12] vivid: add VBI capture and output code

[Hans Verkuil]

From: Hans Verkuil 

This adds support for VBI capture (raw and sliced) and VBI output
(raw and sliced) to the vivid driver. In addition a VBI generator
is added that generates simple VBI data in either sliced or raw
format.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-vbi-cap.c | 353 +++
 drivers/media/platform/vivid/vivid-vbi-cap.h |  40 +++
 drivers/media/platform/vivid/vivid-vbi-gen.c | 247 +++
 drivers/media/platform/vivid/vivid-vbi-gen.h |  33 +++
 drivers/media/platform/vivid/vivid-vbi-out.c | 247 +++
 drivers/media/platform/vivid/vivid-vbi-out.h |  34 +++
 6 files changed, 954 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-vbi-cap.c
 create mode 100644 drivers/media/platform/vivid/vivid-vbi-cap.h
 create mode 100644 drivers/media/platform/vivid/vivid-vbi-gen.c
 create mode 100644 drivers/media/platform/vivid/vivid-vbi-gen.h
 create mode 100644 drivers/media/platform/vivid/vivid-vbi-out.c
 create mode 100644 drivers/media/platform/vivid/vivid-vbi-out.h

diff --git a/drivers/media/platform/vivid/vivid-vbi-cap.c 
b/drivers/media/platform/vivid/vivid-vbi-cap.c
new file mode 100644
index 000..8d209db
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-vbi-cap.c
@@ -0,0 +1,353 @@
+/*
+ * vivid-vbi-cap.c - vbi capture support functions.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-kthread-cap.h"
+#include "vivid-vbi-cap.h"
+#include "vivid-vbi-gen.h"
+
+static void vivid_sliced_vbi_cap_fill(struct vivid_dev *dev, unsigned seqnr)
+{
+   struct vivid_vbi_gen_data *vbi_gen = &dev->vbi_gen;
+   bool is_60hz = dev->std_cap & V4L2_STD_525_60;
+
+   vivid_vbi_gen_sliced(vbi_gen, is_60hz, seqnr);
+
+   if (!is_60hz) {
+   if (dev->loop_video) {
+   if (dev->vbi_out_have_wss) {
+   vbi_gen->data[0].data[0] = dev->vbi_out_wss[0];
+   vbi_gen->data[0].data[1] = dev->vbi_out_wss[1];
+   } else {
+   vbi_gen->data[0].id = 0;
+   }
+   } else {
+   switch (tpg_g_video_aspect(&dev->tpg)) {
+   case TPG_VIDEO_ASPECT_16X9_CENTRE:
+   vbi_gen->data[0].data[0] = 0x0b;
+   break;
+   case TPG_VIDEO_ASPECT_16X9_ANAMORPHIC:
+   vbi_gen->data[0].data[0] = 0x07;
+   break;
+   case TPG_VIDEO_ASPECT_4X3:
+   default:
+   vbi_gen->data[0].data[0] = 0x08;
+   break;
+   }
+   }
+   } else if (dev->loop_video && is_60hz) {
+   if (dev->vbi_out_have_cc[0]) {
+   vbi_gen->data[0].data[0] = dev->vbi_out_cc[0][0];
+   vbi_gen->data[0].data[1] = dev->vbi_out_cc[0][1];
+   } else {
+   vbi_gen->data[0].id = 0;
+   }
+   if (dev->vbi_out_have_cc[1]) {
+   vbi_gen->data[1].data[0] = dev->vbi_out_cc[1][0];
+   vbi_gen->data[1].data[1] = dev->vbi_out_cc[1][1];
+   } else {
+   vbi_gen->data[1].id = 0;
+   }
+   }
+}
+
+static void vivid_g_fmt_vbi_cap(struct vivid_dev *dev, struct v4l2_vbi_format 
*vbi)
+{
+   bool is_60hz = dev->std_cap & V4L2_STD_525_60;
+
+   vbi->sampling_rate = 2700;
+   vbi->offset = 24;
+   vbi->samples_per_line = 1440;
+   vbi->sample_format = V4L2_PIX_FMT_GREY;
+   vbi->start[0] = is_60hz ? 10 : 6;
+   vbi->start[1] = is_60hz ? 273 : 318;
+   vbi->count[0] = vbi->count[1] = is_60hz ? 12 : 18;
+   vbi->flags = dev->vbi_cap_interlaced ? V4L2_VBI_INTERLACED : 0;
+   vbi->reserved[0] = 0;
+   vbi->reserved[1] = 0;
+}
+
+void vivid_raw_vbi_cap_process(struct vivid_dev *dev, struct vivid_buffer *buf)
+{
+   struct v4l2_vbi_format vbi;
+   u8 *vbuf = vb2_plane_va

[PATCHv1 07/12] vivid: add the kthread code that controls the video rate

[Hans Verkuil]

From: Hans Verkuil 

Add the kthread handlers for video/vbi capture and video/vbi output.
These carefully control the rate at which frames are generated (video
capture) and accepted (video output). While the short-term jitter is
around the order of a jiffie, in the long term the rate matches the
configured framerate exactly.

The capture thread handler also takes care of the video looping and
of capture and overlay support. This is probably the most complex part
of this driver due to the many combinations of crop, compose and scaling
on the input and output, and the blending that has to be done if
overlay support is enabled as well.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-kthread-cap.c | 873 +++
 drivers/media/platform/vivid/vivid-kthread-cap.h |  26 +
 drivers/media/platform/vivid/vivid-kthread-out.c | 302 
 drivers/media/platform/vivid/vivid-kthread-out.h |  26 +
 4 files changed, 1227 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-kthread-cap.c
 create mode 100644 drivers/media/platform/vivid/vivid-kthread-cap.h
 create mode 100644 drivers/media/platform/vivid/vivid-kthread-out.c
 create mode 100644 drivers/media/platform/vivid/vivid-kthread-out.h

diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c 
b/drivers/media/platform/vivid/vivid-kthread-cap.c
new file mode 100644
index 000..e32712e
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -0,0 +1,873 @@
+/*
+ * vivid-kthread-cap.h - video/vbi capture thread support functions.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-vid-common.h"
+#include "vivid-vid-cap.h"
+#include "vivid-vid-out.h"
+#include "vivid-radio-common.h"
+#include "vivid-radio-rx.h"
+#include "vivid-radio-tx.h"
+#include "vivid-sdr-cap.h"
+#include "vivid-vbi-cap.h"
+#include "vivid-vbi-out.h"
+#include "vivid-osd.h"
+#include "vivid-ctrls.h"
+
+static inline v4l2_std_id vivid_get_std_cap(const struct vivid_dev *dev)
+{
+   if (vivid_is_sdtv_cap(dev))
+   return dev->std_cap;
+   return 0;
+}
+
+static void copy_pix(struct vivid_dev *dev, int win_y, int win_x,
+   u16 *cap, const u16 *osd)
+{
+   u16 out;
+   int left = dev->overlay_out_left;
+   int top = dev->overlay_out_top;
+   int fb_x = win_x + left;
+   int fb_y = win_y + top;
+   int i;
+
+   out = *cap;
+   *cap = *osd;
+   if (dev->bitmap_out) {
+   const u8 *p = dev->bitmap_out;
+   unsigned stride = (dev->compose_out.width + 7) / 8;
+
+   win_x -= dev->compose_out.left;
+   win_y -= dev->compose_out.top;
+   if (!(p[stride * win_y + win_x / 8] & (1 << (win_x & 7
+   return;
+   }
+
+   for (i = 0; i < dev->clipcount_out; i++) {
+   struct v4l2_rect *r = &dev->clips_out[i].c;
+
+   if (fb_y >= r->top && fb_y < r->top + r->height &&
+   fb_x >= r->left && fb_x < r->left + r->width)
+   return;
+   }
+   if ((dev->fbuf_out_flags & V4L2_FBUF_FLAG_CHROMAKEY) &&
+   *osd != dev->chromakey_out)
+   return;
+   if ((dev->fbuf_out_flags & V4L2_FBUF_FLAG_SRC_CHROMAKEY) &&
+   out == dev->chromakey_out)
+   return;
+   if (dev->fmt_cap->alpha_mask) {
+   if ((dev->fbuf_out_flags & V4L2_FBUF_FLAG_GLOBAL_ALPHA) &&
+   dev->global_alpha_out)
+   return;
+   if ((dev->fbuf_out_flags & V4L2_FBUF_FLAG_LOCAL_ALPHA) &&
+   *cap & dev->fmt_cap->alpha_mask)
+   return;
+   if ((dev->fbuf_out_flags & V4L2_FBUF_FLAG_LOCAL_INV_ALPHA) &&
+   !(*cap & dev->fmt_cap->alpha_mask))
+   return;
+   }
+   *cap = out;
+}
+
+static void blend_line(struct vivid_dev *dev, unsigned y_offset, unsigned 
x_offset,
+   u8

[PATCHv1 11/12] vivid: add support for software defined radio

[Hans Verkuil]

From: Hans Verkuil 

This adds support for an SDR capture device. It generates simple
sinus/cosinus waves. The code for that has been contributed by
Antti.

Signed-off-by: Antti Palosaari 
Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-sdr-cap.c | 497 +++
 drivers/media/platform/vivid/vivid-sdr-cap.h |  34 ++
 2 files changed, 531 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-sdr-cap.c
 create mode 100644 drivers/media/platform/vivid/vivid-sdr-cap.h

diff --git a/drivers/media/platform/vivid/vivid-sdr-cap.c 
b/drivers/media/platform/vivid/vivid-sdr-cap.c
new file mode 100644
index 000..9e81c8c
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-sdr-cap.c
@@ -0,0 +1,497 @@
+/*
+ * vivid-sdr-cap.c - software defined radio support functions.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-ctrls.h"
+#include "vivid-sdr-cap.h"
+
+static const struct v4l2_frequency_band bands_adc[] = {
+   {
+   .tuner = 0,
+   .type = V4L2_TUNER_ADC,
+   .index = 0,
+   .capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   =  30,
+   .rangehigh  =  30,
+   },
+   {
+   .tuner = 0,
+   .type = V4L2_TUNER_ADC,
+   .index = 1,
+   .capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   =  91,
+   .rangehigh  = 280,
+   },
+   {
+   .tuner = 0,
+   .type = V4L2_TUNER_ADC,
+   .index = 2,
+   .capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   = 320,
+   .rangehigh  = 320,
+   },
+};
+
+/* ADC band midpoints */
+#define BAND_ADC_0 ((bands_adc[0].rangehigh + bands_adc[1].rangelow) / 2)
+#define BAND_ADC_1 ((bands_adc[1].rangehigh + bands_adc[2].rangelow) / 2)
+
+static const struct v4l2_frequency_band bands_fm[] = {
+   {
+   .tuner = 1,
+   .type = V4L2_TUNER_RF,
+   .index = 0,
+   .capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   =5000,
+   .rangehigh  =  20,
+   },
+};
+
+static void vivid_thread_sdr_cap_tick(struct vivid_dev *dev)
+{
+   struct vivid_buffer *sdr_cap_buf = NULL;
+
+   dprintk(dev, 1, "SDR Capture Thread Tick\n");
+
+   /* Drop a certain percentage of buffers. */
+   if (dev->perc_dropped_buffers &&
+   prandom_u32_max(100) < dev->perc_dropped_buffers)
+   return;
+
+   spin_lock(&dev->slock);
+   if (!list_empty(&dev->sdr_cap_active)) {
+   sdr_cap_buf = list_entry(dev->sdr_cap_active.next,
+struct vivid_buffer, list);
+   list_del(&sdr_cap_buf->list);
+   }
+   spin_unlock(&dev->slock);
+
+   if (sdr_cap_buf) {
+   sdr_cap_buf->vb.v4l2_buf.sequence = dev->sdr_cap_seq_count;
+   vivid_sdr_cap_process(dev, sdr_cap_buf);
+   v4l2_get_timestamp(&sdr_cap_buf->vb.v4l2_buf.timestamp);
+   sdr_cap_buf->vb.v4l2_buf.timestamp.tv_sec += 
dev->time_wrap_offset;
+   vb2_buffer_done(&sdr_cap_buf->vb, dev->dqbuf_error ?
+   VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
+   dev->dqbuf_error = false;
+   }
+}
+
+static int vivid_thread_sdr_cap(void *data)
+{
+   struct vivid_dev *dev = data;
+   u64 samples_since_start;
+   u64 buffers_since_start;
+   u64 next_jiffies_since_start;
+   unsigned long jiffies_since_start;
+   unsigned long cur_jiffies;
+
+   dprintk(dev, 1, "SDR Capture Thread Start\n");
+
+   set_freezable();
+
+   /* Resets frame counters */
+   dev->sdr_cap_seq_offset = 0;
+   if (dev->seq_wrap)
+   dev->sdr_cap_seq_offset = 0xff80U;
+   dev->jiffies_sdr_cap = jiffies;
+   dev->sdr_cap_seq_resync = false;
+
+   

[PATCHv1 10/12] vivid: add support for radio receivers and transmitters

[Hans Verkuil]

From: Hans Verkuil 

This adds radio receiver and transmitter support. Part of that is common
to both and so is placed in the radio-common source.

These drivers also support RDS. In order to generate valid RDS data a
simple RDS generator is implemented in rds-gen.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-radio-common.c | 189 ++
 drivers/media/platform/vivid/vivid-radio-common.h |  40 +++
 drivers/media/platform/vivid/vivid-radio-rx.c | 287 ++
 drivers/media/platform/vivid/vivid-radio-rx.h |  31 +++
 drivers/media/platform/vivid/vivid-radio-tx.c | 141 +++
 drivers/media/platform/vivid/vivid-radio-tx.h |  29 +++
 drivers/media/platform/vivid/vivid-rds-gen.c  | 164 +
 drivers/media/platform/vivid/vivid-rds-gen.h  |  53 
 8 files changed, 934 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-radio-common.c
 create mode 100644 drivers/media/platform/vivid/vivid-radio-common.h
 create mode 100644 drivers/media/platform/vivid/vivid-radio-rx.c
 create mode 100644 drivers/media/platform/vivid/vivid-radio-rx.h
 create mode 100644 drivers/media/platform/vivid/vivid-radio-tx.c
 create mode 100644 drivers/media/platform/vivid/vivid-radio-tx.h
 create mode 100644 drivers/media/platform/vivid/vivid-rds-gen.c
 create mode 100644 drivers/media/platform/vivid/vivid-rds-gen.h

diff --git a/drivers/media/platform/vivid/vivid-radio-common.c 
b/drivers/media/platform/vivid/vivid-radio-common.c
new file mode 100644
index 000..78c1e92
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-radio-common.c
@@ -0,0 +1,189 @@
+/*
+ * vivid-radio-common.c - common radio rx/tx support functions.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-ctrls.h"
+#include "vivid-radio-common.h"
+#include "vivid-rds-gen.h"
+
+/*
+ * These functions are shared between the vivid receiver and transmitter
+ * since both use the same frequency bands.
+ */
+
+const struct v4l2_frequency_band vivid_radio_bands[TOT_BANDS] = {
+   /* Band FM */
+   {
+   .type = V4L2_TUNER_RADIO,
+   .index = 0,
+   .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   = FM_FREQ_RANGE_LOW,
+   .rangehigh  = FM_FREQ_RANGE_HIGH,
+   .modulation = V4L2_BAND_MODULATION_FM,
+   },
+   /* Band AM */
+   {
+   .type = V4L2_TUNER_RADIO,
+   .index = 1,
+   .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   = AM_FREQ_RANGE_LOW,
+   .rangehigh  = AM_FREQ_RANGE_HIGH,
+   .modulation = V4L2_BAND_MODULATION_AM,
+   },
+   /* Band SW */
+   {
+   .type = V4L2_TUNER_RADIO,
+   .index = 2,
+   .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_FREQ_BANDS,
+   .rangelow   = SW_FREQ_RANGE_LOW,
+   .rangehigh  = SW_FREQ_RANGE_HIGH,
+   .modulation = V4L2_BAND_MODULATION_AM,
+   },
+};
+
+/*
+ * Initialize the RDS generator. If we can loop, then the RDS generator
+ * is set up with the values from the RDS TX controls, otherwise it
+ * will fill in standard values using one of two alternates.
+ */
+void vivid_radio_rds_init(struct vivid_dev *dev)
+{
+   struct vivid_rds_gen *rds = &dev->rds_gen;
+   bool alt = dev->radio_rx_rds_use_alternates;
+
+   /* Do nothing, blocks will be filled by the transmitter */
+   if (dev->radio_rds_loop && !dev->radio_tx_rds_controls)
+   return;
+
+   if (dev->radio_rds_loop) {
+   v4l2_ctrl_lock(dev->radio_tx_rds_pi);
+   rds->picode = dev->radio_tx_rds_pi->cur.val;
+   rds->pty = dev->radio_tx_rds_pty->cur.val;
+   rds->mono_stereo = dev->radio_tx_rds_mono_stereo->cur.val;
+   rds->art_head = dev->radio_tx_rds_art_head->cur.val;
+   rds->compressed = dev->radio_tx_rds_compressed->cur.val;
+   rds->dyn_pty = dev->radio_tx_rds_dyn_pty->cur.val

[PATCHv1 03/12] vivid: add core driver code

[Hans Verkuil]

From: Hans Verkuil 

This is the core driver code that creates all the driver instances
and all the configured devices.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-core.c | 1390 +
 drivers/media/platform/vivid/vivid-core.h |  520 +++
 2 files changed, 1910 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-core.c
 create mode 100644 drivers/media/platform/vivid/vivid-core.h

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
new file mode 100644
index 000..708b053
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -0,0 +1,1390 @@
+/*
+ * vivid-core.c - A Virtual Video Test Driver, core initialization
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-vid-common.h"
+#include "vivid-vid-cap.h"
+#include "vivid-vid-out.h"
+#include "vivid-radio-common.h"
+#include "vivid-radio-rx.h"
+#include "vivid-radio-tx.h"
+#include "vivid-sdr-cap.h"
+#include "vivid-vbi-cap.h"
+#include "vivid-vbi-out.h"
+#include "vivid-osd.h"
+#include "vivid-ctrls.h"
+
+#define VIVID_MODULE_NAME "vivid"
+
+/* The maximum number of vivid devices */
+#define VIVID_MAX_DEVS 64
+
+MODULE_DESCRIPTION("Virtual Video Test Driver");
+MODULE_AUTHOR("Hans Verkuil");
+MODULE_LICENSE("GPL");
+
+static unsigned n_devs = 1;
+module_param(n_devs, uint, 0444);
+MODULE_PARM_DESC(n_devs, " number of driver instances to create");
+
+static int vid_cap_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(vid_cap_nr, int, NULL, 0444);
+MODULE_PARM_DESC(vid_cap_nr, " videoX start number, -1 is autodetect");
+
+static int vid_out_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(vid_out_nr, int, NULL, 0444);
+MODULE_PARM_DESC(vid_out_nr, " videoX start number, -1 is autodetect");
+
+static int vbi_cap_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(vbi_cap_nr, int, NULL, 0444);
+MODULE_PARM_DESC(vbi_cap_nr, " vbiX start number, -1 is autodetect");
+
+static int vbi_out_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(vbi_out_nr, int, NULL, 0444);
+MODULE_PARM_DESC(vbi_out_nr, " vbiX start number, -1 is autodetect");
+
+static int sdr_cap_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(sdr_cap_nr, int, NULL, 0444);
+MODULE_PARM_DESC(sdr_cap_nr, " swradioX start number, -1 is autodetect");
+
+static int radio_rx_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(radio_rx_nr, int, NULL, 0444);
+MODULE_PARM_DESC(radio_rx_nr, " radioX start number, -1 is autodetect");
+
+static int radio_tx_nr[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 };
+module_param_array(radio_tx_nr, int, NULL, 0444);
+MODULE_PARM_DESC(radio_tx_nr, " radioX start number, -1 is autodetect");
+
+static int ccs_cap_mode[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 
};
+module_param_array(ccs_cap_mode, int, NULL, 0444);
+MODULE_PARM_DESC(ccs_cap_mode, " capture crop/compose/scale mode:\n"
+  "\t\tbit 0=crop, 1=compose, 2=scale,\n"
+  "\t\t-1=user-controlled (default)");
+
+static int ccs_out_mode[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = -1 
};
+module_param_array(ccs_out_mode, int, NULL, 0444);
+MODULE_PARM_DESC(ccs_out_mode, " output crop/compose/scale mode:\n"
+  "\t\tbit 0=crop, 1=compose, 2=scale,\n"
+  "\t\t-1=user-controlled (default)");
+
+static unsigned multiplanar[VIVID_MAX_DEVS];
+module_param_array(multiplanar, uint, NULL, 0444);
+MODULE_PARM_DESC(multiplanar, " 0 (default) is alternating single and 
multiplanar devices,\n"
+ "\t\t1 is single planar devices,\n"
+ "\t\t2 is multiplanar devices");
+
+/* Default: video + vbi-cap (raw and sliced) + radio rx + radio tx + sdr + 
vbi-out + vid-out */
+static unsigned node_ty

[PATCHv1 04/12] vivid: add the control handling code

[Hans Verkuil]

From: Hans Verkuil 

The vivid-ctrls code sets up and processes the various V4L2 controls
that are needed by this driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-ctrls.c | 1474 
 drivers/media/platform/vivid/vivid-ctrls.h |   34 +
 2 files changed, 1508 insertions(+)
 create mode 100644 drivers/media/platform/vivid/vivid-ctrls.c
 create mode 100644 drivers/media/platform/vivid/vivid-ctrls.h

diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
new file mode 100644
index 000..20fbcb1
--- /dev/null
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -0,0 +1,1474 @@
+/*
+ * vivid-ctrls.c - control support functions.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vivid-core.h"
+#include "vivid-vid-cap.h"
+#include "vivid-vid-out.h"
+#include "vivid-vid-common.h"
+#include "vivid-radio-common.h"
+#include "vivid-osd.h"
+#include "vivid-ctrls.h"
+
+#define VIVID_CID_CUSTOM_BASE  (V4L2_CID_USER_BASE | 0xf000)
+#define VIVID_CID_BUTTON   (VIVID_CID_CUSTOM_BASE + 0)
+#define VIVID_CID_BOOLEAN  (VIVID_CID_CUSTOM_BASE + 1)
+#define VIVID_CID_INTEGER  (VIVID_CID_CUSTOM_BASE + 2)
+#define VIVID_CID_INTEGER64(VIVID_CID_CUSTOM_BASE + 3)
+#define VIVID_CID_MENU (VIVID_CID_CUSTOM_BASE + 4)
+#define VIVID_CID_STRING   (VIVID_CID_CUSTOM_BASE + 5)
+#define VIVID_CID_BITMASK  (VIVID_CID_CUSTOM_BASE + 6)
+#define VIVID_CID_INTMENU  (VIVID_CID_CUSTOM_BASE + 7)
+
+#define VIVID_CID_IMAGE_PROC_BASE  (V4L2_CTRL_CLASS_IMAGE_PROC | 0xf000)
+#define VIVID_CID_OSD_TEXT_MODE(VIVID_CID_IMAGE_PROC_BASE + 0)
+#define VIVID_CID_HOR_MOVEMENT (VIVID_CID_IMAGE_PROC_BASE + 1)
+#define VIVID_CID_VERT_MOVEMENT(VIVID_CID_IMAGE_PROC_BASE + 2)
+#define VIVID_CID_SHOW_BORDER  (VIVID_CID_IMAGE_PROC_BASE + 4)
+#define VIVID_CID_SHOW_SQUARE  (VIVID_CID_IMAGE_PROC_BASE + 5)
+#define VIVID_CID_INSERT_SAV   (VIVID_CID_IMAGE_PROC_BASE + 6)
+#define VIVID_CID_INSERT_EAV   (VIVID_CID_IMAGE_PROC_BASE + 7)
+#define VIVID_CID_VBI_CAP_INTERLACED   (VIVID_CID_IMAGE_PROC_BASE + 8)
+
+#define VIVID_CID_HFLIP(VIVID_CID_IMAGE_PROC_BASE + 20)
+#define VIVID_CID_VFLIP(VIVID_CID_IMAGE_PROC_BASE + 21)
+#define VIVID_CID_STD_ASPECT_RATIO (VIVID_CID_IMAGE_PROC_BASE + 22)
+#define VIVID_CID_DV_TIMINGS_ASPECT_RATIO  (VIVID_CID_IMAGE_PROC_BASE + 23)
+#define VIVID_CID_TSTAMP_SRC   (VIVID_CID_IMAGE_PROC_BASE + 24)
+#define VIVID_CID_COLORSPACE   (VIVID_CID_IMAGE_PROC_BASE + 25)
+#define VIVID_CID_LIMITED_RGB_RANGE(VIVID_CID_IMAGE_PROC_BASE + 26)
+#define VIVID_CID_ALPHA_MODE   (VIVID_CID_IMAGE_PROC_BASE + 27)
+#define VIVID_CID_HAS_CROP_CAP (VIVID_CID_IMAGE_PROC_BASE + 28)
+#define VIVID_CID_HAS_COMPOSE_CAP  (VIVID_CID_IMAGE_PROC_BASE + 29)
+#define VIVID_CID_HAS_SCALER_CAP   (VIVID_CID_IMAGE_PROC_BASE + 30)
+#define VIVID_CID_HAS_CROP_OUT (VIVID_CID_IMAGE_PROC_BASE + 31)
+#define VIVID_CID_HAS_COMPOSE_OUT  (VIVID_CID_IMAGE_PROC_BASE + 32)
+#define VIVID_CID_HAS_SCALER_OUT   (VIVID_CID_IMAGE_PROC_BASE + 33)
+#define VIVID_CID_LOOP_VIDEO   (VIVID_CID_IMAGE_PROC_BASE + 34)
+#define VIVID_CID_SEQ_WRAP (VIVID_CID_IMAGE_PROC_BASE + 35)
+#define VIVID_CID_TIME_WRAP(VIVID_CID_IMAGE_PROC_BASE + 36)
+#define VIVID_CID_MAX_EDID_BLOCKS  (VIVID_CID_IMAGE_PROC_BASE + 37)
+#define VIVID_CID_PERCENTAGE_FILL  (VIVID_CID_IMAGE_PROC_BASE + 38)
+
+#define VIVID_CID_STD_SIGNAL_MODE  (VIVID_CID_IMAGE_PROC_BASE + 60)
+#define VIVID_CID_STANDARD (VIVID_CID_IMAGE_PROC_BASE + 61)
+#define VIVID_CID_DV_TIMINGS_SIGNAL_MODE   (VIVID_CID_IMAGE_PROC_BASE + 62)
+#define VIVID_CID_DV_TIMINGS   (VIVID_CID_IMAGE_PROC_BASE + 63)
+#define VIVID_CID_PERC_DROPPED (VIVID_CID_IMAGE_PROC_BASE + 64)
+#define VIVID_CID_DISCONNECT   (VIVID_CID_IMAGE_PROC_BASE + 65)
+#define VIVID_CID_DQBUF_ERROR  (VIVID_CID_IMAGE_PROC_BA

Re: omap3isp with DM3730 not working?!

[Michael Dietschi]

Am 29.07.2014 02:53, schrieb Laurent Pinchart:
You're right. Maybe that's the first problem to be fixed though ;-) 
Michael, could you try using the "official" (and under development) 
BT.656 support code for the OMAP3 ISP driver ? I've just pushed the 
branch to git://linuxtv.org/pinchartl/media.git omap3isp/bt656 


Laurent,

I did try this kernel and it does not work either - but with a different 
error.

Any Idea?

Michael


These are the commands and their output:

root@overo:~$  media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP 
CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC


output":0[1]'
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Resetting all links to inactive
Setting up link 16:0 -> 5:0 [1]
Setting up link 5:1 -> 6:0 [1]

root@overo:~$  media-ctl -v -V '"tvp5150 3-005c":0 [UYVY2X8 720x576], 
"OMAP3 ISP CCDC":1 [UYVY2X8 720x576]'Opening


media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Setting up format UYVY2X8 720x576 on pad tvp5150 3-005c/0
Format set: UYVY2X8 720x240
Setting up format UYVY2X8 720x240 on pad OMAP3 ISP CCDC/0
Format set: UYVY2X8 720x240
Setting up format UYVY2X8 720x576 on pad OMAP3 ISP CCDC/1
Format set: UYVY 720x240

root@overo:~$  yavta -f UYVY -s 720x576 --capture=1 --file=imagele 
/dev/video2


Device /dev/video2 opened.
Device `OMAP3 ISP CCDC output' on `media' is a video capture device.
Video format set: UYVY (59565955) 720x576 (stride 1440) buffer size 829440
Video format: UYVY (59565955) 720x576 (stride 1440) buffer size 829440
8 buffers requested.
length: 829440 offset: 0
Buffer 0 mapped at address 0xb6e79000.
length: 829440 offset: 831488
Buffer 1 mapped at address 0xb6dae000.
length: 829440 offset: 1662976
Buffer 2 mapped at address 0xb6ce3000.
length: 829440 offset: 2494464
Buffer 3 mapped at address 0xb6c18000.
length: 829440 offset: 3325952
Buffer 4 mapped at address 0xb6b4d000.
length: 829440 offset: 4157440
Buffer 5 mapped at address 0xb6a82000.
length: 829440 offset: 4988928
Buffer 6 mapped at address 0xb69b7000.
length: 829440 offset: 5820416
Buffer 7 mapped at address 0xb68ec000.
Unable to start streaming: Invalid argument (22).
8 buffers released.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3isp with DM3730 not working?!

[Enrico]

On Wed, Jul 30, 2014 at 4:56 PM, Michael Dietschi
 wrote:
> Am 29.07.2014 02:53, schrieb Laurent Pinchart:
>>
>> You're right. Maybe that's the first problem to be fixed though ;-)
>> Michael, could you try using the "official" (and under development) BT.656
>> support code for the OMAP3 ISP driver ? I've just pushed the branch to
>> git://linuxtv.org/pinchartl/media.git omap3isp/bt656
>
>
> Laurent,
>
> I did try this kernel and it does not work either - but with a different
> error.
> Any Idea?
>
> Michael
>
>
> These are the commands and their output:

Standard question: are you using media-ctl from
git://linuxtv.org/pinchartl/v4l-utils.git field branch and latest
yavta from git://git.ideasonboard.org/yavta.git ?

Enrico
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165

[Matthias Schwarzott]

On 29.07.2014 21:45, Antti Palosaari wrote:
> 
> Do you need to know whole firmware version?
There is only 1 byte to be used and it is called patch version.
> How did you obtain it, from
> sniff?
Yes - but it also is visible in code near crc version (see below).

> What happens if you don't tell fw version to chip at all?
>
In other places it is read to verify a fw was uploaded (compare to be
not equal 0x00).
I guess the exact value is never needed (so just for information).
But I did not try it.

> Usually, almost 100%, firmware version as well all the other needed
> information, is included to firmware image itself. I don't remember many
> cases where special handling is needed. One (only one?) of such case is
> af9013, where I resolved issues by calculating fw checksum by the
> driver. IIRC chip didn't boot if there was wrong checksum for fw.

The checksum is not needed to get the device working.
The chip itself only calculates it when uploading data - and the driver
reads out the calculated checksum and compares it to the expected value.
It is only a verification of the correct upload.

> 
> Own headers and checksums causes troubles if I someone would like to
> extract different firmwares from various windows binaries to test.
> 
> If windows driver needs to know that kind of things, those are usually
> found very near firmware image from the driver binary. Most often just
> dump 32 bytes after firmware image and it is somewhere there. Or before
> firmware image. That is because those are values are stored to same
> source code file => compiler puts that stuff ~same location.
> 
I had a look at the driver - the code itself has the constants compiled
in - they are really mixed with the assembly code.

Rewritten in C it is code that has fixed values as parameters to functions.

ret = load_firmware(firmware,
  0x12, /* patch version */
  48, /* block count */
  0xaa0c /* crc */
);

I also would prefer your version with static const variables near the data.

> static const unsigned char firmware[] = {
>   0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,
>   0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff,
> };
> 
> static const unsigned int firmware_checksum = 0x01234567;
> static const unsigned int firmware_version = 0x002b;
> 
Regards
Matthias

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165

[Antti Palosaari]

All-in-all, did I understand correctly none of those header values are 
not required anymore?


hdr[0] own FW version. used by driver to print our own FW file version
hdr[1] --''--
hdr[2] vendor FW version. programmed to chip register but chip does not 
need it. read back in order to detect if FW is loaded or not

hdr[3] padding. not used
hdr[4] number of FW blocks. driver could calculate it.
hdr[5] padding. not used
hdr[6] crc. not mandatory & driver could calculate it. not 100% FW 
related, chip uses it for every write. verify xfer errors

hdr[7] --''--

regards
Antti



On 07/30/2014 09:50 PM, Matthias Schwarzott wrote:

On 29.07.2014 21:45, Antti Palosaari wrote:


Do you need to know whole firmware version?

There is only 1 byte to be used and it is called patch version.

How did you obtain it, from
sniff?

Yes - but it also is visible in code near crc version (see below).


What happens if you don't tell fw version to chip at all?


In other places it is read to verify a fw was uploaded (compare to be
not equal 0x00).
I guess the exact value is never needed (so just for information).
But I did not try it.


Usually, almost 100%, firmware version as well all the other needed
information, is included to firmware image itself. I don't remember many
cases where special handling is needed. One (only one?) of such case is
af9013, where I resolved issues by calculating fw checksum by the
driver. IIRC chip didn't boot if there was wrong checksum for fw.


The checksum is not needed to get the device working.
The chip itself only calculates it when uploading data - and the driver
reads out the calculated checksum and compares it to the expected value.
It is only a verification of the correct upload.



Own headers and checksums causes troubles if I someone would like to
extract different firmwares from various windows binaries to test.

If windows driver needs to know that kind of things, those are usually
found very near firmware image from the driver binary. Most often just
dump 32 bytes after firmware image and it is somewhere there. Or before
firmware image. That is because those are values are stored to same
source code file => compiler puts that stuff ~same location.


I had a look at the driver - the code itself has the constants compiled
in - they are really mixed with the assembly code.

Rewritten in C it is code that has fixed values as parameters to functions.

ret = load_firmware(firmware,
   0x12, /* patch version */
   48, /* block count */
   0xaa0c /* crc */
);

I also would prefer your version with static const variables near the data.


static const unsigned char firmware[] = {
   0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,
   0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff,
};

static const unsigned int firmware_checksum = 0x01234567;
static const unsigned int firmware_version = 0x002b;


Regards
Matthias



--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Antti Palosaari]

On 07/30/2014 04:00 PM, Antti Palosaari wrote:



On 07/30/2014 08:13 AM, Bjoern wrote:

Hello Rudy

I use a similar card from Digital Devices with Ubuntu 14.04 and
kernel 3.13.0-32-generic. Support for this card was not build into
the kernel and I had to compile it myself. I had to use
media_build_experimental from Mr. Endriss.

http://linuxtv.org/hg/~endriss/media_build_experimental

Your card should be supported with this version.

Regards, Thomas


Hi Rudy,

What Thomas writes is absolutely correct...

This is unfortunately the worst situation I've ever run across in
Linux... There was a kernel driver that worked and was supported by
Digital Devices. Then, from what I read, changes to how the V4L drivers
have to be written was changed - Digital Devices doesn't like that and
they force users to use "experimental" builds which are the "old
style".

This is total rubbish imo - if this is how it was decided that the
drivers have to be nowadays then adjust them. Why am I paying such a lot
of money others right, these DD cards are really not cheap?

Some attempts have been made by people active here to adapt the drivers
and make them work in newer kernels, but so far no one has succeeded.
Last attempt was in Jan 2014 iirc, since then - silence.

I wish I could help out, I can code but Linux is well just a bit more
"difficult" I guess ;-)


I have one of such device too, but I have been too busy all the time
with other drivers...

Basically these DTV drivers should be developed in a order, bridge
driver first, then demod and tuner - for one single device. After it is
committed in tree, you could start adding new devices and drivers. If
you try implement too big bunch of things as a once, you will likely
fail endless reviews and so.

I don't know what is change in development process which causes these
problems. What I remember there has been only few big changes in recent
years, change from Mercurial to Git and reorganization of
directories/files.


Device I have seems to be:
DD Cine S2 V6.5 - Twin Tuner Card DVB-S/S2 (PCI Express Card)
DD DuoFlex C/C2/T/T2 Expansion (V3) - Twin Tuner Expansion-modul DVB-C/T/T2

I will start looking DVB-S/S2 support at the very first as it is the 
bridge needed in any case. I have no experience from PCIe devices...


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] OMAP3 ISP BT.656 support

[Laurent Pinchart]

Hi Enrico,

On Wednesday 23 July 2014 15:57:51 Enrico wrote:
> On Wed, Jul 23, 2014 at 3:54 PM, Enrico wrote:

[snip]

> > You were right i was using the wrong binary, now the output is:
> > 
> > ...
> > - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> > type V4L2 subdev subtype Unknown flags 0
> > device node name /dev/v4l-subdev2
> > pad0: Sink
> > [fmt:UYVY2X8/720x625 field:interlaced]
> > ...
> > pad1: Source
> > [fmt:UYVY/720x624 field:interlaced
> >  crop.bounds:(0,0)/720x624
> >  crop:(0,0)/720x624]
> > ...
> > - entity 16: tvp5150 1-005c (1 pad, 1 link)
> >  type V4L2 subdev subtype Unknown flags 0
> >  device node name /dev/v4l-subdev8
> > pad0: Source
> > [fmt:UYVY2X8/720x625 field:interlaced]

That's surprising. Have you applied the tvp5150 patches from the 
omap3isp/bt656 branch ? The field should be hardcoded to V4L2_FIELD_ALTERNATE 
(reported as "alternate" by media-ctl), as the tvp5150 alternates between the 
top and bottom fields in consecutive frames. The CCDC input should then be 
configured to V4L2_FIELD_ALTERNATE as well, and the CCDC output to 
V4L2_FIELD_ALTERNATE ("alternate"), V4L2_FIELD_INTERLACED_TB ("interlaced-tb") 
or V4L2_FIELD_INTERLACED_BT ("interlaced-bt").

> > but i still get the same error:
> > 
> > root@igep00x0:~/field# ./yavta -f UYVY -n4 -s 720x624 -c100 /dev/video2
> > Device /dev/video2 opened.
> > Device `OMAP3 ISP CCDC output' on `media' is a video output (without
> > mplanes) device.
> > Video format set: UYVY (59565955) 720x624 (stride 1440) field none
> > buffer size 898560
> > Video format: UYVY (59565955) 720x624 (stride 1440) field none buffer
> > size 898560
> > 4 buffers requested.
> > length: 898560 offset: 0 timestamp type/source: mono/EoF
> > Buffer 0/0 mapped at address 0xb6d95000.
> > length: 898560 offset: 901120 timestamp type/source: mono/EoF
> > Buffer 1/0 mapped at address 0xb6cb9000.
> > length: 898560 offset: 1802240 timestamp type/source: mono/EoF
> > Buffer 2/0 mapped at address 0xb6bdd000.
> > length: 898560 offset: 2703360 timestamp type/source: mono/EoF
> > Buffer 3/0 mapped at address 0xb6b01000.
> > Unable to start streaming: Invalid argument (22).
> > 4 buffers released.
> 
> Same error adding field parameter to yavta:
> ./yavta -f UYVY -n4 -s 720x624 -c100 --field interlaced /dev/video2


-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Rudy Zijlstra]

On 19-07-14 19:49, Thomas Kaiser wrote:


Hello Rudy

I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 
3.13.0-32-generic. Support for this card was not build into the kernel 
and I had to compile it myself. I had to use media_build_experimental 
from Mr. Endriss.


http://linuxtv.org/hg/~endriss/media_build_experimental

Your card should be supported with this version.

Regards, Thomas



Hi Thomas,

thank you for the information.

Is there a preferred kernel for the experimental?

Cheers


Rudy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Antti Palosaari]

On 07/30/2014 11:56 PM, Raymond Jender wrote:

Get me off this list!  D A M I T !



To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org

More majordomo info at http://vger.kernel.org/majordomo-info.html


--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Rudy Zijlstra]

On 30-07-14 22:52, Antti Palosaari wrote:



On 07/30/2014 04:00 PM, Antti Palosaari wrote:



On 07/30/2014 08:13 AM, Bjoern wrote:

Hello Rudy

I use a similar card from Digital Devices with Ubuntu 14.04 and
kernel 3.13.0-32-generic. Support for this card was not build into
the kernel and I had to compile it myself. I had to use
media_build_experimental from Mr. Endriss.

http://linuxtv.org/hg/~endriss/media_build_experimental

Your card should be supported with this version.

Regards, Thomas


Hi Rudy,

What Thomas writes is absolutely correct...

This is unfortunately the worst situation I've ever run across in
Linux... There was a kernel driver that worked and was supported by
Digital Devices. Then, from what I read, changes to how the V4L drivers
have to be written was changed - Digital Devices doesn't like that and
they force users to use "experimental" builds which are the "old
style".

This is total rubbish imo - if this is how it was decided that the
drivers have to be nowadays then adjust them. Why am I paying such a 
lot

of money others right, these DD cards are really not cheap?

Some attempts have been made by people active here to adapt the drivers
and make them work in newer kernels, but so far no one has succeeded.
Last attempt was in Jan 2014 iirc, since then - silence.

I wish I could help out, I can code but Linux is well just a bit more
"difficult" I guess ;-)


I have one of such device too, but I have been too busy all the time
with other drivers...

Basically these DTV drivers should be developed in a order, bridge
driver first, then demod and tuner - for one single device. After it is
committed in tree, you could start adding new devices and drivers. If
you try implement too big bunch of things as a once, you will likely
fail endless reviews and so.

I don't know what is change in development process which causes these
problems. What I remember there has been only few big changes in recent
years, change from Mercurial to Git and reorganization of
directories/files.


Device I have seems to be:
DD Cine S2 V6.5 - Twin Tuner Card DVB-S/S2 (PCI Express Card)
DD DuoFlex C/C2/T/T2 Expansion (V3) - Twin Tuner Expansion-modul 
DVB-C/T/T2


I will start looking DVB-S/S2 support at the very first as it is the 
bridge needed in any case. I have no experience from PCIe devices...


regards
Antti


When you have patches that can be tested, willing to help test

Cannot promise to test immediate though

Cheers


Rudy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [next:master 8790/9825] tuner-core.c:undefined reference to `tda829x_attach'

[Antti Palosaari]

Mauro,
Could you look that? I simply cannot understand why it does not see for 
example xc2028_attach(). All those tuners seems to be analog or hybrid.


$ grep CONFIG_MEDIA_TUNER= .config
CONFIG_MEDIA_TUNER=y
$ grep CONFIG_VIDEO_TUNER= .config
CONFIG_VIDEO_TUNER=y
$ grep CONFIG_MEDIA_TUNER_XC2028= .config
CONFIG_MEDIA_TUNER_XC2028=m
$ grep CONFIG_MEDIA_ATTACH= .config
$ grep CONFIG_MEDIA_SUBDRV_AUTOSELECT= .config


Why these ATV tuners are selected when MEDIA_SUBDRV_AUTOSELECT, but DTV not?

# Analog TV tuners, auto-loaded via tuner.ko
config MEDIA_TUNER
tristate
	depends on (MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || 
MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT) && I2C

default y
select MEDIA_TUNER_XC2028 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC4000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT20XX if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_TDA8290 if MEDIA_SUBDRV_AUTOSELECT
	select MEDIA_TUNER_TEA5761 if MEDIA_SUBDRV_AUTOSELECT && 
MEDIA_RADIO_SUPPORT
	select MEDIA_TUNER_TEA5767 if MEDIA_SUBDRV_AUTOSELECT && 
MEDIA_RADIO_SUPPORT

select MEDIA_TUNER_SIMPLE if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_TDA9887 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MC44S803 if MEDIA_SUBDRV_AUTOSELECT

regards
Antti

On 07/30/2014 05:15 PM, kbuild test robot wrote:

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   fcf6395d41087217d4b88d5b2ad7a1ce66ca6ced
commit: f5b44da1ac4146e06147a5df3058f4c265c932ec [8790/9825] [media] Kconfig: 
fix tuners build warnings
config: i386-randconfig-ib1-07302105 (attached as .config)

All error/warnings:

drivers/built-in.o: In function `set_type':

tuner-core.c:(.text+0x340ee6): undefined reference to `tda829x_attach'
tuner-core.c:(.text+0x340fac): undefined reference to `xc2028_attach'
tuner-core.c:(.text+0x34103e): undefined reference to `tda18271_attach'
tuner-core.c:(.text+0x34106e): undefined reference to `xc4000_attach'

drivers/built-in.o: In function `tuner_probe':

tuner-core.c:(.text+0x341484): undefined reference to `tda829x_probe'


---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation



--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems with the omap3isp

[Laurent Pinchart]

Hi Stefan,

Sorry for the late reply.

On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
> Hi Laurent,
> 
> I have some problems with the omap3isp driver. At the moment I use a
> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
> 
> 1. If I change the clock rate to 24 MHz in my camera driver the whole
> system freeze at the clk_prepare_enable. The first enable and disable
> works without any problem. The system freeze during a systemd / udev
> call of media-ctl.

I've never seen that before. Where does your sensor get its clock from ? Is it 
connected to the ISP XCLKA or XCLKB output ? What happens if you don't change 
the clock rate to 24 MHz ? What rate is it set to in that case ?

> 2. If I enable the streaming I get a  "omap3isp omap3isp: CCDC won't
> become idle!" and if I disable streaming I get a "omap3isp omap3isp:
> Unable to stop OMAP3 ISP CCDC". I think the problem is, that I can't
> disable the camera output. Do you change the order of the stream enable
> / disable after Linux 3.4?

Not that I know of.

The two problems might be related, maybe we could concentrate on the first one 
first.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fresco Logic FL2000

[Laurent Pinchart]

Hi Michael,

Sorry for the late reply.

On Tuesday 22 July 2014 11:03:35 Michael Durkin wrote:
> as sudo su
> 
> root@SDR-client:/home/mike# lsusb -v -d 1d5c:2000
> 
> Bus 002 Device 003: ID 1d5c:2000
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.10
>   bDeviceClass  239 Miscellaneous Device
>   bDeviceSubClass 2 ?
>   bDeviceProtocol 1 Interface Association
>   bMaxPacketSize064
>   idVendor   0x1d5c
>   idProduct  0x2000
>   bcdDevice1.00
>   iManufacturer   0
>   iProduct0
>   iSerial 0
>   bNumConfigurations  1

[snip]

> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   1
>   bNumEndpoints   2
>   bInterfaceClass16
>   bInterfaceSubClass  0
>   bInterfaceProtocol  0

That's, as suspected, a USB Audio/Video class device. There's currently no 
Linux driver for that, and I'm not aware any active project to develop one 
(there were prototypes developed behind closed doors though, but nothing 
published as far as I know). Frankly, given how brain-dead the A/V class 
specification is, I wouldn't hold any hope of getting support for that device 
any time soon (or ever).

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- Re: Very Urgent............

[Fabian Morision]

Greetings from gulf region

Thanks for the e-mail. I am very interested on funding lucrative
business partnership with you acting as the manager and sole
controller of the investment while i remain a silent investor for a
period of ten yrs , though I am only looking at investment
opportunities within the range you specified for a start. You can
reply me here (fmoris...@yahoo.com)

Let me know your thought asap

Regards

Financial Consultant

Mr.Fabian Morision
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:   Thu Jul 31 04:00:21 CEST 2014
git branch: test
git hash:   488046c237f3b78f91046d45662b318cd2415f64
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-16-g1db35d0
host hardware:  x86_64
host os:3.15-5.slh.2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: ERRORS
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: ERRORS
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: ERRORS
linux-git-sh: ERRORS
linux-git-x86_64: ERRORS
linux-2.6.32.27-i686: ERRORS
linux-2.6.33.7-i686: ERRORS
linux-2.6.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16-rc1-i686: ERRORS
linux-2.6.32.27-x86_64: ERRORS
linux-2.6.33.7-x86_64: ERRORS
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16-rc1-x86_64: ERRORS
apps: WARNINGS
spec-git: OK
sparse: ERRORS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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:   Thu 31 Jul 08:04:29 CEST 2014
git branch: test
git hash:   27dcb00d0dc1d532b0da940e35a6d020ee33bd47
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-16-g1db35d0
host hardware:  x86_64
host os:3.15-5.slh.2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16-rc1-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html