date:20091031


Michael Hunold escreveu:

Hello Mauro,

on Mon, 28 Sep 2009 Johann Friedrichs sent a patch to linux-media in
order to fix a memory leak in my saa7146 driver.

He contacted me and together we have come up with a new patch that fixes
the problem more explicitely.

Would you please be so kind and manually pick up this patch and provide
it upstream?
  

No problem.

Applied, thanks!

All kudos belong to Johann Friedrich for finding the bug and providing
the initial fix.

Best regards
Michael Hunold.


  


--
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 5/8] drivers/media/video/uvc: Use %pUl to print UUIDs

Hi Laurent,

Em Mon, 12 Oct 2009 00:34:58 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:

 As this will go through the linuxtv v4l-dvb tree, I'll have to add backward
 compatibility code (that will not make it to mainline). If that's ok with you
 it will be easier for me to test and apply that part of the patch through my
 tree once the vsprintf extension gets in. 

I'm assuming that those printk patches from Joe to uvc will go via your tree,
so please submit a pull request when they'll be ready for upstream.




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: [PATCH] v4l2_subdev: rename tuner s_standby operation to core s_power

Em Mon, 12 Oct 2009 00:36:37 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:

 On Monday 05 October 2009 15:48:17 Laurent Pinchart wrote:
  Upcoming I2C v4l2_subdev drivers need a way to control the subdevice
  power state from the core. This use case is already partially covered by
  the tuner s_standby operation, but no way to explicitly come back from
  the standby state is available.
  
  Rename the tuner s_standby operation to core s_power, and fix tuner
  drivers accordingly. The tuner core will call s_power(0) instead of
  s_standby(). No explicit call to s_power(1) is required for tuners as
  they are supposed to wake up from standby automatically.
 
 Mauro, Hans told me he didn't see anything wrong with this patch. As there's 
 no negative feedback so far (but unfortunately no positive feedback either) 
 can it be applied ?

It seems ok to me also. Not only tuner devices need to control power, so it 
seems
better to have this as a core operation instead of a tuner specific one.

ACKED.

I've applied it at the tree, with a small codingstyle fix.

Hmm... mailimport script mangled the subject... I'll fix it on -git.



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: [PATCH]: Add support for Pinnacle PCTV310e card

Hi Massimo,

Em Sat, 24 Oct 2009 18:12:37 +0200
Massimo Del Fedele m...@veneto.com escreveu:

 This one adds support to Pinnacle PCTV310e hybrid tuner card,
 for DVB-T and remote control, still no analog video.

There are a few CodingStyle issues on your patch. Always chech them with
checkpatch.pl.

Also, you forgot your Signed-off-by. Please send it.



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: Hint request for driver change

Em Wed, 28 Oct 2009 18:50:14 + (UTC)
Massimo Del Fedele m...@veneto.com escreveu:

 Mauro Carvalho Chehab mchehab at infradead.org writes:
 
 
  
  It is better to not rename it, to avoid confusion.
 
 Thank you for the answer :-)
 The only problem is that rewriting the full driver I will not be able to test
 all card supported by previous one (I just own one of them).
 Anyways I'll start with mine than ask for some test for the others.

Rewriting the full driver is generally a bad idea, since you'll probably loose
fixes and cause regressions. The better is to incrementally fix it.

 BTW, did you see my patch for adding Pinnacle PCTV310e support (DVB only) in
 current driver ? Did I post it correctly or it miss something ?

I just sent you an email about that. Basically, you forgot a SOB and to do make
checkpatch



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: [PATCH] isl6421.c - added optional features: tone control and temporary diseqc overcurrent


HoP escreveu:

Hi,

this is my first kernel patch, so all comments are welcome.
  

First of all, please check all your patches with checkpatch, to be sure
that they don't have any CodingStyle troubles. There are some on your
patch (the better is to read README.patches for more info useful
for developers).

Attached patch adds two optional (so, disabled by default
and therefore could not break any compatibility) features:

1, tone_control=1
When enabled, ISL6421 overrides frontend's tone control
function (fe-ops.set_tone) by its own one.
  

On your comments, the better is to describe why someone would need
to use such option. You should also add a quick hint about that at the
option description.

2, overcurrent_enable=1
When enabled, overcurrent protection is disabled during
sending diseqc command. Such option is usable when ISL6421
catch overcurrent threshold and starts limiting output.
Note: protection is disabled only during sending
of diseqc command, until next set_tone() usage.
What typically means only max up to few hundreds of ms.
WARNING: overcurrent_enable=1 is dangerous
and can damage your device. Use with care
and only if you really know what you do.
  
I'm not sure if it is a good idea to have this... Why/when someone would 
need this?


If we go ahead and add this one, you should add a notice about it at the 
parameter.
I would also print a big WARNING message at the dmesg if the module were 
loaded

with this option turned on.

/Honza

Signed-off-by: Jan Petrous jpetr...@gmail.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: [RESEND PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

Em Sun, 11 Oct 2009 21:09:24 +0400
aos...@netup.ru aos...@netup.ru escreveu:

 Hello Mauro,
 
 On Friday 09 October 2009 16:01:58 Mauro Carvalho Chehab wrote:
  Wouldn't be be better to just use dvbtraffic userspace apps for it? 
 this feature very usable for debugging. Please add it.
 
  Also,
  your patch has some coding style issues.
 please point to this issues. I will fix.
 

 
 # HG changeset patch
 # User Abylay Ospan aos...@netup.ru
 # Date 1253802277 -14400
 # Node ID 711d9630876ffd81196c1032ce77825d5b433cc8
 # Parent a798c751f06d60335fbbad9fdca8c41f1298d228
 TS speed check. Logging transport stream speed in Kbits per second
 
 Signed-off-by: Abylay Ospan aos...@netup.ru
 
 --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.cWed Sep 23 10:21:53 
 2009 +0200
 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.cThu Sep 24 18:24:37 
 2009 +0400
 @@ -42,6 +42,11 @@
  module_param(dvb_demux_tscheck, int, 0644);
  MODULE_PARM_DESC(dvb_demux_tscheck,
   enable transport stream continuity and TEI check);
 +
 +static int dvb_demux_speedcheck;
 +module_param(dvb_demux_speedcheck, int, 0644);
 +MODULE_PARM_DESC(dvb_demux_speedcheck,
 + enable transport stream speed check);
  
  #define dprintk_tscheck(x...) do {  \
   if (dvb_demux_tscheck  printk_ratelimit())\
 @@ -385,6 +390,37 @@
   struct dvb_demux_feed *feed;
   u16 pid = ts_pid(buf);
   int dvr_done = 0;
 + struct timespec cur_time, delta_time;
 + u64 speed_bytes, speed_timedelta;
 +
 + if (dvb_demux_speedcheck) {
 + demux-speed_pkts_cnt++;
 +
 + /* show speed every SPEED_PKTS_INTERVAL packets */
 + if (!(demux-speed_pkts_cnt%SPEED_PKTS_INTERVAL)) {

You need to add spaces between each argument of the % operator

 + cur_time = current_kernel_time();
 +
 + if (demux-speed_last_time.tv_sec != 0 
 + demux-speed_last_time.tv_nsec != 0) {
 + delta_time = timespec_sub(cur_time,
 + demux-speed_last_time);
 + speed_bytes = (u64)demux-speed_pkts_cnt*188*8;

You need to add spaces between each argument of the * operator

 + /* convert to 1024 basis */
 + speed_bytes = 1000*div64_u64(speed_bytes,
 + 1024);

You need to add spaces between each argument of the * operator

 + speed_timedelta =
 + (u64)timespec_to_ns(delta_time);
 + speed_timedelta = div64_u64(speed_timedelta,
 + 100); /* nsec - usec */
 + printk(KERN_INFO TS speed %llu Kbits/sec \n,
 + div64_u64(speed_bytes,
 + speed_timedelta));
 + };
 +
 + demux-speed_last_time = cur_time;
 + demux-speed_pkts_cnt = 0;
 + };
 + };
  
   if (dvb_demux_tscheck) {
   if (!demux-cnt_storage)
 --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.hWed Sep 23 10:21:53 
 2009 +0200
 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.hThu Sep 24 18:24:37 
 2009 +0400
 @@ -44,6 +44,7 @@
  #define DVB_DEMUX_MASK_MAX 18
  
  #define MAX_PID 0x1fff
 +#define SPEED_PKTS_INTERVAL 5
  
  struct dvb_demux_filter {
   struct dmx_section_filter filter;
 @@ -132,6 +133,9 @@
   spinlock_t lock;
  
   uint8_t *cnt_storage; /* for TS continuity check */
 +
 + struct timespec speed_last_time; /* for TS speed check */
 + uint32_t speed_pkts_cnt; /* for TS speed check */
  };
  
  int dvb_dmx_init(struct dvb_demux *dvbdemux);
 




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: Leadtek DTV-1000S

2009-10-31 Thread hermann pitton

Hi Mike, Mauro,

Am Mittwoch, den 21.10.2009, 15:33 -0400 schrieb Michael Krufky:
 On Wed, Oct 21, 2009 at 5:19 AM, Ryan Day ryan@uq.edu.au wrote:
  Michael-
  I wanted to see if you might be able to assist in getting a DTV-1000S to
  work.  I followed the instructions on the Whirlpool forum (DL the firmware,
  cp it to /lib/firmware, dl the dtv-1000s files from kernellabs.com, untar,
  make, make install, reboot), and everything looks good when I install, but
  when I reboot, the boot up hangs and eventually freezes.
 
  I thought reinstalling might give me a better chance for success with a
  clean slate to work with, but the problem continues.  Unfortunately, I don't
  have any of the error logs or anything, as I reinstalled.
 
  I can't remember the message at the first hang, but the freeze is caused by
  a failure to load the LIRC module.
 
  Also of note is that I'm installing this card as a second tuner.  I have a
  DTV-2000H already installed.  I don't know if that changes anything.
 
  Sorry I can't provide better info, but any advice you can give would be
  great.
 
 Ryan,
 
 This is really a question for the linux-media mailing list, so I've
 added it in cc -- please use REPLY-TO-ALL in your correspondence, so
 that anybody else that may have seen this issue can chime in with
 their advice, or perhaps they may benefit themselves simply by reading
 your problem description.  Also, please remember that your response on
 the mailing list should appear below the quoted thread.
 
 Meanwhile, why would failure to load the LIRC module cause a problem
 on your board, causing a system hang... Sounds fishy to me -- are you
 sure about this?
 
 Have you tried deleting / blacklisting the module that you believe to
 be freezing your system?
 
 Have you tried moving your PCI card to another slot?
 
 Have you google'd for other users of your motherboard who might be
 suffering from similar issues?
 
 I updated the dtv1000s tree yesterday, with the intention of getting
 it merged into the master branch.  Perhaps there is a bug in the new
 repository that is not present in the old repository?
 
 The current repository that you probably have already tested is located here:
 
 http://kernellabs.com/hg/~mkrufky/dtv1000s

there is another report for problems with the DTV-1000S now.

Checking the above and the master tree, it turns out that the card's
analog entry made it into the #if 0 flyvideo tweaks in saa7134-cards.c
and is not valid there.

Have to leave the house now, Mike please fix it or I'll send a fix when
back later in the evening.

Cheers,
Hermann

 
 The only difference in the new tree when compared to the older tree,
 is that I've pulled in the latest v4l-dvb core changes from the master
 branch on linuxtv.org, and updated the DTV1000S patch to account for
 the latest board additions in the saa7134 driver.  The dtv1000s
 support itself hasn't changed at all.  To eliminate this as a possible
 cause, you can try testing the older tree, instead.  The older tree
 that has already been tested by other users of both flavors of this
 dtv1000s board is located here:
 
 http://kernellabs.com/hg/~mkrufky/dtv1000s.old
 
 If the older repository works but the new one doesn't, that would
 indicate that there is a problem in the master v4l-dvb repository.
 
 If all else fails, try removing the other board that you have
 installed, and see if that is a factor in this problem
 
 Please test and report your findings back to the mailing list as a
 reply-to-all response in this thread.
 
 I hope this helps.
 
 Regards,
 
 Mike Krufky


--
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-S2 card recommendation?

2009-10-31 Thread Michael Durket


Is there a DVB-S2 card on the market yet with these features:

1) DVB-S2 (QPSK, 8PSK) and DVB-S modes fully supported in Linux
(i.e. not experimental, not requiring sifting through  
different driver sources

to try to find one that works)

2) Has no software/hardware data rate limitations (i.e. all  
symbol rates supported, no problems locking

any symbol rate the card supports)

3) Available to U.S. purchasers (no country restrictions when  
trying to buy the card)


4) Delivers a full transport stream without filtering of any kind  
by the hardware.

--
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] somebody messed something on xc2028 code?

2009-10-31 Thread Devin Heitmueller

