Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner

[Hans Verkuil]

On Sunday 14 February 2010 23:10:48 Andy Walls wrote:
> On Sun, 2010-02-14 at 16:18 +0100, Hans Verkuil wrote:
> > On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote:
> > > On Friday 12 February 2010 23:36:20 Pete Eberlein wrote:
> > > > On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote:
> > > > > > > > +#include 
> > > > > > > 
> > > > > > > The v4l2-i2c-drv.h is to be used only for drivers that also need 
> > > > > > > to be compiled
> > > > > > > for kernels < 2.6.26. If I am not mistaken that is the case for 
> > > > > > > this driver,
> > > > > > > right? I remember you mentioning that customers of yours use this 
> > > > > > > on such old
> > > > > > > kernels. Just making sure.
> > > > > > 
> > > > > > My company, Sensoray, doesn't have any products that use this tuner.
> > > > > > This driver was orignally written by Micronas to support their 
> > > > > > go7007
> > > > > > chip in the Plextor TV402U models.  I don't have the datasheet or 
> > > > > > know
> > > > > > much about tuners anyway.  I used the v4l2-i2c-drv.h since it seems 
> > > > > > like
> > > > > > a good idea at the time.  What should I use instead?
> > > > > 
> > > > > We way i2c devices are handled changed massively in kernel 2.6.26. In 
> > > > > order to
> > > > > stay backwards compatible with older kernels the v4l2-i2c-drv.h 
> > > > > header was
> > > > > introduced. However, this is a bit of a hack and any i2c driver that 
> > > > > does not
> > > > > need it shouldn't use it.
> > > > > 
> > > > > So only if an i2c driver is *never* used by parent drivers that have 
> > > > > to support
> > > > > kernels < 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of 
> > > > > such an
> > > > > i2c driver is tvp514x.c.
> > > > > 
> > > > > Eventually support for such old kernels will be dropped and the 
> > > > > v4l2-i2c-drv.h
> > > > > header will disappear altogether, but that's not going to happen 
> > > > > anytime soon.
> > > > > 
> > > > > What this means for go7007 is that you have to decide whether you 
> > > > > want this
> > > > > go7007 driver to work only for kernels >= 2.6.26, or whether it 
> > > > > should also
> > > > > work for older kernels. My understanding is that Sensoray wants to be 
> > > > > able to
> > > > > compile go7007 for older kernels. In that case the use of 
> > > > > v4l2-i2c-drv.h is
> > > > > correct. Note that this is not about whether any of *Sensoray's* 
> > > > > products use
> > > > > a particular i2c device, but whether the *go7007* driver uses it.
> > > > > 
> > > > > I hope this clarifies this.
> > > > 
> > > > Yes it does, thank you.  We do want to allow our customers to use the
> > > > go7007 driver with our products on older kernels, so I would like to
> > > > keep the v4l2-i2c-drv.h for now.  I've addressed your other comments in
> > > > the revised patch:
> > > 
> > > I've two small comments. See below.
> > > 
> > > I also realized that this is really two drivers in one: one driver for the
> > > actual tuner device and one for the mpx device which seems similar in
> > > functionality to the vp27smpx.c driver.
> > > 
> > > I will look at it again tomorrow, but I might decide that it is better to
> > > split it up into two drivers: one for the tuner and one for the mpx.
> > 
> > After thinking about this a bit more I decided that this tuner should be 
> > split
> > up into two drivers: one for the mpx device and one for the actual tuner. 
> > This
> > should be fairly easy to do.
> > 
> > One other thing that this accomplishes is that it is easier to see whether 
> > the
> > tuner code can actually be merged into tuner-types.c. From what I can see 
> > now
> > I would say that that is possible for the NTSC_M and NTSC_M_JP models. The
> > PAL/SECAM model is harder since it needs to setup the tuner whenever the
> > standard changes. But it seems that that is also possible by adding code
> > to simple_std_setup() in tuner-simple.c.
> > 
> > I'm pretty sure that these tuners can just be folded into tuner-types.c
> > and tuner-simple.c. We probably only need an mpx driver.
> > 
> > Andy, can you also take a look?
> 
> Sure.  It looks like to me you actually have three chips:
> 
> - oscillator/mixer (at address 0x60 like a TUA6030)
> - programmable IF PLL demodulator (at address 0x43 like a TDA9887)
> - MPX demodulator/dematrix IC.

