webcam drivers and V4L2_MEMORY_USERPTR support

2009-06-01 Thread Stefan Kost
hi,

I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers
v4l2src [1]. This allows to request shared memory buffers from xvideo,
capture into those and therefore save a memcpy. This works great with
the v4l2 driver on our embedded device.

When I was testing this on my desktop, I noticed that almost no driver
seems to support it.
I tested zc0301 and uvcvideo, but also grepped the kernel driver
sources. It seems that gspca might support it, but I ave not confirmed
it. Is there a technical reason for it, or is it simply not implemented?

Thanks
Stefan

[1] http://bugzilla.gnome.org/show_bug.cgi?id=583890
--
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://udev.netup.ru/hg/v4l-dvb-aospan

2009-06-01 Thread Mauro Carvalho Chehab
Em Wed, 27 May 2009 22:15:17 +0400
Abylai Ospan aos...@netup.ru escreveu:

 Mauro,
 
 Please pull from http://udev.netup.ru/hg/v4l-dvb-aospan/rev/e90b61dfd602
 
 Transport Stream continuity check. Very usefull for debugging when
 broken transport stream received.
 

Pulled, thanks.

 +/*
 + * uncomment this define for transport stream packets continuity counter 
 check
 + * #define DVB_DEMUX_SECTION_TS_COUNTER_CHECK
 + */

It wouldn't be better to add it as a Kconfig or as a module option, in order to
be easy for people to enable it?

Also, it may make sense to change it to use printk_ratelimit, to avoid it to 
produce
too much printk errors.



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: webcam drivers and V4L2_MEMORY_USERPTR support

2009-06-01 Thread Trent Piepho
On Mon, 1 Jun 2009, Stefan Kost wrote:
 I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers
 v4l2src [1]. This allows to request shared memory buffers from xvideo,
 capture into those and therefore save a memcpy. This works great with
 the v4l2 driver on our embedded device.

 When I was testing this on my desktop, I noticed that almost no driver
 seems to support it.
 I tested zc0301 and uvcvideo, but also grepped the kernel driver
 sources. It seems that gspca might support it, but I ave not confirmed
 it. Is there a technical reason for it, or is it simply not implemented?

userptr support is relatively new and so it has less support, especially
with driver that pre-date it.  Maybe USB cams use a compressed format and
so userptr with xvideo would not work anyway since xv won't support the
camera's native format.  It certainly could be done for bt8xx, cx88,
saa7134, etc.
--
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: webcam drivers and V4L2_MEMORY_USERPTR support

2009-06-01 Thread Stefan Kost
Trent Piepho schrieb:
 On Mon, 1 Jun 2009, Stefan Kost wrote:
   
 I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers
 v4l2src [1]. This allows to request shared memory buffers from xvideo,
 capture into those and therefore save a memcpy. This works great with
 the v4l2 driver on our embedded device.

 When I was testing this on my desktop, I noticed that almost no driver
 seems to support it.
 I tested zc0301 and uvcvideo, but also grepped the kernel driver
 sources. It seems that gspca might support it, but I ave not confirmed
 it. Is there a technical reason for it, or is it simply not implemented?
 

 userptr support is relatively new and so it has less support, especially
 with driver that pre-date it.  Maybe USB cams use a compressed format and
 so userptr with xvideo would not work anyway since xv won't support the
 camera's native format.  It certainly could be done for bt8xx, cx88,
 saa7134, etc.
 --
 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
   
Yes, I am aware of the format issue. On the gstreamer side formats are
negotiated. Plugins export e.g. wat colorpsaces they support and the
zerocopy path can only be taken if e.g. both support UVYV. Luckily this
is quite common.

But thanks for the info. I have nver touched kernel code sofar, but if I
find some free time, I can try to add support for it in one driver.

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


[SOLVED] Re: Mystique SaTiX DVB-S2 s2-liplianin Ubuntu 9.04 64 bit - modules load but tuning not successful

2009-06-01 Thread Thomas Kernen

Thomas Kernen wrote:


Dear team,

I'm installing a Mystique SaTiX DVB-S2 PCI card (apparently an OEM 
version of KNC DVB Station S2) in a box running Ubuntu 9.04 64bit. 
(2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:45:36 UTC 2009 x86_64 
GNU/Linux)


I've pulled the latest s2-liplianin code from:
http://mercurial.intuxication.org/hg/s2-liplianin

I was able to compile and the modules do load, but I don't seem to be 
able to tune to anything. Note that I've only tried to tune to DVB-S 
transponders for now.


lspci -vvv shows the following:
11:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: KNC One Device 0019
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-

Latency: 123 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 23
Region 0: Memory at d022 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_av
Kernel modules: budget-av

 From dmesg:
[9.796943] budget_av :11:09.0: PCI INT A - GSI 23 (level, low) 
- IRQ 23
[9.796972] saa7146: found saa7146 @ mem c20001186000 (revision 
1, irq 23) (0x1894,0x0019).

[9.796976] saa7146 (0): dma buffer size 192512
[9.796977] DVB: registering new adapter (KNC1 DVB-S2)
[9.853417] adapter failed MAC signature check
[9.853419] encoded MAC from EEPROM was 
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff

[   10.162850] KNC1-1: MAC addr = 00:09:d6:65:2d:91
[   10.35] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting 
for end of xfer

[   10.424422] stb0899_attach: Attaching STB0899
[   10.432541] tda8261_attach: Attaching TDA8261 8PSK/QPSK tuner
[   10.432543] DVB: registering adapter 1 frontend 0 (STB0899 
Multistandard)...

[   10.432731] budget-av: ci interface initialised.

dvbsnoop shows the following:
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/

-
FrontEnd Info...
-

Device: /dev/dvb/adapter1/frontend0

Basic capabilities:
Name: STB0899 Multistandard
Frontend-type:   QPSK (DVB-S)
Frequency (min): 950.000 MHz
Frequency (max): 2150.000 MHz
Frequency stepsiz:   0.000 MHz
Frequency tolerance: 0.000 MHz
Symbol rate (min): 1.00 MSym/s
Symbol rate (max): 45.00 MSym/s
Symbol rate tolerance: 0 ppm
Notifier delay: 0 ms
Frontend capabilities:
auto inversion
FEC AUTO
QPSK

Current parameters:
Frequency:  1776.000 MHz
Inversion:  AUTO
Symbol rate:  27.50 MSym/s
FEC:  FEC AUTO

If I try to use scan-s2 I get the following output:

API major 5, minor 0
ERROR: Cannot open rotor configuration file 'rotor.conf'.
scanning /usr/share/dvb/dvb-s/Astra-19.2E
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
initial transponder DVB-S  12551500 V 2200 5/6 AUTO AUTO
initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO
-- Using DVB-S
  tune to: 12551:vC56S0:S0.0W:22000:
DiSEqC: uncommitted switch pos 0
DiSEqC: e0 10 39 f0 00 00
DiSEqC: switch pos 0, 13V, hiband (index 2)
DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1951500
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
WARNING:  tuning failed!!!
  tune to: 12551:vC56S0:S0.0W:22000: (tuning failed)
DiSEqC: uncommitted switch pos 0
DiSEqC: e0 10 39 f0 00 00
DiSEqC: switch pos 0, 13V, hiband (index 2)
DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1951500
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
WARNING:  tuning failed!!!
-- Using DVB-S2
  tune to: 12551:vC56S1:S0.0W:22000:
DiSEqC: uncommitted switch pos 0
DiSEqC: e0 10 39 f0 00 00
DiSEqC: switch pos 0, 13V, hiband (index 2)
DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1951500
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
WARNING:  tuning failed!!!
  tune to: 12551:vC56S1:S0.0W:22000: (tuning failed)
DiSEqC: uncommitted switch pos 0
DiSEqC: e0 10 39 f0 00 00
DiSEqC: switch pos 0, 13V, hiband (index 2)
DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1951500
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 0x00
  tuning status == 

Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

2009-06-01 Thread Abylai Ospan
Mauro,

В Пнд, 01/06/2009 в 04:52 -0300, Mauro Carvalho Chehab пишет: 
  + * uncomment this define for transport stream packets continuity counter 
  check
  + * #define DVB_DEMUX_SECTION_TS_COUNTER_CHECK
  + */
 
 It wouldn't be better to add it as a Kconfig or as a module option, in order 
 to
 be easy for people to enable it?
module option seems more flexible.

 Also, it may make sense to change it to use printk_ratelimit, to avoid it to 
 produce
 too much printk errors.
yes, this right.

Please pulll new changes -
http://udev.netup.ru/hg/v4l-dvb-aospan/rev/4acf883807a8

1. Module option dvb_demux_tscheck added. Can be changed on fly ( by
echo 1  /sys/module/dvb_core/parameters/dvb_demux_tscheck). Check
disabled by default.
2. printk_ratelimit used.
3. DVB_DEMUX_SECTION_TS_COUNTER_CHECK define removed

-- 
Abylai Ospan aos...@netup.ru
NetUP Inc.


smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] Leadtek WinFast DTV-1800H support

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 01 Jun 2009 03:58:25 +0200
hermann pitton hermann-pit...@arcor.de escreveu:

 
 Am Sonntag, den 31.05.2009, 16:58 -0300 schrieb Mauro Carvalho Chehab:
  Em Sun, 31 May 2009 19:39:15 +0200
  Miroslav  Šustek sustmid...@centrum.cz escreveu:
  
   Trent Piepho xyzzy at speakeasy.org writes:
   
Instead of raising the reset line here, why not change the gpio 
settings in
the card definition to have it high? Change gpio1 for television to 
0x7050
and radio to 0x7010.
   Personally, I don't know when these .gpioX members are used (before
   firmware loads or after...).
   But I assume that adding the high on reset pin shouldn't break anything,
   so we can do this.
   
   And shouldn't we put tuner reset pin to 0 when in composite and s-video 
   mode?
   These inputs don't use tuner or do they?
   If I look in dmesg I can see that firmware is loaded into tuner even
   when these modes are used (I'm using MPlayer to select the input).
   And due to callbacks issued duting firmware loading, tuner is turned on
   (reset pin = 1) no matter if it was turned off by .gpioX setting.
   
   And shouldn't we use the mask bits [24:16] of MO_GPX_IO
   in .gpioX members too? I know only few GPIO pins and the other I don't
   know either what direction they should be. That means GPIO pins which
   I don't know are set as Hi-Z = inputs... Now, when I think of that,
   if it works it's safer when the other pins are in Hi-Z mode. Never mind.
   
   
Then the reset can be done with:
   
case XC2028_TUNER_RESET:
/* GPIO 12 (xc3028 tuner reset) */
cx_write(MO_GP1_IO, 0x101000);
mdelay(50);
cx_write(MO_GP1_IO, 0x101010);
mdelay(50);
return 0;
   
   Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write'
   is risky.
   see here: http://www.spinics.net/lists/linux-dvb/msg29777.html
   And when you are using 'cx_set' and 'cx_clear' you need 3 calls.
   The first to set the direction bit, the second to set 0 on reset pin
   and the third to set 1 on reset pin.
   If you ask me which I think is nicer I'll tell you: that one with 
   'cx_write'.
   If you ask me which one I want to use, I'll tell: I don't care. :)
   
Though I have to wonder why each card needs its own xc2028 reset 
function.
Shouldn't they all be the same other than what gpio they change?
   My English goes lame here. Do you mean that reset function shouldn't use
   GPIO at all?
   
   
@@ -2882,6 +2946,16 @@
cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */
udelay(1000);
break;
+
+ case CX88_BOARD_WINFAST_DTV1800H:
+ /* GPIO 12 (xc3028 tuner reset) */
+ cx_set(MO_GP1_IO, 0x1010);
+ mdelay(50);
+ cx_clear(MO_GP1_IO, 0x10);
+ mdelay(50);
+ cx_set(MO_GP1_IO, 0x10);
+ mdelay(50);
+ break;
}
}
   
