Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-25 Thread David
Pete Zaitcev wrote:
 On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern 
 st...@rowland.harvard.edu wrote:

   
 Pete, you should look at this.  It appears to be a problem with the DMA
 mapping in usbmon.  Probably the same sort of thing you were working on
 about a week ago (trying to access device memory).
 

 Indeed it looks the same. Is this an AMD CPU?
   
yes, a Phenom.

 I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
 in arch/x86/Kconfig). Strange that it started happening now.
   
That is enabled. I'll switch it off and give it another go.

David
--
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: CPen driver development / image format

2009-05-25 Thread Stefan Below

Andy Walls wrote:

On Sun, 2009-05-24 at 13:40 +0200, Stefan Below wrote:
  
Why does the PBM image have this text in it:


# CREATOR: GIMP PNM Filter Version 1.1

if it came from Windows?  Also why does the filename have crop in it?
Did you do some manipulation of the output file from the Windows
application?
  
The Problem with the Cpen OCR Software is, that i cannot grab the real 
image form the pen. I can only get an somehow processed image from the 
Cpen software  that i copied to gimp.


I did also some scans with lines etc. and i hope i can figure it out.

I am quite sure that the firmware on the pen gives me only an (inverted) 
black/white image.


Thanks for your hints,
Stefan


I ask because it may be the case that the C-Pen puts out a format very
close to the default format the Windows app software would like to save
things in.  Comparing that default save format to the data in the URBs
may provide some insight.


Also a solid field isn't very helpful for making deductions about the
image data format.  Try a series of images: vertical line, horizontal
line, diagonal line, ellipse, rectangle, triangle, and square grid.
Then comparison of those source images vs the data bytes might give you
more insight into the format.


Godd Luck,
Andy

  

I hope someone can help me to :-)

Stefan



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

  


--
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 08/10 v2] v4l2-subdev: add a v4l2_i2c_subdev_board() function

2009-05-25 Thread Eduardo Valentin
Hi,

On Fri, May 22, 2009 at 03:14:52PM +0200, Valentin Eduardo (Nokia-D/Helsinki) 
wrote:
 Hi,
 
  
  
  There are two 'missing somethings': the first is that you can have a v4l2 
  driver that uses v4l2_i2c_subdev_board, but the i2c driver that is loaded 
  by that call can also by used by other drivers need to be backwards 
  compatible with older kernels.
  
  So the i2c driver cannot in general obtain the irq and platform_data from 
  i2c_client during probe, since it won't be set during probe (actually, the 
  irq field in i2c_client doesn't even exist on pre-2.6.22 kernels).
  
  But if v4l2_i2c_subdev_board calls s_config explicitly, then this data can 
  be passed to the i2c driver in a manner that works for all kernels.
  
  The second 'something' is that I need something like s_config anyway for 
  those drivers that cannot use this new v4l2_i2c_subdev_board because they 
  have to compile for all kernels. Those drivers can call the existing 
  functions, and then call s_config explicitly.
  
  For the embedded platforms it really doesn't matter: there you just use 
  i2c_board_info, and the only time s_config comes into play is when the i2c 
  driver can also be used by bridge drivers that cannot use 
  v4l2_i2c_subdev_board.
 
 I think this is heading to other direction that I first understood. I don't
 see why one i2c driver which implements the new i2c api would not setup
 its irq and platform data other then during probe time. But let's assume that.
 
 In that case, i2c drivers, even though they implement the new i2c api, should
 not receive the board specific info during probe, but should wait until 
 s_config time.
 
 That would work for all kernels, but then i2c drivers would not have 
 opportunity to
 communicate with device during probe time and do silly checks there.
 
 Why can not v4l2_i2c_subdev_board be able to pass i2c_board_info using normal
 i2c api if we are = 2.6.26, and let s_config to bridge driver? Or even,
 call s_config only for  2.6.26 kernels ?
 
 In both cases, I still see that i2c drivers should be able to be configured
 both using normal i2c probes (with board data) or by using s_config.
 
 Besides that, I think s_config can be passing a void *, something like:
 + int (*s_config)(struct v4l2_subdev *sd, void *config_data);
 
 As in my last rfc patch. This way you don't need to care which board data
 need to be passed. We can even pass a i2c board info there. That should just
 be agreed between bridge and sub dev drivers.

I think I understood your point. Maybe what you are trying to keep is the same
v4l2 api so that can be used in all kernel versions. Based on that we cannot
pass i2c_board_info as v4l2 api function (at least for now).

So, I think I'm sending a patch with this in mind. Which is:
* Addition of s_config(irq, platform_data) into core callbacks set:
+   int (*s_config)(struct v4l2_subdev *sd, int irq, void *platform_data);

* Addition of v4l2_i2c_new_subdev_board, which is basically the same
of v4l2_i2c_new_subdev, but with two additional parameters: irq and 
platform_data.
This function will pass these data to i2c normal probe procedure (if we are = 
2.6.26),
and will call s_config with these two additional parameters.

So, both older i2c version compatible and newer i2c version only drivers can
call it. Is that what you were thinking?

I'm sending that patch as well in other email.


 
  
  Regards,
  
  Hans
  
  -- 
  Hans Verkuil - video4linux developer - sponsored by TANDBERG
 
 -- 
 Eduardo Valentin

-- 
Eduardo Valentin
--
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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-25 Thread David
David wrote:

 I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
 in arch/x86/Kconfig). Strange that it started happening now.
   
 
 That is enabled. I'll switch it off and give it another go.

   
While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I
guess there's nothing I can do to test?
--
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: TW6800 based video capture boards (updates)

2009-05-25 Thread Domenico Andreoli
On Mon, May 25, 2009 at 1:55 PM, Vito vcov...@libero.it wrote:

 Hi all.

Hi Vito,

 I've bought a Provideo 16 in capture PCI-Experess card for my own DVR 
 solution.
 http://www.provideo.com.tw/DVRCARD_PV988.htm
 This card have 8 TW6805 chip installed.
 I've installed the card in a PC with Fedora Core 9 Linux OS
 With this kernel.

 There is some possibility that this card can work in some manner?