On Sat, Oct 31, 2009 at 8:35 AM, Albert Comerma
albert.come...@gmail.com wrote:
 Hi all, I just updated my ubuntu to karmic and found with surprise that with
 2.6.31 kernel my device does not work... It seems to be related to the
 xc2028 code part since the kernel explosion happens when you try to tune the
 device, here it's my dmesg, any idea?

 Albert

 [ 1622.032196] usb 1-1: new high speed USB device using ehci_hcd and address
 4
 [ 1622.166041] usb 1-1: configuration #1 chosen from 1 choice
 [ 1622.167341] dvb-usb: found a 'Pinnacle Expresscard 320cx' in cold state,
 will try to load a firmware
 [ 1622.167353] usb 1-1: firmware: requesting dvb-usb-dib0700-1.20.fw
 [ 1622.188465] dvb-usb: downloading firmware from file
 'dvb-usb-dib0700-1.20.fw'
 [ 1622.396737] dib0700: firmware started successfully.
 [ 1622.900198] dvb-usb: found a 'Pinnacle Expresscard 320cx' in warm state.
 [ 1622.900308] dvb-usb: will pass the complete MPEG2 transport stream to the
 software demuxer.
 [ 1622.900759] DVB: registering new adapter (Pinnacle Expresscard 320cx)
 [ 1623.157839] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
 [ 1623.158165] xc2028 4-0061: creating new instance
 [ 1623.158173] xc2028 4-0061: type set to XCeive xc2028/xc3028 tuner
 [ 1623.158333] input: IR-receiver inside an USB DVB receiver as
 /devices/pci:00/:00:1a.7/usb1/1-1/input/input16
 [ 1623.158418] dvb-usb: schedule remote query interval to 50 msecs.
 [ 1623.158427] dvb-usb: Pinnacle Expresscard 320cx successfully initialized
 and connected.
 [ 1670.979678] CE: hpet increasing min_delta_ns to 15000 nsec
 [ 1753.316527] BUG: unable to handle kernel NULL pointer dereference at
 0008
 [ 1753.316543] IP: [c03a8a13] _request_firmware+0x1f3/0x250
 [ 1753.316562] *pde = 
 [ 1753.316570] Oops:  [#2] SMP
 [ 1753.316578] last sysfs file:
 /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/charge_full
 [ 1753.316586] Modules linked in: tuner_xc2028 dvb_usb_dib0700 dib7000p
 dib7000m dvb_usb dvb_core dib3000mc dibx000_common dib0070 hidp binfmt_misc
 vboxnetflt vboxnetadp vboxdrv ppdev parport_pc snd_hda_codec_idt
 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4
 ecb snd_seq_dummy snd_seq_oss iwlagn bridge stp bnep snd_seq_midi iwlcore
 snd_rawmidi joydev iptable_nat snd_seq_midi_event mac80211 nf_nat snd_seq
 nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 snd_timer snd_seq_device
 iptable_mangle snd sbp2 dell_wmi psmouse iptable_filter serio_raw ip_tables
 soundcore x_tables snd_page_alloc cfg80211 uvcvideo videodev v4l1_compat
 sdhci_pci sdhci led_class lp btusb dell_laptop dcdbas nvidia(P) parport
 usbhid dm_raid45 xor ohci1394 video output ieee1394 tg3 intel_agp agpgart
 [ 1753.316753]

This was actually a regression related to the dib7000 driver and any
tuner that uses request_firmware().  I checked in a fix for one board
that hit it.  It was introduced because 2.6.28 started using the first
parameter passed to request_firmware(), and the dib7000 driver was
sending null.

Can you clarify which bridge your device uses.

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

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

2009-10-31 Thread Erik Andrén

Mauro,

The following three commits add some additional vertical flip quirks
for the s5k4aa sensor.
IMHO, they are 2.6.32 material.

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

for the following 3 changesets:

01/03: gspca - m5602-s5k4aa: Add vflip quirk for the Bruneinit laptop
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=3cf50d4a5aab

02/03: gspca - m5602-s5k4aa: Add another MSI GX700 vflip quirk
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=8962d339d10c

03/03: gspca - m5602-s5k4aa: Add vflip for Fujitsu Amilo Xi 2528
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=759c2c11b860


 m5602_s5k4aa.c |   20 
 1 file changed, 20 insertions(+)

Thanks,
Erik
--
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] somebody messed something on xc2028 code?

2009-10-31 Thread Devin Heitmueller

On Sat, Oct 31, 2009 at 8:35 AM, Albert Comerma
albert.come...@gmail.com wrote:
 Hi all, I just updated my ubuntu to karmic and found with surprise that with
 2.6.31 kernel my device does not work... It seems to be related to the
 xc2028 code part since the kernel explosion happens when you try to tune the
 device, here it's my dmesg, any idea?

 Albert

Oh, you're using the stock 2.6.31 which didn't get my fix yet.  Please
try the latest v4l-dvb tree and see if it still happens.

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: Leadtek DTV-1000S

On Sat, Oct 31, 2009 at 11:24 AM, hermann pitton
hermann-pit...@arcor.de wrote:
 Hi Mike, Mauro,

 Am Mittwoch, den 21.10.2009, 15:33 -0400 schrieb Michael Krufky:
 On Wed, Oct 21, 2009 at 5:19 AM, Ryan Day ryan@uq.edu.au wrote:
  Michael-
  I wanted to see if you might be able to assist in getting a DTV-1000S to
  work.  I followed the instructions on the Whirlpool forum (DL the firmware,
  cp it to /lib/firmware, dl the dtv-1000s files from kernellabs.com, untar,
  make, make install, reboot), and everything looks good when I install, but
  when I reboot, the boot up hangs and eventually freezes.
 
  I thought reinstalling might give me a better chance for success with a
  clean slate to work with, but the problem continues.  Unfortunately, I 
  don't
  have any of the error logs or anything, as I reinstalled.
 
  I can't remember the message at the first hang, but the freeze is caused by
  a failure to load the LIRC module.
 
  Also of note is that I'm installing this card as a second tuner.  I have a
  DTV-2000H already installed.  I don't know if that changes anything.
 
  Sorry I can't provide better info, but any advice you can give would be
  great.


 there is another report for problems with the DTV-1000S now.

 Checking the above and the master tree, it turns out that the card's
 analog entry made it into the #if 0 flyvideo tweaks in saa7134-cards.c
 and is not valid there.

 Have to leave the house now, Mike please fix it or I'll send a fix when
 back later in the evening.

 Cheers,
 Hermann


Thanks for spotting this, Hermann ...  I just fixed the problem and
pushed it to my DTV1000S tree.  I'll issue a pull request to Mauro
right now.

Cheers,

Mike
--
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://kernellabs.com/hg/~mkrufky/dtv1000s

Mauro,

Something went wrong in the merging of the DTV1000S patch.  Hermann
noticed the problem and pointed it out.  The fix is waiting in my
tree.

Please pull from:

http://kernellabs.com/hg/~mkrufky/dtv1000s

for:

- saa7134: fix badly merged DTV1000S patch

 saa7134-cards.c |   32 
 1 file changed, 16 insertions(+), 16 deletions(-)

Cheers,

Mike
--
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/~mkrufky/dtv1000s

On Sat, Oct 31, 2009 at 12:51 PM, Michael Krufky mkru...@kernellabs.com wrote:
 Please pull from:

 http://kernellabs.com/hg/~mkrufky/dtv1000s

 for:

 - saa7134: fix badly merged DTV1000S patch

  saa7134-cards.c |   32 
  1 file changed, 16 insertions(+), 16 deletions(-)

I sent this pull request out too quickly -- I just added a patch for
Leadtek Winfast DTV-1000S remote control, thanks to Michael Obst.

Please pull, for:

- saa7134: fix badly merged DTV1000S patch
- saa7134: add support for Leadtek Winfast DTV-1000S remote control

 common/ir-keymaps.c   |1 +
 video/saa7134/saa7134-cards.c |   33 +
 video/saa7134/saa7134-input.c |6 ++
 3 files changed, 24 insertions(+), 16 deletions(-)

Thanks,

Mike
--
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: Leadtek Winfast DTV-1000S remote control support

On Thu, Oct 29, 2009 at 9:33 AM, Michael Carl Obst
m.o...@ugrad.unimelb.edu.au wrote:
 I am having trouble with the current repository, I can build and install
 it fine but I can't insert the modules, I'm getting two different errors
 which I haven't looked into yet. I have regenerated the patch anyway and
 it builds fine but due to the other problems have not been able to check
 it is still working (although I see no reason why it wouldn't).

As you may have seen from the other email thread, there was a problem
in the way that the DTV1000S patch was merged.  Thanks to Hermann for
pointing it out, I fixed the DTV1000S tree, and added your remote
control patch.  Hopefully Mauro will merge it soon.

If you see any more problems, please let us know.

Cheers,

Mike
--
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] Possible error in firedtv-1394.o?

2009-10-31 Thread Andreas Breitbach

Huge thanks Devin,

now it's working again.

Andy

Am Freitag, den 30.10.2009, 15:53 -0400 schrieb Devin Heitmueller:
 On Fri, Oct 30, 2009 at 3:48 PM, Andreas Breitbach
 andreas.breitb...@gmail.com wrote:
  Hello all.
 
  I subscribed to this mailing list to report a possible error in the
  above mentioned module. For your better understanding, some details
  about my situation: I upgraded yesterday from Jaunty(Ubuntu) to the new
  Karmic. I had a 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE DVB-T
  Receiver(lsusb output), which worked with the drivers avaible from
  http://linuxtv.org/hg/~anttip/. After the upgrade, I tried to compile
  and install the modules necessary for the stick by entering make all.
  It compiles til reaching firedtv-1394.o, I attached the output, which
  complains about this specific module.
  As I'm not a programmer, but rather a normal user who clued together how
  to get this stick working once, I fear I can not be of much help in
  debugging. Nonetheless, I'd be very interested in knowing about the
  status of this and when my TV will be back working(or how I could
  circumvent this error).
 
 Hi Andy,
 
 Yeah, this is a known issue with the build process under Karmic.  The
 iee1394 is enabled by default but Karmic's packaging of the kernel
 headers is missing some files that are needed by the firedtv driver.
 
 To workaround the issue, I usually just open v4l/.config and change
 the firedtv driver from =m to =n.
 
 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: Tunning information of Granada, Spain

2009-10-31 Thread Christoph Pfister

2009/10/30 David Fernández dgva...@gmail.com:
 The attached file es-Granada is the tunning information of my city:
 Granada (Spain)
 (Location: 37,183334 N - 3,78 W)

 Could someone please add this information to the dvb-apps repository?

Added, thanks.

 Thanks.

Christoph
--
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] v4l2_subdev: rename tuner s_standby operation to core s_power

2009-10-31 Thread Laurent Pinchart

On Saturday 31 October 2009 10:13:22 Mauro Carvalho Chehab wrote:
 Em Mon, 12 Oct 2009 00:36:37 +0200
 
 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
  On Monday 05 October 2009 15:48:17 Laurent Pinchart wrote:
   Upcoming I2C v4l2_subdev drivers need a way to control the subdevice
   power state from the core. This use case is already partially covered
   by the tuner s_standby operation, but no way to explicitly come back
   from the standby state is available.
  
   Rename the tuner s_standby operation to core s_power, and fix tuner
   drivers accordingly. The tuner core will call s_power(0) instead of
   s_standby(). No explicit call to s_power(1) is required for tuners as
   they are supposed to wake up from standby automatically.
 
  Mauro, Hans told me he didn't see anything wrong with this patch. As
  there's no negative feedback so far (but unfortunately no positive
  feedback either) can it be applied ?
 
 It seems ok to me also. Not only tuner devices need to control power, so it
  seems better to have this as a core operation instead of a tuner specific
  one.
 
 ACKED.
 
 I've applied it at the tree, with a small codingstyle fix.
 
 Hmm... mailimport script mangled the subject... I'll fix it on -git.

Thanks.

-- 
Regards,

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

[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-10-31 Thread Hans Verkuil

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sat Oct 31 19:00:07 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13254:a76d06e9ff9b
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: WARNINGS
linux-2.6.23.12-armv5: WARNINGS
linux-2.6.24.7-armv5: WARNINGS
linux-2.6.25.11-armv5: WARNINGS
linux-2.6.26-armv5: WARNINGS
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29.1-armv5: OK
linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-rc3-armv5: ERRORS
linux-2.6.32-rc3-armv5-davinci: ERRORS
linux-2.6.27-armv5-ixp: OK
linux-2.6.28-armv5-ixp: OK
linux-2.6.29.1-armv5-ixp: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-rc3-armv5-ixp: ERRORS
linux-2.6.28-armv5-omap2: OK
linux-2.6.29.1-armv5-omap2: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: ERRORS
linux-2.6.32-rc3-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.32-rc3-i686: ERRORS
linux-2.6.23.12-m32r: WARNINGS
linux-2.6.24.7-m32r: WARNINGS
linux-2.6.25.11-m32r: WARNINGS
linux-2.6.26-m32r: WARNINGS
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-rc3-m32r: ERRORS
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-rc3-mips: ERRORS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-rc3-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-rc3-x86_64: ERRORS
sparse (linux-2.6.31): OK
sparse (linux-2.6.32-rc3): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L2 specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
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 5/8] drivers/media/video/uvc: Use %pUl to print UUIDs

2009-10-31 Thread Joe Perches

On Sat, 2009-10-31 at 20:10 +0100, Laurent Pinchart wrote:
 On Saturday 31 October 2009 10:07:01 Mauro Carvalho Chehab wrote:
  I'm assuming that those printk patches from Joe to uvc will go via your
   tree, so please submit a pull request when they'll be ready for upstream.
 I'll submit the pull request as soon as the printk core patch hits upstream.