I've been focusing so much on the IF_I2C_ADDR and MPX_I2C_ADDR defines that
I completely missed the fact that there is also the tuner at 0x60 :-(

You are completely correct: it looks very much like a standard simple
tuner + tda9887.

> 
> 
> The mizer oscillator part programming *really looks like* a TUA6030 or
> equivalent chip being programmed. The charge pump bit is left in a high
> current state, BTW,  meaning fast tuning, but probably more phase noise
> when tuned.
> 
> The IF part programming in this driver *really looks like* a TDA9887
> being programmed.  I have not verified the bits being set against the
> various TV system audio standa

Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

[hermann pitton]

Am Donnerstag, den 11.02.2010, 01:58 +0100 schrieb hermann pitton:
> Hi,
> 
> Am Mittwoch, den 10.02.2010, 20:36 +0100 schrieb Jean Delvare:
> > On Wed, 10 Feb 2010 16:40:03 -0200, Mauro Carvalho Chehab wrote:
> > > Jean Delvare wrote:
> > > > Under the assumption that saa7134_hwinit1() only touches GPIOs
> > > > connected to IR receivers (and it certainly looks like this to me) I
> > > > fail to see how these pins not being initialized could have any effect
> > > > on non-IR code.
> > > 
> > > Now, i suspect that you're messing things again: are you referring to 
> > > saa7134_hwinit1() or
> > > to saa7134_input_init1()?
> > > 
> > > I suspect that you're talking about moving saa7134_input_init1(), since 
> > > saa7134_hwinit1()
> > > has the muted and spinlock inits. It also has the setups for video, vbi 
> > > and mpeg. 
> > > So, moving it require more care.
> > 
> > Err, you're right, I meant saa7134_input_init1() and not
> > saa7134_hwinit1(), copy-and-paste error. Sorry for adding more
> > confusion where it really wasn't needed...
> > 
> 
> both attempts of Jean will work.
> 
> If we are only talking about moving input_init, only that Jean did
> suggest initially, it should work, since only some GPIOs for enabling
> remote chips are affected.
> 
> I can give the crappy tester, but don't have such a remote, but should
> not be a problem to trigger the GPIOs later.
> 
> Cheers,
> Hermann
> 

Hi Jean,

I did test your patch, only following Roman's initial patch already
known, on eight different cards for now, also with three slightly
different remotes and it does not have any negative impact.

Please consider, that it is only about that single card for now and a
per card solution is enough.

I strongly remind, that we should not rely on unknown eeprom bytes, as
told previously and should not expand such into any direction.

If we make progress there, we should change it for all cards, but again,
what had happened on the m$ drivers previously is not encouraging to do
it without any need.

To do it per card in need for now seems enough "service" to me.

If more such should come, unlikely on that driver, I would at first deny
auto detection support, since they are breaking rules.

The problem likely will time out very soon.

Cheers,
Hermann




 





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

[PATCH] dvb: fix sparse warnings

[Randy Dunlap]

From: Randy Dunlap 

Fix sparse warnings in media/dvb/frontends:

drivers/media/dvb/frontends/dibx000_common.c:177:13: warning: non-ANSI function 
declaration of function 'systime'
drivers/media/dvb/frontends/dib0090.c:286:13: warning: function 
'dib0090_dcc_freq' with external linkage has definition
drivers/media/dvb/frontends/tda665x.c:136:55: warning: right shift by bigger 
than source value

Signed-off-by: Randy Dunlap 
---
 drivers/media/dvb/frontends/dib0090.c|2 +-
 drivers/media/dvb/frontends/dibx000_common.c |2 +-
 drivers/media/dvb/frontends/tda665x.c|2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.33-rc8.orig/drivers/media/dvb/frontends/dib0090.c
+++ linux-2.6.33-rc8/drivers/media/dvb/frontends/dib0090.c
@@ -283,7 +283,7 @@ static int dib0090_sleep(struct dvb_fron
return 0;
 }
 
-extern void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast)
+void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast)
 {
struct dib0090_state *state = fe->tuner_priv;
if (fast)
--- linux-2.6.33-rc8.orig/drivers/media/dvb/frontends/dibx000_common.c
+++ linux-2.6.33-rc8/drivers/media/dvb/frontends/dibx000_common.c
@@ -174,7 +174,7 @@ void dibx000_exit_i2c_master(struct dibx
 EXPORT_SYMBOL(dibx000_exit_i2c_master);
 
 
-u32 systime()
+u32 systime(void)
 {
 struct timespec t;
 
--- linux-2.6.33-rc8.orig/drivers/media/dvb/frontends/tda665x.c
+++ linux-2.6.33-rc8/drivers/media/dvb/frontends/tda665x.c
@@ -133,7 +133,7 @@ static int tda665x_set_state(struct dvb_
frequency += config->ref_divider >> 1;
frequency /= config->ref_divider;
 
-   buf[0] = (u8) (frequency & 0x7f00) >> 8;
+   buf[0] = (u8) ((frequency & 0x7f00) >> 8);
buf[1] = (u8) (frequency & 0x00ff) >> 0;
buf[2] = 0x80 | 0x40 | 0x02;
buf[3] = 0x00;
---
~Randy
--
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

KWorld DVB-T 305U now working

[Dean]

My dmesg gave the following (excerpt) when I connected my KWorld 305U.

em28xx #0: Identified as KWorld DVB-T 305U (card=47)
em28xx #0: 

em28xx #0: The support for this board weren't valid yet.
em28xx #0: Please send a report of having this working
em28xx #0: not to V4L mailing list (and/or to other addresses)

So here I am, making this announcement.  Do I even have the correct mailing 
list?  What is the next step towards re-classifying the KWorld 305U as a 
supported device?

Regards.
--
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: Proposal for a V4L2 Media Controller mini-summit

[Laurent Pinchart]

Hi Hans,

On Friday 12 February 2010 15:50:08 Hans Verkuil wrote:
> Hi all,
> 
> During the Linux Plumbers Conference in September 2009 I organized a
> V4L-DVB mini-summit. The focus of that summit was on discussing a
> framework through which we could support all the functionality that the
> video hardware of modern embedded devices provides.
> 
> It was a very successful summit and a lot of work has been done since that
> time. See this posting for to get an idea of what was discussed for those
> who were not present:
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg10136.html
> 
> Since that time we have added a new API to support HDTV formats, a new
> event API is almost ready, a lot of work is being done on the media
> controller API with omap3 as guinea pig and Samsung has done work on the
> memory handling of V4L2.
> 
> From April 12th to 14th the CELF Embedded Linux Conference is held in
> San Francisco, and it is co-located with the Linux Foundation Collaboration
> Summit (April 14th-16th). Links to these conferences are here:
> 
> http://www.embeddedlinuxconference.com/elc_2010/index.html
> http://events.linuxfoundation.org/events/collaboration-summit
> 
> I will be doing a presentation on the new framework during the ELC.
> 
> Since this conference is about 6 months after the mini-summit I consider
> this a good time to organize a new V4L2 Media Controller mini-summit to
> discuss progress and future work in this area. I think that particular
> attention should be given to how we are going to do memory handling. The
> proposals from Samsung have received very little attention and we should
> discuss those in more detail.
> 
> I do not know on which dates exactly such a summit can take place. There
> are three possibilities:
> 
> April 10-11/12
> April 12-14
> April 14/15-16
> 
> I think that registering for the ELC gives to free access to the
> Collaboration Summit, but I'm waiting for a confirmation on that.
> 
> I'm not keen on the center option (12-14 April) since that often means that
> you don't see a lot of the conference itself. And the ELC is generally
> quite interesting.
> 
> There is another alternative and that is that I organize a mini-summit in
> May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I
> think that it is more fun to do this during/before/after a conference. If
> only because there are a lot of linux kernel experts on hand during such a
> conference that you can ask for help if needed.
> 
> Please let me know asap if you are interested in attending such a
> mini-summit and what dates are possible for you:
> 
> a: April 10-11 (or 12)
> b: April 12-14
> c: April 14 (or 15)-16
> d: Somewhere in May (suggestions for dates are welcome)

I'm not keen on the B option either. C is definitely impossible for me, 
leaving only A and D. My preference currently goes for D as I'm not sure yet 
if I will be able to attend the ELC. I should have more information in the 
next few days.

-- 
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: videobuf and streaming I/O questions

[Laurent Pinchart]

Hi Hans,

On Sunday 14 February 2010 15:26:09 Hans Verkuil wrote:
> On Sunday 14 February 2010 14:41:29 Mauro Carvalho Chehab wrote:
> > Hans Verkuil wrote:
> > > Hi all,
> > > 
> > > I've been investigating some problems with my qv4l2 utility and I
> > > encountered some inconsistencies in the streaming I/O documentation
> > > and the videobuf implementation.
> > > 
> > > I would like to know which is correct.

[snip]

> > > 2) The VIDIOC_REQBUFS documentation states that it should be possible
> > > to use a count of 0, in which case it should do an implicit STREAMOFF.
> > > This is currently not implemented. I have included a patch for this
> > > below and if there are no issues with it, then I'll make a pull
> > > request for this.
> > 
> > This can eventually break some application. I think it is safer to fix
> > the specs.
> 
> I don't really see how this would break an application and I think that
> some drivers that do not use videobuf already support this. The reason why
> I think this is a good idea to support it is that this makes it very easy
> to check which streaming mode is supported without actually allocating
> anything.
> 
> I was actually using this in qv4l2 with uvc until I tried it with the mxb
> driver and discovered that videobuf didn't support it. I am definitely in
> favor of fixing the code instead of the spec in this case.

Using a count of 0 to free buffers definitely needs to be supported, so 
videobuf must be fixed. However, I don't think VIDIOC_REQBUFS should issue an 
implicit VIDIOC_STREAMOFF. It should instead return -EBUSY if streaming is in 
progress, or if buffers are still mapped in the userspace memory space.

Performing implicit actions make drivers more complex and error prone. I don't 
see any harm in requiring userspace to call VIDIOC_STREAMOFF before freeing 
buffers.

-- 
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: zr364xx: Aiptek DV8800 (neo): 08ca:2062: Fails on subsequent zr364xx_open()

[Antoine Jacquet]

Hi,

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


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


Yes, this was an off-list discussion, available here:
http://royale.zerezo.com/forum/viewtopic.php?t=355

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


Just checked and the differences in the zr364xx driver are minor.
Would be better if you could work on LinuxTV hg/git tree so we have the 
same basis for patches.


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

cannot see the sequence point.


Ok this is a bit hardcore but nice if it works.
What do you mean by "until the last 2 open()"?
Also, you may want to try with simpler tools like "dd" to do only one 
clean open/close.
Ekiga/Cheese/Skype tend to do many open/close and this may not be the 
ideal tools for debugging, but great to trigger the bugs ;-)



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


I think it's -EINVAL.

2. Picture with (640->320) lines alignment error with ekiga+cheese 
*attached*, wether cam is configured internally for 640x480 or 320x240, 
not affecting.
setting the driver to mode=2 fails with libv4l jpeg decoding errors. I 
try to correct this.


Do you know if the Windows driver support this mode?
If so, it would be helpful to have the snoop too.

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


Ok that's bad, let me know if you find the issue.

Regards,

Antoine


--
Antoine "Royale" Jacquet
http://royale.zerezo.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: Lost remote after kernel/v4l update cx23885 chipset

[Mark Zimmerman]

Greetings:

I found this 
in the archives and I am having the exact same problem. Everything
worked in 2.6.31. Let me know if there is any testing I could do to
help solve this.

-- Mark

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

Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner

[Andy Walls]

On Sun, 2010-02-14 at 16:18 +0100, Hans Verkuil wrote:
> On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote:
> > On Friday 12 February 2010 23:36:20 Pete Eberlein wrote:
> > > On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote:
> > > > > > > +#include 
> > > > > > 
> > > > > > The v4l2-i2c-drv.h is to be used only for drivers that also need to 
> > > > > > be compiled
> > > > > > for kernels < 2.6.26. If I am not mistaken that is the case for 
> > > > > > this driver,
> > > > > > right? I remember you mentioning that customers of yours use this 
> > > > > > on such old
> > > > > > kernels. Just making sure.
> > > > > 
> > > > > My company, Sensoray, doesn't have any products that use this tuner.
> > > > > This driver was orignally written by Micronas to support their go7007
> > > > > chip in the Plextor TV402U models.  I don't have the datasheet or know
> > > > > much about tuners anyway.  I used the v4l2-i2c-drv.h since it seems 
> > > > > like
> > > > > a good idea at the time.  What should I use instead?
> > > > 
> > > > We way i2c devices are handled changed massively in kernel 2.6.26. In 
> > > > order to
> > > > stay backwards compatible with older kernels the v4l2-i2c-drv.h header 
> > > > was
> > > > introduced. However, this is a bit of a hack and any i2c driver that 
> > > > does not
> > > > need it shouldn't use it.
> > > > 
> > > > So only if an i2c driver is *never* used by parent drivers that have to 
> > > > support
> > > > kernels < 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of 
> > > > such an
> > > > i2c driver is tvp514x.c.
> > > > 
> > > > Eventually support for such old kernels will be dropped and the 
> > > > v4l2-i2c-drv.h
> > > > header will disappear altogether, but that's not going to happen 
> > > > anytime soon.
> > > > 
> > > > What this means for go7007 is that you have to decide whether you want 
> > > > this
> > > > go7007 driver to work only for kernels >= 2.6.26, or whether it should 
> > > > also
> > > > work for older kernels. My understanding is that Sensoray wants to be 
> > > > able to
> > > > compile go7007 for older kernels. In that case the use of 
> > > > v4l2-i2c-drv.h is
> > > > correct. Note that this is not about whether any of *Sensoray's* 
> > > > products use
> > > > a particular i2c device, but whether the *go7007* driver uses it.
> > > > 
> > > > I hope this clarifies this.
> > > 
> > > Yes it does, thank you.  We do want to allow our customers to use the
> > > go7007 driver with our products on older kernels, so I would like to
> > > keep the v4l2-i2c-drv.h for now.  I've addressed your other comments in
> > > the revised patch:
> > 
> > I've two small comments. See below.
> > 
> > I also realized that this is really two drivers in one: one driver for the
> > actual tuner device and one for the mpx device which seems similar in
> > functionality to the vp27smpx.c driver.
> > 
> > I will look at it again tomorrow, but I might decide that it is better to
> > split it up into two drivers: one for the tuner and one for the mpx.
> 
> After thinking about this a bit more I decided that this tuner should be split
> up into two drivers: one for the mpx device and one for the actual tuner. This
> should be fairly easy to do.
> 
> One other thing that this accomplishes is that it is easier to see whether the
> tuner code can actually be merged into tuner-types.c. From what I can see now
> I would say that that is possible for the NTSC_M and NTSC_M_JP models. The
> PAL/SECAM model is harder since it needs to setup the tuner whenever the
> standard changes. But it seems that that is also possible by adding code
> to simple_std_setup() in tuner-simple.c.
> 
> I'm pretty sure that these tuners can just be folded into tuner-types.c
> and tuner-simple.c. We probably only need an mpx driver.
> 
> Andy, can you also take a look?

Sure.  It looks like to me you actually have three chips:

- oscillator/mixer (at address 0x60 like a TUA6030)
- programmable IF PLL demodulator (at address 0x43 like a TDA9887)
- MPX demodulator/dematrix IC.


The mizer oscillator part programming *really looks like* a TUA6030 or
equivalent chip being programmed. The charge pump bit is left in a high
current state, BTW,  meaning fast tuning, but probably more phase noise
when tuned.

The IF part programming in this driver *really looks like* a TDA9887
being programmed.  I have not verified the bits being set against the
various TV system audio standards in the switch() statement though.


The MPX part has the same I2C address as some Sanyo TV Sound MPX
demodulators, but the register set is very different.  I can't figure
out what part is being used.  (NXP/Philips BTSC/SAP MPX demodulators use
address 0x5b I think).


Given this, I don't see why most of the driver could not be handled by
tuner-simple and tda9887.


The question becomes do you want to extend tuneer-simple to handle the
MPX chip in analog tuner assemblies with an included MPX chip - so the
bridge driver need n

Re: [PATCH]Add support for SMT7020 to cx88

[Mauro Carvalho Chehab]

Helmut Auer wrote:
> Am 11.02.2010 22:06, schrieb Helmut Auer:
>> From: Helmut Auer 
>>
>> This patch (originally written by Dirk Herrendoerfer) adds support for the 
>> built-in dvb device
>> of a Samsung SMT7020s (x86 based STB) to the cx88 family.
>> (see http://www.linuxtv.org/pipermail/linux-dvb/2007-January/015208.html)
>>
>> Signed-off-by: Helmut Auer 
>>
> What's to do to get attention for this ?
> 
Your patch will likely be catched by patchwork, so, it is on the queue. I should
be handle the pending patches after the holidays. Yet, as it adds a new driver,
we need the Signed-off-by from the driver author (Dirk).

-- 

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

Pull http://jusst.de/hg/v4l-dvb

[Manu Abraham]

Mauro,

Please pull from http://jusst.de/hg/v4l-dvb

for the following changes for the AZ6027 DVB USB DVB-S2 CI device

There has been a shortage of supported CI devices. The driver provides
support for the following:

- Azurewave VP-6027 or AD-SB301 or some other name by which it is called.

Additionally, it supports 2 other re branded USB devices as well, viz,

- Technisat DVB-S2 HD CI
- Terratec DVB-S2 CI


If any other STB0899/STB6100 based similar devices are known,
hopefully we can add in support in to the same driver.


changeset:   14169:fcd125343873
http://jusst.de/hg/v4l-dvb/rev/fcd125343873
AZ6027: Fix build warnings


changeset:   14168:f0304f694aca
http://jusst.de/hg/v4l-dvb/rev/f0304f694aca
AZ6027: Fix checkpatch violations


changeset:   14167:1af35f1537e7
http://jusst.de/hg/v4l-dvb/rev/1af35f1537e7
AZ6027: Add driver supported ID's


changeset:   14166:d40a2eb97f77
http://jusst.de/hg/v4l-dvb/re/d40a2eb97f77
AZ6027: Update Build


changeset:   14165:eefc5eae5449
http://jusst.de/hg/v4l-dvb/rev/eefc5eae5449
AZ6027: Add driver supported ID's


changeset:   14164:e961a33a85ac
http://jusst.de/hg/v4l-dvb/rev/e961a33a85ac
AZ6027: Initial import of the driver


It appears to function prima facie;


[  499.201809] TUPLE type:0x1b length:37
[  499.202184]   0x00: 0xcf .
[  499.202561]   0x01: 0x04 .
[  499.202934]   0x02: 0x09 .
[  499.203308]   0x03: 0x37 7
[  499.203682]   0x04: 0x55 U
[  499.204057]   0x05: 0x4d M
[  499.204432]   0x06: 0x5d ]
[  499.204807]   0x07: 0x1d .
[  499.205182]   0x08: 0x56 V
[  499.205557]   0x09: 0x22 "
[  499.205931]   0x0a: 0xc0 .
[  499.206396]   0x0b: 0x09 .
[  499.206807]   0x0c: 0x44 D
[  499.207181]   0x0d: 0x56 V
[  499.207555]   0x0e: 0x42 B
[  499.207930]   0x0f: 0x5f _
[  499.208305]   0x10: 0x48 H
[  499.208679]   0x11: 0x4f O
[  499.209054]   0x12: 0x53 S
[  499.209428]   0x13: 0x54 T
[  499.209803]   0x14: 0x00 .
[  499.210178]   0x15: 0xc1 .
[  499.210552]   0x16: 0x0e .
[  499.210928]   0x17: 0x44 D
[  499.211303]   0x18: 0x56 V
[  499.211677]   0x19: 0x42 B
[  499.212052]   0x1a: 0x5f _
[  499.212427]   0x1b: 0x43 C
[  499.212801]   0x1c: 0x49 I
[  499.213176]   0x1d: 0x5f _
[  499.213551]   0x1e: 0x4d M
[  499.213926]   0x1f: 0x4f O
[  499.214388]   0x20: 0x44 D
[  499.214802]   0x21: 0x55 U
[  499.215175]   0x22: 0x4c L
[  499.215549]   0x23: 0x45 E
[  499.215924]   0x24: 0x00 .
[  499.216673] TUPLE type:0x14 length:0
[  499.217048] END OF CHAIN TUPLE type:0xff
[  499.217050] Valid DVB CAM detected MANID: DEVID:1
CONFIGBASE:0x1fe CONFIGOPTION:0xf
[  499.217053] dvb_ca_en50221_set_configoption
[  499.217672] Set configoption 0xf, read configoption 0xf
[  499.217922] DVB CAM validated successfully
[  499.518210] dvb_ca_en50221_link_init
[  499.518458] dvb_ca_en50221_wait_if_status
[  499.518709] dvb_ca_en50221_wait_if_status succeeded timeout:0
[  499.518711] dvb_ca_en50221_read_data
[  499.520206] Received CA packet for slot 0 connection id 0x0
last_frag:0 size:0x2
[  499.520455] Chosen link buffer size of 128
[  499.520706] dvb_ca_en50221_wait_if_status
[  499.520957] dvb_ca_en50221_wait_if_status succeeded timeout:0
[  499.520959] dvb_ca_en50221_write_data
[  499.523082] Wrote CA packet for slot 0, connection id 0x0
last_frag:0 size:0x2
[  499.523830] dvb_ca adapter 0: DVB CAM detected and initialised successfully


Regards,
Manu
--
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] V4L: dvb-usb, add extra sync to down-up input events

[Jiri Slaby]

Userspace is allowed to coalesce events between SYNCs. And since the code
emits UP right after DOWN for the same key, it may be missed
(up+down=nothing). Add an extra sync in between UP and DOWN events to disable
the coalesce.

Signed-off-by: Jiri Slaby 
Cc: Dmitry Torokhov 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
---
 drivers/media/dvb/dvb-usb/dib0700_core.c   |1 +
 drivers/media/dvb/dvb-usb/dvb-usb-remote.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c 
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 4450214..4f961d2 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -612,6 +612,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
case REMOTE_KEY_REPEAT:
deb_info("key repeated\n");
input_event(d->rc_input_dev, EV_KEY, event, 1);
+   input_sync(d->rc_input_dev);
input_event(d->rc_input_dev, EV_KEY, d->last_event, 0);
input_sync(d->rc_input_dev);
break;
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c 
b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
index 6b5ded9..a03ef7e 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
@@ -107,6 +107,7 @@ static void dvb_usb_read_remote_control(struct work_struct 
*work)
case REMOTE_KEY_REPEAT:
deb_rc("key repeated\n");
input_event(d->rc_input_dev, EV_KEY, event, 1);
+   input_sync(d->rc_input_dev);
input_event(d->rc_input_dev, EV_KEY, d->last_event, 0);
input_sync(d->rc_input_dev);
break;
-- 
1.6.6.1

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

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

[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:Sun Feb 14 19:00:12 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14198:14021dfc00f3
gcc version: i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os: 2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-rc5-armv5: OK
linux-2.6.32.6-armv5-davinci: ERRORS
linux-2.6.33-rc5-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-dm365: ERRORS
linux-2.6.33-rc5-armv5-dm365: ERRORS
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-rc5-armv5-ixp: OK
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-rc5-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.17-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.20-i686: OK
linux-2.6.26.8-i686: OK
linux-2.6.27.44-i686: OK
linux-2.6.28.10-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: OK
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-rc5-i686: OK
linux-2.6.32.6-m32r: OK
linux-2.6.33-rc5-m32r: OK
linux-2.6.32.6-mips: OK
linux-2.6.33-rc5-mips: OK
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-rc5-powerpc64: OK
linux-2.6.22.19-x86_64: OK
linux-2.6.23.17-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.20-x86_64: OK
linux-2.6.26.8-x86_64: OK
linux-2.6.27.44-x86_64: OK
linux-2.6.28.10-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: OK
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-rc5-x86_64: OK
spec: OK
sparse (v4l-dvb-git): ERRORS
sparse (linux-2.6.33-rc5): ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: OK
linux-2.6.19.7-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: OK
linux-2.6.19.7-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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

[PATCH] mfd: Add timb-radio to the timberdale MFD

[Richard Röjfors]

This patch addes timb-radio to all configurations of the timberdale MFD.

Connected to the FPGA is a TEF6862 tuner and a SAA7706H DSP, the I2C
board info of these devices is passed via the timb-radio platform data.

Signed-off-by: Richard Röjfors 
---
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 603cf06..1ed44d2 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -37,6 +37,8 @@
 #include 
 #include 

+#include 
+
 #include "timberdale.h"

 #define DRIVER_NAME "timberdale"
@@ -213,6 +215,40 @@ const static __devinitconst struct resource 
timberdale_uartlite_resources[] = {
},
 };

+const static __devinitconst struct resource timberdale_radio_resources[] = {
+   {
+   .start  = RDSOFFSET,
+   .end= RDSEND,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = IRQ_TIMBERDALE_RDS,
+   .end= IRQ_TIMBERDALE_RDS,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static __devinitdata struct i2c_board_info timberdale_tef6868_i2c_board_info = 
{
+   I2C_BOARD_INFO("tef6862", 0x60)
+};
+
+static __devinitdata struct i2c_board_info timberdale_saa7706_i2c_board_info = 
{
+   I2C_BOARD_INFO("saa7706h", 0x1C)
+};
+
+static __devinitdata struct timb_radio_platform_data
+   timberdale_radio_platform_data = {
+   .i2c_adapter = 0,
+   .tuner = {
+   .module_name = "tef6862",
+   .info = &timberdale_tef6868_i2c_board_info
+   },
+   .dsp = {
+   .module_name = "saa7706h",
+   .info = &timberdale_saa7706_i2c_board_info
+   }
+};
+
 const static __devinitconst struct resource timberdale_dma_resources[] = {
{
.start  = DMAOFFSET,
@@ -240,6 +276,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg0[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+   .name = "timb-radio",
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = &timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = "xilinx_spi",
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
@@ -282,6 +325,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg1[] = {
.resources = timberdale_mlogicore_resources,
},
{
+   .name = "timb-radio",
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = &timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = "xilinx_spi",
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
@@ -314,6 +364,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg2[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+   .name = "timb-radio",
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = &timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = "xilinx_spi",
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
@@ -348,6 +405,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg3[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+   .name = "timb-radio",
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = &timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = "xilinx_spi",
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]Add support for SMT7020 to cx88

[Helmut Auer]

Am 11.02.2010 22:06, schrieb Helmut Auer:
> From: Helmut Auer 
> 
> This patch (originally written by Dirk Herrendoerfer) adds support for the 
> built-in dvb device
> of a Samsung SMT7020s (x86 based STB) to the cx88 family.
> (see http://www.linuxtv.org/pipermail/linux-dvb/2007-January/015208.html)
> 
> Signed-off-by: Helmut Auer 
> 
What's to do to get attention for this ?

-- 
Helmut Auer, hel...@helmutauer.de
--
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

alevt-dvb now part of the dvb-apps - some critical remarks / enhancements

[Chicken Shack]

Hi everybody,
Hello Manu,

now that Francesco's proposal is reality I want to add some necessary
things as I do not want or appreciate an implementation of alevt-dvb
in a kind of half-way-down-the-line-style.

Either this is done correctly (100 %) or this should not be done at all.

I provide some patchset as outline attachment to improve:

1. alevt.patch: - Changes in Changelog, README and TODO
  a nasty superfluous error message in vbi.c is being
  wiped out

2. alevt.png:   wasn't part of the implemetation patch,
please apply manually in the main directory of alevt

3. apps_manpages.patch: in one of my creative moments I wrote a
whole bunch of manpages for the dvb-apps suite.
In case of Debianization of the package
the lintian tool requires 1 manpage per binary.
Mandatory!
4. apps_zapcycles.patch: one of my apps needs a shorter timeout for szap
to function correctly

5. dvb-apps.lintian-overrides: These are program errors that
lintian finds during testing
the validity of the package.


A. I'd appreciate to apply 1. - 3.
B. Applying 4. is not necessary, but would ease my personal hosting
C. 5. should be eliminated by an experienced software hacker

5. looks like this:

dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libucsi.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvbapi.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvben50221.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvbsec.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvbcfg.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libesg.so


D. As I stated several times, the major problem of that program is NOT
where it is hosted, but furthermore the problem that it does not
know how to deal with a channel change in DVB mode when the transponder
is being changed by the external player application.
Just as reminder...

P. S.: Wouldn't it be a good idea to imply a dependency checker into the
dvb-apps package?
It's a bit unhandy to tell the people via readme to go to /utils/alevt
and type make, if the dependencies are fulfilled.

Guess that can be automatized?

Cheers

CS

--- a/util/alevt/ChangeLog
+++ b/util/alevt/ChangeLog
@@ -1,11 +1,11 @@
-Thu Feb 11 22:05:00 MET 2010	(1.7.0)
+Sat Feb 14 15:10:00 MET 2010	(1.7.0)
 
 - redesigned version:
 - outfile, new starting methods, libzvbi implementation
 - lots of bug fixes, all patches available in the Internet applied
-- extensive code cleanup
+- intensive code cleanup
 
-Mon Dec  3 03:11:07 MET 2007	(1.6.2)
+Mon Dec 3 03:11:07 MET 2007	(1.6.2)
 
 - compilation fixes for newer gcc
 - makefile tweaks (man vs share/man, /usr/X11R6 vs /usr, etc)
--- a/util/alevt/README
+++ b/util/alevt/README
@@ -13,7 +13,7 @@
 3. lots of cruft which is completely outdated or obsolete for other reasons
 
 To handle all that in one big effort I decided to redesign the program
-completely, enlarging its capabilities for DVB-S at the same time.
+completely, enlarging its DVB capabilities at the same time.
 
 So here are the changes:
 
@@ -22,8 +22,7 @@
 
 2. Erasure of old outdated integers, functions, parameters:
 
-- bell, big_buf, debug, display, editor, erc, fine_tune, newbttv,
-- oldbttv
+- bell, big_buf, debug, display, editor, erc, fine_tune, newbttv, oldbttv.
 
 3. Coding style cleanups (no superfluous comments, not more than
80 characters per column, no uncommented code.
@@ -52,20 +51,24 @@
make install" there is an uninstaller now to revert the installation:
"make uninstall".
 
-ENJOY IT!
+External dependencies to run that program:
 
-Uwe Bugla, February 11th, 2010.
+AleVT needs some some system libraries to be installed in your system.
+- libc6 (>= 2.3.6)
+- libpng12 (>= 1.2.13)
+- libx11 (>= 1.3.3)
+- libzvbi0 (>= 0.2.11)
+- zlib (>= 1.1.4)
 
-External dependencies
+ENJOY IT!
 
-AleVT needs some system libraries to be installed in your system.
-They are zlib, libX11, libpng and libzvbi.
+Uwe Bugla, February 14th, 2010.
 
 Credits go to:
 - Andreas Rottmann from debian.org for compiler fixes and
   other kinds of investigation.
 - Francesco Lavra for supplying a kernel patch to avoid kernel demux
-  incompatibilities with kernels >= 2.6.32
+  incompatibilities with kernels 2.6.32-rc1 - 2.6.33-rc7
 - Andy Walls for helpful investigation in kernelspace
 - Edgar Toernig for providing the source version 1.6.2 and doing all the
   development for the basic versions
--- a/util/alevt/TODO
+++ b/util/alevt/TODO
@@ -1,12 +1,18 @@
-Hi, these are issues that I unfortunately cannot resolve myself:
+These are issues that I unfortunately cannot resolve myself:
 
-1. graphical menu written in GKT2, to be used in 

Re: Info

[Devin Heitmueller]

On Sun, Feb 14, 2010 at 12:33 PM, Florent NOUVELLON
 wrote:
> Hi Devin,
>
> Did you with Prahal advanced the 0072/terratec hybrid xs fm support in
> linux-dvb driver ?
>
> If you need any kind of help (testing, or whatever) feel free to ask me.
>
> Regards,
> Florent

Hi Florent,

Prahal was making good progress, and I was helping him over irc when I
had time.  But I have not invested any of my own time working on the
driver at this point (as I've been tied up working on other projects).

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

em28xx and Terratex Cinergy Hybrid T USB XS 0ccd,004c

[Catimimi]

Hello,

If it can help to validate this unit, you'll find below the result od 
dmesg whenit is plugged in :


[   86.977094] usb 2-1: new high speed USB device using ehci_hcd and 
address 3

[   87.129594] usb 2-1: New USB device found, idVendor=0ccd, idProduct=004c
[   87.129614] usb 2-1: New USB device strings: Mfr=2, Product=1, 
SerialNumber=0

[   87.129627] usb 2-1: Product: Cinergy Hybrid T USB XS FR
[   87.129637] usb 2-1: Manufacturer: TerraTec Electronic GmbH
[   87.129824] usb 2-1: configuration #1 chosen from 1 choice
[   87.313123] em28xx: New device TerraTec Electronic GmbH Cinergy 
Hybrid T USB XS FR @ 480 Mbps (0ccd:004c, interface 0, class 0)

[   87.326274] em28xx #0: chip ID is em2882/em2883
[   87.485970] em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 4c 00 60 12 
5c 03 6a 38 a2 34
[   87.485993] em28xx #0: i2c eeprom 10: 00 00 06 57 46 07 00 00 00 00 
00 00 00 00 00 00
[   87.486011] em28xx #0: i2c eeprom 20: 4e 00 10 00 f0 10 31 88 b8 00 
14 00 5b 1e 00 00
[   87.486029] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 
00 00 00 00 00 00
[   87.486047] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486064] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486082] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 
38 03 43 00 69 00
[   87.486100] em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 
20 00 48 00 79 00
[   87.486118] em28xx #0: i2c eeprom 80: 62 00 72 00 69 00 64 00 20 00 
54 00 20 00 55 00
[   87.486135] em28xx #0: i2c eeprom 90: 53 00 42 00 20 00 58 00 53 00 
20 00 46 00 52 00
[   87.486153] em28xx #0: i2c eeprom a0: 00 00 34 03 54 00 65 00 72 00 
72 00 61 00 54 00
[   87.486170] em28xx #0: i2c eeprom b0: 65 00 63 00 20 00 45 00 6c 00 
65 00 63 00 74 00
[   87.486188] em28xx #0: i2c eeprom c0: 72 00 6f 00 6e 00 69 00 63 00 
20 00 47 00 6d 00
[   87.486206] em28xx #0: i2c eeprom d0: 62 00 48 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486223] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486241] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00

[   87.486260] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xfea8f21d
[   87.486266] em28xx #0: EEPROM info:
[   87.486271] em28xx #0:I2S audio, sample rate=32k
[   87.486276] em28xx #0:500mA max power
[   87.486281] em28xx #0:Table at 0x06, strings=0x386a, 0x34a2, 0x
[   87.486970] em28xx #0: Identified as Terratec Hybrid XS Secam (card=51)
[   87.486983] em28xx #0:
[   87.486984]
[   87.486990] em28xx #0: The support for this board weren't valid yet.
[   87.486996] em28xx #0: Please send a report of having this working
[   87.487002] em28xx #0: not to V4L mailing list (and/or to other 
addresses)

[   87.487004]
[   87.507721] msp3400 0-0044: MSP3415G-B8 found @ 0x88 (em28xx #0)
[   87.507737] msp3400 0-0044: msp3400 supports nicam and radio, mode is 
autodetect and autoselect

[   87.521848] tvp5150 0-005c: chip found @ 0xb8 (em28xx #0)
[   87.540508] tuner 0-0061: chip found @ 0xc2 (em28xx #0)
[   87.573389] xc2028 0-0061: creating new instance
[   87.573400] xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner
[   87.573413] usb 2-1: firmware: requesting xc3028-v27.fw
[   87.636660] xc2028 0-0061: Loading 80 firmware images from 
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[   87.685063] xc2028 0-0061: Loading firmware for type=BASE (1), id 
.
[   88.690351] xc2028 0-0061: Loading firmware for type=(0), id 
b700.

[   88.705224] SCODE (2000), id b700:
[   88.705235] xc2028 0-0061: Loading SCODE for type=MONO SCODE 
HAS_IF_4320 (60008000), id 8000.

[   88.888098] em28xx #0: Config register raw data: 0x60
[   88.888111] em28xx #0: I2S Audio (3 sample rates)
[   88.888116] em28xx #0: No AC97 audio processor
[   89.001959] tvp5150 0-005c: tvp5150am1 detected.
[   89.116049] em28xx #0: v4l2 driver version 0.1.2
[   89.132359] tvp5150 0-005c: i2c i/o error: rc == -19 (should be 1)
[   89.135958] msp3400 0-0044: I/O error #0 (read 0x10/0x30)
[   89.144720] msp3400 0-0044: I/O error #1 (read 0x10/0x30)
[   89.156582] msp3400 0-0044: I/O error #2 (read 0x10/0x30)
[   89.168058] msp3400 0-0044: resetting chip, sound will go off.
[   89.169227] msp3400 0-0044: chip reset failed
[   89.170704] msp3400 0-0044: chip reset failed
[   89.214685] em28xx #0: V4L2 device registered as /dev/video1 and 
/dev/vbi0

[   89.242829] usbcore: registered new interface driver snd-usb-audio
[   89.242843] usbcore: registered new interface driver em28xx
[   89.242854] em28xx driver loaded
[   89.353470] tvp5150 0-005c: tvp5150am1 detected.
[   89.673467] tvp5150 0-005c: tvp5150am1 detected.

There is an error with tvp5150 and with msp3400.
The following Modules are loaded :

em28xx
msp3400
tvp5150
tuner_xc3028
snd_rawmidi
snd_usb_lib
snd_usb_audio

I run openSUSE 11.2 with the very last kernel 2.6.31.12-0.1

Ready to make test.
Regar

How to add DVB-S2 support to firedtv?

[Stefan Richter]

Hi all,

what steps need to be taken to get DVB-S2 support into the firedtv
driver?  (The status is, as far as I understood:  FireDTV S2 and Floppy
DTV S2 devices recognize HD channels during channel scan but cannot tune
to them.  FireDTV C/CI DVB-C boxes however tune and play back HD
channels just fine.)

I suppose the frontend needs to be extended for s2api.  Was there a
respective conversion in another DVB driver that can serve as a good
coding example?

Is documentation from Digital Everywhere required regarding the
vendor-specific AV/C requests (LNB_CONTROL? TUNE_QPSK2?) or is the
current driver code enough to connect the dots?

Is the transport stream different from DVB-C HD streams so that changes
to the isochronous I/O part would be required?
-- 
Stefan Richter
-=-==-=- --=- -===-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner

[Hans Verkuil]

On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote:
> On Friday 12 February 2010 23:36:20 Pete Eberlein wrote:
> > On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote:
> > > > > > +#include 
> > > > > 
> > > > > The v4l2-i2c-drv.h is to be used only for drivers that also need to 
> > > > > be compiled
> > > > > for kernels < 2.6.26. If I am not mistaken that is the case for this 
> > > > > driver,
> > > > > right? I remember you mentioning that customers of yours use this on 
> > > > > such old
> > > > > kernels. Just making sure.
> > > > 
> > > > My company, Sensoray, doesn't have any products that use this tuner.
> > > > This driver was orignally written by Micronas to support their go7007
> > > > chip in the Plextor TV402U models.  I don't have the datasheet or know
> > > > much about tuners anyway.  I used the v4l2-i2c-drv.h since it seems like
> > > > a good idea at the time.  What should I use instead?
> > > 
> > > We way i2c devices are handled changed massively in kernel 2.6.26. In 
> > > order to
> > > stay backwards compatible with older kernels the v4l2-i2c-drv.h header was
> > > introduced. However, this is a bit of a hack and any i2c driver that does 
> > > not
> > > need it shouldn't use it.
> > > 
> > > So only if an i2c driver is *never* used by parent drivers that have to 
> > > support
> > > kernels < 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of such 
> > > an
> > > i2c driver is tvp514x.c.
> > > 
> > > Eventually support for such old kernels will be dropped and the 
> > > v4l2-i2c-drv.h
> > > header will disappear altogether, but that's not going to happen anytime 
> > > soon.
> > > 
> > > What this means for go7007 is that you have to decide whether you want 
> > > this
> > > go7007 driver to work only for kernels >= 2.6.26, or whether it should 
> > > also
> > > work for older kernels. My understanding is that Sensoray wants to be 
> > > able to
> > > compile go7007 for older kernels. In that case the use of v4l2-i2c-drv.h 
> > > is
> > > correct. Note that this is not about whether any of *Sensoray's* products 
> > > use
> > > a particular i2c device, but whether the *go7007* driver uses it.
> > > 
> > > I hope this clarifies this.
> > 
> > Yes it does, thank you.  We do want to allow our customers to use the
> > go7007 driver with our products on older kernels, so I would like to
> > keep the v4l2-i2c-drv.h for now.  I've addressed your other comments in
> > the revised patch:
> 
> I've two small comments. See below.
> 
> I also realized that this is really two drivers in one: one driver for the
> actual tuner device and one for the mpx device which seems similar in
> functionality to the vp27smpx.c driver.
> 
> I will look at it again tomorrow, but I might decide that it is better to
> split it up into two drivers: one for the tuner and one for the mpx.

After thinking about this a bit more I decided that this tuner should be split
up into two drivers: one for the mpx device and one for the actual tuner. This
should be fairly easy to do.

One other thing that this accomplishes is that it is easier to see whether the
tuner code can actually be merged into tuner-types.c. From what I can see now
I would say that that is possible for the NTSC_M and NTSC_M_JP models. The
PAL/SECAM model is harder since it needs to setup the tuner whenever the
standard changes. But it seems that that is also possible by adding code
to simple_std_setup() in tuner-simple.c.

I'm pretty sure that these tuners can just be folded into tuner-types.c
and tuner-simple.c. We probably only need an mpx driver.

Andy, can you also take a look?

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: videobuf and streaming I/O questions

[Hans Verkuil]

On Sunday 14 February 2010 14:41:29 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> > Hi all,
> > 
> > I've been investigating some problems with my qv4l2 utility and I 
> > encountered
> > some inconsistencies in the streaming I/O documentation and the videobuf
> > implementation.
> > 
> > I would like to know which is correct.
> > 
> > 1) The VIDIOC_QBUF documentation should specify that the application has
> > to fill in the v4l2_buffer 'flags' field. The fact that this is not 
> > explicitly
> > stated tripped me up in qv4l2.
> 
> I don't think you need to set the flags, but for sure you need to clear the 
> data
> on all ioctls. The capture-example.c is a reference code for implementation, 
> and it
> does:
> 
> CLEAR(buf);
> buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> buf.memory = V4L2_MEMORY_MMAP;
> buf.index = i;
> 
> if (-1 == xioctl(fd, VIDIOC_QBUF, &buf))
> errno_exit("VIDIOC_QBUF");
> 
> As far as I've tested, this app works on all drivers that support mmap.

I will fix the spec for this.

> > 2) The VIDIOC_REQBUFS documentation states that it should be possible to use
> > a count of 0, in which case it should do an implicit STREAMOFF. This is
> > currently not implemented. I have included a patch for this below and if 
> > there
> > are no issues with it, then I'll make a pull request for this.
> 
> This can eventually break some application. I think it is safer to fix the 
> specs.

I don't really see how this would break an application and I think that some
drivers that do not use videobuf already support this. The reason why I think
this is a good idea to support it is that this makes it very easy to check
which streaming mode is supported without actually allocating anything.

I was actually using this in qv4l2 with uvc until I tried it with the mxb driver
and discovered that videobuf didn't support it. I am definitely in favor of
fixing the code instead of the spec in this case.

> > 3) The VIDIOC_REQBUFS documentation states that the count field is only used
> > by MEMORY_MMAP, not by MEMORY_USERPTR. This seems to be a false statement.
> > videobuf certainly uses the count field.
> 
> True. We need to fix the specs.
>  
> > 4) The same is true for QBUF and DQBUF and the index field of struct 
> > v4l2_buffer:
> > the documentation states that it is only used for MMAP, but as far as I can 
> > tell
> > that is not true and it should be used for USERPTR as well.
> 
> True. We need to fix the specs.
> > 
> > 5) Section 3.2 states that one should use VIDIOC_REQBUFS to determine if the
> > memory mapping flavor is supported by the driver. At least in the case of 
> > the
> > saa7146/mxb driver (which uses videobuf) this does not work. Even though it 
> > only
> > supports mmap, videobuf happily accepts userptr mode as well. Who is 
> > supposed
> > to test this? The driver before it calls videobuf_reqbufs?
> 
> videobuf-dma-sg supports all modes. if the driver has restrictions to one of 
> the mode,
> videobuf have no way to know. So, the driver must limit.

OK.

> 
> > 6) V4L2_MEMORY_OVERLAY seems to be supported in videobuf, yet there is no 
> > driver
> > that supports it as far as I can tell and the documentation does not explain
> > what it is supposed to do. What is the status of this?
> 
> It is supported by videobuf and it is implemented by a few drivers. The best 
> example
> is bttv-driver. I think saa7134 also implements the overlay mode.

Can you write a bit of documentation on how the m union of v4l2_buffer has to
be filled in for this mode? I will integrate that into the spec.

I found one mention here: 

http://archive.linuxcoding.com/video-4-linux/2002/msg03126.html

And one application that uses it here:

http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.3.tar.gz

Although it would be nice if it could actually be tested by someone whether
this is actually still working.

Regards,

Hans


> Some motherboard chipsets don't work fine on overlay mode, since, in general, 
> it causes
> a PCI2PCI data transfers. It is a known bug that, when PCI2PCI DMA transfers 
> are happening,
> and if a PCI2MEM or MEM2PCI DMA is called (for example, to write a data to 
> disk or to get
> swapped memory), that the two transfers got messed, causing memory and/or 
> disk corruption.
> 
> There are some PCI quirks to disable this feature at the chipsets where this 
> bug is known
> (some chipsets manufactured by VIA and by SYS).
> 
> This is mostly why people don't get enough motivation for use it on other 
> drivers.
> > 
> > When I know the correct answers to this I will fix these issues. The qv4l2 
> > tool
> > is written based on the documentation instead of copy-and-paste, so this 
> > was a
> > good test case to discover these inconsistencies.
> 
> Yes.
> > 
> > Regards,
> > 
> > Hans
> 
> Cheers,
> Mauro
> 

-- 

Re: videobuf and streaming I/O questions

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> Hi all,
> 
> I've been investigating some problems with my qv4l2 utility and I encountered
> some inconsistencies in the streaming I/O documentation and the videobuf
> implementation.
> 
> I would like to know which is correct.
> 
> 1) The VIDIOC_QBUF documentation should specify that the application has
> to fill in the v4l2_buffer 'flags' field. The fact that this is not explicitly
> stated tripped me up in qv4l2.

I don't think you need to set the flags, but for sure you need to clear the data
on all ioctls. The capture-example.c is a reference code for implementation, 
and it
does:

CLEAR(buf);
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_MMAP;
buf.index = i;

if (-1 == xioctl(fd, VIDIOC_QBUF, &buf))
errno_exit("VIDIOC_QBUF");

As far as I've tested, this app works on all drivers that support mmap.

> 2) The VIDIOC_REQBUFS documentation states that it should be possible to use
> a count of 0, in which case it should do an implicit STREAMOFF. This is
> currently not implemented. I have included a patch for this below and if there
> are no issues with it, then I'll make a pull request for this.

This can eventually break some application. I think it is safer to fix the 
specs.

> 3) The VIDIOC_REQBUFS documentation states that the count field is only used
> by MEMORY_MMAP, not by MEMORY_USERPTR. This seems to be a false statement.
> videobuf certainly uses the count field.

True. We need to fix the specs.
 
> 4) The same is true for QBUF and DQBUF and the index field of struct 
> v4l2_buffer:
> the documentation states that it is only used for MMAP, but as far as I can 
> tell
> that is not true and it should be used for USERPTR as well.

True. We need to fix the specs.
> 
> 5) Section 3.2 states that one should use VIDIOC_REQBUFS to determine if the
> memory mapping flavor is supported by the driver. At least in the case of the
> saa7146/mxb driver (which uses videobuf) this does not work. Even though it 
> only
> supports mmap, videobuf happily accepts userptr mode as well. Who is supposed
> to test this? The driver before it calls videobuf_reqbufs?