Few days ago I created a repository on gitorious, http://gitorious.org/tw68.
I pushed the clean room driver written by William, mine is not available
for publication. My plan is to dig into it and see what improvements I can
bring. Anybody interested is free to jump onboard.

Currently I am not able to make any statement of usability of the free
one but Willy surely can :)

Best regards,
Domenico Andreoli

-[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50
--
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: [PULL] http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix

2009-05-25 Thread Mauro Carvalho Chehab
Em Wed, 20 May 2009 23:22:41 -0400
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

 Hello Mauro,
 
 Please pull from
 http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix for the
 following:
 
 dvb_frontend: fix case where fepriv-exit not reset

Didn't work. Please submit me again after fixing the trouble.

$ ./hgimport http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix
Pushing from remote site 
http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix, tree: 
dvb-frontend-exit-fix
rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado
abort: error: timed out
Number of patches: 0





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


Re: [RFC,PATCH] VIDIOC_G_EXT_CTRLS does not handle NULL pointer correctly

2009-05-25 Thread Mauro Carvalho Chehab
Em Mon, 25 May 2009 13:17:02 +0200
Laurent Pinchart laurent.pinch...@skynet.be escreveu:

 Hi everybody,
 
 Márton Németh found an integer overflow bug in the extended control ioctl 
 handling code. This affects both video_usercopy and video_ioctl2. See 
 http://bugzilla.kernel.org/show_bug.cgi?id=13357 for a detailed description 
 of 
 the problem.
 

 Restricting v4l2_ext_controls::count to values smaller than KMALLOC_MAX_SIZE /
 sizeof(struct v4l2_ext_control) should be enough, but we might want to 
 restrict the value even further. I'd like opinions on this.

Seems fine to my eyes, but being so close to kmalloc size doesn't seem to be a
good idea. It seems better to choose an arbitrary size big enough to handle all 
current needs.



Cheers,
Mauro
--
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: Not only TV LV5H hybrid tv card

2009-05-25 Thread Martin Kragelund
Hi Devin,

 My queue of em28xx devices I'm adding support for is already three or
 four deep.  Ask again in a couple of weeks and I will see what I can
 do to get this one working.

How are you queue looking? I would be very grateful to get my device
working in Linux :)
And thank you for you rapid reply two weeks ago - very nice to see
that there was hope of getting the device to work

Best Regards,
Martin




 Cheers,

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com




-- 
Martin Kragelund, M.Sc.E.E., Ph.D. Student
Aalborg University Denmark
Department of Electronic Systems, Automation and Control
Fredrik Bajers Vej 7C, 9220 Aalborg Ø, Denmark, Room C4-207
Office: +45 99408746, Mobile: +45 40856086, Fax: +45 98151739
--
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: [PULL] http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix

2009-05-25 Thread Devin Heitmueller
On Mon, May 25, 2009 at 8:51 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Didn't work. Please submit me again after fixing the trouble.

 $ ./hgimport http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix
 Pushing from remote site 
 http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix, tree: 
 dvb-frontend-exit-fix
 rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado
 abort: error: timed out
 Number of patches: 0

Sorry, we had some networking problems over the last couple of days.
Everything is back up now, so please try again.

Thank you,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: Re : cannot rmmod stb0899

2009-05-25 Thread Andreas Besse

Manu wrote:

Easiest way to rmmod stb0899 is to go to your v4l-dvb devel directory
and do;
sudo make unload
indeed stb0899 is needed by other drivers (like budget_ci and others).
So this command will remove them all.
Anyway you need to compile all drivers from the same tree else things
will go wrong.


thank you for your answer. As you can see in the logs of my first
message I tried make rmmod in the v4l-dvb directory. This has the same
effect as make unload. The script is not able to unload the drivers
(ERROR: Module .. is in use).

Any other ideas how to unload the drivers?

regards,
Andreas Besse
--
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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-25 Thread David
Alan Stern wrote:
 Okay, here's a patch for you to try.  It refreshes the toggle setting 
 in a linked but otherwise idle QH when a new URB is queued.

 Alan Stern


 Index: usb-2.6/drivers/usb/host/ehci-q.c
 ===
 --- usb-2.6.orig/drivers/usb/host/ehci-q.c
 +++ usb-2.6/drivers/usb/host/ehci-q.c
 @@ -88,7 +88,7 @@ static inline void
  qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
  {
   /* writes to an active overlay are unsafe */
 - BUG_ON(qh-qh_state != QH_STATE_IDLE);
 + BUG_ON(qh-qh_state != QH_STATE_IDLE  !list_empty(qh-qtd_list));
  
   qh-hw_qtd_next = QTD_NEXT(ehci, qtd-qtd_dma);
   qh-hw_alt_next = EHCI_LIST_END(ehci);
 @@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
   /* can't sleep here, we have ehci-lock... */
   qh = qh_make (ehci, urb, GFP_ATOMIC);
   *ptr = qh;
 + } else if (list_empty(qh-qtd_list)) {
 + /* There might have been a Clear-Halt while the QH
 +  * was linked but empty.
 +  */
 + qh_refresh(ehci, qh);
   }
 +
   if (likely (qh != NULL)) {
   struct ehci_qtd *qtd;
  

   
No luck I'm afraid (although there now appear to be 2 timeouts, not
one). I'm going to follow up on the laptop and get a USB log.

[  118.017016] usb 1-10: new high speed USB device using ehci_hcd and
address 5
[  118.148589] usb 1-10: configuration #1 chosen from 1 choice
[  118.452964] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[  118.452972] usb 1-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[  118.488474] dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
[  118.550946] usbcore: registered new interface driver dvb_usb_ttusb2
[  118.552553] usb 1-10: USB disconnect, address 5
[  118.561083] dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
[  120.313020] usb 1-10: new high speed USB device using ehci_hcd and
address 6
[  120.444942] usb 1-10: configuration #1 chosen from 1 choice
[  120.445886] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm
state.
[  120.446672] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[  120.447014] DVB: registering new adapter (Technotrend TT-connect S-2400)
[  120.455026] DVB: registering adapter 0 frontend 129197120 (Philips
TDA10086 DVB-S)...
[  120.458383] LNBx2x attached on addr=83dvb-usb: recv bulk message
failed: -110
[  122.457126] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[  124.456109] dvb-usb: recv bulk message failed: -110
[  124.456117] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[  124.456122] dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.


