XC5000 improvements: call for testers!

[Devin Heitmueller]

Hello all,

I'm happy to announce that there have been some considerable
improvements to the xc5000 driver, and I am looking for people with
xc5000 based devices to test:

== Noteworthy changes ==

* Power management is now properly supported - no more sucking up your
laptop battery and burning your fingers on the tuner's f-connector
when the device is idle (can be disabled with the "no_poweroff"
modprobe option).

* Faster tuning - average 10x improvement in time to lock.  Average
lock time now around 350ms, down from 3200ms.  No more multi-second
delays when trying to channel surf in tvtime.

* Redistributable firmware - Xceive has graciously allowed us to
redistribute the firmware and bundle it in the distros.  No more need
for users to manually extract the blob from the Hauppauge Windows
driver.

* Various fixes to bridges and dvb core found during power management testing.

* Support for DVB-T tuning, thanks to David T.L. Wong 

To test the code, clone from the following hg repository:

http://linuxtv.org/hg/~dheitmueller/xc5000-improvements-beta/

Unfortunately, current users are going to have to upgrade to the new
firmware.  However, this is a one time cost and I will work with the
distros to get it bundled so that users won't have to do this in the
future:

http://www.devinheitmueller.com/xc5000/dvb-fe-xc5000-1.6.114.fw
http://www.devinheitmueller.com/xc5000/README.xc5000

Thanks go out to Xceive for providing access to the xc5000
specification, reference driver code, and firmware under the
appropriate license.  Thanks also go out to Michael Krufky for his
considerable effort in helping test/debug different xc5000 hardware.

I look forward to hearing back from testers with any problems they may
encounter.  Now is the time to bring these up before it gets merged
into the mainline.

Thanks,

Devin

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

Re: [PULL] http://linuxtv.org/hg/~stoth/tda10048

[Mike Isely]

Nice catch.  Thanks.

  -Mike


On Tue, 5 May 2009, Steven Toth wrote:

> In addition to this:
> 
> Please pull from http://www.linuxtv.org/hg/~stoth/tda10048
> 
>-  tda10048: Added option to block i2c gate control from other drivers.
>-  pvrusb2: Ensure the PVRUSB2 disabled the i2c gate on the tda10048.
> 
>  dvb/frontends/tda10048.c|  222 +++-
>  dvb/frontends/tda10048.h|   17 +
>  video/cx23885/cx23885-dvb.c |4
>  video/pvrusb2/pvrusb2-devattr.c |3
>  4 files changed, 244 insertions(+), 2 deletions(-)
> 
> This fixes a bug in the current PVRUSB2 tree where DVB-T is not working due
> to multiple repeaters upsteam of the tuner on the same i2c bus.
> 
> - Steve
> 
> Steven Toth wrote:
> > Mauro,
> > 
> > Please pull from http://www.linuxtv.org/hg/~stoth/tda10048
> > 
> >-  tda10048: Add ability to select I/F at attach time.
> >-  cx23885: For tda10048 boards ensure we specify the I/F
> >-  pvrusb2: Ensure we specify the I/F at attach time.
> > 
> >  dvb/frontends/tda10048.c|  219 +++-
> >  dvb/frontends/tda10048.h|   14 +
> >  video/cx23885/cx23885-dvb.c |4
> >  video/pvrusb2/pvrusb2-devattr.c |2
> >  4 files changed, 237 insertions(+), 2 deletions(-)
> > 
> > The TDA10048 used to have a hard-coded I/F, I've improved this to support
> > different I/F's and ensured that all current bridge drivers specify their
> > needs.
> > 
> > Regards,
> > 
> > - Steve
> > 
> 
> 

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://linuxtv.org/hg/~awalls/cx18-av-core

[Andy Walls]

Mauro,

Please pull from http://linuxtv.org/hg/~awalls/cx18-av-core

for the following changeset:

01/01: cx18: Have audio decoder drive SIF gain control, and rework AFE config
http://linuxtv.org/hg/~awalls/cx18-av-core?cmd=changeset;node=9beb99150ab1


This change fixes consistently bad tuner audio.  (So far, three users
have reported positive test results.)

 cx18-av-core.c |  234 -
 1 file changed, 165 insertions(+), 69 deletions(-)


It turns out that the cx18 driver was setting up the CX23418 front-end
to perform SIF AGC based on the video decoder's assessment of signal
strength and not the audio decoder's assessment.  This caused the 1st
stage amplifier for SIF to overdrive the next stage of the processing
chain for SIF, causing very bad static for some users.

An analogous fix (turning off the AFE and Video PLL autoconifguration
and explicitly setting them up) may have to be done in the cx25840
module for the CX25840/1/2/3, CX23885, CX231xx, and CX25836/7.  I'll see
if such a change would fix the PVR-150 "tinny audio" problem first
though, before going through all that work.

BTW, it looks like the CX231xx module seems to be calling the cx25840
module with improper values to get the AFE mux routing set up.  The
cx231xx module copied the way the cx23885 driver was doing things, but
used enumeration values in the range that the ivtv driver uses. 


Regards,
Andy

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

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

[Andy Walls]

> > If you don't encode with PAL/M, then some TV sets won't work. Also, even
> > on TV sets that supports multiple standards, sometimes we need to
> > disable autodetection of NTSC, because this is broken on some TV sets.
> > I've personally experienced this trouble with two TV sets, including a
> > brand-new LCD1080p TV set I bought this year. On some conditions, if you
> > let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
> > changes to the other standard (missing the colors) for some seconds, and
> > then returns back. So, you have moments with colors and moments without.
> >
> > It should also be noticed that there are several devices (TV sets, DVD
> > players, etc) manufactured abroad that people assumes that PAL/M color
> > carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the
> > color carriers are somewhat different, this produces a very annoying
> > effect: the color image will present a static image as a image with
> > colors moving, since there will be a frequency shift between the
> > horizontal frequency rate and the pixel sampling rate (that are derived
> > from the color carrier on several decoders), causing color detection
> > misleading at the pixels. So, the pixels at the boundary of a shape have
> > their colors oscillating.
> 
> Very interesting. I honestly thought that all TVs everywhere (except
> perhaps very old ones) would be able to handle 'standard' PAL or NTSC on
> their Composite and S-Video inputs.

The difference between an NTSC-M system and PAL-M system is very slight:

http://www.pembers.freeserve.co.uk/World-TV-Standards/Transmission-Systems.html

since the 'M' determines most of the parameters.  The color burst on the
CVBS would be the only difference.  I can see how color burst could be
detected wrong on CVBS.  I'm not sure how the chroma baseband signal in
S-Video would get messed up though.

Regards,
Andy

> Chaithrika, can you take a look at this based on Mauro's input?
> 
> 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

Re: [linux-dvb] Can't scan transponders with Terratec Cinergy HT PCI board

[hermann pitton]