videobuf-dma-sg supports all modes. if the driver has restrictions to one of 
the mode,
videobuf have no way to know. So, the driver must limit.

> 6) V4L2_MEMORY_OVERLAY seems to be supported in videobuf, yet there is no 
> driver
> that supports it as far as I can tell and the documentation does not explain
> what it is supposed to do. What is the status of this?

It is supported by videobuf and it is implemented by a few drivers. The best 
example
is bttv-driver. I think saa7134 also implements the overlay mode.

Some motherboard chipsets don't work fine on overlay mode, since, in general, 
it causes
a PCI2PCI data transfers. It is a known bug that, when PCI2PCI DMA transfers 
are happening,
and if a PCI2MEM or MEM2PCI DMA is called (for example, to write a data to disk 
or to get
swapped memory), that the two transfers got messed, causing memory and/or disk 
corruption.

There are some PCI quirks to disable this feature at the chipsets where this 
bug is known
(some chipsets manufactured by VIA and by SYS).

This is mostly why people don't get enough motivation for use it on other 
drivers.
> 
> When I know the correct answers to this I will fix these issues. The qv4l2 
> tool
> is written based on the documentation instead of copy-and-paste, so this was a
> good test case to discover these inconsistencies.

Yes.
> 
> Regards,
> 
>   Hans

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