David

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


[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2009-05-25 Thread Jean-Francois Moine
Hi Mauro,

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following 6 changesets:

01/06: gspca - spca508: Cleanup source and update copyright.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=59d19da68b20

02/06: gspca - spca508: Optimize code.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=fd77a61cef9c

03/06: gspca - ov534: JPEG 320x240 and 640x480 formats for ov965x.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=8120b8f65ea5

04/06: gspca - main: VIDIOC_ENUM_FRAMESIZES ioctl added.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=1d1836e016ab

05/06: gspca - spca561: Change the Rev12a controls.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=44abd9059b3c

06/06: gspca - spca561: Rename the 'White Balance' control to 'Hue'.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=c0fb5be5acdb


 gspca.c   |   27 
 ov534.c   |  256 +---
 spca508.c | 1905 --
 spca561.c |  105 +--
 4 files changed, 1135 insertions(+), 1158 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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: Temporary success with Pinnacle PCTV 801e (xc5000 chip)

2009-05-25 Thread N Klepeis

Devin,   Yup, works nice now.   Good work!  --Neil

Devin Heitmueller wrote:

On Sat, May 23, 2009 at 5:15 PM, N Klepeis li...@klepeis.net wrote:

Hi,

I installed the latest v4l-dvb from CVS with the latest firmware
(dvb-fe-xc5000-1.6.114.fw) for the 801e (XC5000 chip).   I can  scan for
channels no problem.   But after a first use with either mplayer or mythtv,
it then immediately stops working and won't start again until I unplug and
then reinsert the device from the USB port.   On the first time use
everything seems fine and I can watch TV through mplayer for as long as I
want.On the 2nd use (restart mplayer), there's an error (FE_GET_INFO
error: 19, FD: 3).On the 2nd use with mythtv, mythtv cannot connect to
the card at all in mythtvsetup, but on the first time use I can assign
channel.conf.  I know there have been recent updates to the xc5000
driver.I only started trying this chip this week so I never confirmed
that any prior driver version worked.

Any thoughts on how to proceed? Below are the full console outputs when
using with mplayer and when running dmesg.   (This is fedora 10).

--Neil



Neil,

Already tracked down and a PULL has been requested for the patch:

http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix

Cheers,

Devin



--
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: videodev: Unknown symbol i2c_unregister_device (in kernels older than 2.6.26)

2009-05-25 Thread Andy Walls
On Sun, 2009-05-24 at 20:52 -0400, David Ward wrote:
 On 05/24/2009 07:10 PM, Matt Doran wrote:
  Hi there,
 
  I tried using the latest v4l code on an Mythtv box running 2.6.20, but
  the v4l videodev module fails to load with the following warnings:
 
 videodev: Unknown symbol i2c_unregister_device
 v4l2_common: Unknown symbol v4l2_device_register_subdev
 
 
  It seems the i2c_unregister_device function was added in 2.6.26.
  References to this function in v4l2-common.c are enclosed in an ifdef
  like:
 
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
 
 
  However in v4l2_device_unregister() in v4l2-device.c, there is a
  reference to i2c_unregister_device without any ifdefs.   I am
  running a pretty old kernel, but I'd guess anyone running 2.6.25 or
  earlier will have this problem.   It seems this code was added by
  Mauro 3 weeks ago in this rev:
 
 http://linuxtv.org/hg/v4l-dvb/rev/87afa7a4ccdf
 
 
 
 
  I also had some other compile problems, but don't have all the details
  (sorry!).  I had to disable the following drivers to get it to compile:
 
 * CONFIG_VIDEO_PVRUSB2
 * CONFIG_VIDEO_THS7303
 * CONFIG_VIDEO_ADV7343
 * CONFIG_DVB_SIANO_SMS1XXX
 
 
  Regards,
  Matt
 
 
 Matt, I checked out v4l-dvb today and am using it under 2.6.24 and so 
 far so good.  When did the error appear -- when you were trying to load 
 the module?
 
 I have been seeing the errors compiling adv7343.c and ths7303.c under 
 2.6.24 as well.  Andy Walls and Chaithrika Subrahmanya had written 
 patches for those two modules respectively, but there were some comments 
 during the review of the patches, so I think they are still being worked on.

Well, just to manage expectations: I am not working on this.  I do not
advise waiting for something from me. ;)


As an end user, you work-around is to use make menuconfig (or
whatever) as Matt did: disable the modules that aren't compiling on
older kernels.


If it really bugs you (it would bug me), please submit a tested patch
against:

v4l-dvb/v4l/versions.txt

to disable compilations of the offending drivers for older kernels.

Backward compatability fixes are not going to be appealing work for
anyone, especially if you're not actually using the problem drivers.

Regards,
Andy


 David

--
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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-25 Thread David
David wrote:
 Alan Stern wrote:
   
 Okay, here's a patch for you to try.  It refreshes the toggle setting 
 in a linked but otherwise idle QH when a new URB is queued.

 Alan Stern


 Index: usb-2.6/drivers/usb/host/ehci-q.c
 ===
 --- usb-2.6.orig/drivers/usb/host/ehci-q.c
 +++ usb-2.6/drivers/usb/host/ehci-q.c
 @@ -88,7 +88,7 @@ static inline void
  qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
  {
  /* writes to an active overlay are unsafe */
 -BUG_ON(qh-qh_state != QH_STATE_IDLE);
 +BUG_ON(qh-qh_state != QH_STATE_IDLE  !list_empty(qh-qtd_list));
  
  qh-hw_qtd_next = QTD_NEXT(ehci, qtd-qtd_dma);
  qh-hw_alt_next = EHCI_LIST_END(ehci);
 @@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
  /* can't sleep here, we have ehci-lock... */
  qh = qh_make (ehci, urb, GFP_ATOMIC);
  *ptr = qh;
 +} else if (list_empty(qh-qtd_list)) {
 +/* There might have been a Clear-Halt while the QH
 + * was linked but empty.
 + */
 +qh_refresh(ehci, qh);
  }
 +
  if (likely (qh != NULL)) {
  struct ehci_qtd *qtd;
  

   
 
 No luck I'm afraid (although there now appear to be 2 timeouts, not
 one). I'm going to follow up on the laptop and get a USB log.
   