Couldn't you replace this with:
   
case CX88_BOARD_WINFAST_DTV1800H:
cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0);
break;
   Yes, this will do the same job.
   I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C
   communication. The 'cx88_xc3028_winfast1800h_callback' 
   (cx88_tuner_callback)
   is meant to be used when tuner code (during firmware loading) needs it.
   This is probably why others did it this way (these are separated issues
   even if they do the same thing) and I only obey existing form.
   
   I only want to finally add the support for this card.
   You know many people (not developers) don't care if this function is used
   or that function is used twice, instead. They just want to install they 
   distro
   and watch the tv.
   I classify myself as an programmer rather than ordinary user, so I care 
   how
   the code looks like. I'm open to the discussion about these things, but
   this can take long time and I just want the card to be supported asap.
   There are more cards which has code like this so if linuxtv developers 
   realize
   eg. to not use callbacks or use only cx_set and cx_clear (instead of 
   cx_write)
   they'll do it all at once (not every card separately).
   
   I attached modified patch:
   - .gpioX members of inputs which use tuner have reset pin 1 (tuner 
   enabled)
   - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner 
   disabled)
   - resets (in callback and the one in pre_i2c) use only two 'cx_write' 
   calls
   
   I'm keeping the tested-by lines even if this modified version of patch 
   wasn't
   tested by those people (the previous version was). I trust this changes 
   can't
   break the functionality.
   If you think it's too audacious then drop them.
   
   It's on linuxtv developers which of these two patches will be chosen.
  
  For the sake of not loosing this patch again, I've applied it as-is. I hope 
  I
  got the latest version. It is hard to track patches that aren't got by 
  patchwork.
  
  I agree with Trent's proposals for optimizing the code: It is better to just
  call 

Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 01 Jun 2009 13:02:56 +0400
Abylai Ospan aos...@netup.ru escreveu:

 Mauro,
 
 В Пнд, 01/06/2009 в 04:52 -0300, Mauro Carvalho Chehab пишет: 
   + * uncomment this define for transport stream packets continuity counter 
   check
   + * #define DVB_DEMUX_SECTION_TS_COUNTER_CHECK
   + */
  
  It wouldn't be better to add it as a Kconfig or as a module option, in 
  order to
  be easy for people to enable it?
 module option seems more flexible.
 
  Also, it may make sense to change it to use printk_ratelimit, to avoid it 
  to produce
  too much printk errors.
 yes, this right.
 
 Please pulll new changes -
 http://udev.netup.ru/hg/v4l-dvb-aospan/rev/4acf883807a8

 
 # HG changeset patch
 # User Abylay Ospan aos...@netup.ru
 # Date 1243846636 -14400
 # Node ID 4acf883807a8f9fcd82f7c45ee61513955b6a82b
 # Parent d55ec37bebfa91dfa0586393551382ba37355b56
 TS continuity check: show error message when discontinuity detected or TEI 
 flag detected in header
 
 Signed-off-by: Abylay Ospan aos...@netup.ru
 
 --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 05:22:37 
 2009 -0300
 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 12:57:16 
 2009 +0400
 @@ -37,6 +37,13 @@
  ** #define DVB_DEMUX_SECTION_LOSS_LOG to monitor payload loss in the syslog
  */
  // #define DVB_DEMUX_SECTION_LOSS_LOG
 +
 +static int dvb_demux_tscheck;
 +module_param(dvb_demux_tscheck, int, 0644);
 +MODULE_PARM_DESC(dvb_demux_tscheck, enable transport stream continuity and 
 TEI check);
 +
 +#define dprintk_tscheck(x...) do { if (dvb_demux_tscheck  
 printk_ratelimit()) printk(x); } while (0)

Please check your patch against kernel codingstyle with checkpatch.pl. There
are some CodingStyle violations here and on the code bellow.

In this specific case, break it into one statement per line, like:

#define dprintk_tscheck(x...) do {  \
if (dvb_demux_tscheck  printk_ratelimit())\
printk(x);  \
} while (0)


 +
  
  
 /**
   * static inlined helper functions
 @@ -375,6 +382,24 @@
   struct dvb_demux_feed *feed;
   u16 pid = ts_pid(buf);
   int dvr_done = 0;
 +
 + int cnt_pid;
 +
 + if(dvb_demux_tscheck){

CodingStyle.

 + /* check pkt counter */
 + cnt_pid = ( (buf[1]  0x1f)8 ) | buf[2];

CodingStyle.

 +
 + if(cnt_pid != 0x1fff){

CodingStyle.

 + if( buf[1]  0x80 )

CodingStyle.

 + dprintk_tscheck(TEI detected. PID=0x%x 
 data1=0x%x\n, cnt_pid, buf[1]  );

CodingStyle.

 +
 + if( (buf[3]  0xf) != demux-cnt_storage[cnt_pid] )

CodingStyle.

 + dprintk_tscheck(TS packet counter mismatch. 
 PID=0x%x expected 0x%x got 0x%x\n, cnt_pid, demux-cnt_storage[cnt_pid], 
 buf[3]  0xf );

CodingStyle.

 +
 + demux-cnt_storage[cnt_pid] = ( (buf[3]  0xf) + 1)  
 0xf;

CodingStyle.

 + };
 + /* end check */
 + };
  
   list_for_each_entry(feed, demux-feed_list, list_head) {
   if ((feed-pid != pid)  (feed-pid != 0x2000))
 --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.hMon Jun 01 05:22:37 
 2009 -0300
 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.hMon Jun 01 12:57:16 
 2009 +0400
 @@ -128,6 +128,8 @@
  
   struct mutex mutex;
   spinlock_t lock;
 +
 + uint8_t cnt_storage[0x1fff]; /// for TS continuity check

Please, don't add the penalty of increasing the size of the struct to this
amount of size if debug is disabled. You should instead add a pointer here and
allocate it dynamically only if debug is enabled.

  };
  
  int dvb_dmx_init(struct dvb_demux *dvbdemux);
 

Also, as the previous changeset were already merged, do your patch against the 
current tree



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: [linux-dvb] SDMC DM1105N not being detected

2009-06-01 Thread Simon Kenyon

Igor M. Liplianin wrote:

On 30 May 2009 20:00:32 Igor M. Liplianin wrote:
  

On 26 May 2009 23:02:57 Simon Kenyon wrote:


Igor M. Liplianin wrote:
  

The card is working with external LNB power supply, for example,
through the loop out from another sat box. So, we need to know, which
way to control LNB power on the board. Usually it is through GPIO pins.
For example:
Pins 112 and 111 for GPIO0, GPIO1. Also GPIO15 is at 65 pin.
You can edit this lines in code:
-*-*-*-*-*-*-*-*-*-*-*-*-
/* GPIO's for LNB power control for Axess DM05 */
#define DM05_LNB_MASK   0xfffc  // GPIO
control #define DM05_LNB_13V0x3fffd // GPIO
value #define DM05_LNB_18V0x3fffc // GPIO
value -*-*-*-*-*-*-*-*-*-*-*-*-

BTW:
Bit value 0 for GPIOCTL means output, 1 - input.
Bit value for GPIOVAL - read/write.
GPIO pins count is 18. Bits over 18 affect nothing.


i will try to work out the correct values
when i have done so (or given up trying) i will let you know

thank you very much for your help
--
simon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Patch against latest v4l-dvb.
Please, test it.


Patch version 2

  

the picture seems to be breaking up badly
will revert to my version and see if that fixes it
--
simon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] xc2028: Add support for Taiwan 6 MHz DVB-T

2009-06-01 Thread Andy Walls
On Sun, 2009-05-31 at 20:50 -0400, Andy Walls wrote^Wescreveu:
 On Sun, 2009-05-31 at 16:33 -0300, Mauro Carvalho Chehab wrote:
  Em Sun, 31 May 2009 13:39:18 -0400
  Andy Walls awa...@radix.net escreveu:
  
 
 then I guess I'm OK with the change you have. 

Hmmm. Maybe not.

 
  So, the proper patch to tuner-xc3028 seems to be the enclosed one.
  
  If both of you and Terry agree, I'll apply this one at the tree.