Am Montag, den 04.05.2009, 22:13 +0200 schrieb Charles:
> On Fri, May 1, 2009 at 2:26 AM, hermann pitton  
> wrote:
> > Hi Charles,
> >
> > Am Donnerstag, den 30.04.2009, 13:54 +0200 schrieb Charles:
> >> Hello,
> >>
> >>
> >> I installed my Terratec Cinergy HT PCI DVB-T board on Ubuntu 9.04
> >
> > I guess HT PCI can mean a lot, like My Cinema, WinFast and the like ...
> >
> >> using your tutorial
> >> (http://www.linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers)
> >> and when trying to scan transponders, no result was found:
> >>
> >> $ ls -l /dev/dvb/adapter0
> >> total 0
> >> crw-rw+ 1 root video 212, 1 2009-04-30 12:19 demux0
> >> crw-rw+ 1 root video 212, 2 2009-04-30 12:19 dvr0
> >> crw-rw+ 1 root video 212, 0 2009-04-30 12:19 frontend0
> >> crw-rw+ 1 root video 212, 3 2009-04-30 12:19 net0
> >>
> >> $ scan /usr/share/dvb/dvb-t/fr-Nantes
> >> scanning /usr/share/dvb/dvb-t/fr-Nantes
> >> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> >> initial transponder 49800 0 2 9 3 1 0 0
> >> initial transponder 50600 0 2 9 3 1 0 0
> >> initial transponder 52200 0 2 9 3 1 0 0
> >> initial transponder 53000 0 2 9 3 1 0 0
> >> initial transponder 65800 0 2 9 3 1 0 0
> >> initial transponder 80200 0 2 9 3 1 0 0
> >
> > Can't tell offhand if the zl10353 eventually has this problem too, which
> > is well known on the tda10046.
> >
> > Please try to add plus 167 kHz to your initial scan file for Nantes,
> > like you can see it here for one of the Lyon transmitters.
> >
[snip]

> 
> Hi Hermann,
> 
> Thank you. I added 167Khz to the scan file but it didn't solve my problem:
> 
> 
> $ scan /usr/share/dvb/dvb-t/fr-Nantes
> scanning /usr/share/dvb/dvb-t/fr-Nantes
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> initial transponder 498167000 0 2 9 3 1 0 0
> initial transponder 506167000 0 2 9 3 1 0 0
> initial transponder 522167000 0 2 9 3 1 0 0
> initial transponder 530167000 0 2 9 3 1 0 0
> initial transponder 658167000 0 2 9 3 1 0 0
> initial transponder 802167000 0 2 9 3 1 0 0
> >>> tune to: 
> >>> 498167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 498167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> >>>  (tuning failed)
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 506167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 506167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> >>>  (tuning failed)
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 522167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 522167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> >>>  (tuning failed)
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> >>>  (tuning failed)
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 658167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 658167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> >>>  (tuning failed)
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 802167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> WARNING: >>> tuning failed!!!
> >>> tune to: 
> >>> 802167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
> >>>  (tuning failed)
> WARNING: >>> tuning failed!!!
> ERROR: initial tuning failed
> dumping lists (0 services)
> Done.
> $
> 
> 
> Any other idea?

Not really.

Which HT PCI it is, copy/paste relevant parts of "dmesg".

If it is not a known issue with a certain card/driver,
I would assume the signal is too poor.

Cheers,
Hermann


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

Re: Hauppauge 950Q Analog (Composite Input) Problem

[John R.]

kenny wang wrote:

Hi, John

I am using exactly the same device, and several weeks ago Devin helped 
me make it work perfectly. I downloaded and compiled the newest codes 
from v4l mecurial, and simply use tvtime to play the video. But you need 
to use some other command to play sound:


Thanks.  Devin's response got me through the basic stuff I was missing. 
 Yours should help quite a bit in getting sound to work.  For anyone 
that is working with composite input, here is a sample invocation for 
video only:


mplayer tv:// -tv 
driver=v4l2:input=1:norm=ntsc:width=640:height=480:device=/dev/video0 -vo xv


John
--
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: saa7134/2.6.26 regression, noisy output

[hermann pitton]

Hi,

Am Montag, den 04.05.2009, 21:52 +0200 schrieb Anders Eriksson: 
> 
> Hi hermann,
> 
> hermann-pit...@arcor.de said:
> > There is no way to detect which sort of such a LNA circuitry is employed.
> > Just try and error and pray. Also no further documentation for the changing
> > code itself and only some comments by Hartmut on the lists.
> >
> > In case config = 1 gpio0 of the tda827x is involved, on others a gpio pin of
> > the saa7134 and some registers.
> >
> > It was already broken when tuner callback stuff for XCeive tuners was
> > introduced and firmware loading for those.
> >
> > Guess the problem is to get the gpio change to the tda827x through.
> >
> > Hartmut came up with this fix that time you get with "hg export 7393".
> > (attached)
> >
> > I did not even have any such a LNA device at this time, but might be
> > interesting if this snapshot really works for you. Still have only one type 
> > 2
> > device now.
> >
> > If I look through hg log > hg.log, the only somehow related later change by
> > Hartmut was this one. (link points to Hartmut's repo)
> >
> > http://linuxtv.org/hg/~hhackmann/v4l-dvb/rev/779169257208
> >
> > And last entry is that compile warning fix on top for int mask not removed 
> > at
> > once. Should all be only saa7134 gpio related.
>
> I had a look at the diff you attached, and it made me a bit confuse. Most 
> (all?) of it seem to be already applied in later kernels (>2.6.26), and they 
> all fail on me.

hmm, the idea eventually was, to download these two snapshots, or make
the last few changes manually on the first and try on 2.6.25.

Then we might know, if the problem is already visible within Hartmut's
latest fix attempts or even more and other stuff is involved.

"make rmmod" and save the original modules media folder.
Then "make" and "make install" and you get a new one.

The same way you can restore your old working media folder by putting it
back in place and "depmod -a".

You can click on top of the site on bz2 or gz to get such a snapshot. 
http://linuxtv.org/hg/v4l-dvb/rev/49ba58715fe0

> however, looking through the diff, I sumbled on the dprink's and I started to 
> enable them on all modules I thought relevant. Here's a diff between the last
> -good and first-bad commit. The salient differences I can see is the "AGC2 
> gain"
> and the "setting GPIO22 to vsync 0". I have no clue what they mean, but my 
> next step is to see if I can kill these differences.
> 
> Is thee anything else in there which you find note worthy?

-saa7133[0]/core: setting GPIO22 to vsync 0

This saa7133 GPIO22 setting is related to LNA configuration.

The code has changed, doesn't print the above anymore and became a tuner
callback. Maybe related.

> Rgds,
> /Anders
> PS What is the tda829x doing? I see some differences there too.

It is the analog demodulator within the saa7131e, controls the i2c gate
to the tda8275a silicon tuner and gpio0 on it is involved in type 1 LNA
control, according the comments. (details under NDA i don't have)

> 
> $ diff -u dmesg_2.6.25-03{6,7}* 
> --- dmesg_2.6.25-03622-g1fe873692009-05-04 21:32:37.0 +0200
> +++ dmesg_2.6.25-03774-g99e09ea 2009-05-04 21:37:06.0 +0200
> @@ -42,14 +42,13 @@
>  tda829x 1-004b: tda827xa config is 0x01
>  tda827x: setting tda827x to system xx
>  tda827x: setting LNA to high gain
> -saa7133[0]/core: setting GPIO22 to vsync 0
> -tda827x: AGC2 gain is: 3
> +tda827x: AGC2 gain is: 10
>  tda829x 1-004b: tda8290 not locked, no signal?
>  tda829x 1-004b: tda8290 not locked, no signal?
>  tda829x 1-004b: tda8290 not locked, no signal?
> -tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 0, lock: 0
> -tda829x 1-004b: adjust gain, step 2. Agc: 131, lock: 0
> -tda829x 1-004b: adjust gain, step 3. Agc: 44
> +tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 1, lock: 0
> +tda829x 1-004b: adjust gain, step 2. Agc: 255, lock: 0
> +tda829x 1-004b: adjust gain, step 3. Agc: 235
>  tuner' 1-004b: saa7133[0] tuner' I2C addr 0x96 with type 54 used for 0x0e
>  saa7133[0]/core: hwinit2
>  tuner' 1-004b: switching to v4l2
> @@ -58,8 +57,7 @@
>  tda829x 1-004b: tda827xa config is 0x01
>  tda827x: setting tda827x to system B
>  tda827x: setting LNA to high gain
> -saa7133[0]/core: setting GPIO22 to vsync 0
> -tda827x: AGC2 gain is: 3
> +tda827x: AGC2 gain is: 10
>  tda829x 1-004b: tda8290 not locked, no signal?
[snip]

Cheers,
Hermann


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

Re: [PULL] http://linuxtv.org/hg/~stoth/tda10048

[Steven Toth]

In addition to this:

Please pull from http://www.linuxtv.org/hg/~stoth/tda10048

   -  tda10048: Added option to block i2c gate control from other drivers.
   -  pvrusb2: Ensure the PVRUSB2 disabled the i2c gate on the tda10048.

 dvb/frontends/tda10048.c|  222 +++-
 dvb/frontends/tda10048.h|   17 +
 video/cx23885/cx23885-dvb.c |4
 video/pvrusb2/pvrusb2-devattr.c |3
 4 files changed, 244 insertions(+), 2 deletions(-)

This fixes a bug in the current PVRUSB2 tree where DVB-T is not working due
to multiple repeaters upsteam of the tuner on the same i2c bus.

- Steve

Steven Toth wrote:

Mauro,

Please pull from http://www.linuxtv.org/hg/~stoth/tda10048

   -  tda10048: Add ability to select I/F at attach time.
   -  cx23885: For tda10048 boards ensure we specify the I/F
   -  pvrusb2: Ensure we specify the I/F at attach time.

 dvb/frontends/tda10048.c|  219 +++-
 dvb/frontends/tda10048.h|   14 +
 video/cx23885/cx23885-dvb.c |4
 video/pvrusb2/pvrusb2-devattr.c |2
 4 files changed, 237 insertions(+), 2 deletions(-)

The TDA10048 used to have a hard-coded I/F, I've improved this to 
support different I/F's and ensured that all current bridge drivers 
specify their needs.


Regards,

- Steve



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

[PULL] http://linuxtv.org/hg/~stoth/tda10048

[Steven Toth]

Mauro,

Please pull from http://www.linuxtv.org/hg/~stoth/tda10048

   -  tda10048: Add ability to select I/F at attach time.
   -  cx23885: For tda10048 boards ensure we specify the I/F
   -  pvrusb2: Ensure we specify the I/F at attach time.

 dvb/frontends/tda10048.c|  219 +++-
 dvb/frontends/tda10048.h|   14 +
 video/cx23885/cx23885-dvb.c |4
 video/pvrusb2/pvrusb2-devattr.c |2
 4 files changed, 237 insertions(+), 2 deletions(-)

The TDA10048 used to have a hard-coded I/F, I've improved this to support 
different I/F's and ensured that all current bridge drivers specify their needs.


Regards,

- Steve
--
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 1/3] mm: introduce follow_pte()

[Johannes Weiner]

On Tue, May 05, 2009 at 02:05:17PM -0700, Andrew Morton wrote:
> On Tue, 5 May 2009 22:38:07 +0200
> Johannes Weiner  wrote:
> 
> > On Tue, May 05, 2009 at 12:24:42PM -0700, Andrew Morton wrote:
> > > On Mon,  4 May 2009 11:54:32 +0200
> > > Johannes Weiner  wrote:
> > > 
> > > > A generic readonly page table lookup helper to map an address space
> > > > and an address from it to a pte.
> > > 
> > > umm, OK.
> > > 
> > > Is there actually some point to these three patches?  If so, what is it?
> > 
> > Magnus needs to check for physical contiguity of a VMAs backing pages
> > to support zero-copy exportation of video data to userspace.
> > 
> > This series implements follow_pfn() so he can walk the VMA backing
> > pages and ensure their PFNs are in linear order.
> > 
> > [ This patch can be collapsed with 2/3, I just thought it would be
> >   easier to read the diffs when having them separate. ]
> > 
> > 1/3 and 2/3: factor out the page table walk from follow_phys() into
> > follow_pte().
> > 
> > 3/3: implement follow_pfn() on top of follow_pte().
> 
> So we could bundle these patches with Magnus's patchset, or we could
> consider these three patches as a cleanup or something.
>
> Given that 3/3 introduces an unused function, I'm inclined to sit tight
> and await Magnus's work.

Yeah, I didn't see the video guys responding on Magnus' patch yet, so
let's wait for them.

Magnus, the actual conversion of your code should be trivial, could
you respin it on top of these three patches using follow_pfn() then?

Thanks, Hannes
--
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 1/3] mm: introduce follow_pte()

[Andrew Morton]

On Tue, 5 May 2009 22:38:07 +0200
Johannes Weiner  wrote:

> On Tue, May 05, 2009 at 12:24:42PM -0700, Andrew Morton wrote:
> > On Mon,  4 May 2009 11:54:32 +0200
> > Johannes Weiner  wrote:
> > 
> > > A generic readonly page table lookup helper to map an address space
> > > and an address from it to a pte.
> > 
> > umm, OK.
> > 
> > Is there actually some point to these three patches?  If so, what is it?
> 
> Magnus needs to check for physical contiguity of a VMAs backing pages
> to support zero-copy exportation of video data to userspace.
> 
> This series implements follow_pfn() so he can walk the VMA backing
> pages and ensure their PFNs are in linear order.
> 
> [ This patch can be collapsed with 2/3, I just thought it would be
>   easier to read the diffs when having them separate. ]
> 
> 1/3 and 2/3: factor out the page table walk from follow_phys() into
> follow_pte().
> 
> 3/3: implement follow_pfn() on top of follow_pte().

So we could bundle these patches with Magnus's patchset, or we could
consider these three patches as a cleanup or something.

Given that 3/3 introduces an unused function, I'm inclined to sit tight
and await Magnus's work.

--
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 1/3] mm: introduce follow_pte()