USB log post-patch attached. Thanks for all the effort so far!

David


postpatch.log.bz2
Description: application/bzip


Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/

2009-05-25 Thread Trent Piepho
On Mon, 25 May 2009, Mauro Carvalho Chehab wrote:

 +   if (params-frequency = 4800  params-frequency = 15400) \
 +   bs = 0x09;
 +   if (params-frequency = 16100  params-frequency = 43900) 
 \
 +   bs = 0x0a;
 +   if (params-frequency = 44700  params-frequency = 86300) 
 \
 +   bs = 0x08;

 Just remove the backslash. You don't need they.

The original code has this, but bs will be zero for a frequency between 154
MHz to 161 Mhz as welll as 439-447 MHz.  Probably wrong.  My guess is the
data sheet says, low band 48 to 154 MHz, mid band 161 MHz to 439 MHz,
etc., where 154 is the frequency of the last channel in the low band and
161 is the first channel in the mid band.  Then someone translated this to
code without really understanding what's going on.  It should probably be:

if  (params-frequency  44300) bs = 0x08;
else if (params-frequency  15750) bs = 0x0a;
elsebs = 0x09;

The tuner's limits should already be enforced elsewhere.  Or just convert
this to use dvb_pll.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC,PATCH] VIDIOC_G_EXT_CTRLS does not handle NULL pointer correctly