I believe Andrew Morton has picked up the patches for
his mm-commits set.  If you do nothing, these should
show up in Linus' tree after awhile.

lib-vsprintfc-add-%pu-to-print-uuid-guids.patch
fs-xfs-xfs_log_recoverc-use-%pu-to-print-uuids.patch
randomc-use-%pu-to-print-uuids.patch
drivers-firmware-dmi_scanc-use-%pub-to-print-uuids.patch
drivers-md-mdc-use-%pu-to-print-uuids.patch
fs-gfs2-sysc-use-%pub-to-print-uuids.patch
fs-ubifs-use-%pub-to-print-uuids.patch
efih-use-%pul-to-print-uuids.patch
drivers-media-video-uvc-use-%pul-to-print-uuids.patch
lib-unified-uuid-guid-definition.patch
gfs2-use-unified-uuid-guid-code.patch


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

cx18: YUV frame alignment improvements

2009-10-31 Thread Andy Walls

All,

At

http://linuxtv.org/hg/~awalls/cx18-yuv

I have checked in some improvements to YUV handling in the cx18
driver.  

There was a problem in that a lost/dropped buffer between the cx18
driver and the CX23418 firmware would cause the video frame alignment to
be lost with no easy way to recover.

These changes do the following:

1. Force YUV buffer sizes to be large enough to hold either 1 full 525
line system frame or 1 full 625 line system frame with new module
options and defaults.  That makes the YUV buffers quite large, but
allows for 1 frame per buffer for full sized video frames.

2. Not being able to allocate the now large YUV buffers is non-fatal.
The driver will still load and work for other stream types, even if it
can't get the YUV buffers.  A warning is blurted out in the log, in case
YUV buffers can't be allocated.

3. __GFP_REPEAT has been added when trying to make the initial video
buffer allocations.  After I added this, I never had the large YUV
buffers fail to be allocated.

4. We now lie to the firmware about the actual YUV buffer size, so that
the firmware always thinks the buffers are exactly large enough to hold
exactly an integral number of YUV frames based on the image height.
This means that dropped/lost YUV buffers between the cx18 driver and the
CX23418 firmware will only drop whole frames and no misalignment should
occur.


# modinfo cx18
[...]
parm:   enc_yuv_buffers:Encoder YUV buffer memory (MB). (enc_yuv_bufs 
can override)
Default: 3 (int)
parm:   enc_yuv_bufsize:Size of an encoder YUV buffer (kB)
Allowed values:
  0 (do not allocate YUV buffers)
507 (when never capturing 625 line systems)
608 (when capturing 625 and/or 525 line systems)
Default: 608 (int)
parm:   enc_yuv_bufs:Number of encoder YUV buffers
Default is computed from other enc_yuv_* parameters 
(int)
[...]

# modprobe cx18
# mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc


You can add 'debug=264' to the modprobe line to watch the size of the
payloads coming back from the firmware to make sure they are an integral
number of frames, but logging stats on every noticably degrades
performance.

Regards,
Andy

--
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: cx18: YUV frame alignment improvements

2009-10-31 Thread Devin Heitmueller

On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls awa...@radix.net wrote:
All,

http://linuxtv.org/hg/~awalls/cx18-yuv

I have checked in some improvements to YUV handling in the cx18
driver.

There was a problem in that a lost/dropped buffer between the cx18
driver and the CX23418 firmware would cause the video frame alignment to
be lost with no easy way to recover.

These changes do the following:

1. Force YUV buffer sizes to be large enough to hold either 1 full 525
line system frame or 1 full 625 line system frame with new module
options and defaults. That makes the YUV buffers quite large, but
allows for 1 frame per buffer for full sized video frames.

2. Not being able to allocate the now large YUV buffers is non-fatal.
The driver will still load and work for other stream types, even if it
can't get the YUV buffers. A warning is blurted out in the log, in case
YUV buffers can't be allocated.

3. __GFP_REPEAT has been added when trying to make the initial video
buffer allocations. After I added this, I never had the large YUV
buffers fail to be allocated.

4. We now lie to the firmware about the actual YUV buffer size, so that
the firmware always thinks the buffers are exactly large enough to hold
exactly an integral number of YUV frames based on the image height.
This means that dropped/lost YUV buffers between the cx18 driver and the
CX23418 firmware will only drop whole frames and no misalignment should
occur.

# modinfo cx18
[...]
parm: enc_yuv_buffers:Encoder YUV buffer memory (MB). (enc_yuv_bufs
can override)
Default: 3 (int)
parm: enc_yuv_bufsize:Size of an encoder YUV buffer (kB)
Allowed values:
0 (do not allocate YUV buffers)
507 (when never capturing 625 line systems)
608 (when capturing 625 and/or 525 line
systems)
Default: 608 (int)
parm: enc_yuv_bufs:Number of encoder YUV buffers
Default is computed from other enc_yuv_* parameters
(int)
[...]

# modprobe cx18
# mplayer /dev/video32 -demuxer rawvideo -rawvideo
w=720:h=480:format=hm12:ntsc

You can add 'debug=264' to the modprobe line to watch the size of the
payloads coming back from the firmware to make sure they are an integral
number of frames, but logging stats on every noticably degrades
performance.

Regards,
Andy

Hi Andy,

How does this code work if the cx23418 scaler is used (resulting in
the size of the frames to be non-constant)? Or is the scaler not
currently supported in the driver?

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: Leadtek DTV-1000S

2009-10-31 Thread Michael Obst

Hi,
Thanks for fixing this, I can confirm that it now compiles and
inserts and the remote works, so does the av input to the tvcard
however the card does not seem to be able to tune any channels, I have
checked the old driver and that is still able to tune in channels. The
output from my dmesg is below.

Thanks
Michael Obst

[  502.761860] saa7130/34: v4l2 driver version 0.2.15 loaded
[  502.761886] saa7130[0]: found at :04:01.0, rev: 1, irq: 17,
latency: 64, mmio: 0xfebffc00
[  502.761890] saa7130[0]: subsystem: 107d:6655, board: Leadtek
Winfast DTV1000S [card=175,autodetected]
[  502.761898] saa7130[0]: board init: gpio is 2121400
[  502.761938] input: saa7134 IR (Leadtek Winfast DTV as
/devices/pci:00/:00:1e.0/:04:01.0/input/input10
[  502.761966] IRQ 17/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[  502.912003] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43
43 a9 1c 55 d2 b2 92
[  502.912009] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff
ff ff ff ff ff ff ff
[  502.912014] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08
ff 00 8a ff ff ff ff
[  502.912019] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912024] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff
04 ff ff ff ff ff ff
[  502.912029] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912034] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912040] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912045] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912050] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912055] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912060] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912065] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912070] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912075] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.912080] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[  502.928502] Chip ID is not zero. It is not a TEA5767
[  502.928544] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
[  502.960501] tda8290: no gate control were provided!
[  502.960589] saa7130[0]: registered device video0 [v4l2]
[  502.960602] saa7130[0]: registered device vbi0
[  502.963002] saa7134 ALSA driver for DMA sound loaded
[  502.963003] saa7130[0]/alsa: Leadtek Winfast DTV1000S doesn't
support digital audio
[  502.963600] dvb_init() allocating 1 frontend
[  503.032771] tda18271 0-0060: creating new instance
[  503.040502] TDA18271HD/C2 detected @ 0-0060
[  503.436003] DVB: registering new adapter (saa7130[0])
[  503.436006] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)...
[  503.764502] tda10048_firmware_upload: waiting for firmware upload
(dvb-fe-tda10048-1.0.fw)...
[  503.764506] saa7134 :04:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw
[  503.766223] tda10048_firmware_upload: firmware read 24878 bytes.
[  503.766224] tda10048_firmware_upload: firmware uploading
[  507.844010] tda10048_firmware_upload: firmware uploaded

2009/11/1 Michael Krufky mkru...@kernellabs.com:
 On Sat, Oct 31, 2009 at 11:24 AM, hermann pitton
 hermann-pit...@arcor.de wrote:
 Hi Mike, Mauro,

 Am Mittwoch, den 21.10.2009, 15:33 -0400 schrieb Michael Krufky:
 On Wed, Oct 21, 2009 at 5:19 AM, Ryan Day ryan@uq.edu.au wrote:
  Michael-
  I wanted to see if you might be able to assist in getting a DTV-1000S to
  work.  I followed the instructions on the Whirlpool forum (DL the 
  firmware,
  cp it to /lib/firmware, dl the dtv-1000s files from kernellabs.com, untar,
  make, make install, reboot), and everything looks good when I install, but
  when I reboot, the boot up hangs and eventually freezes.
 
  I thought reinstalling might give me a better chance for success with a
  clean slate to work with, but the problem continues.  Unfortunately, I 
  don't
  have any of the error logs or anything, as I reinstalled.
 
  I can't remember the message at the first hang, but the freeze is caused 
  by
  a failure to load the LIRC module.
 
  Also of note is that I'm installing this card as a second tuner.  I have a
  DTV-2000H already installed.  I don't know if that changes anything.
 
  Sorry I can't provide better info, but any advice you can give would be
  great.


 there is another report for problems with the DTV-1000S now.

 Checking the above and the master tree, it turns out that the card's
 analog entry made it into the #if 0 flyvideo tweaks in saa7134-cards.c
 and is not valid there.

 Have to leave the house now, Mike please fix it or I'll send a fix when
 back later in the evening.

 Cheers,
 Hermann


 Thanks for spotting this, Hermann ...  I

Re: Leadtek DTV-1000S

On Sat, Oct 31, 2009 at 6:08 PM, Michael Obst
m.o...@ugrad.unimelb.edu.au wrote:
 Hi,
    Thanks for fixing this, I can confirm that it now compiles and
 inserts and the remote works, so does the av input to the tvcard
 however the card does not seem to be able to tune any channels, I have
 checked the old driver and that is still able to tune in channels. The
 output from my dmesg is below.

 Thanks
 Michael Obst

Michael,

This is an interesting problem -- the part of your dmesg that stands
out to me is this:

 [  502.928544] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
 [  502.960501] tda8290: no gate control were provided!

That error message was added as a safety measure -- it shouldn't be
possible to ever hit that code path.  Are you running any non-GPL
binary drivers on your system, such as NVIDIA or anything else?

Let me explain:

The no gate control were provided! message was added by Mauro to the
tda8290 driver, mainly as a check to ensure that we don't call a null
function pointer.  The gate control is actually provided by the
tda8290 driver itself, by either tda8290_i2c_bridge or
tda8295_i2c_bridge, depending on which hardware is present.  In your
case, it's a tda8290.

The function pointer is filled during the tda829x_attach() function,
before we call the tda829x_find_tuner function, where this error
message is displayed.  The only way for this to have occurred, as far
as I can tell,  is if the probe to detect the tda8290 itself had
failed.

Have you repeated your test with the same problem each time, or did
this only happen once?

Can you try again, from a cold reboot?

Also, I'm just assuming that this failure occurred during a digital
tune -- is that correct?  Does analog television work?

If the problem is reproducible, can you also show us dmesg during a failed tune?

I'm very interested in hearing more about this -- please let me know.

Regards,

Mike
--
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: Leadtek DTV-1000S

On Sat, Oct 31, 2009 at 6:43 PM, Michael Krufky mkru...@kernellabs.com wrote:
 On Sat, Oct 31, 2009 at 6:08 PM, Michael Obst
 m.o...@ugrad.unimelb.edu.au wrote:
 Hi,
    Thanks for fixing this, I can confirm that it now compiles and
 inserts and the remote works, so does the av input to the tvcard
 however the card does not seem to be able to tune any channels, I have
 checked the old driver and that is still able to tune in channels. The
 output from my dmesg is below.

 Thanks
 Michael Obst

 Michael,

 This is an interesting problem -- the part of your dmesg that stands
 out to me is this:

 [  502.928544] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
 [  502.960501] tda8290: no gate control were provided!

 That error message was added as a safety measure -- it shouldn't be
 possible to ever hit that code path.  Are you running any non-GPL
 binary drivers on your system, such as NVIDIA or anything else?

 Let me explain:

 The no gate control were provided! message was added by Mauro to the
 tda8290 driver, mainly as a check to ensure that we don't call a null
 function pointer.  The gate control is actually provided by the
 tda8290 driver itself, by either tda8290_i2c_bridge or
 tda8295_i2c_bridge, depending on which hardware is present.  In your
 case, it's a tda8290.

 The function pointer is filled during the tda829x_attach() function,
 before we call the tda829x_find_tuner function, where this error
 message is displayed.  The only way for this to have occurred, as far
 as I can tell,  is if the probe to detect the tda8290 itself had
 failed.

 Have you repeated your test with the same problem each time, or did
 this only happen once?

 Can you try again, from a cold reboot?

 Also, I'm just assuming that this failure occurred during a digital
 tune -- is that correct?  Does analog television work?

 If the problem is reproducible, can you also show us dmesg during a failed 
 tune?

 I'm very interested in hearing more about this -- please let me know.

Oops, on second look, seems that the error occurred during analog
bring-up ... does digital tv work?

-Mike
--
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: em28xx DVB modeswitching change: call for testers

2009-10-31 Thread Alain Perrot