[Johannes Weiner]

On Tue, May 05, 2009 at 12:24:42PM -0700, Andrew Morton wrote:
> On Mon,  4 May 2009 11:54:32 +0200
> Johannes Weiner  wrote:
> 
> > A generic readonly page table lookup helper to map an address space
> > and an address from it to a pte.
> 
> umm, OK.
> 
> Is there actually some point to these three patches?  If so, what is it?

Magnus needs to check for physical contiguity of a VMAs backing pages
to support zero-copy exportation of video data to userspace.

This series implements follow_pfn() so he can walk the VMA backing
pages and ensure their PFNs are in linear order.

[ This patch can be collapsed with 2/3, I just thought it would be
  easier to read the diffs when having them separate. ]

1/3 and 2/3: factor out the page table walk from follow_phys() into
follow_pte().

3/3: implement follow_pfn() on top of follow_pte().
--
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

saa7134-alsa and snd_card_new only error with alsa 1.0.19 / ubuntu 9.04 jaunty - tracked down, further help appreciated

[Lars Oliver Hansen]

Hello,

I'm getting exactly one error message in dmesg: saa7134_alsa: Unknown
symbol snd_card_new  which means I don't have any sound with analog tv.

I've tracked down the call to snd_card_new to the only location in
compat.h where it is called if #ifdef NEED_SND_CARD_CREATE is true. If
#ifdef NEED_SND_CARD_CREATE is true, there is also done an inclusion of
sound/core.h. Core.h is an alsa header which in the latest alsa 1.0.19
includes a definition of snd_card_new. However this definition is
missing in the sources that come with Ubuntu 9.04 Jaunty against which I
compiled the v4l-dvb sources (The saa7134-alsa error occurs with both my
compilation and did occur with the pre-compiled drivers which came with
9.04 Jaunty!).