2009-05-25 Thread Trent Piepho
On Mon, 25 May 2009, Laurent Pinchart wrote:
 diff -r e0d881b21bc9 linux/drivers/media/video/v4l2-ioctl.c
 --- a/linux/drivers/media/video/v4l2-ioctl.c  Tue May 19 15:12:17 2009 +0200
 +++ b/linux/drivers/media/video/v4l2-ioctl.c  Sun May 24 18:26:29 2009 +0200
 @@ -402,6 +402,10 @@
  a specific control that caused it. */
   p-error_idx = p-count;
   user_ptr = (void __user *)p-controls;
 + if (p-count  KMALLOC_MAX_SIZE / sizeof(p-controls[0])) {
 + err = -ENOMEM;
 + goto out_ext_ctrl;
 + }
   if (p-count) {
   ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
   /* Note: v4l2_ext_controls fits in sbuf[] so mbuf is 
 still NULL. */
 @@ -1859,6 +1863,10 @@
  a specific control that caused it. */
   p-error_idx = p-count;
   user_ptr = (void __user *)p-controls;
 + if (p-count  KMALLOC_MAX_SIZE / sizeof(p-controls[0])) {
 + err = -ENOMEM;
 + goto out_ext_ctrl;
 + }
   if (p-count) {
   ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
   /* Note: v4l2_ext_controls fits in sbuf[] so mbuf is 
 still NULL. */

 Restricting v4l2_ext_controls::count to values smaller than KMALLOC_MAX_SIZE /
 sizeof(struct v4l2_ext_control) should be enough, but we might want to
 restrict the value even further. I'd like opinions on this.

One thing that could be done is to call access_ok() on the range before
kmalloc'ing a buffer.  If p-count is too high, then it's possible that the
copy_from_user will fail because the process does not have the address
space to copy.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-25 Thread Martin Dauskardt
 #define TUNER_PHILIPS_FQ1216ME  24  /* you must actively select 
B/G/D/K, I, L, L` */
 #define TUNER_PHILIPS_FQ1216AME_MK4 56  /* Hauppauge PVR-150 PAL */
 
 #define TUNER_PHILIPS_FM1216ME_MK3  38
 
 #define TUNER_PHILIPS_FMD1216ME_MK3 63
 #define TUNER_PHILIPS_FMD1216MEX_MK378
 #define TUNER_PHILIPS_FM1216MK5 79
 
 Could the user try one of those, starting with the FQ1216 tuner numbers
 (24 and 56), to see if one of them works?  For the FQ1261LME MK3,
 tveeprom has the FM1216ME_MK3 tuner number (38).
 

I have this card now at home for testing. First results:

#define TUNER_PHILIPS_FQ1216ME  24  /* you must actively select 
B/G/D/K, I, L, 
Result: only static

#define TUNER_PHILIPS_FM1216ME_MK3  38
result: picture + sound o.k.

#define TUNER_PHILIPS_FQ1216AME_MK4 56  /* Hauppauge PVR-150 PAL */
result: picture o.k., but no sound

#define TUNER_PHILIPS_FMD1216ME_MK3 63
result: picture + sound o.k.

#define TUNER_PHILIPS_FMD1216MEX_MK378
result: picture + sound o.k.

#define TUNER_PHILIPS_FM1216MK5 79
result: picture o.k. , but audio disappears every few seconds (for about 1-2 
seconds, then comes back) 

tuner type 63 and 79 are Hybrid tuners. This is fore sure an analogue-only 
tuner. The sticker says Multi-PAL, and according to VIDIOC_ENUMSTD  it 
supports PAL, PAL-BG and PAL-H. 

So I think 38 is right. Any suggestions for further tests?
--
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: [linux-dvb] SDMC DM1105N not being detected

2009-05-25 Thread Simon Kenyon

Igor M. Liplianin wrote:

On 20 May 2009 16:44:22 Simon Kenyon wrote:
  

mp3geek wrote:


Not even being detected in Linux 2.6.29.1, I have the modules dm1105
loaded, but since its not even being detected by linux..

lspci -vv shows this (I'm assuming this is the card..), dmesg shows
nothing dvb being loaded

00:0b.0 Ethernet controller: Device 195d:1105 (rev 10)
Subsystem: Device 195d:1105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 30 (4000ns min, 8000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 9400 [size=256]


The chip says the following, SDMC DM1105N, EasyTV-DVBS V1.0B
(2008-04-26), 0735 E280034
  

because i saw that there was a driver written by igor, i took a chance
and bought a DM04 DVB-S card on ebay. it only cost ─20 (including
shipping from HK to Ireland) so i reckoned nothing ventured, nothing
gained
on a windows box it runs rather nicely. granted that the software
provided does not provide a BDA driver, so you are pretty much limited
to the stuff that comes with the card.
but a big me too on linux (which is what i bought it for)
i similarly get an ethernet controller and nothing in the kernel log
when i load the dm1105 module.

what do i need to do to debug the situation and/or update the driver?

regards
--
simon



It seems, one can find GPIO values for LNB power control.
Do not forget about Vendor/Device ID's. 

I wrote code to support card with subsystem/device 195d/1105, but no one reported success, so I 
decided not to include it in commit :(


It was more then one year ago

http://liplianin.at.tut.by/dvblipl.tar.bz2

  

igor,

i downloaded it and built it (after making a few small changes to make 
it compile with tip)

it finds the hardware, but does not seem able to get a data stream
kaffeine seems to show that there is signal - and it does seem to vary 
in a way that is consistent with a working card


what do i need to do to help get this to work. i would like to as (under 
windows) it seems to work well and it is very, very cheap (13 euro on ebay)


it is on a machine which i can dual boot into windows (if that is any use)

regards
--
simon
--
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: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-25 Thread Martin Dauskardt
Am Montag, 25. Mai 2009 21:34:43 schrieb Martin Dauskardt:

 #define TUNER_PHILIPS_FM1216MK5 79
 result: picture o.k. , but audio disappears every few seconds (for about 1-2 
 seconds, then comes back) 

correction: This is not a problem of tuner type 79. It happens also with tuner 
type 38. Sometimes the audio is also muted after the start of the 
application. Only switching to another input and back brings the audio back.

I am beginning to wonder if this problem may be related to a similar problem 
with the PVRUSB2:
http://www.isely.net/pipermail/pvrusb2/2009-May/002331.html

If there is a problem with the new v4l2 sub-device mechanism, it seems to be 
more specific to some devices than to others. With my PVR350 I didn't notice 
such problems - although I remember that in **very** rare cases the audio 
fails after a channel switch.  

Greets, 
Martin

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


dvb_usb_nova_t_usb2: firmware is loaded too late

2009-05-25 Thread Dominique Dumont
Hello

I have some trouble with the initialisation of dvb_usb_nova_t_usb2: the 
firmware is loaded about 1 minute after the module is registered by usbcore:

May 25 11:42:30 gandalf kernel: [   79.511486] usbcore: registered new 
interface driver dvb_usb_nova_t_usb2
May 25 11:43:30 gandalf kernel: [  150.149787] usb 4-4: firmware: requesting 
dvb-usb-nova-t-usb2-02.fw
May 25 11:43:30 gandalf kernel: [  150.278343] dvb-usb: downloading firmware 
from file 'dvb-usb-nova-t-usb2-02.fw'

The problem I have is that vdr will start after the nova module is loaded but 
before the firmware is loaded. Unfortunately, vdr will not be able to detect 
the nova device so the dvb-t channels are not usable until vdr is restarted.

Where does this delay between module load and firmware upload comes from ?
Is there a way to reduce or supress this delay ?

All the best


--
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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-25 Thread Alan Stern
On Mon, 25 May 2009, David wrote:

 David wrote:
  Alan Stern wrote:

  Okay, here's a patch for you to try.  It refreshes the toggle setting 
  in a linked but otherwise idle QH when a new URB is queued.
 
  Alan Stern
 
 
  Index: usb-2.6/drivers/usb/host/ehci-q.c
  ===
  --- usb-2.6.orig/drivers/usb/host/ehci-q.c
  +++ usb-2.6/drivers/usb/host/ehci-q.c
  @@ -88,7 +88,7 @@ static inline void
   qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd 
  *qtd)
   {
 /* writes to an active overlay are unsafe */
  -  BUG_ON(qh-qh_state != QH_STATE_IDLE);
  +  BUG_ON(qh-qh_state != QH_STATE_IDLE  !list_empty(qh-qtd_list));
   
 qh-hw_qtd_next = QTD_NEXT(ehci, qtd-qtd_dma);
 qh-hw_alt_next = EHCI_LIST_END(ehci);
  @@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
 /* can't sleep here, we have ehci-lock... */
 qh = qh_make (ehci, urb, GFP_ATOMIC);
 *ptr = qh;
  +  } else if (list_empty(qh-qtd_list)) {
  +  /* There might have been a Clear-Halt while the QH
  +   * was linked but empty.
  +   */
  +  qh_refresh(ehci, qh);
 }
  +
 if (likely (qh != NULL)) {
 struct ehci_qtd *qtd;
   
 

  
  No luck I'm afraid (although there now appear to be 2 timeouts, not
  one). I'm going to follow up on the laptop and get a USB log.

 USB log post-patch attached. Thanks for all the effort so far!

Yes, the log shows two timeouts.  Maybe I misunderstood something and 
the patch only made the situation worse!

We may have to try a debugging patch to find out what's really 
happening here.  I'll get back to you on that...

Alan Stern

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


Strange PCI IDs

2009-05-25 Thread Nicolas Léveillé

Hello,

While discovering the bttv code (I'd like to add support to a yet 
unsupported bttv derivative, the PMS PDI Deluxe) I found a strange commit:


changeset:   10944:6b90215088f0
user:Mauro Carvalho Chehab mche...@redhat.com
date:Wed Mar 11 08:18:53 2009 -0300
summary: Conceptronic CTVFMI2 PCI Id

within: linux/drivers/media/video/bt8xx/bttv-cards.c

{ 0x109e036e, BTTV_BOARD_CONCEPTRONIC_CTVFMI2,  Conceptronic 
CTVFMi v2},


Does the above work at all for autodetecting this card?

The PCI ID looks suspiciously like a generic PCI ID, especially 
considering that:


  109e : vendor id for Brooktree Corporation
  036e : device id for Bt878 Video Capture

So I immediately was surprised to see the above PCI ID constant.

It does not appear it would cause any problem since the vendor and 
device ids are reversed anyway, however is this really correct? 
Shouldn't there be a comment about it?


Cheers,
Nicolas Léveillé


--
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: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-25 Thread hermann pitton
Hi,

Am Montag, den 25.05.2009, 21:34 +0200 schrieb Martin Dauskardt:
  #define TUNER_PHILIPS_FQ1216ME  24  /* you must actively select 
 B/G/D/K, I, L, L` */
  #define TUNER_PHILIPS_FQ1216AME_MK4 56  /* Hauppauge PVR-150 PAL */
  
  #define TUNER_PHILIPS_FM1216ME_MK3  38
  
  #define TUNER_PHILIPS_FMD1216ME_MK3 63
  #define TUNER_PHILIPS_FMD1216MEX_MK378
  #define TUNER_PHILIPS_FM1216MK5 79
  
  Could the user try one of those, starting with the FQ1216 tuner numbers
  (24 and 56), to see if one of them works?  For the FQ1261LME MK3,
  tveeprom has the FM1216ME_MK3 tuner number (38).
  
 
 I have this card now at home for testing. First results:
 
 #define TUNER_PHILIPS_FQ1216ME24  /* you must actively 
 select B/G/D/K, I, L, 
 Result: only static
 
 #define TUNER_PHILIPS_FM1216ME_MK338
 result: picture + sound o.k.
 
 #define TUNER_PHILIPS_FQ1216AME_MK4   56  /* Hauppauge PVR-150 PAL */
 result: picture o.k., but no sound
 
 #define TUNER_PHILIPS_FMD1216ME_MK3   63
 result: picture + sound o.k.
 
 #define TUNER_PHILIPS_FMD1216MEX_MK3  78
 result: picture + sound o.k.
 
 #define TUNER_PHILIPS_FM1216MK5 79
 result: picture o.k. , but audio disappears every few seconds (for about 1-2 
 seconds, then comes back) 
 
 tuner type 63 and 79 are Hybrid tuners. This is fore sure an analogue-only 
 tuner. The sticker says Multi-PAL, and according to VIDIOC_ENUMSTD  it 
 supports PAL, PAL-BG and PAL-H. 
 
 So I think 38 is right. Any suggestions for further tests?

in my opinion the entry of tuner type 24 is buggy.
I posted once about it, but it is long ago.

/*  TUNER_PHILIPS_FQ1216ME - Philips PAL  */

static struct tuner_params tuner_philips_fq1216me_params[] = {
{
.type   = TUNER_PARAM_TYPE_PAL,
.ranges = tuner_lg_pal_ranges,
.count  = ARRAY_SIZE(tuner_lg_pal_ranges),
.has_tda9887 = 1,
.port1_active = 1,
.port2_active = 1,
.port2_invert_for_secam_lc = 1,
},
};

At least tuner_lg_pal_ranges must be wrong for an MK3 and UHF should
fail, if you can test on that. Switch must be 0x04 and not 0x08.

The hybrid tuners are also not compatible to an FM1216ME/I MK3.
They miss some frequencies when used for such an one and some low VHF
channels are snowy. The tda9887 is also not visible on them without
special initialization in tuner-core.c for them. Likely not the case on
yours.

FQ types from Philips are without radio support. FM types have radio.
Also the FMD1216MEX_MK3 has a different radio IF, BTW.

Previously I did recommend tuner 56 for them, but now with the more
detailed tda988/5/6/7 settings it misses .port2_active = 1.
Hans likely knows that it is right and else we would have reports from
people using it I guess. Hm.

You could test with tda9887 port2=0, if you get sound on that one too.

If the entry is correct and can't be changed, we likely need a new tuner
entry or the TUNER_PHILIPS_FQ1216ME must use mk3 ranges on UHF. But on
that one I have some doubts at all. How could it happen, given how old
it is and previously without tda9887 at all, that the wrong UHF switch
is undiscovered until today?

Hm, the new MK5 has trouble with sound, FM anyway, but
TUNER_PHILIPS_FM1216MK5 is a complete clone of the FM1216ME MK3,
except for the discussed 1MHz change for UHF beginning and 0xce versus
0x8e. IIRC, 0xce should be even the better choice on tuners without
radio, but I need to look it up again or Andy is more aware about the
recent discussions. (faster tuning bit)

Maybe Dmitry has a datasheet for that one too.

One question, which might be interesting is the RF loop through.
Is it enabled by default or even switchable?

The latter would be reason enough to create a new tuner type I think.

Just some quick ideas. (ivtv will bounce me, not subscribed)

Cheers,
Hermann








--
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] Add QAM64 support for hvr-950q (au8522)

2009-05-25 Thread Frank Dischner
Hi Devin,

 Do you have the USB trace you used as the basis for this dump?  And
 did you programatically parse that dump to generate the table, or did
 you enter it by hand?  Could you please email me the underlying dump
 so I can double check the data?

I wrote a program to parse the trace and make it more readable, but I
entered the table by hand. Unfortunately, I no longer have any qam
traces. I can make a new one, if you'd like, but it'll have to wait
until I have time to install windows.

 I think the correct approach here would be to have three tables, a
 table of common registers, and two tables, one for each modulation
 type.  It would program the common registers first, and then pick the
 correct table to program the rest.  If we are concerned about the
 order that the registers are being programmed in, we can just setup
 the two tables so they start at the first register which is different
 (since it is almost at the bottom of the table anyway).

I didn't notice how similar they were when writing the patch, thanks
for pointing it out! I'll do some tests and see how much can be
combined into a common table.

While I'm at it, I thought I'd go ahead and make a patch to remove the
top bits from the vsb table, but I've got a question about that. I
think the first four entries are unnecessary. I'm pretty sure 8090 and
8091 have to do with the 8522's i2c controller and 4092 is a status
register. I have no idea what 2005 is, but the new code would change
it to A005 and I don't remember seeing either in any of the traces I
did (though I never did a vsb trace). Is this correct or am I missing
something? If I make a patch, can you or someone else test it for me?
(can't get a signal here)

Frank
--
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: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-25 Thread hermann pitton
Hi,

Am Montag, den 25.05.2009, 22:04 +0200 schrieb Martin Dauskardt:
 Am Montag, 25. Mai 2009 21:34:43 schrieb Martin Dauskardt:
 
  #define TUNER_PHILIPS_FM1216MK5 79
  result: picture o.k. , but audio disappears every few seconds (for about 
  1-2 
  seconds, then comes back) 
 
 correction: This is not a problem of tuner type 79. It happens also with 
 tuner 
 type 38. Sometimes the audio is also muted after the start of the 
 application. Only switching to another input and back brings the audio back.
 
 I am beginning to wonder if this problem may be related to a similar problem 
 with the PVRUSB2:
 http://www.isely.net/pipermail/pvrusb2/2009-May/002331.html
 
 If there is a problem with the new v4l2 sub-device mechanism, it seems to be 
 more specific to some devices than to others. With my PVR350 I didn't notice 
 such problems - although I remember that in **very** rare cases the audio 
 fails after a channel switch.  
 
 Greets, 
 Martin
 

Ah, good to know. You better stay around 2.6.28 for testing tuners then.

I have reported already difficult to debug bugs on 2.6.29 with _some_
devices and others on the same driver still work. I have again verified
that they for sure do work on 2.6.30-rc2-git4 yesterday.

Cheers,
Hermann

(ivtv list removed, re-add if appropriate)

--
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: Strange PCI IDs

2009-05-25 Thread hermann pitton
Hi,

Am Montag, den 25.05.2009, 23:26 +0200 schrieb Nicolas Léveillé:
 Hello,
 
 While discovering the bttv code (I'd like to add support to a yet 
 unsupported bttv derivative, the PMS PDI Deluxe) I found a strange commit:
 
 changeset:   10944:6b90215088f0
 user:Mauro Carvalho Chehab mche...@redhat.com
 date:Wed Mar 11 08:18:53 2009 -0300
 summary: Conceptronic CTVFMI2 PCI Id
 
 within: linux/drivers/media/video/bt8xx/bttv-cards.c
 
  { 0x109e036e, BTTV_BOARD_CONCEPTRONIC_CTVFMI2,  Conceptronic 
 CTVFMi v2},
 
 Does the above work at all for autodetecting this card?
 
 The PCI ID looks suspiciously like a generic PCI ID, especially 
 considering that:
 
109e : vendor id for Brooktree Corporation
036e : device id for Bt878 Video Capture
 
 So I immediately was surprised to see the above PCI ID constant.
 
 It does not appear it would cause any problem since the vendor and 
 device ids are reversed anyway, however is this really correct? 
 Shouldn't there be a comment about it?
 
 Cheers,
 Nicolas Léveillé
 

on the saa7134 driver we treat these sort of subsystem IDs, lots of
them, as invalid. One patch once made use of them and that part was
removed.

Cheers,
Hermann


--
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] Add QAM64 support for hvr-950q (au8522)

2009-05-25 Thread Devin Heitmueller
On Mon, May 25, 2009 at 6:03 PM, Frank Dischner
phaedrus...@googlemail.com wrote:
 While I'm at it, I thought I'd go ahead and make a patch to remove the
 top bits from the vsb table, but I've got a question about that. I
 think the first four entries are unnecessary. I'm pretty sure 8090 and
 8091 have to do with the 8522's i2c controller and 4092 is a status
 register. I have no idea what 2005 is, but the new code would change
 it to A005 and I don't remember seeing either in any of the traces I
 did (though I never did a vsb trace). Is this correct or am I missing
 something? If I make a patch, can you or someone else test it for me?
 (can't get a signal here)

Yeah, I noticed the 4092 entry.  The 4 means it's a read operation
so it almost certainly shouldn't be in the table.  I just haven't
taken the time to look closer at a Windows trace to see if it was
*really* a register read operation that got stuck into the table or
whether it was supposed to be a write operation.

I haven't reviewed the VSB table yes, so I am not sure about the other entries.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-25 Thread Pete Zaitcev
On Mon, 25 May 2009 13:25:55 +0100, David da...@unsolicited.net wrote:

  I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
  in arch/x86/Kconfig). Strange that it started happening now.
  
  That is enabled. I'll switch it off and give it another go.

 While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I
 guess there's nothing I can do to test?

I suppose so. I misunderstood how this worked. I guessed that the
DMA API debugging was the culprit because its introduction coincided
with the recent onset of this oops.

Although usbmon does essentially illegal tricks to look at data
already mapped for DMA, the code used to work for a few releases.
Bisecting may help. I cannot be sure of it though, and it's
going to take a lot of reboots.

Unfortunately, although I have an Opteron, the issue does not
occur here, so I'm at a loss for the moment. But I'll have to
tackle it somehow. Not sure how though. Any suggestions are welcome.

-- Pete
--
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: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-25 Thread hermann pitton
Hi,

Am Montag, den 25.05.2009, 23:45 +0200 schrieb hermann pitton:
 Hi,
 
 Am Montag, den 25.05.2009, 21:34 +0200 schrieb Martin Dauskardt:
   #define TUNER_PHILIPS_FQ1216ME  24  /* you must actively 
   select 
  B/G/D/K, I, L, L` */
   #define TUNER_PHILIPS_FQ1216AME_MK4 56  /* Hauppauge PVR-150 PAL 
   */
   
   #define TUNER_PHILIPS_FM1216ME_MK3  38
   
   #define TUNER_PHILIPS_FMD1216ME_MK3 63
   #define TUNER_PHILIPS_FMD1216MEX_MK378
   #define TUNER_PHILIPS_FM1216MK5 79
   
   Could the user try one of those, starting with the FQ1216 tuner numbers
   (24 and 56), to see if one of them works?  For the FQ1261LME MK3,
   tveeprom has the FM1216ME_MK3 tuner number (38).
   
  
  I have this card now at home for testing. First results:
  
  #define TUNER_PHILIPS_FQ1216ME  24  /* you must actively 
  select B/G/D/K, I, L, 
  Result: only static
  
  #define TUNER_PHILIPS_FM1216ME_MK3  38
  result: picture + sound o.k.
  
  #define TUNER_PHILIPS_FQ1216AME_MK4 56  /* Hauppauge PVR-150 PAL */
  result: picture o.k., but no sound
  
  #define TUNER_PHILIPS_FMD1216ME_MK3 63
  result: picture + sound o.k.
  
  #define TUNER_PHILIPS_FMD1216MEX_MK378
  result: picture + sound o.k.
  
  #define TUNER_PHILIPS_FM1216MK5 79
  result: picture o.k. , but audio disappears every few seconds (for about 
  1-2 
  seconds, then comes back) 
  
  tuner type 63 and 79 are Hybrid tuners. This is fore sure an analogue-only 
  tuner. The sticker says Multi-PAL, and according to VIDIOC_ENUMSTD  it 
  supports PAL, PAL-BG and PAL-H. 
  
  So I think 38 is right. Any suggestions for further tests?
 
 in my opinion the entry of tuner type 24 is buggy.
 I posted once about it, but it is long ago.
 
 /*  TUNER_PHILIPS_FQ1216ME - Philips PAL  */
 
 static struct tuner_params tuner_philips_fq1216me_params[] = {
   {
   .type   = TUNER_PARAM_TYPE_PAL,
   .ranges = tuner_lg_pal_ranges,
   .count  = ARRAY_SIZE(tuner_lg_pal_ranges),
   .has_tda9887 = 1,
   .port1_active = 1,
   .port2_active = 1,
   .port2_invert_for_secam_lc = 1,
   },
 };
 
 At least tuner_lg_pal_ranges must be wrong for an MK3 and UHF should
 fail, if you can test on that. Switch must be 0x04 and not 0x08.
 
 The hybrid tuners are also not compatible to an FM1216ME/I MK3.
 They miss some frequencies when used for such an one and some low VHF
 channels are snowy. The tda9887 is also not visible on them without
 special initialization in tuner-core.c for them. Likely not the case on
 yours.
 
 FQ types from Philips are without radio support. FM types have radio.
 Also the FMD1216MEX_MK3 has a different radio IF, BTW.
 
 Previously I did recommend tuner 56 for them, but now with the more
 detailed tda988/5/6/7 settings it misses .port2_active = 1.
 Hans likely knows that it is right and else we would have reports from
 people using it I guess. Hm.
 
 You could test with tda9887 port2=0, if you get sound on that one too.
 
 If the entry is correct and can't be changed, we likely need a new tuner
 entry or the TUNER_PHILIPS_FQ1216ME must use mk3 ranges on UHF. But on
 that one I have some doubts at all. How could it happen, given how old
 it is and previously without tda9887 at all, that the wrong UHF switch
 is undiscovered until today?
 
 Hm, the new MK5 has trouble with sound, FM anyway, but
 TUNER_PHILIPS_FM1216MK5 is a complete clone of the FM1216ME MK3,
 except for the discussed 1MHz change for UHF beginning and 0xce versus
 0x8e. IIRC, 0xce should be even the better choice on tuners without
 radio, but I need to look it up again or Andy is more aware about the
 recent discussions. (faster tuning bit)
 
 Maybe Dmitry has a datasheet for that one too.

for that MK5, I suggest to remove it completely to stay at some old
rules we did not ship with that bad so far.

We can change the UHF switch on the tuner 38 for that 1 MHz, it will not
cause any trouble, but that new entry only causes confusion and 0xce
should even be wrong for an FM tuner.

Dmitry, defend your stuff, if needed.

 One question, which might be interesting is the RF loop through.
 Is it enabled by default or even switchable?
 
 The latter would be reason enough to create a new tuner type I think.
 
 Just some quick ideas. (ivtv will bounce me, not subscribed)

Cheers,
Hermann




--
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: videodev: Unknown symbol i2c_unregister_device (in kernels older than 2.6.26)

2009-05-25 Thread Matt Doran

Andy Walls wrote:

On Sun, 2009-05-24 at 20:52 -0400, David Ward wrote:
  

On 05/24/2009 07:10 PM, Matt Doran wrote:


Hi there,

I tried using the latest v4l code on an Mythtv box running 2.6.20, but
the v4l videodev module fails to load with the following warnings:

   videodev: Unknown symbol i2c_unregister_device
   v4l2_common: Unknown symbol v4l2_device_register_subdev


It seems the i2c_unregister_device function was added in 2.6.26.
References to this function in v4l2-common.c are enclosed in an ifdef
like:

   #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)


However in v4l2_device_unregister() in v4l2-device.c, there is a
reference to i2c_unregister_device without any ifdefs.   I am
running a pretty old kernel, but I'd guess anyone running 2.6.25 or
earlier will have this problem.   It seems this code was added by
Mauro 3 weeks ago in this rev:

   http://linuxtv.org/hg/v4l-dvb/rev/87afa7a4ccdf

  
I have been seeing the errors compiling adv7343.c and ths7303.c under 
2.6.24 as well.  Andy Walls and Chaithrika Subrahmanya had written 
patches for those two modules respectively, but there were some comments 
during the review of the patches, so I think they are still being worked on.



Well, just to manage expectations: I am not working on this.  I do not
advise waiting for something from me. ;)


As an end user, you work-around is to use make menuconfig (or
whatever) as Matt did: disable the modules that aren't compiling on
older kernels.

  
I agree, but the main problem I raise is the use of 
i2c_unregister_device in the main v4l module on Linux kernels that 
don't support it.


Regards,
Matt

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


Problem with SCM/Viaccess CAM

2009-05-25 Thread Tomer Barletz
Hi,
When inserting a SCM/Viaccess CAM, I get the following message:
dvb_ca adapter 0: DVB CAM did not respond :(

According to this:
http://linuxtv.org/hg/v4l-dvb/file/142fd6020df3/linux/Documentation/dvb/ci.txt
this CAM should work.

I'm using kernel 2.6.10.

Any help would be greatly appreciated,
Tomer
--
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