On Wed, Oct 14, 2009 at 4:52 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 Hello all,

 I have setup a tree that removes the mode switching code when
 starting/stopping streaming.  If you have one of the em28xx dvb
 devices mentioned in the previous thread and volunteered to test,
 please try out the following tree:

 http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch

 In particular, this should work for those of you who reported problems
 with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were
 using that one line change I sent this week.  It should also work with
 Antti's Reddo board without needing his patch to move the demod reset
 into the tuner_gpio.

 This also brings us one more step forward to setting up the locking
 properly so that applications cannot simultaneously open the analog
 and dvb side of the device.

 Thanks for your help,

 Devin

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

Hi,

I finally give your tree a try with my Dazzle Hybrid Stick on a laptop running
Kubuntu 9.10 Karmic (Linux 2.6.31).

With the drivers from your tree, the device is properly detected as a Pinnacle
Hybrid Pro, but a scan using Kaffeine find DVB-T channels on one or two
frequencies only and tuning to one of these channels almost always fail.

I reverted back to the drivers from the stock Linux 2.6.31 kernel from Kubuntu
9.10. The scan does not really work better, but using an older list of channels,
I can tune channels with significantly less failures.

Regards,
Alain
--
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] somebody messed something on xc2028 code?

2009-10-31 Thread Albert Comerma


Yes, it worked! the current tree works well. Thanks.

Albert

En/na Devin Heitmueller ha escrit:

On Sat, Oct 31, 2009 at 8:35 AM, Albert Comerma
albert.come...@gmail.com wrote:
  

Hi all, I just updated my ubuntu to karmic and found with surprise that with
2.6.31 kernel my device does not work... It seems to be related to the
xc2028 code part since the kernel explosion happens when you try to tune the
device, here it's my dmesg, any idea?

Albert



Oh, you're using the stock 2.6.31 which didn't get my fix yet.  Please
try the latest v4l-dvb tree and see if it still happens.

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: Leadtek DTV-1000S

2009-10-31 Thread Michael Obst