Adding snd_card_new to the Ubuntu 9.04 sources was/is no good idea as it
calls its own snd_card_create from init.c which conflicts with
snd_card_create from compat.h which is the wrapper around snd_card_new
there.

As the call to snd_card_create in compat.h passes the identical argument
list as would be passed to init.c s snd_card_create later, I figured I
can add the declaration of snd_card_create to the core.h of the Ubuntu
9.04 sources which is/was missing too there as extern and disable the
snd_card_create in compat.h (compat.h includes core.h thus core.h s
extern snd_card_create should be called). As init.c does an
export_symbol of snd_card_create I guessed this could work.

So I would have instead of a wrapped call to a non-existant snd_card_new
a direct call to an exported snd_card_create.
Unfortunately I get this in dmesg now:

saa7134_alsa: no symbol version for snd_card_create
[ 4383.422044] saa7134_alsa: Unknown symbol snd_card_create

What can I do now?

Any help?

Thanks!


Best Regards

Lars

--
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 1/3] mm: introduce follow_pte()

[Andrew Morton]

On Mon,  4 May 2009 11:54:32 +0200
Johannes Weiner  wrote:

> A generic readonly page table lookup helper to map an address space
> and an address from it to a pte.

umm, OK.

Is there actually some point to these three patches?  If so, what is it?
--
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:Tue May  5 19:00:05 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11696:fe524e0a6412
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: OK
linux-2.6.28-armv5: OK
linux-2.6.29.1-armv5: OK
linux-2.6.30-rc4-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-rc4-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-rc4-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: OK
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-rc4-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-rc4-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-rc4-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-rc4-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: OK
linux-2.6.30-rc4-x86_64: WARNINGS
sparse (linux-2.6.29.1): OK
sparse (linux-2.6.30-rc4): 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: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: WARNINGS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: EC168 "dvb_usb: Unknown symbol release_firmware"

[drbob]

On Tue, 05 May 2009 15:41:58 +, drbob wrote:

> On Tue, 05 May 2009 13:47:49 +0300, Antti Palosaari wrote:
> 
> 
>> I haven't opened my stick but looked your pictures. I have never seen
>> so bad soldering quality :o
> 
> Yeah it's pretty bad. I was pretty surprised it works at all when I saw
> it as in several places component terminals or chip pins appear to be
> bridged.
> 
> 
>> Driver development is a little bit freeze currently due to lack of
>> EC168 specs. If you can provide specs please contact me!
>> 
>> 
> No specs here, I'm just an end user, but a translated google search
> (english->chinese) for "ec168 dvb" threw up this page:
> 
> 
> 
> 
> I think it's a company in China selling a reference design and tech
> support to potential manufacturers, so they probably have the tech docs.
> Good luck if you fancy trying to get a response from them.

After a little further digging I think the company that orignally 
designed the ec168 is probably defunct. I found a US address and contact 
number for the company here:



However the phone line has been disconnected. As per the wiki, their web 
page has also disappeared.


--
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: EC168 "dvb_usb: Unknown symbol release_firmware"

[drbob]

On Tue, 05 May 2009 13:47:49 +0300, Antti Palosaari wrote:

> 
> I haven't opened my stick but looked your pictures. I have never seen so
> bad soldering quality :o

Yeah it's pretty bad. I was pretty surprised it works at all when I saw 
it as in several places component terminals or chip pins appear to be 
bridged.

> 
> Driver development is a little bit freeze currently due to lack of EC168
> specs. If you can provide specs please contact me!
> 

No specs here, I'm just an end user, but a translated google search 
(english->chinese) for "ec168 dvb" threw up this page:




I think it's a company in China selling a reference design and tech 
support to potential manufacturers, so they probably have the tech 
docs. Good luck if you fancy trying to get a response from them.


--
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: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c

[Guennadi Liakhovetski]

On Tue, 5 May 2009, Agustin wrote:

> No, as there is no driver_match_device() in 2.6.29 nor in my patched 
> version. How important is that?

No, sorry, forget it, that's not your problem.

> Meanwhile I noticed that IRQ 176 is being triggered, then discarded as 
> "unhandled" by ipu_idmac, who gives the message "IRQ on active buffer on 
> channel 7, active 0, ready 0, 0, current 0!" below...

Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c 
idmac_interrupt() you'll see, that this message is printed when IDMAC 
produces an interrupt for a DMA buffer, but at the same time it says, that 
the buffer, that should have completed is still in use... I've seen a few 
of such inconsistencies, and up to now always managed to get rid of them 
in one or another way. But that should not be related to the conversion. 
Maybe your formats on the sensor and on the SoC do not match, verify that.

Thanks
Guennadi

> > > I am not sure where to look for the problem, so here is a debug dump in 
> > > case 
> > you can
> > > point me in the right direction...
> > > 
> > > 
> > > r...@sixcam:~ insmod sixcam.ko 
> > > sixcam_mod_init(): ok
> > > Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26
> > > sixcam_i2c_probe(): ok
> > > camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
> > > sixcam_init(): initialized camera.
> > > camera 0-0: MX3 Camera driver attached to camera 0
> > > sixcam_video_probe(): probed camera.
> > > mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00
> > > sixcam_release(): ok
> > > camera 0-0: MX3 Camera driver detached from camera 0
> > > 
> > > r...@sixcam:~ capture --bpp 8 --size 1536x1024
> > > mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> > > mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
> > > mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
> > > camera 0-0: soc_camera: Found 0 supported formats.
> > > mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> > > mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in 
> > > pass-through 
> > mode
> > > mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
> > > mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in 
> > > pass-through 
> > mode
> > > mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
> > > mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through 
> > > mode
> > > camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
> > > sixcam_init(): initialized camera.
> > > camera 0-0: MX3 Camera driver attached to camera 0
> > > camera 0-0: soc_camera: camera device open
> > > sixcam_set_fmt(): 640x480+0+0
> > > sixcam_try_fmt(): icd->width=640 icd->height=480 fmt.pix.width=1536 
> > fmt.pix.height=1024.
> > > --> fmt.pix.width=1536 fmt.pix.height=1024.
> > > ipu-core: ipu_idmac: timeout = 0 * 10ms
> > > ipu-core: ipu_idmac: init channel = 7
> > > ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, 
> > IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0
> > > ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 
> > > 0x0, 
> > TASKS_STAT 0x3
> > > dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176
> > > sixcam_set_fmt(): 1536x1024+0+0
> > > camera 0-0: soc_camera: set width: 1536 height: 1024
> > > mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> > > mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095
> > > sixcam_set_bus_param(): 0x2095
> > > mx3-camera.0: mx3_camera: Set SENS_CONF to 708
> > > VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: 
> > > soc_camera_reqbufs: 1
> > >  1024, pixelformat = 'GREY'
> > > mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free
> > > camera 0-0: soc_camera: mmap called, vma=0xc4f886e0
> > > mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper
> > > mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr 
> > > c900 
> > (size 1572864)
> > > mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 
> > > 40147000-402c7000 
> > (18) pgoff 00084000 buf 0
> > > mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 
> > [count=0,vma=40147000-402c7000]
> > > camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0
> > > mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP
> > > camera 0-0: soc_camera: soc_camera_streamon
> > > sixcam_start_capture(): trigger on!
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 
> > > 0x
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 
> > > 0x4000
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 
> > > 0x
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 
> > > 0xFF5FF000
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 
> > > 0x0003
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010078, data = 
> > > 0x8400
> > > ipu-core: ipu_idmac: write param mem - addr = 0x00010079, data = 
> > > 0x
> 

