Re: [PATCH v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC)

2014-08-12 Thread thomas schorpp

Am 12.08.2014 um 08:25 schrieb anuroop.k...@gmail.com:

On Wednesday, August 14, 2013 11:14:15 PM UTC+5:30, Thomas Schorpp wrote:

OK, with the patched fex file and devices.c from

[linux-sunxi] [PATCH v2 1/1] [sunxi-boards/a20] Add support for Allwinner 
(DVB/ATSC) Transport Stream Controller(s) (TSC)

[PATCH v2 1/1] [stage/sunxi-3.4] sw_nand: sunxi devices core using wrong MMIO 
region range, overlaps TSC/TSI register base address 0x01c04000

and the driver patches from this topic here






the driver basically loads and inits:




please forgive me if my questions are wrong. I am fairly new to android  
Allwinner platform.


1. The tscdrv.c code (my linux-sunxi port, too) is (c) AW proprietary, You need 
to contact AW support (+ for a complete TSC Manual).

2. I've suspended my TSC project until a complete A20 TSC manual is available 
or I get the time for register probe rev. engineering.

3. https://groups.google.com/forum/#!topic/android-porting/EMAG4RUlOjI

Now we are planning to integrate a TV chip with this (DVB-T) . Allwinner has TS 
control block and a sample driver along with it.

Who is we?

I don't support Android OS platform, nor do we support closed source product 
developers from hidden proprietary products manufacturers
usually not releasing derivated works of GPL'd code back to us or the 
android-porting project with their products,
especially not for free. Please refer to the known consultant companies if Your company 
needs help.

Please, tell Your Boss there's a big difference between help and valuable 
expensive engineering project consulting, thank You.
Code maybe free under GPL (only the without warranty version) but consulting 
for it is not, and violating the GPL is breaking the law, worldwide.

This is the second request directly adressed to me off-list from a commercial 
company to work for free for them,
I will drop any further to the JUNK Mail folder without notice.



thanks a lot
Anuroop



thanks A LOT :-//
y
tom

--
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 v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC)

2014-08-12 Thread thomas schorpp

Am 12.08.2014 um 14:21 schrieb Mihail Tommonen:

Hi,

2. I've suspended my TSC project until a complete A20 TSC manual is

available or I get the time for register probe rev. engineering.



Have you seen this:
http://dl.linux-sunxi.org/A10/A10%20Transport%20Stream%20Controller%20V1.00%2020120917.pdf
I expect a20 tsc to be really similiart to a10.


Incomplete. Prove me wrong by getting a full TS without bypassing the TSC using 
the GPIO ports in other MUX mode directly, if possible (sig speed).



WBR

Miska



y
tom
--
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 v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC)

2013-08-14 Thread thomas schorpp

OK, with the patched fex file and devices.c from
[linux-sunxi] [PATCH v2 1/1] [sunxi-boards/a20] Add support for Allwinner 
(DVB/ATSC) Transport Stream Controller(s) (TSC)
[PATCH v2 1/1] [stage/sunxi-3.4] sw_nand: sunxi devices core using wrong MMIO 
region range, overlaps TSC/TSI register base address 0x01c04000
and the driver patches from this topic here

the driver basically loads and inits:

[  161.016837] [tsc-inf] tscdev_init: kmalloc memory, size: 0x212000
[  161.042378] [tsc-dbg] register_tsiomem: check_mem_region return: 0
[  161.055409] [tsc-dbg] register_tsiomem: devp-regsaddr: 0xf0104000

root@vdr2:~# cat /proc/iomem |grep -C 1 -i ts
01c03000-01c03fff : sw_nand
01c04000-01c04fff : ts regs
01c0a000-01c0afff : disp

root@vdr2:~# ls -l /dev/ts*
crw--- 1 root root 225, 0 Aug 14 19:10 /dev/tsc_dev

And ioctl() triggers the controller setup successfully.

root@vdr2:~# dd if=/dev/tsc_dev of=/dev/null bs=1K count=100 

[ 1064.861178] [tsc-inf] tscdev_open: ahb_ts clk rate: 0x1
[ 1064.871506] [tsc-inf] tscdev_open: parent clock rate 38400
[ 1064.881674] [tsc-inf] tscdev_open: clock rate 19200
[ 1064.891079] [tsc-inf] tscdev_open: clock rate 19200

Ready to build the Philips CU1216-MKIII TDA10023 DVB-C- Receiver recycling 
SMT extension board next days.
Others are invited to build boards with their receiver modules and extend 
driver Kconfig for more receivers, too.

Next i2c and frontend driver integration, if someone can do that faster, pls 
don't wait for me and pls CC linux-media list.

dvb_core integration after the hardware and driver PIO tests success.

Thanks for all the great community support :-)

y
tom

--
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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers

2013-02-12 Thread thomas schorpp

On 12.02.2013 22:20, Joe Perches wrote:

His email bounces and he hasn't done work on
these sections in a couple of years.

Signed-off-by: Joe Perches j...@perches.com
---
  MAINTAINERS | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1d0651e..8d47b3a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7523,7 +7523,6 @@ F:drivers/staging/comedi/

  STAGING - CRYSTAL HD VIDEO DECODER
  M:Naren Sankar nsan...@broadcom.com
-M: Jarod Wilson ja...@wilsonet.com
  M:Scott Davilla davi...@4pi.com
  M:Manu Abraham abraham.m...@gmail.com
  S:Odd Fixes
@@ -7557,9 +7556,8 @@ S:Odd Fixes
  F:drivers/staging/iio/



Not bouncing:

 - RCPT TO:ja...@redhat.com
-  250 2.0.0 r1D2CGt8016879 Message accepted for delivery
 - RCPT TO:davi...@4pi.com
-  250 OK id=1U5S5A-0001hr-O7
 - RCPT TO:nsan...@broadcom.com
-  250 OK - Data received

but noreply on 5+ tries, as for

ame...@debian.org (Broadcom crystalhd LGPL code repository @ Debian  Debian 
maintainer)

No reply to confirmed critical BUG with emergency patches in tracker:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699470
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682252
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=crystalhd

y
tom

--
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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers

2013-02-12 Thread thomas schorpp

On 13.02.2013 03:49, Joe Perches wrote:

On Wed, 2013-02-13 at 03:38 +0100, thomas schorpp wrote:

On 12.02.2013 22:20, Joe Perches wrote:

His email bounces and he hasn't done work on
these sections in a couple of years.

[]

diff --git a/MAINTAINERS b/MAINTAINERS

[]

-M: Jarod Wilson ja...@wilsonet.com



Not bouncing:

   - RCPT TO:ja...@redhat.com
-  250 2.0.0 r1D2CGt8016879 Message accepted for delivery


That's his redhat address, it doesn't bounce.

Try the ja...@wilsonet.com address
as shown above listed in MAINTAINERS.

Bounces for me.


Cant confirm:

wilsonet.com.   5602IN  MX  0 aspmx.l.google.com.
...

 - RCPT TO:ja...@wilsonet.com
-  250 2.0.0 OK 1360733211 g1si2865285eeo.229 - gsmtp

$ grep jarod /var/log/mail.log
$

perches.com mail is handled by 10 mx.perches.com.cust.hostedemail.com.
554 5.7.1 Service unavailable; Client host blocked using urbl.hostedemail.com

Maybe Your genious mailhoster blocks You too with https://www.senderscore.org 
for sending
to much linux spam with fake bounces or Google is blocking them with their 
own blocklist bullshit ;-)

y
tom

--
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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers

2013-02-12 Thread thomas schorpp

On 13.02.2013 06:15, VDR User wrote:

You can also try Jarod Wilson on freenode irc in #lirc. He is usually there.



What for? Bothering him with issues from blocklisting mailhosters' RFC 
violations?

y
tom

--
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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers

2013-02-12 Thread thomas schorpp

On 13.02.2013 06:54, thomas schorpp wrote:

On 13.02.2013 03:49, Joe Perches wrote:

...


Bounces for me.


Cant confirm:

wilsonet.com.5602INMX0 aspmx.l.google.com.
...

  - RCPT TO:ja...@wilsonet.com
-  250 2.0.0 OK 1360733211 g1si2865285eeo.229 - gsmtp

$ grep jarod /var/log/mail.log
$



Sorry, need some sleep soon, correction:

$ grep google /var/log/mail.log
$

But still no bounce.

y
tom



--
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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers

2013-02-12 Thread thomas schorpp

On 13.02.2013 07:15, thomas schorpp wrote:

On 13.02.2013 06:15, VDR User wrote:

You can also try Jarod Wilson on freenode irc in #lirc. He is usually there.



What for? Bothering him with issues from blocklisting mailhosters' RFC 
violations?

y
tom



Unbelievable, this blocklist bullshit .org 
https://www.senderscore.org/senderscore/

claims the reputation to teach others about reputation and blocking internet 
mailers

but their own crap mailserver cannot even handle TLS:


$ swaks -tls -t postmas...@senderscore.org -h xx -f 
=== Trying smtp.returnpath.net:25...
=== Connected to smtp.returnpath.net.
-  220 smtp.returnpath.net ESMTP Postfix
 - EHLO x
-  250-smtp.returnpath.net
...
*** Host did not advertise STARTTLS
 - QUIT
-  221 2.0.0 Bye
=== Connection closed with remote host.

Bah!

y
tom

--
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] crystalhd git.linuxtv.org kernel driver: Fix PM suspend broken by emergency patches

2013-02-08 Thread thomas schorpp

Fix PM suspend() broken by emergency patches, thanks to Philip Langdale for 
pointing out.

...But PM resume() didn't work anyway with the original code, always err 
invalid args.

Recommended workaround user space PM handling for ACPI S3:

/etc/pm/config.d/00suspend_modules:2:SUSPEND_MODULES=dvb_ttpci crystalhd

/etc/pm/sleep.d/92_crystalhd
#!/bin/sh

#SERVICES=crystalhd

#for service in $SERVICES; do
#services_reverse=$service $services_reverse
#done

case $1 in
hibernate|suspend)
;;
thaw|resume)
echo 1  /sys/devices/pci:00/:00:1c.1/:02:00.0/reset
#echo 1  /sys/devices/pci:00/:00:1c.1/:02:00.0/rescan
esac

and after malfunction with FW Command T/O, etc, crystalhd PCI-E device needs 
the reset up to 3x and module reload.

--

Patch attached.

crystalhd git.linuxtv.org kernel driver: Fix PM suspend broken by emergency 
patches

Signed-off-by: Thomas Schorpp thomas.scho...@gmail.com

y
tom


diff --git a/driver/linux/crystalhd_cmds.c b/driver/linux/crystalhd_cmds.c
index cecd710..cb6e65d 100644
--- a/driver/linux/crystalhd_cmds.c
+++ b/driver/linux/crystalhd_cmds.c
@@ -32,6 +32,11 @@ static struct crystalhd_user *bc_cproc_get_uid(struct crystalhd_cmd *ctx)
 	struct crystalhd_user *user = NULL;
 	int i;
 