videobuf and streaming I/O questions

[Hans Verkuil]

Hi all,

I've been investigating some problems with my qv4l2 utility and I encountered
some inconsistencies in the streaming I/O documentation and the videobuf
implementation.

I would like to know which is correct.

1) The VIDIOC_QBUF documentation should specify that the application has
to fill in the v4l2_buffer 'flags' field. The fact that this is not explicitly
stated tripped me up in qv4l2.

2) The VIDIOC_REQBUFS documentation states that it should be possible to use
a count of 0, in which case it should do an implicit STREAMOFF. This is
currently not implemented. I have included a patch for this below and if there
are no issues with it, then I'll make a pull request for this.

3) The VIDIOC_REQBUFS documentation states that the count field is only used
by MEMORY_MMAP, not by MEMORY_USERPTR. This seems to be a false statement.
videobuf certainly uses the count field.

4) The same is true for QBUF and DQBUF and the index field of struct 
v4l2_buffer:
the documentation states that it is only used for MMAP, but as far as I can tell
that is not true and it should be used for USERPTR as well.

5) Section 3.2 states that one should use VIDIOC_REQBUFS to determine if the
memory mapping flavor is supported by the driver. At least in the case of the
saa7146/mxb driver (which uses videobuf) this does not work. Even though it only
supports mmap, videobuf happily accepts userptr mode as well. Who is supposed
to test this? The driver before it calls videobuf_reqbufs?