Re: Nova-T 500 does not survive reboot

[Eduard Huguet]

>> Hi,
>>Any news on this? I'd like to try the URB patch someone mentioned,
>> but I
>> can't find the link.
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg04643.html
>
> I am running a current dvb tree with this patch.
>
> so far so good.
>
> I did not find the time to check if I regained proper reboots, though. I
> know, sad excuse...
>
> nico
>
>

I'll give it a try. Thanks for the tip!
Cheers,
  Eduard
--
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: Nova-T 500 does not survive reboot

[Eduard Huguet]

Nicolas Will  youplala.net> writes:

> 
> Hello all,
> 
> I am running an hg clone from a few days ago with firmware 1.20 on a
> 64-bit Ubuntu Intrepid (2.6.27 kernel).
> 
> I have noticed that for some time now the card/driver/firmware
> combination does not like warm reboots.
> 
> If I reboot the system and try to use any Nova-T 500 tuner, I
> immediately get the mt2060 I2C errors.
> 
> If I completely shut down the system, remove the power, then reboot, all
> is fine.
> 
> I have missed most of the linux-media traffic, I was still stuck on
> linux-dvb. Have I missed some discussions about this?
> 
> Thanks!
> 
> Nico
> 

Hi, 
   Any news on this? I'd like to try the URB patch someone mentioned, but I
can't find the link.

Best regards, 
  Eduard




--
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://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

[chaithrika]

Hans,