+	if (!ctx) {
+		dev_err(chddev(), %s: Invalid Arg\n, __func__);
+		return user;
+	}
+
 	for (i = 0; i  BC_LINK_MAX_OPENS; i++) {
 		if (!ctx-user[i].in_use) {
 			user = ctx-user[i];
@@ -46,6 +51,11 @@ int bc_get_userhandle_count(struct crystalhd_cmd *ctx)
 {
 	int i, count = 0;
 
+	if (!ctx) {
+		dev_err(chddev(), %s: Invalid Arg\n, __func__);
+		return BC_STS_INV_ARG;
+	}
+
 	for (i = 0; i  BC_LINK_MAX_OPENS; i++) {
 		if (ctx-user[i].in_use)
 			count++;
@@ -154,7 +164,7 @@ static BC_STATUS bc_cproc_get_hwtype(struct crystalhd_cmd *ctx, crystalhd_ioctl_
 static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 	idata-udata.u.regAcc.Value = ctx-hw_ctx-pfnReadDevRegister(ctx-adp,
 	idata-udata.u.regAcc.Offset);
@@ -164,7 +174,7 @@ static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_reg_wr(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	ctx-hw_ctx-pfnWriteDevRegister(ctx-adp, idata-udata.u.regAcc.Offset,
@@ -176,7 +186,7 @@ static BC_STATUS bc_cproc_reg_wr(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_link_reg_rd(struct crystalhd_cmd *ctx,
   crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	idata-udata.u.regAcc.Value = ctx-hw_ctx-pfnReadFPGARegister(ctx-adp,
@@ -187,7 +197,7 @@ static BC_STATUS bc_cproc_link_reg_rd(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_link_reg_wr(struct crystalhd_cmd *ctx,
   crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	ctx-hw_ctx-pfnWriteFPGARegister(ctx-adp, idata-udata.u.regAcc.Offset,
@@ -201,7 +211,7 @@ static BC_STATUS bc_cproc_mem_rd(struct crystalhd_cmd *ctx,
 {
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata || !idata-add_cdata)
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata)
 		return BC_STS_INV_ARG;
 
 	if (idata-udata.u.devMem.NumDwords  (idata-add_cdata_sz / 4)) {
@@ -220,7 +230,7 @@ static BC_STATUS bc_cproc_mem_wr(struct crystalhd_cmd *ctx,
 {
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata || !idata-add_cdata)
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata)
 		return BC_STS_INV_ARG;
 
 	if (idata-udata.u.devMem.NumDwords  (idata-add_cdata_sz / 4)) {
@@ -307,7 +317,7 @@ static BC_STATUS bc_cproc_download_fw(struct crystalhd_cmd *ctx,
 
 	dev_dbg(chddev(), Downloading FW\n);
 
-	if (!ctx || !idata || !idata-add_cdata || !idata-add_cdata_sz) {
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata || !idata-add_cdata_sz) {
 		dev_err(chddev(), %s: Invalid Arg\n, __func__);
 		return BC_STS_INV_ARG;
 	}
@@ -350,7 +360,7 @@ static BC_STATUS bc_cproc_do_fw_cmd(struct crystalhd_cmd *ctx, crystalhd_ioctl_d
 	BC_STATUS sts;
 	uint32_t *cmd;
 
-	if (!(ctx-state  BC_LINK_INIT)) {
+	if ( !ctx || !idata || !(ctx-state  BC_LINK_INIT) || !ctx-hw_ctx) {
 		dev_dbg(dev, Link invalid state do fw cmd %x \n, ctx-state);
 		return BC_STS_ERR_USAGE;
 	}
@@ -395,7 +405,7 @@ static void bc_proc_in_completion(struct crystalhd_dio_req *dio_hnd,
 		return;
 	}
 	if (sts == BC_STS_IO_USER_ABORT || sts == BC_STS_PWR_MGMT)
-		 return;
+		return;
 
 	dio_hnd-uinfo.comp_sts = sts;
 	dio_hnd-uinfo.ev_sts = 1;
@@ -407,6 +417,9 @@ static BC_STATUS bc_cproc_codein_sleep(struct crystalhd_cmd *ctx)
 	wait_queue_head_t sleep_ev;
 	int rc = 0;
 
+	if (!ctx)
+		return BC_STS_INV_ARG;
+
 	if (ctx-state  BC_LINK_SUSPEND)
 		return BC_STS_PWR_MGMT

[PATCH] crystalhd git.linuxtv.org kernel driver: FIX kernel freeze or OOPS in ISRs

2013-02-04 Thread thomas schorpp

As expectable, the (unhandled?) false returns from the NULL pointer fixes may 
lead to kernel deadlock freezes and crashes in the ISRs.
Reproducing scenario: ctrl-c at capture startup, e.g.

Next try to fix it.

Future efforts should focus on the new kernel staging GPL driver.
--

Patch attached.

crystalhd git.linuxtv.org kernel driver: FIX kernel freeze or OOPS in ISRs

Signed-off-by: Thomas Schorpp thomas.scho...@gmail.com

y
tom

diff --git a/driver/linux/crystalhd_cmds.c b/driver/linux/crystalhd_cmds.c
index cecd710..ba743df 100644
--- a/driver/linux/crystalhd_cmds.c
+++ b/driver/linux/crystalhd_cmds.c
@@ -32,6 +32,11 @@ static struct crystalhd_user *bc_cproc_get_uid(struct crystalhd_cmd *ctx)
 	struct crystalhd_user *user = NULL;
 	int i;
 
+	if (!ctx) {
+		dev_err(chddev(), %s: Invalid Arg\n, __func__);
+		return user;
+	}
+
 	for (i = 0; i  BC_LINK_MAX_OPENS; i++) {
 		if (!ctx-user[i].in_use) {
 			user = ctx-user[i];
@@ -46,6 +51,11 @@ int bc_get_userhandle_count(struct crystalhd_cmd *ctx)
 {
 	int i, count = 0;
 
+	if (!ctx) {
+		dev_err(chddev(), %s: Invalid Arg\n, __func__);
+		return BC_STS_INV_ARG;
+	}
+
 	for (i = 0; i  BC_LINK_MAX_OPENS; i++) {
 		if (ctx-user[i].in_use)
 			count++;
@@ -154,7 +164,7 @@ static BC_STATUS bc_cproc_get_hwtype(struct crystalhd_cmd *ctx, crystalhd_ioctl_
 static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 	idata-udata.u.regAcc.Value = ctx-hw_ctx-pfnReadDevRegister(ctx-adp,
 	idata-udata.u.regAcc.Offset);
@@ -164,7 +174,7 @@ static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_reg_wr(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	ctx-hw_ctx-pfnWriteDevRegister(ctx-adp, idata-udata.u.regAcc.Offset,
@@ -176,7 +186,7 @@ static BC_STATUS bc_cproc_reg_wr(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_link_reg_rd(struct crystalhd_cmd *ctx,
   crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	idata-udata.u.regAcc.Value = ctx-hw_ctx-pfnReadFPGARegister(ctx-adp,
@@ -187,7 +197,7 @@ static BC_STATUS bc_cproc_link_reg_rd(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_link_reg_wr(struct crystalhd_cmd *ctx,
   crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	ctx-hw_ctx-pfnWriteFPGARegister(ctx-adp, idata-udata.u.regAcc.Offset,
@@ -201,7 +211,7 @@ static BC_STATUS bc_cproc_mem_rd(struct crystalhd_cmd *ctx,
 {
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata || !idata-add_cdata)
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata)
 		return BC_STS_INV_ARG;
 
 	if (idata-udata.u.devMem.NumDwords  (idata-add_cdata_sz / 4)) {
@@ -220,7 +230,7 @@ static BC_STATUS bc_cproc_mem_wr(struct crystalhd_cmd *ctx,
 {
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata || !idata-add_cdata)
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata)
 		return BC_STS_INV_ARG;
 
 	if (idata-udata.u.devMem.NumDwords  (idata-add_cdata_sz / 4)) {
@@ -307,7 +317,7 @@ static BC_STATUS bc_cproc_download_fw(struct crystalhd_cmd *ctx,
 
 	dev_dbg(chddev(), Downloading FW\n);
 
-	if (!ctx || !idata || !idata-add_cdata || !idata-add_cdata_sz) {
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata || !idata-add_cdata_sz) {
 		dev_err(chddev(), %s: Invalid Arg\n, __func__);
 		return BC_STS_INV_ARG;
 	}
@@ -350,7 +360,7 @@ static BC_STATUS bc_cproc_do_fw_cmd(struct crystalhd_cmd *ctx, crystalhd_ioctl_d
 	BC_STATUS sts;
 	uint32_t *cmd;
 
-	if (!(ctx-state  BC_LINK_INIT)) {
+	if ( !ctx || !idata || !(ctx-state  BC_LINK_INIT) || !ctx-hw_ctx) {
 		dev_dbg(dev, Link invalid state do fw cmd %x \n, ctx-state);
 		return BC_STS_ERR_USAGE;
 	}
@@ -395,7 +405,7 @@ static void bc_proc_in_completion(struct crystalhd_dio_req *dio_hnd,
 		return;
 	}
 	if (sts == BC_STS_IO_USER_ABORT || sts == BC_STS_PWR_MGMT)
-		 return;
+		return;
 
 	dio_hnd-uinfo.comp_sts = sts;
 	dio_hnd-uinfo.ev_sts = 1;
@@ -407,6 +417,9 @@ static BC_STATUS bc_cproc_codein_sleep(struct crystalhd_cmd *ctx)
 	wait_queue_head_t sleep_ev;
 	int rc = 0;
 
+	if (!ctx)
+		return BC_STS_INV_ARG;
+
 	if (ctx-state  BC_LINK_SUSPEND)
 		return BC_STS_PWR_MGMT;
 
@@ -432,7 +445,7 @@ static BC_STATUS bc_cproc_hw_txdma(struct crystalhd_cmd *ctx,
 	wait_queue_head_t event;
 	int rc = 0;
 
-	if (!ctx || !idata || !dio) {
+	if (!ctx || !ctx-hw_ctx || !idata || !dio) {
 		dev_err(dev, %s: Invalid Arg\n, __func__);
 		return BC_STS_INV_ARG;
 	}
@@ -573,7 +586,7 @@ static BC_STATUS bc_cproc_add_cap_buff(struct crystalhd_cmd *ctx,
 	struct crystalhd_dio_req *dio_hnd = NULL;
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata) {
+	if (!ctx || !ctx-hw_ctx || !idata) {
 		dev_err

[PATCH] crystalhd git.linuxtv.org kernel driver: FIX kernel unhandled paging request BUG triggered by multithreaded or faulty apps

2013-02-01 Thread thomas schorpp
,data: 0x0 0x880079ecf0c0 
0x880036e82c00
Feb  1 20:21:59 tom3 kernel: [ 1915.507970] crystalhd :03:00.0: 
bc_cproc_get_stats: Invalid Arg ctx,hw,data: 0x0 0x880079ecf0c0 
0x880036e82c00
...
Feb  1 20:22:00 tom3 kernel: [ 1915.589897] crystalhd :03:00.0: 
bc_cproc_get_stats: Invalid Arg ctx,hw,data: 0x0 0x880079ecf0c0 
0x880036e82c00
Feb  1 20:22:00 tom3 kernel: [ 1915.592526] crystalhd :03:00.0: 
bc_cproc_get_stats: Invalid Arg ctx,hw,data: 0x0 0x880079ecf0c0 
0x880036e82c00
Feb  1 20:22:00 tom3 kernel: [ 1915.594811] crystalhd :03:00.0: 
bc_cproc_get_stats: Invalid Arg ctx,hw,data: 0x0 0x880079ecf0c0 
0x880036e82c00
Feb  1 20:22:00 tom3 kernel: [ 1915.597345] crystalhd :03:00.0: 
bc_cproc_flush_cap_buffs: Invalid Arg
Feb  1 20:22:00 tom3 kernel: [ 1915.602438] crystalhd :03:00.0: Closing 
user[0] handle via ioctl with mode 1c200
Feb  1 20:22:00 tom3 kernel: [ 1915.602444] crystalhd_hw_stop_capture: Invalid 
Arguments
Feb  1 20:22:00 tom3 kernel: [ 1915.602448] crystalhd_hw_free_dma_rings: 
Invalid Arguments
Feb  1 20:22:00 tom3 kernel: [ 1915.602537] crystalhd_hw_close: Invalid 
Arguments
Feb  1 20:22:02 tom3 kernel: [ 1917.532285] matroskademux0:[6701]: segfault at 
7fbc69548018 ip 7fbc6ac044d2 sp 7fbc4f7fd080 error 6 in 
libpthread-2.11.3.so[7fbc6abf7000+17000]

is still not working but not crashing my kernel anymore. totem, ffmpeg, mplayer 
tests passed.
Since none of the maintainers nor Broadcom corp. care or agree on a common 
codebase, I've no motivation to fix

21372-Feb  1 18:39:52 tom3 kernel: [59854.079584] crystalhd :03:00.0: 
Opening new user[0] handle
21373-Feb  1 18:39:52 tom3 kernel: [59854.079607] crystalhd :03:00.0: 
Opening new user[0] handle

or any more.

Future efforts should focus on the new kernel staging GPL driver.
--

Patch attached.

crystalhd git.linuxtv.org kernel driver: FIX kernel unhandled paging request 
BUG triggered by multithreaded or faulty apps

Signed-off-by: Thomas Schorpp thomas.scho...@gmail.com

y
tom



diff --git a/driver/linux/crystalhd_cmds.c b/driver/linux/crystalhd_cmds.c
index cecd710..ba743df 100644
--- a/driver/linux/crystalhd_cmds.c
+++ b/driver/linux/crystalhd_cmds.c
@@ -32,6 +32,11 @@ static struct crystalhd_user *bc_cproc_get_uid(struct crystalhd_cmd *ctx)
 	struct crystalhd_user *user = NULL;
 	int i;
 
+	if (!ctx) {
+		dev_err(chddev(), %s: Invalid Arg\n, __func__);
+		return user;
+	}
+
 	for (i = 0; i  BC_LINK_MAX_OPENS; i++) {
 		if (!ctx-user[i].in_use) {
 			user = ctx-user[i];
@@ -46,6 +51,11 @@ int bc_get_userhandle_count(struct crystalhd_cmd *ctx)
 {
 	int i, count = 0;
 
+	if (!ctx) {
+		dev_err(chddev(), %s: Invalid Arg\n, __func__);
+		return BC_STS_INV_ARG;
+	}
+
 	for (i = 0; i  BC_LINK_MAX_OPENS; i++) {
 		if (ctx-user[i].in_use)
 			count++;
@@ -154,7 +164,7 @@ static BC_STATUS bc_cproc_get_hwtype(struct crystalhd_cmd *ctx, crystalhd_ioctl_
 static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 	idata-udata.u.regAcc.Value = ctx-hw_ctx-pfnReadDevRegister(ctx-adp,
 	idata-udata.u.regAcc.Offset);
@@ -164,7 +174,7 @@ static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_reg_wr(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	ctx-hw_ctx-pfnWriteDevRegister(ctx-adp, idata-udata.u.regAcc.Offset,
@@ -176,7 +186,7 @@ static BC_STATUS bc_cproc_reg_wr(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_link_reg_rd(struct crystalhd_cmd *ctx,
   crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	idata-udata.u.regAcc.Value = ctx-hw_ctx-pfnReadFPGARegister(ctx-adp,
@@ -187,7 +197,7 @@ static BC_STATUS bc_cproc_link_reg_rd(struct crystalhd_cmd *ctx,
 static BC_STATUS bc_cproc_link_reg_wr(struct crystalhd_cmd *ctx,
   crystalhd_ioctl_data *idata)
 {
-	if (!ctx || !idata)
+	if (!ctx || !ctx-hw_ctx || !idata)
 		return BC_STS_INV_ARG;
 
 	ctx-hw_ctx-pfnWriteFPGARegister(ctx-adp, idata-udata.u.regAcc.Offset,
@@ -201,7 +211,7 @@ static BC_STATUS bc_cproc_mem_rd(struct crystalhd_cmd *ctx,
 {
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata || !idata-add_cdata)
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata)
 		return BC_STS_INV_ARG;
 
 	if (idata-udata.u.devMem.NumDwords  (idata-add_cdata_sz / 4)) {
@@ -220,7 +230,7 @@ static BC_STATUS bc_cproc_mem_wr(struct crystalhd_cmd *ctx,
 {
 	BC_STATUS sts = BC_STS_SUCCESS;
 
-	if (!ctx || !idata || !idata-add_cdata)
+	if (!ctx || !ctx-hw_ctx || !idata || !idata-add_cdata)
 		return BC_STS_INV_ARG;
 
 	if (idata-udata.u.devMem.NumDwords  (idata-add_cdata_sz / 4)) {
@@ -307,7 +317,7 @@ static BC_STATUS bc_cproc_download_fw(struct crystalhd_cmd

[PATCH] crystalhd git.linuxtv.org kernel driver: FIX MORE null pointer BUGs triggered by multithreaded or faulty apps

2013-01-31 Thread thomas schorpp
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsDevRegisterRead: Ioctl failed: 1
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsGetDriveStats: Ioctl failed: 1
txThreadProc: Got status 1 from GetDriverStatus
DtsNotifyMode: Ioctl failed: 1
Notify Operating Mode Failed
DtsAllocIoctlData Error
Unable to detach from Dil shared memory ...
DtsDelDilShMem:Unable get shmid ...
Stream with high frequencies VQ coding
/usr/bin/transmageddon: Zeile 3:  6499 Speicherzugriffsfehler  python 
transmageddon.py
schorpp@tom3:~$

This is a quickdirty hack emergency critical bug fix only! May break other 
apps than totem, ffmpeg, mplayer, be warned!

--

Patch attached.

crystalhd git.linuxtv.org kernel driver: FIX MORE null pointer BUGs triggered 
by multithreaded or faulty apps

Signed-off-by: Thomas Schorpp thomas.scho...@gmail.com

y
tom


diff --git a/driver/linux/crystalhd_cmds.c b/driver/linux/crystalhd_cmds.c
index cecd710..b62811b 100644
--- a/driver/linux/crystalhd_cmds.c
+++ b/driver/linux/crystalhd_cmds.c
@@ -154,7 +154,7 @@ static BC_STATUS bc_cproc_get_hwtype(struct crystalhd_cmd *ctx, crystalhd_ioctl_
 static BC_STATUS bc_cproc_reg_rd(struct crystalhd_cmd *ctx,
  crystalhd_ioctl_data *idata

Re: [BUG] crystalhd git.linuxtv.org kernel driver: Crashing again Linux, 3.2, using mozilla flashplugin from adobe

2013-01-10 Thread thomas schorpp
:47 tom3 kernel: [122005.766014]  [a0465566] 
crystalhd_hw_get_cap_buffer+0x56/0x1a0 [crystalhd]
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [a046383d] 
bc_cproc_fetch_frame+0x8d/0x1b0 [crystalhd]
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [a0460db1] 
chd_dec_api_cmd+0x81/0x100 [crystalhd]
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [a0460ec0] 
chd_dec_ioctl+0x90/0x170 [crystalhd]
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [811704bc] 
do_vfs_ioctl+0x9c/0x330
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [8115ebb0] ? 
fget_light+0x40/0x140
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [8108d9bd] ? 
trace_hardirqs_on_caller+0x11d/0x1b0
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [8117079f] 
sys_ioctl+0x4f/0x80
Jan 11 01:37:47 tom3 kernel: [122005.766014]  [8149b6eb] 
system_call_fastpath+0x16/0x1b
Jan 11 01:37:47 tom3 kernel: [122005.766014] Code: 89 f7 e8 18 1d 03 e1 45 85 ed 75 
81 48 8b bd 78 ff ff ff e8 77 97 c1 e0 85 c0 0f 85 c7 00 00 00 4c 89 e7 e8 57 f3 ff 
ff 49 89 c0 f6 40 2c 03 0f 85 3d 01 00 00 48 8b 4d 80 48 8b 81 d0 00 00 00

Message from syslogd@tom3 at Jan 11 01:37:47 ...
 kernel:[122005.766014] Code: 89 f7 e8 18 1d 03 e1 45 85 ed 75 81 48 8b bd 78 ff ff 
ff e8 77 97 c1 e0 85 c0 0f 85 c7 00 00 00 4c 89 e7 e8 57 f3 ff ff 49 89 c0 f6 
40 2c 03 0f 85 3d 01 00 00 48 8b 4d 80 48 8b 81 d0 00 00 00
Jan 11 01:37:47 tom3 kernel: [122005.766014] RIP  [a046214c] 
crystalhd_dioq_fetch_wait+0x25c/0x410 [crystalhd]
Jan 11 01:37:47 tom3 kernel: [122005.766014]  RSP 880005ed3d48
Jan 11 01:37:47 tom3 kernel: [122005.766014] CR2: 002c

Message from syslogd@tom3 at Jan 11 01:37:47 ...
 kernel:[122005.766014] CR2: 002c
Jan 11 01:37:47 tom3 kernel: [122005.794469] ---[ end trace 09ed3619a23bee55 
]---



On 08.01.2013 00:33, thomas schorpp wrote:

Hi People,

-topic-

be careful using the bleeding edge stable kernel series  3.2 with this 
driver.

y
tom


On 05.01.2013 13:44, thomas schorpp wrote:

-Removed Broadcom kernel module authors pras...@broadcom.com, 
nsan...@broadcom.com from CC list, unreachable, see att. Trying listed official 
Press contact instead-

Hi Oliver,  hi crystalhd users and devs,  hello Broadcom Crystal HD staff,

1.
sorry for the delay, I had to upgrade my old debian i386 
stable...squeeze-backports userspace on the old core2duo machine to amd64 by 
full reinstall, otherwise the driver interface of libcrystalhd3 i686 to 
3.6.10...3.7.1amd64 SMP kernel.org kernels has failed permanently,

please (anyone still running such a setup or You) try to confirm this and 
report to this thread.

lspci still shows the same PCI-E errors (see my other posts to this list) with 
the working libcrystalhd3 amd64 and broadcom designed crystalhd driver now, so
this data reported from the chipset or lspci has to be considered faulty or 
stale and irelevant now, I will build the latest lspci from source to 
crosscheck this.


Please build ffmpeg rel. 1.0.1(non-MT version, not later version, git master 
showed up with an audio format bug, presenting wrong audio sample format as 
planar (sfltp, fltp, s16p) which bino cannot handle and makes mplayer cry for 
not having libavresample access but which is disabled by default in ffmpeg 
configure defaults and debian dmo source packages )
from Your distro source package with --disable-decoders='h264, h264_vdpau, 
h264_vda' and leave only h264_crystalhd need as h.264 decoder

and so trigger crystalhd by every app on your system accessing h.264 content 
for parsing or decoding and linked to libavcodec (check binaries with ldd if 
linked against this libavcodec54, , in libavcodec53 h264_crystalhd is flagged 
CAP_EXPERIMENTAL, which makes it unaccesible by other apps than the ffmpeg 
program (-strict -2), mplayer: -vc ffh264crystalhd, or will fail 
--disable-decoders='h264, h264_vdpau, h264_vda')  like mplayer (not statically 
linked), kaffeine, vlc, gnome nautilus media file properties (uses mplayer 
-identify) sequentially called and then in parallel and record and post the 
Ooopses in this thread here until the authors return from winter sports ;-)
Note for Bino users: System requirement is at least debian squeeze-backports X 
and DRI, otherwise bino will segfault the dri driver, i965 here and you need to 
build libGLEW(mx) 1.6 from source for debian stable systems, see 
http://savannah.nongnu.org/bugs/?33368 http://bino3d.org/help-wanted.html

2.
With the new amd64 userspace on 3.7.1 SMP PREEMPT kernel things got even more 
worse here now, got 5 kernel panics in IRQ handler of the crystalhd driver in 
1h while watching h.264 with
mplayer2/1 (single threaded decoding mode, stereo3d filter) resulting in system 
halting kernel crashes, I need to setup serial console debugging to get the 
logs, on my Pentium M i686 vdr machine, kernel has been able to continue at 
least after the null pointer oopses.
We need to have confirmation for this, too.

3.
Since

Re: global mutex in dvb_usercopy (dvbdev.c)

2013-01-10 Thread thomas schorpp

On 10.01.2013 15:25, Mauro Carvalho Chehab wrote:

Em Thu, 10 Jan 2013 03:06:51 +0100
thomas schorpp thomas.scho...@gmail.com escreveu:


On 09.01.2013 22:30, Nikolaus Schulz wrote:

On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote:

Hi Everyone,
  I have a doubt regarding about the global mutex lock in
dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) .


/* call driver */
mutex_lock(dvbdev_mutex);
if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD)
err = -EINVAL;
mutex_unlock(dvbdev_mutex);


Why is this mutex needed? When I check similar functions like
video_usercopy, this kind of global locking is not present when func()
is called.


I cannot say anything about video_usercopy(), but as it happens, there's
a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in
dvb_usercopy() with more fine-grained locking.

Nikolaus

[1] 
http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb


Unfortunately, frontend ioctls can be blocked by the frontend thread for several 
seconds; this leads to unacceptable lock contention.
Especially the stv0297 signal locking, as it turned out in situations of bad 
signal input or my cable providers outtage today it has slowed down dvb_ttpci 
(notable as OSD- output latency and possibly driver buffer overflows of budget 
source devices) that much that I had to disable tuning with parm --outputonly 
in vdr-plugin-dvbsddevice.

Can anyone confirm that and have a look at the other frontend drivers for 
tuners needing as much driver control?

I will try to apply the patch manually to Linux 3.2 and check with Latencytop 
tomorrow.


Well, an ioctl's should not block for a long time, if the device is opened
with O_NONBLOCK. Unfortunately, not all drivers follow this rule, and
blocks.

The right fix seem to have a logic at stv0297 that would do the signal
locking in background, or to use the already-existent DVB frontend
thread, and answering to userspace the last cached result, instead of
actively talking with the frontend device driver.

Both approaches have advantages and disadvantages. In any case, a change
like that at dvb core has the potential of causing troubles to userspace,
although I think it is the better thing to do, at the long term.


Could You or another with write access commit this in 
http://git.linuxtv.org/media_build.git if applicable, too, please?
I'look into but I'm not yet worked in in kernel threading methods, need to read 
the O'reilly linux Driver book first about ;-)

y
tom

--
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: global mutex in dvb_usercopy (dvbdev.c)

2013-01-09 Thread thomas schorpp

On 09.01.2013 22:30, Nikolaus Schulz wrote:

On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote:

Hi Everyone,
 I have a doubt regarding about the global mutex lock in
dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) .


/* call driver */
mutex_lock(dvbdev_mutex);
if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD)
err = -EINVAL;
mutex_unlock(dvbdev_mutex);


Why is this mutex needed? When I check similar functions like
video_usercopy, this kind of global locking is not present when func()
is called.


I cannot say anything about video_usercopy(), but as it happens, there's
a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in
dvb_usercopy() with more fine-grained locking.

Nikolaus

[1] 
http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb


Unfortunately, frontend ioctls can be blocked by the frontend thread for several 
seconds; this leads to unacceptable lock contention.
Especially the stv0297 signal locking, as it turned out in situations of bad 
signal input or my cable providers outtage today it has slowed down dvb_ttpci 
(notable as OSD- output latency and possibly driver buffer overflows of budget 
source devices) that much that I had to disable tuning with parm --outputonly 
in vdr-plugin-dvbsddevice.

Can anyone confirm that and have a look at the other frontend drivers for 
tuners needing as much driver control?

I will try to apply the patch manually to Linux 3.2 and check with Latencytop 
tomorrow.

y
tom





--
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: [BUG] crystalhd git.linuxtv.org kernel driver: No more Oops or kernel crashes with Linux 3.2

2013-01-07 Thread thomas schorpp

Hi People,

-topic-

be careful using the bleeding edge stable kernel series  3.2 with this 
driver.

y
tom


On 05.01.2013 13:44, thomas schorpp wrote:

-Removed Broadcom kernel module authors pras...@broadcom.com, 
nsan...@broadcom.com from CC list, unreachable, see att. Trying listed official 
Press contact instead-

Hi Oliver,  hi crystalhd users and devs,  hello Broadcom Crystal HD staff,

1.
sorry for the delay, I had to upgrade my old debian i386 
stable...squeeze-backports userspace on the old core2duo machine to amd64 by 
full reinstall, otherwise the driver interface of libcrystalhd3 i686 to 
3.6.10...3.7.1amd64 SMP kernel.org kernels has failed permanently,

please (anyone still running such a setup or You) try to confirm this and 
report to this thread.

lspci still shows the same PCI-E errors (see my other posts to this list) with 
the working libcrystalhd3 amd64 and broadcom designed crystalhd driver now, so
this data reported from the chipset or lspci has to be considered faulty or 
stale and irelevant now, I will build the latest lspci from source to 
crosscheck this.


Please build ffmpeg rel. 1.0.1(non-MT version, not later version, git master 
showed up with an audio format bug, presenting wrong audio sample format as 
planar (sfltp, fltp, s16p) which bino cannot handle and makes mplayer cry for 
not having libavresample access but which is disabled by default in ffmpeg 
configure defaults and debian dmo source packages )
from Your distro source package with --disable-decoders='h264, h264_vdpau, 
h264_vda' and leave only h264_crystalhd need as h.264 decoder

and so trigger crystalhd by every app on your system accessing h.264 content 
for parsing or decoding and linked to libavcodec (check binaries with ldd if 
linked against this libavcodec54, , in libavcodec53 h264_crystalhd is flagged 
CAP_EXPERIMENTAL, which makes it unaccesible by other apps than the ffmpeg 
program (-strict -2), mplayer: -vc ffh264crystalhd, or will fail 
--disable-decoders='h264, h264_vdpau, h264_vda')  like mplayer (not statically 
linked), kaffeine, vlc, gnome nautilus media file properties (uses mplayer 
-identify) sequentially called and then in parallel and record and post the 
Ooopses in this thread here until the authors return from winter sports ;-)
Note for Bino users: System requirement is at least debian squeeze-backports X 
and DRI, otherwise bino will segfault the dri driver, i965 here and you need to 
build libGLEW(mx) 1.6 from source for debian stable systems, see 
http://savannah.nongnu.org/bugs/?33368 http://bino3d.org/help-wanted.html

2.
With the new amd64 userspace on 3.7.1 SMP PREEMPT kernel things got even more 
worse here now, got 5 kernel panics in IRQ handler of the crystalhd driver in 
1h while watching h.264 with
mplayer2/1 (single threaded decoding mode, stereo3d filter) resulting in system 
halting kernel crashes, I need to setup serial console debugging to get the 
logs, on my Pentium M i686 vdr machine, kernel has been able to continue at 
least after the null pointer oopses.
We need to have confirmation for this, too.

3.
Since the source code still states broadcom staff as module authors and the 
download on the broadcom website is packaged broken tar.bz2 and does not build 
here with recent kernels,
I'm CC'ing them now, too, and because it's their basic driver skeleton design 
and the quality and performance of this driver is far below the windows driver, 
which performs h.264 1080 great with http://mpc-hc.sourceforge.net at 5-10% cpu 
usage even on xp x64 on a i965, this should be the reference development target.

4.
The driver Makefile won't compile it with debian squeeze-backports 3.2 and 3.2 
bpo kbuild infrastructure, missing helper scripts and includes, it needs a full 
ready build kernel from sources:

schorpp@tom3:/usr/local/src/crystalhd/driver/linux$ LC_ALL=C make
make -C /lib/modules/3.2.0-0.bpo.4-amd64/build 
SUBDIRS=/mnt/data/usr/local/src/crystalhd/driver/linux modules
make[1]: Entering directory 
`/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-amd64'
/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-common/Makefile:287: 
/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-common/scripts/Kbuild.include: 
Datei oder Verzeichnis nicht gefunden
/bin/bash: 
/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-common/scripts/gcc-x86_64-has-stack-protector.sh:
 Datei oder Verzeichnis nicht gefunden
/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-common/arch/x86/Makefile:81: 
stack protector enabled but no compiler support
/bin/bash: 
/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-common/scripts/gcc-goto.sh: Datei 
oder Verzeichnis nicht gefunden
make: *** Leerer Variablenname.  Schluss.
make[3]: *** [_module_/mnt/data/usr/local/src/crystalhd/driver/linux] Fehler 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/mnt/data/usr/src/linux-headers-3.2.0-0.bpo.4-amd64'
make: *** [all] Error 2
schorpp@tom3:/usr/local/src/crystalhd/driver/linux$

5.
I'm

Re: [BUG] crystalhd git.linuxtv.org kernel driver: unable to handle kernel paging requests, improper (spin)locking(?) and paging, null pointer oopses on SMP, libcrstalhd3-git i686 not interfacing to a

2013-01-05 Thread thomas schorpp
] 
bc_cproc_fetch_frame+0xbd/0x1b0 [crystalhd]
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [a03ccdab] 
chd_dec_api_cmd+0xab/0x100 [crystalhd]
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [a03ccf42] 
chd_dec_ioctl+0x142/0x160 [crystalhd]
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [81181d6a] 
do_vfs_ioctl+0x2da/0x310
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [8118d8f0] ? 
fget_light+0x70/0x160
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [81181df7] 
sys_ioctl+0x57/0x90
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [8123c79e] ? 
trace_hardirqs_on_thunk+0x3a/0x3f
Jan  4 20:43:38 tom3 kernel: [  779.891477]  [814de802] 
system_call_fastpath+0x16/0x1b
Jan  4 20:43:38 tom3 kernel: [  779.891477] Code: 87 10 e1 45 85 ed 0f 85 4f 01 00 00 
48 8b bd 78 ff ff ff e8 a3 e4 c9 e0 85 c0 0f 85 4e 01 00 00 4c 89 e7 e8 b3 f3 ff ff 
49 89 c0 f6 40 2c 03 0f 85 97 01 00 00 48 8b 4d 80 48 8b 81 d0 00 00 00
Jan  4 20:43:38 tom3 kernel: [  779.891477] RIP  [a03ce0a0] 
crystalhd_dioq_fetch_wait+0x210/0x3e0 [crystalhd]
Jan  4 20:43:38 tom3 kernel: [  779.891477]  RSP 88004a387d28
Jan  4 20:43:38 tom3 kernel: [  779.891477] CR2: 002c
Jan  4 20:43:38 tom3 kernel: [  779.912578] delay: estimated 384, actual 0
Jan  4 20:43:38 tom3 kernel: [  779.912610] delay: estimated 384, actual 48
Jan  4 20:43:38 tom3 kernel: [  779.914258] ---[ end trace b4d3d5bb1ad97fd7 ]---
Jan  4 20:46:05 tom3 kernel: [  926.565061] SysRq : Emergency Remount R/O


On 03.01.2013 16:17, Oliver Schinagl wrote:

I actually am one of the few that has one of those decoders so should be able 
to test things when needed. Just let me know what to test and I will try to 
comply

On 02-01-13 08:48, thomas schorpp wrote:

Hello guys,

I'm working on supporting BCM 970012/15 crystalhd decoder in userspace video/tv 
apps and

can't find where to report bugs of

http://git.linuxtv.org/jarod/crystalhd.git
devinheitmueller I think he just borrowed our git server.

So I borrow this list to get more developers, testers and sw- quality guys in.

Forgot to mention the attached Oopses under high load and multithreading in 
half automated stress/mass testing.

Scenario e.g.:
Dec 29 15:58:29 vdr1 kernel: [ 5698.364950] crystalhd :02:00.0: Opening new 
user[0] handle
Dec 29 15:58:30 vdr1 kernel: [ 5698.557932] crystalhd :02:00.0: Opening new 
user[0] handle
Dec 29 15:58:30 vdr1 kernel: [ 5698.846312] crystalhd :02:00.0: Close the 
handle first..

Looks like the driver is not threadsave, rebuilding kernel with spinlock 
debugging, should show more up.

y
tom

-Att: Kernel OOPS bt, etc

Dec 29 15:56:10 vdr1 kernel: [ 5558.568671] BUG: unable to handle kernel paging 
request at 2062696c
Dec 29 15:56:10 vdr1 kernel: [ 5558.568678] IP: [2062696c] 0x2062696b
Dec 29 15:56:10 vdr1 kernel: [ 5558.568681] *pdpt = 08497001 *pde = 

Dec 29 15:56:10 vdr1 kernel: [ 5558.568684] Oops: 0010 [#4] PREEMPT
Dec 29 15:56:10 vdr1 kernel: [ 5558.568731] Modules linked in: md5 crypto_hash 
cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep 
bluetooth crc16 binfmt_misc uinput fuse nfsd exportfs auth_rpcgss nfs_acl nfs 
lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit iptable_filter 
ip_tables af_packet ipv6 w83627ehf hwmon_vid hwmon uvcvideo isl6405 cryptomgr 
aead dvb_pll tda10086 saa7134_dvb tuner arc4 crypto_blkcipher crypto_algapi 
tda10021 snd_usb_audio snd_usbmidi_lib snd_hwdep rt73usb snd_pcm_oss rt2x00usb 
rt2x00lib stv0297 mac80211 snd_intel8x0 snd_ac97_codec snd_mixer_oss ac97_bus 
joydev snd_seq_dummy snd_pcm videobuf_dvb snd_seq_oss hid_sunplus hid_generic 
saa7134 videobuf2_vmalloc videobuf2_memops usbhid cfg80211 videobuf2_core 
snd_seq_midi hid snd_page_alloc snd_rawmidi budget_av dvb_ttpci crc_itu_t 
crypto budget_core saa7146_vv ttpci_eeprom saa7146 dvb_core
snd_seq_midi_eve
n
t tveeprom videobuf_dma_sg
Dec 29 15:56:10 vdr1 kernel: videobuf_core v4l2_common snd_seq rc_core videodev 
snd_seq_device crystalhd(O) snd_timer shpchp snd rng_core pci_hotplug serio_raw 
pcspkr i2c_i801 8250_pnp 8250 soundcore serial_core acpi_cpufreq mperf 
processor evdev ext3 mbcache jbd sg sr_mod sd_mod crc_t10dif cdrom ata_piix 
ahci libahci uhci_hcd libata ehci_hcd scsi_mod usbcore
Dec 29 15:56:10 vdr1 kernel: [ 5558.568770] Pid: 11841, comm: mplayer Tainted: 
G  DO 3.6.10-PM #8/Alviso
Dec 29 15:56:10 vdr1 kernel: [ 5558.568772] EIP: 0060:[2062696c] EFLAGS: 
00010286 CPU: 0
Dec 29 15:56:10 vdr1 kernel: [ 5558.568775] EIP is at 0x2062696c
Dec 29 15:56:10 vdr1 kernel: [ 5558.568777] EAX: 00370042 EBX: c843c000 ECX: 
636e3800 EDX: 1c10
Dec 29 15:56:10 vdr1 kernel: [ 5558.568778] ESI: 000238fc EDI: fb0068fc EBP: 
c842dea8 ESP: c842de74
Dec 29 15:56:10 vdr1 kernel: [ 5558.568780]  DS: 007b ES: 007b FS:  GS: 
0033 SS: 0068
Dec 29 15:56:10 vdr1 kernel: [ 5558.568781] CR0

[PATCH/RFC] crystalhd-video (vaapi-backend): struct VADriverVTable *vtable; is heap, updated to API 0.32, configure GLX support misdetection

2013-01-02 Thread thomas schorpp

Hi, I've found at http://gitorious.org/crystalhd-video palatis has started an 
vaapi backend for crystalhd and updated it to API rev. 0.32

but RFC #1, Applicable Linux Media API for Broadcom Crystal HD decoders:

I don't know yet if vaapi or vdpau is the right approach for a acceptable API 
for Broadcom crystal hd decoders, since it's a decoder (codec) not just an 
accelerator on such GPUs
and as I understand the little documentation so far, both APIs are X-Server 
rendering dependant but we've got many decoding only and framebuffer, 
transcoding and embedded
systems use cases around to which neither the vdpau nor the vaapi concepts 
would apply then and both API were useless for transcoders then?
Altough I don't know either yet if the Broadcom firmwares do allow faster than 
realtime movie framerate at all what transcoders usually need?
According to the ISO-OSI model, I would not mix or force decoding and/to X- 
Output in one API model and leave such (hw-) codecs in ffmpeg etc.

Fixes:

1. glx ext not detected by configure
crystalhd-video configuration summary:

VA-API version ... : 0.32.0
VA-API drivers path .. : /usr/lib/i386-linux-gnu/dri
CRYSTALHD version  : 3
GLX support .. : no --- ?

# dpkg -L libva-dev |grep -i glx
/usr/lib/i386-linux-gnu/pkgconfig/libva-glx.pc
/usr/include/va/va_glx.h
/usr/include/va/va_backend_glx.h
/usr/lib/i386-linux-gnu/libva-glx.so

Debug? ... : yes
Tracer? .. : yes

2. struct VADriverVTable *vtable; is heap, not stack allocateable in API 0.32, 
patch attached.

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -std=c99 -g -O2 -D__LINUX_USER__ -MT 
crystalhd_drv_video.lo -MD -MP -MF .deps/crystalhd_drv_video.Tpo -c 
crystalhd_drv_video.c  -fPIC -DPIC -o .libs/crystalhd_drv_video.o
crystalhd_drv_video.c: In function '__vaDriverInit_0_31':
crystalhd_drv_video.c:1851:13: error: request for member 'vaTerminate' in 
something not a structure or union
...
crystalhd_drv_video.c:1894:13: error: request for member 'vaBufferInfo' in 
something not a structure or union
make[2]: *** [crystalhd_drv_video.lo] Fehler 1

3. test results:

init: vainfo:

Running DIL (3.22.0) Version
DtsDeviceOpen: Opening HW in mode 0
Clock set to 180
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Broadcom Crystal HD Video Decoder 3.10.0.0
vainfo: Supported profile and entrypoints
   VAProfileMPEG2Simple:VAEntrypointVLD
   VAProfileMPEG2Simple:VAEntrypointMoComp
   VAProfileMPEG2Main  :VAEntrypointVLD
   VAProfileMPEG2Main  :VAEntrypointMoComp
   VAProfileH264Baseline   :VAEntrypointVLD
   VAProfileH264Main   :VAEntrypointVLD
   VAProfileH264High   :VAEntrypointVLD
DtsAllocIoctlData Error

Manually linked to my GPU chipset name
ln -s /usr/lib/i386-linux-gnu/dri/crystalhd_drv_video.so 
/usr/lib/i386-linux-gnu/dri/i915_drv_video.so
but nothing is accessing it it seems.

y
tom

-Att: patch against http://gitorious.org/crystalhd-video git master,HEAD at the 
timestamp of file.



diff --git a/extra/crystalhd_wrapper/crystalhd_common.c b/extra/crystalhd_wrapper/crystalhd_common.c
index c26d5a5..e0c7eb0 100644
--- a/extra/crystalhd_wrapper/crystalhd_common.c
+++ b/extra/crystalhd_wrapper/crystalhd_common.c
@@ -48,7 +48,7 @@ const char *string_of_BC_STATUS(BC_STATUS status)
 		STATUS(CERT_VERIFY_ERROR);
 		STATUS(DEC_EXIST_OPEN);
 		STATUS(PENDING);
-		STATUS(CLK_NOCHG);
+//		STATUS(CLK_NOCHG);
 		STATUS(ERROR);
 #undef STATUS
 	}
diff --git a/src/crystalhd_drv_video.c b/src/crystalhd_drv_video.c
index 5fbae33..8f99f6a 100644
--- a/src/crystalhd_drv_video.c
+++ b/src/crystalhd_drv_video.c
@@ -1828,7 +1828,7 @@ crystalhd_Terminate(
 }
 
 VAStatus
-__vaDriverInit_0_31(
+__vaDriverInit_0_32(
 		VADriverContextP ctx
 	)
 {
@@ -1848,50 +1848,50 @@ __vaDriverInit_0_31(
 	ctx-max_display_attributes = CRYSTALHD_MAX_DISPLAY_ATTRIBUTES;
 	ctx-str_vendor = CRYSTALHD_STR_VENDOR;
 
-	ctx-vtable.vaTerminate = crystalhd_Terminate;
-	ctx-vtable.vaQueryConfigEntrypoints = crystalhd_QueryConfigEntrypoints;
-	ctx-vtable.vaQueryConfigProfiles = crystalhd_QueryConfigProfiles;
-	ctx-vtable.vaQueryConfigEntrypoints = crystalhd_QueryConfigEntrypoints;
-	ctx-vtable.vaQueryConfigAttributes = crystalhd_QueryConfigAttributes;
-	ctx-vtable.vaCreateConfig = crystalhd_CreateConfig;
-	ctx-vtable.vaDestroyConfig = crystalhd_DestroyConfig;
-	ctx-vtable.vaGetConfigAttributes = crystalhd_GetConfigAttributes;
-	ctx-vtable.vaCreateSurfaces = crystalhd_CreateSurfaces;
-	ctx-vtable.vaDestroySurfaces = crystalhd_DestroySurfaces;
-	ctx-vtable.vaCreateContext = crystalhd_CreateContext;
-	ctx-vtable.vaDestroyContext = crystalhd_DestroyContext;
-	ctx-vtable.vaCreateBuffer = crystalhd_CreateBuffer;
-	ctx-vtable.vaBufferSetNumElements = crystalhd_BufferSetNumElements;
-	

[PATCH] crystalhd git.linuxtv.org kernel driver: crystalhd BC (not staging) driver-, examples-, section mismatch-. udev- fixes. v3.10.1

2013-01-01 Thread thomas schorpp

Hello guys,

I'm working on supporting BCM 970012/15 crystalhd decoder and
can't find where to report bugs of
http://git.linuxtv.org/jarod/crystalhd.git
devinheitmueller I think he just borrowed our git server.

and send patches.

So I borrow this list to get more developers, testers and sw- quality guys in 
until the maintainers in CC say where the right place is.

Patch for crystalhd 3.10.1 attached.

y
tom

-Att: Statuslogs, still no go on x86_64 kernel with x86_32 userspace, PCI-E 
errors with 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI 
Express Port 1 (rev 03):


Jan  2 00:00:55 tom3 kernel: [ 5910.428529] Unloading crystalhd 3.10.0
Jan  2 00:00:55 tom3 kernel: [ 5910.429683] crystalhd :03:00.0: released 
api device - 250
Jan  2 00:01:00 tom3 kernel: [ 5914.673159] Loading crystalhd v3.10.1
Jan  2 00:01:00 tom3 kernel: [ 5914.673334] crystalhd :03:00.0: Starting 
Device:0x1612
Jan  2 00:01:00 tom3 kernel: [ 5914.677823] crystalhd :03:00.0: irq 52 for 
MSI/MSI-X
Jan  2 00:01:00 tom3 kernel: [ 5914.932221] crystalhd :03:00.0: enabling 
bus mastering
Jan  2 00:01:12 tom3 kernel: [ 5927.335471] crystalhd :03:00.0: Opening new 
user[0] handle
Jan  2 00:01:13 tom3 kernel: [ 5927.683262] crystalhd :03:00.0: Closing 
user[0] handle with mode 

# hellobcm
starting up
Running DIL (3.22.0) Version
DtsDeviceOpen: Opening HW in mode 0
IOCTL Command Failed -1 cmd c2186201 sts 0
DtsGetHwType: Ioctl failed: -1
Get Hardware Type Failed
IOCTL Command Failed -1 cmd c2186211 sts 0
DtsGetDriveStats: Ioctl failed: -1
txThreadProc: Got status -1 from GetDriverStatus
IOCTL Command Failed -1 cmd c2186210 sts 0
DtsAllocIoctlData Error
IOCTL Command Failed -1 cmd c2186214 sts 0
DtsReleaseUserHandle: Ioctl failed: -1
Unable to detach from Dil shared memory ...
DtsDelDilShMem:Unable get shmid ...
crap, DtsDeviceOpen failed
Failed to open device

# lspci -vvvnnn -s 03:00.0
03:00.0 Multimedia controller [0480]: Broadcom Corporation BCM70012 Video 
Decoder [Crystal HD] [14e4:1612] (rev 01)
Subsystem: Broadcom Corporation Device [14e4:2612]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR+ PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 52
Region 0: Memory at deff (64-bit, non-prefetchable) [size=64K]
Region 2: Memory at df00 (64-bit, non-prefetchable) [size=4M]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [60] Vendor Specific Information: Len=6c ?
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0300c  Data: 4183
Capabilities: [cc] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, 
L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 
4us, L1 64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed 

[BUG] crystalhd git.linuxtv.org kernel driver: unable to handle kernel paging requests, improper (spin)locking(?) and paging

2013-01-01 Thread thomas schorpp

Hello guys,

I'm working on supporting BCM 970012/15 crystalhd decoder in userspace video/tv 
apps and

can't find where to report bugs of

http://git.linuxtv.org/jarod/crystalhd.git
devinheitmueller I think he just borrowed our git server.

So I borrow this list to get more developers, testers and sw- quality guys in.

Forgot to mention the attached Oopses under high load and multithreading in 
half automated stress/mass testing.

Scenario e.g.:
Dec 29 15:58:29 vdr1 kernel: [ 5698.364950] crystalhd :02:00.0: Opening new 
user[0] handle
Dec 29 15:58:30 vdr1 kernel: [ 5698.557932] crystalhd :02:00.0: Opening new 
user[0] handle
Dec 29 15:58:30 vdr1 kernel: [ 5698.846312] crystalhd :02:00.0: Close the 
handle first..

Looks like the driver is not threadsave, rebuilding kernel with spinlock 
debugging, should show more up.

y
tom

-Att: Kernel OOPS bt, etc

Dec 29 15:56:10 vdr1 kernel: [ 5558.568671] BUG: unable to handle kernel paging 
request at 2062696c
Dec 29 15:56:10 vdr1 kernel: [ 5558.568678] IP: [2062696c] 0x2062696b
Dec 29 15:56:10 vdr1 kernel: [ 5558.568681] *pdpt = 08497001 *pde = 

Dec 29 15:56:10 vdr1 kernel: [ 5558.568684] Oops: 0010 [#4] PREEMPT
Dec 29 15:56:10 vdr1 kernel: [ 5558.568731] Modules linked in: md5 crypto_hash 
cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep 
bluetooth crc16 binfmt_misc uinput fuse nfsd exportfs auth_rpcgss nfs_acl nfs 
lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit iptable_filter 
ip_tables af_packet ipv6 w83627ehf hwmon_vid hwmon uvcvideo isl6405 cryptomgr 
aead dvb_pll tda10086 saa7134_dvb tuner arc4 crypto_blkcipher crypto_algapi 
tda10021 snd_usb_audio snd_usbmidi_lib snd_hwdep rt73usb snd_pcm_oss rt2x00usb 
rt2x00lib stv0297 mac80211 snd_intel8x0 snd_ac97_codec snd_mixer_oss ac97_bus 
joydev snd_seq_dummy snd_pcm videobuf_dvb snd_seq_oss hid_sunplus hid_generic 
saa7134 videobuf2_vmalloc videobuf2_memops usbhid cfg80211 videobuf2_core 
snd_seq_midi hid snd_page_alloc snd_rawmidi budget_av dvb_ttpci crc_itu_t 
crypto budget_core saa7146_vv ttpci_eeprom saa7146 dvb_core snd_seq_midi_even
t tveeprom videobuf_dma_sg
Dec 29 15:56:10 vdr1 kernel: videobuf_core v4l2_common snd_seq rc_core videodev 
snd_seq_device crystalhd(O) snd_timer shpchp snd rng_core pci_hotplug serio_raw 
pcspkr i2c_i801 8250_pnp 8250 soundcore serial_core acpi_cpufreq mperf 
processor evdev ext3 mbcache jbd sg sr_mod sd_mod crc_t10dif cdrom ata_piix 
ahci libahci uhci_hcd libata ehci_hcd scsi_mod usbcore
Dec 29 15:56:10 vdr1 kernel: [ 5558.568770] Pid: 11841, comm: mplayer Tainted: 
G  DO 3.6.10-PM #8/Alviso
Dec 29 15:56:10 vdr1 kernel: [ 5558.568772] EIP: 0060:[2062696c] EFLAGS: 
00010286 CPU: 0
Dec 29 15:56:10 vdr1 kernel: [ 5558.568775] EIP is at 0x2062696c
Dec 29 15:56:10 vdr1 kernel: [ 5558.568777] EAX: 00370042 EBX: c843c000 ECX: 
636e3800 EDX: 1c10
Dec 29 15:56:10 vdr1 kernel: [ 5558.568778] ESI: 000238fc EDI: fb0068fc EBP: 
c842dea8 ESP: c842de74
Dec 29 15:56:10 vdr1 kernel: [ 5558.568780]  DS: 007b ES: 007b FS:  GS: 
0033 SS: 0068
Dec 29 15:56:10 vdr1 kernel: [ 5558.568781] CR0: 8005003b CR2: 2062696c CR3: 
084d9000 CR4: 07f0
Dec 29 15:56:10 vdr1 kernel: [ 5558.568783] DR0:  DR1:  DR2: 
 DR3: 
Dec 29 15:56:10 vdr1 kernel: [ 5558.568784] DR6: 0ff0 DR7: 0400
Dec 29 15:56:10 vdr1 kernel: [ 5558.568786] Process mplayer (pid: 11841, 
ti=c842c000 task=f0aba940 task.ti=c842c000)
Dec 29 15:56:10 vdr1 kernel: [ 5558.568787] Stack:
Dec 29 15:56:10 vdr1 kernel: [ 5558.568793]  fa18a569 ff10 c117e3f6 
0060 00010246 002a8464 f7138064 fafe3000
Dec 29 15:56:10 vdr1 kernel: [ 5558.568798]  002a8440 c117e811 f5920988 
fafe3000 c843c000 c842ded8 fa18564d c842ded8
Dec 29 15:56:10 vdr1 kernel: [ 5558.568803]  fa182597 f595a400 f595a62c 
c842ded8 fa182977 002a8464 f5920900 f595a400
Dec 29 15:56:10 vdr1 kernel: [ 5558.568804] Call Trace:
Dec 29 15:56:10 vdr1 kernel: [ 5558.568818]  [fa18a569] ? 
crystalhd_link_download_fw+0x189/0x300 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568823]  [c117e3f6] ? 
__copy_from_user_ll+0xd6/0xf0
Dec 29 15:56:10 vdr1 kernel: [ 5558.568828]  [c117e811] ? 
_copy_from_user+0x41/0xb0
Dec 29 15:56:10 vdr1 kernel: [ 5558.568839]  [fa18564d] 
bc_cproc_download_fw+0xed/0x150 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568846]  [fa182597] ? 
chd_dec_proc_user_data+0x237/0x320 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568854]  [fa182977] ? 
chd_dec_alloc_iodata+0xf7/0x120 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568861]  [fa182b5e] 
chd_dec_ioctl+0x16e/0x1c0 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568870]  [fa185560] ? 
bc_proc_in_completion+0x70/0x70 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568877]  [fa1829f0] ? 
chd_dec_free_iodata+0x50/0x50 [crystalhd]
Dec 29 15:56:10 vdr1 kernel: [ 5558.568881]  [c10f4355] 

[BUG] crystalhd git.linuxtv.org kernel driver: NULL pointer deref in crystalhd_dioq_fetch_wait() while playing SBS 3D h.264 in mplayer2

2012-12-28 Thread thomas schorpp

Hello guys,

I'm working on supporting BCM 970012/15 crystalhd decoder in userspace video/tv 
apps and

can't find where to report bugs of

http://git.linuxtv.org/jarod/crystalhd.git
devinheitmueller I think he just borrowed our git server.

So I borrow this list to get more developers, testers and sw- quality guys in.

Got another null pointer deref OOPS in crystalhd_dioq_fetch_wait after 
chd_dec_free_iodata while playing 3D SBS with -vf stereo3d=sbsl:agmc using 
crystalhd driver on
debian wheezy
Linux vdr1 3.6.10-PM #8 PREEMPT Sat Dec 15 00:54:11 CET 2012 i686 GNU/Linux
crystalhd driver+lib, libavcodec crystalhd.c git HEAD but libavcodec53

System not crashed but this issue needs rmmod -f and modprobe /-r again 
otherwise crash on access, see bt #2 below.

And there's something strange: Why is pulseaudio loading libcrystalhd.so , see 
lsof output end of logs below.

Note: I've disabled the legacy h264 software codec in libavcodec53 to force 
every app using h264_crystalhd for h.264 with
my backport patch -Attached- from ffmpeg git HEAD of yesterday to 
libavcodec.so.53.61.100 , debian src ffmpeg 7:0.10.3-dmo1 0
using
./configure ... --disable-decoder='h264,h264_vdpau,h264_vda'
to automate testing of (lib)crystalhd(.ko) with all apps requesting libavcodec 
h.264 ;-)
Don't worry, I've left the childlock in the patch to not get this patch in 
any distro.

y
tom

-Att: Backport patch for crystalhd.c using in libavcodec53
-Att: Kernel OOPS bt, etc

Dec 29 03:45:48 vdr1 kernel: [21380.312142] crystalhd :02:00.0: 
list_index:0 rx[631] rxtot[65358] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:45:48 vdr1 kernel: [21380.345357] crystalhd :02:00.0: MISSING 2 
PICTURES
Dec 29 03:45:57 vdr1 kernel: [21389.239365] crystalhd :02:00.0: 
list_index:1 rx[632] rxtot[65907] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0
Dec 29 03:45:57 vdr1 kernel: [21389.299893] crystalhd :02:00.0: 
list_index:0 rx[633] rxtot[65910] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:45:58 vdr1 kernel: [21390.298013] crystalhd :02:00.0: 
list_index:1 rx[634] rxtot[65971] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0
Dec 29 03:45:59 vdr1 kernel: [21391.287414] crystalhd :02:00.0: 
list_index:0 rx[635] rxtot[66032] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:46:03 vdr1 kernel: [21395.291567] crystalhd :02:00.0: 
list_index:0 rx[636] rxtot[66278] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:46:04 vdr1 kernel: [21396.298724] crystalhd :02:00.0: 
list_index:0 rx[637] rxtot[66340] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:46:06 vdr1 kernel: [21398.262450] crystalhd :02:00.0: 
list_index:1 rx[638] rxtot[66461] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0
Dec 29 03:46:09 vdr1 kernel: [21400.767268] crystalhd :02:00.0: 
list_index:1 rx[639] rxtot[66615] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0
Dec 29 03:46:11 vdr1 kernel: [21403.254963] crystalhd :02:00.0: 
list_index:0 rx[640] rxtot[66768] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:46:13 vdr1 kernel: [21405.292398] crystalhd :02:00.0: 
list_index:1 rx[641] rxtot[66893] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0
Dec 29 03:46:14 vdr1 kernel: [21406.288434] crystalhd :02:00.0: 
list_index:0 rx[642] rxtot[66954] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0
Dec 29 03:46:15 vdr1 kernel: [21406.782372] BUG: unable to handle kernel NULL 
pointer dereference at 0018
Dec 29 03:46:15 vdr1 kernel: [21406.782876] IP: [fa46e8cc] 
crystalhd_dioq_fetch_wait+0x19c/0x330 [crystalhd]
Dec 29 03:46:15 vdr1 kernel: [21406.783173] *pdpt = 2f95e001 *pde = 

Dec 29 03:46:15 vdr1 kernel: [21406.783173] Oops:  [#1] PREEMPT
Dec 29 03:46:15 vdr1 kernel: [21406.783173] Modules linked in: md5 crypto_hash 
cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep 
bluetooth crc16 binfmt_misc uinput fuse nfsd exportfs auth_rpcgss nfs_acl nfs 
lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit iptable_filter 
ip_tables af_packet ipv6 w83627ehf hwmon_vid hwmon isl6405 uvcvideo dvb_pll 
tda10086 saa7134_dvb videobuf_dvb tuner tda10021 cryptomgr aead arc4 
crypto_blkcipher crypto_algapi snd_usb_audio stv0297 snd_usbmidi_lib 
snd_intel8x0 snd_ac97_codec ac97_bus rt73usb rt2x00usb rt2x00lib snd_hwdep 
snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi snd_pcm_oss snd_mixer_oss 
joydev snd_pcm snd_rawmidi saa7134 hid_sunplus hid_generic snd_seq_midi_event 
videobuf2_vmalloc videobuf2_memops budget_av videobuf2_core cfg80211 usbhid hid 
snd_page_alloc snd_seq dvb_ttpci saa7146_vv budget_core crc_itu_t ttpci_eeprom 
crypto saa7146
dvb_core tveeprom videobu
Dec 29 03:46:15 vdr1 kernel: f_dma_sg videobuf_core v4l2_common snd_seq_device 
snd_timer crystalhd(O) videodev snd rc_core shpchp i2c_i801 pci_hotplug 
serio_raw pcspkr rng_core soundcore 8250_pnp 8250 serial_core acpi_cpufreq 
mperf processor evdev ext3 mbcache jbd sg sr_mod sd_mod cdrom crc_t10dif 
ata_piix ahci libahci libata scsi_mod uhci_hcd ehci_hcd usbcore
Dec 29 

[BUG] crystalhd git.linuxtv.org kernel driver: NULL pointer deref in bc_cproc_reset_stats() after crashing bino3d

2012-12-28 Thread thomas schorpp

Hello guys,

I'm working on supporting BCM 970012/15 crystalhd decoder in userspace video/tv 
apps and

can't find where to report bugs of

http://git.linuxtv.org/jarod/crystalhd.git
devinheitmueller I think he just borrowed our git server.

So I borrow this list to get more developers, testers and sw- quality guys in.

Got a double free null pointer deref OOPS in chd_dec_free_iodata on crashing 
bino3d using crystalhd driver on
debian wheezy
Linux vdr1 3.6.10-PM #8 PREEMPT Sat Dec 15 00:54:11 CET 2012 i686 GNU/Linux
crystalhd driver+lib, libavcodec crystalhd.c git HEAD but libavcodec53

reproducible and only occuring after
Dec 27 12:12:17 vdr1 kernel: [33147.169731] crystalhd_hw_stats: Invalid 
Arguments
log message.

System not crashing, driver still usable.

Note: I've disabled the legacy h264 software codec in libavcodec53 to force 
every app using h264_crystalhd for h.264 with
my backport patch -Attached- from ffmpeg git HEAD of yesterday to 
libavcodec.so.53.61.100 , debian src ffmpeg 7:0.10.3-dmo1 0
using
./configure ... --disable-decoder='h264,h264_vdpau,h264_vda'
to automate testing of (lib)crystalhd(.ko) with all apps requesting libavcodec 
h.264 ;-)
Don't worry, I've left the childlock in the patch to not get this patch in 
any distro.

y
tom

-Att: Kernel OOPS bt, etc

Dec 27 12:11:57 vdr1 kernel: [33127.022053] crystalhd :02:00.0: Opening new 
user[0] handle
Dec 27 12:12:00 vdr1 kernel: [33129.862089] start_capture: pause_th:12, 
resume_th:5
Dec 27 12:12:00 vdr1 kernel: [33130.273355] crystalhd :02:00.0: Closing 
user[0] handle via ioctl with mode 1417200
Dec 27 12:12:00 vdr1 kernel: [33130.589582] crystalhd :02:00.0: Opening new 
user[0] handle
Dec 27 12:12:03 vdr1 kernel: [33133.464029] start_capture: pause_th:12, 
resume_th:5
Dec 27 12:12:17 vdr1 kernel: [33146.856414] crystalhd :02:00.0: Closing 
user[0] handle with mode 1417200
Dec 27 12:12:17 vdr1 kernel: [33147.169731] crystalhd_hw_stats: Invalid 
Arguments
Dec 27 12:12:17 vdr1 kernel: [33147.169778] BUG: unable to handle kernel NULL 
pointer dereference at 0040
Dec 27 12:12:17 vdr1 kernel: [33147.170259] IP: [c11848d8] 
do_raw_spin_trylock+0x8/0x50
Dec 27 12:12:17 vdr1 kernel: [33147.170621] *pdpt = 2b9cb001 *pde = 

Dec 27 12:12:17 vdr1 kernel: [33147.170622] Oops:  [#1] PREEMPT
Dec 27 12:12:17 vdr1 kernel: [33147.170622] Modules linked in: dvb_ttpci md5 
crypto_hash cpufreq_stats cpufreq_powersave cpufreq_userspace 
cpufreq_conservative bnep rfcomm bluetooth crc16 binfmt_misc uinput fuse nfsd 
exportfs auth_rpcgss nfs_acl nfs lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 
ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state 
nf_conntrack xt_limit iptable_filter ip_tables af_packet ipv6 w83627ehf 
hwmon_vid hwmon uvcvideo isl6405 dvb_pll tda10086 saa7134_dvb tuner 
videobuf_dvb tda10021 saa7134 stv0297 snd_usb_audio cryptomgr aead arc4 
crypto_blkcipher crypto_algapi snd_usbmidi_lib snd_hwdep rt73usb rt2x00usb 
rt2x00lib snd_pcm_oss budget_av snd_intel8x0 saa7146_vv budget_core 
ttpci_eeprom snd_ac97_codec saa7146 mac80211 ac97_bus snd_mixer_oss 
snd_seq_dummy snd_pcm snd_seq_oss cfg80211 dvb_core tveeprom videobuf2_vmalloc 
videobuf2_memops videobuf_dma_sg videobuf2_core snd_page_alloc snd_seq_midi 
joydev videobuf_core v4l2_common crc_itu_t crypto snd_ra

wmidi videodev snd_seq_mid
Dec 27 12:12:17 vdr1 kernel: i_event snd_seq rc_core shpchp snd_seq_device 
snd_timer snd serio_raw i2c_i801 pcspkr pci_hotplug rng_core crystalhd(O) 
8250_pnp soundcore 8250 serial_core acpi_cpufreq mperf processor evdev ext3 
mbcache jbd sg sr_mod sd_mod cdrom crc_t10dif hid_generic hid_sunplus usbhid 
hid ata_piix ahci libahci uhci_hcd ehci_hcd libata scsi_mod usbcore [last 
unloaded: dvb_ttpci]
Dec 27 12:12:17 vdr1 kernel: [33147.170622] Pid: 23337, comm: bino Tainted: G   
O 3.6.10-PM #8/Alviso
Dec 27 12:12:17 vdr1 kernel: [33147.170622] EIP: 0060:[c11848d8] EFLAGS: 
00210046 CPU: 0
Dec 27 12:12:17 vdr1 kernel: [33147.170622] EIP is at 
do_raw_spin_trylock+0x8/0x50
Dec 27 12:12:17 vdr1 kernel: [33147.170622] EAX: 0040 EBX:  ECX: 
0040 EDX: 
Dec 27 12:12:17 vdr1 kernel: [33147.170622] ESI: 0040 EDI: 00200292 EBP: 
f5379e5c ESP: f5379e58
Dec 27 12:12:17 vdr1 kernel: [33147.170622]  DS: 007b ES: 007b FS:  GS: 
0033 SS: 0068
Dec 27 12:12:17 vdr1 kernel: [33147.170622] CR0: 8005003b CR2: 0040 CR3: 
315c7000 CR4: 07f0
Dec 27 12:12:17 vdr1 kernel: [33147.170622] DR0:  DR1:  DR2: 
 DR3: 
Dec 27 12:12:17 vdr1 kernel: [33147.170622] DR6: 0ff0 DR7: 0400
Dec 27 12:12:17 vdr1 kernel: [33147.170622] Process bino (pid: 23337, 
ti=f5378000 task=f59e2940 task.ti=f5378000)
Dec 27 12:12:17 vdr1 kernel: [33147.170622] Stack:
Dec 27 12:12:17 vdr1 kernel: [33147.170622]  0050 f5379e80 c136c9b5 
 0002  fa1f1bd6 f42e9400
Dec 27 12:12:17 vdr1 kernel: [33147.170622]  f595dc88  f5379ed8 

dvb-c: TT C-1501: tda827x.c: Cannot hold lock at 746 MHz

2010-10-02 Thread thomas schorpp

Hello,

Klaas patch is not complete:
http://article.gmane.org/gmane.linux.drivers.dvb/47571

I found a hole at 746MHz with 2.6.34.0 kernel and DE provider kabelbw.de,
Picture fragments and audio bursts only:

Oct  2 15:53:03 tom1 vdr: [16380] receiver on device 1 thread ended (pid=16268, 
tid=16380)
Oct  2 15:53:03 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:03 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:03 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct  2 15:53:04 tom1 vdr: [16462] setting audio track to 1 (0)
Oct  2 15:53:04 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:04 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:04 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct  2 15:53:04 tom1 vdr: [16279] frontend 0 lost lock on channel 496, tp 746
Oct  2 15:53:04 tom1 vdr: [16279] frontend 0 regained lock on channel 496, tp 
746
Oct  2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct  2 15:53:05 tom1 vdr: [16279] frontend 0 lost lock on channel 496, tp 746
Oct  2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct  2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct  2 15:53:06 tom1 vdr: [16279] frontend 0 regained lock on channel 496, tp 
746
Oct  2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct  2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct  2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct  2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct  2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct  2 15:53:06 tom1 vdr: [16268] switching to channel 494

cycle: 78  d_time: 0.004 s  Sig: 51657  SNR: 43690  BER: 1728  UBLK: 55  Stat: 
0x00 []
cycle: 79  d_time: 0.004 s  Sig: 52428  SNR: 60395  BER: 1728  UBLK: 57  Stat: 
0x03 [SIG CARR ]
cycle: 80  d_time: 0.004 s  Sig: 50886  SNR: 46517  BER: 1728  UBLK: 95  Stat: 
0x00 []
cycle: 81  d_time: 0.007 s  Sig: 52428  SNR: 44461  BER: 1728  UBLK: 54  Stat: 
0x03 [SIG CARR ]
cycle: 82  d_time: 0.003 s  Sig: 51657  SNR: 61423  BER: 1728  UBLK: 5  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 83  d_time: 0.237 s  Sig: 40092  SNR: 47288  BER: 1048575  UBLK: 66  
Stat: 0x00 []
cycle: 84  d_time: 0.005 s  Sig: 56283  SNR: 45232  BER: 1728  UBLK: 113  Stat: 
0x00 []
cycle: 85  d_time: 0.006 s  Sig: 53199  SNR: 46774  BER: 1728  UBLK: 136  Stat: 
0x00 []
cycle: 86  d_time: 0.008 s  Sig: 50115  SNR: 44975  BER: 1728  UBLK: 55  Stat: 
0x00 []
cycle: 87  d_time: 0.004 s  Sig: 53199  SNR: 53970  BER: 1728  UBLK: 287  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 88  d_time: 0.020 s  Sig: 50886  SNR: 61166  BER: 1728  UBLK: 62  Stat: 
0x03 [SIG CARR ]

Current parameters:
Frequency:  746000.000 kHz
Inversion:  ON
Symbol rate:  6.90 MSym/s
FEC:  none
Modulation:  QAM 64

Card is just bought newly:

00:06.0 0480: 1131:7146 (rev 01)
Subsystem: 13c2:101a
Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at fbeffc00 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb

Other (tested favourite) channels are tuned in fine.

No network problems for this transponder reported in cable provider's support 
forums.

Anyone got the chips datasheet or a hint what to tweak in the tda827xa_dvbc[] 
for this frequency?

{ .lomax = 80200, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1}, ?

thx,
Y
tom



--
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-c: TT C-1501: tda827x.c: Cannot hold lock at 746 MHz

2010-10-02 Thread thomas schorpp

Am 02.10.2010 16:43, schrieb thomas schorpp:

Hello,

Klaas patch is not complete:
http://article.gmane.org/gmane.linux.drivers.dvb/47571

I found a hole at 746MHz with 2.6.34.0 kernel and DE provider kabelbw.de,
Picture fragments and audio bursts only:

Oct 2 15:53:03 tom1 vdr: [16380] receiver on device 1 thread ended (pid=16268, 
tid=16380)
Oct 2 15:53:03 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:03 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:03 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:04 tom1 vdr: [16462] setting audio track to 1 (0)
Oct 2 15:53:04 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:04 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:04 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:04 tom1 vdr: [16279] frontend 0 lost lock on channel 496, tp 746
Oct 2 15:53:04 tom1 vdr: [16279] frontend 0 regained lock on channel 496, tp 746
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:05 tom1 vdr: [16279] frontend 0 lost lock on channel 496, tp 746
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:06 tom1 vdr: [16279] frontend 0 regained lock on channel 496, tp 746
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:06 tom1 vdr: [16268] switching to channel 494

cycle: 78 d_time: 0.004 s Sig: 51657 SNR: 43690 BER: 1728 UBLK: 55 Stat: 0x00 []
cycle: 79 d_time: 0.004 s Sig: 52428 SNR: 60395 BER: 1728 UBLK: 57 Stat: 0x03 
[SIG CARR ]
cycle: 80 d_time: 0.004 s Sig: 50886 SNR: 46517 BER: 1728 UBLK: 95 Stat: 0x00 []
cycle: 81 d_time: 0.007 s Sig: 52428 SNR: 44461 BER: 1728 UBLK: 54 Stat: 0x03 
[SIG CARR ]
cycle: 82 d_time: 0.003 s Sig: 51657 SNR: 61423 BER: 1728 UBLK: 5 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 83 d_time: 0.237 s Sig: 40092 SNR: 47288 BER: 1048575 UBLK: 66 Stat: 
0x00 []
cycle: 84 d_time: 0.005 s Sig: 56283 SNR: 45232 BER: 1728 UBLK: 113 Stat: 0x00 
[]
cycle: 85 d_time: 0.006 s Sig: 53199 SNR: 46774 BER: 1728 UBLK: 136 Stat: 0x00 
[]
cycle: 86 d_time: 0.008 s Sig: 50115 SNR: 44975 BER: 1728 UBLK: 55 Stat: 0x00 []
cycle: 87 d_time: 0.004 s Sig: 53199 SNR: 53970 BER: 1728 UBLK: 287 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 88 d_time: 0.020 s Sig: 50886 SNR: 61166 BER: 1728 UBLK: 62 Stat: 0x03 
[SIG CARR ]

Current parameters:
Frequency: 746000.000 kHz
Inversion: ON
Symbol rate: 6.90 MSym/s
FEC: none
Modulation: QAM 64

Card is just bought newly:

00:06.0 0480: 1131:7146 (rev 01)
Subsystem: 13c2:101a
Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at fbeffc00 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb

Other (tested favourite) channels are tuned in fine.

No network problems for this transponder reported in cable provider's support 
forums.

Anyone got the chips datasheet or a hint what to tweak in the tda827xa_dvbc[] 
for this frequency?

{ .lomax = 80200, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1}, ?

thx,
Y
tom





Hm, this gets complicated, tuning is fine at 722+754MHz but not on 746MHz,
this is within the same control segment

{ .lomax = 72000, .svco = 2, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 
1},
{ .lomax = 80200, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 
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


Re: dvb-c: TT C-1501: tda827x.c: Cannot hold lock at 746 MHz

2010-10-02 Thread thomas schorpp

Am 02.10.2010 17:19, schrieb thomas schorpp:

Am 02.10.2010 16:43, schrieb thomas schorpp:

Hello,

Klaas patch is not complete:
http://article.gmane.org/gmane.linux.drivers.dvb/47571

I found a hole at 746MHz with 2.6.34.0 kernel and DE provider kabelbw.de,
Picture fragments and audio bursts only:

Oct 2 15:53:03 tom1 vdr: [16380] receiver on device 1 thread ended (pid=16268, 
tid=16380)
Oct 2 15:53:03 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:03 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:03 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:04 tom1 vdr: [16462] setting audio track to 1 (0)
Oct 2 15:53:04 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:04 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:04 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:04 tom1 vdr: [16279] frontend 0 lost lock on channel 496, tp 746
Oct 2 15:53:04 tom1 vdr: [16279] frontend 0 regained lock on channel 496, tp 746
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:05 tom1 vdr: [16279] frontend 0 lost lock on channel 496, tp 746
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:05 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:05 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:06 tom1 vdr: [16279] frontend 0 regained lock on channel 496, tp 746
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 5
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params:
Oct 2 15:53:06 tom1 kernel: tda827x: tda827xa_set_params select tda827xa_dvbc
Oct 2 15:53:06 tom1 kernel: tda827x: tda8275a AGC2 gain is: 4
Oct 2 15:53:06 tom1 vdr: [16268] switching to channel 494

cycle: 78 d_time: 0.004 s Sig: 51657 SNR: 43690 BER: 1728 UBLK: 55 Stat: 0x00 []
cycle: 79 d_time: 0.004 s Sig: 52428 SNR: 60395 BER: 1728 UBLK: 57 Stat: 0x03 
[SIG CARR ]
cycle: 80 d_time: 0.004 s Sig: 50886 SNR: 46517 BER: 1728 UBLK: 95 Stat: 0x00 []
cycle: 81 d_time: 0.007 s Sig: 52428 SNR: 44461 BER: 1728 UBLK: 54 Stat: 0x03 
[SIG CARR ]
cycle: 82 d_time: 0.003 s Sig: 51657 SNR: 61423 BER: 1728 UBLK: 5 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 83 d_time: 0.237 s Sig: 40092 SNR: 47288 BER: 1048575 UBLK: 66 Stat: 
0x00 []
cycle: 84 d_time: 0.005 s Sig: 56283 SNR: 45232 BER: 1728 UBLK: 113 Stat: 0x00 
[]
cycle: 85 d_time: 0.006 s Sig: 53199 SNR: 46774 BER: 1728 UBLK: 136 Stat: 0x00 
[]
cycle: 86 d_time: 0.008 s Sig: 50115 SNR: 44975 BER: 1728 UBLK: 55 Stat: 0x00 []
cycle: 87 d_time: 0.004 s Sig: 53199 SNR: 53970 BER: 1728 UBLK: 287 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 88 d_time: 0.020 s Sig: 50886 SNR: 61166 BER: 1728 UBLK: 62 Stat: 0x03 
[SIG CARR ]

Current parameters:
Frequency: 746000.000 kHz
Inversion: ON
Symbol rate: 6.90 MSym/s
FEC: none
Modulation: QAM 64

Card is just bought newly:

00:06.0 0480: 1131:7146 (rev 01)
Subsystem: 13c2:101a
Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at fbeffc00 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb

Other (tested favourite) channels are tuned in fine.

No network problems for this transponder reported in cable provider's support 
forums.

Anyone got the chips datasheet or a hint what to tweak in the tda827xa_dvbc[] 
for this frequency?

{ .lomax = 80200, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1}, ?

thx,
Y
tom





Hm, this gets complicated, tuning is fine at 722+754MHz but not on 746MHz,
this is within the same control segment

{ .lomax = 72000, .svco = 2, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
{ .lomax = 80200, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},



Tweaking those parameters doesn't change anything.

Fixed. Bad IEC Connectors. Avoid Philips coaxial cable products or TT Tuner 
connectors :-/

--
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: was: af9015, af9013 DVB-T problems. now: Intermittent USB disconnects with many (2.0) high speed devices

2010-06-13 Thread thomas schorpp

Am 13.06.2010 15:57, schrieb Alan Stern:

On Sun, 13 Jun 2010, thomas schorpp wrote:


ehci-hcd is broken and halts silently or disconnects after hours or a few days, 
with the wlan usb adapter


How do you know the bug is in ehci-hcd and not in the hardware?


All 3 usb devices and 2 different series VIA usb hosts and Hemsing's and many 
other broken i2c comms reporter's on linux-media are broken instead?
Well, if we get that confirmed, I'll buy 2 of those with NEC chipset:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItemitem=190318779935




I was able to catch a dmesg err message like ehci...force halt... handshake 
failed once only.


Can you please post the error message?


Jun  3 08:38:29 tom3 kernel: [75071.004062] ehci_hcd :00:0e.2: force halt; 
handhake cc9c0814 c000  - -110
Jun  3 08:45:13 tom3 kernel: [75475.004061] ehci_hcd :00:0e.2: force halt; 
handhake cc9c0814 c000  - -110
Previous debian testing version of Linux tom3 2.6.32-5-686 #1 SMP Tue Jun 1 
04:59:47 UTC 2010 i686 GNU/Linux,
not yet reproduced with current version.



The disconnects with dvb-usb need reboot cause driver cannot be removed with 
modprobe.


That sounds like it might be a bug in dvb-usb driver.  It always should
be possible to remove the driver.


Sure.




This long standing bug is really nasty and makes permanent high speed usb 
connections unusable on Linux,
at least with this VIA hardware.

No debug parms in modules, we need to ask linux-usb how to debug this.


You can start by building a kernel with CONFIG_USB_DEBUG enabled.


Yes, will do it, thx.



Alan Stern




y
tom
--
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: was: af9015, af9013 DVB-T problems. now: Intermittent USB disconnects with many (2.0) high speed devices

2010-06-13 Thread thomas schorpp

Am 13.06.2010 17:22, schrieb Alan Stern:

On Sun, 13 Jun 2010, thomas schorpp wrote:


Am 13.06.2010 15:57, schrieb Alan Stern:

On Sun, 13 Jun 2010, thomas schorpp wrote:


ehci-hcd is broken and halts silently or disconnects after hours or a few days, 
with the wlan usb adapter


How do you know the bug is in ehci-hcd and not in the hardware?


All 3 usb devices and 2 different series VIA usb hosts and Hemsing's and many 
other broken i2c comms reporter's on linux-media are broken instead?


It's certainly possible and has been known to happen.


Well, if we get that confirmed, I'll buy 2 of those with NEC chipset:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItemitem=190318779935




I was able to catch a dmesg err message like ehci...force halt... handshake 
failed once only.


Can you please post the error message?


Jun  3 08:38:29 tom3 kernel: [75071.004062] ehci_hcd :00:0e.2: force halt; 
handhake cc9c0814 c000  -  -110
Jun  3 08:45:13 tom3 kernel: [75475.004061] ehci_hcd :00:0e.2: force halt; 
handhake cc9c0814 c000  -  -110
Previous debian testing version of Linux tom3 2.6.32-5-686 #1 SMP Tue Jun 1 
04:59:47 UTC 2010 i686 GNU/Linux,
not yet reproduced with current version.


Reproducible with the new debian testing kernel:

[90395.57] usb 4-4: USB disconnect, address 3
[90395.585864] wlan0: deauthenticating from 00:19:cb:87:5e:4a by local choice 
(reason=3)
[90396.100206] usb 4-4: new high speed USB device using ehci_hcd and address 4
[90411.192304] hub 4-0:1.0: unable to enumerate USB device on port 4
[90411.448242] usb 3-2: new full speed USB device using uhci_hcd and address 3
[90411.635297] usb 3-2: not running at top speed; connect to a high speed hub
[90411.757316] usb 3-2: New USB device found, idVendor=148f, idProduct=2573
...
[90412.212601] Registered led device: rt73usb-phy4::quality
[90414.004060] ehci_hcd :00:0e.2: force halt; handhake cca1a814 c000 
 - -110

Trying to reproduce in full speed only mode without ehci_hcd driver loaded.



You may need to copy the broken periodic workaround code from the
PCI_VENDOR_ID_INTEL case in ehci_pci_setup(),
drivers/usb/host/ehci-pci.c into the PCI_VENDOR_ID_VIA case.


Yes, will do this on the machine with the 2.6.34 kernel and watch the dvb-usb 
stick for disconnects to report.



Alan Stern




Thank You very much,
y
tom
--
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 RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)

2010-03-09 Thread thomas schorpp

LiM wrote:

Hi,

for information...i have the same dongle (LeadTek WinFast DTV Dongle
Mini - Bus 001 Device 003: ID 0413:6a03 Leadtek Research, Inc. )
and after compiled RTL2832U + change VID+PID in rtl2832u.h (i changed
USB_VID_GTEK + USB_PID_GTEK_WARM to leadtek`s 0413:6a03)
is tuner working!  (me-tv + kaffeine)



Good. Supported tuner chip. Pls do extensive tests (multiple recording streams, long time use usb-disconnects, 
other dvb apps...) and report any issues.


But we must support the MSI and others, too, so introduce an USB-ids array and device detection for 
USB_VID_GTEK + USB_PID_GTEK_WARM, see the other drivers for example code.


I don't have got the devices.


Installation of Realtek rtl2832u-based DVB-T-USB-Sticks:




gedit ./linux/drivers/media/dvb/dvb-usb/Makefile


Not acceptable in linux software development, pls *attach* patch to a mail with [PATCH]... in subject line 
by using linux diff utility (man diff) 
Example:

diff -rNU3 orig code dir changed code dir  ubuntuusers-de-rtl2832u-01.patch
With signed-off-by author mail adress 


For patching non-driver user space apps, please contact their project devlists.

y
tom


Jan Hoogenraad napsal(a):

Mauro:

Can you remove the VERY OLD branch:
http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab
It is giving some confusion here.

Thomas  Jan:

I've got the RTL2831 code (mind the last digit) vetted off by LeadTek.
For the rtl2832, I haven't had contact with them.

Certainly, Jan could try any of the three archives.
I know Antti has thoughts on the rtl2832, I'm sure he knows more.

thomas schorpp wrote:

Jan Hoogenraad wrote:

Antti has been working on drivers for the RTL283x.

http://linuxtv.org/hg/~anttip/rtl2831u
or
http://linuxtv.org/hg/~anttip/qt1010/

~jhoogenraad/rtl2831-r2 rtl2831-r2 development repository: *known
working version* Jan Hoogenraad

Should Jan Slaninka try it?

If you have more information on the RTL2832, I'd be happy to add it at:
http://www.linuxtv.org/wiki/index.php/Rtl2831_devices

Nothing on the Realtek website yet.



Jan Slaninka wrote:

Hi,

I'd like to ask for a support with getting LeadTek WindFast DTV Dongle
mini running on Linux. So far I was able to fetch latest v4l-dvb from
HG, and successfully compiled module dvb_usb_rtl2832u found in
090730_RTL2832U_LINUX_Ver1.1.rar  

Can be considered as GPL code then according to

http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab

Patch to make RTL2831U DVB-T USB2.0 DEVICE work, based on RealTek
version 080314

~mchehab/rtl2831 rtl2831 development repository with *RealTek GPL
code* for rtl2831 Mauro Carvalho Chehab 24 months ago

?

y
tom

--
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 RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)

2010-03-07 Thread thomas schorpp

Jan Hoogenraad wrote:

Antti has been working on drivers for the RTL283x.

http://linuxtv.org/hg/~anttip/rtl2831u
or
http://linuxtv.org/hg/~anttip/qt1010/


~jhoogenraad/rtl2831-r2 rtl2831-r2 development repository: *known 
working version*  Jan Hoogenraad

Should Jan Slaninka try it? 



If you have more information on the RTL2832, I'd be happy to add it at:
http://www.linuxtv.org/wiki/index.php/Rtl2831_devices


Nothing on the Realtek website yet.




Jan Slaninka wrote:

Hi,

I'd like to ask for a support with getting LeadTek WindFast DTV Dongle
mini running on Linux. So far I was able to fetch latest v4l-dvb from
HG, and successfully compiled module dvb_usb_rtl2832u found in


090730_RTL2832U_LINUX_Ver1.1.rar  


Can be considered as GPL code then according to

http://linuxtv.org/hg/~mchehab/rtl2831/rev/d116540ebaab

Patch to make RTL2831U DVB-T USB2.0 DEVICE work, based on RealTek version 080314

~mchehab/rtl2831rtl2831 development repository with *RealTek GPL code* 
for rtl2831  Mauro Carvalho Chehab   24 months ago

?

y
tom
--
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 RTL2832U DVB-T dongle (LeadTek WinFast DTV Dongle Mini)

2010-03-06 Thread thomas schorpp

Jan Slaninka wrote:

Hi,

I'd like to ask for a support with getting LeadTek WindFast DTV Dongle
mini running on Linux. So far I was able to fetch latest v4l-dvb from
HG, and successfully compiled module dvb_usb_rtl2832u found in



090730_RTL2832U_LINUX_Ver1.1.rar


From Ubuntu etc Webforums? 


Not linuxtv.org or OSS code, missing license, so considered *Realtek 
proprietary* as default license by (c) law.

Ask the maintainers to ask Realtek if they like to have it GPL'd so we can add, 
improve and maintain it.

Do not distribute patches for it over this list or forums until license status 
is cleared.


but with no luck.
The box says the dongle's TV Tuner is Infineon 396


No such Infineon Tuner 
http://www.infineon.com/cms/en/product/channel.html?channel=ff80808112ab681d0112ab6b9bb708b9

must be other device You've seen, possibly EEPROM/Regulator.


and Demodulator is
RTL2832U. Is there any chance with this one? Any hints appreciated.

Thanks,
Jan




Bus 002 Device 009: ID 0413:6a03 Leadtek Research, Inc.


Add this USB-ID to the driver and try your luck.

If the frontend tuner is not detected automatically, assign it manually in the 
source code.

y
tom
--
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


[BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input

2010-02-26 Thread thomas schorpp
Hi, 


Issue is already confirmed here:
http://www.vdr-portal.de/board/thread.php?threadid=93268

Linux 2.6.32.8, 80cm dish.

Do we have any Tuner/Decoder optimization points in the FE code?

This is not OK:

lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors 
SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia 
GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at 
fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power 
Management version 1 Kernel driver in use: saa7134

grep cTS2PES /var/log/syslog
Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity 
errors
Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity 
errors
Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity 
errors
Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity 
errors
Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity 
errors
Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity 
errors
Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity 
errors
Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity 
errors
Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity 
errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity 
errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity 
errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity 
errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity 
errors
Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors
Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors

dvbsnoop -s feinfo -adapter 2
Current parameters:
Frequency: 1236.253 MHz
Inversion: OFF
Symbol rate: 31.794142 MSym/s
FEC: FEC 3/4

dvbsnoop -s signal -adapter 2
cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]
cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG 
CARR VIT SYNC LOCK ]

Low signal strength values are AGC-loop misinterpretation as usual?

y
tom

--
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: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input

2010-02-26 Thread thomas schorpp

Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-)

Even at higher BER:

Current parameters:
   Frequency:  1945.320 MHz
   Inversion:  OFF
   Symbol rate:  22.000154 MSym/s
   FEC:  FEC 5/6

cycle: 1  d_time: 0.001 s  Sig: 18504  SNR: 39578  BER: 168  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 2  d_time: 0.073 s  Sig: 18247  SNR: 39578  BER: 225  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 3  d_time: 0.079 s  Sig: 18504  SNR: 37779  BER: 140  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 4  d_time: 0.072 s  Sig: 18504  SNR: 39835  BER: 198  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 5  d_time: 0.071 s  Sig: 18504  SNR: 39835  BER: 221  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 6  d_time: 0.072 s  Sig: 18247  SNR: 39578  BER: 249  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 7  d_time: 0.072 s  Sig: 18504  SNR: 39835  BER: 191  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 8  d_time: 0.072 s  Sig: 18504  SNR: 39578  BER: 185  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 9  d_time: 0.072 s  Sig: 18761  SNR: 39578  BER: 137  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]

I'll report if issue reoccurs and try to finetune crystal based tuner/demod 
parameters, then.

y
tom

thomas schorpp wrote:

Hi,
Issue is already confirmed here:
http://www.vdr-portal.de/board/thread.php?threadid=93268

Linux 2.6.32.8, 80cm dish.

Do we have any Tuner/Decoder optimization points in the FE code?

This is not OK:

lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips 
Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) 
Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium 
devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) 
[size=1K] Capabilities: [40] Power Management version 1 Kernel driver in 
use: saa7134


grep cTS2PES /var/log/syslog
Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS 
continuity errors
Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS 
continuity errors
Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS 
continuity errors
Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS 
continuity errors
Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS 
continuity errors
Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS 
continuity errors
Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS 
continuity errors
Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS 
continuity errors
Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS 
continuity errors
Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS 
continuity errors
Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS 
continuity errors


dvbsnoop -s feinfo -adapter 2
Current parameters:
Frequency: 1236.253 MHz
Inversion: OFF
Symbol rate: 31.794142 MSym/s
FEC: FEC 3/4

dvbsnoop -s signal -adapter 2
cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]


Low signal strength values are AGC-loop misinterpretation as usual?

y
tom



--
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: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input

2010-02-26 Thread thomas schorpp

Hello, Hermann,

hermann pitton wrote:

Hi Thomas,

Am Samstag, den 27.02.2010, 00:34 +0100 schrieb thomas schorpp:

Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-)

Even at higher BER:

Current parameters:
Frequency:  1945.320 MHz
Inversion:  OFF
Symbol rate:  22.000154 MSym/s
FEC:  FEC 5/6

cycle: 1  d_time: 0.001 s  Sig: 18504  SNR: 39578  BER: 168  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 2  d_time: 0.073 s  Sig: 18247  SNR: 39578  BER: 225  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 3  d_time: 0.079 s  Sig: 18504  SNR: 37779  BER: 140  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 4  d_time: 0.072 s  Sig: 18504  SNR: 39835  BER: 198  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 5  d_time: 0.071 s  Sig: 18504  SNR: 39835  BER: 221  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 6  d_time: 0.072 s  Sig: 18247  SNR: 39578  BER: 249  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 7  d_time: 0.072 s  Sig: 18504  SNR: 39835  BER: 191  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 8  d_time: 0.072 s  Sig: 18504  SNR: 39578  BER: 185  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 9  d_time: 0.072 s  Sig: 18761  SNR: 39578  BER: 137  UBLK: 0  Stat: 
0x1f [SIG CARR VIT SYNC LOCK ]

I'll report if issue reoccurs and try to finetune crystal based tuner/demod 
parameters, then.

y
tom


I just started to try to look it up, but don't have ground yet.


Look for tda10086 changesets in the stable branch git repository at kernel.org 2.6.32.7...33 
and linux-media repository ?


If there's no applicable change then I've misinterpreted the fix for the clear sky tonight :D  
but I'm pretty sure the issue occured at any weather with hours of clear sky periods last week, 
there's not been a minute without TS errors in VDR as long as the card has been in use.




I reported unexpected bad performance under GNU/Linux for that card
previously.


On this list? Give weblink pls.



Can you point me to the fix?

Cheers,
Hermann


y
tom




thomas schorpp wrote:

Hi,
Issue is already confirmed here:
http://www.vdr-portal.de/board/thread.php?threadid=93268

Linux 2.6.32.8, 80cm dish.

Do we have any Tuner/Decoder optimization points in the FE code?

This is not OK:

lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips 
Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) 
Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium 
devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) 
[size=1K] Capabilities: [40] Power Management version 1 Kernel driver in 
use: saa7134


grep cTS2PES /var/log/syslog
Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS 
continuity errors
Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS 
continuity errors
Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS 
continuity errors
Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS 
continuity errors
Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS 
continuity errors
Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS 
continuity errors
Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS 
continuity errors
Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS 
continuity errors
Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS 
continuity errors
Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS 
continuity errors
Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS 
continuity errors
Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS 
continuity errors


dvbsnoop -s feinfo -adapter 2
Current parameters:
Frequency: 1236.253 MHz
Inversion: OFF
Symbol rate: 31.794142 MSym/s
FEC: FEC 3/4

dvbsnoop -s signal -adapter 2
cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]
cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f 
[SIG CARR VIT SYNC LOCK ]


Low signal strength values are AGC-loop misinterpretation as usual?

y
tom







--
To unsubscribe

Re: zr364xx: Aiptek DV8800 (neo): 08ca:2062: Fails on subsequent zr364xx_open()

2010-02-12 Thread thomas schorpp

Hi Antoine,

Antoine Jacquet wrote:

Hi Thomas,

Looks like the device does not like to be fed with the (full) init 
METHOD2 on every open()...

Since the VIDIOC_QUERYCAP worked it should not be the wrong METHOD.


Someone reported similar behavior recently, and was apparently able to 
fix the issue by adding more delay between open/close sequences.


No search tags to find it on the list, can You remember device model?



Could you try the attached patch to see if it solves the issue?


Didn't work, same -110 errors, sorry, no v4l-dvb git here, vdr production 
machine on 2.6.32.7.



If not, we can also try to add some mdelay() after each usb_control_msg().


1. Patch with optimized delay below, slow but works, 1st try was delaying subsequent msg 
at open sequence i=6, worked until the last 2 open() before capture start.
From the windows snoopy log I sent yesterday I can see only 1-2 URBs with relevant delay of ~1s but 

cannot see the sequence point.

What is error -22, can not find it in errno.h?

2. Picture with (640-320) lines alignment error with ekiga+cheese 
*attached*, wether cam is configured internally for 640x480 or 320x240, not affecting.

setting the driver to mode=2 fails with libv4l jpeg decoding errors. I try to 
correct this.

3. Driver oops on modprobe -r or device firmware crash, 
I need to unplug first or null pointer fault occours (mutex locks), see below




Regards,

Antoine



y
tom

--- drivers/media/video/zr364xx.c.orig  2009-12-18 23:27:07.0 +0100
+++ drivers/media/video/zr364xx.c   2010-02-12 12:57:54.0 +0100
@@ -205,40 +205,41 @@
struct zr364xx_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
const struct zr364xx_fmt *fmt;
};

/* function used to send initialisation commands to the camera */
static int send_control_msg(struct usb_device *udev, u8 request, u16 value,
u16 index, unsigned char *cp, u16 size)
{
int status;

unsigned char *transfer_buffer = kmalloc(size, GFP_KERNEL);
if (!transfer_buffer) {
dev_err(udev-dev, kmalloc(%d) failed\n, size);
return -ENOMEM;
}

memcpy(transfer_buffer, cp, size);

+   mdelay(300);
status = usb_control_msg(udev,
 usb_sndctrlpipe(udev, 0),
 request,
 USB_DIR_OUT | USB_TYPE_VENDOR |
 USB_RECIP_DEVICE, value, index,
 transfer_buffer, size, CTRL_TIMEOUT);

kfree(transfer_buffer);

if (status  0)
dev_err(udev-dev,
Failed sending control message, error %d.\n, status);

return status;
}


/* Control messages sent to the camera to initialize it
 * and launch the capture */
typedef struct {
@@ -1248,40 +1249,41 @@


/* open the camera */
static int zr364xx_open(struct file *file)
{
struct video_device *vdev = video_devdata(file);
struct zr364xx_camera *cam = video_drvdata(file);
struct usb_device *udev = cam-udev;
int i, err;

DBG(%s\n, __func__);

mutex_lock(cam-open_lock);

if (cam-users) {
err = -EBUSY;
goto out;
}

for (i = 0; init[cam-method][i].size != -1; i++) {
+// if (i == 6) mdelay(1000);
err =
send_control_msg(udev, 1, init[cam-method][i].value,
 0, init[cam-method][i].bytes,
 init[cam-method][i].size);
if (err  0) {
dev_err(cam-udev-dev,
error during open sequence: %d\n, i);
goto out;
}
}

cam-skip = 2;
cam-users++;
file-private_data = vdev;
cam-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
cam-fmt = formats;

videobuf_queue_vmalloc_init(cam-vb_vidq, zr364xx_video_qops,
NULL, cam-slock,
cam-type,


usb 1-2: new high speed USB device using ehci_hcd and address 7
usb 1-2: New USB device found, idVendor=08ca, idProduct=2062
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: DV 8800
usb 1-2: Manufacturer: AIPTEK
usb 1-2: configuration #1 chosen from 1 choice
zr364xx probing...
zr364xx 1-2:1.0: Zoran 364xx compatible webcam plugged
zr364xx 1-2:1.0: model 08ca:2062 detected
usb 1-2: 320x240 mode selected
zr364xx dev: 880039379000, udev 8800388d1800 interface 880039380a00
zr364xx num endpoints 3
zr364xx board init: 880039379000
zr364xx valloc 880039379028, idx 0, pdata c900019ef000
zr364xx zr364xx_start_readpipe: start pipe IN x81
zr364xx submitting URB 8800393a1900
zr364xx : board initialized
usb 1-2: Zoran 364xx controlling 

zr364xx: Aiptek DV8800 (neo): 08ca:2062: Fails on subsequent zr364xx_open()

2010-02-11 Thread thomas schorpp
Hi, 


Linux 2.6.30+32.x

Great there's a driver but seems to be untested/stub for this device:

usb 1-2: new high speed USB device using ehci_hcd and address 9
usb 1-2: New USB device found, idVendor=08ca, idProduct=2062
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: DV 8800
usb 1-2: Manufacturer: AIPTEK
usb 1-2: configuration #1 chosen from 1 choice
zr364xx probing...
zr364xx 1-2:1.0: Zoran 364xx compatible webcam plugged
zr364xx 1-2:1.0: model 08ca:2062 detected
usb 1-2: 320x240 mode selected
zr364xx dev: 88001eb62000, udev 88001e84c000 interface 88001ea35400
zr364xx num endpoints 3
zr364xx board init: 88001eb62000
zr364xx valloc 88001eb62028, idx 0, pdata c900039d9000
zr364xx zr364xx_start_readpipe: start pipe IN x81
zr364xx submitting URB 88001eafccc0
zr364xx : board initialized
usb 1-2: Zoran 364xx controlling video device 3
zr364xx zr364xx_open
zr364xx zr364xx_open: 0
Zoran 364xx: VIDIOC_QUERYCAP driver=Zoran 364xx, card=DV 8800, bus=1-2, 
version=0x0703, capabilities=0x0501
zr364xx zr364xx_release
zr364xx zr364xx_open
usb 1-2: Failed sending control message, error -110.
usb 1-2: error during open sequence: 6
zr364xx zr364xx_open: -110
usb 1-2: USB disconnect, address 9
zr364xx read_pipe_completion, err shutdown
zr364xx 1-2:1.0: Zoran 364xx webcam unplugged
zr364xx stop read pipe
zr364xx vfree c900039d9000

Same with mode=2 like the cam is configured (VGA+QVGA available in settings).

I'll sniff out the cmd sequences on an old win xp32 installation, no x64/vista/7 drivers found, 
or do You see the failure reason already?


Looks like the device does not like to be fed with the (full) init METHOD2 on 
every open()...
Since the VIDIOC_QUERYCAP worked it should not be the wrong METHOD.

y
tom

--
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