I have to do more looking.  The 

 
  +   } else if (priv-cur_fw.type  DTV6) {
  +   /* For Taiwan DVB-T 6 MHz bandwidth - Terry Wu */
  +   offset = 175;

offset part of Terry's patch is missing from yours.  Based on what I now
know, I think setting the offset is necessary for 6 MHz DVB-T (DTV6) to
work.  I'll try to resubmit something tonight.

Regards,
Andy

  Cheers,
  Mauro.
  
  
  diff --git a/linux/drivers/media/common/tuners/tuner-xc2028.c 
  b/linux/drivers/media/common/tuners/tuner-xc2028.c
  --- a/linux/drivers/media/common/tuners/tuner-xc2028.c
  +++ b/linux/drivers/media/common/tuners/tuner-xc2028.c
  @@ -1026,21 +1026,20 @@ static int xc2028_set_params(struct dvb_
  switch(fe-ops.info.type) {
  case FE_OFDM:
  bw = p-u.ofdm.bandwidth;
  -   break;
  -   case FE_QAM:
  -   tuner_info(WARN: There are some reports that 
  -  QAM 6 MHz doesn't work.\n
  -  If this works for you, please report by 
  -  e-mail to: v4l-dvb-maintai...@linuxtv.org\n);
  -   bw = BANDWIDTH_6_MHZ;
  -   type |= QAM;
  +   /*
  +* The only countries with 6MHz seem to be Taiwan/Uruguay.
  +* Both seem to require QAM firmware for OFDM decoding
  +* Tested in Taiwan by Terry Wu terrywu2...@gmail.com
  +*/
  +   if (bw == BANDWIDTH_6_MHZ)
  +   type |= QAM;
  break;
  case FE_ATSC:
  bw = BANDWIDTH_6_MHZ;
  /* The only ATSC firmware (at least on v2.7) is D2633 */
  type |= ATSC | D2633;
  break;
  -   /* DVB-S is not supported */
  +   /* DVB-S and pure QAM (FE_QAM) are not supported */
  default:
  return -EINVAL;
  }
  
  
  
  
  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
 

--
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: Wiki software update

2009-06-01 Thread Johannes Stezenbach
Hi Hermann,

On Mon, Jun 01, 2009 at 02:08:07AM +0200, hermann pitton wrote:
 Am Montag, den 01.06.2009, 01:28 +0200 schrieb Johannes Stezenbach:
  
  I just updated the V4L-DVB Wiki and the old V4L Wiki
  to MediaWiki-1.14.0. Please let me know in case
  something broke.
 
 did not test all links, but on this one some older issues seem to still
 perpetuate.
 
 http://www.linuxtv.org/wiki/index.php?title=How_to_Perform_a_Bisectaction=edit
 
 I get, that I'm not allowed to do that.

Well, you need to be logged in to create or edit pages. Or are
you saying that you cannot edit this page even though you are logged in?


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


Zolid Hybrid TV Card wiki page

2009-06-01 Thread Sander Pientka
Hi, I've just created a wiki page for my tv card: 
http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner/ . I hope it 
provides usable information to make my card supported by saa7134.
-- 
Met vriendelijke groet,
Sander Pientka
--
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: Wiki software update

2009-06-01 Thread Johannes Stezenbach
On Mon, Jun 01, 2009 at 12:14:08PM +1000, Robin Perkins wrote:
 On 01/06/2009, at 9:28 AM, Johannes Stezenbach wrote:

 I just updated the V4L-DVB Wiki and the old V4L Wiki
 to MediaWiki-1.14.0. Please let me know in case
 something broke.

 Is there any possibility of renaming the v4l-dvb wiki to perhaps the  
 Linux-media Wiki just to get some persistence in names ? (I have had  
 people on irc ask if v4l-dvb can only do dvb.) Perhaps reflect that  
 Linux-media does more than just DVB on the LinuxTV main page as well?

I'd be fine with a rename, but I leave it up the Wiki power
users to decide. The links on http://wiki.kernel.org/ should
also be changed.


Johannes
--
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: webcam drivers and V4L2_MEMORY_USERPTR support

2009-06-01 Thread Hans de Goede



On 06/01/2009 09:58 AM, Trent Piepho wrote:

On Mon, 1 Jun 2009, Stefan Kost wrote:

I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers
v4l2src [1]. This allows to request shared memory buffers from xvideo,
capture into those and therefore save a memcpy. This works great with
the v4l2 driver on our embedded device.

When I was testing this on my desktop, I noticed that almost no driver
seems to support it.
I tested zc0301 and uvcvideo, but also grepped the kernel driver
sources. It seems that gspca might support it, but I ave not confirmed
it. Is there a technical reason for it, or is it simply not implemented?


userptr support is relatively new and so it has less support, especially
with driver that pre-date it.  Maybe USB cams use a compressed format and
so userptr with xvideo would not work anyway since xv won't support the
camera's native format.  It certainly could be done for bt8xx, cx88,
saa7134, etc.


Even in the webcam with custom compressed format case, userptr support could
be useful to safe a memcpy, as libv4l currently fakes mmap buffers, so what
happens  is:

cam direct transfer mmap buffer libv4l format conversion fake mmap buffer
application-memcpy dest buffer

So if libv4l would support userptr's (which it currently does not do) we
could still safe a memcpy here.

I would be willing to take *clean, non invasive* patches to libv4l to add
userptr support, but I'm not sure if this can be done in a clean way (haven't
tried).

An alternative could be for the app to just use read() in the above case
as then the app already provides the dest buffer. And the conversion will write
directly to the application provided buffer.

Regards,

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


CAM initialisation failing

2009-06-01 Thread Thomas Kernen


Dear community,

After finally getting my Mystique SaTiX DVB-S2 PCI card (clone of KNC1 
DVB Station S2), I'm now facing trouble with the CAM initialisation 
(KNC1 CA daughter card, PowerCam Pro CAM and Viaccess card)


All of the hardware (DVB-S2 PCI card, sat card, CI, CAM) has been tested 
under Windows with any issues, hence I suspect this is a module related 
issue.


To try and better understand the issue, I added some debug statements to 
the following modules:

options dvb-core cam_debug=1 debug=1
options budget-core debug=1

And this is the output I'm getting:

[9.146782] DVB: registering new adapter (KNC1 DVB-S2)
[9.203364] adapter failed MAC signature check
[9.203366] encoded MAC from EEPROM was 
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff

[9.410061] budget_av: saa7113_init(): saa7113 not found on KNC card
[9.510352] KNC1-1: MAC addr = 00:09:d6:65:2d:91
[9.642505] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting 
for end of xfer

[9.764427] stb0899_attach: Attaching STB0899
[9.776853] tda8261_attach: Attaching TDA8261 8PSK/QPSK tuner
[9.776855] DVB: registering adapter 1 frontend 0 (STB0899 
Multistandard)...

[9.776888] dvb_ca_en50221_init
[9.777048] budget-av: ci interface initialised.
[9.777050] dvb_ca_en50221_thread
snip
[   14.770017] budget-av: cam inserted A
[   14.770032] budget_av: ciintf_slot_reset(): ciintf_slot_reset
[   14.950033] TUPLE type:0x1d length:4
[   14.950041]   0x00: 0x00 .
[   14.950048]   0x01: 0x61 a
[   14.950055]   0x02: 0x00 .
[   14.950063]   0x03: 0xff .
[   14.950076] TUPLE type:0x1c length:4
[   14.950083]   0x00: 0x00 .
[   14.950091]   0x01: 0xd3 .
[   14.950098]   0x02: 0x00 .
[   14.950105]   0x03: 0xff .
[   14.950118] TUPLE type:0x15 length:11
[   14.950126]   0x00: 0x05 .
[   14.950133]   0x01: 0x00 .
[   14.950140]   0x02: 0x47 G
[   14.950147]   0x03: 0x00 .
[   14.950154]   0x04: 0x4d M
[   14.950161]   0x05: 0x00 .
[   14.950168]   0x06: 0x4c L
[   14.950175]   0x07: 0x00 .
[   14.950182]   0x08: 0x4c L
[   14.950189]   0x09: 0x00 .
[   14.950196]   0x0a: 0xff .
[   14.950210] TUPLE type:0x20 length:4
[   14.950217]   0x00: 0x02 .
[   14.950224]   0x01: 0xca .
[   14.950232]   0x02: 0x12 .
[   14.950239]   0x03: 0x60 `
[   14.950252] TUPLE type:0x1a length:21
[   14.950260]   0x00: 0x01 .
[   14.950267]   0x01: 0x0f .
[   14.950274]   0x02: 0x00 .
[   14.950281]   0x03: 0x02 .
[   14.950288]   0x04: 0x03 .
[   14.950295]   0x05: 0xc0 .
[   14.950302]   0x06: 0x0e .
[   14.950309]   0x07: 0x41 A
[   14.950316]   0x08: 0x02 .
[   14.950323]   0x09: 0x44 D
[   14.950330]   0x0a: 0x56 V
[   14.950337]   0x0b: 0x42 B
[   14.950344]   0x0c: 0x5f _
[   14.950352]   0x0d: 0x43 C
[   14.950359]   0x0e: 0x49 I
[   14.950366]   0x0f: 0x5f _
[   14.950373]   0x10: 0x56 V
[   14.950380]   0x11: 0x31 1
[   14.950387]   0x12: 0x2e .
[   14.950394]   0x13: 0x30 0
[   14.950401]   0x14: 0x30 0
[   14.950415] TUPLE type:0x1b length:42
[   14.950422]   0x00: 0xcf .
[   14.950429]   0x01: 0x04 .
[   14.950436]   0x02: 0x09 .
[   14.950443]   0x03: 0x7f .
[   14.950450]   0x04: 0x55 U
[   14.950458]   0x05: 0xcd .
[   14.950465]   0x06: 0x19 .
[   14.950472]   0x07: 0xd5 .
[   14.950479]   0x08: 0x19 .
[   14.950486]   0x09: 0x3d =
[   14.950493]   0x0a: 0x9e .
[   14.950500]   0x0b: 0x25 %
[   14.950507]   0x0c: 0x26 
[   14.950514]   0x0d: 0x54 T
[   14.950521]   0x0e: 0x22 
[   14.950528]   0x0f: 0xc0 .
[   14.950535]   0x10: 0x09 .
[   14.950542]   0x11: 0x44 D
[   14.950549]   0x12: 0x56 V
[   14.950557]   0x13: 0x42 B
[   14.950564]   0x14: 0x5f _
[   14.950571]   0x15: 0x48 H
[   14.950578]   0x16: 0x4f O
[   14.950585]   0x17: 0x53 S
[   14.950592]   0x18: 0x54 T
[   14.950599]   0x19: 0x00 .
[   14.950606]   0x1a: 0xc1 .
[   14.950613]   0x1b: 0x0e .
[   14.950620]   0x1c: 0x44 D
[   14.950627]   0x1d: 0x56 V
[   14.950634]   0x1e: 0x42 B
[   14.950642]   0x1f: 0x5f _
[   14.950649]   0x20: 0x43 C
[   14.950656]   0x21: 0x49 I
[   14.950663]   0x22: 0x5f _
[   14.950670]   0x23: 0x4d M
[   14.950677]   0x24: 0x4f O
[   14.950684]   0x25: 0x44 D
[   14.950691]   0x26: 0x55 U
[   14.950698]   0x27: 0x4c L
[   14.950705]   0x28: 0x45 E
[   14.950712]   0x29: 0x00 .
[   14.950727] TUPLE type:0x14 length:0
[   14.950734] END OF CHAIN TUPLE type:0xff
[   14.950735] Valid DVB CAM detected MANID:ca02 DEVID:6012 
CONFIGBASE:0x200 CONFIGOPTION:0xf

[   14.950736] dvb_ca_en50221_set_configoption
[   14.950750] Set configoption 0xf, read configoption 0xf
[   14.950757] DVB CAM validated successfully
snip
[   15.050023] dvb_ca_en50221_link_init
[   15.050030] dvb_ca_en50221_wait_if_status
[   15.050037] dvb_ca_en50221_wait_if_status succeeded timeout:0
[   15.050038] dvb_ca_en50221_read_data
[   15.050084] dvb_ca adapter 1: DVB CAM link initialisation failed :(

So if I understand correctly the CAM is ok but the en50221 module is 
times out when trying to read the card, is this correct?


Any 

Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

2009-06-01 Thread Abylai Ospan
В Пнд, 01/06/2009 в 06:38 -0300, Mauro Carvalho Chehab пишет:
 Please check your patch against kernel codingstyle with checkpatch.pl. There
 are some CodingStyle violations here and on the code bellow.
Please pull new changes - 
http://udev.netup.ru/hg/v4l-dvb-aospan/rev/0d3e6c0695cc

1. checkpatch.pl don't show warnings/errors ( except printk line
length ).

2. cnt_storage array dinamically allocated before doing checks. We can't
allocate it in dvb_dmx_init routine because module option
dvb_demux_tscheck  can be enabled on running system ( not in module
startup only ).

-- 
Abylai Ospan aos...@netup.ru
NetUP Inc.


smime.p7s
Description: S/MIME cryptographic signature


Re: [PULL] generic image bounds setting and alignment function

2009-06-01 Thread Robert Jarzmik
Trent Piepho xy...@speakeasy.org writes:

 Mauro,

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

 This series adds a function for bounding and alignment image sizes and
 modifies a number of drivers to use it.  It came up when the pxa patches to
 deal with the alignment issues for that driver were posted.  I haven't
 tested these patches for pxa.

Hi Trent,

I didn't see the review of that serie, I'm curious what others said.
As for my comments, I'll inline your code, sorry about that.

 02/14: v4l2: Create helper function for bounding and aligning images
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d

+static unsigned int clamp_align(unsigned int x, unsigned int min,
+   unsigned int max, unsigned int align)
+{
+   /* Bits that must be zero to be aligned */
+   unsigned int mask = ~((1  align) - 1);
+
+   /* Round to nearest aligned value */
+   if (align)
+   x = (x + (1  (align - 1)))  mask;

If I'm not mistaken, these lines are an equivalent of :
balign = 1  align;
if (align)
x = ALIGN(x + 1 - balign/2, balign);

Isn't that simpler to read ?

+
+   /* Clamp to aligned value of min and max */
+   if (x  min)
+   x = (min + ~mask)  mask;
+   else if (x  max)
+   x = max  mask;
+
+   return x;
+}

 03/14: pxa-camera: Use v4l bounding/alignment function
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=cb48209c1841

+ /* Limit to pxa hardware capabilities. YUV422P planar format requires
+ * images size to be a multiple of 16 bytes. If not, zeros will be
+ * inserted between Y and U planes, and U and V planes, which violates
+ * the YUV422P standard. */
The multiple lines comment format, according to the Coding Style, would be
rather :
/*
 *
 */
That is a question for Guennadi, as he is the maintainer of pxa_camera.

+ v4l2_bound_align_image(pix-width, 48, 2048, 1,
+ pix-height, 32, 2048, 0,
+ xlate-host_fmt-fourcc == V4L2_PIX_FMT_YUV422P ? 4 : 0);

Cheers.

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


RE: [PATCH 3/9] dm355 ccdc module for vpfe capture driver

2009-06-01 Thread Karicheri, Muralidharan
Laurent,

Thanks for reviewing this. I have not gone through all of your comments, but 
would like to respond to the following one first. I will respond to the rest as 
I do the rework.

I've had a quick look at the DM355 and DM6446 datasheets. The CCDC and VPSS
registers share the same memory block. Can't you use a single resource ?

One nice (and better in my opinion) solution would be to declare a
structure
with all the VPSS/CCDC registers as they are implemented in hardware and
access the structure fields with __raw_read/write*. You would then store a
single pointer only. Check arch/powerpc/include/asm/immap_cpm2.h for an
example.

I think, a better solution will be to move the vpss system module part to the 
board specific file dm355.c or dm6446.c and export functions to configure them 
as needed by the different drivers. The vpss has evolved quite a lot from 
DM6446 to DM355 to DM365. Registers such as INTSEL and INTSTAT and others are 
applicable to other modules as well, not just the ccdc module. The VPBE and 
resizer drivers will need to configure them too. Also the vpss system module 
features available in DM365 is much more than that in DM355. Interrupts line to 
ARM are programmable in DM365 vpss and multiple vpss irq lines can be muxed to 
the ARM side. So I would imaging functions enable/disable irq line to arm, 
clearing irq bits, enabling various clocks etc can be done in a specific soc 
specific file (dm355.c, dm365.c or dm6446.c) and can be exported for use in 
specific drivers. I just want to get your feedback so that I can make this 
change. With this change, there is no need to use structures for holding 
register offsets as you have suggested.
--
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


New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Paulraj, Sandeep

Hello,

WE have a module(H3A) on Davinci DM6446,DM355 and DM365.

Customers require a way to collect the data required to perform the Auto 
Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as 
opposed to software. This is primarily for performance reasons as there is not 
enough software processing MIPS (to do 3A statistics) available in
an imaging/video system.

Including this block in hardware reduces the load on the processor and 
bandwidth to the memory as the data is collected on the fly from the imager.

This modules collects statistics and we currently implement it as a character 
driver.

Which mailing list would be the most appropriate mailing list to submit patches 
for review?

Thanks,
Sandeep
--
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] em28xx device mode detection based on endpoints

2009-06-01 Thread Devin Heitmueller
On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger
mrechber...@gmail.com wrote:
 Hi,

 On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger
 mrechber...@gmail.com wrote:
 On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger
 mrechber...@gmail.com wrote:
 Hi,

 for em28xx devices the device node detection can be based on the
 encoded endpoint address, for example EP 0x81 (USB IN, Interrupt),
 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input
 EP).
 It is not necessary that digital TV devices have a frontend, the
 em28xx chip only specifies an MPEG-TS input EP.

 Following patch adds a check based on the Endpoints, although it might
 be extended that all devices match the possible devicenodes based on
 the endpoints, currently the driver registers an analog TV node by
 default for all unknown devices which is not necessarily correct, this
 patch disables the ATV node if no analog TV endpoint is available.



 attached patch fixes the deregistration, as well loads the em28xx-dvb
 module automatically as soon as an MPEG-TS endpoint was found.

 Signed-off-by: Markus Rechberger mrechber...@gmail.com

 best regards,
 Markus


Hello Markus,

I spent some time reviewing this patch, and the patch's content does
not seem to match your description of its functionality.  Further,
this patch appears to be a combination of a number of several
different changes, rather than being broken into separate patches.

First off, I totally agree that the analog subsystem should not be
loaded on devices such as em287[0-4].  I was going to do this work
(using the chip id to determine analog support) but just had not had a
chance to doing the necessary testing to ensure it did not break
anything.

The patch appears to be primarily for devices that are not supported
in the kernel.  In fact, the logic as written *only* gets used for
unknown devices.  Further, the code that doesn't create the frontend
device has no application in the kernel.  All devices currently in the
kernel make use of the dvb frontend interface, so there is no
practical application to loading the driver and setting up the isoc
handlers but blocking access to the dvb frontend device.

Aside from the code that selectively disables analog support, the
patch only seems to advance compatibility with your userland em28xx
framework while providing no benefit to the in-kernel driver.

Regarding the possibility of custom firmware, we currently do not have
any devices in the in-kernel driver that make use of custom firmware.
If you could tell me how to check for custom firmware versus the
default vendor firmware, I could potentially do a patch that uses the
vendor registers unless custom firmware is installed, at which point
we could have custom logic (such as using the endpoint definition).
However, given there are no such devices in-kernel, this is not a high
priority as far as I am concerned.

For what it's worth, I did add an additional patch to allow the user
to disable the 480Mbps check via a modprobe option (to avoid a
regression for any of your existing customers), and I will be checking
in the code to properly compute the isoc size for em2874/em2884 based
on the vendor registers (even though there are currently no supported
devices in the kernel that require it currently).  However, I do not
believe the patch you have proposed is appropriate for inclusion in
the mainline kernel.

Regards,

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: [PATCH] em28xx device mode detection based on endpoints

2009-06-01 Thread Markus Rechberger
On Mon, Jun 1, 2009 at 5:19 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger
 mrechber...@gmail.com wrote:
 Hi,

 On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger
 mrechber...@gmail.com wrote:
 On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger
 mrechber...@gmail.com wrote:
 Hi,

 for em28xx devices the device node detection can be based on the
 encoded endpoint address, for example EP 0x81 (USB IN, Interrupt),
 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input
 EP).
 It is not necessary that digital TV devices have a frontend, the
 em28xx chip only specifies an MPEG-TS input EP.

 Following patch adds a check based on the Endpoints, although it might
 be extended that all devices match the possible devicenodes based on
 the endpoints, currently the driver registers an analog TV node by
 default for all unknown devices which is not necessarily correct, this
 patch disables the ATV node if no analog TV endpoint is available.



 attached patch fixes the deregistration, as well loads the em28xx-dvb
 module automatically as soon as an MPEG-TS endpoint was found.

 Signed-off-by: Markus Rechberger mrechber...@gmail.com

 best regards,
 Markus


 Hello Markus,

 I spent some time reviewing this patch, and the patch's content does
 not seem to match your description of its functionality.  Further,
 this patch appears to be a combination of a number of several
 different changes, rather than being broken into separate patches.


what doesn't match the description?

 First off, I totally agree that the analog subsystem should not be
 loaded on devices such as em287[0-4].  I was going to do this work
 (using the chip id to determine analog support) but just had not had a
 chance to doing the necessary testing to ensure it did not break
 anything.

 The patch appears to be primarily for devices that are not supported
 in the kernel.  In fact, the logic as written *only* gets used for
 unknown devices.  Further, the code that doesn't create the frontend
 device has no application in the kernel.

this is wrong, there are devices without a tuner frontend, mpeg
encoders (as written earlier already)
The em28xx chip only defines an mpeg-ts input, whenever a customer
wants to add a frontend or
mpeg encoder is up to him.

 All devices currently in the
 kernel make use of the dvb frontend interface, so there is no
 practical application to loading the driver and setting up the isoc
 handlers but blocking access to the dvb frontend device.

 Aside from the code that selectively disables analog support, the
 patch only seems to advance compatibility with your userland em28xx
 framework while providing no benefit to the in-kernel driver.


There's also a tuner customization option in the kernel module (eg set tuner ID
manually). This more or less can be seen as a cleanup, further patches would
come up. The next step would be to add customization support for various chips
this would allow me to just drop in a demod for certain customers who are aware
that they are not allowed to forward their modules. The application is mainly
for business customers who don't ship to endusers and make up a direct deal
with eg. Micronas. There is no reason to punish one company because the other
one denies it.

 Regarding the possibility of custom firmware, we currently do not have
 any devices in the in-kernel driver that make use of custom firmware.
 If you could tell me how to check for custom firmware versus the
 default vendor firmware, I could potentially do a patch that uses the
 vendor registers unless custom firmware is installed, at which point
 we could have custom logic (such as using the endpoint definition).
 However, given there are no such devices in-kernel, this is not a high
 priority as far as I am concerned.


endpoint size as mentioned already, old firmware shows up the endpoint size of 0
newer one shows up a certain size.

 For what it's worth, I did add an additional patch to allow the user
 to disable the 480Mbps check via a modprobe option (to avoid a
 regression for any of your existing customers)

All my customers are using the other kernel driver since the existing
one is too limited right now

best regards,
Markus
--
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] em28xx device mode detection based on endpoints

2009-06-01 Thread Douglas Schilling Landgraf
Hello Devin,

On Mon, 1 Jun 2009 11:19:22 -0400
Devin Heitmueller dheitmuel...@kernellabs.com wrote:

 On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger
 mrechber...@gmail.com wrote:
  Hi,
 
  On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger
  mrechber...@gmail.com wrote:
  On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger
  mrechber...@gmail.com wrote:
  Hi,
 
  for em28xx devices the device node detection can be based on the
  encoded endpoint address, for example EP 0x81 (USB IN, Interrupt),
  0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts
  input EP).
  It is not necessary that digital TV devices have a frontend, the
  em28xx chip only specifies an MPEG-TS input EP.
 
  Following patch adds a check based on the Endpoints, although it
  might be extended that all devices match the possible devicenodes
  based on the endpoints, currently the driver registers an analog
  TV node by default for all unknown devices which is not
  necessarily correct, this patch disables the ATV node if no
  analog TV endpoint is available.
 
 
 
  attached patch fixes the deregistration, as well loads the
  em28xx-dvb module automatically as soon as an MPEG-TS endpoint was
  found.
 
  Signed-off-by: Markus Rechberger mrechber...@gmail.com
 
  best regards,
  Markus
 
 
 Hello Markus,
 
 I spent some time reviewing this patch, and the patch's content does
 not seem to match your description of its functionality.  Further,
 this patch appears to be a combination of a number of several
 different changes, rather than being broken into separate patches.
 
 First off, I totally agree that the analog subsystem should not be
 loaded on devices such as em287[0-4].  I was going to do this work
 (using the chip id to determine analog support) but just had not had a
 chance to doing the necessary testing to ensure it did not break
 anything.
 
 The patch appears to be primarily for devices that are not supported
 in the kernel.  In fact, the logic as written *only* gets used for
 unknown devices.  Further, the code that doesn't create the frontend
 device has no application in the kernel.  All devices currently in the
 kernel make use of the dvb frontend interface, so there is no
 practical application to loading the driver and setting up the isoc
 handlers but blocking access to the dvb frontend device.
 
 Aside from the code that selectively disables analog support, the
 patch only seems to advance compatibility with your userland em28xx
 framework while providing no benefit to the in-kernel driver.

 Regarding the possibility of custom firmware, we currently do not have
 any devices in the in-kernel driver that make use of custom firmware.
 If you could tell me how to check for custom firmware versus the
 default vendor firmware, I could potentially do a patch that uses the
 vendor registers unless custom firmware is installed, at which point
 we could have custom logic (such as using the endpoint definition).
 However, given there are no such devices in-kernel, this is not a high
 priority as far as I am concerned.
 
 For what it's worth, I did add an additional patch to allow the user
 to disable the 480Mbps check via a modprobe option (to avoid a
 regression for any of your existing customers), and I will be checking
 in the code to properly compute the isoc size for em2874/em2884 based
 on the vendor registers (even though there are currently no supported
 devices in the kernel that require it currently).  However, I do not
 believe the patch you have proposed is appropriate for inclusion in
 the mainline kernel.

Agree with you Devin. 

Also, the patch does a lot of changes instead of break it in several
patches.

Cheers,
Douglas
--
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] em28xx device mode detection based on endpoints

2009-06-01 Thread Markus Rechberger
On Mon, Jun 1, 2009 at 6:04 PM, Douglas Schilling Landgraf
dougsl...@gmail.com wrote:
 Hello Devin,

 On Mon, 1 Jun 2009 11:19:22 -0400
 Devin Heitmueller dheitmuel...@kernellabs.com wrote:

 On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger
 mrechber...@gmail.com wrote:
  Hi,
 
  On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger
  mrechber...@gmail.com wrote:
  On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger
  mrechber...@gmail.com wrote:
  Hi,
 
  for em28xx devices the device node detection can be based on the
  encoded endpoint address, for example EP 0x81 (USB IN, Interrupt),
  0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts
  input EP).
  It is not necessary that digital TV devices have a frontend, the
  em28xx chip only specifies an MPEG-TS input EP.
 
  Following patch adds a check based on the Endpoints, although it
  might be extended that all devices match the possible devicenodes
  based on the endpoints, currently the driver registers an analog
  TV node by default for all unknown devices which is not
  necessarily correct, this patch disables the ATV node if no
  analog TV endpoint is available.
 
 
 
  attached patch fixes the deregistration, as well loads the
  em28xx-dvb module automatically as soon as an MPEG-TS endpoint was
  found.
 
  Signed-off-by: Markus Rechberger mrechber...@gmail.com
 
  best regards,
  Markus
 

 Hello Markus,

 I spent some time reviewing this patch, and the patch's content does
 not seem to match your description of its functionality.  Further,
 this patch appears to be a combination of a number of several
 different changes, rather than being broken into separate patches.

 First off, I totally agree that the analog subsystem should not be
 loaded on devices such as em287[0-4].  I was going to do this work
 (using the chip id to determine analog support) but just had not had a
 chance to doing the necessary testing to ensure it did not break
 anything.

 The patch appears to be primarily for devices that are not supported
 in the kernel.  In fact, the logic as written *only* gets used for
 unknown devices.  Further, the code that doesn't create the frontend
 device has no application in the kernel.  All devices currently in the
 kernel make use of the dvb frontend interface, so there is no
 practical application to loading the driver and setting up the isoc
 handlers but blocking access to the dvb frontend device.

 Aside from the code that selectively disables analog support, the
 patch only seems to advance compatibility with your userland em28xx
 framework while providing no benefit to the in-kernel driver.

 Regarding the possibility of custom firmware, we currently do not have
 any devices in the in-kernel driver that make use of custom firmware.
 If you could tell me how to check for custom firmware versus the
 default vendor firmware, I could potentially do a patch that uses the
 vendor registers unless custom firmware is installed, at which point
 we could have custom logic (such as using the endpoint definition).
 However, given there are no such devices in-kernel, this is not a high
 priority as far as I am concerned.

 For what it's worth, I did add an additional patch to allow the user
 to disable the 480Mbps check via a modprobe option (to avoid a
 regression for any of your existing customers), and I will be checking
 in the code to properly compute the isoc size for em2874/em2884 based
 on the vendor registers (even though there are currently no supported
 devices in the kernel that require it currently).  However, I do not
 believe the patch you have proposed is appropriate for inclusion in
 the mainline kernel.

 Agree with you Devin.

 Also, the patch does a lot of changes instead of break it in several
 patches.


do you want smaller patches?

regards,
Markus
--
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] em28xx device mode detection based on endpoints

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 1 Jun 2009 18:07:24 +0200
Markus Rechberger mrechber...@gmail.com escreveu:

  I spent some time reviewing this patch, and the patch's content does
  not seem to match your description of its functionality.  Further,
  this patch appears to be a combination of a number of several
  different changes, rather than being broken into separate patches.
 
  First off, I totally agree that the analog subsystem should not be
  loaded on devices such as em287[0-4].  I was going to do this work
  (using the chip id to determine analog support) but just had not had a
  chance to doing the necessary testing to ensure it did not break
  anything.
 
  The patch appears to be primarily for devices that are not supported
  in the kernel.  In fact, the logic as written *only* gets used for
  unknown devices.  Further, the code that doesn't create the frontend
  device has no application in the kernel.  All devices currently in the
  kernel make use of the dvb frontend interface, so there is no
  practical application to loading the driver and setting up the isoc
  handlers but blocking access to the dvb frontend device.
 
  Aside from the code that selectively disables analog support, the
  patch only seems to advance compatibility with your userland em28xx
  framework while providing no benefit to the in-kernel driver.
 
  Regarding the possibility of custom firmware, we currently do not have
  any devices in the in-kernel driver that make use of custom firmware.
  If you could tell me how to check for custom firmware versus the
  default vendor firmware, I could potentially do a patch that uses the
  vendor registers unless custom firmware is installed, at which point
  we could have custom logic (such as using the endpoint definition).
  However, given there are no such devices in-kernel, this is not a high
  priority as far as I am concerned.
 
  For what it's worth, I did add an additional patch to allow the user
  to disable the 480Mbps check via a modprobe option (to avoid a
  regression for any of your existing customers), and I will be checking
  in the code to properly compute the isoc size for em2874/em2884 based
  on the vendor registers (even though there are currently no supported
  devices in the kernel that require it currently).  However, I do not
  believe the patch you have proposed is appropriate for inclusion in
  the mainline kernel.
 
  Agree with you Devin.
 
  Also, the patch does a lot of changes instead of break it in several
  patches.
 
 
 do you want smaller patches?

Markus,

Please break it into smaller patches, being one patch per change. This makes
easier for me to review and for people to comment each one of the addressed 
issues.



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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 1 Jun 2009 09:56:40 -0500
Paulraj, Sandeep s-paul...@ti.com escreveu:

 
 Hello,
 
 WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
 
 Customers require a way to collect the data required to perform the Auto 
 Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as 
 opposed to software. This is primarily for performance reasons as there is 
 not enough software processing MIPS (to do 3A statistics) available in
 an imaging/video system.
 
 Including this block in hardware reduces the load on the processor and 
 bandwidth to the memory as the data is collected on the fly from the imager.
 
 This modules collects statistics and we currently implement it as a character 
 driver.
 
 Which mailing list would be the most appropriate mailing list to submit 
 patches for review?

You should send they to:
LMML linux-media@vger.kernel.org

If you are proposing API changes, please submit they first.

 
 Thanks,
 Sandeep
 --
 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




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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Paulraj, Sandeep


 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
 Sent: Monday, June 01, 2009 12:35 PM
 To: Paulraj, Sandeep
 Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen,
 Mark
 Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
 
 Em Mon, 1 Jun 2009 09:56:40 -0500
 Paulraj, Sandeep s-paul...@ti.com escreveu:
 
 
  Hello,
 
  WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
 
  Customers require a way to collect the data required to perform the Auto
 Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
 opposed to software. This is primarily for performance reasons as there is
 not enough software processing MIPS (to do 3A statistics) available in
  an imaging/video system.
 
  Including this block in hardware reduces the load on the processor and
 bandwidth to the memory as the data is collected on the fly from the
 imager.
 
  This modules collects statistics and we currently implement it as a
 character driver.
 
  Which mailing list would be the most appropriate mailing list to submit
 patches for review?
 
 You should send they to:
   LMML linux-media@vger.kernel.org
 
 If you are proposing API changes, please submit they first.
[Sandeep] WE don't propose any API changes. This module for which we want to 
submit patches is a TI proprietary IP. We currently implement this as a 
character device and have a few IOCTL's.
We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.

Can we continue to use it as a character driver?
 
 
  Thanks,
  Sandeep
  --
  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
 
 
 
 
 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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 1 Jun 2009 11:54:37 -0500
Paulraj, Sandeep s-paul...@ti.com escreveu:

 
 
  -Original Message-
  From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
  Sent: Monday, June 01, 2009 12:35 PM
  To: Paulraj, Sandeep
  Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen,
  Mark
  Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
  
  Em Mon, 1 Jun 2009 09:56:40 -0500
  Paulraj, Sandeep s-paul...@ti.com escreveu:
  
  
   Hello,
  
   WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
  
   Customers require a way to collect the data required to perform the Auto
  Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
  opposed to software. This is primarily for performance reasons as there is
  not enough software processing MIPS (to do 3A statistics) available in
   an imaging/video system.
  
   Including this block in hardware reduces the load on the processor and
  bandwidth to the memory as the data is collected on the fly from the
  imager.
  
   This modules collects statistics and we currently implement it as a
  character driver.
  
   Which mailing list would be the most appropriate mailing list to submit
  patches for review?
  
  You should send they to:
  LMML linux-media@vger.kernel.org
  
  If you are proposing API changes, please submit they first.
 [Sandeep] WE don't propose any API changes. This module for which we want to 
 submit patches is a TI proprietary IP. We currently implement this as a 
 character device and have a few IOCTL's.
 We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.
 
 Can we continue to use it as a character driver?

In this case, I don't see why you want it to be 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


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

2009-06-01 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:Mon Jun  1 19:00:06 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11918:e6a8672631a0
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: WARNINGS
linux-2.6.28-armv5: WARNINGS
linux-2.6.29.1-armv5: OK
linux-2.6.30-rc7-armv5: OK
linux-2.6.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-rc7-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-rc7-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-rc7-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-rc7-m32r: OK
linux-2.6.22.19-mips: ERRORS
linux-2.6.26-mips: ERRORS
linux-2.6.27-mips: ERRORS
linux-2.6.28-mips: ERRORS
linux-2.6.29.1-mips: ERRORS
linux-2.6.30-rc7-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-rc7-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-rc7-x86_64: WARNINGS
sparse (linux-2.6.29.1): OK
sparse (linux-2.6.30-rc7): 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: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
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: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The V4L2 specification from this daily build is here:

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

The DVB API specification from this daily build 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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Aguirre Rodriguez, Sergio Alberto
 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] 
 On Behalf Of Paulraj, Sandeep
 Sent: Monday, June 01, 2009 5:56 PM
 To: linux-media@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org; Grosen, Mark
 Subject: New Driver for DaVinci DM355/DM365/DM6446
 
 Hello,
 
 WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
 
 Customers require a way to collect the data required to perform the Auto 
 Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as 
 opposed to software.  This is primarily for performance reasons as there is 
 not enough software processing MIPS (to do 3A statistics) available in
 an imaging/video system.
 
 Including this block in hardware reduces the load on the processor and 
 bandwidth to the memory as the data is collected on the fly from the imager.
 
 This modules collects statistics and we currently implement it as a character 
 driver.

This also exists in OMAP3 chips, and is part of the ISP module.

I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently 
just shared through a gitorious repository:

http://gitorious.org/omap3camera

The way we offer an interface for the user to be able to request this 
statistics is with the usage of private IOCTLs declared inside the same V4L2 
capturing device driver.

So, that way we have a V4L2 driver which has a private call, instead of having 
it separately from the capture driver.

Regards,
Sergio
 
 Which mailing list would be the most appropriate mailing list to submit 
 patches for review?
 
 Thanks,
 Sandeep
 --
 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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Paulraj, Sandeep
Mauro,
  Please see inline

 -Original Message-
 From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
 Sent: Monday, June 01, 2009 1:57 PM
 To: Paulraj, Sandeep
 Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen,
 Mark
 Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
 
 Em Mon, 1 Jun 2009 11:54:37 -0500
 Paulraj, Sandeep s-paul...@ti.com escreveu:
 
 
 
   -Original Message-
   From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
   Sent: Monday, June 01, 2009 12:35 PM
   To: Paulraj, Sandeep
   Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen,
   Mark
   Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
  
   Em Mon, 1 Jun 2009 09:56:40 -0500
   Paulraj, Sandeep s-paul...@ti.com escreveu:
  
   
Hello,
   
WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
   
Customers require a way to collect the data required to perform the
 Auto
   Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in
 hardware as
   opposed to software. This is primarily for performance reasons as
 there is
   not enough software processing MIPS (to do 3A statistics) available in
an imaging/video system.
   
Including this block in hardware reduces the load on the processor
 and
   bandwidth to the memory as the data is collected on the fly from the
   imager.
   
This modules collects statistics and we currently implement it as a
   character driver.
   
Which mailing list would be the most appropriate mailing list to
 submit
   patches for review?
  
   You should send they to:
 LMML linux-media@vger.kernel.org
  
   If you are proposing API changes, please submit they first.
  [Sandeep] WE don't propose any API changes. This module for which we
 want to submit patches is a TI proprietary IP. We currently implement this
 as a character device and have a few IOCTL's.
  We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.
 
  Can we continue to use it as a character driver?
 
 In this case, I don't see why you want it to be upstream.
[Sandeep] TI customers and TI itself want to see this driver part of open 
source trees. Considering this we would like to submit our patches to the 
linux-media mailing list.
IS this OK?
 
 
 
 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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Karicheri, Muralidharan
Sergio,

Is it part of the patches Vaibhav  others from TI are submitting to open 
source ? I know that there is an ongoing effort at TI India to submit the 
resizer driver to open source for OMAP3? As per the email exchanges I had with 
Vaibhav (TI India) on this, it is part of the ISP module. We plan to submit the 
patches to open source for H3A and was trying to see which is the right way to 
do it. We will investigate the tree you mentioned below and let you know if we 
have additional questions. The plan is to align with OMAP3 for the 
implementation.

regards,

Murali Karicheri
email: m-kariche...@ti.com

-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
Sent: Monday, June 01, 2009 2:39 PM
To: Paulraj, Sandeep; linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; Grosen, Mark
Subject: RE: New Driver for DaVinci DM355/DM365/DM6446

 From: linux-media-ow...@vger.kernel.org [linux-media-
ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep
 Sent: Monday, June 01, 2009 5:56 PM
 To: linux-media@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org; Grosen, Mark
 Subject: New Driver for DaVinci DM355/DM365/DM6446

 Hello,

 WE have a module(H3A) on Davinci DM6446,DM355 and DM365.

 Customers require a way to collect the data required to perform the Auto
Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
opposed to software.  This is primarily for performance reasons as there
is not enough software processing MIPS (to do 3A statistics) available in
 an imaging/video system.

 Including this block in hardware reduces the load on the processor and
bandwidth to the memory as the data is collected on the fly from the imager.

 This modules collects statistics and we currently implement it as a
character driver.

This also exists in OMAP3 chips, and is part of the ISP module.

I maintain, along with Sakari Ailus, a V4L2 camera driver, which is
currently just shared through a gitorious repository:

http://gitorious.org/omap3camera

The way we offer an interface for the user to be able to request this
statistics is with the usage of private IOCTLs declared inside the same
V4L2 capturing device driver.

So, that way we have a V4L2 driver which has a private call, instead of
having it separately from the capture driver.

Regards,
Sergio

 Which mailing list would be the most appropriate mailing list to submit
patches for review?

 Thanks,
 Sandeep
 --
 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

--
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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 1 Jun 2009 13:39:17 -0500
Paulraj, Sandeep s-paul...@ti.com escreveu:

   [Sandeep] WE don't propose any API changes. This module for which we  
  want to submit patches is a TI proprietary IP. We currently implement this
  as a character device and have a few IOCTL's.  
   We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.
  
   Can we continue to use it as a character driver?  
  
  In this case, I don't see why you want it to be upstream.  
 [Sandeep] TI customers and TI itself want to see this driver part of open 
 source trees. Considering this we would like to submit our patches to the 
 linux-media mailing list.
 IS this OK?

If you're just providing a character API with some protocol protected by IP,
you're not providing the source code of the driver, but something else. 

It is not ok to provide such driver. 

Also, even if you disclosure your protocol, it makes no sense to create another
API for userspace communication, for features that already exists or can easily
expand to accommodate your needs. 

So, you should really use the V4L2 API for the driver, expanding it where
required, if you want it to be considered for upstream addition.



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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 1 Jun 2009 13:38:37 -0500
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com escreveu:

  From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] 
  On Behalf Of Paulraj, Sandeep
  Sent: Monday, June 01, 2009 5:56 PM
  To: linux-media@vger.kernel.org
  Cc: linux-ker...@vger.kernel.org; Grosen, Mark
  Subject: New Driver for DaVinci DM355/DM365/DM6446
  
  Hello,
  
  WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
  
  Customers require a way to collect the data required to perform the Auto 
  Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as 
  opposed to software.  This is primarily for performance reasons as there 
  is not enough software processing MIPS (to do 3A statistics) available in
  an imaging/video system.
  
  Including this block in hardware reduces the load on the processor and 
  bandwidth to the memory as the data is collected on the fly from the imager.
  
  This modules collects statistics and we currently implement it as a 
  character driver.
 
 This also exists in OMAP3 chips, and is part of the ISP module.
 
 I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently 
 just shared through a gitorious repository:
 
 http://gitorious.org/omap3camera
 
 The way we offer an interface for the user to be able to request this 
 statistics is with the usage of private IOCTLs declared inside the same V4L2 
 capturing device driver.
 
 So, that way we have a V4L2 driver which has a private call, instead of 
 having it separately from the capture driver.

This seems to be a much better approach, provided that the private IOCTL's will
be properly documented on a public document. If there are enough usage for
they, we may even add them as an optional part of V4L2 API.



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: New Driver for DaVinci DM355/DM365/DM6446

2009-06-01 Thread Aguirre Rodriguez, Sergio Alberto
 From: Karicheri, Muralidharan
 Sent: Monday, June 01, 2009 9:58 PM
 To: Aguirre Rodriguez, Sergio Alberto; Paulraj, Sandeep; 
 linux-media@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org; Grosen, Mark
 Subject: RE: New Driver for DaVinci DM355/DM365/DM6446
 
 Sergio,
 
 Is it part of the patches Vaibhav  others from TI are submitting to open 
 source ?

Yes, currently I have been sharing this codebase with Vaibhav, which he is 
taking for the 3530 EVM, which uses the camera ISP to receive images from a 
video decoder using a parallel BT656 output.


 I know that there is an
 ongoing effort at TI India to submit the resizer driver to open source for 
 OMAP3?

I guess this is still on hold, as the current internal approach is not 
acceptable in the V4L2 standards.

 As per the email
 exchanges I had with Vaibhav (TI India) on this, it is part of the ISP module.

That's correct.

 We plan to submit the
 patches to open source for H3A and was trying to see which is the right way 
 to do it.

The ISP driver core that we are sharing, it already has the H3A driver on it, 
which is accessed through Private IOCTLs declared inside the driver.

 We will
 investigate the tree you mentioned below and let you know if we have 
 additional questions.

Vaibhav should be already familiar with this codebase, so maybe it could be 
easier for you to talk with him about this.

 The plan is to align with OMAP3 for the implementation.

Although the current code maintenance is on hold because i've been busy with 
some other custormer requirements, i havent been able to continue working on 
the pending TODOs so far. But as this strategy on a better collaboration with 
the community is attempted, i'm trying ot find my way to get back wit hthe 
maintenance of this driver to meet at least the required changes for acceptance 
of the driver.

It'll be definitively good to align on this, so we can avoid rewriting the same 
thing over again.

Regards,
Sergio
 
 regards,
 
 Murali Karicheri
 email: m-kariche...@ti.com
 
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
Sent: Monday, June 01, 2009 2:39 PM
To: Paulraj, Sandeep; linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; Grosen, Mark
Subject: RE: New Driver for DaVinci DM355/DM365/DM6446

 From: linux-media-ow...@vger.kernel.org [linux-media-
ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep
 Sent: Monday, June 01, 2009 5:56 PM
 To: linux-media@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org; Grosen, Mark
 Subject: New Driver for DaVinci DM355/DM365/DM6446

 Hello,

 WE have a module(H3A) on Davinci DM6446,DM355 and DM365.

 Customers require a way to collect the data required to perform the Auto
Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
opposed to software.  This is primarily for performance reasons as there
is not enough software processing MIPS (to do 3A statistics) available in
 an imaging/video system.

 Including this block in hardware reduces the load on the processor and
bandwidth to the memory as the data is collected on the fly from the imager.

 This modules collects statistics and we currently implement it as a
character driver.

This also exists in OMAP3 chips, and is part of the ISP module.

I maintain, along with Sakari Ailus, a V4L2 camera driver, which is
currently just shared through a gitorious repository:

http://gitorious.org/omap3camera

The way we offer an interface for the user to be able to request this
statistics is with the usage of private IOCTLs declared inside the same
V4L2 capturing device driver.

So, that way we have a V4L2 driver which has a private call, instead of
having it separately from the capture driver.

Regards,
Sergio

 Which mailing list would be the most appropriate mailing list to submit
patches for review?

 Thanks,
 Sandeep
 --
 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

--
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://udev.netup.ru/hg/v4l-dvb-aospan

2009-06-01 Thread Mauro Carvalho Chehab
Em Mon, 01 Jun 2009 17:42:24 +0400
Abylai Ospan aos...@netup.ru escreveu:

 В Пнд, 01/06/2009 в 06:38 -0300, Mauro Carvalho Chehab пишет:
  Please check your patch against kernel codingstyle with checkpatch.pl. There
  are some CodingStyle violations here and on the code bellow.
 Please pull new changes - 
 http://udev.netup.ru/hg/v4l-dvb-aospan/rev/0d3e6c0695cc
 
 1. checkpatch.pl don't show warnings/errors ( except printk line
 length ).
 
 2. cnt_storage array dinamically allocated before doing checks. We can't
 allocate it in dvb_dmx_init routine because module option
 dvb_demux_tscheck  can be enabled on running system ( not in module
 startup only ).
 

Ok, we're close to a final version.

TS continuity check: show error message when discontinuity detected or TEI flag 
detected in header

Signed-off-by: Abylay Ospan aos...@netup.ru

 --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 05:22:37 
 2009 -0300
 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 17:36:33 
 2009 +0400
 @@ -37,6 +37,15 @@
  ** #define DVB_DEMUX_SECTION_LOSS_LOG to monitor payload loss in the syslog
  */
  // #define DVB_DEMUX_SECTION_LOSS_LOG
 +
 +static int dvb_demux_tscheck;
 +module_param(dvb_demux_tscheck, int, 0644);
 +MODULE_PARM_DESC(dvb_demux_tscheck, \
 + enable transport stream continuity and TEI check);

Please remove the backslash on the above line. Just do:

MODULE_PARM_DESC(dvb_demux_tscheck,
enable transport stream continuity and TEI check);


 +
 +#define dprintk_tscheck(x...) do { \
 + if (dvb_demux_tscheck  printk_ratelimit()) printk(x); } while (0)

checkpatch.pl is not perfect. The better is to break the macro as I've shown on
my previous email, breaking one statement per line:

#define dprintk_tscheck(x...) do {  \
if (dvb_demux_tscheck  printk_ratelimit())\
printk(x);  \
} while (0)

This allows a faster reading of the line.

PS.: The defines are the only places at the source code where the backslashes 
are needed.

 +
  
  
 /**
   * static inlined helper functions
 @@ -375,6 +384,29 @@
   struct dvb_demux_feed *feed;
   u16 pid = ts_pid(buf);
   int dvr_done = 0;
 +

No need for an empty line here. Please remove to keep all vars together.

 + int cnt_pid;

unsigned cnt_pid;

 +
 + if (dvb_demux_tscheck) {
 +

No need for an empty line here.

 + if (!demux-cnt_storage)
 + demux-cnt_storage = vmalloc(0x1fff);

Please add a define for 0x1fff and use the define, instead of using a magic 
value at vmalloc, like:

#define MAX_PID 0x1ffe
...
if (!demux-cnt_storage)
demux-cnt_storage = vmalloc(MAX_PID + 1);

You need to add a check to see if the vmalloc really worked.
Also, if you don't have memory for the first packet, it doesn't make sense to
keep insisting on allocating memory. Better just to disable the check. So, I
would code it like:

if (!demux-cnt_storage) {
WARN(Couldn't allocate memory for TS/TEI check. 
Disabling it\n);
dvb_demux_tscheck = 0;
goto no_dvb_demux_tscheck;
}


 +
 + /* check pkt counter */
 + cnt_pid = ((buf[1]  0x1f)8) | buf[2];
 +
 + if (cnt_pid != 0x1fff) {

if (cnt_pid = MAX_PID) {

This will make clear that there's no chance of writing outside the array limit,
after changing cnt_pid to unsigned.

 + if (buf[1]  0x80)
 + dprintk_tscheck(TEI detected. PID=0x%x 
 data1=0x%x\n, cnt_pid, buf[1]);
 +
 + if ((buf[3]  0xf) != demux-cnt_storage[cnt_pid])
 + dprintk_tscheck(TS packet counter mismatch. 
 PID=0x%x expected 0x%x got 0x%x\n,\
 + cnt_pid, 
 demux-cnt_storage[cnt_pid], buf[3]  0xf);

Please, don't add the backslash. Also, in order to have it 80-line compliant, 
you could break the strings as:

dprintk_tscheck(TS packet counter mismatch. 
PID=0x%x expected 0x%x got 
0x%x\n,
cnt_pid, 
demux-cnt_storage[cnt_pid],
buf[3]  0xf);
 +
 + demux-cnt_storage[cnt_pid] = ((buf[3]  0xf) + 1)0xf;
 + };
 + /* end check */
 + };
  

In order to work with the lack of memory, you'll need a label here:

no_dvb_demux_tscheck:

Another alternative would be to convert the debug logic into a static function.
The source code will look cleaner, and the gcc optimizer will tranform it into
inline and produce the same binary. Something like:

if (demux-cnt_storage)
   

Re: Terratec DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset

2009-06-01 Thread Marco Borm

Hi folks.

Sorry but I'm unable to reply to my previous message, because I just 
don't have this message. Now I'm registered to both lists...


I played a little bit with my problem and tried the latest source from 
the repository, but EOVERFLOW still occurs seconds after starting vdr.
I activated the debug options of all, I hope, relevant modules now and 
got a more detailed kern.log.

Maybe some expert can help me and take look at it.
Interesting section:

Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: dmxdev: section callback 4e f2 6c 40 0a e7
Jun  1 23:16:14 vdr kernel: dmxdev: section callback 50 f2 55 40 13 e1
Jun  1 23:16:14 vdr kernel: dmxdev: section callback 00 b0 1d 03 01 d1
Jun  1 23:16:14 vdr kernel: stop pid: 0x00a0, feedtype: 1
Jun  1 23:16:14 vdr kernel: setting pid (no):   160 00a0 at index 7 'off'
Jun  1 23:16:14 vdr kernel: function : dvb_dmxdev_filter_set
Jun  1 23:16:14 vdr kernel: start pid: 0x00e0, feedtype: 1
Jun  1 23:16:14 vdr kernel: setting pid (no):   224 00e0 at index 7 'on'
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
Jun  1 23:16:14 vdr kernel: function : dvb_dvr_poll
BOOM - Jun  1 23:16:14 vdr kernel: urb completition error -75.

The whole logfile is available here:
http://www.retrodesignfan.eu/dvb/dib0700-usb-hangup.log


Greetings,
Marco Borm

Marco Borm wrote:

Hi folks,

yesterday I bought  a Terratec Cinergy DT USB XS Diversity and the 
device works just plugplay and without problems under Windows AND 
linux mplayer+ tzap but resets the whole USB bus very shortly after I 
starting vdr. I don't think this has something to do with vdr itself, 
so I posting here.


My configuration is Debian on testing, kernel is 
2.6.29-4.slh.1-sidux-686, DVB drivers aren't self compiled, vdr is 
(1.6.0-2/1.6.0), device info: ID 0ccd:0081 TerraTec Electronic GmbH.

log entries:
Jun  1 01:14:47 vdr kernel: dib0700: loaded with support for 8 
different device-types
Jun  1 01:14:47 vdr kernel: dvb-usb: found a 'Terratec Cinergy DT USB 
XS Diversity' in warm state.
Jun  1 01:14:47 vdr kernel: dvb-usb: will pass the complete MPEG2 
transport stream to the software demuxer.
Jun  1 01:14:47 vdr kernel: DVB: registering new adapter (Terratec 
Cinergy DT USB XS Diversity)
Jun  1 01:14:47 vdr kernel: DVB: registering adapter 1 frontend 0 
(DiBcom 7000PC)...

Jun  1 01:14:47 vdr kernel: DiB0070: successfully identified
Jun  1 01:14:47 vdr kernel: dvb-usb: will pass the complete MPEG2 
transport stream to the software demuxer.
Jun  1 01:14:47 vdr kernel: DVB: registering new adapter (Terratec 
Cinergy DT USB XS Diversity)
Jun  1 01:14:47 vdr kernel: DVB: registering adapter 2 frontend 0 
(DiBcom 7000PC)...

Jun  1 01:14:47 vdr kernel: DiB0070: successfully identified
Jun  1 01:14:47 vdr kernel: dvb-usb: Terratec Cinergy DT USB XS 
Diversity successfully initialized and connected.
Jun  1 01:14:47 vdr kernel: usbcore: registered new interface driver 
dvb_usb_dib0700
vdr start - Jun  1 01:16:24 vdr logger: runvdr get_modulenames: 
dvb_usb#012videobuf_dvb#012cx88_dvb dvb_core
USB reset - Jun  1 01:18:00 vdr kernel: usb 1-2: USB disconnect, [... 
all devices reconnecting to the bus ]

Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C read failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
Jun  1 01:18:28 vdr kernel: DiB0070 I2C write failed
[...]

This logs aren't very helpful, but I find something interesting with 
Wireshark and usbmon:

device - host
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (3)
Endpoint: 0x83
Device: 13
Data: present (0)
URB status: Value too large for defined data type (-EOVERFLOW) (-75)
URB length [bytes]: 39424
Data length [bytes]: 39424

after this URB I get a URB transfer type: URB_INTERRUPT (1) and all 
goes to hell.


Its also  interesting that the URB+data length in the failure package 
is 39424 but URB length [bytes]: 39480 in every package before that.


As I know this device works without problems under linux for other 
people, so I'm wondering why. I searched but found nothing about such 
a problem.


The wireshark capturefile is downloadable here: 
http://rapidshare.com/files/239429647/terratec-xs-usb-overflow.html



Thanks for hints,
Marco Borm



--
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] Leadtek WinFast DTV-1800H support

2009-06-01 Thread hermann pitton

Am Montag, den 01.06.2009, 06:07 -0300 schrieb Mauro Carvalho Chehab:
 Em Mon, 01 Jun 2009 03:58:25 +0200
 hermann pitton hermann-pit...@arcor.de escreveu:
 
  
  Am Sonntag, den 31.05.2009, 16:58 -0300 schrieb Mauro Carvalho Chehab:
   Em Sun, 31 May 2009 19:39:15 +0200
   Miroslav  Šustek sustmid...@centrum.cz escreveu:
   
Trent Piepho xyzzy at speakeasy.org writes:

 Instead of raising the reset line here, why not change the gpio 
 settings in
 the card definition to have it high? Change gpio1 for television to 
 0x7050
 and radio to 0x7010.
Personally, I don't know when these .gpioX members are used (before
firmware loads or after...).
But I assume that adding the high on reset pin shouldn't break anything,
so we can do this.

And shouldn't we put tuner reset pin to 0 when in composite and s-video 
mode?
These inputs don't use tuner or do they?
If I look in dmesg I can see that firmware is loaded into tuner even
when these modes are used (I'm using MPlayer to select the input).
And due to callbacks issued duting firmware loading, tuner is turned on
(reset pin = 1) no matter if it was turned off by .gpioX setting.

And shouldn't we use the mask bits [24:16] of MO_GPX_IO
in .gpioX members too? I know only few GPIO pins and the other I don't
know either what direction they should be. That means GPIO pins which
I don't know are set as Hi-Z = inputs... Now, when I think of that,
if it works it's safer when the other pins are in Hi-Z mode. Never mind.


 Then the reset can be done with:

 case XC2028_TUNER_RESET:
 /* GPIO 12 (xc3028 tuner reset) */
 cx_write(MO_GP1_IO, 0x101000);
 mdelay(50);
 cx_write(MO_GP1_IO, 0x101010);
 mdelay(50);
 return 0;

Earlier I was told to use 'cx_set' and 'cx_clear' because using 
'cx_write'
is risky.
see here: http://www.spinics.net/lists/linux-dvb/msg29777.html
And when you are using 'cx_set' and 'cx_clear' you need 3 calls.
The first to set the direction bit, the second to set 0 on reset pin
and the third to set 1 on reset pin.
If you ask me which I think is nicer I'll tell you: that one with 
'cx_write'.
If you ask me which one I want to use, I'll tell: I don't care. :)

 Though I have to wonder why each card needs its own xc2028 reset 
 function.
 Shouldn't they all be the same other than what gpio they change?
My English goes lame here. Do you mean that reset function shouldn't use
GPIO at all?


 @@ -2882,6 +2946,16 @@
 cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */
 udelay(1000);
 break;
 +
 + case CX88_BOARD_WINFAST_DTV1800H:
 + /* GPIO 12 (xc3028 tuner reset) */
 + cx_set(MO_GP1_IO, 0x1010);
 + mdelay(50);
 + cx_clear(MO_GP1_IO, 0x10);
 + mdelay(50);
 + cx_set(MO_GP1_IO, 0x10);
 + mdelay(50);
 + break;
 }
 }

 Couldn't you replace this with:

 case CX88_BOARD_WINFAST_DTV1800H:
 cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0);
 break;
Yes, this will do the same job.
I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C
communication. The 'cx88_xc3028_winfast1800h_callback' 
(cx88_tuner_callback)
is meant to be used when tuner code (during firmware loading) needs it.
This is probably why others did it this way (these are separated issues
even if they do the same thing) and I only obey existing form.

I only want to finally add the support for this card.
You know many people (not developers) don't care if this function is 
used
or that function is used twice, instead. They just want to install 
they distro
and watch the tv.
I classify myself as an programmer rather than ordinary user, so I care 
how
the code looks like. I'm open to the discussion about these things, but
this can take long time and I just want the card to be supported asap.
There are more cards which has code like this so if linuxtv developers 
realize
eg. to not use callbacks or use only cx_set and cx_clear (instead of 
cx_write)
they'll do it all at once (not every card separately).

I attached modified patch:
- .gpioX members of inputs which use tuner have reset pin 1 (tuner 
enabled)
- .gpioX members of inputs which don't use tuner have reset pin 0 
(tuner disabled)
- resets (in callback and the one in pre_i2c) use only two 'cx_write' 
calls

I'm keeping the tested-by lines even if this modified version of 
patch wasn't
tested by those people (the previous version was). I trust this changes 
can't
break the functionality.
If you think it's too audacious then drop them.

It's on linuxtv developers which of these two patches will be chosen.
   
   For the sake of not loosing this patch again, I've 

Re: Wiki software update

2009-06-01 Thread hermann pitton
Hi Johannes,

Am Montag, den 01.06.2009, 13:41 +0200 schrieb Johannes Stezenbach:
 Hi Hermann,
 
 On Mon, Jun 01, 2009 at 02:08:07AM +0200, hermann pitton wrote:
  Am Montag, den 01.06.2009, 01:28 +0200 schrieb Johannes Stezenbach:
   
   I just updated the V4L-DVB Wiki and the old V4L Wiki
   to MediaWiki-1.14.0. Please let me know in case
   something broke.
  
  did not test all links, but on this one some older issues seem to still
  perpetuate.
  
  http://www.linuxtv.org/wiki/index.php?title=How_to_Perform_a_Bisectaction=edit
  
  I get, that I'm not allowed to do that.
 
 Well, you need to be logged in to create or edit pages. Or are
 you saying that you cannot edit this page even though you are logged in?
 
 
 Johannes

sorry, my bad.

Thought it means also a site on the wiki,
but it obviously only tries to provide the external link.

Thanks,
Hermann


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


Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

2009-06-01 Thread Andreas Oberritter
Hi,

I missed the original mail, so I am replying to this one. See below.

 @@ -375,6 +384,29 @@
  struct dvb_demux_feed *feed;
  u16 pid = ts_pid(buf);
  int dvr_done = 0;
 +
 
 No need for an empty line here. Please remove to keep all vars together.
 
 +int cnt_pid;
 
 unsigned cnt_pid;
 

There's no need for cnt_pid at all, because pid already contains
the PID value.

 Please add a define for 0x1fff and use the define, instead of using a magic 
 value at vmalloc, like:
 
 #define MAX_PID   0x1ffe

One would assume MAX_PID to be 0x1fff. Maybe it would be better to
have two definitions to improve readability.

for dvb_dmx_swfilter_packet():
#define NULL_PID 0x1fff

for vmalloc:
#define MAX_PID 0x1fff
or
#define NUM_PIDS 0x2000
... and use (NUM_PIDS - 1) to make clear that no memory for the NULL
PID is allocated.

Regards,
Andreas
--
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: webcam drivers and V4L2_MEMORY_USERPTR support

2009-06-01 Thread Laurent Pinchart
Hi Stefan,

On Monday 01 June 2009 09:26:10 Stefan Kost wrote:
 hi,

 I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers
 v4l2src [1]. This allows to request shared memory buffers from xvideo,
 capture into those and therefore save a memcpy. This works great with
 the v4l2 driver on our embedded device.

 When I was testing this on my desktop, I noticed that almost no driver
 seems to support it.
 I tested zc0301 and uvcvideo, but also grepped the kernel driver
 sources. It seems that gspca might support it, but I ave not confirmed
 it. Is there a technical reason for it, or is it simply not implemented?

For the uvcvideo driver it's simply not implemented. I was about to give it a 
try when I found out a mismatch between the V4L2 specification and the 
videobuf implementation (which I wanted to use as the reference 
implementation).

The V4L2 specification states, in section 3.3, that

The driver must be switched into user pointer I/O mode by calling the 
VIDIOC_REQBUFS with the desired buffer type. No buffers are allocated 
beforehands, consequently they are not indexed and cannot be queried like 
mapped buffers with the VIDIOC_QUERYBUF ioctl.

Example 3-2 shows that v4l2_requestbuffers::count is not used when using 
USERPTR.

However, videobuf pre-allocates v4l2_requestbuffers::count kernel-side buffer 
descriptors when VIDIOC_REQBUFS is called with USERPTR.

If someone could clarify which of the V4L2 specification or the videobuf 
implementation is right I could give USERPTR a try in the uvcvideo driver.

Best regards,

Laurent Pinchart

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


Re: [hg:v4l-dvb] Fix firmware load for DVB-T @ 6MHz

2009-06-01 Thread Andy Walls
On Mon, 2009-06-01 at 17:20 +0200, Patch from Mauro Carvalho Chehab
wrote:
 The patch number 11917 was added via Mauro Carvalho Chehab 
 mche...@redhat.com
 to http://linuxtv.org/hg/v4l-dvb master development tree.
 
 Kernel patches in this development tree may be modified to be backward
 compatible with older kernels. Compatibility modifications will be
 removed before inclusion into the mainstream Kernel
 
 If anyone has any objections, please let us know by sending a message to:
   Linux Media Mailing List linux-media@vger.kernel.org
 
 --
 
 From: Mauro Carvalho Chehab  mche...@redhat.com
 Fix firmware load for DVB-T @ 6MHz
 
 
 bandwidth for xc3028/xc3028L
 
 
 The only two countries that are known to use 6MHz bandwidth are Taiwan
 and Uruguay. Both use QAM subcarriers at OFTM.
 
 This patch fixes the firmware load for such countries, where the
 required firmware is the QAM one.
 
 This also confirms the previous tests where it was noticed that the 6MHz
 QAM firmware doesn't work for cable. So, this patch also removes support
 for DVB-C, instead of just printing a warning.
 
 Thanks to Terry Wu terrywu2...@gmail.com for pointing this issue and
 to Andy Walls awa...@radix.net for an initial patch for this fix.
 
 Priority: normal
 
 CC: Terry Wu terrywu2...@gmail.com
 CC: Andy Walls awa...@radix.net
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 

Acked-by: Andy Walls awa...@radix.net

I looks like it accomplishes the 6 MHz DVB-T support in
xc2028_set_params() that Terry needed.  I personally wouldn't have
disabled the FE_QAM stuff.  However it doesn't matter as far as current
Linux driver use of the XC3028 is concerned - no driver currently sets
up the XC3028 with a DVB-C demod.

Regards,
Andy

 ---
 
  linux/drivers/media/common/tuners/tuner-xc2028.c |   17 +++
  1 file changed, 8 insertions(+), 9 deletions(-)
 
 diff -r d55ec37bebfa -r c78c18fe3dc9 
 linux/drivers/media/common/tuners/tuner-xc2028.c
 --- a/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 
 05:22:37 2009 -0300
 +++ b/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 
 11:46:08 2009 -0300
 @@ -1026,21 +1026,20 @@ static int xc2028_set_params(struct dvb_
   switch(fe-ops.info.type) {
   case FE_OFDM:
   bw = p-u.ofdm.bandwidth;
 - break;
 - case FE_QAM:
 - tuner_info(WARN: There are some reports that 
 -QAM 6 MHz doesn't work.\n
 -If this works for you, please report by 
 -e-mail to: v4l-dvb-maintai...@linuxtv.org\n);
 - bw = BANDWIDTH_6_MHZ;
 - type |= QAM;
 + /*
 +  * The only countries with 6MHz seem to be Taiwan/Uruguay.
 +  * Both seem to require QAM firmware for OFDM decoding
 +  * Tested in Taiwan by Terry Wu terrywu2...@gmail.com
 +  */
 + if (bw == BANDWIDTH_6_MHZ)
 + type |= QAM;
   break;
   case FE_ATSC:
   bw = BANDWIDTH_6_MHZ;
   /* The only ATSC firmware (at least on v2.7) is D2633 */
   type |= ATSC | D2633;
   break;
 - /* DVB-S is not supported */
 + /* DVB-S and pure QAM (FE_QAM) are not supported */
   default:
   return -EINVAL;
   }
 
 
 ---
 
 Patch is available at: 
 http://linuxtv.org/hg/v4l-dvb/rev/c78c18fe3dc9f1338a589130c4eeed14c1d90b44
 

--
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: [hg:v4l-dvb] tuner-xc2028: Fix offset frequencies for DVB @ 6MHz

2009-06-01 Thread Andy Walls
On Mon, 2009-06-01 at 17:20 +0200, Patch from Mauro Carvalho Chehab
wrote:
 The patch number 11918 was added via Mauro Carvalho Chehab 
 mche...@redhat.com
 to http://linuxtv.org/hg/v4l-dvb master development tree.
 
 Kernel patches in this development tree may be modified to be backward
 compatible with older kernels. Compatibility modifications will be
 removed before inclusion into the mainstream Kernel
 
 If anyone has any objections, please let us know by sending a message to:
   Linux Media Mailing List linux-media@vger.kernel.org
 
 --
 
 From: Mauro Carvalho Chehab  mche...@redhat.com
 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz
 
 
 Both ATSC and DVB @ 6MHz bandwidth require the same offset.
 
 While we're fixing it, let's cleanup the bandwidth setup to better
 reflect the fact that it is a function of the bandwidth.
 
 Thanks to Terry Wu terrywu2...@gmail.com for pointing this issue and
 to Andy Walls awa...@radix.net for an initial patch for this fix.
 
 Priority: normal
 
 CC: Terry Wu terrywu2...@gmail.com
 CC: Andy Walls awa...@radix.net
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

Acked-by: Andy Walls awa...@radix.net

You may want to emphasize with a comment that 'offset = 0' is used for
T_ANALOG_TV.  It's somewhat hidden by its initialization early in the
function.

Italy also appears to use 7 MHz VHF and 8 MHz UHF.

Regards,
Andy

 ---
 
  linux/drivers/media/common/tuners/tuner-xc2028.c |   32 ---
  1 file changed, 19 insertions(+), 13 deletions(-)
 
 diff -r c78c18fe3dc9 -r e6a8672631a0 
 linux/drivers/media/common/tuners/tuner-xc2028.c
 --- a/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 
 11:46:08 2009 -0300
 +++ b/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 
 12:18:10 2009 -0300
 @@ -921,22 +921,28 @@ static int generic_set_freq(struct dvb_f
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV) {
 + if (new_mode == T_ANALOG_TV)
   rc = send_seq(priv, {0x00, 0x00});
 - } else if (priv-cur_fw.type  ATSC) {
 - offset = 175;
 - } else {
 - offset = 275;
 +
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency
 +  */
 + if (new_mode != T_ANALOG_TV) {
 + /* Sets the offset according with firmware */
 + if (priv-cur_fw.type  DTV6)
 + offset = 175;
 + if (priv-cur_fw.type  DTV7)
 + offset = 225;
 + else/* DTV8 or DTV78 */
 + offset = 275;
 +
   /*
 -  * We must adjust the offset by 500kHz in two cases in order
 -  * to correctly center the IF output:
 -  * 1) When the ZARLINK456 or DIBCOM52 tables were explicitly
 -  *selected and a 7MHz channel is tuned;
 -  * 2) When tuning a VHF channel with DTV78 firmware.
 +  * We must adjust the offset by 500kHz  when
 +  * tuning a 7MHz VHF channel with DTV78 firmware
 +  * (used in Australia)
*/
 - if (((priv-cur_fw.type  DTV7) 
 -  (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 - ((priv-cur_fw.type  DTV78)  freq  47000))
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
   offset -= 50;
   }
  
 
 
 ---
 
 Patch is available at: 
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0f5f549f5ee5db3acac4f35013942
 

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


Re: [PATCH 3/9] dm355 ccdc module for vpfe capture driver

2009-06-01 Thread Kevin Hilman
Karicheri, Muralidharan m-kariche...@ti.com writes:

 Laurent,

 Thanks for reviewing this. I have not gone through all of your comments, but 
 would like to respond to the following one first. I will respond to the rest 
 as I do the rework.

I've had a quick look at the DM355 and DM6446 datasheets. The CCDC and VPSS
registers share the same memory block. Can't you use a single resource ?

One nice (and better in my opinion) solution would be to declare a
structure
with all the VPSS/CCDC registers as they are implemented in hardware and
access the structure fields with __raw_read/write*. You would then store a
single pointer only. Check arch/powerpc/include/asm/immap_cpm2.h for an
example.

 I think, a better solution will be to move the vpss system module
 part to the board specific file dm355.c or dm6446.c 

Just to clarify, the files you mention are SoC specific files, not
board-specific files...

 and export functions to configure them as needed by the different
 drivers.

My first reaction to this is... no.  I'm reluctant to have a bunch of
driver specific hooks in the core davinci SoC specific code.  I'd much
rather see this stuff kept along with the driver in drivers/media/*
and abstracted as necessary there.

 The vpss has evolved quite a lot from DM6446 to DM355 to
 DM365. Registers such as INTSEL and INTSTAT and others are
 applicable to other modules as well, not just the ccdc module. The
 VPBE and resizer drivers will need to configure them too. Also the
 vpss system module features available in DM365 is much more than
 that in DM355. 

Based on this, it sounds to me that this driver needs to be broken up
a little bit more and some of the shared pieces need to be abstracted
out so they can be shared among the modules.

 Interrupts line to ARM are programmable in DM365 vpss and multiple
 vpss irq lines can be muxed to the ARM side. So I would imaging
 functions enable/disable irq line to arm, clearing irq bits,
 enabling various clocks etc can be done in a specific soc specific
 file (dm355.c, dm365.c or dm6446.c) and can be exported for use in
 specific drivers. I just want to get your feedback so that I can
 make this change. With this change, there is no need to use
 structures for holding register offsets as you have suggested.

Kevin

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