> -Original Message-
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Tuesday, May 05, 2009 5:41 PM
> To: Mauro Carvalho Chehab
> Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; Chaithrika U S
> Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
> 
> Hi Mauro,
> 
> > Hans Verkuil escreveu:
> >> On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
> >>
> >>> On Sun, 19 Apr 2009 12:46:00 +0200
> >>> Hans Verkuil  wrote:
> >>>
> >>>
>  Hi Mauro,
> 
>  Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-
> davinci
>  for the
>  following:
> 
>  - v4l: TI THS7303 video amplifier driver code
> 
> >>> +static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id
> std)
> >>> +{
> >>> +   int err = 0;
> >>> +   u8 val;
> >>> +   struct i2c_client *client;
> >>> +
> >>> +   client = v4l2_get_subdevdata(sd);
> >>> +
> >>> +   if ((std & V4L2_STD_NTSC) || (std & V4L2_STD_PAL)) {
> >>> +   val = 0x02;
> >>> +   v4l2_dbg(1, debug, sd, "setting value for SDTV
> >>> format\n");
> >>> +   } else {
> >>> +   val = 0x00;
> >>> +   v4l2_dbg(1, debug, sd, "disabling all channels\n");
> >>> +   }
> >>> +
> >>>
> >>> Hmm... Are you sure that the above check is ok? The standards
> you're
> >>> allowing
> >>> are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like
> >>> PAL/N,
> >>> PAL/N', PAL/60, PAL/M will stay away.
> >>>
> >>> If what you want is all standards but SECAM, then the correct
> syntax
> >>> would be something like:
> >>>   if (std & (V4L2_STD_ALL & ~V4L2_STD_SECAM))
> >>>
> >>>
>  - Analog Devices ADV7343 video encoder driver
> 
> >>> +#define SD_STD_NTSC(0x00)
> >>> +#define SD_STD_PAL_BDGHI   (0x01)
> >>> +#define SD_STD_PAL_M   (0x02)
> >>> +#define SD_STD_PAL_N   (0x03)
> >>>
> >>> Hmm... from the comments at the beginning of the .c file, it seems
> that
> >>> the
> >>> hardware supports all standards but SECAM. The above register
> >>> definitions also
> >>> specifies PAL/M and PAL/M as supported standards.
> >>>
> >>> However, by looking at the std_into table:
> >>>
> >>> +static const struct adv7343_std_info
> >>> +   adv7343_composite_std_info[] = {
> >>> +   {
> >>> +   SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
> >>> +   },
> >>> +   {
> >>> +   SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A,
> V4L2_STD_PAL,
> >>> +   },
> >>> +};
> >>> +
> >>> +static const struct adv7343_std_info
> >>> +   adv7343_component_std_info[] = {
> >>> +   {
> >>> +   SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
> >>> +   },
> >>> +   {
> >>> +   SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21,
> V4L2_STD_PAL,
> >>> +   },
> >>> +};
> >>>
> >>> Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for
> both
> >>> PAL and
> >>> NTSC? This seems wrong to my eyes.
> >>>
> >>> Also, both tables have several supported standards missed.
> >>>
> >>
> >> Mauro,
> >>
> >> Are there TVs in Brazil that are unable to handle standard NTSC-M on
> the
> >> composite or S-Video inputs?
> > Yes. There are models that only handles PAL-M.
> >
> >> There are no encoders in v4l-dvb that do
> >> something special for PAL-M.
> >>
> > Maybe because nobody tested they and reported an issue? Before I
> started
> > working on this,
> > most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
> 
> To be fair, it is very hard to implement something you cannot test
> yourself, and most people can only test PAL/NTSC.
> 
> >> All just check against 525 vs 625 line standards.
> >> And I can't imagine that that will cause problems for Brazilian TVs.
> >>
> > If you don't encode with PAL/M, then some TV sets won't work. Also,
> even
> > on TV sets that supports multiple standards, sometimes we need to
> > disable autodetection of NTSC, because this is broken on some TV
> sets.
> > I've personally experienced this trouble with two TV sets, including
> a
> > brand-new LCD1080p TV set I bought this year. On some conditions, if
> you
> > let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
> > changes to the other standard (missing the colors) for some seconds,
> and
> > then returns back. So, you have moments with colors and moments
> without.
> >
> > It should also be noticed that there are several devices (TV sets,
> DVD
> > players, etc) manufactured abroad that people assumes that PAL/M
> color
> > carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since
> the
> > color carriers are somewhat different, this produces a very annoying
> > effect: the color image will present a static image as a image with
> > colors moving, since there will be a frequency shift between the
> > horizontal frequency rate and the pixel sampling rate (that are
> derived
> > from the color carrier on several decoders), caus

Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c

[Agustin]

On Tue, 5 May 2009, Guennadi Liakhovetski  wrote:
> 
> On Tue, 5 May 2009, Agustin wrote:
> 
> > 
> > Hi Guennadi,
> > 
> > --- Guennadi Liakhovetski wrote:
> > > On Mon, 13 Apr 2009, Agustin wrote:
> > > 
> > > > Which patchset should one use today to have latest and most stable 
> > > > "mx3_camera" driver in 2.6.29?
> > > > 
> > > > [snip]
> > > 
> > > Please, use http://marc.info/?l=linux-arm-kernel&m=123866462620240&w=2 
> > > also notice, which patches it needs. As a basis you can take linux-next 
> > > or 
> > > a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git
> > 
> > I managed to merge your patch stack of 20090415 on top of Sascha's stack 
> > for 
> 2.6.29.
> > I think that is just before the "v4l-subdev" work. Then I adapted my code 
> > to 
> work pretty
> > much as your mt9p031 driver.
> > 
> > Now I get a timeout when trying to capture a single image, with the same 
> hardware
> > configuration that is working fine with 2.6.28-next.
> > I can see my "Sixcam" camera dumping a few frames before the timeout.
> 
> Have you applied this patch:
> 
> Author: Ming Lei 
> Date:   Fri Mar 27 21:50:00 2009 +0800
> 
> driver core: fix driver_match_device
> 
> This patch fixes a bug introduced in commit
> 49b420a13ff95b449947181190b08367348e3e1b.
> 
> If a instance of bus_type doesn't have  .match method,
> all .probe of drivers in the bus should be called, or else
> the .probe have not a chance to be called.
> 
> Signed-off-by: Ming Lei 
> Reported-by: Guennadi Liakhovetski 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ?

No, as there is no driver_match_device() in 2.6.29 nor in my patched version. 
How important is that?

Meanwhile I noticed that IRQ 176 is being triggered, then discarded as 
"unhandled" by ipu_idmac, who gives the message "IRQ on active buffer on 
channel 7, active 0, ready 0, 0, current 0!" below...

> > 
> > I am not sure where to look for the problem, so here is a debug dump in 
> > case 
> you can
> > point me in the right direction...
> > 
> > 
> > r...@sixcam:~ insmod sixcam.ko 
> > sixcam_mod_init(): ok
> > Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26
> > sixcam_i2c_probe(): ok
> > camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
> > sixcam_init(): initialized camera.
> > camera 0-0: MX3 Camera driver attached to camera 0
> > sixcam_video_probe(): probed camera.
> > mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00
> > sixcam_release(): ok
> > camera 0-0: MX3 Camera driver detached from camera 0
> > 
> > r...@sixcam:~ capture --bpp 8 --size 1536x1024
> > mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> > mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
> > mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
> > camera 0-0: soc_camera: Found 0 supported formats.
> > mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> > mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through 
> mode
> > mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
> > mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in 
> > pass-through 
> mode
> > mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
> > mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through 
> > mode
> > camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
> > sixcam_init(): initialized camera.
> > camera 0-0: MX3 Camera driver attached to camera 0
> > camera 0-0: soc_camera: camera device open
> > sixcam_set_fmt(): 640x480+0+0
> > sixcam_try_fmt(): icd->width=640 icd->height=480 fmt.pix.width=1536 
> fmt.pix.height=1024.
> > --> fmt.pix.width=1536 fmt.pix.height=1024.
> > ipu-core: ipu_idmac: timeout = 0 * 10ms
> > ipu-core: ipu_idmac: init channel = 7
> > ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, 
> IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0
> > ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, 
> TASKS_STAT 0x3
> > dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176
> > sixcam_set_fmt(): 1536x1024+0+0
> > camera 0-0: soc_camera: set width: 1536 height: 1024
> > mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> > mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095
> > sixcam_set_bus_param(): 0x2095
> > mx3-camera.0: mx3_camera: Set SENS_CONF to 708
> > VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 
> > 1
> >  1024, pixelformat = 'GREY'
> > mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free
> > camera 0-0: soc_camera: mmap called, vma=0xc4f886e0
> > mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper
> > mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr 
> > c900 
> (size 1572864)
> > mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 
> > 40147000-402c7000 
> (18) pgoff 00084000 buf 0
> > mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 
> [count=0,vma=40147000-402c7000]
> > camera 0-0: soc_camera: vma sta

Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c

[Guennadi Liakhovetski]

On Tue, 5 May 2009, Agustin wrote:

> 
> Hi Guennadi,
> 
> --- Guennadi Liakhovetski  wrote:
> > On Mon, 13 Apr 2009, Agustin wrote:
> > 
> > > Which patchset should one use today to have latest and most stable 
> > > "mx3_camera" driver in 2.6.29?
> > > 
> > > [snip]
> > 
> > Please, use http://marc.info/?l=linux-arm-kernel&m=123866462620240&w=2 
> > also notice, which patches it needs. As a basis you can take linux-next or 
> > a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git
> 
> I managed to merge your patch stack of 20090415 on top of Sascha's stack for 
> 2.6.29.
> I think that is just before the "v4l-subdev" work. Then I adapted my code to 
> work pretty
> much as your mt9p031 driver.
> 
> Now I get a timeout when trying to capture a single image, with the same 
> hardware
> configuration that is working fine with 2.6.28-next.
> I can see my "Sixcam" camera dumping a few frames before the timeout.

Have you applied this patch:

Author: Ming Lei 
Date:   Fri Mar 27 21:50:00 2009 +0800

driver core: fix driver_match_device

This patch fixes a bug introduced in commit
49b420a13ff95b449947181190b08367348e3e1b.

If a instance of bus_type doesn't have  .match method,
all .probe of drivers in the bus should be called, or else
the .probe have not a chance to be called.

Signed-off-by: Ming Lei 
Reported-by: Guennadi Liakhovetski 
Signed-off-by: Greg Kroah-Hartman 

?

Thanks
Guennadi

> 
> I am not sure where to look for the problem, so here is a debug dump in case 
> you can
> point me in the right direction...
> 
> 
> r...@sixcam:~ insmod sixcam.ko 
> sixcam_mod_init(): ok
> Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26
> sixcam_i2c_probe(): ok
> camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
> sixcam_init(): initialized camera.
> camera 0-0: MX3 Camera driver attached to camera 0
> sixcam_video_probe(): probed camera.
> mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00
> sixcam_release(): ok
> camera 0-0: MX3 Camera driver detached from camera 0
> 
> r...@sixcam:~ capture --bpp 8 --size 1536x1024
> mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
> mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
> camera 0-0: soc_camera: Found 0 supported formats.
> mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through 
> mode
> mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
> mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through 
> mode
> mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
> mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode
> camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
> sixcam_init(): initialized camera.
> camera 0-0: MX3 Camera driver attached to camera 0
> camera 0-0: soc_camera: camera device open
> sixcam_set_fmt(): 640x480+0+0
> sixcam_try_fmt(): icd->width=640 icd->height=480 fmt.pix.width=1536 
> fmt.pix.height=1024.
> --> fmt.pix.width=1536 fmt.pix.height=1024.
> ipu-core: ipu_idmac: timeout = 0 * 10ms
> ipu-core: ipu_idmac: init channel = 7
> ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, 
> IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0
> ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, 
> TASKS_STAT 0x3
> dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176
> sixcam_set_fmt(): 1536x1024+0+0
> camera 0-0: soc_camera: set width: 1536 height: 1024
> mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
> mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095
> sixcam_set_bus_param(): 0x2095
> mx3-camera.0: mx3_camera: Set SENS_CONF to 708
> VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1
>  1024, pixelformat = 'GREY'
> mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free
> camera 0-0: soc_camera: mmap called, vma=0xc4f886e0
> mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper
> mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr 
> c900 (size 1572864)
> mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 
> 40147000-402c7000 (18) pgoff 00084000 buf 0
> mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 
> [count=0,vma=40147000-402c7000]
> camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0
> mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP
> camera 0-0: soc_camera: soc_camera_streamon
> sixcam_start_capture(): trigger on!
> ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 0x
> ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 0x4000
> ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 0x
> ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 0xFF5FF000
> ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 0x0003
> 

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

[Hans Verkuil]

Hi Mauro,

> Hans Verkuil escreveu:
>> On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
>>
>>> On Sun, 19 Apr 2009 12:46:00 +0200
>>> Hans Verkuil  wrote:
>>>
>>>
 Hi Mauro,

 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
 for the
 following:

 - v4l: TI THS7303 video amplifier driver code

>>> +static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
>>> +{
>>> +   int err = 0;
>>> +   u8 val;
>>> +   struct i2c_client *client;
>>> +
>>> +   client = v4l2_get_subdevdata(sd);
>>> +
>>> +   if ((std & V4L2_STD_NTSC) || (std & V4L2_STD_PAL)) {
>>> +   val = 0x02;
>>> +   v4l2_dbg(1, debug, sd, "setting value for SDTV
>>> format\n");
>>> +   } else {
>>> +   val = 0x00;
>>> +   v4l2_dbg(1, debug, sd, "disabling all channels\n");
>>> +   }
>>> +
>>>
>>> Hmm... Are you sure that the above check is ok? The standards you're
>>> allowing
>>> are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like
>>> PAL/N,
>>> PAL/N', PAL/60, PAL/M will stay away.
>>>
>>> If what you want is all standards but SECAM, then the correct syntax
>>> would be something like:
>>> if (std & (V4L2_STD_ALL & ~V4L2_STD_SECAM))
>>>
>>>
 - Analog Devices ADV7343 video encoder driver

>>> +#define SD_STD_NTSC(0x00)
>>> +#define SD_STD_PAL_BDGHI   (0x01)
>>> +#define SD_STD_PAL_M   (0x02)
>>> +#define SD_STD_PAL_N   (0x03)
>>>
>>> Hmm... from the comments at the beginning of the .c file, it seems that
>>> the
>>> hardware supports all standards but SECAM. The above register
>>> definitions also
>>> specifies PAL/M and PAL/M as supported standards.
>>>
>>> However, by looking at the std_into table:
>>>
>>> +static const struct adv7343_std_info
>>> +   adv7343_composite_std_info[] = {
>>> +   {
>>> +   SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
>>> +   },
>>> +   {
>>> +   SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
>>> +   },
>>> +};
>>> +
>>> +static const struct adv7343_std_info
>>> +   adv7343_component_std_info[] = {
>>> +   {
>>> +   SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
>>> +   },
>>> +   {
>>> +   SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
>>> +   },
>>> +};
>>>
>>> Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both
>>> PAL and
>>> NTSC? This seems wrong to my eyes.
>>>
>>> Also, both tables have several supported standards missed.
>>>
>>
>> Mauro,
>>
>> Are there TVs in Brazil that are unable to handle standard NTSC-M on the
>> composite or S-Video inputs?
> Yes. There are models that only handles PAL-M.
>
>> There are no encoders in v4l-dvb that do
>> something special for PAL-M.
>>
> Maybe because nobody tested they and reported an issue? Before I started
> working on this,
> most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...

To be fair, it is very hard to implement something you cannot test
yourself, and most people can only test PAL/NTSC.

>> All just check against 525 vs 625 line standards.
>> And I can't imagine that that will cause problems for Brazilian TVs.
>>
> If you don't encode with PAL/M, then some TV sets won't work. Also, even
> on TV sets that supports multiple standards, sometimes we need to
> disable autodetection of NTSC, because this is broken on some TV sets.
> I've personally experienced this trouble with two TV sets, including a
> brand-new LCD1080p TV set I bought this year. On some conditions, if you
> let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
> changes to the other standard (missing the colors) for some seconds, and
> then returns back. So, you have moments with colors and moments without.
>
> It should also be noticed that there are several devices (TV sets, DVD
> players, etc) manufactured abroad that people assumes that PAL/M color
> carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the
> color carriers are somewhat different, this produces a very annoying
> effect: the color image will present a static image as a image with
> colors moving, since there will be a frequency shift between the
> horizontal frequency rate and the pixel sampling rate (that are derived
> from the color carrier on several decoders), causing color detection
> misleading at the pixels. So, the pixels at the boundary of a shape have
> their colors oscillating.

Very interesting. I honestly thought that all TVs everywhere (except
perhaps very old ones) would be able to handle 'standard' PAL or NTSC on
their Composite and S-Video inputs.

>
>> I think these drivers should just use V4L2_STD_525_60 and
>> V4L2_STD_625_50,
>> just like saa7127 does.
>>
> I have no device here with saa7127, so I'm not sure how this works with
> other standards.

Currently it does only PAL and NTSC. Although it can do SECAM it is never
actu

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Laurent Pinchart]

Hi Hans,

On Saturday 02 May 2009 17:24:10 Hans Verkuil wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> following:
>
> - v4l-dvb: add missing DMA_BIT_MASK compat macro for kernels <2.6.24
> - ivtv: fix compiler warning.
> - uvc: fix compile warning
> - tuner: remove tuner_i2c_address_check
> - v4l2: add v4l2_device_set_name()
> - ivtv: use v4l2_device_set_name.
> - v4l2-device: unregister i2c_clients when unregistering the v4l2_device.
> - ivtv: fix incorrect bit tests
> - ivtv/radio: fix V4L2_TUNER_MODE/V4L2_TUNER_SUB confusion
> - radio-fm16: cleanups
> - radio-fm16: fix g_tuner.
> - v4l2-spec: fix V4L2_TUNER_MODE_STEREO doc.
>
> Note that there are a few high-prio fixes:
>
> - ivtv: fix compiler warning.
> - uvc: fix compile warning
> - ivtv: fix incorrect bit tests
> - ivtv/radio: fix V4L2_TUNER_MODE/V4L2_TUNER_SUB confusion
>
> These should go into 2.6.30.
>
> Laurent, I've CC-ed you due to the uvc change.

I should have applied the patch myself, sorry. I've been traveling a lot 
lately, hence the delay. Next time please send me a reminder, I would probably 
have done things a bit differently.

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

soc-camera: timing out during capture - Re: Testing latest mx3_camera.c

[Agustin]

Hi Guennadi,

--- Guennadi Liakhovetski  wrote:
> On Mon, 13 Apr 2009, Agustin wrote:
> 
> > Which patchset should one use today to have latest and most stable 
> > "mx3_camera" driver in 2.6.29?
> > 
> > [snip]
> 
> Please, use http://marc.info/?l=linux-arm-kernel&m=123866462620240&w=2 
> also notice, which patches it needs. As a basis you can take linux-next or 
> a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git

I managed to merge your patch stack of 20090415 on top of Sascha's stack for 
2.6.29.
I think that is just before the "v4l-subdev" work. Then I adapted my code to 
work pretty
much as your mt9p031 driver.

Now I get a timeout when trying to capture a single image, with the same 
hardware
configuration that is working fine with 2.6.28-next.
I can see my "Sixcam" camera dumping a few frames before the timeout.

I am not sure where to look for the problem, so here is a debug dump in case 
you can
point me in the right direction...


r...@sixcam:~ insmod sixcam.ko 
sixcam_mod_init(): ok
Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26
sixcam_i2c_probe(): ok
camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
sixcam_init(): initialized camera.
camera 0-0: MX3 Camera driver attached to camera 0
sixcam_video_probe(): probed camera.
mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00
sixcam_release(): ok
camera 0-0: MX3 Camera driver detached from camera 0

r...@sixcam:~ capture --bpp 8 --size 1536x1024
mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
camera 0-0: soc_camera: Found 0 supported formats.
mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode
mx3-camera.0: mx3_camera: requested bus width 15 bit: 0
mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through 
mode
mx3-camera.0: mx3_camera: requested bus width 10 bit: 0
mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode
camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897
sixcam_init(): initialized camera.
camera 0-0: MX3 Camera driver attached to camera 0
camera 0-0: soc_camera: camera device open
sixcam_set_fmt(): 640x480+0+0
sixcam_try_fmt(): icd->width=640 icd->height=480 fmt.pix.width=1536 
fmt.pix.height=1024.
--> fmt.pix.width=1536 fmt.pix.height=1024.
ipu-core: ipu_idmac: timeout = 0 * 10ms
ipu-core: ipu_idmac: init channel = 7
ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, 
IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0
ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, 
TASKS_STAT 0x3
dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176
sixcam_set_fmt(): 1536x1024+0+0
camera 0-0: soc_camera: set width: 1536 height: 1024
mx3-camera.0: mx3_camera: requested bus width 8 bit: 0
mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095
sixcam_set_bus_param(): 0x2095
mx3-camera.0: mx3_camera: Set SENS_CONF to 708
VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1
 1024, pixelformat = 'GREY'
mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free
camera 0-0: soc_camera: mmap called, vma=0xc4f886e0
mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper
mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 
(size 1572864)
mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 
(18) pgoff 00084000 buf 0
mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 
[count=0,vma=40147000-402c7000]
camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0
mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP
camera 0-0: soc_camera: soc_camera_streamon
sixcam_start_capture(): trigger on!
ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 0x
ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 0x4000
ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 0x
ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 0xFF5FF000
ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 0x0003
ipu-core: ipu_idmac: write param mem - addr = 0x00010078, data = 0x8400
ipu-core: ipu_idmac: write param mem - addr = 0x00010079, data = 0x
ipu-core: ipu_idmac: write param mem - addr = 0x0001007A, data = 0x3E0E2FFB
ipu-core: ipu_idmac: write param mem - addr = 0x0001007B, data = 0x0002
ipu-core: ipu_idmac: write param mem - addr = 0x0001007C, data = 0x
dma dma0chan7: ipu_idmac: Submitting sg c4e0772c
dma dma0chan7: ipu_idmac: Updated sg c4e0772c on channel 0x7 buffer 0
ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, 
IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0
ipu-core: ipu_idmac: BUF0_RDY 0x80, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, 
TASKS_STAT 0x3
ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x4001, 

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

[Mauro Carvalho Chehab]

Manu Abraham escreveu:

Mauro,

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

Supports newer silicon cuts, also catches more errors.

Regards,
Manu
  

Applied, thanks.

It generated one warning here:

/home/v4l/master/v4l/stv090x.c: In function 'stv090x_optimize_track':
/home/v4l/master/v4l/stv090x.c:3408: warning: 'short_crl' may be used 
uninitialized in this function



Could you please fix?

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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

[Mauro Carvalho Chehab]

Hans Verkuil escreveu:

On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
  

On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil  wrote:



Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the 
following:


- v4l: TI THS7303 video amplifier driver code
  

+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+   int err = 0;
+   u8 val;
+   struct i2c_client *client;
+
+   client = v4l2_get_subdevdata(sd);
+
+   if ((std & V4L2_STD_NTSC) || (std & V4L2_STD_PAL)) {
+   val = 0x02;
+   v4l2_dbg(1, debug, sd, "setting value for SDTV format\n");
+   } else {
+   val = 0x00;
+   v4l2_dbg(1, debug, sd, "disabling all channels\n");
+   }
+

Hmm... Are you sure that the above check is ok? The standards you're allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like PAL/N,
PAL/N', PAL/60, PAL/M will stay away.

If what you want is all standards but SECAM, then the correct syntax would be 
something like:
if (std & (V4L2_STD_ALL & ~V4L2_STD_SECAM))



- Analog Devices ADV7343 video encoder driver
  

+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI   (0x01)
+#define SD_STD_PAL_M   (0x02)
+#define SD_STD_PAL_N   (0x03)

Hmm... from the comments at the beginning of the .c file, it seems that the
hardware supports all standards but SECAM. The above register definitions also
specifies PAL/M and PAL/M as supported standards. 


However, by looking at the std_into table:

+static const struct adv7343_std_info
+   adv7343_composite_std_info[] = {
+   {
+   SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+   },
+   {
+   SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+   },
+};
+
+static const struct adv7343_std_info
+   adv7343_component_std_info[] = {
+   {
+   SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+   },
+   {
+   SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+   },
+};

Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both PAL and
NTSC? This seems wrong to my eyes.

Also, both tables have several supported standards missed.



Mauro,

Are there TVs in Brazil that are unable to handle standard NTSC-M on the
composite or S-Video inputs? 

Yes. There are models that only handles PAL-M.


There are no encoders in v4l-dvb that do
something special for PAL-M. 
  
Maybe because nobody tested they and reported an issue? Before I started 
working on this,

most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...

All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
  
If you don't encode with PAL/M, then some TV sets won't work. Also, even 
on TV sets that supports multiple standards, sometimes we need to 
disable autodetection of NTSC, because this is broken on some TV sets. 
I've personally experienced this trouble with two TV sets, including a 
brand-new LCD1080p TV set I bought this year. On some conditions, if you 
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and 
changes to the other standard (missing the colors) for some seconds, and 
then returns back. So, you have moments with colors and moments without.


It should also be noticed that there are several devices (TV sets, DVD 
players, etc) manufactured abroad that people assumes that PAL/M color 
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the 
color carriers are somewhat different, this produces a very annoying 
effect: the color image will present a static image as a image with 
colors moving, since there will be a frequency shift between the 
horizontal frequency rate and the pixel sampling rate (that are derived 
from the color carrier on several decoders), causing color detection 
misleading at the pixels. So, the pixels at the boundary of a shape have 
their colors oscillating.



I think these drivers should just use V4L2_STD_525_60 and V4L2_STD_625_50,
just like saa7127 does.
  
I have no device here with saa7127, so I'm not sure how this works with 
other standards. But, expecially on encoding, you should be able to 
produce the right standard. I can't see it producing a right standard if 
you just use V4L2_STD_525_60 and V4L2_STD_625_50 with s-video.  At least 
on one place, you should say to the encoder what should be the color 
carrier frequency and if it will encode with PAL, NTSC or SECAM.



By the way, what's the rationale of not allowing the driver to encode on 
all supported formats?



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

[PATCH] libv4l: spca508 UV inversion

[Jean-Francois Moine]

Hello Hans,

People with a spca508 webcam report a color inversion in the images.
Here is a simple patch to fix this problem.

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/


patch.pat
Description: Binary data

Re: [PATCH] videobuf-dma-contig: remove sync operation

[Matthieu CASTET]

Paul Mundt a écrit :
> On Tue, Apr 28, 2009 at 05:45:39PM +0900, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Remove the videobuf-dma-contig sync operation. Sync is only needed
>> for noncoherent buffers, and since videobuf-dma-contig is built on
>> coherent memory allocators the memory is by definition always in sync.
>>
> Note that this also fixes a bogus oops, which is what caused this to be
> brought up in the first place..
> 
>> Reported-by: Matthieu CASTET 
>> Signed-off-by: Magnus Damm 
>> ---
>>
>>  Thanks to Mattieu, Paul and Paulius for all the help!
>>  Tested on SH7722 Migo-R with CEU and ov7725.
>>
>>  drivers/media/video/videobuf-dma-contig.c |   14 --
>>  1 file changed, 14 deletions(-)
>>
> Reviewed-by: Paul Mundt 
Test-by : Matthieu CASTET 

Well I backport it on a older kernel (2.6.27), but the result should be
the same.
--
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