This problem is reproducible and occurs the same from a cold boot or
inserting saa7134. Analog tv has never worked on this card, I was
under the impression there was no analog tuner on the card (looking at
http://www.leadtek.com/eng/tv_tuner/image/digital_tv.pdf). The info
was simply from doing a modprobe on saa7134. The only lines in the
dmesg that were different from the old driver was

saa7130[0]/alsa: Leadtek Winfast DTV1000S doesn't support digital audio

So I guess the analog part has always failed

I am using the nvidia driver and a driver for my wireless card, I will
turn these off and see if I can get a different result.

During tuning for digital tv with the old driver I got

[ 1081.808505] tda18271: performing RF tracking filter calibration
[ 1086.152006] tda18271: RF tracking filter calibration complete
[ 1091.020535] hda-intel: IRQ timing workaround is activated for card
#0. Suggest a bigger bdl_pos_adj.


The final line did not appear when I tried to tune using the new version

[ 1225.904503] tda18271: performing RF tracking filter calibration
[ 1230.272003] tda18271: RF tracking filter calibration complete


Thanks
Michael Obst

2009/11/1 Michael Krufky mkru...@kernellabs.com:
 On Sat, Oct 31, 2009 at 6:43 PM, Michael Krufky mkru...@kernellabs.com 
 wrote:
 On Sat, Oct 31, 2009 at 6:08 PM, Michael Obst
 m.o...@ugrad.unimelb.edu.au wrote:
 Hi,
    Thanks for fixing this, I can confirm that it now compiles and
 inserts and the remote works, so does the av input to the tvcard
 however the card does not seem to be able to tune any channels, I have
 checked the old driver and that is still able to tune in channels. The
 output from my dmesg is below.

 Thanks
 Michael Obst

 Michael,

 This is an interesting problem -- the part of your dmesg that stands
 out to me is this:

 [  502.928544] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
 [  502.960501] tda8290: no gate control were provided!

 That error message was added as a safety measure -- it shouldn't be
 possible to ever hit that code path.  Are you running any non-GPL
 binary drivers on your system, such as NVIDIA or anything else?

 Let me explain:

 The no gate control were provided! message was added by Mauro to the
 tda8290 driver, mainly as a check to ensure that we don't call a null
 function pointer.  The gate control is actually provided by the
 tda8290 driver itself, by either tda8290_i2c_bridge or
 tda8295_i2c_bridge, depending on which hardware is present.  In your
 case, it's a tda8290.

 The function pointer is filled during the tda829x_attach() function,
 before we call the tda829x_find_tuner function, where this error
 message is displayed.  The only way for this to have occurred, as far
 as I can tell,  is if the probe to detect the tda8290 itself had
 failed.

 Have you repeated your test with the same problem each time, or did
 this only happen once?

 Can you try again, from a cold reboot?

 Also, I'm just assuming that this failure occurred during a digital
 tune -- is that correct?  Does analog television work?

 If the problem is reproducible, can you also show us dmesg during a failed 
 tune?

 I'm very interested in hearing more about this -- please let me know.

 Oops, on second look, seems that the error occurred during analog
 bring-up ... does digital tv work?

 -Mike
 --
 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: Genpix driver is broken (no 8psk lock). Here's why how to fix.

2009-10-31 Thread VDR User

On Wed, Sep 23, 2009 at 10:55 AM, VDR User user@gmail.com wrote:
 Over a month ago I reported a problem with a change that was made to
 the Genpix driver which broke 8PSK.  The change limited DVB-S streams
 to QPSK and 8PSK to DVB-S2.  There are a couple problems with this.
 First of all, Genpix devices do NOT support DVB-S2 but pretends to for
 access to 8PSK.  Secondly, the 8PSK the Genpix provides is modified,
 aka 8PSK turbo-fec.  Two of the biggest North American DVB-S providers
 use 8PSK turbo-fec for a lot of their content.  Therefore, limiting
 DVB-S to QPSK only is crippling reception of all those providers
 transponders which use it.

 Ideally 8PSK should be allowed for DVB-S in v4l so that a device like
 the Genpix doesn't have to pretend to be something it's not to use it.
  While I seriously doubt that will be fixed, this problem can still be
 resolved by simply reverting back to the drivers original behavior
 with the following patch:

 diff -pruN v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c
 v4l-dvb/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c
 --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c
 2009-08-14 19:17:43.0 -0700
 +++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2009-08-14
 19:19:18.0 -0700
 @@ -146,8 +146,8 @@ static int gp8psk_fe_set_frontend(struct

        switch (c-delivery_system) {
        case SYS_DVBS:
 -               /* Only QPSK is supported for DVB-S */
 -               if (c-modulation != QPSK) {
 +               /* Allow QPSK and 8PSK */
 +               if (c-modulation != QPSK  c-modulation != PSK_8) {
                        deb_fe(%s: unsupported modulation selected (%d)\n,
                                __func__, c-modulation);
                        return -EOPNOTSUPP;


Now another month has passed and this problem still has not been
fixed.  Please do so!

Best regards,
Derek
--
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 00/21] gspca pac7302/pac7311: separate the two drivers

Hi,

the following patchset refactores the Pixart PAC7311 subdriver. The
current situation is that the code contains a lot of decisions
like this:

if (sd-sensor == SENSOR_PAC7302) {
... do this ...
} else {
... do something else ...
}

The sensor type is determined using the USB Vendor ID and Product
ID which means that the decisions shown are not really necessary.

The goal of the patchset is to have a PAC7302 and a PAC7311 subdriver
which have the benefit that there is no decision necessary on sensor
type at runtime. The common functions can be extracted later but this
would be a different patchset.

Regards,

Márton Németh

--
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 01/21] gspca pac7302/pac7311: add prefix for sensor specific functions

From: Márton Németh nm...@freemail.hu

There are some functions which are already sensor specific. Mark them
with pac7302_ or pac7311_ prefix

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN a/drivers/media/video/gspca/pac7311.c 
b/drivers/media/video/gspca/pac7311.c
--- a/drivers/media/video/gspca/pac7311.c   2009-10-30 16:12:05.0 
+0100
+++ b/drivers/media/video/gspca/pac7311.c   2009-10-30 17:09:52.0 
+0100
@@ -543,7 +543,7 @@ static int sd_config(struct gspca_dev *g
 }

 /* This function is used by pac7302 only */
-static void setbrightcont(struct gspca_dev *gspca_dev)
+static void pac7302_setbrightcont(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;
int i, v;
@@ -570,7 +570,7 @@ static void setbrightcont(struct gspca_d
 }

 /* This function is used by pac7311 only */
-static void setcontrast(struct gspca_dev *gspca_dev)
+static void pac7311_setcontrast(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;

@@ -581,7 +581,7 @@ static void setcontrast(struct gspca_dev
 }

 /* This function is used by pac7302 only */
-static void setcolors(struct gspca_dev *gspca_dev)
+static void pac7302_setcolors(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;
int i, v;
@@ -700,11 +700,11 @@ static int sd_start(struct gspca_dev *gs

if (sd-sensor == SENSOR_PAC7302) {
reg_w_var(gspca_dev, start_7302);
-   setbrightcont(gspca_dev);
-   setcolors(gspca_dev);
+   pac7302_setbrightcont(gspca_dev);
+   pac7302_setcolors(gspca_dev);
} else {
reg_w_var(gspca_dev, start_7311);
-   setcontrast(gspca_dev);
+   pac7311_setcontrast(gspca_dev);
}
setgain(gspca_dev);
setexposure(gspca_dev);
@@ -923,7 +923,7 @@ static int sd_setbrightness(struct gspca

sd-brightness = val;
if (gspca_dev-streaming)
-   setbrightcont(gspca_dev);
+   pac7302_setbrightcont(gspca_dev);
return 0;
 }

@@ -942,9 +942,9 @@ static int sd_setcontrast(struct gspca_d
sd-contrast = val;
if (gspca_dev-streaming) {
if (sd-sensor == SENSOR_PAC7302)
-   setbrightcont(gspca_dev);
+   pac7302_setbrightcont(gspca_dev);
else
-   setcontrast(gspca_dev);
+   pac7311_setcontrast(gspca_dev);
}
return 0;
 }
@@ -963,7 +963,7 @@ static int sd_setcolors(struct gspca_dev

sd-colors = val;
if (gspca_dev-streaming)
-   setcolors(gspca_dev);
+   pac7302_setcolors(gspca_dev);
return 0;
 }

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

[PATCH 03/21] gspca pac7302/pac7311: separate pkt_scan

From: Márton Németh nm...@freemail.hu

Separate the pkt_scan function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN c/drivers/media/video/gspca/pac7311.c 
d/drivers/media/video/gspca/pac7311.c
--- c/drivers/media/video/gspca/pac7311.c   2009-10-30 17:05:09.0 
+0100
+++ d/drivers/media/video/gspca/pac7311.c   2009-10-30 17:15:51.0 
+0100
@@ -844,7 +844,7 @@ static const unsigned char pac7311_jpeg_
 };

 /* this function is run at interrupt level */
-static void sd_pkt_scan(struct gspca_dev *gspca_dev,
+static void pac7302_sd_pkt_scan(struct gspca_dev *gspca_dev,
struct gspca_frame *frame,  /* target */
__u8 *data, /* isoc packet */
int len)/* iso packet length */
@@ -857,17 +857,12 @@ static void sd_pkt_scan(struct gspca_dev
unsigned char tmpbuf[4];
int n, lum_offset, footer_length;

-   if (sd-sensor == SENSOR_PAC7302) {
- /* 6 bytes after the FF D9 EOF marker a number of lumination
-bytes are send corresponding to different parts of the
-image, the 14th and 15th byte after the EOF seem to
-correspond to the center of the image */
- lum_offset = 61 + sizeof pac_sof_marker;
- footer_length = 74;
-   } else {
- lum_offset = 24 + sizeof pac_sof_marker;
- footer_length = 26;
-   }
+   /* 6 bytes after the FF D9 EOF marker a number of lumination
+  bytes are send corresponding to different parts of the
+  image, the 14th and 15th byte after the EOF seem to
+  correspond to the center of the image */
+   lum_offset = 61 + sizeof pac_sof_marker;
+   footer_length = 74;

/* Finish decoding current frame */
n = (sof - data) - (footer_length + sizeof pac_sof_marker);
@@ -898,18 +893,76 @@ static void sd_pkt_scan(struct gspca_dev
/* Start the new frame with the jpeg header */
gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
pac7311_jpeg_header1, sizeof(pac7311_jpeg_header1));
-   if (sd-sensor == SENSOR_PAC7302) {
-   /* The PAC7302 has the image rotated 90 degrees */
-   tmpbuf[0] = gspca_dev-width  8;
-   tmpbuf[1] = gspca_dev-width  0xff;
-   tmpbuf[2] = gspca_dev-height  8;
-   tmpbuf[3] = gspca_dev-height  0xff;
-   } else {
-   tmpbuf[0] = gspca_dev-height  8;
-   tmpbuf[1] = gspca_dev-height  0xff;
-   tmpbuf[2] = gspca_dev-width  8;
-   tmpbuf[3] = gspca_dev-width  0xff;
+
+   /* The PAC7302 has the image rotated 90 degrees */
+   tmpbuf[0] = gspca_dev-width  8;
+   tmpbuf[1] = gspca_dev-width  0xff;
+   tmpbuf[2] = gspca_dev-height  8;
+   tmpbuf[3] = gspca_dev-height  0xff;
+
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame, tmpbuf, 4);
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
+   pac7311_jpeg_header2, sizeof(pac7311_jpeg_header2));
+   }
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
+}
+
+/* this function is run at interrupt level */
+static void pac7311_sd_pkt_scan(struct gspca_dev *gspca_dev,
+   struct gspca_frame *frame,  /* target */
+   __u8 *data, /* isoc packet */
+   int len)/* iso packet length */
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   unsigned char *sof;
+
+   sof = pac_find_sof(gspca_dev, data, len);
+   if (sof) {
+   unsigned char tmpbuf[4];
+   int n, lum_offset, footer_length;
+
+   /* 6 bytes after the FF D9 EOF marker a number of lumination
+  bytes are send corresponding to different parts of the
+  image, the 14th and 15th byte after the EOF seem to
+  correspond to the center of the image */
+   lum_offset = 24 + sizeof pac_sof_marker;
+   footer_length = 26;
+
+   /* Finish decoding current frame */
+   n = (sof - data) - (footer_length + sizeof pac_sof_marker);
+   if (n  0) {
+   frame-data_end += n;
+   n = 0;
}
+   frame = gspca_frame_add(gspca_dev, INTER_PACKET, frame,
+

[PATCH 04/21] gspca pac7302/pac7311: separate config

From: Márton Németh nm...@freemail.hu

Separate the config function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN d/drivers/media/video/gspca/pac7311.c 
e/drivers/media/video/gspca/pac7311.c
--- d/drivers/media/video/gspca/pac7311.c   2009-10-30 17:15:51.0 
+0100
+++ e/drivers/media/video/gspca/pac7311.c   2009-10-30 17:27:57.0 
+0100
@@ -509,8 +509,8 @@ static void reg_w_var(struct gspca_dev *
/* not reached */
 }

-/* this function is called at probe time */
-static int sd_config(struct gspca_dev *gspca_dev,
+/* this function is called at probe time for pac7302 */
+static int pac7302_sd_config(struct gspca_dev *gspca_dev,
const struct usb_device_id *id)
 {
struct sd *sd = (struct sd *) gspca_dev;
@@ -519,17 +519,36 @@ static int sd_config(struct gspca_dev *g
cam = gspca_dev-cam;

sd-sensor = id-driver_info;
-   if (sd-sensor == SENSOR_PAC7302) {
-   PDEBUG(D_CONF, Find Sensor PAC7302);
-   cam-cam_mode = vga_mode[2];   /* only 640x480 */
-   cam-nmodes = 1;
-   } else {
-   PDEBUG(D_CONF, Find Sensor PAC7311);
-   cam-cam_mode = vga_mode;
-   cam-nmodes = ARRAY_SIZE(vga_mode);
-   gspca_dev-ctrl_dis = (1  BRIGHTNESS_IDX)
-   | (1  SATURATION_IDX);
-   }
+   PDEBUG(D_CONF, Find Sensor PAC7302);
+   cam-cam_mode = vga_mode[2];   /* only 640x480 */
+   cam-nmodes = 1;
+
+   sd-brightness = BRIGHTNESS_DEF;
+   sd-contrast = CONTRAST_DEF;
+   sd-colors = COLOR_DEF;
+   sd-gain = GAIN_DEF;
+   sd-exposure = EXPOSURE_DEF;
+   sd-autogain = AUTOGAIN_DEF;
+   sd-hflip = HFLIP_DEF;
+   sd-vflip = VFLIP_DEF;
+   return 0;
+}
+
+/* this function is called at probe time for pac7311 */
+static int pac7311_sd_config(struct gspca_dev *gspca_dev,
+   const struct usb_device_id *id)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   struct cam *cam;
+
+   cam = gspca_dev-cam;
+
+   sd-sensor = id-driver_info;
+   PDEBUG(D_CONF, Find Sensor PAC7311);
+   cam-cam_mode = vga_mode;
+   cam-nmodes = ARRAY_SIZE(vga_mode);
+   gspca_dev-ctrl_dis = (1  BRIGHTNESS_IDX)
+   | (1  SATURATION_IDX);

sd-brightness = BRIGHTNESS_DEF;
sd-contrast = CONTRAST_DEF;
@@ -1136,7 +1155,7 @@ static struct sd_desc pac7302_sd_desc =
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
-   .config = sd_config,
+   .config = pac7302_sd_config,
.init = sd_init,
.start = sd_start,
.stopN = sd_stopN,
@@ -1150,7 +1169,7 @@ static struct sd_desc pac7311_sd_desc =
.name = MODULE_NAME,
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
-   .config = sd_config,
+   .config = pac7311_sd_config,
.init = sd_init,
.start = sd_start,
.stopN = sd_stopN,
--
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 05/21] gspca pac7302/pac7311: separate init

From: Márton Németh nm...@freemail.hu

Separate the init function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN e/drivers/media/video/gspca/pac7311.c 
f/drivers/media/video/gspca/pac7311.c
--- e/drivers/media/video/gspca/pac7311.c   2009-10-30 17:27:57.0 
+0100
+++ f/drivers/media/video/gspca/pac7311.c   2009-10-30 18:04:30.0 
+0100
@@ -698,15 +698,18 @@ static void sethvflip(struct gspca_dev *
reg_w(gspca_dev, 0x11, 0x01);
 }

-/* this function is called at probe and resume time */
-static int sd_init(struct gspca_dev *gspca_dev)
+/* this function is called at probe and resume time for pac7302 */
+static int pac7302_sd_init(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   reg_w_seq(gspca_dev, init_7302, sizeof init_7302);

-   if (sd-sensor == SENSOR_PAC7302)
-   reg_w_seq(gspca_dev, init_7302, sizeof init_7302);
-   else
-   reg_w_seq(gspca_dev, init_7311, sizeof init_7311);
+   return 0;
+}
+
+/* this function is called at probe and resume time for pac7311 */
+static int pac7311_sd_init(struct gspca_dev *gspca_dev)
+{
+   reg_w_seq(gspca_dev, init_7311, sizeof init_7311);

return 0;
 }
@@ -1156,7 +1159,7 @@ static struct sd_desc pac7302_sd_desc =
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
.config = pac7302_sd_config,
-   .init = sd_init,
+   .init = pac7302_sd_init,
.start = sd_start,
.stopN = sd_stopN,
.stop0 = sd_stop0,
@@ -1170,7 +1173,7 @@ static struct sd_desc pac7311_sd_desc =
.ctrls = sd_ctrls,
.nctrls = ARRAY_SIZE(sd_ctrls),
.config = pac7311_sd_config,
-   .init = sd_init,
+   .init = pac7311_sd_init,
.start = sd_start,
.stopN = sd_stopN,
.stop0 = sd_stop0,
--
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 06/21] gspca pac7302/pac7311: separate start

From: Márton Németh nm...@freemail.hu

Separate the start function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN f/drivers/media/video/gspca/pac7311.c 
g/drivers/media/video/gspca/pac7311.c
--- f/drivers/media/video/gspca/pac7311.c   2009-10-30 18:04:30.0 
+0100
+++ g/drivers/media/video/gspca/pac7311.c   2009-10-30 18:03:15.0 
+0100
@@ -714,20 +714,40 @@ static int pac7311_sd_init(struct gspca_
return 0;
 }

-static int sd_start(struct gspca_dev *gspca_dev)
+static int pac7302_sd_start(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;

sd-sof_read = 0;

-   if (sd-sensor == SENSOR_PAC7302) {
-   reg_w_var(gspca_dev, start_7302);
-   pac7302_setbrightcont(gspca_dev);
-   pac7302_setcolors(gspca_dev);
-   } else {
-   reg_w_var(gspca_dev, start_7311);
-   pac7311_setcontrast(gspca_dev);
-   }
+   reg_w_var(gspca_dev, start_7302);
+   pac7302_setbrightcont(gspca_dev);
+   pac7302_setcolors(gspca_dev);
+   setgain(gspca_dev);
+   setexposure(gspca_dev);
+   sethvflip(gspca_dev);
+
+   /* only resolution 640x480 is supported for pac7302 */
+
+   sd-sof_read = 0;
+   sd-autogain_ignore_frames = 0;
+   atomic_set(sd-avg_lum, -1);
+
+   /* start stream */
+   reg_w(gspca_dev, 0xff, 0x01);
+   reg_w(gspca_dev, 0x78, 0x01);
+
+   return 0;
+}
+
+static int pac7311_sd_start(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   sd-sof_read = 0;
+
+   reg_w_var(gspca_dev, start_7311);
+   pac7311_setcontrast(gspca_dev);
setgain(gspca_dev);
setexposure(gspca_dev);
sethvflip(gspca_dev);
@@ -745,8 +765,6 @@ static int sd_start(struct gspca_dev *gs
reg_w(gspca_dev, 0x87, 0x11);
break;
case 0: /* 640x480 */
-   if (sd-sensor == SENSOR_PAC7302)
-   break;
reg_w(gspca_dev, 0xff, 0x01);
reg_w(gspca_dev, 0x17, 0x00);
reg_w(gspca_dev, 0x87, 0x12);
@@ -759,10 +777,8 @@ static int sd_start(struct gspca_dev *gs

/* start stream */
reg_w(gspca_dev, 0xff, 0x01);
-   if (sd-sensor == SENSOR_PAC7302)
-   reg_w(gspca_dev, 0x78, 0x01);
-   else
-   reg_w(gspca_dev, 0x78, 0x05);
+   reg_w(gspca_dev, 0x78, 0x05);
+
return 0;
 }

@@ -1160,7 +1176,7 @@ static struct sd_desc pac7302_sd_desc =
.nctrls = ARRAY_SIZE(sd_ctrls),
.config = pac7302_sd_config,
.init = pac7302_sd_init,
-   .start = sd_start,
+   .start = pac7302_sd_start,
.stopN = sd_stopN,
.stop0 = sd_stop0,
.pkt_scan = pac7302_sd_pkt_scan,
@@ -1174,7 +1190,7 @@ static struct sd_desc pac7311_sd_desc =
.nctrls = ARRAY_SIZE(sd_ctrls),
.config = pac7311_sd_config,
.init = pac7311_sd_init,
-   .start = sd_start,
+   .start = pac7311_sd_start,
.stopN = sd_stopN,
.stop0 = sd_stop0,
.pkt_scan = pac7311_sd_pkt_scan,
--
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 07/21] gspca pac7302/pac7311: separate stopN

From: Márton Németh nm...@freemail.hu

Separate the stopN function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN g/drivers/media/video/gspca/pac7311.c 
h/drivers/media/video/gspca/pac7311.c
--- g/drivers/media/video/gspca/pac7311.c   2009-10-30 18:03:15.0 
+0100
+++ h/drivers/media/video/gspca/pac7311.c   2009-10-30 18:01:57.0 
+0100
@@ -782,16 +782,15 @@ static int pac7311_sd_start(struct gspca
return 0;
 }

-static void sd_stopN(struct gspca_dev *gspca_dev)
+static void pac7302_sd_stopN(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   reg_w(gspca_dev, 0xff, 0x01);
+   reg_w(gspca_dev, 0x78, 0x00);
+   reg_w(gspca_dev, 0x78, 0x00);
+}

-   if (sd-sensor == SENSOR_PAC7302) {
-   reg_w(gspca_dev, 0xff, 0x01);
-   reg_w(gspca_dev, 0x78, 0x00);
-   reg_w(gspca_dev, 0x78, 0x00);
-   return;
-   }
+static void pac7311_sd_stopN(struct gspca_dev *gspca_dev)
+{
reg_w(gspca_dev, 0xff, 0x04);
reg_w(gspca_dev, 0x27, 0x80);
reg_w(gspca_dev, 0x28, 0xca);
@@ -1177,7 +1176,7 @@ static struct sd_desc pac7302_sd_desc =
.config = pac7302_sd_config,
.init = pac7302_sd_init,
.start = pac7302_sd_start,
-   .stopN = sd_stopN,
+   .stopN = pac7302_sd_stopN,
.stop0 = sd_stop0,
.pkt_scan = pac7302_sd_pkt_scan,
.dq_callback = do_autogain,
@@ -1191,7 +1190,7 @@ static struct sd_desc pac7311_sd_desc =
.config = pac7311_sd_config,
.init = pac7311_sd_init,
.start = pac7311_sd_start,
-   .stopN = sd_stopN,
+   .stopN = pac7311_sd_stopN,
.stop0 = sd_stop0,
.pkt_scan = pac7311_sd_pkt_scan,
.dq_callback = do_autogain,
--
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 08/21] gspca pac7302/pac7311: separate stop0

From: Márton Németh nm...@freemail.hu

Separate the stop0 function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN h/drivers/media/video/gspca/pac7311.c 
i/drivers/media/video/gspca/pac7311.c
--- h/drivers/media/video/gspca/pac7311.c   2009-10-30 18:01:57.0 
+0100
+++ i/drivers/media/video/gspca/pac7311.c   2009-10-30 17:59:39.0 
+0100
@@ -803,17 +803,18 @@ static void pac7311_sd_stopN(struct gspc
reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
 }

-/* called on streamoff with alt 0 and on disconnect */
-static void sd_stop0(struct gspca_dev *gspca_dev)
+/* called on streamoff with alt 0 and on disconnect for pac7302 */
+static void pac7302_sd_stop0(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
-
if (!gspca_dev-present)
return;
-   if (sd-sensor == SENSOR_PAC7302) {
-   reg_w(gspca_dev, 0xff, 0x01);
-   reg_w(gspca_dev, 0x78, 0x40);
-   }
+   reg_w(gspca_dev, 0xff, 0x01);
+   reg_w(gspca_dev, 0x78, 0x40);
+}
+
+/* called on streamoff with alt 0 and on disconnect for 7311 */
+static void pac7311_sd_stop0(struct gspca_dev *gspca_dev)
+{
 }

 /* Include pac common sof detection functions */
@@ -1177,7 +1178,7 @@ static struct sd_desc pac7302_sd_desc =
.init = pac7302_sd_init,
.start = pac7302_sd_start,
.stopN = pac7302_sd_stopN,
-   .stop0 = sd_stop0,
+   .stop0 = pac7302_sd_stop0,
.pkt_scan = pac7302_sd_pkt_scan,
.dq_callback = do_autogain,
 };
@@ -1191,7 +1192,7 @@ static struct sd_desc pac7311_sd_desc =
.init = pac7311_sd_init,
.start = pac7311_sd_start,
.stopN = pac7311_sd_stopN,
-   .stop0 = sd_stop0,
+   .stop0 = pac7311_sd_stop0,
.pkt_scan = pac7311_sd_pkt_scan,
.dq_callback = do_autogain,
 };
--
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 09/21] gspca pac7302/pac7311: separate dq_callback

From: Márton Németh nm...@freemail.hu

Separate the dq_callback function. Remove the run-time decision for
PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN i/drivers/media/video/gspca/pac7311.c 
j/drivers/media/video/gspca/pac7311.c
--- i/drivers/media/video/gspca/pac7311.c   2009-10-30 17:59:39.0 
+0100
+++ j/drivers/media/video/gspca/pac7311.c   2009-10-30 18:00:55.0 
+0100
@@ -820,7 +820,7 @@ static void pac7311_sd_stop0(struct gspc
 /* Include pac common sof detection functions */
 #include pac_common.h

-static void do_autogain(struct gspca_dev *gspca_dev)
+static void pac7302_do_autogain(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;
int avg_lum = atomic_read(sd-avg_lum);
@@ -829,22 +829,36 @@ static void do_autogain(struct gspca_dev
if (avg_lum == -1)
return;

-   if (sd-sensor == SENSOR_PAC7302) {
-   desired_lum = 270 + sd-brightness * 4;
-   /* Hack hack, with the 7202 the first exposure step is
-  pretty large, so if we're about to make the first
-  exposure increase make the deadzone large to avoid
-  oscilating */
-   if (desired_lum  avg_lum  sd-gain == GAIN_DEF 
-   sd-exposure  EXPOSURE_DEF 
-   sd-exposure  42)
-   deadzone = 90;
-   else
-   deadzone = 30;
-   } else {
-   desired_lum = 200;
-   deadzone = 20;
-   }
+   desired_lum = 270 + sd-brightness * 4;
+   /* Hack hack, with the 7202 the first exposure step is
+  pretty large, so if we're about to make the first
+  exposure increase make the deadzone large to avoid
+  oscilating */
+   if (desired_lum  avg_lum  sd-gain == GAIN_DEF 
+   sd-exposure  EXPOSURE_DEF 
+   sd-exposure  42)
+   deadzone = 90;
+   else
+   deadzone = 30;
+
+   if (sd-autogain_ignore_frames  0)
+   sd-autogain_ignore_frames--;
+   else if (gspca_auto_gain_n_exposure(gspca_dev, avg_lum, desired_lum,
+   deadzone, GAIN_KNEE, EXPOSURE_KNEE))
+   sd-autogain_ignore_frames = PAC_AUTOGAIN_IGNORE_FRAMES;
+}
+
+static void pac7311_do_autogain(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   int avg_lum = atomic_read(sd-avg_lum);
+   int desired_lum, deadzone;
+
+   if (avg_lum == -1)
+   return;
+
+   desired_lum = 200;
+   deadzone = 20;

if (sd-autogain_ignore_frames  0)
sd-autogain_ignore_frames--;
@@ -1180,7 +1194,7 @@ static struct sd_desc pac7302_sd_desc =
.stopN = pac7302_sd_stopN,
.stop0 = pac7302_sd_stop0,
.pkt_scan = pac7302_sd_pkt_scan,
-   .dq_callback = do_autogain,
+   .dq_callback = pac7302_do_autogain,
 };

 /* sub-driver description for pac7311 */
@@ -1194,7 +1208,7 @@ static struct sd_desc pac7311_sd_desc =
.stopN = pac7311_sd_stopN,
.stop0 = pac7311_sd_stop0,
.pkt_scan = pac7311_sd_pkt_scan,
-   .dq_callback = do_autogain,
+   .dq_callback = pac7311_do_autogain,
 };

 /* -- module initialisation -- */
--
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 12/21] gspca pac7302/pac7311: separate hvflip

From: Márton Németh nm...@freemail.hu

Separate the horizontal and vertical flip control. Remove the run-time
decision for PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN l/drivers/media/video/gspca/pac7311.c 
m/drivers/media/video/gspca/pac7311.c
--- l/drivers/media/video/gspca/pac7311.c   2009-10-31 07:21:22.0 
+0100
+++ m/drivers/media/video/gspca/pac7311.c   2009-10-31 07:29:51.0 
+0100
@@ -91,10 +91,14 @@ static int pac7302_sd_setcolors(struct g
 static int pac7302_sd_getcolors(struct gspca_dev *gspca_dev, __s32 *val);
 static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
 static int sd_getautogain(struct gspca_dev *gspca_dev, __s32 *val);
-static int sd_sethflip(struct gspca_dev *gspca_dev, __s32 val);
-static int sd_gethflip(struct gspca_dev *gspca_dev, __s32 *val);
-static int sd_setvflip(struct gspca_dev *gspca_dev, __s32 val);
-static int sd_getvflip(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7302_sd_sethflip(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7311_sd_sethflip(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7302_sd_gethflip(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7311_sd_gethflip(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7302_sd_setvflip(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7311_sd_setvflip(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7302_sd_getvflip(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7311_sd_getvflip(struct gspca_dev *gspca_dev, __s32 *val);
 static int sd_setgain(struct gspca_dev *gspca_dev, __s32 val);
 static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
 static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
@@ -207,8 +211,8 @@ static struct ctrl pac7302_sd_ctrls[] =
 #define HFLIP_DEF 0
.default_value = HFLIP_DEF,
},
-   .set = sd_sethflip,
-   .get = sd_gethflip,
+   .set = pac7302_sd_sethflip,
+   .get = pac7302_sd_gethflip,
},
{
{
@@ -221,8 +225,8 @@ static struct ctrl pac7302_sd_ctrls[] =
 #define VFLIP_DEF 0
.default_value = VFLIP_DEF,
},
-   .set = sd_setvflip,
-   .get = sd_getvflip,
+   .set = pac7302_sd_setvflip,
+   .get = pac7302_sd_getvflip,
},
 };

@@ -301,8 +305,8 @@ static struct ctrl pac7311_sd_ctrls[] =
 #define HFLIP_DEF 0
.default_value = HFLIP_DEF,
},
-   .set = sd_sethflip,
-   .get = sd_gethflip,
+   .set = pac7311_sd_sethflip,
+   .get = pac7311_sd_gethflip,
},
{
{
@@ -315,8 +319,8 @@ static struct ctrl pac7311_sd_ctrls[] =
 #define VFLIP_DEF 0
.default_value = VFLIP_DEF,
},
-   .set = sd_setvflip,
-   .get = sd_getvflip,
+   .set = pac7311_sd_setvflip,
+   .get = pac7311_sd_getvflip,
},
 };

@@ -771,20 +775,25 @@ static void setexposure(struct gspca_dev
reg_w(gspca_dev, 0x11, 0x01);
 }

-static void sethvflip(struct gspca_dev *gspca_dev)
+static void pac7302_sethvflip(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;
__u8 data;

-   if (sd-sensor == SENSOR_PAC7302) {
-   reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
-   data = (sd-hflip ? 0x08 : 0x00)
-   | (sd-vflip ? 0x04 : 0x00);
-   } else {
-   reg_w(gspca_dev, 0xff, 0x04);   /* page 4 */
-   data = (sd-hflip ? 0x04 : 0x00)
-   | (sd-vflip ? 0x08 : 0x00);
-   }
+   reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
+   data = (sd-hflip ? 0x08 : 0x00) | (sd-vflip ? 0x04 : 0x00);
+   reg_w(gspca_dev, 0x21, data);
+   /* load registers to sensor (Bit 0, auto clear) */
+   reg_w(gspca_dev, 0x11, 0x01);
+}
+
+static void pac7311_sethvflip(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   __u8 data;
+
+   reg_w(gspca_dev, 0xff, 0x04);   /* page 4 */
+   data = (sd-hflip ? 0x04 : 0x00) | (sd-vflip ? 0x08 : 0x00);
reg_w(gspca_dev, 0x21, data);
/* load registers to sensor (Bit 0, auto clear) */
reg_w(gspca_dev, 0x11, 0x01);
@@ -817,7 +826,7 @@ static int pac7302_sd_start(struct gspca
pac7302_setcolors(gspca_dev);
setgain(gspca_dev);
setexposure(gspca_dev);
-   sethvflip(gspca_dev);
+   pac7302_sethvflip(gspca_dev);

/* only resolution 640x480 is supported for pac7302 */

@@ -842,7 +851,7 @@ static int pac7311_sd_start(struct gspca
pac7311_setcontrast(gspca_dev);
setgain(gspca_dev);
setexposure(gspca_dev);
-   sethvflip(gspca_dev);
+

[PATCH 13/21] gspca pac7302/pac7311: separate gain/autogain control

From: Márton Németh nm...@freemail.hu

Separate the gain and autogain controls. Remove the run-time
decision for PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN m/drivers/media/video/gspca/pac7311.c 
n/drivers/media/video/gspca/pac7311.c
--- m/drivers/media/video/gspca/pac7311.c   2009-10-31 07:29:51.0 
+0100
+++ n/drivers/media/video/gspca/pac7311.c   2009-10-31 07:38:45.0 
+0100
@@ -89,8 +89,10 @@ static int pac7302_sd_getcontrast(struct
 static int pac7311_sd_getcontrast(struct gspca_dev *gspca_dev, __s32 *val);
 static int pac7302_sd_setcolors(struct gspca_dev *gspca_dev, __s32 val);
 static int pac7302_sd_getcolors(struct gspca_dev *gspca_dev, __s32 *val);
-static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
-static int sd_getautogain(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7302_sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7311_sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7302_sd_getautogain(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7311_sd_getautogain(struct gspca_dev *gspca_dev, __s32 *val);
 static int pac7302_sd_sethflip(struct gspca_dev *gspca_dev, __s32 val);
 static int pac7311_sd_sethflip(struct gspca_dev *gspca_dev, __s32 val);
 static int pac7302_sd_gethflip(struct gspca_dev *gspca_dev, __s32 *val);
@@ -99,8 +101,10 @@ static int pac7302_sd_setvflip(struct gs
 static int pac7311_sd_setvflip(struct gspca_dev *gspca_dev, __s32 val);
 static int pac7302_sd_getvflip(struct gspca_dev *gspca_dev, __s32 *val);
 static int pac7311_sd_getvflip(struct gspca_dev *gspca_dev, __s32 *val);
-static int sd_setgain(struct gspca_dev *gspca_dev, __s32 val);
-static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7302_sd_setgain(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7311_sd_setgain(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7302_sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7311_sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
 static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
 static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);

@@ -167,8 +171,8 @@ static struct ctrl pac7302_sd_ctrls[] =
 #define GAIN_KNEE 255 /* Gain seems to cause little noise on the pac73xx */
.default_value = GAIN_DEF,
},
-   .set = sd_setgain,
-   .get = sd_getgain,
+   .set = pac7302_sd_setgain,
+   .get = pac7302_sd_getgain,
},
{
{
@@ -197,8 +201,8 @@ static struct ctrl pac7302_sd_ctrls[] =
 #define AUTOGAIN_DEF 1
.default_value = AUTOGAIN_DEF,
},
-   .set = sd_setautogain,
-   .get = sd_getautogain,
+   .set = pac7302_sd_setautogain,
+   .get = pac7302_sd_getautogain,
},
{
{
@@ -261,8 +265,8 @@ static struct ctrl pac7311_sd_ctrls[] =
 #define GAIN_KNEE 255 /* Gain seems to cause little noise on the pac73xx */
.default_value = GAIN_DEF,
},
-   .set = sd_setgain,
-   .get = sd_getgain,
+   .set = pac7311_sd_setgain,
+   .get = pac7311_sd_getgain,
},
{
{
@@ -291,8 +295,8 @@ static struct ctrl pac7311_sd_ctrls[] =
 #define AUTOGAIN_DEF 1
.default_value = AUTOGAIN_DEF,
},
-   .set = sd_setautogain,
-   .get = sd_getautogain,
+   .set = pac7311_sd_setautogain,
+   .get = pac7311_sd_getautogain,
},
{
{
@@ -717,23 +721,30 @@ static void pac7302_setcolors(struct gsp
PDEBUG(D_CONF|D_STREAM, color: %i, sd-colors);
 }

-static void setgain(struct gspca_dev *gspca_dev)
+static void pac7302_setgain(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;

-   if (sd-sensor == SENSOR_PAC7302) {
-   reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
-   reg_w(gspca_dev, 0x10, sd-gain  3);
-   } else {
-   int gain = GAIN_MAX - sd-gain;
-   if (gain  1)
-   gain = 1;
-   else if (gain  245)
-   gain = 245;
-   reg_w(gspca_dev, 0xff, 0x04);   /* page 4 */
-   reg_w(gspca_dev, 0x0e, 0x00);
-   reg_w(gspca_dev, 0x0f, gain);
-   }
+   reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
+   reg_w(gspca_dev, 0x10, sd-gain  3);
+
+   /* load registers to sensor (Bit 0, auto clear) */
+   reg_w(gspca_dev, 0x11, 0x01);
+}
+
+static void pac7311_setgain(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   int gain = GAIN_MAX - sd-gain;
+
+   if (gain  1)
+   gain = 1;
+

[PATCH 15/21] gspca pac7302/pac7311: simplify pac_find_sof

From: Márton Németh nm...@freemail.hu

Remove struct sd dependency from pac_find_sof() function implementation,
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN o/drivers/media/video/gspca/mr97310a.c 
p/drivers/media/video/gspca/mr97310a.c
--- o/drivers/media/video/gspca/mr97310a.c  2009-10-31 08:11:38.0 
+0100
+++ p/drivers/media/video/gspca/mr97310a.c  2009-10-31 08:20:00.0 
+0100
@@ -957,9 +957,10 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data,   /* isoc packet */
int len)  /* iso packet length */
 {
+   struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(sd-sof_read, data, len);
if (sof) {
int n;

diff -uprN o/drivers/media/video/gspca/pac207.c 
p/drivers/media/video/gspca/pac207.c
--- o/drivers/media/video/gspca/pac207.c2009-10-23 07:07:59.0 
+0200
+++ p/drivers/media/video/gspca/pac207.c2009-10-31 08:18:59.0 
+0100
@@ -344,7 +344,7 @@ static void sd_pkt_scan(struct gspca_dev
struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(sd-sof_read, data, len);
if (sof) {
int n;

diff -uprN o/drivers/media/video/gspca/pac7311.c 
p/drivers/media/video/gspca/pac7311.c
--- o/drivers/media/video/gspca/pac7311.c   2009-10-31 07:45:27.0 
+0100
+++ p/drivers/media/video/gspca/pac7311.c   2009-10-31 08:22:45.0 
+0100
@@ -1035,7 +1035,7 @@ static void pac7302_sd_pkt_scan(struct g
struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(sd-sof_read, data, len);
if (sof) {
unsigned char tmpbuf[4];
int n, lum_offset, footer_length;
@@ -1099,7 +1099,7 @@ static void pac7311_sd_pkt_scan(struct g
struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(sd-sof_read, data, len);
if (sof) {
unsigned char tmpbuf[4];
int n, lum_offset, footer_length;
diff -uprN o/drivers/media/video/gspca/pac_common.h 
p/drivers/media/video/gspca/pac_common.h
--- o/drivers/media/video/gspca/pac_common.h2009-10-30 16:12:05.0 
+0100
+++ p/drivers/media/video/gspca/pac_common.h2009-10-31 08:17:38.0 
+0100
@@ -72,42 +72,41 @@ static const unsigned char pac_sof_marke
   +--+
 */

-static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
+static unsigned char *pac_find_sof(u8 *sof_read,
unsigned char *m, int len)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
int i;

/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i  len; i++) {
-   switch (sd-sof_read) {
+   switch (*sof_read) {
case 0:
if (m[i] == 0xff)
-   sd-sof_read = 1;
+   *sof_read = 1;
break;
case 1:
if (m[i] == 0xff)
-   sd-sof_read = 2;
+   *sof_read = 2;
else
-   sd-sof_read = 0;
+   *sof_read = 0;
break;
case 2:
switch (m[i]) {
case 0x00:
-   sd-sof_read = 3;
+   *sof_read = 3;
break;
case 0xff:
/* stay in this state */
break;
default:
-   sd-sof_read = 0;
+   *sof_read = 0;
}
break;
case 3:
if (m[i] == 0xff)
-   sd-sof_read = 4;
+   *sof_read = 4;
else
-   sd-sof_read = 0;
+   *sof_read = 0;
break;
case 4:
switch (m[i]) {
@@ -117,18 +116,18 @@ static unsigned char *pac_find_sof(struc
SOF found, bytes to analyze: %u.
 Frame starts at byte #%u,

[PATCH 14/21] gspca pac7302/pac7311: separate exposure

From: Márton Németh nm...@freemail.hu

Separate the exposure control. Remove the run-time
decision for PAC7302 and PAC7311 sensors.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN n/drivers/media/video/gspca/pac7311.c 
o/drivers/media/video/gspca/pac7311.c
--- n/drivers/media/video/gspca/pac7311.c   2009-10-31 07:38:45.0 
+0100
+++ o/drivers/media/video/gspca/pac7311.c   2009-10-31 07:45:27.0 
+0100
@@ -105,8 +105,10 @@ static int pac7302_sd_setgain(struct gsp
 static int pac7311_sd_setgain(struct gspca_dev *gspca_dev, __s32 val);
 static int pac7302_sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
 static int pac7311_sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
-static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
-static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7302_sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7311_sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
+static int pac7302_sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
+static int pac7311_sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);

 static struct ctrl pac7302_sd_ctrls[] = {
 /* This control is pac7302 only */
@@ -187,8 +189,8 @@ static struct ctrl pac7302_sd_ctrls[] =
 #define EXPOSURE_KNEE 50 /* 100 ms / 10 fps */
.default_value = EXPOSURE_DEF,
},
-   .set = sd_setexposure,
-   .get = sd_getexposure,
+   .set = pac7302_sd_setexposure,
+   .get = pac7302_sd_getexposure,
},
{
{
@@ -281,8 +283,8 @@ static struct ctrl pac7311_sd_ctrls[] =
 #define EXPOSURE_KNEE 50 /* 100 ms / 10 fps */
.default_value = EXPOSURE_DEF,
},
-   .set = sd_setexposure,
-   .get = sd_getexposure,
+   .set = pac7311_sd_setexposure,
+   .get = pac7311_sd_getexposure,
},
{
{
@@ -749,7 +751,7 @@ static void pac7311_setgain(struct gspca
reg_w(gspca_dev, 0x11, 0x01);
 }

-static void setexposure(struct gspca_dev *gspca_dev)
+static void pac7302_setexposure(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;
__u8 reg;
@@ -763,25 +765,42 @@ static void setexposure(struct gspca_dev
else if (reg  63)
reg = 63;

-   if (sd-sensor == SENSOR_PAC7302) {
-   /* On the pac7302 reg2 MUST be a multiple of 3, so round it to
-  the nearest multiple of 3, except when between 6 and 12? */
-   if (reg  6 || reg  12)
-   reg = ((reg + 1) / 3) * 3;
-   reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
-   reg_w(gspca_dev, 0x02, reg);
-   } else {
-   reg_w(gspca_dev, 0xff, 0x04);   /* page 4 */
-   reg_w(gspca_dev, 0x02, reg);
-   /* Page 1 register 8 must always be 0x08 except when not in
-  640x480 mode and Page3/4 reg 2 = 3 then it must be 9 */
-   reg_w(gspca_dev, 0xff, 0x01);
-   if (gspca_dev-cam.cam_mode[(int)gspca_dev-curr_mode].priv 
-   reg = 3)
-   reg_w(gspca_dev, 0x08, 0x09);
-   else
-   reg_w(gspca_dev, 0x08, 0x08);
-   }
+   /* On the pac7302 reg2 MUST be a multiple of 3, so round it to
+  the nearest multiple of 3, except when between 6 and 12? */
+   if (reg  6 || reg  12)
+   reg = ((reg + 1) / 3) * 3;
+   reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
+   reg_w(gspca_dev, 0x02, reg);
+
+   /* load registers to sensor (Bit 0, auto clear) */
+   reg_w(gspca_dev, 0x11, 0x01);
+}
+
+static void pac7311_setexposure(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   __u8 reg;
+
+   /* register 2 of frame 3/4 contains the clock divider configuring the
+  no fps according to the formula: 60 / reg. sd-exposure is the
+  desired exposure time in ms. */
+   reg = 120 * sd-exposure / 1000;
+   if (reg  2)
+   reg = 2;
+   else if (reg  63)
+   reg = 63;
+
+   reg_w(gspca_dev, 0xff, 0x04);   /* page 4 */
+   reg_w(gspca_dev, 0x02, reg);
+   /* Page 1 register 8 must always be 0x08 except when not in
+  640x480 mode and Page3/4 reg 2 = 3 then it must be 9 */
+   reg_w(gspca_dev, 0xff, 0x01);
+   if (gspca_dev-cam.cam_mode[(int)gspca_dev-curr_mode].priv 
+   reg = 3)
+   reg_w(gspca_dev, 0x08, 0x09);
+   else
+   reg_w(gspca_dev, 0x08, 0x08);
+
/* load registers to sensor (Bit 0, auto clear) */
reg_w(gspca_dev, 0x11, 0x01);
 }
@@ -836,7 +855,7 @@ static int pac7302_sd_start(struct gspca

[PATCH 16/21] gspca pac7302/pac7311: separate private sd

From: Márton Németh nm...@freemail.hu

Separate the private struct sd where the sensor specific data is stored.
The sensor field is no longer needed because we use separate functions.
Brightness and color fields are not used in pac7311, so removed.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN p/drivers/media/video/gspca/pac7311.c 
q/drivers/media/video/gspca/pac7311.c
--- p/drivers/media/video/gspca/pac7311.c   2009-10-31 08:22:45.0 
+0100
+++ q/drivers/media/video/gspca/pac7311.c   2009-10-31 08:26:17.0 
+0100
@@ -57,8 +57,8 @@ MODULE_AUTHOR(Thomas Kaiser tho...@kais
 MODULE_DESCRIPTION(Pixart PAC7311);
 MODULE_LICENSE(GPL);

-/* specific webcam descriptor */
-struct sd {
+/* specific webcam descriptor for pac7302 */
+struct pac7302_sd {
struct gspca_dev gspca_dev; /* !! must be the first item */

unsigned char brightness;
@@ -70,7 +70,26 @@ struct sd {
__u8 hflip;
__u8 vflip;

-   __u8 sensor;
+#define SENSOR_PAC7302 0
+#define SENSOR_PAC7311 1
+
+   u8 sof_read;
+   u8 autogain_ignore_frames;
+
+   atomic_t avg_lum;
+};
+
+/* specific webcam descriptor for pac7311 */
+struct pac7311_sd {
+   struct gspca_dev gspca_dev; /* !! must be the first item */
+
+   unsigned char contrast;
+   unsigned char gain;
+   unsigned char exposure;
+   unsigned char autogain;
+   __u8 hflip;
+   __u8 vflip;
+
 #define SENSOR_PAC7302 0
 #define SENSOR_PAC7311 1

@@ -617,12 +636,11 @@ static void reg_w_var(struct gspca_dev *
 static int pac7302_sd_config(struct gspca_dev *gspca_dev,
const struct usb_device_id *id)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7302_sd *sd = (struct pac7302_sd *) gspca_dev;
struct cam *cam;

cam = gspca_dev-cam;

-   sd-sensor = id-driver_info;
PDEBUG(D_CONF, Find Sensor PAC7302);
cam-cam_mode = vga_mode[2];   /* only 640x480 */
cam-nmodes = 1;
@@ -642,19 +660,16 @@ static int pac7302_sd_config(struct gspc
 static int pac7311_sd_config(struct gspca_dev *gspca_dev,
const struct usb_device_id *id)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7311_sd *sd = (struct pac7311_sd *) gspca_dev;
struct cam *cam;

cam = gspca_dev-cam;

-   sd-sensor = id-driver_info;
PDEBUG(D_CONF, Find Sensor PAC7311);
cam-cam_mode = vga_mode;
cam-nmodes = ARRAY_SIZE(vga_mode);

-   sd-brightness = BRIGHTNESS_DEF;
sd-contrast = CONTRAST_DEF;
-   sd-colors = COLOR_DEF;
sd-gain = GAIN_DEF;
sd-exposure = EXPOSURE_DEF;
sd-autogain = AUTOGAIN_DEF;
@@ -666,7 +681,7 @@ static int pac7311_sd_config(struct gspc
 /* This function is used by pac7302 only */
 static void pac7302_setbrightcont(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7302_sd *sd = (struct pac7302_sd *) gspca_dev;
int i, v;
static const __u8 max[10] =
{0x29, 0x33, 0x42, 0x5a, 0x6e, 0x80, 0x9f, 0xbb,
@@ -693,7 +708,7 @@ static void pac7302_setbrightcont(struct
 /* This function is used by pac7311 only */
 static void pac7311_setcontrast(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7311_sd *sd = (struct pac7311_sd *) gspca_dev;

reg_w(gspca_dev, 0xff, 0x04);
reg_w(gspca_dev, 0x10, sd-contrast  4);
@@ -704,7 +719,7 @@ static void pac7311_setcontrast(struct g
 /* This function is used by pac7302 only */
 static void pac7302_setcolors(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7302_sd *sd = (struct pac7302_sd *) gspca_dev;
int i, v;
static const int a[9] =
{217, -212, 0, -101, 170, -67, -38, -315, 355};
@@ -725,7 +740,7 @@ static void pac7302_setcolors(struct gsp

 static void pac7302_setgain(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7302_sd *sd = (struct pac7302_sd *) gspca_dev;

reg_w(gspca_dev, 0xff, 0x03);   /* page 3 */
reg_w(gspca_dev, 0x10, sd-gain  3);
@@ -736,7 +751,7 @@ static void pac7302_setgain(struct gspca

 static void pac7311_setgain(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7311_sd *sd = (struct pac7311_sd *) gspca_dev;
int gain = GAIN_MAX - sd-gain;

if (gain  1)
@@ -753,7 +768,7 @@ static void pac7311_setgain(struct gspca

 static void pac7302_setexposure(struct gspca_dev *gspca_dev)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
+   struct pac7302_sd *sd = (struct pac7302_sd *) gspca_dev;
__u8 reg;

/* register 2 of frame 3/4 contains the clock divider

[PATCH 18/21] gspca pac7302/pac7311: generalize reg_w_var

From: Márton Németh nm...@freemail.hu

The original implementation of reg_w_var contains direct references to pac7302
and 7311 specific structures. Move these references to the parameter list.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN r/drivers/media/video/gspca/pac7311.c 
s/drivers/media/video/gspca/pac7311.c
--- r/drivers/media/video/gspca/pac7311.c   2009-10-31 09:07:56.0 
+0100
+++ s/drivers/media/video/gspca/pac7311.c   2009-10-31 10:21:55.0 
+0100
@@ -602,7 +602,9 @@ static void reg_w_page(struct gspca_dev

 /* output a variable sequence */
 static void reg_w_var(struct gspca_dev *gspca_dev,
-   const __u8 *seq)
+   const __u8 *seq,
+   const __u8 *page3, unsigned int page3_len,
+   const __u8 *page4, unsigned int page4_len)
 {
int index, len;

@@ -613,10 +615,10 @@ static void reg_w_var(struct gspca_dev *
case END_OF_SEQUENCE:
return;
case LOAD_PAGE4:
-   reg_w_page(gspca_dev, page4_7311, sizeof page4_7311);
+   reg_w_page(gspca_dev, page4, page4_len);
break;
case LOAD_PAGE3:
-   reg_w_page(gspca_dev, page3_7302, sizeof page3_7302);
+   reg_w_page(gspca_dev, page3, page3_len);
break;
default:
if (len  USB_BUF_SZ) {
@@ -874,7 +876,9 @@ static int pac7302_sd_start(struct gspca

sd-sof_read = 0;

-   reg_w_var(gspca_dev, start_7302);
+   reg_w_var(gspca_dev, start_7302,
+   page3_7302, sizeof(page3_7302),
+   NULL, 0);
pac7302_setbrightcont(gspca_dev);
pac7302_setcolors(gspca_dev);
pac7302_setgain(gspca_dev);
@@ -900,7 +904,9 @@ static int pac7311_sd_start(struct gspca

sd-sof_read = 0;

-   reg_w_var(gspca_dev, start_7311);
+   reg_w_var(gspca_dev, start_7311,
+   NULL, 0,
+   page4_7311, sizeof(page4_7311));
pac7311_setcontrast(gspca_dev);
pac7311_setgain(gspca_dev);
pac7311_setexposure(gspca_dev);
--
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 19/21] gspca pac7302/pac7311: extract pac_start_frame

From: Márton Németh nm...@freemail.hu

Creating the start of the frame is done in the same way for pac7302
and for pac7311. Extract this common part to the pac_start_frame()
function.

Signed-off-by: Márton Németh nm...@freemail.hu
Cc: Thomas Kaiser tho...@kaiser-linux.li
Cc: Theodore Kilgore kilg...@auburn.edu
Cc: Kyle Guinn ely...@gmail.com
---
diff -uprN s/drivers/media/video/gspca/pac7311.c 
t/drivers/media/video/gspca/pac7311.c
--- s/drivers/media/video/gspca/pac7311.c   2009-10-31 10:21:55.0 
+0100
+++ t/drivers/media/video/gspca/pac7311.c   2009-10-31 10:20:49.0 
+0100
@@ -1028,7 +1028,7 @@ static void pac7311_do_autogain(struct g
 }

 /* JPEG header, part 1 */
-static const unsigned char pac7311_jpeg_header1[] = {
+static const unsigned char pac_jpeg_header1[] = {
   0xff, 0xd8,  /* SOI: Start of Image */

   0xff, 0xc0,  /* SOF0: Start of Frame (Baseline DCT) */
@@ -1039,7 +1039,7 @@ static const unsigned char pac7311_jpeg_
 };

 /* JPEG header, continued */
-static const unsigned char pac7311_jpeg_header2[] = {
+static const unsigned char pac_jpeg_header2[] = {
   0x03,/* Number of image components: 3 */
   0x01, 0x21, 0x00,/* ID=1, Subsampling 1x1, Quantization table: 0 */
   0x02, 0x11, 0x01,/* ID=2, Subsampling 2x1, Quantization table: 1 */
@@ -1055,6 +1055,26 @@ static const unsigned char pac7311_jpeg_
   0x00 /* Successive approximation: 0 */
 };

+static void pac_start_frame(struct gspca_dev *gspca_dev,
+   struct gspca_frame *frame,
+   __u16 lines, __u16 samples_per_line)
+{
+   unsigned char tmpbuf[4];
+
+   gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+   pac_jpeg_header1, sizeof(pac_jpeg_header1));
+
+   tmpbuf[0] = lines  8;
+   tmpbuf[1] = lines  0xff;
+   tmpbuf[2] = samples_per_line  8;
+   tmpbuf[3] = samples_per_line  0xff;
+
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
+   tmpbuf, sizeof(tmpbuf));
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
+   pac_jpeg_header2, sizeof(pac_jpeg_header2));
+}
+
 /* this function is run at interrupt level */
 static void pac7302_sd_pkt_scan(struct gspca_dev *gspca_dev,
struct gspca_frame *frame,  /* target */
@@ -1066,7 +1086,6 @@ static void pac7302_sd_pkt_scan(struct g

sof = pac_find_sof(sd-sof_read, data, len);
if (sof) {
-   unsigned char tmpbuf[4];
int n, lum_offset, footer_length;

/* 6 bytes after the FF D9 EOF marker a number of lumination
@@ -1103,18 +1122,9 @@ static void pac7302_sd_pkt_scan(struct g
atomic_set(sd-avg_lum, -1);

/* Start the new frame with the jpeg header */
-   gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
-   pac7311_jpeg_header1, sizeof(pac7311_jpeg_header1));
-
/* The PAC7302 has the image rotated 90 degrees */
-   tmpbuf[0] = gspca_dev-width  8;
-   tmpbuf[1] = gspca_dev-width  0xff;
-   tmpbuf[2] = gspca_dev-height  8;
-   tmpbuf[3] = gspca_dev-height  0xff;
-
-   gspca_frame_add(gspca_dev, INTER_PACKET, frame, tmpbuf, 4);
-   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
-   pac7311_jpeg_header2, sizeof(pac7311_jpeg_header2));
+   pac_start_frame(gspca_dev, frame,
+   gspca_dev-width, gspca_dev-height);
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
 }
@@ -1130,7 +1140,6 @@ static void pac7311_sd_pkt_scan(struct g

sof = pac_find_sof(sd-sof_read, data, len);
if (sof) {
-   unsigned char tmpbuf[4];
int n, lum_offset, footer_length;

/* 6 bytes after the FF D9 EOF marker a number of lumination
@@ -1167,17 +1176,8 @@ static void pac7311_sd_pkt_scan(struct g
atomic_set(sd-avg_lum, -1);

/* Start the new frame with the jpeg header */
-   gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
-   pac7311_jpeg_header1, sizeof(pac7311_jpeg_header1));
-
-   tmpbuf[0] = gspca_dev-height  8;
-   tmpbuf[1] = gspca_dev-height  0xff;
-   tmpbuf[2] = gspca_dev-width  8;
-   tmpbuf[3] = gspca_dev-width  0xff;
-
-   gspca_frame_add(gspca_dev, INTER_PACKET, frame, tmpbuf, 4);
-   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
-   pac7311_jpeg_header2, sizeof(pac7311_jpeg_header2));
+   pac_start_frame(gspca_dev, frame,
+   gspca_dev-height, gspca_dev-width);
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
 }
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org

Re: Leadtek DTV-1000S

 2009/11/1 Michael Krufky mkru...@kernellabs.com:
 On Sat, Oct 31, 2009 at 6:43 PM, Michael Krufky mkru...@kernellabs.com 
 wrote:
 On Sat, Oct 31, 2009 at 6:08 PM, Michael Obst
 m.o...@ugrad.unimelb.edu.au wrote:
 Hi,
    Thanks for fixing this, I can confirm that it now compiles and
 inserts and the remote works, so does the av input to the tvcard
 however the card does not seem to be able to tune any channels, I have
 checked the old driver and that is still able to tune in channels. The
 output from my dmesg is below.

 Thanks
 Michael Obst

 Michael,

 This is an interesting problem -- the part of your dmesg that stands
 out to me is this:

 [  502.928544] tuner 0-0060: chip found @ 0xc0 (saa7130[0])
 [  502.960501] tda8290: no gate control were provided!

 That error message was added as a safety measure -- it shouldn't be
 possible to ever hit that code path.  Are you running any non-GPL
 binary drivers on your system, such as NVIDIA or anything else?

 Let me explain:

 The no gate control were provided! message was added by Mauro to the
 tda8290 driver, mainly as a check to ensure that we don't call a null
 function pointer.  The gate control is actually provided by the
 tda8290 driver itself, by either tda8290_i2c_bridge or
 tda8295_i2c_bridge, depending on which hardware is present.  In your
 case, it's a tda8290.

 The function pointer is filled during the tda829x_attach() function,
 before we call the tda829x_find_tuner function, where this error
 message is displayed.  The only way for this to have occurred, as far
 as I can tell,  is if the probe to detect the tda8290 itself had
 failed.

 Have you repeated your test with the same problem each time, or did
 this only happen once?

 Can you try again, from a cold reboot?

 Also, I'm just assuming that this failure occurred during a digital
 tune -- is that correct?  Does analog television work?

 If the problem is reproducible, can you also show us dmesg during a failed 
 tune?

 I'm very interested in hearing more about this -- please let me know.

 Oops, on second look, seems that the error occurred during analog
 bring-up ... does digital tv work?

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



On Sat, Oct 31, 2009 at 7:04 PM, Michael Obst
m.o...@ugrad.unimelb.edu.au wrote:
 This problem is reproducible and occurs the same from a cold boot or
 inserting saa7134. Analog tv has never worked on this card, I was
 under the impression there was no analog tuner on the card (looking at
 http://www.leadtek.com/eng/tv_tuner/image/digital_tv.pdf). The info
 was simply from doing a modprobe on saa7134. The only lines in the
 dmesg that were different from the old driver was

 saa7130[0]/alsa: Leadtek Winfast DTV1000S doesn't support digital audio

 So I guess the analog part has always failed

 I am using the nvidia driver and a driver for my wireless card, I will
 turn these off and see if I can get a different result.

 During tuning for digital tv with the old driver I got

 [ 1081.808505] tda18271: performing RF tracking filter calibration
 [ 1086.152006] tda18271: RF tracking filter calibration complete
 [ 1091.020535] hda-intel: IRQ timing workaround is activated for card
 #0. Suggest a bigger bdl_pos_adj.


 The final line did not appear when I tried to tune using the new version

 [ 1225.904503] tda18271: performing RF tracking filter calibration
 [ 1230.272003] tda18271: RF tracking filter calibration complete

Michael,

The policy on this mailing list is to reply BELOW the quoted text.
Please keep this in mind for the future.

I didn't realize the board had a saa7130 chipset -- That explains a
lot.  This means that there actually is no tda8290 on the board.  (the
tda8290 is usually found inside the saa7131 chipset)

You can remove the line, TUNER_PHILIPS_TDA8290 from the card
definition in saa7134-cards.c -- replace it with TUNER_ABSENT.

That shouldn't fix the problem, but it would be interesting to hear if
it changes anything.  I see that communication with the tuner is
working properly...  It's taking 5 seconds to complete the rf tracking
filter calibration in either case, so we know that the line of
communication to the tuner itself isn't a problem.

I think this will be easier if we meet in irc.  Can you meed me in
#linuxtv on irc.freenode.net?

If not, please enable module option debug=1 to tda18271 and send back
full dmesg, unedited, including startup of the device and a tune
attempt.

Also, enable debug=1 for the tda10048 module -- maybe something
changed there.  I just tested this code with my ATSC saa7134 board
that uses the tda18271, and it's working fine, so I doubt it's the
tuner persay, but we should investigate anyway.

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

[PATCH 21/21] gspca pac7302/pac7311: remove prefixes