6) V4L2_MEMORY_OVERLAY seems to be supported in videobuf, yet there is no driver
that supports it as far as I can tell and the documentation does not explain
what it is supposed to do. What is the status of this?

When I know the correct answers to this I will fix these issues. The qv4l2 tool
is written based on the documentation instead of copy-and-paste, so this was a
good test case to discover these inconsistencies.

Regards,

Hans

---
[PATCH] V4L-DVB: Add support for count == 0 to videobuf's VIDIOC_REQBUFS 
implementation.

The spec says that VIDIOC_REQBUFS should support a count of 0, in which
case it should act like an implicit VIDIOC_STREAMOFF. The core videobuf
implementation did not support this, so we add this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/videobuf-core.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index bb0a1c8..10cb0ec 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -40,6 +40,8 @@ MODULE_LICENSE("GPL");
if (debug >= level) \
printk(KERN_DEBUG "vbuf: " fmt , ## arg); } while (0)
 
+static int __videobuf_streamoff(struct videobuf_queue *q);
+
 /* - */
 
 #define CALL(q, f, arg...) \
@@ -395,11 +397,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
unsigned int size, count;
int retval;
 
-   if (req->count < 1) {
-   dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
-   return -EINVAL;
-   }
-
if (req->memory != V4L2_MEMORY_MMAP &&
req->memory != V4L2_MEMORY_USERPTR  &&
req->memory != V4L2_MEMORY_OVERLAY) {
@@ -414,6 +411,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
goto done;
}
 
+   if (req->count == 0) {
+   __videobuf_streamoff(q);
+   retval = 0;
+   goto done;
+   }
+
if (q->streaming) {
dprintk(1, "reqbufs: streaming already exists\n");
retval = -EBUSY;
-- 
1.6.4.2



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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] add missing 'p' at card name 'Hauppauge HD PVR'

[Lars Hanisch]

I don't know if there are applications which rely on this name,
but after all it's a spelling mistake.

Signed-off-by: Lars Hanisch 
---
 drivers/media/video/hdpvr/hdpvr-video.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/hdpvr/hdpvr-video.c 
b/drivers/media/video/hdpvr/hdpvr-video.c
index 1c49c07..196f82d 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -573,7 +573,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
struct hdpvr_device *dev = video_drvdata(file);

strcpy(cap->driver, "hdpvr");
-   strcpy(cap->card, "Haupauge HD PVR");
+   strcpy(cap->card, "Hauppauge HD PVR");
usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info));
cap->version = HDPVR_VERSION;
cap->capabilities = V4L2_CAP_VIDEO_CAPTURE |
--
1.6.3.3
--
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