Re: [PATCH] media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
thank you very very much!!
Hoping this patch find it's way into mainline ASAP! :)
It will make my life much easier, when dealing with systems with long uptime
especially.
Enrico
On Wed, 24 Jan 2018, Mauro Carvalho Chehab wrote:
Date: Wed, 24 Jan 2018 12:05:24
From: Mauro Carvalho Chehab <mche...@osg.samsung.com>
To: Enrico Mioso <mrkiko...@gmail.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Jonathan Corbet <cor...@lwn.net>
Cc: Mauro Carvalho Chehab <mche...@osg.samsung.com>,
Mauro Carvalho Chehab <mche...@infradead.org>,
Linux Doc Mailing List <linux-...@vger.kernel.org>,
Michael Krufky <mkru...@linuxtv.org>, Sean Young <s...@mess.org>,
Hans Verkuil <hans.verk...@cisco.com>,
Andrey Konovalov <andreyk...@google.com>,
Piotr Oleszczyk <piotr.oleszc...@gmail.com>,
Alexey Dobriyan <adobri...@gmail.com>
Subject: [PATCH] media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.
That prevents filling the dmesg with lots of messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
Reported-by: Enrico Mioso <mrkiko...@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
drivers/media/usb/dvb-usb/cxusb.c | 2 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index 37dea0adc695..cfe86b4864b3 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -677,6 +677,8 @@ static int dvico_bluebird_xc2028_callback(void *ptr, int
component,
case XC2028_RESET_CLK:
deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
break;
+ case XC2028_I2C_FLUSH:
+ break;
default:
deb_info("%s: unknown command %d, arg %d\n", __func__,
command, arg);
diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 366b05529915..a9968fb1e8e4 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -430,6 +430,7 @@ static int stk7700ph_xc3028_callback(void *ptr, int
component,
state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
break;
case XC2028_RESET_CLK:
+ case XC2028_I2C_FLUSH:
break;
default:
err("%s: unknown command %d, arg %d\n", __func__,
--
2.14.3
Re: [PATCH] media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
Thank you very very much for the fix.
You did really make my everyday experience better.
On Wed, 24 Jan 2018, Mauro Carvalho Chehab wrote:
Date: Wed, 24 Jan 2018 12:05:24
From: Mauro Carvalho Chehab <mche...@osg.samsung.com>
To: Enrico Mioso <mrkiko...@gmail.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Jonathan Corbet <cor...@lwn.net>
Cc: Mauro Carvalho Chehab <mche...@osg.samsung.com>,
Mauro Carvalho Chehab <mche...@infradead.org>,
Linux Doc Mailing List <linux-...@vger.kernel.org>,
Michael Krufky <mkru...@linuxtv.org>, Sean Young <s...@mess.org>,
Hans Verkuil <hans.verk...@cisco.com>,
Andrey Konovalov <andreyk...@google.com>,
Piotr Oleszczyk <piotr.oleszc...@gmail.com>,
Alexey Dobriyan <adobri...@gmail.com>
Subject: [PATCH] media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.
That prevents filling the dmesg with lots of messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
Reported-by: Enrico Mioso <mrkiko...@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
drivers/media/usb/dvb-usb/cxusb.c | 2 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index 37dea0adc695..cfe86b4864b3 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -677,6 +677,8 @@ static int dvico_bluebird_xc2028_callback(void *ptr, int
component,
case XC2028_RESET_CLK:
deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
break;
+ case XC2028_I2C_FLUSH:
+ break;
default:
deb_info("%s: unknown command %d, arg %d\n", __func__,
command, arg);
diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 366b05529915..a9968fb1e8e4 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -430,6 +430,7 @@ static int stk7700ph_xc3028_callback(void *ptr, int
component,
state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
break;
case XC2028_RESET_CLK:
+ case XC2028_I2C_FLUSH:
break;
default:
err("%s: unknown command %d, arg %d\n", __func__,
--
2.14.3
Re: [PATCH] dib700: stop flooding system ring buffer
Hello Honza,
thank you very very much for your help and hints. These things make a community
what it is, and I apreciate it extremely.
You're perfectly right, I didn't think about this well and/or enough.
Apreciated your hints.
On Wed, 24 Jan 2018, Honza Petrouš wrote:
Date: Wed, 24 Jan 2018 14:07:52
From: Honza Petrouš <jpetr...@gmail.com>
To: Enrico Mioso <mrkiko...@gmail.com>
Cc: linux-media@vger.kernel.org, Sean Young <s...@mess.org>,
Piotr Oleszczyk <piotr.oleszc...@gmail.com>,
Andrey Konovalov <andreyk...@google.com>,
Andrew Morton <a...@linux-foundation.org>,
Alexey Dobriyan <adobri...@gmail.com>,
Mauro Carvalho Chehab <mche...@kernel.org>
Subject: Re: [PATCH] dib700: stop flooding system ring buffer
Hi Enrico,
I'm not maintener, so treat next hints as hints only :)
2018-01-24 8:40 GMT+01:00 Enrico Mioso <mrkiko...@gmail.com>:
Stop flooding system ring buffer with messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
while tuning an Asus My Cinema-U3000Hybrid dvb card.
The correctness of this patch is opinable, but it's annoying me so much I
sent it anyway.
CC: linux-media@vger.kernel.org
CC: Sean Young <s...@mess.org>
CC: Piotr Oleszczyk <piotr.oleszc...@gmail.com>
CC: Andrey Konovalov <andreyk...@google.com>
CC: Andrew Morton <a...@linux-foundation.org>
CC: Alexey Dobriyan <adobri...@gmail.com>
CC: Mauro Carvalho Chehab <mche...@kernel.org>
Signed-off-by: Enrico Mioso <mrkiko...@gmail.com>
---
drivers/media/usb/dvb-usb/dib0700_devices.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 366b05529915..bc5d250ed2f2 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -432,8 +432,7 @@ static int stk7700ph_xc3028_callback(void *ptr, int
component,
case XC2028_RESET_CLK:
break;
default:
- err("%s: unknown command %d, arg %d\n", __func__,
- command, arg);
May be change err() to debug() or something similar would be better?
+ break;
return -EINVAL;
Anyway it looks strange to break before return.
In both cases (w/ or w/o removal of message) I would stay
with -EINVAL for unknown command here.
}
return 0;
--
2.16.1
/Honza
[PATCH] dib700: stop flooding system ring buffer
Stop flooding system ring buffer with messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
while tuning an Asus My Cinema-U3000Hybrid dvb card.
The correctness of this patch is opinable, but it's annoying me so much I
sent it anyway.
CC: linux-media@vger.kernel.org
CC: Sean Young <s...@mess.org>
CC: Piotr Oleszczyk <piotr.oleszc...@gmail.com>
CC: Andrey Konovalov <andreyk...@google.com>
CC: Andrew Morton <a...@linux-foundation.org>
CC: Alexey Dobriyan <adobri...@gmail.com>
CC: Mauro Carvalho Chehab <mche...@kernel.org>
Signed-off-by: Enrico Mioso <mrkiko...@gmail.com>
---
drivers/media/usb/dvb-usb/dib0700_devices.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 366b05529915..bc5d250ed2f2 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -432,8 +432,7 @@ static int stk7700ph_xc3028_callback(void *ptr, int
component,
case XC2028_RESET_CLK:
break;
default:
- err("%s: unknown command %d, arg %d\n", __func__,
- command, arg);
+ break;
return -EINVAL;
}
return 0;
--
2.16.1
Re: [PATCH] dvb-usb: Add memory free on error path in dw2102_probe()
For me it's fine.
Reviewed-By: Enrico Mioso <mrkiko...@gmail.com>
On Thu, 10 Aug 2017, Anton Vasilyev wrote:
Date: Thu, 10 Aug 2017 17:27:44
From: Anton Vasilyev <vasil...@ispras.ru>
To: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: Anton Vasilyev <vasil...@ispras.ru>, Jonathan McDowell <nood...@earth.li>,
Alyssa Milburn <amilb...@zall.org>, Enrico Mioso <mrkiko...@gmail.com>,
linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
ldv-proj...@linuxtesting.org
Subject: [PATCH] dvb-usb: Add memory free on error path in dw2102_probe()
If dw2102_probe() fails on dvb_usb_device_init(), then memleak occurs.
The patch adds deallocation to the error path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev <vasil...@ispras.ru>
---
drivers/media/usb/dvb-usb/dw2102.c | 39 +-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 6e654e5..0d63693 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -2332,10 +2332,12 @@ static struct dvb_usb_device_properties
tt_s2_4600_properties = {
static int dw2102_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
+ int retval = -ENOMEM;
p1100 = kmemdup(_properties,
sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
if (!p1100)
- return -ENOMEM;
+ goto err0;
+
/* copy default structure */
/* fill only different fields */
p1100->firmware = P1100_FIRMWARE;
@@ -2346,10 +2348,9 @@ static int dw2102_probe(struct usb_interface *intf,
s660 = kmemdup(_properties,
sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
- if (!s660) {
- kfree(p1100);
- return -ENOMEM;
- }
+ if (!s660)
+ goto err1;
+
s660->firmware = S660_FIRMWARE;
s660->num_device_descs = 3;
s660->devices[0] = d660;
@@ -2359,11 +2360,9 @@ static int dw2102_probe(struct usb_interface *intf,
p7500 = kmemdup(_properties,
sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
- if (!p7500) {
- kfree(p1100);
- kfree(s660);
- return -ENOMEM;
- }
+ if (!p7500)
+ goto err2;
+
p7500->firmware = P7500_FIRMWARE;
p7500->devices[0] = d7500;
p7500->rc.core.rc_query = prof_rc_query;
@@ -2373,12 +2372,9 @@ static int dw2102_probe(struct usb_interface *intf,
s421 = kmemdup(_properties,
sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
- if (!s421) {
- kfree(p1100);
- kfree(s660);
- kfree(p7500);
- return -ENOMEM;
- }
+ if (!s421)
+ goto err3;
+
s421->num_device_descs = 2;
s421->devices[0] = d421;
s421->devices[1] = d632;
@@ -2408,7 +2404,16 @@ static int dw2102_probe(struct usb_interface *intf,
THIS_MODULE, NULL, adapter_nr))
return 0;
- return -ENODEV;
+ retval = -ENODEV;
+ kfree(s421);
+err3:
+ kfree(p7500);
+err2:
+ kfree(s660);
+err1:
+ kfree(p1100);
+err0:
+ return retval;
}
static void dw2102_disconnect(struct usb_interface *intf)
--
2.7.4
Re: dmesg flood + tuning problems on Asus My Cinema-U3000Hybrid
Sorry, one last note... I am not subscribed to the list, so please keep me in CC.
Re: [git:media_tree/master] [media] Add Cinergy S2 rev.4 support
Hello guys. First of all, thank you for your great work. I am writing to you to understand if there where problems with a patch I sent something like 17 octobrer to add an USB id. Where there any problems? I saw it was accepted but can't find it in the kernel. I admit I didn't check in media tree. Sorry for the disturbance. Thank you. -- 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: DVB: Unable to find symbol af9013_attach() (probably not a bug)
hello guys. At the end the problem seems related to the use of the CONFIG_TRIM_UNUSED_KSYMS option. Now everything works fine. Thanks, 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
DVB: Unable to find symbol af9013_attach() (probably not a bug)
Hello guys. I am facing the following error message when plugging in a nice USB stick: DVB: Unable to find symbol af9013_attach() I think this may be very very well a problem of my setup and kernel config: Linux version 4.9.0-rc5ho+ (mrkiko@gatosaldo) (gcc version 6.2.1 20160830 (GCC) ) #1 SMP Sun Nov 20 21:47:03 CET 2016 (GNU ld (GNU Binutils) 2.27). My kernel config follows. Thank you for all guys. # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.9.0-rc5 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_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_BITS_MAX=16 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 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_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEBUG_RODATA=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="ho" # CONFIG_LOCALVERSION_AUTO is not set 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=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(gato-saldo)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_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_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # 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_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_NMI_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y # CONFIG_MEMCG_SWAP_ENABLED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CGROUP_SCHED is not set CONFIG_CGROUP_PIDS=y # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_HUGETLB=y # CONFIG_CPUSETS is not set # CONFIG_CGROUP_DEVICE is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_DEBUG is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set
[PATCH] Add Cinergy S2 rev.4 support
This patch derives from previous one(s) by CrazyCat. I used the commit adding
rev.3 to mainline Linux kernel as an example, so credits go to its author(s).
The hardware seems to scan and tune OK.
Signed-off-by: Enrico Mioso <mrkiko...@gmail.com>
---
drivers/media/usb/dvb-usb/dw2102.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 5fb0c65..4bd1d13 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -1642,6 +1642,7 @@ enum dw2102_table_entry {
TEVII_S632,
TERRATEC_CINERGY_S2_R2,
TERRATEC_CINERGY_S2_R3,
+ TERRATEC_CINERGY_S2_R4,
GOTVIEW_SAT_HD,
GENIATECH_T220,
TECHNOTREND_S2_4600,
@@ -1671,6 +1672,7 @@ static struct usb_device_id dw2102_table[] = {
[TEVII_S632] = {USB_DEVICE(0x9022, USB_PID_TEVII_S632)},
[TERRATEC_CINERGY_S2_R2] = {USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_S2_R2)},
[TERRATEC_CINERGY_S2_R3] = {USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_S2_R3)},
+ [TERRATEC_CINERGY_S2_R4] = {USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_S2_R4)},
[GOTVIEW_SAT_HD] = {USB_DEVICE(0x1FE1, USB_PID_GOTVIEW_SAT_HD)},
[GENIATECH_T220] = {USB_DEVICE(0x1f4d, 0xD220)},
[TECHNOTREND_S2_4600] = {USB_DEVICE(USB_VID_TECHNOTREND,
--
2.10.0
--
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: [RFC] V4L2 codecs in user space
Am 08.06.2015 um 12:04 schrieb Hans Verkuil: big_snip / Just curious: as we're talking about userland libraries, why not just using gstreamer ? --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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 v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 19:54 schrieb Robert Schwebel: By the way: i still have some your older patches (2012) in my tree, eg. some mediabus, camara, display timing stuff, etc ... not sure whether I really need them for my device. Should I post them to linux-media list for review? No. That's all old stuff and has developed quite a lot since then. We'll post new series here on the lists when they are ready for mainline. Great :) Do you have them on some public repo, so I can give 'em a try ? --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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 v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 13:59 schrieb Philipp Zabel: Where can I get the recent ones ? Could you push it to your public repo ? I've updated the tmp/imx-ipu-scaler branch. Thx. already integrated it into my tree - works fine :) By the way: i still have some your older patches (2012) in my tree, eg. some mediabus, camara, display timing stuff, etc ... not sure whether I really need them for my device. Should I post them to linux-media list for review ? Oh, and I also still have your famous DRM_IOCTL_MODE_MAP_DUMB hack (the Reluctantly-signed-off-by: one ;-), meanwhile rebased / adapted into 4.x. Do you have any idea, what the amd-gpu driver/library exactly does with the retrieved address ? Send it directly to the gpu ? That should be capture-io-mode=dmabuf for the decoder and output-io-mode=dmabuf-import for the converter element. h264parse doesn't provide and fbdevsink can't handle dmabufs, so the decoder's output-io-mode and the converter's capture-io-mode should be kept as mmio. I played around a little bit - this command line only takes 55% cpu: gst-launch-1.0 filesrc location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec output-io-mode=4 capture-io-mode=4 \! v4l2 video0convert capture-io-mode=4 output-io-mode=5 \! fbdevsink By the way: what's the exact difference between dmabuf and dmabuf-import ? By the way: do you have any idea whether the proprietary driver (or the gpus itself) might talk to ipu and vpu ? Not that I am aware of. Well, you perhaps can imagine - I dont trust these guys ... --mtx ps: greetings from Bene ... you won't guess where I met him last weekend ;-) -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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 v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 27.05.2015 um 20:42 schrieb Jean-Michel Hautbois: snip @Phillip, I've missed the previous mails (just subscribed here yesterday) ... Are these patches same as in your git branch tmp/imx-ipu-scaler ? I've got them running on 4.0.4 and currently trying on 4.1-rc* Yet another question: when using it w/ gst for video playback, can be directly pass buffers between VPU, IPU and FB (or let them directly write into shared buffers), so CPU doesn't need to act on each frame for each step in the decoding pipeline ? Playing an 800x400 mp4 still produces about 70..75%. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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 v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 12:44 schrieb Philipp Zabel: Hi, Are these patches same as in your git branch tmp/imx-ipu-scaler ? No, that is an older version. Where can I get the recent ones ? Could you push it to your public repo ? when using it w/ gst for video playback, can be directly pass buffers between VPU, IPU and FB (or let them directly write into shared buffers), so CPU doesn't need to act on each frame for each step in the decoding pipeline ? Check out the (capture/output-)io-mode parameters, that's what the dmabuf/dmabuf-import option pairs are for. Tried dmabuf, but load stays at the same (77..80% CPU, 1.2 loadavg). dmabuf-import doesnt run at all: root@KoMo:/usr/share/videos/komo gst-launch-1.0 filesrc location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec output-io-mode=5 \! v4l2video0convert capture-io-mode=5 output-io-mode=4 \! fbdevsink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: No downstream pool to import from. Additional debug info: gstv4l2object.c(3441): gst_v4l2_object_decide_allocation (): /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: When importing DMABUF or USERPTR, we need a pool to import from ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Perhaps not implemented yet in the old version of the patches ? By the way: do you have any idea whether the proprietary driver (or the gpus itself) might talk to ipu and vpu ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: [RFC] Media controller entity information property API
Am 28.05.2015 um 11:27 schrieb Mauro Carvalho Chehab: Hi folks, just subscribed to the list, so I might have missed something snip Constructing unique names that are human readable, stable, unique and fit to 31 characters reserved for the purpose is not thought to be possible: device bus string that would be in some cases enough to uniquely identify a device any be longer than that. On hot-pluggable busses e.g. a serial number is needed. Dont we have any chance of lifting that restriction ? From a userland PoV, I'd really like to see them via path names (and actually access them directly via their own files) The structure of the properties tree can be non-trivial. This RFC defines a text representation format of the tree to facilitate discussing and documenting the tree structure separately from its binary representation used in IOCTL calls. The terms are used elsewhere in the document. Does it have to be an IOTCTL ? IOCTL have the unpleasant side effect, that they're hard to transport via network filesystems (in the end, would need special protocol extensions for each single one - assuming we can *safely* detect, which IOCTL really was called) Instead I'd prefer some pure filesystem-based approach - like @Plan9 or sysfs. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: imx53 IPU support on 4.0.4
Am 20.05.2015 um 15:21 schrieb Fabio Estevam: Hi, (Haven't 4.1rc* yet, as it broke some other things for me.) What are the regressions you see? Trouble w/ emmc/sd suddenly being ro. Guess, something in with the corresponding APIs changed and I didn't rebase correctly. It's now several weeks ago (IIRC, on rc1) - I'm currently rebasing everything again to the recent master. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: imx53 IPU support on 4.0.4
Am 20.05.2015 um 22:55 schrieb Russell King - ARM Linux: Hi, The way kernel development works is that patches are sent to mailing lists for review. Kernel developers review the patches and provide comments back. The comments are discussed and actioned, and a new set of patches posted for further review. This cycle repeats. Okay. I just wanted to prevent too much traffic. But I'll use git-send-email, if you prefer. When everyone is happy, the patches can be applied, or pulled from a non-github git tree. (Kernel people generally don't like github.) Why so ? This is so that upstream kernel developers don't get too overloaded with work that really should be done by downstream folk (imagine if they had to rewrite every patch that came their way...) Of course. I wasn't aware of the separate linux-media maillist at that time. By the way: I've now moved to Phillip's recent ipuv3 patches, but still have lots of others (about 30) for my tqma53-based board, which might be generic enough for going into mainline someday (many of them by ptx folks). Should I post them to lkml or somewhere else ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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
imx53 IPU support on 4.0.4
Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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: [RFC] How implement Secure Data Path ?
Am 08.05.2015 um 10:37 schrieb Daniel Vetter: dma-buf user handles are fds, which means anything allocated can be passed around nicely already. The question really is whether we'll have one ioctl on top of a special dev node or a syscall. I thought that in these cases where the dev node is only ever used to allocate the real thing, a syscall is the preferred way to go. I'd generally prefer a /dev node instead of syscall, as they can be dynamically allocated (loaded as module, etc), which in turn offers more finer control (eg. for containers, etc). One could easily replace the it with its own implementation (w/o patching the kernel directly and reboot it). Actually, I'm a bit unhappy with the syscall inflation, in fact I'm not even a big friend of ioctl's - I'd really prefer the Plan9 way :p I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. We have handles (well file descriptors) to dma-bufs already, I'm a bit confused what you mean? Just curious (as I'm pretty new to this area): how to GEM objects and dma-bufs relate to each other ? Is it possible to directly exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- 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
[PATCH v2] [media] mt9p031: fixed calculation of clk_div
There must be used 'min_t', not 'max_t' for calculating the divider. Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/i2c/mt9p031.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c index 0cabf91..43ee299 100644 --- a/drivers/media/i2c/mt9p031.c +++ b/drivers/media/i2c/mt9p031.c @@ -254,7 +254,7 @@ static int mt9p031_clk_setup(struct mt9p031 *mt9p031) div = DIV_ROUND_UP(ext_freq, pdata-target_freq); div = roundup_pow_of_two(div) / 2; - mt9p031-clk_div = max_t(unsigned int, div, 64); + mt9p031-clk_div = min_t(unsigned int, div, 64); mt9p031-use_pll = false; return 0; -- 2.1.0 -- 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] mt9p031: fixed calculation of clk_div
Laurent Pinchart laurent.pinch...@ideasonboard.com writes: and the upper limit is '63' (value uses 6:0 register bits). And this I don't. You can encode numbers from 0 to 127 on 7 bits. yes; you are right (original '64' was correct because sensor allows only dividers of a power-of-two). -mt9p031-clk_div = max_t(unsigned int, div, 64); +mt9p031-clk_div = min_t(unsigned int, div, 63); 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
[PATCH] [media] mt9p031: fixed calculation of clk_div
There must be used 'min_t', not 'max_t' for calculating the divider and the upper limit is '63' (value uses 6:0 register bits). Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/i2c/mt9p031.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c index 0cabf91..43ee299 100644 --- a/drivers/media/i2c/mt9p031.c +++ b/drivers/media/i2c/mt9p031.c @@ -254,7 +254,7 @@ static int mt9p031_clk_setup(struct mt9p031 *mt9p031) div = DIV_ROUND_UP(ext_freq, pdata-target_freq); div = roundup_pow_of_two(div) / 2; - mt9p031-clk_div = max_t(unsigned int, div, 64); + mt9p031-clk_div = min_t(unsigned int, div, 63); mt9p031-use_pll = false; return 0; -- 2.1.0 -- 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 0/8] OMAP3 ISP CCDC fixes
On Fri, Aug 1, 2014 at 3:46 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hello, This patch series fixes several stability issues related to the CCDC, especially (but not exclusively) in BT.656 mode. The patches apply on top of the OMAP3 ISP CCDC BT.656 mode support series previously posted. You can find both series at git://linuxtv.org/pinchartl/media.git omap3isp/bt656 I'm not sure to be completely happy with the last three patches. The CCDC state machine is getting too complex for my tastes, race conditions becoming too hard to spot. This doesn't mean the code is wrong, but a rewrite of the state machine will probably needed sooner than later. I tested this patch series on an igep proton (omap3530) with tvp5150, kernel 3.16, bt656 mode. All issues i had with the first series are fixed, so: Tested-by: Enrico Butera ebut...@users.sourceforge.net -- 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
On Wed, Jul 30, 2014 at 11:01 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: 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). No, i missed those patches i was using only the omap3isp patches you posted here. With those patches and configuring the pipleline as you suggested i could finally capture some good frames with yavta. But i think there is some race, because it's not very reliable. This is what i see: (with yavta -c50 -f UYVY -s 720x576 --field interlaced-tb /dev/video2) 1) first run, ok 2) if i re-run it soon after it finishes, it just hangs on start (in VIDIOC_DQBUF). I have to stop it with ctrl+c and after some seconds it exits, and the kernel prints the ccdc stop timeout message. in any case when it doesn't hang i can capture 200 frames with no errors. And if i wait some seconds before running it again it usually works (not always). 3) if i add -F to yavta (saving to a tmpfs in ram), it hangs after capturing some frames (usually between 20 and 30). yet again, same ctrl+c thing (it exits, ccdc stop timeout...). Apart from these issues your patches are much better then the old ones! Any hints on what i can try to fix these issues? Thanks, 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: omap3isp with DM3730 not working?!
On Thu, Jul 31, 2014 at 12:06 PM, Michael Dietschi michael.diets...@inunum.com wrote: Am 30.07.2014 17:21, schrieb Enrico: 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 No, not exactly. I used older versions which came with Yocto Poky Daisy. But I also tried with these newer ones and get the same: 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]' root@overo:~$ ./media-ctl -v -f 'tvp5150 3-005c:0 [UYVY2X8 720x576], OMAP3 ISP CCDC:1 [UYVY2X8 720x576]' root@overo:~$ ./yavta -f UYVY -s 720x576 --capture=1 --file=image.raw /dev/video2 I think you are missing the ccdc sink pad setup, basically you should have something like this: - 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/720x288 field:alternate] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [fmt:UYVY/720x576 field:interlaced-tb crop.bounds:(0,0)/720x288 crop:(0,0)/720x288] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] with this setup i can correctly capture deinterlaced frames with yavta, but have a look at the [PATCH 00/11] OMAP3 ISP BT.656 support thread, i noticed some problems maybe it's the same for you. 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: omap3isp with DM3730 not working?!
On Thu, Jul 31, 2014 at 2:31 PM, Michael Dietschi michael.diets...@inunum.com wrote: Am 31.07.2014 12:36, schrieb Enrico: I think you are missing the ccdc sink pad setup, basically you should have something like this: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad1: Source [fmt:UYVY/720x576 field:interlaced-tb crop.bounds:(0,0)/720x288 crop:(0,0)/720x288] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad1: Source [fmt:UYVY/720x240 field:alternate crop.bounds:(0,0)/720x240 crop:(0,0)/720x240] It seems you are missing this: media-ctl --set-format 'OMAP3 ISP CCDC:1 [UYVY 720x480 field:interlaced-tb]' and add --field interlaced-tb to yavta. 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: omap3isp with DM3730 not working?!
On Wed, Jul 30, 2014 at 4:56 PM, Michael Dietschi michael.diets...@inunum.com 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: omap3isp with DM3730 not working?!
On Mon, Jul 28, 2014 at 9:20 AM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Enrico and Michael, On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi michael.diets...@inunum.com wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Hi Sakari, that's true in normal mode, but with bt656 patches VD1 is not used. 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: omap3isp with DM3730 not working?!
On Mon, Jul 28, 2014 at 12:29 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Monday 28 July 2014 10:30:17 Enrico wrote: On Mon, Jul 28, 2014 at 9:20 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Hi Sakari, that's true in normal mode, but with bt656 patches VD1 is not used. That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt. ...in your new patches. But sleepyrobot's are the old ones and i bet Michael is using those patches. 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: omap3isp with DM3730 not working?!
On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi michael.diets...@inunum.com wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Anyway maybe a different pinmux where the camera pins are not setup correctly? 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 00/11] OMAP3 ISP BT.656 support
On Tue, Jul 22, 2014 at 6:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Tuesday 22 July 2014 18:26:52 Enrico wrote: On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart wrote: Hi Enrico, You will need to upgrade media-ctl and yavta to versions that support interlaced formats. media-ctl has been moved to v4l-utils (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at git://git.ideasonboard.org/yavta.git. You want to use the master branch for both trees. It seems that in v4l-utils there is no field support in media-ctl, am i wrong? Oops, my bad, you're absolutely right. I forgot to add that i'm using yavta master and media-ctl field branch (from ideasonboard). Could you please try media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field The IOB repository is deprecated, although the version of media-ctl present there might work, I'd like to rule out that issue. The media-ctl output you've posted doesn't show field information, so you're probably running either the wrong media-ctl version or the wrong kernel version. 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] 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. And ccdc pad1: Source (entity 5) is strange, i think it should be field:none (because ccdc output is deinterlaced). 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 00/11] OMAP3 ISP BT.656 support
On Wed, Jul 23, 2014 at 3:54 PM, Enrico ebut...@users.sourceforge.net wrote: On Tue, Jul 22, 2014 at 6:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Tuesday 22 July 2014 18:26:52 Enrico wrote: On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart wrote: Hi Enrico, You will need to upgrade media-ctl and yavta to versions that support interlaced formats. media-ctl has been moved to v4l-utils (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at git://git.ideasonboard.org/yavta.git. You want to use the master branch for both trees. It seems that in v4l-utils there is no field support in media-ctl, am i wrong? Oops, my bad, you're absolutely right. I forgot to add that i'm using yavta master and media-ctl field branch (from ideasonboard). Could you please try media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field The IOB repository is deprecated, although the version of media-ctl present there might work, I'd like to rule out that issue. The media-ctl output you've posted doesn't show field information, so you're probably running either the wrong media-ctl version or the wrong kernel version. 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] 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 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 00/11] OMAP3 ISP BT.656 support
On Tue, Jun 24, 2014 at 5:19 PM, Enrico ebut...@users.berlios.de wrote: On Tue, May 27, 2014 at 10:38 AM, Enrico ebut...@users.berlios.de wrote: On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hello, This patch sets implements support for BT.656 and interlaced formats in the OMAP3 ISP driver. Better late than never I suppose, although given how long this has been on my to-do list there's probably no valid excuse. Thanks Laurent! I hope to have time soon to test it :) Hi Laurent, i wanted to try your patches but i'm having a problem (probably not caused by your patches). I merged media_tree master and omap3isp branches, applied your patches and added camera platform data in pdata-quirks, but when loading the omap3-isp driver i have: omap3isp: clk_set_rate for cam_mclk failed The returned value from clk_set_rate is -22 (EINVAL), but i can't see any other debug message to track it down. Any ides? I'm testing it on an igep proton (omap3530 version). I found out that my previous email was not working anymore, so i didn't read about Stefan patch (ti,set-rate-parent). With that patch i can setup my pipeline (attached), but i can't make yavta capture: 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 0xb6ce4000. length: 898560 offset: 901120 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xb6c08000. length: 898560 offset: 1802240 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xb6b2c000. length: 898560 offset: 2703360 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xb6a5. Unable to start streaming: Invalid argument (22). 4 buffers released. strace: ioctl(3, VIDIOC_STREAMON, 0xbef9c75c) = -1 EINVAL (Invalid argument) any ideas? Thanks, Enrico Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x20 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] - OMAP3 ISP CCP2 input:0 [] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CCDC:0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source - OMAP3 ISP CCP2:0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CSI2a output:0 [] - OMAP3 ISP CCDC:0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - OMAP3 ISP CSI2a:1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [UYVY 720x624 (0,0)/720x624] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [unknown 720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink - OMAP3 ISP CCDC:1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] - OMAP3 ISP CCDC:2 [] - OMAP3 ISP preview input:0 [] pad1: Source [YUYV 4082x4088] - OMAP3 ISP preview output:0 [] - OMAP3 ISP resizer:0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source - OMAP3 ISP preview:0 [] - entity 9: OMAP3
Re: [PATCH 00/11] OMAP3 ISP BT.656 support
On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, You will need to upgrade media-ctl and yavta to versions that support interlaced formats. media-ctl has been moved to v4l-utils (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at git://git.ideasonboard.org/yavta.git. You want to use the master branch for both trees. It seems that in v4l-utils there is no field support in media-ctl, am i wrong? I forgot to add that i'm using yavta master and media-ctl field branch (from ideasonboard). 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 00/11] OMAP3 ISP BT.656 support
On Tue, Jun 24, 2014 at 5:19 PM, Enrico ebut...@users.berlios.de wrote: On Tue, May 27, 2014 at 10:38 AM, Enrico ebut...@users.berlios.de wrote: On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hello, This patch sets implements support for BT.656 and interlaced formats in the OMAP3 ISP driver. Better late than never I suppose, although given how long this has been on my to-do list there's probably no valid excuse. Thanks Laurent! I hope to have time soon to test it :) Hi Laurent, i wanted to try your patches but i'm having a problem (probably not caused by your patches). I merged media_tree master and omap3isp branches, applied your patches and added camera platform data in pdata-quirks, but when loading the omap3-isp driver i have: omap3isp: clk_set_rate for cam_mclk failed The returned value from clk_set_rate is -22 (EINVAL), but i can't see any other debug message to track it down. Any ides? I'm testing it on an igep proton (omap3530 version). Trying it on an igep com module (dm3730) i don't get the clk_set_rate error (but there is no tvp hardware connected so i can't go farther). So it must be something different between omap3430/omap3630 clocks, i tried to use (CM_CAM_MCLK_HZ / 2) with the omap3530 one but i get the same error. I don't know what else i can try. 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 00/11] OMAP3 ISP BT.656 support
On Tue, May 27, 2014 at 10:38 AM, Enrico ebut...@users.berlios.de wrote: On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hello, This patch sets implements support for BT.656 and interlaced formats in the OMAP3 ISP driver. Better late than never I suppose, although given how long this has been on my to-do list there's probably no valid excuse. Thanks Laurent! I hope to have time soon to test it :) Hi Laurent, i wanted to try your patches but i'm having a problem (probably not caused by your patches). I merged media_tree master and omap3isp branches, applied your patches and added camera platform data in pdata-quirks, but when loading the omap3-isp driver i have: omap3isp: clk_set_rate for cam_mclk failed The returned value from clk_set_rate is -22 (EINVAL), but i can't see any other debug message to track it down. Any ides? I'm testing it on an igep proton (omap3530 version). Thanks, 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 00/11] OMAP3 ISP BT.656 support
On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hello, This patch sets implements support for BT.656 and interlaced formats in the OMAP3 ISP driver. Better late than never I suppose, although given how long this has been on my to-do list there's probably no valid excuse. Thanks Laurent! I hope to have time soon to test it :) 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: [ANNOUNCE] git web interface was changed to cgit
On Thu, Apr 3, 2014 at 12:26 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: Hi all, I changed today our git web interface from gitweb to cgit, due to seveal reasons: ... Please ping me if you fin any problems on it. http://git.linuxtv.org/cgit.cgi/media_build.git/tree/README the first time i opened that link i got an internal server error, then it shows an empty file (many lines, all empty). It seems to happen for every file, even in other repos: http://git.linuxtv.org/cgit.cgi/linux.git/tree/README 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: omap3isp device tree support
On Fri, Jan 10, 2014 at 10:02 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 09/01/2014 19:14, Enrico a écrit : On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD julien.ber...@parrot.com wrote: Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. There is only one problem, but it's unrelated to your DT work. It's an old problem (see for example [1] and [2]), seen by other people too and it seems it's still there. Basically if i capture with yavta while the system is idle then it just waits without getting any frame. If i add some cpu load (usually i do a cat /dev/zero in a ssh terminal) it starts capturing correctly. The strange thing is that i do get isp interrupts in the idle case, so i don't know why they don't propagate to yavta. Any hints on how to debug this? Enrico [1]: https://linuxtv.org/patch/7836/ [2]: a https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html I have had what looked a lot like these problems before and it was due to a wrong configuration of the ccdc cropping regarding to the blanking. Could you send me the configuration of the pipeline that you apply with media-ctl, just in case this is the same problem. i'm using: media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl --set-format 'tvp5150 2-005c:0 [UYVY 720x625]' And then capture with yavta -s 720x625 (or 720x576, can't remember right now). Thanks, Enrico I don't think this is sufficient, though I am no expert about omap3 isp, you should configure the format of the ccdc input and of the ccdc output too. When I had this problem, it was solved by adding cropping at the input of the CCDC, corresponding to the blanking period, which was : - media-ctl -v -f 'OMAP3 ISP CCDC:0 [UYVY2X8 720x576 (0,49/720x576)]' or - media-ctl -v -f 'OMAP3 ISP CCDC:0 [UYVY2X8 720x480 (0,45/720x480)]' respectively. I don't know if this can be of any help. Regards, Julien BERAUD It seems i can't set cropping at the CCDC input (sink), but i can on output (source): - 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] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [fmt:UYVY2X8/720x576 crop.bounds:(0,0)/720x624 crop:(0,48)/720x576] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [fmt:unknown/720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] The strange thing is that with these settings the situation is even worse, i don't get any frames in yavta (while i see interrupts on omap3isp) even with the cat /dev/zero trick. So you are right, playing with cropping can make it work or not, are you sure you could set cropping at the ccdc input? Enrico Enrico, Sorry it didn't work. I just wanted to give a hint of what could be going wrong. I am sorry I don't have time to investigate, I am sure I could set the cropping at the input of ccdc, and that the result was to write register ISPCCDC_VERT_START in order to skip the vertical blanking period correctly. The branch I was on was a bit different though. If you want to investigate this issue, you will at least need to see what is written in the registers of the ISP. Regards, Julien I think i nailed down
Re: omap3isp device tree support
On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD julien.ber...@parrot.com wrote: Le 07/01/2014 11:12, Enrico a écrit : On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. There is only one problem, but it's unrelated to your DT work. It's an old problem (see for example [1] and [2]), seen by other people too and it seems it's still there. Basically if i capture with yavta while the system is idle then it just waits without getting any frame. If i add some cpu load (usually i do a cat /dev/zero in a ssh terminal) it starts capturing correctly. The strange thing is that i do get isp interrupts in the idle case, so i don't know why they don't propagate to yavta. Any hints on how to debug this? Enrico [1]: https://linuxtv.org/patch/7836/ [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html I have had what looked a lot like these problems before and it was due to a wrong configuration of the ccdc cropping regarding to the blanking. Could you send me the configuration of the pipeline that you apply with media-ctl, just in case this is the same problem. i'm using: media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl --set-format 'tvp5150 2-005c:0 [UYVY 720x625]' And then capture with yavta -s 720x625 (or 720x576, can't remember right now). Thanks, Enrico I don't think this is sufficient, though I am no expert about omap3 isp, you should configure the format of the ccdc input and of the ccdc output too. When I had this problem, it was solved by adding cropping at the input of the CCDC, corresponding to the blanking period, which was : - media-ctl -v -f 'OMAP3 ISP CCDC:0 [UYVY2X8 720x576 (0,49/720x576)]' or - media-ctl -v -f 'OMAP3 ISP CCDC:0 [UYVY2X8 720x480 (0,45/720x480)]' respectively. I don't know if this can be of any help. Regards, Julien BERAUD It seems i can't set cropping at the CCDC input (sink), but i can on output (source): - 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] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 1-005c:0 [ENABLED] pad1: Source [fmt:UYVY2X8/720x576 crop.bounds:(0,0)/720x624 crop:(0,48)/720x576] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [fmt:unknown/720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] The strange thing is that with these settings the situation is even worse, i don't get any frames in yavta (while i see interrupts on omap3isp) even with the cat /dev/zero trick. So you are right, playing with cropping can make it work or not, are you sure you could set cropping at the ccdc input? 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: omap3isp device tree support
On Tue, Jan 7, 2014 at 5:59 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Friday 03 January 2014 12:30:33 Enrico wrote: On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard wrote: So I converted the iommu to DT (patches just sent), Florian, I've used your patches as a base for OMAP3 ISP DT work and they seem pretty good (although patch 1/7 will need to be reworked, but that's not a blocker). I've just had to fix a problem with the OMAP3 IOMMU, please see http://git.linuxtv.org/pinchartl/media.git/commit/d3abafde0277f168df0b2912b5d84550590d80b2 I'd appreciate your comments on that. I can post the patch already if you think that would be helpful. You can find my work-in-progress branch at http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp/dt (the last three patches are definitely not complete yet). used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. The second patch is not clean enough in my opinion. I need to find time to work on it. I had set some time aside for OMAP3 ISP development last week but I've ended up working on DT support (not done yet, I've worked with Sakari and he might finish the job in the upcoming weeks) instead of BT.656. I'm afraid this will have to wait for around three weeks. Yes i know the history of those patches, and if i'm not wrong you didn't have the hardware to test them so i just wanted to confirm that they work (apart from the other problem). 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: omap3isp device tree support
On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD julien.ber...@parrot.com wrote: Le 03/01/2014 12:30, Enrico a écrit : On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. There is only one problem, but it's unrelated to your DT work. It's an old problem (see for example [1] and [2]), seen by other people too and it seems it's still there. Basically if i capture with yavta while the system is idle then it just waits without getting any frame. If i add some cpu load (usually i do a cat /dev/zero in a ssh terminal) it starts capturing correctly. The strange thing is that i do get isp interrupts in the idle case, so i don't know why they don't propagate to yavta. Any hints on how to debug this? Enrico [1]: https://linuxtv.org/patch/7836/ [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html I have had what looked a lot like these problems before and it was due to a wrong configuration of the ccdc cropping regarding to the blanking. Could you send me the configuration of the pipeline that you apply with media-ctl, just in case this is the same problem. i'm using: media-ctl -r -l 'tvp5150 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl --set-format 'tvp5150 2-005c:0 [UYVY 720x625]' And then capture with yavta -s 720x625 (or 720x576, can't remember right now). Thanks, 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: omap3isp device tree support
On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. And here i am. I can confirm it works, video source is tvp5150 (with platform data in pdata-quirks.c) in bt656 mode. Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so if you want to push it you can add a Tested-by me. There is only one problem, but it's unrelated to your DT work. It's an old problem (see for example [1] and [2]), seen by other people too and it seems it's still there. Basically if i capture with yavta while the system is idle then it just waits without getting any frame. If i add some cpu load (usually i do a cat /dev/zero in a ssh terminal) it starts capturing correctly. The strange thing is that i do get isp interrupts in the idle case, so i don't know why they don't propagate to yavta. Any hints on how to debug this? Enrico [1]: https://linuxtv.org/patch/7836/ [2]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.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
Re: omap3isp device tree support
On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe: [1.575225] console [ttyO2] enabled [1.581268] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb042050 [1.589324] Internal error: : 1028 [#1] ARM [1.593719] Modules linked in: [1.596954] CPU: 0 PID: 1 Comm: swapper Tainted: GW3.13.0-rc3+ #2 [1.604461] task: de87 ti: de86c000 task.ti: de86c000 [1.610137] PC is at serial_omap_probe+0x3a8/0x644 [1.615203] LR is at trace_hardirqs_on_caller+0x104/0x1dc [1.620849] pc : [c028c0a4]lr : [c006411c]psr: 2153 [1.620849] sp : de86de30 ip : c06f8784 fp : [1.632934] r10: r9 : dea931ad r8 : c0b7e144 [1.638397] r7 : dea75c50 r6 : de8e4c00 r5 : de8e4c10 r4 : dea93010 [1.645263] r3 : fb042000 r2 : fb042050 r1 : 0014 r0 : [1.652130] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [1.659912] Control: 10c5387d Table: 80004019 DAC: 0015 [1.665924] Process swapper (pid: 1, stack limit = 0xde86c240) [1.672058] Stack: (0xde86de30 to 0xde86e000) [1.676635] de20: c053bd40 dea931ad [1.685241] de40: de8e4c10 de8e4c10 c0636340 c0636340 006e [1.693847] de60: de86c030 c029414c c0294134 c0b7e618 de8e4c10 c0292c98 de8e4c10 c0636340 [1.702453] de80: de8e4c44 c05eb8ac c0292e90 c0636340 c0292dfc c02912a8 [1.711029] dea0: de803aa8 de8c8050 c0636340 de9e4900 c0636ec0 c029246c c0559bec c0636340 [1.719635] dec0: 0006 c0636340 0006 c064e500 c064e500 c0293254 c05fddf8 [1.728240] dee0: 0006 c05eb8cc c05fddf8 c00087e4 de87 c0620438 6153 c0068fcc [1.736816] df00: c064e500 1480 c0620434 c05f72e0 c05f72b8 c0439170 0002 de86c000 [1.745422] df20: c0f9e9f5 c04568d4 006e c004be2c c05ab990 0006 c0f9ea08 0006 [1.754028] df40: 6153 c05fddf8 0006 c064e500 c064e500 c05d1480 006e c05f72e0 [1.762634] df60: c05f72d4 c05d1c68 0006 0006 c05d1480 c00550a0 052d1144 [1.771209] df80: 08010820 c04310f4 [1.779815] dfa0: c04310fc c000e048 [1.788421] dfc0: [1.796997] dfe0: 0013 41001412 44300082 [1.805633] [c028c0a4] (serial_omap_probe+0x3a8/0x644) from [c029414c] (platform_drv_probe+0x18/0x48) [1.815673] [c029414c] (platform_drv_probe+0x18/0x48) from [c0292c98] (driver_probe_device+0x114/0x234) [1.825927] [c0292c98] (driver_probe_device+0x114/0x234) from [c0292e90] (__driver_attach+0x94/0x98) [1.835906] [c0292e90] (__driver_attach+0x94/0x98) from [c02912a8] (bus_for_each_dev+0x60/0x94) [1.845428] [c02912a8] (bus_for_each_dev+0x60/0x94) from [c029246c] (bus_add_driver+0x148/0x1f0) [1.855010] [c029246c] (bus_add_driver+0x148/0x1f0) from [c0293254] (driver_register+0x78/0xf8) [1.864532] [c0293254] (driver_register+0x78/0xf8) from [c05eb8cc] (serial_omap_init+0x20/0x44) [1.874053] [c05eb8cc] (serial_omap_init+0x20/0x44) from [c00087e4] (do_one_initcall+0x100/0x150) [1.883758] [c00087e4] (do_one_initcall+0x100/0x150) from [c05d1c68] (kernel_init_freeable+0x1fc/0x29c) [1.894012] [c05d1c68] (kernel_init_freeable+0x1fc/0x29c) from [c04310fc] (kernel_init+0x8/0x120) [1.903717] [c04310fc] (kernel_init+0x8/0x120) from [c000e048] (ret_from_fork+0x14/0x2c) [1.912567] Code: e5d42051 e5943024 e3a01014 e0832211 (e5923000) is it a known bug? something i should check in my config/dts? 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: omap3isp device tree support
On Mon, Dec 23, 2013 at 6:45 PM, Enrico ebut...@users.berlios.de wrote: On Wed, Dec 18, 2013 at 11:09 AM, Enrico ebut...@users.berlios.de wrote: On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. Uhm it's unrelated to omap3isp but i get a kernel panic in serial_omap_probe: Sorry for the noise, it was a stupid problem with DT. 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: omap3isp device tree support
On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt Thanks Florian, i will report what i get with my setup. 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
omap3isp device tree support
Hi, i know there is some work going on for omap3isp device tree support, but right now is it possible to enable it in some other way in a DT kernel? I've tried enabling it in board-generic.c (omap3_init_camera(...) with proper platform data) but it hangs early at boot, do someone know if it's possible and how to do it? Thanks, 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: omap3isp device tree support
On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard florian.vauss...@epfl.ch wrote: Hello, On 12/06/2013 11:13 AM, Enrico wrote: Hi, i know there is some work going on for omap3isp device tree support, but right now is it possible to enable it in some other way in a DT kernel? The DT support is not yet ready, but an RFC binding has been proposed. It won't be ready for 3.14. I've tried enabling it in board-generic.c (omap3_init_camera(...) with proper platform data) but it hangs early at boot, do someone know if it's possible and how to do it? I did the same a few days ago, and went through several problems (panics, half DT support,...). Now I am able to probe the ISP, I still have one kernel panic to fix. Hope to send the patches in 1 or 2 days. We are still in a transition period, but things should calm down in the coming releases. Cheers, Florian [1] http://www.spinics.net/lists/linux-media/msg69424.html Thanks Florian, i will gladly help in testing. 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: media-ctl: line 1: syntax error: ( unexpected
On Fri, Aug 23, 2013 at 3:08 PM, Tom bassai_...@gmx.net wrote: Tom Bassai_Dai at gmx.net writes: Hello, I got the media-ctl tool from http://git.ideasonboard.org/git/media-ctl.git and compiled and build it successfully. But when try to run it I get this error: sudo ./media-ctl -r -l ov3640 3-003c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1] ./media-ctl: line 1: syntax error: ( unexpected Does anyone know how I can solve that problem? Looks like you are trying to execute a wrapper script instead of the real binary, it's in src/.libs 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: OMAP3 ISP DQBUF hangs
On Mon, Aug 19, 2013 at 4:53 PM, Tom bassai_...@gmx.net wrote: you are right. it seems that the list of the ccdc has no buffer left, because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in my log. But I don't understand what I need to do to solve the problem. What I do is: - configure the pipeline - open the video device - do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type = V4L2_BUF_TYPE_VIDEO_CAPTURE) - do ioctl VIDIOC_QUERYBUF - do ioctl VIDIOC_STREAMON - do ioctl VIDIOC_QBUF without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem. Does anyone have an idea what I need to do to solve this problem? Even if you are sure your application works, try with media-ctl + yavta first so you can send logs that everybody understand. Did you check you have interrupts during capture? (cat /proc/interrupts before and after yavta, look for omap3isp or something like that). 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: homebrew versatile set top box
On Sun, Jun 24, 2012 at 10:27 PM, Sebastiano Fabio Genovese syna...@videobank.it wrote: For the electronic part I am able to complete the project in its entirety, for software I would have some difficulty, as I should be studying very hard for months because I have no experience in developing kernel driver, especially the difficulty of v4l. I thank all those who can help me or give me a simple piece of advice, My advice: choose hardware that already has good kernel and userspace (if needed) support, even if it's not the best hardware solution. Then you will only have to put together various pieces of software to get what you want. When you have a working prototype then you can think about switching to the best hardware, develop kernel drivers... Ciao, 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: FW: OMAP 3 ISP
On Tue, May 29, 2012 at 10:15 AM, jean-philippe francois jp.franc...@cynove.com wrote: 2012/5/29 Alex Gershgorin al...@meprolight.com: Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org Hi Alex, I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board. Device is booting correctly but probe function in omap3isp module not getting called. Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex Hi, I had a similar problem with a 2.6.39 kernel, that was solved with a 3.2 kernel. When compiled as a module, the probe function was called, but was failing later. The single message I would see was ISP revision x.y found [1] When compiled in the kernel image, everything was fine. [1] http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2103 I think with kernel version 3.0 i had the same problem, i had to modprobe iommu2 before omap3isp, removing (if already loaded) iommu. Probably later on it was fixed and you don't need that anymore. Laurent will know better. 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: Status of gstreamer video capture/encoding
On Wed, May 16, 2012 at 2:26 AM, Simon Knopp simon.kn...@pg.canterbury.ac.nz wrote: Hi all, I am trying to understand the current state of video capture and encoding using gstreamer for kernels = 2.6.39 on an OMAP3530. Currently on 2.6.34 (omap3-2.6.34-caspapx) I use essentially: v4l2src ! TIVidenc1 codecName=h264enc ! rtph264pay ! udpsink 1) As far as I understand, 'yavta' is currently the only way to capture from media-ctl-based cameras -- gstreamer's v4l2src doesn't work for these cameras. Is this correct? 2) I have read that 'subdevsrc' or 'mcsrc' is capable of doing this [1], though I'm not sure whether they're somehow meego-specific. Has anyone tried these source elements on a Gumstix Overo? I don't know the current situation, but up to some months ago v4l2src was not working with media-ctl-based cameras. Never tried subdevsrc or mcsrc. 3) As far as using the DSP for encoding video, Last I heard no one had done it yet [2]. Has anyone had success with either 'gst-ti', 'gst-dsp', or 'gst-openmax' [3,4,5] on 3.x kernels? Yes it works, i use gst-ti for video encoding with kernel 3.2 (omap3530+tvp5150). 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: OMAP3ISP won't start
On Mon, Apr 2, 2012 at 2:24 PM, Gary Thomas g...@mlbassoc.com wrote: Just to be clear - I did have to make a few patches to both the TVP5150 driver and CCDC part of OMAP3ISP as some of the BT656 support is still not in Laurent's tree. I'll send patches, etc, once I get it working, but as mentioned above, at least at the register level, these are set up the same as in my working tree. What patches did you add on top of Laurent tree? I had a look some days ago and for example it's missing the right setup for VD0/VD1 (no VD1 and VD0 set to half height), this could be the cause of a not working isp. You can check if you get interrupts from the isp (/proc/interrupts). Another thing that is missing is the logic in the irq handler that wait for a complete frame before calling next video buffer (or something like that). 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: OMAP3ISP won't start
On Mon, Apr 2, 2012 at 3:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-04-02 07:15, Enrico wrote: On Mon, Apr 2, 2012 at 2:45 PM, Gary Thomasg...@mlbassoc.com wrote: The items you mention are just what I merged from my previous kernel. My changes are still pretty rough but I can send them to you if you'd like. Post them here and we will try to spot where the problem is, they could be useful for Laurent too as a reference. Attached. I just had a quick look and it seems everything is there, i can't test it right now but when i did test a mainline 3.3 kernel with my patches i had to use the nohlt kernel parm. If i'm not wrong without that param i had the same error, you can give it a try. 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: OMAP3ISP won't start
On Mon, Apr 2, 2012 at 4:55 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-04-02 08:38, Enrico wrote: Attached. I just had a quick look and it seems everything is there, i can't test it right now but when i did test a mainline 3.3 kernel with my patches i had to use the nohlt kernel parm. If i'm not wrong without that param i had the same error, you can give it a try. Hurray, that does work. Laurent, this is an old problem that i noticed some time ago [1] but apparently things are getting worse. The situation now is: kernel 3.2 without cpu_idle: no need for nohlt kernel 3.2 with cpu_idle: nohlt is needed kernel 3.3 with/without cpu_idle: nohlt always needed I really don't know where the problem comes from, but i verified that the cam powerdomain is correctly acquired during capture, i don't know what else i can check. [1]: http://www.digipedia.pl/usenet/thread/18550/20510/ 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: [off-topic] Linux-media e-mail problems
Hi, FYI: I suddenly stopped receiving e-mails from this list last week, March 16th. Does anyone have an explanation for that? Same here, i had to subscribe again. 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] Adding YUV input support for OMAP3ISP driver
On Sat, Feb 4, 2012 at 4:26 PM, Enrico ebut...@users.berlios.de wrote: On Sat, Feb 4, 2012 at 12:48 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-01-30 10:30, Gary Thomas wrote: On 2012-01-20 05:19, Laurent Pinchart wrote: Hi Enrico, On Thursday 19 January 2012 15:17:57 Enrico wrote: On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-01-19 06:35, Gary Thomas wrote: My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0] .i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. rant Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). /rant I totally understand your feeling. I'd like to get YUV support integrated in the OMAP3 ISP driver. However, I have no YUV image source hardware, so I can only review the patches but not test them. If someone can rebase the existing patches on top of http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-yuv and test them, then I'll review the result. The attached patches produce a working setup against Laurent's tree above. That said, I don't recall exactly where which changes came from (I'm old school and not very git savvy, sorry). I've CC'd all the folks I think provided at least part of these changes. Perhaps we can all work together to come up with a proper set of patches which can be pushed upstream for this, once and for all? Thanks Ping! Is no one but me interested in getting these changes into the mainline? I am interested, i didn't have time to test it but i will for sure. And i think it's important to test non bt656/yuv sensors too, but i have no hardware for that. Enrico I had some time to test your patches, i can confirm they work in my setup too but i have some doubts. 1- in the tvp5150 driver there is a hardcoded pal height (active area) of 576px, while it's true that it's the max pal area you will get i think it's wrong to force it in the driver because you will loose some image area (see [1] and [2]). It is better to return the max frame size and let the application crop it. And if i'm not wrong i think Javier posted a patch to add crop support in tvp5150 driver and that's even better. 2- as you can see from [1] and [2] image quality is very different, but i think it's just that in [1] top/bottom fields are swapped. For the above reasons and if there is a general consensus i propose to Laurent to just have a look at the patches i made some time ago (and i use everyday) from [3] and [4]. They are against mainline kernel but can be ported to whatever branch, once and for all. Enrico [1]: http://img822.imageshack.us/img822/1208/frame08.png [2]: http://img688.imageshack.us/img688/81/frame081.png [3]: https://github.com/ebutera/meta-igep/tree/master/recipes-kernel/linux/linux-3.2/omap3isp [4]: https://github.com/ebutera/meta-igep/tree/master/recipes-kernel/linux/linux-3.2/tvp5150 -- 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/2] media: tvp5150: Add cropping support.
On Fri, Mar 2, 2012 at 9:35 AM, javier Martin javier.mar...@vista-silicon.com wrote: Hi all, I've been using and testing these patches successfully for a month. Do you have any comments on them? Do you think they are ready to be merged? [PATCH 1/2] media: tvp5150: Add cropping support [PATCH 2/2] media: tvp5150: Add g_mbus_fmt_callback fwiw, +1 for getting these merged. 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] Adding YUV input support for OMAP3ISP driver
On Sat, Feb 4, 2012 at 12:48 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-01-30 10:30, Gary Thomas wrote: On 2012-01-20 05:19, Laurent Pinchart wrote: Hi Enrico, On Thursday 19 January 2012 15:17:57 Enrico wrote: On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomasg...@mlbassoc.com wrote: On 2012-01-19 06:35, Gary Thomas wrote: My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0] .i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. rant Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). /rant I totally understand your feeling. I'd like to get YUV support integrated in the OMAP3 ISP driver. However, I have no YUV image source hardware, so I can only review the patches but not test them. If someone can rebase the existing patches on top of http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-yuv and test them, then I'll review the result. The attached patches produce a working setup against Laurent's tree above. That said, I don't recall exactly where which changes came from (I'm old school and not very git savvy, sorry). I've CC'd all the folks I think provided at least part of these changes. Perhaps we can all work together to come up with a proper set of patches which can be pushed upstream for this, once and for all? Thanks Ping! Is no one but me interested in getting these changes into the mainline? I am interested, i didn't have time to test it but i will for sure. And i think it's important to test non bt656/yuv sensors too, but i have no hardware for that. 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] Adding YUV input support for OMAP3ISP driver
On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-01-19 06:35, Gary Thomas wrote: My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0].i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. rant Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). /rant Enrico [1]: https://github.com/ebutera/meta-igep/tree/master/recipes-kernel/linux -- 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: [RFC 0/3] omap3isp: add BT656 support
On Thu, Oct 13, 2011 at 5:04 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Tue, Oct 11, 2011 at 5:08 PM, Enrico Butera ebut...@users.berlios.de wrote: This patch series add support for BT656 to omap3isp. It is based on patches from Deepthy Ravi and Javier Martinez Canillas. To be applied on top of omap3isp-omap3isp-yuv branch at: git.linuxtv.org/pinchartl/media.git Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data drivers/media/video/omap3isp/ispccdc.c | 143 ++- drivers/media/video/omap3isp/ispccdc.h | 1 + drivers/media/video/omap3isp/ispreg.h | 1 + drivers/media/video/omap3isp/ispvideo.c | 2 +- drivers/media/video/omap3isp/ispvideo.h | 4 +- include/media/omap3isp.h | 3 + 6 files changed, 129 insertions(+), 25 deletions(-) -- 1.7.4.1 Hello Laurent, Sakari and Deepthy, Did you take a look at Enrico's patches? We (Enrico, Gary and me) really want to add support both for interlaced mode and BT.656 video data format to the ISP driver. We are putting a lot of effort to this task but need the help of someone who knows better than use the ISP internals. So, we will be very happy if you can help us with this. We will address any issue you find with the patches. Right know we can get video in YUV format (CCDC BT.656 decoding and deinterlacing is already working) from the CCDC ouput pad (/dev/video2) but we have some ghosting effect and don't know what is causing this nor how to fix. Thank a lot and best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain Ping? 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: OMAP3 ISP ghosting
On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-13 06:32, Enrico wrote: Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. Is there any way to prove this by doing the de-interlacing in software? I just tested software deinterlacing (with gstreamer) and i can confirm it works very well, it removes ghosting completely. It will cause other problems that have a big performance impact (colorspace conversions, doubled framerates...) but that's another story, and i don't know if this is the appropriate place to talk about them. So i don't think it's the tvp51xx to blame or the isp, you will have to deinterlace with any analog decoder (unless it has integrated deinterlacing). 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: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 9:01 AM, Boris Todorov boris.st.todo...@gmail.com wrote: On Tue, Oct 18, 2011 at 7:31 PM, Enrico ebut...@users.berlios.de wrote: You can try if this: http://www.spinics.net/lists/linux-media/msg37795.html makes it work. Tried it but it's doesn't work for me. When yavta calls VIDIOC_DQBUF I'm stuck here: omap3isp_video_queue_dqbuf() - isp_video_buffer_wait() Wait for a buffer to be ready with O_NONBLOCK Btw my kernel is 2.6.35 but ISP and V4L are taken from omap3isp-omap3isp-yuv and according ISP/TVP register settings everything should be OK... When you stop yavta you should have in the kernel log something like this (this comes from an old log i'm not 100% sure they are the correct values): [ 655.470581] omap3isp omap3isp: ###CCDC PCR=0x [ 655.475677] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 655.481231] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 655.486816] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 655.492431] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 655.498046] omap3isp omap3isp: ###CCDC VERT_START=0x [ 655.503784] omap3isp omap3isp: ###CCDC VERT_LINES=0x0139 [ 655.509460] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 655.514892] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 655.520507] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 655.525848] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 655.531372] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 655.536651] omap3isp omap3isp: ###CCDC DCSUB=0x0040 [ 655.541900] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 655.547271] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 655.552612] omap3isp omap3isp: ###CCDC FPC=0x [ 655.557708] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 655.563232] omap3isp omap3isp: ###CCDC VDINT=0x013800d1 [ 655.568511] omap3isp omap3isp: ###CCDC ALAW=0x [ 655.573669] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 655.579193] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 655.584289] omap3isp omap3isp: ###CCDC FMTCFG=0xe000 [ 655.589660] omap3isp omap3isp: ###CCDC FMT_HORZ=0x [ 655.595184] omap3isp omap3isp: ###CCDC FMT_VERT=0x [ 655.600769] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 655.606323] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 655.611816] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 655.617279] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 655.622711] omap3isp omap3isp: ###CCDC VP_OUT=0x [ 655.628051] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 655.633758] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 655.639556] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 655.645599] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x Send your values so we can try to see where the problem is. 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: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov boris.st.todo...@gmail.com wrote: Here is my log: [ 24.683685] omap3isp omap3isp: -CCDC Register dump- [ 24.683685] omap3isp omap3isp: ###CCDC PCR=0x [ 24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x [ 24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105 [ 24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x [ 24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x [ 24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 24.683837] omap3isp omap3isp: ###CCDC FPC=0x [ 24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104 [ 24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d [ 24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 24.684051] omap3isp omap3isp: This is with: .data_lane_shift = 0, .clk_pol = 0, .hs_pol = 0, .vs_pol = 0, .data_pol = 0, .fldmode = 1, .bt656 = 1, and the above mentioned media-ctl settings From a quick look It seems ok (apart ALAW that maybe should be 0). One thing to check: before loading omap3-isp kernel module you must manually load iommu2, if you don't it will automatically load only iommu and it will not work 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: omap3isp: BT.656 support
On Tue, Oct 18, 2011 at 3:33 PM, Boris Todorov boris.st.todo...@gmail.com wrote: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I can see data from TVP5151 but there are no interrupts in ISP. You can try if this: http://www.spinics.net/lists/linux-media/msg37795.html makes it work. 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: OMAP3 ISP - interlaced data incorrect
On Sat, Oct 15, 2011 at 1:07 AM, Gary Thomas g...@mlbassoc.com wrote: For days, I've been chasing ghosts :-) I know they are still there, but I think they are more a function of the source than the ISP setup. So, I went looking for a better source, NTSC in my case. My choice is is a DVD player with known good video (I'm convinced that my cheap NTSC camera produces crap, especially when there is a lot of motion in the frames). Looking at this on an analogue TV (yes, they still exist!), the picture is not bad, so I think it's a good choice, at least when trying to understand what's happening with the OMAP3 ISP. Look at these two pictures: http://www.mlbassoc.com/misc/nemo-1.png http://www.mlbassoc.com/misc/nemo-swapped-1.png These represent one frame of data captured via my OMAP3 ISP + TVP5150 from a DVD (sorry, Disney). The first is a raw conversion of the frame using ffmpeg. As you can see, there seem to be lines swapped, so I wrote a little program to swap the lines even/odd. The second (nemo-swapped) shows what this looks like. Obviously, the data is not being stored in memory correctly. Does anyone know how to adjust the ISP to make this work the right way around? Currently in ispccdc.c, we have: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); I tried this: ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 2); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0); but this lead to a kernel panic :-( Somehow, we need to be storing the data something like this: EE EE EE EE ... EO EO EO EO ... OE OE OE OE ... OO OO OO OO ... but the current layout is ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); EO EO EO EO ... EE EE EE EE ... OO OO OO OO ... OE OE OE OE ... First, I need to get the data into memory in the correct order :-) Note: these results are consistent, i.e. if I stop things and do another grab, they are incorrect in the same [wrong] order. Just set the FINV bit (search for it in ispccdc.c), i tested it before and i had the opposite result (from a good looking nemo-swapped-like picture to a bad one). I've not done any recent tests with the gstreamer modules and the TI DSP code, but I will shortly. We'll see how well that does. I've tested it with the dsp and nothing changes, same problems. But i will be happy if proven wrong! 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: OMAP3 ISP - interlaced data incorrect
On Sat, Oct 15, 2011 at 1:23 AM, Gary Thomas g...@mlbassoc.com wrote: To be clear, moving from film to video, there would be no change of data within a single frame between the two interleaved halves. I'm sure this was even true of old cameras, which were not digital capture devices being used to send interleaved analogue data. You can see some of this in the [otherwise quite good] sequence of images http://www.mlbassoc.com/misc/nemo-swapped-1.png ... http://www.mlbassoc.com/misc/nemo-swapped-00062.png * Frames being skipped /or very stale data being reused - I think this is a [user] software problem. The ISP driver assumes that it always has an empty buffer to move captured data into. Depending on the [user] program which is consuming the data, this may or not be true. In the case of ffmpeg, if I capture raw images, ffmpeg can almost always keep up and there is always a free buffer. However, if I have ffmpeg turn the raw frames into compressed video (mp4), nearly 1/2 of the time, the ISP will run dry on buffers. I think I know how to fix this (untested) but it shows that some of the issues may be with the userland code we rely on. In the case of ffmpeg capturing raw data, there were no times that the ISP driver wanted a buffer and failed to get one, at least when storing the frames in a RAM disk. If stored to a physical device like MMC card, this might not be true. However, when ffmpeg is used to create an MP4 image, even to RAM disk, nearly 1/2 of the time the ISP goes wanting, which certainly can't be good! That is to be expected, it's not good but the worst thing that could happen is that you will lose some frames, not fields (unless you are losing interrupts too). So you will get laggy video, but with no ghosting. But i can't remember what the isp buffer code do when out of buffer so i'm assuming it will do a sane thing (drop the current frame). 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: OMAP3 ISP ghosting
On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas g...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? 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: OMAP3 ISP ghosting
On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-13 02:42, Enrico wrote: On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomasg...@mlbassoc.com wrote: Any ideas on this? My naive attempt (diffs attached) just hangs up. These changes disable BT-656 mode in the CCDC and tell the TVP5150 to output raw YUV 4:2:2 data including all SYNC signals. I tried that too, you will need to change many of the is_bt656 into is_fldmode. For isp configuration it seems that the only difference between the two is (more or less) just the REC656 register. I made a hundred attempts and in the end i had a quite working capture (just not centered) but ghosting always there. I made another test and by luck i got a strange thing, look at the following image: http://postimage.org/image/2d610pjk4/ (It's noisy because of a hardware problem) I made it with these changes: //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1); //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1); ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1); So you have an image with a field with no offset, and a field with offsets. Now if you look between my thumb and my forefinger behind them there's a monoscope picture and in one field you can see 2 black squares, in the other one you can see 3 black squares. So the two field that will be composing a single image differ very much. Now the questions are: is this expected to happen on an analogue video source and we can't do anything (apart from software deinterlacing)? is this a problem with tvp5150? Is this a problem with the isp? Yes, there does seem to be significant movement/differences between these two images. Are you saying that these should be the two halves of one frame that would be stitched together by de-interlacing? Perhaps the halves are out of sync and the bottom one of this image really goes with the top of the next (frame13)? They are two fields that normally will be merged into a frame, but with those settings i made the isp expand (SDOFST) just one of the fields. One possible thing is that, as you say, the bottom one of this image really goes with the top of the next. But one thing to consider is that it is normal for interlaced video to have such effects, that's why progressive scan was invented. The ghosting problem is still evident, even in this split image. Notice that every other scan line is really poor - basically junk. When this gets merged as part of the de-interlace, the ghosts appear. I don't think so. The bottom part is expanded by the isp, so it's ok to have green half lines, that's where the top part will go if it is expanded by the isp. Looking at the single images (top and bottom) i don't see ghosting artifacts (not only in that image but in a sequence of 16 frames), just a little blurry in moving parts but that's expected in an interlaced video. So it seems to me that the images arrive correctly at the isp and the deinterlacing causes ghosting. 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: [RFC 0/3] omap3isp: add BT656 support
On Wed, Oct 12, 2011 at 12:34 AM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.com wrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. I can't see how to turn off omap_vout In multimedia/video capture/omap2 video4linux I had it disabled and enabling it gave me an error too, but it's not something that is changed by my patches so it is broken in the -yuv tree. I made a distclean rebuild and i don't have any errors, are you sure you need that include in ispccdc.c? 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: omap3-isp status
On Mon, Oct 10, 2011 at 8:18 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Mon, Oct 10, 2011 at 7:09 PM, Enrico ebut...@users.berlios.de wrote:
On Mon, Oct 10, 2011 at 6:53 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Mon, Oct 10, 2011 at 6:34 PM, Enrico ebut...@users.berlios.de wrote:
Ok, i made it work. It was missing just the config_outlineoffset i
wrote before and a missing FLDMODE in SYNC registers.
Great, do you get the ghosting effect or do you have a clean video?
Unfortunately i always get the ghosting effect. But this is something
we will try to fix later.
Agree, we should try to get some code upstream to add interlaced video
and bt.656 support and fix the artifact later.
Moreover it seems to me that the software-maintained field id
(interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
useless, i've tried to only use the FLDSTAT bit from isp register
(fid) in vd0_isr:
if (fid == 0) {
restart = ccdc_isr_buffer(ccdc);
goto done;
}
and it works. I've not tested very long frame sequences, only up to 16
frames. The only issue is that the first frame could be half-green
because a field is missing.
Yes, when I tried Deepthy patches I realized that the fldstat was not
in sync with the frames, but probably I made something wrong.
I had noticed the same thing, but now i tested it and it is ok, maybe
my fault too.
We had the same problem with the hal-green frame. Our solution was to
synchronize the CCDC with the first even field looking at fdstat on
the VD1 interrupt handler and forcing to start processing from an ODD
sub-frame.
Thinking more about it, it's ugly to have that half-green video frame
even if it's just one. It's better to keep your or Deepthy solution.
Enrico
Well, that is something that can be fixed later also. Can you send to
the list your patches? So, Laurent, Sakari and others than know more
about the ISP can review it. I hope they can find the cause for the
artifact.
I'm attaching some fixes (taken from Deepthy patches) to be applied on
top of your v2 patches, with those i can grab frames but i only get
garbage.
I think the problem is that it always hits this in ccdc_isr_buffer:
if (ccdc_sbl_wait_idle(ccdc, 1000)) {
dev_info(isp-dev, CCDC won't become idle!\n);
goto done;
}
so the video buffer never gets updated.
At this point i think it is better to go on with my port of Deepthy
patches and try to solve the ghosting issues, maybe with your fixes
about buffer decoupling.
Laurent, what do you suggest to do?
Enrico
From 078f2843ba94cfbc150f6c01cc614c0ed3a35fd4 Mon Sep 17 00:00:00 2001
From: Enrico Butera ebut...@users.berlios.de
Date: Tue, 11 Oct 2011 11:51:38 +0200
Subject: [PATCH] omap3isp: some fixes for Javier v2 patches
Signed-off-by: Enrico Butera ebut...@users.berlios.de
---
drivers/media/video/omap3isp/ispccdc.c | 41 +++
1 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index f1da49c..0cb4e36 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -43,6 +43,7 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
static bool ccdc_input_is_fldmode(struct isp_ccdc_device *ccdc);
+static int __ccdc_handle_stopping(struct isp_ccdc_device *ccdc, u32 event);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -795,11 +796,17 @@ static void ccdc_apply_controls(struct isp_ccdc_device *ccdc)
void omap3isp_ccdc_restore_context(struct isp_device *isp)
{
struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct v4l2_mbus_framefmt *format;
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, ISPCCDC_CFG_VDLC);
- ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
- | OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
+ /* CCDC_PAD_SINK */
+ format = ccdc-formats[CCDC_PAD_SINK];
+ if ((format-code != V4L2_MBUS_FMT_UYVY8_2X8)
+ (format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+ ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
+| OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
+
ccdc_apply_controls(ccdc);
ccdc_configure_fpc(ccdc);
}
@@ -1021,10 +1028,10 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
if (pdata pdata-bt656)
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
else
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
}
/* CCDC formats descriptions */
@@ -1187,7 +1194,9 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
ccdc_pattern
[RFC 0/3] omap3isp: add BT656 support
This patch series add support for BT656 to omap3isp. It is based on patches from Deepthy Ravi and Javier Martinez Canillas. To be applied on top of omap3isp-omap3isp-yuv branch at: git.linuxtv.org/pinchartl/media.git Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data drivers/media/video/omap3isp/ispccdc.c | 143 ++- drivers/media/video/omap3isp/ispccdc.h |1 + drivers/media/video/omap3isp/ispreg.h |1 + drivers/media/video/omap3isp/ispvideo.c |2 +- drivers/media/video/omap3isp/ispvideo.h |4 +- include/media/omap3isp.h|3 + 6 files changed, 129 insertions(+), 25 deletions(-) -- 1.7.4.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
[RFC 1/3] omap3isp: ccdc: Add interlaced field mode to platform data
From: Javier Martinez Canillas martinez.jav...@gmail.com
The fldmode field from the CCDC_SYN_MODE register configure the ISP CCDC
between progresive and interlaced mode.
Adding this field to the platform data, allows boards to configure accordingly.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
Signed-off-by: Enrico Butera ebut...@users.berlios.de
---
include/media/omap3isp.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 3b2d2b7..0f215de 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -61,6 +61,8 @@ enum {
* 0 - Normal, 1 - One's complement
* @bt656: ITU-R BT656 embedded synchronization
* 0 - HS/VS sync, 1 - BT656 sync
+ * @fldmode: Field mode
+ * 0 - progressive, 1 - Interlaced
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
@@ -69,6 +71,7 @@ struct isp_parallel_platform_data {
unsigned int vs_pol:1;
unsigned int data_pol:1;
unsigned int bt656:1;
+ unsigned int fldmode:1;
};
enum {
--
1.7.4.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
[RFC 2/3] omap3isp: ispvideo: export isp_video_mbus_to_pix
This function will be used in ispccdc.
Signed-off-by: Enrico Butera ebut...@users.berlios.de
---
drivers/media/video/omap3isp/ispvideo.c |2 +-
drivers/media/video/omap3isp/ispvideo.h |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index cc73375..d59f886 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -164,7 +164,7 @@ static bool isp_video_is_shiftable(enum v4l2_mbus_pixelcode
in,
*
* Return the number of padding bytes at end of line.
*/
-static unsigned int isp_video_mbus_to_pix(const struct isp_video *video,
+unsigned int isp_video_mbus_to_pix(const struct isp_video *video,
const struct v4l2_mbus_framefmt *mbus,
struct v4l2_pix_format *pix)
{
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h
index 52fe46b..5fa8fd7 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -200,7 +200,9 @@ struct isp_buffer *omap3isp_video_buffer_next(struct
isp_video *video,
unsigned int error);
void omap3isp_video_resume(struct isp_video *video, int continuous);
struct media_pad *omap3isp_video_remote_pad(struct isp_video *video);
-
+extern unsigned int isp_video_mbus_to_pix(const struct isp_video *video,
+ const struct v4l2_mbus_framefmt *mbus,
+ struct v4l2_pix_format *pix);
const struct isp_format_info *
omap3isp_video_format_info(enum v4l2_mbus_pixelcode code);
--
1.7.4.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
[RFC 3/3] omap3isp: ispccdc: configure CCDC registers and add BT656 support
This is a port of the following Deepthy Ravi patches:
[PATCH 5/8] ispccdc: Configure CCDC registers
[PATCH 6/8] ispccdc: Add support for BT656 interface
Signed-off-by: Enrico Butera ebut...@users.berlios.de
---
drivers/media/video/omap3isp/ispccdc.c | 143 ++-
drivers/media/video/omap3isp/ispccdc.h |1 +
drivers/media/video/omap3isp/ispreg.h |1 +
3 files changed, 122 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index c25db54..fde3268 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -59,8 +59,11 @@ static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_SGBRG12_1X12,
V4L2_MBUS_FMT_YUYV8_2X8,
V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
};
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+
/*
* ccdc_print_status - Print current CCDC Module register values.
* @ccdc: Pointer to ISP CCDC device.
@@ -792,11 +795,16 @@ static void ccdc_apply_controls(struct isp_ccdc_device
*ccdc)
void omap3isp_ccdc_restore_context(struct isp_device *isp)
{
struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct v4l2_mbus_framefmt *format;
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, ISPCCDC_CFG_VDLC);
- ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
-| OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
+ /* CCDC_PAD_SINK */
+ format = ccdc-formats[CCDC_PAD_SINK];
+ if ((format-code != V4L2_MBUS_FMT_UYVY8_2X8)
+ (format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+ ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
+ | OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
ccdc_apply_controls(ccdc);
ccdc_configure_fpc(ccdc);
}
@@ -1010,6 +1018,9 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1021,10 +1032,11 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
if (pdata pdata-bt656)
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
else
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
+
}
/* CCDC formats descriptions */
@@ -1106,6 +1118,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
struct isp_parallel_platform_data *pdata = NULL;
struct v4l2_subdev *sensor;
struct v4l2_mbus_framefmt *format;
+ struct v4l2_pix_format pix;
const struct isp_format_info *fmt_info;
struct v4l2_subdev_format fmt_src;
unsigned int depth_out;
@@ -1164,6 +1177,9 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
/* CCDC_PAD_SINK */
format = ccdc-formats[CCDC_PAD_SINK];
+ if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
+ isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG,
+ ISPCCDC_CFG_Y8POS);
/* Mosaic filter */
switch (format-code) {
case V4L2_MBUS_FMT_SRGGB10_1X10:
@@ -1183,28 +1199,70 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
ccdc_pattern = ccdc_sgrbg_pattern;
break;
}
- ccdc_config_imgattr(ccdc, ccdc_pattern);
- /* Generate VD0 on the last line of the image and VD1 on the
-* 2/3 height line.
-*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
- OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+ if ((format-code != V4L2_MBUS_FMT_YUYV8_2X8)
+ (format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+ ccdc_config_imgattr(ccdc, ccdc_pattern);
+
+ /* BT656: Generate VD0 on the last line of each field, and we
+ * don't use VD1.
+ * Non BT656: Generate VD0 on the last line of the image and VD1 on the
+ * 2/3 height line.
+ */
+ if (pdata-bt656)
+ isp_reg_writel(isp,
+ (format-height/2 - 2) ISPCCDC_VDINT_0_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+ else
+ isp_reg_writel(isp,
+ ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
+ ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT
Re: [RFC 0/3] omap3isp: add BT656 support
On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomas g...@mlbassoc.com wrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. 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: [RFC 0/3] omap3isp: add BT656 support
On Wed, Oct 12, 2011 at 12:36 AM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-11 16:34, Gary Thomas wrote: On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.com wrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. That said, it's not clear the current/final state of them. I don't see any repost after the very long discussion with Laurent. Me too, and i don't remeber if Javier is going/was requested to send a v2. Maybe you could just send that file to me directly? I'm not at work now but you can find the patches here: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 They should apply cleanly. 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: omap3-isp status
On Mon, Oct 10, 2011 at 1:00 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Mon, Oct 10, 2011 at 12:35 AM, Enrico ebut...@users.berlios.de wrote: I made some tests and unfortunately there are some problems. Note: i made these tests picking some patches from omap3isp-yuv branch and applying to igep 3.1.0rc9 kernel (more or less like mainline + some bsp patches) so maybe i made some mistakes (the tvp5150 driver is patched too), but due to the nature of the problems i don't think this is the case. Javier patches v1: i can grab frames with yavta but i get only garbage. Javier patches v2: i cannot grab frames with yavta (it hangs). I see only 2 interrupts on the isp, then stops. I compared Javier-v2 registers setup with Deepthy's patches and there are some differences. Moreover i remember that in Deepthy patches vd1 interrupt was not used (and in fact i had the same yavta-hanging problem before, and Deepthy patches solved it). I think Javier-v1 patches didn't hang the isp because they changed vd0/vd1 logic too, so maybe there were only some wrong isp registers but the logic was correct. Now i wonder if it could be easier/better to port Deepthy patches first and then add Javier fixes... Enrico Hi Enrico, Yes, you are right in interlaced mode the VD1 interrupt handler doesn't have to be executed. In v1 there is a conditional execution and that is why the ISP doesn't hang up. Could you please try changing this on ispccdc.c with v2 patches? diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 9b40968..bfd3f46 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device *ccdc, u32 events) if (ccdc-state == ISP_PIPELINE_STREAM_STOPPED) return 0; - if (events IRQ0STATUS_CCDC_VD1_IRQ) + if ((events IRQ0STATUS_CCDC_VD1_IRQ) + !ccdc_input_is_fldmode(ccdc)) ccdc_vd1_isr(ccdc); ccdc_lsc_isr(ccdc, events); With this change the ISP shouldn't hang but I don't know if you will get the right data. I tried that but i only get this: root@igep0020:~# yavta -c4 -f UYVY -s 720x625 -n 4 /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: UYVY (59565955) 720x625 buffer size 90 Video format: UYVY (59565955) 720x625 buffer size 90 4 buffers requested. length: 90 offset: 0 Buffer 0 mapped at address 0x4027a000. length: 90 offset: 901120 Buffer 1 mapped at address 0x403de000. length: 90 offset: 1802240 Buffer 2 mapped at address 0x4059b000. length: 90 offset: 2703360 Buffer 3 mapped at address 0x40748000. [ 952.675170] omap3isp omap3isp: CCDC won't become idle! [ 952.695159] omap3isp omap3isp: CCDC won't become idle! [ 952.715179] omap3isp omap3isp: CCDC won't become idle! [ 952.735137] omap3isp omap3isp: CCDC won't become idle! and it continues forever saying that. I'm going to try to apply Deepthy patches on omap3isp-yuv and hope it will work. 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: omap3-isp status
On Mon, Oct 10, 2011 at 11:02 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Is your tree (igep 3.1.0rc9 kernel + omap3isp-yuv patches) accessible so I can clone and give a try? I can then make a patch-set on top on that, one that I can actually test on real hardware and be sure that is working well. If I can git clone your tree then it will be faster, otherwise I will try omap3isp-yuv with igep board support added, but it would take me more time to do so. I will find some free time late this afternoon to try that. I have updated my igep openembedded layer at [1] (testing branch) with: current igep master kernel (3.1.0rc9) + omap3isp-yuv patches + your patches v2 + tvp5150 patches + some tvp5150 and board files fixes. All the patches (specified in the .bb file) are git am-able patches so you can just clone the igep master repository and apply all the patches (0001-0025). This is the cover letter for the patches i applied, if someone can review the omap3isp related patches to be sure i didn't forget anything it would be very helpful: Arnaud Lacombe (1): drivers/media: do not use EXTRA_CFLAGS Enrico Butera (3): tvp5150: compile fixes and added missing entity_cleanup exp-igep0022: add tvp5151 support igep00x0: fix camera platform data Guennadi Liakhovetski (1): omap3isp: ccdc: remove redundant operation Ivaylo Petrov (1): omap3isp: csi2: Add V4L2_MBUS_FMT_YUYV8_2X8 support Javier Martinez Canillas (6): omap3isp: ccdc: Add interlaced field mode to platform data omap3isp: ccdc: Add interlaced count field to isp_ccdc_device omap3isp: ccdc: Add support to ITU-R BT.656 video data format tvp5150: Add constants for PAL and NTSC video standards tvp5150: Add video format registers configuration values tvp5150: Migrate to media-controller framework and add video format detection Laurent Pinchart (12): omap3isp: Don't accept pipelines with no video source as valid omap3isp: Move platform data definitions from isp.h to media/omap3isp.h omap3isp: Don't fail streamon when the sensor doesn't implement s_stream omap3isp: video: Avoid crashes when pipeline set stream operation fails omap3isp: Move media_entity_cleanup() from unregister() to cleanup() omap3isp: Move *_init_entities() functions to the init/cleanup section omap3isp: Add missing mutex_destroy() calls omap3isp: Fix memory leaks in initialization error paths omap3isp: video: Split format info bpp field into width and bpp omap3isp: ccdc: Remove support for interlaced data and master HS/VS mode omap3isp: ccdc: Remove ispccdc_syncif structure omap3isp: ccdc: Add YUV input formats support Michael Jones (1): omap3isp: queue: fail QBUF if user buffer is too small arch/arm/mach-omap2/board-igep00x0.c | 67 + arch/arm/mach-omap2/exp-igep0022.c |3 + drivers/media/video/omap3isp/Makefile |4 +- drivers/media/video/omap3isp/isp.c | 13 +- drivers/media/video/omap3isp/isp.h | 87 +-- drivers/media/video/omap3isp/ispccdc.c | 376 -- drivers/media/video/omap3isp/ispccdc.h | 38 +--- drivers/media/video/omap3isp/ispccp2.c | 129 +- drivers/media/video/omap3isp/ispcsi2.c | 118 +--- drivers/media/video/omap3isp/isph3a_aewb.c |2 +- drivers/media/video/omap3isp/isph3a_af.c |2 +- drivers/media/video/omap3isp/isphist.c |2 +- drivers/media/video/omap3isp/isppreview.c | 108 drivers/media/video/omap3isp/ispqueue.c|4 + drivers/media/video/omap3isp/ispresizer.c | 104 drivers/media/video/omap3isp/ispstat.c | 52 ++-- drivers/media/video/omap3isp/ispstat.h |2 +- drivers/media/video/omap3isp/ispvideo.c| 77 -- drivers/media/video/omap3isp/ispvideo.h|5 +- drivers/media/video/tvp5150.c | 408 +++- drivers/media/video/tvp5150_reg.h | 17 +- include/media/omap3isp.h | 138 ++ include/media/tvp5150.h|6 + 23 files changed, 1215 insertions(+), 547 deletions(-) create mode 100644 include/media/omap3isp.h 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: omap3-isp status
On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote: I have updated my igep openembedded layer at [1] (testing branch) with: Ops, forgot [1] ! [1]: https://github.com/ebutera/meta-igep 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: omap3-isp status
On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote:
On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote:
I have updated my igep openembedded layer at [1] (testing branch) with:
Ops, forgot [1] !
[1]: https://github.com/ebutera/meta-igep
Enrico
Perfect, thank you Enrico. I will try this latter today and let you
know. I'm sure I can get this working (with the ghosting effect of
course) so you can at least obtain 25 fps and once I have this working
I will resend the patch-set as v3 so Laurent can review it and
hopefully help us to fix the artifact on the video.
Yes it must be something simple but not easy to spot.
And to add even more confusion i've attached two patches: one is a
port of two Deepthy patches, the other one just a board fix.
Just replace patches 0017-18-19 with the attached 0001 patch, and
after patch 0025 apply the attached 0002 patch.
With these i can succesfully grab frames with yavta BUT i only get
half-height frames. Disclaimer: i just made the patch monkey and gave
it a run without a review so it could be anything.
Enrico
From abb4d9df937ebda4f628d5b94ae02c60e7b06a7b Mon Sep 17 00:00:00 2001
From: Enrico Butera ebut...@users.berlios.de
Date: Mon, 10 Oct 2011 14:16:46 +0200
Subject: [PATCH] omap3isp: configure ccdc and add bt656 support
This is a port of the following Deepthy Ravi patches:
[PATCH 5/8] ispccdc: Configure CCDC registers
[PATCH 6/8] ispccdc: Add support for BT656 interface
Signed-off-by: Enrico Butera ebut...@users.berlios.de
---
drivers/media/video/omap3isp/ispccdc.c | 126 +--
drivers/media/video/omap3isp/ispccdc.h |1 +
drivers/media/video/omap3isp/ispreg.h |1 +
drivers/media/video/omap3isp/ispvideo.c |2 +-
drivers/media/video/omap3isp/ispvideo.h |4 +-
5 files changed, 110 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index ce0e57d..3903acf 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -60,8 +60,11 @@ static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_SGBRG12_1X12,
V4L2_MBUS_FMT_YUYV8_2X8,
V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
};
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+
/*
* ccdc_print_status - Print current CCDC Module register values.
* @ccdc: Pointer to ISP CCDC device.
@@ -793,11 +796,16 @@ static void ccdc_apply_controls(struct isp_ccdc_device *ccdc)
void omap3isp_ccdc_restore_context(struct isp_device *isp)
{
struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct v4l2_mbus_framefmt *format;
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, ISPCCDC_CFG_VDLC);
- ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
- | OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
+ /* CCDC_PAD_SINK */
+ format = ccdc-formats[CCDC_PAD_SINK];
+ if ((format-code != V4L2_MBUS_FMT_UYVY8_2X8)
+ (format-code != V4L2_MBUS_FMT_UYVY8_2X8))
+ ccdc-update = OMAP3ISP_CCDC_ALAW | OMAP3ISP_CCDC_LPF
+| OMAP3ISP_CCDC_BLCLAMP | OMAP3ISP_CCDC_BCOMP;
ccdc_apply_controls(ccdc);
ccdc_configure_fpc(ccdc);
}
@@ -1022,10 +1030,10 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
if (pdata pdata-bt656)
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
else
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_REC656IF,
- ISPCCDC_REC656IF_R656ON);
+ ISPCCDC_REC656IF_R656ON | ISPCCDC_REC656IF_ECCFVH);
}
/* CCDC formats descriptions */
@@ -1107,6 +1115,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
struct isp_parallel_platform_data *pdata = NULL;
struct v4l2_subdev *sensor;
struct v4l2_mbus_framefmt *format;
+ struct v4l2_pix_format pix;
const struct isp_format_info *fmt_info;
struct v4l2_subdev_format fmt_src;
unsigned int depth_out;
@@ -1165,6 +1174,9 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
/* CCDC_PAD_SINK */
format = ccdc-formats[CCDC_PAD_SINK];
+ if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
+ isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG,
+ ISPCCDC_CFG_Y8POS);
/* Mosaic filter */
switch (format-code) {
case V4L2_MBUS_FMT_SRGGB10_1X10:
@@ -1184,27 +1196,59 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
ccdc_pattern = ccdc_sgrbg_pattern;
break;
}
- ccdc_config_imgattr(ccdc, ccdc_pattern);
- /* Generate VD0 on the last line of the image and VD1 on the
- * 2/3 height line.
- */
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
- OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+ if ((format-code != V4L2_MBUS_FMT_YUYV8_2X8)
+ (format-code != V4L2_MBUS_FMT_UYVY8_2X8
Re: omap3-isp status
On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote: On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote: I have updated my igep openembedded layer at [1] (testing branch) with: Ops, forgot [1] ! [1]: https://github.com/ebutera/meta-igep Enrico Perfect, thank you Enrico. I will try this latter today and let you know. I'm sure I can get this working (with the ghosting effect of course) so you can at least obtain 25 fps and once I have this working I will resend the patch-set as v3 so Laurent can review it and hopefully help us to fix the artifact on the video. For your tests i suggest to add nohlt to the kernel cmdline, see [1] for the reason. Enrico [1]: http://www.spinics.net/lists/linux-media/msg37795.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
Re: omap3-isp status
On Mon, Oct 10, 2011 at 2:46 PM, Enrico ebut...@users.berlios.de wrote: On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Mon, Oct 10, 2011 at 12:07 PM, Enrico ebut...@users.berlios.de wrote: On Mon, Oct 10, 2011 at 12:06 PM, Enrico ebut...@users.berlios.de wrote: I have updated my igep openembedded layer at [1] (testing branch) with: Ops, forgot [1] ! [1]: https://github.com/ebutera/meta-igep Enrico Perfect, thank you Enrico. I will try this latter today and let you know. I'm sure I can get this working (with the ghosting effect of course) so you can at least obtain 25 fps and once I have this working I will resend the patch-set as v3 so Laurent can review it and hopefully help us to fix the artifact on the video. Yes it must be something simple but not easy to spot. And to add even more confusion i've attached two patches: one is a port of two Deepthy patches, the other one just a board fix. Just replace patches 0017-18-19 with the attached 0001 patch, and after patch 0025 apply the attached 0002 patch. With these i can succesfully grab frames with yavta BUT i only get half-height frames. Disclaimer: i just made the patch monkey and gave it a run without a review so it could be anything. My bad, i forgot a part about config_outlineoffset (ODDEVEN...), i still have (different) half-green images though... Side note: while making some tests i can confirm that the solution adopted in Deepthy patches: u32 syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE); fid = syn_mode ISPCCDC_SYN_MODE_FLDSTAT; /* toggle the software maintained fid */ works as expected, i see fid switching correctly. 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: omap3-isp status
On Mon, Oct 10, 2011 at 4:17 PM, Enrico ebut...@users.berlios.de wrote:
On Mon, Oct 10, 2011 at 2:46 PM, Enrico ebut...@users.berlios.de wrote:
On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas
Perfect, thank you Enrico. I will try this latter today and let you
know. I'm sure I can get this working (with the ghosting effect of
course) so you can at least obtain 25 fps and once I have this working
I will resend the patch-set as v3 so Laurent can review it and
hopefully help us to fix the artifact on the video.
Yes it must be something simple but not easy to spot.
And to add even more confusion i've attached two patches: one is a
port of two Deepthy patches, the other one just a board fix.
Just replace patches 0017-18-19 with the attached 0001 patch, and
after patch 0025 apply the attached 0002 patch.
With these i can succesfully grab frames with yavta BUT i only get
half-height frames. Disclaimer: i just made the patch monkey and gave
it a run without a review so it could be anything.
My bad, i forgot a part about config_outlineoffset (ODDEVEN...), i
still have (different) half-green images though...
Side note: while making some tests i can confirm that the solution
adopted in Deepthy patches:
u32 syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
fid = syn_mode ISPCCDC_SYN_MODE_FLDSTAT;
/* toggle the software maintained fid */
works as expected, i see fid switching correctly.
Ok, i made it work. It was missing just the config_outlineoffset i
wrote before and a missing FLDMODE in SYNC registers.
Moreover it seems to me that the software-maintained field id
(interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
useless, i've tried to only use the FLDSTAT bit from isp register
(fid) in vd0_isr:
if (fid == 0) {
restart = ccdc_isr_buffer(ccdc);
goto done;
}
and it works. I've not tested very long frame sequences, only up to 16
frames. The only issue is that the first frame could be half-green
because a field is missing.
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: omap3-isp status
On Mon, Oct 10, 2011 at 6:53 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Mon, Oct 10, 2011 at 6:34 PM, Enrico ebut...@users.berlios.de wrote:
Ok, i made it work. It was missing just the config_outlineoffset i
wrote before and a missing FLDMODE in SYNC registers.
Great, do you get the ghosting effect or do you have a clean video?
Unfortunately i always get the ghosting effect. But this is something
we will try to fix later.
Moreover it seems to me that the software-maintained field id
(interlaced_cnt in Javier patches, fldstat in Deepthy patches) is
useless, i've tried to only use the FLDSTAT bit from isp register
(fid) in vd0_isr:
if (fid == 0) {
restart = ccdc_isr_buffer(ccdc);
goto done;
}
and it works. I've not tested very long frame sequences, only up to 16
frames. The only issue is that the first frame could be half-green
because a field is missing.
Yes, when I tried Deepthy patches I realized that the fldstat was not
in sync with the frames, but probably I made something wrong.
I had noticed the same thing, but now i tested it and it is ok, maybe
my fault too.
We had the same problem with the hal-green frame. Our solution was to
synchronize the CCDC with the first even field looking at fdstat on
the VD1 interrupt handler and forcing to start processing from an ODD
sub-frame.
Thinking more about it, it's ugly to have that half-green video frame
even if it's just one. It's better to keep your or Deepthy solution.
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 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 12:02 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patch. Laurent, apart from the specific comments on Javier code, did you have a look at Deepthy patches too? I say this because asking Javier for fixes means (to me) that you are going to merge his patches (if testing will confirm it works of course). Am i wrong? Btw i'm trying to get these patches on 3.1.0rc9 (from igep repository, that should be just like mainline 3.1.0rc9 with some bsp patches), i hope i will report good news. 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: omap3-isp status
On Sat, Oct 8, 2011 at 6:11 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Yes, I'll cook a patch today on top on your omap3isp-yuv and send for review. I won't be able to test neither since I don't have proper hardware at home. But at least you will get an idea of the approach we are using to solve this and can point possible flaws. I made some tests and unfortunately there are some problems. Note: i made these tests picking some patches from omap3isp-yuv branch and applying to igep 3.1.0rc9 kernel (more or less like mainline + some bsp patches) so maybe i made some mistakes (the tvp5150 driver is patched too), but due to the nature of the problems i don't think this is the case. Javier patches v1: i can grab frames with yavta but i get only garbage. Javier patches v2: i cannot grab frames with yavta (it hangs). I see only 2 interrupts on the isp, then stops. I compared Javier-v2 registers setup with Deepthy's patches and there are some differences. Moreover i remember that in Deepthy patches vd1 interrupt was not used (and in fact i had the same yavta-hanging problem before, and Deepthy patches solved it). I think Javier-v1 patches didn't hang the isp because they changed vd0/vd1 logic too, so maybe there were only some wrong isp registers but the logic was correct. Now i wonder if it could be easier/better to port Deepthy patches first and then add Javier fixes... 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: omap3-isp status
On Thu, Oct 6, 2011 at 6:05 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Thu, Oct 6, 2011 at 5:25 PM, Enrico ebut...@users.berlios.de wrote: - i don't see Deepthy patches, it seems to be based on the pre-Deepthy-patches driver and fixed (not that this is a bad thing!); i say this because, like Gary, i'm interested in a possible forward porting to a more recent kernel so i was searching for a starting point I didn't know there was a more recent version of Deepthy patches, Since they are not yet in mainline we should decide if we work on top of that or on top of mainline. Deepthy patches are very good to separate bt656 and non-bt656 execution inside the ISP, also add a platform data variable to decide which mode has to be used. But reading the documentation and from my experimental validation I think that there are a few things that can be improved. First the assumption that we can use FLDSTAT to check if a frame is ODD or EVEN I find to not always be true. Also I don't know who sets this value since in the TRM always talks as it is only used with discrete syncs. Yes about FLDSTAT i noticed the same thing. And that's why we need someone that knows the ISP better to help us Also, I don't think that we should change the ISP CCDC configuration inside the VD0 interrupt handler. Since the shadowed registers only can be accessed during a frame processing, or more formally the new values are taken at the beginning of a frame execution. By the time we change for example the output address memory for the next buffer in the VD0 handler, the next frame is already being processed so that value won't be used for the CCDC until that frame finish. So It is not behaving as the code expect, since for 3 frames the CCDC output memory address will be the same. That is why I move most of the logic to the VD1 interrupt since there the current frame didn't finish yet and we can configure the CCDC for the next frame. But to do that the buffer for the next frame and the releasing of the last buffer can't happen simultaneously, that is why I decouple these two actions. Again, this is my own observations and what I understood from the TRM and I could be wrong. I can't comment on that, i hope Laurent or Deepthy will join the discussion... - i don't think that adding the priv field in v4l2-mediabus.h will be accepted, and since it is related to the default cropping you added i think it can be dropped and just let the user choose the appropriate cropping Yes, probably is too much of a hack, but I didn't know of another way that the subdev could report to the ISP of the standard and since v4l2_pix_format has also a priv field, I think it could be at least a temporary solution (remember that we want this to work first and then we plan to do it right for upstream submission). ...and my hope continues here. 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: omap3-isp status
On Fri, Oct 7, 2011 at 12:22 PM, Gary Thomas g...@mlbassoc.com wrote: Do we know for sure that these problems are happening in the ISP itself or could they possibly be in the TVP5150? Does anyone have experience with a different analogue encoder? Never tried another encoder, but at this point it's something to look at. I don't think some TI people will say yes the encoder has ghosting artifacts. 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: omap3-isp status
On Thu, Oct 6, 2011 at 9:51 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Since the patches are not against mainline I can't post for reviewing but can be found in one of our development trees [1]. Comments are highly appreciated. The tree is a 2.6.37 that already contain Deepthy patch. I rebased my changes on top of that to correctly support both BT656 an non-BT656 video data processing. [1]: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=shortlog;h=refs/heads/linux-2.6.37.y-next Some random comments from a quick view at [1]: - i don't see Deepthy patches, it seems to be based on the pre-Deepthy-patches driver and fixed (not that this is a bad thing!); i say this because, like Gary, i'm interested in a possible forward porting to a more recent kernel so i was searching for a starting point - i don't think that adding the priv field in v4l2-mediabus.h will be accepted, and since it is related to the default cropping you added i think it can be dropped and just let the user choose the appropriate cropping - because of the previous point, i think the PAL(NTSC)_NUM_ACTIVE_LINES can stay to 625(525) - we really need some comments from someone that is not me, you and Gary [1]: http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=history;f=drivers/media/video/isp;hb=refs/heads/linux-2.6.37.y-next Right now I have a working the tvp5151 with the ISP. I can capture ITU-R BT656 video both in PAL-M and NTSC standard. Also, the whole pipeline is configured automatically with the video standard detected by the tvp5151. Also, I'm using the CCDC to crop the frames and only capture the active lines for each standard (576 for PAL and 480 for NTSC) using the CCDC to crop the image. As I told you before video capturing is working for both PAL and NTSC using standard V4L2 application (i.e: gstreamer) but the video still shows some motion artifacts. Capturing YUV frames and looking at them I realized that there does exist a pattern, the sequence 2 frames correct and 3 frames with interlacing effects always repeats. Yes i've seen that too, i was planning to do some tests when things will settle down. 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: Help with omap3isp resizing
On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote: On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote: Thanks for your help. I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to work now. However, I needed to take out the memcpy in ccdc_try_format(), because otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm not sure why it was done that way. I think it's better that the given code gets checked to see if it's in the list and if so use it. Do you know of any valid reason why this copy is done? If I remember corretly, it's because there's nothing the CCDC may do to the size of the image --- the driver doesn't either support cropping on the CCDC. The sink format used to be always the same as the source format, the assumption which no longer is valid when YUYV8_2X8 etc. formats are supported. This must be taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_1X16 instead of just copying the format as such. Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems possible to set some registers (start pixel horizontal/vertical and so on...) to crop the final image, but i never tested it. 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
omap3-isp status
Hi all, since we are all interested in this driver (and tvp5150) i'll try to make a summary of the current situation and understand what is needed to finally get it into the main tree instead of having to apply a dozen patches manually. The current status of git repositories/branches is: - main tree: working (i suppose) but no support for bt656 input - pinchartl/media: * omap3isp-omap3isp-next: i think it's in sync with linuxtv master (for the omap3-isp parts) * omap3isp-omap3isp-yuv: like ..next but with some additional format patches Floating patches: - Deepthy: sent patches (against mainline) to add bt656 support Laurent made some comments, i haven't seen a v2 to be applied - Javier: sent patches for tvp5150, currently discussed on linux-media; possible patches/fixes for omap3-isp Now what can we all do to converge to a final solution? I think this is also blocking the possible development/test of missing features, like the recently-discussed resizer and cropping ones. 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 0/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Sat, Oct 1, 2011 at 5:55 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: We hack a few bits of the ISP CCDC driver to support ITU-R BT656 interlaced data with embedded syncs video format and ported the tvp5150 driver to the MCF so it can be detected as a sub-device and be part of the OMAP ISP image processing pipeline (as a source pad). That was already posted on the list [1], there was some discussion but i don't know what's the status/plan to get it into mainline. And, as you can see in [2], don't expect many comments :D [1]: http://www.spinics.net/lists/linux-media/msg37710.html [2]: http://www.spinics.net/lists/linux-media/msg37116.html Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html I didn't know that the physical connection affected the video output format, I thought that it was only a physical medium to carry the same information, sorry if my comments are silly but I'm really newbie with video in general. I think you got it right, i haven't tested it but the output format shouldn't be affected by the video source( if it stays pal/ntsc of course). Maybe you will get only a different active video area so only cropping will be affected. 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 0/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Sat, Oct 1, 2011 at 7:27 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Yes, I saw it. That is why I didn't post our modifications to the ISP CCDC driver. Our approach is very similar to the one followed by TI (changing the CCDC output buffer every two VD0 interrupts) but we did different a few things: - decouple next buffer obtaining from last buffer releasing - maintain two buffers (struct isp_buffer), current and last - move move most of the logic to the VD1 interrupt since the ISP is already busy while execution VD0 handler. If you think it is a better approach you can submit it for review, right now there is no clean version supporting bt656 so yours can be the one. Even if it does detect the signal shape (NTSC, PAL), doesn't one still need to [externally] configure the pads for this shape? Yes, that is why I wanted to do the auto-detection for the tvp5151, so we only have to manually configure the ISP components (or any other hardware video processing pipeline entities, sorry for my OMAP-specific comments). Laurent was not very happy [3] about changing video formats out of the driver control, so this should be discussed more. [3]: http://www.spinics.net/lists/linux-omap/msg56983.html Ok, I thought it was the right thing to do, my bad. Lets do it from user-space then using the MCF. I see there is some ongoing discussion about a similar topic, so just follow it and see how it turns out. 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: omap3isp as a wakeup source
On Tue, Sep 13, 2011 at 3:25 PM, Enrico ebut...@users.berlios.de wrote: On Tue, Sep 13, 2011 at 12:29 PM, Tero Kristo t-kri...@ti.com wrote: Powerdomain is automatically on if there are any clocks enabled on it. If you make sure that ISP has some activity ongoing, then it should be on. You can check the state of the camera powerdomain from /sys/kernel/debug/pm_debug/count file, if you have mounted debugfs. And in fact something seems wrong (this is on a patched 3.0.4 kernel): usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:9,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (20) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) core_l4_clkdm-core_pwrdm (23) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) I think the line cam_clkdm-cam_pwrdm (0) means that it was never enabled, but i grabbed some frames with yavta before that. Forget that, i was wrong. While yavta is running (or better to say: hanged waiting for frames) i have this: cam_pwrdm (ON),OFF:0,RET:6,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_clkdm-cam_pwrdm (3) So it seems that clocks/power domains are acquired correctly but ignored. And from /proc/interrupts i can see the isp counter increasing (while yavta is hanged waiting for frames). Is it possibile this happens only because some pm_runtime_enable/disable/get/put are missing in omap3isp? Thanks, 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: omap3isp as a wakeup source
On Tue, Sep 13, 2011 at 11:48 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-13 at 08:49 +0200, Sakari Ailus wrote:
anish singh wrote:
On Tue, Sep 13, 2011 at 1:58 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
On Mon, Sep 12, 2011 at 04:50:42PM +0200, Enrico wrote:
Hi,
Hi Enrico,
While testing omap3isp+tvp5150 with latest Deepthy bt656 patches
(kernel 3.1rc4) i noticed that yavta hangs very often when grabbing
or, if not hanged, it grabs at max ~10fps.
Then i noticed that tapping on the (serial) console made it unblock
for some frames, so i thought it doesn't prevent the cpu to go
idle/sleep. Using the boot arg nohlt the problem disappear and it
grabs at a steady 25fps.
In the code i found a comment that says the camera can't be a wakeup
source but the camera powerdomain is instead used to decide to not go
idle, so at this point i think the camera powerdomain is not enabled
but i don't know how/where to enable it. Any ideas?
I can confirm this indeed is the case --- ISP can't wake up the system ---
but don't know how to prevent the system from going to sleep when using
the
ISP.
Had it been on android i think wakelock would have been very useful.
I believe there are proper means to do this using more standard methods
as well. Not being a PM expert, I don't know how.
Cc Tero.
Hi,
I don't think there are proper means yet to do this, as camera is
somewhat a special case in omap3, it is apparently the only module that
is causing this kind of problem. However, you can prevent idle when
camera is active with something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2789e0a..7fdf6e2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -358,6 +358,9 @@ void omap_sram_idle(void)
omap3_per_save_context();
}
+ if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
+ clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
+
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
-Tero
i think something related is already in
arch/arm/mach-omap2/cpuidle34xx.c omap3_enter_idle_bm(...):
/*
* Prevent idle completely if CAM is active.
* CAM does not have wakeup capability in OMAP3.
*/
cam_state = pwrdm_read_pwrst(cam_pd);
if (cam_state == PWRDM_POWER_ON) {
new_state = dev-safe_state;
goto select_state;
}
But probably the power domain is not set to ON, and i don't know where
it should be set. Maybe, as Laurent suggested, adding runtime PM
support will fix it?
Thanks,
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: omap3isp as a wakeup source
On Tue, Sep 13, 2011 at 11:48 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-13 at 08:49 +0200, Sakari Ailus wrote:
anish singh wrote:
On Tue, Sep 13, 2011 at 1:58 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
On Mon, Sep 12, 2011 at 04:50:42PM +0200, Enrico wrote:
Hi,
Hi Enrico,
While testing omap3isp+tvp5150 with latest Deepthy bt656 patches
(kernel 3.1rc4) i noticed that yavta hangs very often when grabbing
or, if not hanged, it grabs at max ~10fps.
Then i noticed that tapping on the (serial) console made it unblock
for some frames, so i thought it doesn't prevent the cpu to go
idle/sleep. Using the boot arg nohlt the problem disappear and it
grabs at a steady 25fps.
In the code i found a comment that says the camera can't be a wakeup
source but the camera powerdomain is instead used to decide to not go
idle, so at this point i think the camera powerdomain is not enabled
but i don't know how/where to enable it. Any ideas?
I can confirm this indeed is the case --- ISP can't wake up the system ---
but don't know how to prevent the system from going to sleep when using
the
ISP.
Had it been on android i think wakelock would have been very useful.
I believe there are proper means to do this using more standard methods
as well. Not being a PM expert, I don't know how.
Cc Tero.
Hi,
I don't think there are proper means yet to do this, as camera is
somewhat a special case in omap3, it is apparently the only module that
is causing this kind of problem. However, you can prevent idle when
camera is active with something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2789e0a..7fdf6e2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -358,6 +358,9 @@ void omap_sram_idle(void)
omap3_per_save_context();
}
+ if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
+ clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
+
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
-Tero
One more thing: i just noticed that in Deepthy bt656 patches there is
one patch [1] to add cam regulators (1v8 and 2v8) to the omap3evm
board file, i'm not using an omap3evm but maybe i should add them to
my board file too?
Enrico
[1]: http://www.spinics.net/lists/linux-omap/msg56922.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
Re: omap3isp as a wakeup source
On Tue, Sep 13, 2011 at 12:29 PM, Tero Kristo t-kri...@ti.com wrote: Powerdomain is automatically on if there are any clocks enabled on it. If you make sure that ISP has some activity ongoing, then it should be on. You can check the state of the camera powerdomain from /sys/kernel/debug/pm_debug/count file, if you have mounted debugfs. And in fact something seems wrong (this is on a patched 3.0.4 kernel): usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:9,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (20) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) core_l4_clkdm-core_pwrdm (23) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) I think the line cam_clkdm-cam_pwrdm (0) means that it was never enabled, but i grabbed some frames with yavta before that. Anyone more into runtime PM that i can CC for suggestions? 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
