Re: [linux-dvb] ndiswrapper for dvb drivers?

2011-04-18 Thread hermann pitton

Am Freitag, den 08.04.2011, 11:22 +0200 schrieb pigeonskil...@libero.it:
 Good day to you all.
  My question is simple:
  it would be possible to write a program like ndiswrapper for dvb drivers?
  Just think: only a small initial effort to write a program that can use 
 hundreds of  DVB drivers taken from the Windows world...
 

Hi,

I'm going through mail backlash again.

Arrgh, what a not aware of anything major BS.

Either you have the not yet public driver details, than you can write
wrappers, please then do so.

Not the preferred solution.

Or you ask people still hacking on some stuff, why the damned hell some
those idiots still try to hack it ...

Patches are welcome.

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: [linux-dvb] Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857

2011-03-19 Thread hermann-pitton
 
Hi Jason,

 Hi Hermann,
 
  Hopefully it does help in that other case.

that one really counts now.

 I have it working now.  I had to add a delay of 120 seconds in the
 mythtv backend script to allow the driver enough time to scan both
 cards and install the firmware properly.  Previously the mythtv
 backend at startup was trying to talk to the cards before the firmware
 was loaded and so they'd fail to work.
 
 It's not a big hassle but it would seem in spite of a test in the
 startup script to ensure udev configuration was complete before
 mythbackend was loaded it would seem that udev device configuration

Sorry, no time yet to dig into it further, but I seem to hear some faint noise.

How sure you are to have original eeprom content on your card ?

Some bill, original packing material or similar?

On some first impression, l doubt we deal with something it claims to be.

Cheers,
Hermann










 was completing before the firmware was loaded.
 
 Is there the possibility of adding some feature into the driver to
 make sure it fails on opening if the firmware isn't properly loaded?
 
 Another general question, does V4L sequentially initialise hardware or
 does it run in parallel?  It would seem to be a good time saver to
 have all DVB cards initialised in parallel to speed up booting of a
 system.
 
 I have reverted back to Mythbuntu 10.04 and kernel 2.6.32 and the
 cards work fine now (though with the latest v29 of the firmware for
 these cards).
 
 Cheers
 Jason
 
--
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] Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857

2011-03-17 Thread hermann pitton
Hi Jason,

Am Samstag, den 12.03.2011, 10:43 +1100 schrieb Jason Hecker:
 I just bought a pair of what are a version of the My Cinema 7131
 Hybrid cards.
 
 The kernel reports it as saa7134: Asus Tiger revision 1.0, subsys
 1043:4857 
 
 I did inititially try Mythbuntu 10.04 but the firmware upload seemed
 to fail fairly consistently.  Restarting with v10.10 the firmware
 loads but I can't seem to scan the channels with Mythbackend - it has
 a 0% signal and 100% signal to noise.  I am using MythTV 0.24 with
 Avenard's latest patches.
 
 This version of the card has written on the silkscreen Tiger rev 3.02,
 a sticker that says Tiger_8M AA.F7.C0.01 (which would appear to be the
 latest firmware for this card on Asus's support site) but there is
 only one RF connector on CON1.  CON2 is not fitted nor is the IR
 receiver.  Now I saw mentioned on a list that to get DVB working on
 this card in Linux you need to connect the TV antenna to the FM port,
 which I suspect is the one not fitted.  The latest Windows drivers for
 this card is circa 2009.
 
 Two questions:
 - Is there some sort of SAA7134 module argument I need to use to get
 the card working on the TV RF input?
 - Why does the kernel show the firmware is being reloaded every time
 MythTV seems to want to talk to the card?  This slows down access as
 it seems to take about 30 seconds for the firmware to install each
 time.
 
 I am happy to provide whatever debug dumps or more info if need be.
 

this hits me only by accident, reading through backlash, but I added
that Asus Tiger Revision 1.0 with subsys 1043:4857, with a huge delay
only. (approximately 1 1/2 years)

The development and testing for the new tuner types was done only much
later on freely available stuff, a so called Asus Dual _non_ OEM
variant.

Not to tell what we did all see thereafter, but that all was at least,
with only one exception, valid using the PCI subsystem as unique
identifier.

Luckily, as far as I can see, we have only a fictional radio device on
your new variant left over.

This can still be very annoying, but won't do any harm, except wasting a
users time, bad enough, but at least not any radiation from that sort of
radio flaw.

Since the PCI subsystem is identical with mine, still around somewhere,
with radio support, either take that dead radio device for now or a last
chance is to discover, if any eeprom differences are there to eventually
filter that minor, but unpleasant shortcoming for those trying in vain
on the radio.

Cheers,
Hermann

To restore the power on a failing power plant in urgent need of it seems
to be a good idea, after six or seven days ...

All my excuses for the failing radio device on that not yet seen OEM
stuff, but I can ensure, to piss on it doesn't help any further.

Hopefully it does help in that other case.





--
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] support of GoTView PCI-E X5 3D Hybrid in cx23885

2010-12-06 Thread hermann pitton
Hi guys,

Am Sonntag, den 05.12.2010, 13:22 -0500 schrieb Devin Heitmueller:
 On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov 4er...@gmail.com wrote:
  Hello, Steve,
  thank you very much for your comments!
 
  As for DVB maybe I'm not correct. The initialization itself, which the DVB
  part of patch is about, is fully tested by me and works successfully on my
  everyday PC. The thing I meant saying 'untested' concerned receiving DVB
  signal through the initialized device.
 
  So I think I was mistaken that the code itself is untested. I hope it's
  possible to add full of this patch.
 
 Hello Alexey,
 
 What I believe Steven is trying to say is the device successfully
 initializing is not enough to consider the DVB part of the driver to
 be working.  If you have not seen the device receiving digital
 television, the DVB parts of this patch should not be committed.
 
 There are a variety of other reasons why DVB streaming would not work
 even if the device properly initializes.  These can include an
 improperly configured IF, wrong GPIOs, missing power management code,
 etc.
 
 It is far worse for a user to be led to believe the driver should be
 working but doesn't then it is for the driver claim to not work with
 DVB at all.  This is how we end up with users wasting hours wondering
 what is wrong with their MythTV setup when in fact the driver never
 actually worked in the first place.
 
 Find someone to test the DVB parts of the board that it shows DVB
 streaming.  If you cannot do that, remove those parts from the patch
 until someone can be found who is able to test the functionality.
 
 Devin
 

Devin and Steven are totally right.

There should not be any untested hardware functionality enabled.

I have spend countless time, zillions of emails, often even years after
the initial support for a new device was enabled, to hunt down what
people did really test and what was only copy/paste from a previous card
entry.

Never add untested stuff !

We agreed, years ago, that even in a case we can likely expect a
standard behavior on some new hardware, given the expertise of someone
who might have seen maybe hundreds of similar devices previously, only
#if 0 for the untested stuff is allowed.

Even if we have muxes, gpios etc, we can take from windows drivers, .inf
files or regspy.exe/DScaler for example, it is still not really safe to
enable such untested inputs and leave only a comment in the code like
untested, taken from the .inf or so.

PCI cards for example, with the same subvendor and subdevice ID, can
have never ending new revisions, changing almost everything they started
with on the first revision for _multiple_ times.

Audio and video muxes, all sort of gpio controls from all sort of chips
on the board, the AGC, the LNA type, the i2c gate, the IR support ...

All you can imagine and more really happens concerning hardware, and we
have cases where even eeprom decoding doesn't help and some unknown
vendor specific checksums come into the game.

We still are in need of full hardware documentation, down to the
smallest chip and any line on the PCB, and do miss it.

And overall this is improved by more and more hidden devices in products
with a seal stating, if broken any warranty is gone, and soldered RF
shielding over the relevant parts, hardly to remove without breaking the
device.

Never add untested stuff.

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: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)

2010-11-25 Thread hermann pitton
Hi,

Am Donnerstag, den 25.11.2010, 00:56 -0500 schrieb Hooman B.:
 Thanks,
 
 I see the drivers for both TDA18271HDC2 and TDA8290 loaded.
 I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is
 the digital channel decoder different from the digital tuner??
 Should be looking for a different chip?

they are detected by chip IDs.

The tda8290 is the IF demodulator for global analog TV.
In case of the saa7135 it is an extra chip on the PCB, which most often
can also control the tuner over an i2c gate.

The tda18271hdc2 is a global hybrid tuner for analog and digital
terrestrial TV. It can also provide a FM radio IF. Further processing
and stereo separation for that is done on capable bridges like
saa7133/35/31e, not on the tda 8290.

Yes, for any terrestrial digital TV you need an extra channel decoder
and all known details about it.

http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards

In case of terrestrial ATSC, it must be able to deal with 8VSB
modulation.

IIRC, on the saa713x we have that tuner only in combination with the
tda10048 and DVB-T for now, but other combinations seem to be already
around.

Hermann

 Based on these to chips, I added my card in  saa7134_tda8290_callback
 to call saa7134_tda8290_18271_callback and here is the output of my
 dmesg:
 [  828.879454] dvb_init() allocating 1 frontend
 [  829.180234] nxt200x: nxt200x_readbytes: i2c read error (addr 0x0a, err == 
 -5)
 [  829.180244] Unknown/Unsupported NXT chip: 00 00 00 00 00
 [  829.180542] saa7133[0]/dvb: frontend initialization failed
 
 Hooman
 
 On Wed, Nov 24, 2010 at 7:21 PM, hermann pitton hermann-pit...@arcor.de 
 wrote:
 
  Hi,
 
  Am Dienstag, den 23.11.2010, 17:34 -0500 schrieb Hooman B.:
  Hello!
  I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid
  ATSC (17de:a134)
  to work with the latest v4l drivers from source (in Ubuntu).
 
  Right now, everything [capture, analog, radio, even IR] works - except
  the ATSC tuner (there is no
  front-end device). But that's the one thing I need working :-(
 
  OK.
 
  Here's the output of lspci -nnvv
  
  03:01.0 Multimedia controller [0480]: Philips Semiconductors
  SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
  Subsystem: KWorld Computer Co. Ltd. Device [17de:a134]
  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
  Stepping- SERR- FastB2B- DisINTx-
  Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
  TAbort- MAbort- SERR- PERR- INTx-
  Latency: 255 (63750ns min, 63750ns max)
  Interrupt: pin A routed to IRQ 16
  Region 0: Memory at fdaff000 (32-bit, non-prefetchable) [size=2K]
  Capabilities: access denied
  Kernel driver in use: saa7134
  Kernel modules: saa7134
  
 
  This is the most similar card that I forced in saa7134-cards.c:
  
  .vendor   = PCI_VENDOR_ID_PHILIPS,
  .device   = PCI_DEVICE_ID_PHILIPS_SAA7133,
  .subvendor= 0x17de,
  .subdevice= 0xa134,
  .driver_data  = SAA7134_BOARD_MSI_TVATANYWHERE_PLUS,
  
 
  The chips are : SAA7135HL/203 and TDA18271HDC2
 
 
  Both variants of the MSI t...@nywhere Plus do not have any support for
  digital TV.
 
  You need to find out the type of digital channel decoder on your board
  at first.
 
  Then you check saa7134-dvb.c, if it is already supported on other cards.
 
  You have to investigate the details of how the channel decoder is
  employed, but with some luck can try with already supported cards.
 
  If i2c traffic locks up and chips disappear from the bus, a cold boot
  might be necessary to continue with testing.
 
  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: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)

2010-11-24 Thread hermann pitton

Hi,

Am Dienstag, den 23.11.2010, 17:34 -0500 schrieb Hooman B.:
 Hello!
 I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid
 ATSC (17de:a134)
 to work with the latest v4l drivers from source (in Ubuntu).
 
 Right now, everything [capture, analog, radio, even IR] works - except
 the ATSC tuner (there is no
 front-end device). But that's the one thing I need working :-(

OK.

 Here's the output of lspci -nnvv
 
 03:01.0 Multimedia controller [0480]: Philips Semiconductors
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
 Subsystem: KWorld Computer Co. Ltd. Device [17de:a134]
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 255 (63750ns min, 63750ns max)
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at fdaff000 (32-bit, non-prefetchable) [size=2K]
 Capabilities: access denied
 Kernel driver in use: saa7134
 Kernel modules: saa7134
 
 
 This is the most similar card that I forced in saa7134-cards.c:
 
 .vendor   = PCI_VENDOR_ID_PHILIPS,
 .device   = PCI_DEVICE_ID_PHILIPS_SAA7133,
 .subvendor= 0x17de,
 .subdevice= 0xa134,
 .driver_data  = SAA7134_BOARD_MSI_TVATANYWHERE_PLUS,
 
 
 The chips are : SAA7135HL/203 and TDA18271HDC2
 

Both variants of the MSI t...@nywhere Plus do not have any support for
digital TV.

You need to find out the type of digital channel decoder on your board
at first.

Then you check saa7134-dvb.c, if it is already supported on other cards.

You have to investigate the details of how the channel decoder is
employed, but with some luck can try with already supported cards.

If i2c traffic locks up and chips disappear from the bus, a cold boot
might be necessary to continue with testing.

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: Problem with Compro T200 (TDA1004x) and tuning Hi

2010-11-24 Thread hermann pitton
Hi Mike,

Am Dienstag, den 23.11.2010, 13:36 + schrieb Mike Martin: 
 On 22 November 2010 19:43, hermann pitton hermann-pit...@arcor.de wrote:
 
  Am Montag, den 22.11.2010, 15:08 + schrieb Mike Martin:
  On 22 November 2010 06:08, hermann pitton hermann-pit...@arcor.de wrote:
   Hi Mike,
  
   Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin:
   I am trying to tune channels with this card (which seems to be
   installed OK). However the output is
  
   Using DVB card Philips TDA10046H DVB-T
   tuning DVB-T (in United Kingdom) to 497833000 Hz
   polling
   Getting frontend event
   FE_STATUS:
   polling
   polling
   polling
  
  
   usually, in the UK, this can be caused by the missing ability to detect
   some frequencies offsets by the tda10046.
  
   Since you have already a minus of 167000Hz, typically for the UK, in
   your initial scan/tuning file, this most common problem likely can be
   excluded.
  
   So there are eventually three variants causing the problem on a first
   idea.
  
   1. They changed to 498 MHz. (or did change something else too, auto
 is your friend in the initial scan file then, except for the freq.)
  
 
  tried that no difference
   2. Your overall signal is not good enough.
  
  well up until friday I was using a HVR900, until it decided to refuse
  to believe it was plugged into a USB2 bus, and it was working fine
 
   3. You sit on some kernel with some bug.
 
  [...]
 
  Well, it is still very easy to install the latest remaining v4l-dvb from
  hg/mercurial for a quick test too.
 
  I don't have your hardware, but all my stuff is still fine there so far.
 
  AFAIR, your device, added by Hartmut, has some sort of TD1316 without an
  extra tda9887 IF demodulator for analog reception soldered outside of
  the tuner on the PCB.
 
  However, it is in a loop for eeprom auto detection on the side of the
  bridge.
 
  If that fails, and for my experience four of five attempts to fiddle
  with that later did fail, you don't have a chance for any DVB either.
 
  You might have to force the card number in such a case, but I'm still
  far away from what might be going on and your report is without any
  details so far.
 
  Cheers,
  Hermann
 
 
 
 One problem is the last time I used it - it worked. Although that was
 in a different location/PC

yup, I know too it did work for years.

 Current system P4 Fedora 14, stock kernel
 
 output scandvb
 
 scanning uk-Aberdare_auto
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 initial transponder 474167000 3 9 9 6 2 4 4
 initial transponder 482167000 3 9 9 6 2 4 4
 initial transponder 497833000 3 9 9 6 2 4 4
 initial transponder 506167000 3 9 9 6 2 4 4
 initial transponder 521833000 0 2 9 3 0 0 0
 initial transponder 530167000 0 2 9 3 0 0 0
  tune to: 
  474167000:INVERSION_AUTO:BANDWIDTH_AUTO:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
 WARNING:  tuning failed!!!

One thing I forgot about, you might have to force the bandwidth too.

If that still fails, you might be on the road for bisecting through the
previous patches.

I can't even tell, how reliable bisecting can work currently.

However, it might be worth to test with the remaining v4l-dvb mercurial
code as a start.

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: Problem with Compro T200 (TDA1004x) and tuning Hi

2010-11-22 Thread hermann pitton

Am Montag, den 22.11.2010, 15:08 + schrieb Mike Martin:
 On 22 November 2010 06:08, hermann pitton hermann-pit...@arcor.de wrote:
  Hi Mike,
 
  Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin:
  I am trying to tune channels with this card (which seems to be
  installed OK). However the output is
 
  Using DVB card Philips TDA10046H DVB-T
  tuning DVB-T (in United Kingdom) to 497833000 Hz
  polling
  Getting frontend event
  FE_STATUS:
  polling
  polling
  polling
 
 
  usually, in the UK, this can be caused by the missing ability to detect
  some frequencies offsets by the tda10046.
 
  Since you have already a minus of 167000Hz, typically for the UK, in
  your initial scan/tuning file, this most common problem likely can be
  excluded.
 
  So there are eventually three variants causing the problem on a first
  idea.
 
  1. They changed to 498 MHz. (or did change something else too, auto
is your friend in the initial scan file then, except for the freq.)
 
 
 tried that no difference
  2. Your overall signal is not good enough.
 
 well up until friday I was using a HVR900, until it decided to refuse
 to believe it was plugged into a USB2 bus, and it was working fine
 
  3. You sit on some kernel with some bug.

[...]

Well, it is still very easy to install the latest remaining v4l-dvb from
hg/mercurial for a quick test too.

I don't have your hardware, but all my stuff is still fine there so far.

AFAIR, your device, added by Hartmut, has some sort of TD1316 without an
extra tda9887 IF demodulator for analog reception soldered outside of
the tuner on the PCB.

However, it is in a loop for eeprom auto detection on the side of the
bridge.

If that fails, and for my experience four of five attempts to fiddle
with that later did fail, you don't have a chance for any DVB either.

You might have to force the card number in such a case, but I'm still
far away from what might be going on and your report is without any
details so far.

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: Problem with Compro T200 (TDA1004x) and tuning Hi

2010-11-21 Thread hermann pitton
Hi Mike,

Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin:
 I am trying to tune channels with this card (which seems to be
 installed OK). However the output is
 
 Using DVB card Philips TDA10046H DVB-T
 tuning DVB-T (in United Kingdom) to 497833000 Hz
 polling
 Getting frontend event
 FE_STATUS:
 polling
 polling
 polling
 

usually, in the UK, this can be caused by the missing ability to detect
some frequencies offsets by the tda10046.

Since you have already a minus of 167000Hz, typically for the UK, in
your initial scan/tuning file, this most common problem likely can be
excluded.

So there are eventually three variants causing the problem on a first
idea.

1. They changed to 498 MHz. (or did change something else too, auto
   is your friend in the initial scan file then, except for the freq.)

2. Your overall signal is not good enough.

3. You sit on some kernel with some bug.

Case one and two are not hard to come through, for case three, the
remedies are slipping away.

You might have to install some latest .rc-git stuff, likely without
support for your graphics card, coming up in vesa mode only, try to
record something, and boot back into some kernel with support for
displaying the record, we all have HDTV these days ...

It might look like that, since the mobile devices and webcams took it
all over here ;)

Cheers,
Hermann




 





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


Re: [PATCH 06/10] saa7134: make module parameters boolean

2010-11-19 Thread hermann pitton

Am Samstag, den 20.11.2010, 00:43 +0100 schrieb David Härdeman:
 int to bool conversion for module parameters which are truely boolean.
 
 Signed-off-by: David Härdeman da...@hardeman.nu
 ---
  drivers/media/video/saa7134/saa7134-input.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/video/saa7134/saa7134-input.c 
 b/drivers/media/video/saa7134/saa7134-input.c
 index 8b80efb..aea74e2 100644
 --- a/drivers/media/video/saa7134/saa7134-input.c
 +++ b/drivers/media/video/saa7134/saa7134-input.c
 @@ -29,12 +29,12 @@
  
  #define MODULE_NAME saa7134
  
 -static unsigned int disable_ir;
 -module_param(disable_ir, int, 0444);
 +static bool disable_ir;
 +module_param(disable_ir, bool, 0444);
  MODULE_PARM_DESC(disable_ir,disable infrared remote support);
  
 -static unsigned int ir_debug;
 -module_param(ir_debug, int, 0644);
 +static bool ir_debug;
 +module_param(ir_debug, bool, 0644);
  MODULE_PARM_DESC(ir_debug,enable debug messages [IR]);
  
  static int pinnacle_remote;
 

Hi,

not exactly that one, but given all the previous changes,

I wonder if there will ever be some tested-by: from someone ...

Cheers,
Hermann


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


Re: [PATCH 3/3] [media] rc: Remove ir-common module

2010-11-13 Thread hermann pitton

Am Samstag, den 13.11.2010, 17:33 -0200 schrieb Mauro Carvalho Chehab:
 Now, just one old bttv board uses the old RC5 raw decoding routines.
 Its conversion to rc-core requires the generation of IRQ data for both
 positive and negative transitions at the IRQ line. I'm not sure if
 bttv driver supports it or if the transitions will be reliable enough.
 So, due to the lack of hardware for testing, the better for now is to
 just move the legacy routines to bttv driver, and wait for someone with
 a Nebula Digi could help to port it to use also rc-core raw decoders.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

Without any testing feedback from the bttv Nebula Digi since we made it
available for the saa7134 for Asus IR IRQ sampling too

Acked-by: hermann pitton hermann-pit...@arcor.de

Cheers,
Hermann 


  delete mode 100644 drivers/media/rc/ir-functions.c
 
 diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
 index 2d15468..ef19375 100644
 --- a/drivers/media/rc/Kconfig
 +++ b/drivers/media/rc/Kconfig
 @@ -10,11 +10,6 @@ menuconfig IR_CORE
 if you don't need IR, as otherwise, you may not be able to
 compile the driver for your adapter.
  
 -config IR_LEGACY
 - tristate
 - depends on IR_CORE
 - default IR_CORE
 -
  if IR_CORE
  
  config LIRC
 diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
 index 859c12c..8c0e4cb 100644
 --- a/drivers/media/rc/Makefile
 +++ b/drivers/media/rc/Makefile
 @@ -1,10 +1,8 @@
 -ir-common-objs  := ir-functions.o
  rc-core-objs := rc-main.o rc-raw.o
  
  obj-y += keymaps/
  
  obj-$(CONFIG_IR_CORE) += rc-core.o
 -obj-$(CONFIG_IR_LEGACY) += ir-common.o
  obj-$(CONFIG_LIRC) += lirc_dev.o
  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
 diff --git a/drivers/media/rc/ir-functions.c b/drivers/media/rc/ir-functions.c
 deleted file mode 100644
 index 14397d0..000
 --- a/drivers/media/rc/ir-functions.c
 +++ /dev/null
 @@ -1,120 +0,0 @@
 -/*
 - * some common functions to handle infrared remote protocol decoding for
 - * drivers which have not yet been (or can't be) converted to use the
 - * regular protocol decoders...
 - *
 - * (c) 2003 Gerd Knorr kra...@bytesex.org [SuSE Labs]
 - *
 - *  This program is free software; you can redistribute it and/or modify
 - *  it under the terms of the GNU General Public License as published by
 - *  the Free Software Foundation; either version 2 of the License, or
 - *  (at your option) any later version.
 - *
 - *  This program is distributed in the hope that it will be useful,
 - *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 - *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 - *  GNU General Public License for more details.
 - *
 - *  You should have received a copy of the GNU General Public License
 - *  along with this program; if not, write to the Free Software
 - *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 - */
 -
 -#include linux/module.h
 -#include linux/string.h
 -#include linux/jiffies.h
 -#include media/ir-common.h
 -#include rc-core-priv.h
 -
 -/* 
 -- */
 -
 -MODULE_AUTHOR(Gerd Knorr kra...@bytesex.org [SuSE Labs]);
 -MODULE_LICENSE(GPL);
 -
 -/* RC5 decoding stuff, moved from bttv-input.c to share it with
 - * saa7134 */
 -
 -/* decode raw bit pattern to RC5 code */
 -static u32 ir_rc5_decode(unsigned int code)
 -{
 - unsigned int org_code = code;
 - unsigned int pair;
 - unsigned int rc5 = 0;
 - int i;
 -
 - for (i = 0; i  14; ++i) {
 - pair = code  0x3;
 - code = 2;
 -
 - rc5 = 1;
 - switch (pair) {
 - case 0:
 - case 2:
 - break;
 - case 1:
 - rc5 |= 1;
 - break;
 - case 3:
 - IR_dprintk(1, ir-common: ir_rc5_decode(%x) bad 
 code\n, org_code);
 - return 0;
 - }
 - }
 - IR_dprintk(1, ir-common: code=%x, rc5=%x, start=%x, toggle=%x, 
 address=%x, 
 - instr=%x\n, rc5, org_code, RC5_START(rc5),
 - RC5_TOGGLE(rc5), RC5_ADDR(rc5), RC5_INSTR(rc5));
 - return rc5;
 -}
 -
 -void ir_rc5_timer_end(unsigned long data)
 -{
 - struct card_ir *ir = (struct card_ir *)data;
 - struct timeval tv;
 - unsigned long current_jiffies;
 - u32 gap;
 - u32 rc5 = 0;
 -
 - /* get time */
 - current_jiffies = jiffies;
 - do_gettimeofday(tv);
 -
 - /* avoid overflow with gap 1s */
 - if (tv.tv_sec - ir-base_time.tv_sec  1) {
 - gap = 20;
 - } else {
 - gap = 100 * (tv.tv_sec - ir-base_time.tv_sec) +
 - tv.tv_usec - ir-base_time.tv_usec;
 - }
 -
 - /* signal we're ready to start a new code */
 - ir-active = 0;
 -
 - /* Allow some

Re: Bounty for the first Open Source driver for Kinect

2010-11-10 Thread hermann pitton

Am Donnerstag, den 11.11.2010, 00:36 +0100 schrieb Markus Rechberger:
 On Thu, Nov 11, 2010 at 12:29 AM, Antonio Ospite
 osp...@studenti.unina.it wrote:
  On Thu, 11 Nov 2010 00:13:09 +0100
  Markus Rechberger mrechber...@gmail.com wrote:
 
  On Wed, Nov 10, 2010 at 11:48 PM, Mohamed Ikbel Boulabiar
  boulab...@gmail.com wrote:
   On Wed, Nov 10, 2010 at 10:24 PM, Antonio Ospite
   osp...@studenti.unina.it wrote:
   If there are arguments against a kernel driver I can't see them yet.
  [...]
   If I want to use this device, I will add many userspace code to create
   the skeleton model and that need much computation. Kernel Module adds
   performance to my other code.
 
  just some experience from our side, we do have fully working
  video4linux1/2 drivers
  in userspace, the only exception we have is a very thin layered
  kernelmodule in order
  to improve the datatransfer.
 
  Markus, can you point to some example so I can get a clearer picture?
 
 
 unfortunately we're closed source (and much more advanced) but you can
 have a look at other projects:

Markus,

please go away with such.

Despite of all previously, this is _not_ a place for any closed source
to discuss. There is nothing to discuss on that, please stop it.

Either try to come back with open source in a new round, or at least
don't try to hide what you have. Without all the code and hardware
specific stuff _previously_ developed/hacked on v4l-dvb, you don't
exist.

I still admit, overall, you did a very good job previously, but all
others are _not_ just your captives after some clashes.

With unfortunately we're closed source, you deliberately declare, that
you have nothing to do with open source at all anymore.

?

So, what is the remaining interest for you, except that you can continue
easier in userspace, instead of getting a hard block in the kernel, if
some enough have enough of your closed source ?

Cheers,
Hermann


 * libv4l2
 * freebsd has webcamd or something like that to emulate analog
 tv/webcams and dvb (they are even reusing linux kernel drivers with a
 userspace wrapper - so everything works in userspace for them).
 
 aside of that you can just debug userspace drivers with gdb, valgrind
 etc. if issues come up it will only affect your work not the entire
 system, kernel is seriously something critical.
 
 Markus
  Thanks,
Antonio
 
  --
  Antonio Ospite
  http://ao2.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


Re: V4L/DVB/IR patches pending merge

2010-11-01 Thread hermann pitton

Am Montag, den 01.11.2010, 11:30 +0100 schrieb Bjørn Mork:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
  == mantis patches - Waiting for Manu Abraham 
  abraham.m...@gmail.com == 
 
  Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c  
  http://patchwork.kernel.org/patch/92961   David Härdeman 
  da...@hardeman.nu
  Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, 
  improve http://patchwork.kernel.org/patch/107036  Marko Ristola 
  marko.rist...@kolumbus.fi
  Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files 
  http://patchwork.kernel.org/patch/107062  Bjørn Mork 
  bj...@mork.no
  Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module 
  removal http://patchwork.kernel.org/patch/107063  Bjørn Mork 
  bj...@mork.no
  Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make 
  modules  http://patchwork.kernel.org/patch/107147  Manu Abraham 
  abraham.m...@gmail.com
  Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits   
  http://patchwork.kernel.org/patch/109972  Ben Hutchings 
  b...@decadent.org.uk
  Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, 
  improve http://patchwork.kernel.org/patch/110909  Marko Ristola 
  marko.rist...@kolumbus.fi
  Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery 
  http://patchwork.kernel.org/patch/111090  Marko Ristola 
  marko.rist...@kolumbus.fi
  Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of 
  busy reg http://patchwork.kernel.org/patch/111245  Marko Ristola 
  marko.rist...@kolumbus.fi
  Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis)   
  http://patchwork.kernel.org/patch/112708  Niklas Claesson 
  nicke.claes...@gmail.com
  Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per 
  interrupt http://patchwork.kernel.org/patch/118173  Marko Ristola 
  marko.rist...@kolumbus.fi
  Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 
  demod   http://patchwork.kernel.org/patch/244201  Tuxoholic 
  tuxoho...@hotmail.de
  Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus  
  http://patchwork.kernel.org/patch/105621  Florent AUDEBERT 
  florent.audeb...@anevia.com
 
  What to say? Well, still waiting for Manu to handle those patches. He said 
  he had a problem with
  his dish and should be working on it next week. Let's hope we can finally 
  have some movement
  on those patches in time for .37.
 
 Can we agree that this was yet another useless waiting exercise?  Please
 start learning from experience.  You are just repeating the same mistake
 again and again.  Its rather frustrating to watch.  Like watching a rat
 in a maze banging it's head against the same wall over and over again.
 
 
 
 Bjørn


Bjorn,

you are taking it wrong.

Indeed, neither Manu nor Mauro can do anything on this now.

It got stuck from outside. There is a war.

If you look closer, beside of Mantis stuff, there are drivers for much
more recent chipsets, failing for not having linux support right now,
being able to do the triple performance and even much more.

Without help, neither Manu nor Mauro can hack them together.

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: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-07 Thread hermann pitton

Hi Giorgio,

Am Mittwoch, den 06.10.2010, 13:50 +0200 schrieb Giorgio:

[big snip]

  Likely, I only have to read the LKML daily ...
 
  Despite of that, we need a good analysis of course, and a way how to
  avoid such.
 
 Maybe we can have some kind of test team? It would help to find
 regressions before it's too late.
 
  Cheers,
  Hermann
 
 Giorgio Vazzana

Yes, we always need test teams.

And Mauro explicitly did call for testing.

I did, Dmitry did and Mauro.

But we did not find the potential bug, caused by moving some identical
code between saa7134-ts and saa7134-core forth and back.

This was still on hg and I only have _some_ of such cards.

Having this on latest Linus git stuff,

likely only compile fixes on previous -next, can find such ...

;)

I'm sorry for repeating my dumbness on that.

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: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-04 Thread hermann pitton
Hi Giorgio,

Am Montag, den 04.10.2010, 18:11 +0200 schrieb Giorgio:
 On 04/10/2010 01:48, Dejan Rodiger wrote:
  Hi Hermann,
  
  I finally found the time to wire analog antena and I checked it with
  my TV if it is working correctly.
  Since I am using local cable provider which didn't upgrade their
  system in 10 years and they are still broadcast in analog, I had a
  problem off finding channel list, so in the end I tried tvtime-scanner
  and it found about 58 channels. But, out of this 58 most of them were
  not good (no signal). I was able to finetune few programs. My main
  programs (local Croatian TV stations) were not found. Maybe I need to
  finetune every found station.
  
  I also tried zapping which crashed my X.
  
  I am also lost in setting mythtv. I set analog tunner on /dev/video0.
  But I think I have a problem of setting the channel list for my local
  cable provider. Is it possible to scan whole list or something. If you
  have any reading recommendation to set this, I would be helpfull
 
 Dejan,
 
 I have the exact same card:
 
 # sudo lpci -vnn
 02:07.0 Multimedia controller [0480]: Philips Semiconductors 
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
   Subsystem: ASUSTeK Computer Inc. Device [1043:4876]
   Flags: bus master, medium devsel, latency 64, IRQ 20
   Memory at fbfff800 (32-bit, non-prefetchable) [size=2K]
   Capabilities: [40] Power Management version 2
   Kernel driver in use: saa7134
   Kernel modules: saa7134
 
 and I can confirm you that it's autodetected and works very well (both the
 analog and the digital part) on 2.6.35.
 2.6.32 has a problem with dvb-t reception, but I have reported it and 
 hopefully
 it will be fixed soon upstream: 
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/23604

thanks for the report and pointing to the details again.

We can see, that my testings on four different machines and Dmitri's
tests have not been enough. Mauro had the Dual card=78 version from me
too at least for analog TV testing.

And, that was on hg with most backward compat as possible.

How good are our chances, to run in such and similar troubles in the
future, in fact staying only on latest -rc, rc-git and in best case on
-next stuff previously?

It will all come down to the distros and such a bug fix might take just
a year in the future regularly ...

So, if the quality control was not even sufficient on hg, what will
happen on latest -rc git stuff for that?

Obviously zillions of people do much more prefer to crash around there
than on hg ... ;)

Likely, I only have to read the LKML daily ...

Despite of that, we need a good analysis of course, and a way how to
avoid such.

Cheers,
Hermann


 
 If you want to test the analog part, install MPlayer and run the following 
 command:
 
 mplayer tv:// -tv 
 driver=v4l2:device=/dev/video0:norm=PAL:input=0:chanlist=europe-west
 
 and then press 'k' or 'h' to select previous/next channel (after you switch
 channel, wait some seconds until the card tunes, for some channels I need
 5 seconds here, for others about 1 second). Now, with some patience, explore
 all the channels and you should be able to find your local tv stations.
 Also, you might need to adjust mplayer options, like norm= or chanlist=
 (you could try chanlist=europe-east).
 
 The command line above doesn't grab audio though, so you won't hear a thing.
 If you want to hear the audio you need to make sure saa7134-alsa is loaded
 and run something like:
 
 mplayer tv:// -tv 
 driver=v4l2:device=/dev/video0:norm=PAL:input=0:alsa:adevice=hw.1,0:amode=1:immediatemode=0:chanlist=europe-west
 
 (make sure you select the right alsa device in adevice=)
 
 The wiki has a good page about MPlayer:
 
 http://www.linuxtv.org/wiki/index.php/MPlayer
 
 and of course the MPlayer man page explain all the options too.
 
 These pages are also useful (but some things might be a bit outdated):
 
 http://www.linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid
 http://www.linuxtv.org/wiki/index.php/Saa7134-alsa
 
 I hope this can help you and others reading this ML.
 
 Regards,
 Giorgio Vazzana
 
  Thanks
  --
  Dejan Rodiger
  S: callto://drodiger
  
  
  
  On Thu, Sep 23, 2010 at 00:46,  hermann-pit...@arcor.de wrote:
 
 
  Hi Dejan,
 
  - Original Nachricht 
  Von: Dejan Rodiger dejan.rodi...@gmail.com
  An:  hermann pitton hermann-pit...@arcor.de
  Datum:   22.09.2010 13:20
  Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support
 
  Hi Herman,
 
  here is dmesg output without forcing card=78.
  As I see it uses card=112, autodetected
 
  [   16.043345] IR RC6 protocol handler initialized
  [   16.173473] IR JVC protocol handler initialized
  [   16.236641] IR Sony protocol handler initialized
  [   16.433187] lirc_dev: IR Remote Control driver registered, major 250
  [   16.572705] IR LIRC bridge handler initialized
  [   16.894983] Linux video capture interface: v2.00
  [   16.957585

Re: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-04 Thread hermann pitton

Am Montag, den 04.10.2010, 19:59 -0400 schrieb Devin Heitmueller:
 On Mon, Oct 4, 2010 at 7:21 PM, hermann pitton hermann-pit...@arcor.de 
 wrote:
  thanks for the report and pointing to the details again.
 
  We can see, that my testings on four different machines and Dmitri's
  tests have not been enough. Mauro had the Dual card=78 version from me
  too at least for analog TV testing.
 
  And, that was on hg with most backward compat as possible.
 
  How good are our chances, to run in such and similar troubles in the
  future, in fact staying only on latest -rc, rc-git and in best case on
  -next stuff previously?
 
  It will all come down to the distros and such a bug fix might take just
  a year in the future regularly ...
 
  So, if the quality control was not even sufficient on hg, what will
  happen on latest -rc git stuff for that?
 
  Obviously zillions of people do much more prefer to crash around there
  than on hg ... ;)
 
 I think it's been made pretty clear:  we don't give a crap about
 whether users' PCs crash.  Getting the code into the bleeding edge
 kernel is the most important thing.  Reducing maintainership overhead
 is clearly more important than whether the code actually works.
 
 Forget about the hg backport system.  We would rather get crap code
 into the bleeding edge kernel where almost zero users will test it
 than to put it into HG where there is actually a chance for users to
 see the problems before it goes into the mainline kernel (except for
 the 0.1% of users who are willing to install the latest bleeding edge
 kernel and make it work with all their other hardware).
 
 Yes, we should all be prepared for lots of regressions being
 introduced, and nobody notices them until the code is already in the
 distros and has reached the masses.  And then maybe if the users are
 lucky the distro maintainers will backport fixes.
 
 It's been made pretty clear that reducing merge overhead is more
 important than delivering a quality product.
 
 I'll stop hijacking the thread now.
 
 Devin


Devin,

you are always very welcome!

I know for sure, that you know what you are talking about.

Thanks,
Hermann


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


Re: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-03 Thread hermann pitton
Hi Dejan,

Am Montag, den 04.10.2010, 01:48 +0200 schrieb Dejan Rodiger:
 Hi Hermann,
 
 I finally found the time to wire analog antena and I checked it with
 my TV if it is working correctly.
 Since I am using local cable provider which didn't upgrade their
 system in 10 years and they are still broadcast in analog, I had a
 problem off finding channel list, so in the end I tried tvtime-scanner
 and it found about 58 channels. But, out of this 58 most of them were
 not good (no signal). I was able to finetune few programs. My main
 programs (local Croatian TV stations) were not found. Maybe I need to
 finetune every found station.

that doesn't sound good. The card should just work.

Anyone else still out there with the same?

Or are we finally destroyed by so called compile fixes and linux
next stuff ?

 I also tried zapping which crashed my X.

Yeah, goes on since years, but has still good vbi :)

dunno, if Michael has further plans on that.

 I am also lost in setting mythtv. I set analog tunner on /dev/video0.
 But I think I have a problem of setting the channel list for my local
 cable provider. Is it possible to scan whole list or something. If you
 have any reading recommendation to set this, I would be helpfull
 
 Thanks
 --
 Dejan Rodiger
 S: callto://drodiger

For DVB-T try kaffeine or low level tools. Allow full delay for tuning
and locking.

If that fails, and no other well known other hardware restrictions are
in place, we have some broken code.

I do have a triple Asus 3in1 OEM with the same LNA config as that first
hybrid board has.

If really broken, not noticed yet here, but also not used since long, we
can meet on some same code base and track it down.

Cheers,
Hermann


 
 
 
 On Thu, Sep 23, 2010 at 00:46,  hermann-pit...@arcor.de wrote:
 
 
  Hi Dejan,
 
  - Original Nachricht 
  Von: Dejan Rodiger dejan.rodi...@gmail.com
  An:  hermann pitton hermann-pit...@arcor.de
  Datum:   22.09.2010 13:20
  Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support
 
  Hi Herman,
 
  here is dmesg output without forcing card=78.
  As I see it uses card=112, autodetected
 
  [   16.043345] IR RC6 protocol handler initialized
  [   16.173473] IR JVC protocol handler initialized
  [   16.236641] IR Sony protocol handler initialized
  [   16.433187] lirc_dev: IR Remote Control driver registered, major 250
  [   16.572705] IR LIRC bridge handler initialized
  [   16.894983] Linux video capture interface: v2.00
  [   16.957585] saa7130/34: v4l2 driver version 0.2.16 loaded
  [   16.958300] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
  [   16.958306]   alloc irq_desc for 18 on node 0
  [   16.958309]   alloc kstat_irqs on node 0
  [   16.958320] saa7134 :01:06.0: PCI INT A - Link[APC3] - GSI 18
  (level, low) - IRQ 18
  [   16.958327] saa7133[0]: found at :01:06.0, rev: 209, irq: 18,
  latency: 32, mmio: 0xfdeff000
  [   16.958334] saa7133[0]: subsystem: 1043:4876, board: ASUSTeK P7131
  Hybrid [card=112,autodetected]
  [   16.958378] saa7133[0]: board init: gpio is 0
  [   17.010075] Registered IR keymap rc-asus-pc39
  [   17.010197] input: saa7134 IR (ASUSTeK P7131 Hybri as
  /devices/pci:00/:00:09.0/:01:06.0/rc/rc0/input4
  [   17.010268] rc0: saa7134 IR (ASUSTeK P7131 Hybri as
  /devices/pci:00/:00:09.0/:01:06.0/rc/rc0
  [   17.190477] saa7133[0]: i2c eeprom 00: 43 10 76 48 54 20 1c 00 43
  43 a9 1c 55 d2 b2 92
  [   17.190490] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff
  ff ff ff ff ff ff ff
  [   17.190502] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08
  ff 00 d5 ff ff ff ff
  [   17.190513] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190524] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 55
  50 ff ff ff ff ff ff
  [   17.190534] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190545] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190556] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190566] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190577] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190587] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190598] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190609] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190620] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
  [   17.190641] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff
 
  [   17.610120] tuner 2-004b: chip found @ 0x96 (saa7133[0])
 
  [   17.780037] tda829x 2-004b: setting tuner address to 61
  [   17.940020] tda829x 2

Re: [GIT PULL for 2.6.36] V4L/DVB fixes

2010-09-29 Thread hermann pitton

Linus,

Am Montag, den 27.09.2010, 17:02 -0700 schrieb Linus Torvalds:
 On Mon, Sep 27, 2010 at 1:57 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  The following changes since commit 32163f4b2cef28a5aab8b226ffecfc6379a53786:
 
   alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 -0700)
 
  are available in the git repository at:
   ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
  v4l_for_linus
 
 I get
 
   scripts/kconfig/conf --oldconfig arch/x86/Kconfig
   drivers/media/Kconfig:146: 'endif' in different file than 'if'
   drivers/media/IR/Kconfig:15: location of the 'if'
   drivers/Kconfig:114: unexpected 'endmenu' within if block
   drivers/Kconfig:1: missing end statement for this entry
   make[1]: *** [oldconfig] Error 1
   make: *** [oldconfig] Error 2
 
 with this. And it seems to be due to a totally broken commit at the
 very beginning of the series by a commit called Kconfig fixes
 (Hah!), that clearly has not been tested at all.
 
 The commit sequence was also done today, apparently immediately before
 sending me the pull request. Which sure as hell explains the clearly
 not tested at all situation.
 
 Don't do this. You are now officially on my shit-list for sending me
 total crap.
 
 How effing hard can it be to understand: you don't send me stuff that
 hasn't been tested. It needs to be in -next for SEVERAL DAYS, and you
 don't rebase it or take it from some random quilt series just before
 sending it to me.
 
 That's true _especially_ during the -rc series. But it's damn well
 true at any other time too.
 
 I'm angry. I expect at least some _minimal_ amount of competence from
 people I pull from. This was not it. Get your ^#! act together!
 
Linus

you should not be such rude.

You have never been in any hardware details on v4l and dvb.

After Gerd Knorr did quit, out of reasons, you noticed there is some
noise on v4l and dvb, but you never had to fix much on your own in the
last eight years.

Shouting around and blaming others always was enough ...

I agree, a rc-1 should be at least compile tested.

Any idea, why this goes away?

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: [GIT PULL for 2.6.36] V4L/DVB fixes

2010-09-29 Thread hermann pitton

Am Donnerstag, den 30.09.2010, 00:08 -0300 schrieb Mauro Carvalho
Chehab:
 Em 29-09-2010 22:04, hermann pitton escreveu:
  
  Linus,
  
  Am Montag, den 27.09.2010, 17:02 -0700 schrieb Linus Torvalds:
  On Mon, Sep 27, 2010 at 1:57 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
  The following changes since commit 
  32163f4b2cef28a5aab8b226ffecfc6379a53786:
 
   alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 
  -0700)
 
  are available in the git repository at:
   ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
  v4l_for_linus
 
  I get
 
scripts/kconfig/conf --oldconfig arch/x86/Kconfig
drivers/media/Kconfig:146: 'endif' in different file than 'if'
drivers/media/IR/Kconfig:15: location of the 'if'
drivers/Kconfig:114: unexpected 'endmenu' within if block
drivers/Kconfig:1: missing end statement for this entry
make[1]: *** [oldconfig] Error 1
make: *** [oldconfig] Error 2
 
  with this. And it seems to be due to a totally broken commit at the
  very beginning of the series by a commit called Kconfig fixes
  (Hah!), that clearly has not been tested at all.
 
  The commit sequence was also done today, apparently immediately before
  sending me the pull request. Which sure as hell explains the clearly
  not tested at all situation.
 
  Don't do this. You are now officially on my shit-list for sending me
  total crap.
 
  How effing hard can it be to understand: you don't send me stuff that
  hasn't been tested. It needs to be in -next for SEVERAL DAYS, and you
  don't rebase it or take it from some random quilt series just before
  sending it to me.
 
  That's true _especially_ during the -rc series. But it's damn well
  true at any other time too.
 
  I'm angry. I expect at least some _minimal_ amount of competence from
  people I pull from. This was not it. Get your ^#! act together!
 
 Linus
  
  you should not be such rude.
  
  You have never been in any hardware details on v4l and dvb.
  
  After Gerd Knorr did quit, out of reasons, you noticed there is some
  noise on v4l and dvb, but you never had to fix much on your own in the
  last eight years.
  
  Shouting around and blaming others always was enough ...
  
  I agree, a rc-1 should be at least compile tested.
  
  Any idea, why this goes away?
 
 Hermann,
 
 That's OK. I did crap. Linus is right. I'll send him the patches again
 after having the same tree branch being tested for a few days at linux-next, 
 without any bad results.
 
 Cheers,
 Mauro.

Mauro,

hopefully, a few days on linux-next can replace all what we had in the
past, causing sometimes years of delay ...

What to say ?

OK, if you say we are fine with it now, it is up to you.

So, the whole mistake was, that Linus did not start kicking asses harder
earlier?

What a total crap!

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: [linux-dvb] Asus MyCinema P7131 Dual support

2010-09-22 Thread hermann-pitton
 

Hi Dejan,

- Original Nachricht 
Von: Dejan Rodiger dejan.rodi...@gmail.com
An:  hermann pitton hermann-pit...@arcor.de
Datum:   22.09.2010 13:20
Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support

 Hi Herman,
 
 here is dmesg output without forcing card=78.
 As I see it uses card=112, autodetected
 
 [   16.043345] IR RC6 protocol handler initialized
 [   16.173473] IR JVC protocol handler initialized
 [   16.236641] IR Sony protocol handler initialized
 [   16.433187] lirc_dev: IR Remote Control driver registered, major 250
 [   16.572705] IR LIRC bridge handler initialized
 [   16.894983] Linux video capture interface: v2.00
 [   16.957585] saa7130/34: v4l2 driver version 0.2.16 loaded
 [   16.958300] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
 [   16.958306]   alloc irq_desc for 18 on node 0
 [   16.958309]   alloc kstat_irqs on node 0
 [   16.958320] saa7134 :01:06.0: PCI INT A - Link[APC3] - GSI 18
 (level, low) - IRQ 18
 [   16.958327] saa7133[0]: found at :01:06.0, rev: 209, irq: 18,
 latency: 32, mmio: 0xfdeff000
 [   16.958334] saa7133[0]: subsystem: 1043:4876, board: ASUSTeK P7131
 Hybrid [card=112,autodetected]
 [   16.958378] saa7133[0]: board init: gpio is 0
 [   17.010075] Registered IR keymap rc-asus-pc39
 [   17.010197] input: saa7134 IR (ASUSTeK P7131 Hybri as
 /devices/pci:00/:00:09.0/:01:06.0/rc/rc0/input4
 [   17.010268] rc0: saa7134 IR (ASUSTeK P7131 Hybri as
 /devices/pci:00/:00:09.0/:01:06.0/rc/rc0
 [   17.190477] saa7133[0]: i2c eeprom 00: 43 10 76 48 54 20 1c 00 43
 43 a9 1c 55 d2 b2 92
 [   17.190490] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff
 ff ff ff ff ff ff ff
 [   17.190502] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08
 ff 00 d5 ff ff ff ff
 [   17.190513] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190524] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 55
 50 ff ff ff ff ff ff
 [   17.190534] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190545] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190556] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190566] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190577] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190587] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190598] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190609] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190620] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190641] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 
 [   17.610120] tuner 2-004b: chip found @ 0x96 (saa7133[0])
 
 [   17.780037] tda829x 2-004b: setting tuner address to 61
 [   17.940020] tda829x 2-004b: type set to tda8290+75a
 
 [   24.000114] saa7133[0]: registered device video0 [v4l2]
 [   24.000150] saa7133[0]: registered device vbi0
 [   24.000182] saa7133[0]: registered device radio0
 [   24.027730] saa7134 ALSA driver for DMA sound loaded
 [   24.027770] saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 18
 registered as card -2
 
 [   25.900159] DVB: registering new adapter (saa7133[0])
 [   25.900165] DVB: registering adapter 0 frontend 0 (Philips
 TDA10046H DVB-T)...
 
 [   26.710050] tda1004x: setting up plls for 48MHz sampling clock
 [   27.710043] tda1004x: found firmware revision 29 -- ok
 
 
 --
 Dejan Rodiger
 M: +385917829076
 S: callto://drodiger
 

all looks fine now.

With auto detection you should have correct LNA support for analog tuning and 
DVB-T.

You need to connect the DVB-T signal to the FM/RF antenna input and the analog 
TV signal
to the cable RF input..

If you plug in the remote receiver, gpio 0x04 will switch to high.

Does this help any further?

What went wrong previously, making you think you might have to force for 
example card = 78 ?

I can revive almost all of the Asus cards on the saa713x driver if needed.

Have fun, hopefully.

Cheers,
Hermann


 
 On Wed, Sep 22, 2010 at 01:13, hermann pitton hermann-pit...@arcor.de
 wrote:
  Hi Dejan,
 
  Am Dienstag, den 21.09.2010, 10:07 +0200 schrieb Dejan Rodiger:
  Hi,
 
  I am using Ubuntu linux 10.10 with the latest kernel 2.6.35-22-generic
  on x86_64. I have installed nonfree firmware which should support this
  card, but to be sure, can somebody confirm that my TV card is
  supported in Analog or DVB mode?
 
  sudo lspci -vnn
  01:06.0 Multimedia controller [0480]: Philips Semiconductors
  SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
          Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid
  [1043:4876

Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

2010-09-22 Thread hermann pitton

Am Mittwoch, den 22.09.2010, 08:08 +0200 schrieb Guennadi Liakhovetski:
 On Wed, 22 Sep 2010, hermann pitton wrote:
 
  Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
   On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
   
This is a V4L2 driver for TI OMAP1 SoC camera interface.
  
  [snip]
  
+
+   } else {
+   dev_warn(dev, %s: unhandled camera interrupt, status 
== 
+   0x%0x\n, __func__, it_status);
   
   Please, don't split strings
  
  sorry for any OT interference.
  
  But, are there any new rules out?
  
  Maybe I missed them.
  
  Either way, the above was forced during the last three years.
  
  Not at all ?
 
 No. Splitting print strings has always been discouraged, because it makes 
 tracking back kernel logs difficult. The reason for this has been the 80 
 character line length limit, which has now been effectively lifted. I'm 
 sure you can find enough links on the internet for any of these topics.
 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/

Guennadi,

thanks for the update!

If somebody ever would like to waste time on it, lots of patches and
whole drivers have been forced into this limitations for strings too.

In fact, fixing only a few lines, including the offset, you almost
always did hit it.

I'm pleased to hear now, that this problem never did exist ;))

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: [linux-dvb] Asus MyCinema P7131 Dual support

2010-09-21 Thread hermann pitton
Hi Dejan,

Am Dienstag, den 21.09.2010, 10:07 +0200 schrieb Dejan Rodiger:
 Hi,
 
 I am using Ubuntu linux 10.10 with the latest kernel 2.6.35-22-generic
 on x86_64. I have installed nonfree firmware which should support this
 card, but to be sure, can somebody confirm that my TV card is
 supported in Analog or DVB mode?
 
 sudo lspci -vnn
 01:06.0 Multimedia controller [0480]: Philips Semiconductors
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
 Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid
 [1043:4876]
 Flags: bus master, medium devsel, latency 32, IRQ 18
 Memory at fdeff000 (32-bit, non-prefetchable) [size=2K]
 Capabilities: [40] Power Management version 2
 Kernel driver in use: saa7134
 Kernel modules: saa7134
 
 It says Hybrid, but I put the following in
 the /etc/modprobe.d/saa7134.conf
 options saa7134 card=78 tuner=54
 
 
 Thanks
 -- 
 Dejan Rodiger
 S: callto://drodiger

don't have time to follow this closely anymore.

But forcing it to card=78 is plain wrong. It has an early additional LNA
in confirmed config = 2 status.

Your card should be auto detected and previously always was, based on
what we have in saa7134-cards.c and further for it. (saa7134-dvb and
related tuner/demod stuff)

}, {
.vendor   = PCI_VENDOR_ID_PHILIPS,
.device   = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x1043,
.subdevice= 0x4876,
.driver_data  = SAA7134_BOARD_ASUSTeK_P7131_HYBRID_LNA,
},{

I remember for sure, that this card was fully functional for all use
cases and it was not easy to get it there. I don't have it.

Please provide the dmesg for failing auto detection without forcing
some card = number as a starting point.

I for sure want to see this board fully functional again.

Cheers,
Hermann








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


Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

2010-09-21 Thread hermann pitton
Hi,

Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
 On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
 
  This is a V4L2 driver for TI OMAP1 SoC camera interface.

[snip]

  +
  +   } else {
  +   dev_warn(dev, %s: unhandled camera interrupt, status == 
  +   0x%0x\n, __func__, it_status);
 
 Please, don't split strings

sorry for any OT interference.

But, are there any new rules out?

Maybe I missed them.

Either way, the above was forced during the last three years.

Not at all ?

Cheers,
Hermann



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


Re: patch for lifeview hybrid mini

2010-08-23 Thread hermann pitton

Am Montag, den 23.08.2010, 16:06 +0200 schrieb tomloh...@gmail.com:
 Le 17/08/2010 02:24, hermann pitton a écrit : 
  Hi,
  
  Am Sonntag, den 15.08.2010, 07:20 +0200 schrieb tomloh...@gmail.com:

   Hi,
   
   the proposed patch is 6 month old and the owner of the card does not 
   give any more sign of life for the support of the radio.
   can someone review it and push it as is?
   
   Cheers,
   
   Signed-off-by: thomas gentytomloh...@gmail.com
   
   
  Thomas, just some quick notes, since nobody else cares.
  
  The m$ regspy gpio logs do show only gpio22 changing for analog and
  DVB-T and this should be the out of reference AGC control on a hopefully
  single hybrid tuner on that device called DUO.
  
  Remember, gpios not set in the mask of the analog part of the device do
  not change/switch anything, but those set there will change to zero even
  without explicit gpio define for that specific analog input.
  
  Out of historical reasons, we don't have this in our logs for DVB, also
  else they would be littered by the changing gpios for the TS/MPEG
  interface, but should be OK. We don't need to mark DVB related gpio
  stuff in the analog gpio mask, since we need to use some sort of hack to
  switch gpios on saa713x in DVB mode.
  
  dvb and v4l still don't know much about what each other subsystem does
  on that, but we have some progress.
  
  So, for now, I don't know for what gpio21 high in analog TV mode should
  be good, since the m$ driver seems not to do anything on that one, for
  what we have so far. Also it is common on later LifeView stuff (arrgh),
  but always is present in related logs then too.
  
  If ever needed,
  
  despite of that line inputs and muxes are also totally unconfirmed, and
  radio is plain madness ...
  
  drop the radio support for now, mark the external inputs as untested and
  I give some reviewed by so far with headaches.
  
  If we can't get more from here anymore, we must let it bounce.
  
  Cheers,
  Hermann
  
  
  

 
 Hi Hermann,
 
 thanks for you response
 
 for gpios : there is no software bundled with this card to listen to
 the radio so there is maybe a gpio not showed 
 in regspy when trying to listen music. Is this a bad assumption?
 anyway gpios 22 and 16 are hight in regspy
 with gpiomask 410 000 :
 dvb, analog tv and svideo work fine
 only radio remains :
 you can hear the results for radio here (2 Mo): 
 http://perso.orange.fr/tomlohave/linux/radio.test
 we can clearly hear the sound of a song but it is broken and
 interrupted, the question is why
 have you a suggestion ?
 
 Cheers
 
 T.G

Hello Thomas,

the assumption is good then.

Latest revisions of the Lifeview cards do switch to radio mode with
gpio21 high and let it low for TV. (it was the other way round
previously)

I was just wondering, if it might have radio support at all, since
gpio21 is not set in the m$ gpio mask and you say it does not come with
radio software.

The gpio18 and 16 can trigger IRQs and are usually in use on such
remotes for the button up/down signal and related IRQ sampling.

All saa7133/35/31e with tda8275ac and radio IF support use a special
7.5MHz ceramic filter, usually a huge well visible part in blue or
orange color, but on latest designs they are hard to identify, since
they might appear as SMD discrets now too.

The switch to this filter is often related to a an antenna connector RF
input switch triggered by the same gpio, but not necessarily. All sort
of combinations do exist.

Anyway, we demodulate the radio IF from such tuners on the
saa7133/35/31e on the saa chip and do also the stereo separation and
detection there. Hartmut added the needed code in saa7134-tvaudio and it
is valid for all tuner=54.

To achieve that, you need to use amux = TV for radio and likely also
some gpio is involved for the RF routing.

Cheers,
Hermann


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


Re: patch for lifeview hybrid mini

2010-08-16 Thread hermann pitton
Hi,

Am Sonntag, den 15.08.2010, 07:20 +0200 schrieb tomloh...@gmail.com:
 Hi,
 
 the proposed patch is 6 month old and the owner of the card does not 
 give any more sign of life for the support of the radio.
 can someone review it and push it as is?
 
 Cheers,
 
 Signed-off-by: thomas gentytomloh...@gmail.com
 

Thomas, just some quick notes, since nobody else cares.

The m$ regspy gpio logs do show only gpio22 changing for analog and
DVB-T and this should be the out of reference AGC control on a hopefully
single hybrid tuner on that device called DUO.

Remember, gpios not set in the mask of the analog part of the device do
not change/switch anything, but those set there will change to zero even
without explicit gpio define for that specific analog input.

Out of historical reasons, we don't have this in our logs for DVB, also
else they would be littered by the changing gpios for the TS/MPEG
interface, but should be OK. We don't need to mark DVB related gpio
stuff in the analog gpio mask, since we need to use some sort of hack to
switch gpios on saa713x in DVB mode.

dvb and v4l still don't know much about what each other subsystem does
on that, but we have some progress.

So, for now, I don't know for what gpio21 high in analog TV mode should
be good, since the m$ driver seems not to do anything on that one, for
what we have so far. Also it is common on later LifeView stuff (arrgh),
but always is present in related logs then too.

If ever needed,

despite of that line inputs and muxes are also totally unconfirmed, and
radio is plain madness ...

drop the radio support for now, mark the external inputs as untested and
I give some reviewed by so far with headaches.

If we can't get more from here anymore, we must let it bounce.

Cheers,
Hermann












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


Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

2010-07-15 Thread hermann pitton
Dear Kuninori,

Am Donnerstag, den 15.07.2010, 14:37 +0900 schrieb Kuninori Morimoto:
 Dear hermann
 
  Is there any documentation and how can a user know about it?
 
 Ecovec board which I and Guennadi were talking about is an evaluation board.
 If you buy this board, you can find DVD including manual in its box.
 Please check
 ${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf

on that stage it is now, you can't call me to crawl the web or buy any
evaluation board, likely high priced, still not even providing a link.

If you use GNU/Linux, free of charge, you have to provide acceptable
documentation too.

 dip-switch settings is wrote in
 3.4 Switch Specification
 
 If you don't have this board,
 but have kernel source code,
 you can watch explain comment on top of
 ${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
 
 Best regards
 --
 Kuninori Morimoto

This is lame. I do want to know what is out in the markets already and
no fall back on initial dip-switch comments. Comparable sensors ship
from China directly for some 5 Euros and less here.

This is a change (chance?) in culture too, and was already discussed in
1976 by some, but was at least public for all those a little bit more
interested since, let's say, 1982.

This is going on for a long time now, it did not hit the linuxtv.org
wiki at all until today, but introduces most relevant API changes. To
stop to provide support for older devices, in favor of the like of such
stuff, was mentioned several times already to get quicker to the
bonanza.

All major hardware manufacturers, and/or those claiming to be codec
possessors, have hired linux devel teams around the globe to move this
forward.

What it means, that everyone likely can film his life soon with two HD
cameras on mobile devices at once, let's say with 1080p for now, one
following his view to the outside world, the other one pointing to
him/her at the same time, about that, there is no word on this list.

It is not about missing some dip switch settings on an evaluation board.

It is about missing documentation, but much more about missing
reflection, if GNU/Linux should give the vehicle for such.

And it obviously does, even without any further comments.

Cheers,
Hermann















 







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


Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

2010-07-13 Thread hermann pitton

Am Mittwoch, den 14.07.2010, 09:12 +0900 schrieb Kuninori Morimoto:
 Dear Guennadi
 
 
  our luck, that mplayer (and gstreamer?) ignore returned field value. But 
  we'll have to fix this in sh_mobile_ceu_camera.
 
 Hmm  I understand.
 I guess, at first, we need test program for it.
 
 
  Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works 
  on migor for me, but not on ecovec, although the chip can be detected. Are 
  there any modifications necessary to the kernel or to the board to get it 
  to work? Maybe a jumper or something? I plug in a video signal source in 
  the video in connector, next to the viceo out one, using the same 
  cable, so, cabling should work too. But I'm only getting select timeouts 
  and no interrupts on the CEU.
 
 Hmm..  strange...
 No kernel patch is needed to use tw9910 on Ecovec.
 
 Ahh...
 Maybe the criminal is dip-switch.
 We can not use tw9910 and 2nd camera in same time.
 
 Please check DS2[3] on Ecovec.
 It should OFF when you use tw9910.
 
 I wrote dip-switch info on top of
 ${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
 Please check it too.
 
 Best regards
 --
 Kuninori Morimoto
  


Kuninori,

you are well treated and highly honored by all staying in development
with you. For me it is just some glitch on the edges, but very well
noted.

For now, a dip-switch, you must have been abroad somewhere, can't be a
criminal. Or?

http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ

Could you eventually agree with that about what a dip-switch is or do I
miss what you mean?

Do you really tell there are still unclear dip-switches in 2010?

If so, please let's know, but then you can't do anything against such in
software, of course.

Cheers,
Hermann






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


Re: [PATCH] Terratec Cinergy 250 PCI support

2010-07-08 Thread hermann pitton
Hi Jean-Michel,

Am Sonntag, den 04.07.2010, 19:03 +0200 schrieb Jean-Michel Grimaldi:
 Thanks Hermann,
 
 Yes my card is 153b:1160 in dmesg. After testing, the right audio is
 actually LINE2 rather than LINE1 (it did not make any difference for
 me since I did not use the audio on this card). Hence the following
 patch does the job for my card:

sorry for the delay.

Ah, indeed the same PCI subsystem on yours.

Looks like the documentation of the card variants needs improvement.

On the low profile one at the bttv-gallery the chips for digital TV are
not soldered, it has the huge brown 7.5MHz radio IF filter, the yellow
input connector seems to be for radio RF antenna input. 
Especially to be noted, it has a KS008 for i2c IR.

But that fuzzy picture on the package there shows the same card as on
your second link. It has extra connectors for audio in and out. (blue
and green)

Like on your card on your first link, 250 PCI Ver.1.0, the KS008 is
missing, the digital TV chips are present, the huge radio IF ceramic
filter is gone and likely replaced by some SMD part, since analog radio
support is still announced, but you don't have the blue and green audio
connectors.

Thanks for testing also the audio input.
Your result is conform to the .inf file in the bttv-gallery.

Is external audio-in over a break out cable together with S-Video?
Is the yellow input for the radio RF antenna or Composite?
The vmux 3 is typically used for an extra Composite input whereas vmux 0
is in most cases Composite over the S-Video connector.

Please post also all dmesg related to the card for the record and in
case we should need it in the future.

BTW, the recent Cinergy HT PCI is cx88x based and comes with a Composite
to S-Video adapter.
http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html

But for the connectivity they show the HT PCI with saa7131e ...
and point to the yellow input from VCR/DVD/etc.

 --- saa7134-cards.old.c2010-07-04 18:50:13.0 +0200
 +++ saa7134-cards.new.c2010-07-04 18:17:54.0 +0200
 @@ -2832,6 +2832,10 @@
  .amux = TV,
  .tv   = 1,
  },{
 +.name = name_comp1,
 +.vmux = 3,
 +.amux = LINE2,
 +},{
  .name = name_svideo,  /* NOT tested */
  .vmux = 8,
  .amux = LINE1,
 
 I did not touch the existing sections in case another variation of the
 card worked with them.
 Is this patch ok now?
 Regards,
 
 Jean-Michel

Yes, looks at least much better.
We can change the amux of svideo to LINE2 too.

In the attached version of your patch against mercurial v4l-dvb I do
this and sign off for it.

Please reply with your SOB for adding and testing the Composite input
and put it above my reviewed by and the patch should be ready for
lift-off now.

Thanks for working on it,
Hermann

patch is attached

saa7134: add the Composite input on Cinergy 250 PCI and fix related amux

This was untested until now and the changes are also conform to the
.inf file of the Philips driver. We change the amux for S-Video
accordingly too. There are slightly different variants of the card
not yet fully investigated.

Priority: normal



Reviewed-by: hermann pitton hermann-pit...@arcor.de
Signed-off-by: hermann pitton hermann-pit...@arcor.de


 2010/7/2 hermann pitton hermann-pit...@arcor.de
 Hi Jean-Michel,
 
 Am Mittwoch, den 30.06.2010, 00:02 +0200 schrieb Jean-Michel
 Grimaldi:
  Hi Hermann,
 
  Thanks for your answer. Do you mean I should add an entry
 with .name =
  name_comp1, .vmux = 3, .amux = LINE1 ?
 
  Should I remove the svideo entry, given that the card (which
 can be
  seen at [1]) only has a (proprietary) composite jack?
 However there
  seems to exist another card with the same name Terratec
 Cinergy 250
  PCI but different connectors : [2]
 
  What do you think? Should I just add a composite entry and
 leave the
  svideo as it is?
 
  Jean-Michel
 
  [1] http://www.arminformatique.fr/images/TerraTec%20Cinergy%
 20250%
  20PCI.jpg
  [2] http://www.notebookland.hu/shop
  +TERRATEC-CINERGY-250-PCI-TERRATEC-TV-tuner_29849_49
 
 
 
 
 there is also a low profile PCI card.
 
 http://www.terratec.net/de/produkte/bilder/img/2195346_5f78fcd0d7.png
 http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html
 
 Without any such device in my possession and without
 sufficient testing
 and reports, hard to tell.
 
 Do you have the known subsystem 153b:1160 ?
 
 For that one from http://www.bttv-gallery.de
 
 chips: saa7131e, KS008, 8275ac1
 pcb: TV-7131 Ver:B
 :00:0b.0 Multimedia controller

Re: Fwd: Firmware for HVR-1110

2010-07-05 Thread hermann pitton
Hi, JD,

Am Montag, den 05.07.2010, 19:08 + schrieb JD:
 
 
 All seems to be working fine now, I followed the installtion guide for the
 HVR-1120 and used the tda10048 f/w and I can now find DVB channels; I am still
 not sure as to why my card is looking for a different f/w tho, and would like 
 to
 know why if anyone finds out.
 
 Thanks for your help.
 

can't see the problem with different firmware in your logs.

I guess the root cause for all your prior trouble was that the HVR 1120
is packed as a HVR1110.

Such unfortunately is a known problem with new Hauppauge products since
a decade :(

That flaw is compensated by best auto detection and open eeprom content.
Also guys like Steven and Michael did develop the drivers you need on
that new card during their free time. (demodulator is in serial TS mode
and new tuner on saa7134)

All auto detection looks OK and of course also correct firmware is
uploaded then. Especially the C2 tuner variant is still quite new and I
guess Michael would prefer reports based on code on development level. 

Cheers,
Hermann


[   12.185935] saa7130/34: v4l2 driver version 0.2.15 loaded
[   12.185990] saa7134 :03:04.0: PCI INT A - GSI 16 (level, low) -
IRQ 16
[   12.185997] saa7133[0]: found at :03:04.0, rev: 209, irq: 16,
latency: 64, mmio: 0xfebff800
[   12.186004] saa7133[0]: subsystem: 0070:6707, board: Hauppauge
WinTV-HVR1120 DVB-T/Hybrid [card=156,autodetected]
[   12.186027] saa7133[0]: board init: gpio is 4
[   12.208619] IRQ 16/saa7133[0]: IRQF_DISABLED is not guaranteed on
shared IRQs
[   12.222966] HDA Intel :00:1b.0: PCI INT A - GSI 16 (level, low)
- IRQ 16
[   12.223016] HDA Intel :00:1b.0: setting latency timer to 64
[   12.292676] hda_codec: ALC662 rev1: BIOS auto-probing.
[   12.294322] input: HDA Digital PCBeep
as /devices/pci:00/:00:1b.0/input/input6
[   12.360024] saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43
a9 1c 55 d2 b2 92
[   12.360044] saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff
ff ff ff ff ff ff
[   12.360062] saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff
00 b0 ff ff ff ff
[   12.360080] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[   12.360097] saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04
00 20 00 ff ff ff
[   12.360114] saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360131] saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360149] saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360166] saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 ba 54
5e f0 73 05 29 00
[   12.360183] saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 19
8d 72 07 70 73 09
[   12.360201] saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72
0e 01 72 0f 01 72
[   12.360215] saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79
8d 00 00 00 00 00
[   12.360224] saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360233] saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360241] saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360250] saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   12.360260] i2c i2c-1: Invalid 7-bit address 0x7a
[   12.360745] tveeprom 1-0050: Hauppauge model 67209, rev C1F5, serial#
6182074
[   12.360748] tveeprom 1-0050: MAC address is 00-0D-FE-5E-54-BA
[   12.360750] tveeprom 1-0050: tuner model is NXP 18271C2 (idx 155,
type 54)
[   12.360753] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L')
PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4)
[   12.360755] tveeprom 1-0050: audio processor is SAA7131 (idx 41)
[   12.360757] tveeprom 1-0050: decoder processor is SAA7131 (idx 35)
[   12.360759] tveeprom 1-0050: has radio, has IR receiver, has no IR
transmitter
[   12.360761] saa7133[0]: hauppauge eeprom: model=67209
[   12.628148] tuner 1-004b: chip found @ 0x96 (saa7133[0])
[   12.695985] r8169: eth0: link up
[   12.695992] r8169: eth0: link up
[   12.708063] tda829x 1-004b: setting tuner address to 60
[   12.954972] tda18271 1-0060: creating new instance
[   13.21] TDA18271HD/C2 detected @ 1-0060
[   14.458202] CPU0 attaching NULL sched-domain.
[   14.458209] CPU1 attaching NULL sched-domain.
[   14.480104] CPU0 attaching sched-domain:
[   14.480108]  domain 0: span 0-1 level MC
[   14.480110]   groups: 0 1
[   14.480116] CPU1 attaching sched-domain:
[   14.480118]  domain 0: span 0-1 level MC
[   14.480120]   groups: 1 0
[   14.520030] tda18271: performing RF tracking filter calibration
[   15.810914] CPU0 attaching NULL sched-domain.
[   15.810921] CPU1 attaching NULL sched-domain.
[   15.832110] CPU0 attaching sched-domain:
[   15.832114]  domain 0: span 0-1 level MC
[   15.832117]   groups: 0 1
[   15.832122] CPU1 attaching sched-domain:
[   15.832124]  domain 0: span 0-1 level MC
[   15.832126]   groups: 1 0
[   

Re: Fwd: Firmware for HVR-1110

2010-07-03 Thread hermann pitton
Hi JD,

Am Samstag, den 03.07.2010, 03:32 +0100 schrieb JD:
 I'm confused as to what firmware in needed for the HVR-1110.
 
 Scouring the web, everywhere claims that the dvb-fe-tda10046 is
 required; however, dmesg logs show that this fails to be uploaded, and
 instead it is looking for dvb-fe-tda-10048:
 
 If I use tda-10048 then this seems to successfully loaded, but I am
 unable to find any channels with a scan;  the dvb nodes within /dev/
 are created and modules loaded, but dvbscan fails to tune.
 
 --
 dmesg
 
 $ dmesg |grep firmware
 tda10048_firmware_upload: waiting for firmware upload
 (dvb-fe-tda10048-1.0.fw)...
 saa7134 :03:04.0: firmware: requesting dvb-fe-tda10048-1.0.fw
 tda10048_firmware_upload: firmware read 24878 bytes.
 tda10048_firmware_upload: firmware uploading
 tda10048_firmware_upload: firmware uploaded
 
 Any tips?
 Thanks.
 --

all variants of the HVR-1110 have a tda 10046.

I can't see, how firmware loading can fail on auto detection of those
and even switch over to tda10048 as an alternative.

Do you force some card = number and are maybe on a not yet detected
HVR-1120?

Please provide the full dmesg log related to your card and make sure you
are on Michael Krufky's latest patches.

Cheers,
Hermann


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


Re: [PATCH] Terratec Cinergy 250 PCI support

2010-07-01 Thread hermann pitton
 for the radio antenna
RF input and changing to a low profile regularly calls for smaller
connectors too.

The opposite can be true of course too and much did change ...

In best case, they do have a different PCI subsystem then, if not and
much worse, maybe we can still figure out some difference from the
eeprom content. Worst case, we don't know how to make any difference and
the OEM does not follow Philips recommendations for the eeprom content
and uses some proprietary methods to detect the cards.

Cheers,
Hermann 

 
 2010/6/25 hermann pitton hermann-pit...@arcor.de
 
 Am Freitag, den 25.06.2010, 01:43 +0200 schrieb hermann
 pitton: 
 
  Hi, Jean-Michel,
 
  Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel
 Grimaldi:
   Hi, I have a Terratec Cinergy 250 PCI video card, and a
 small
   modification in saa7134-cards.c is needed for it to work.
 I built the
   patch on 2.6.34 version (I sent the modification to the
 maintainer in
   early 2009 but got no feedback):
  
   -- saa7134-cards.old.c  2010-06-25 00:31:16.0
 +0200
   +++ saa7134-cards.new.c 2010-06-25 00:30:52.0
 +0200
   @@ -2833,7 +2833,7 @@
   .tv   = 1,
   },{
   .name = name_svideo,  /* NOT tested */
   -   .vmux = 8,
   +   .vmux = 3,
   .amux = LINE1,
   }},
   .radio = {
  
   Thanks for taking it into account in future kernels.
  
 
  hm, don't know who missed it. After Gerd, the main mover on
 saa7134 was
  Hartmut, also /me and some well known others cared.
 
  Official maintainer these days is Mauro.
 
  For latest DVB stuff, you also will meet Mike Krufky.
 
  I'm sorry, but your patch is still wrong.
 
  You do have only a Composite signal. S-Video, with separated
 chroma and
  luma, can only be on vmux 5-9.
 
  NACKED-by: hermann pitton hermann-pit...@arcor.de
 
 
 Jean-Michel,
 
 do you understand?
 
 You need to add the missing Composite inputs instead.
 One of them can be Composite over the S-Video-in connector.
 
 Have a look at other cards in saa7134-cards.c.
 
 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: Problems with Pinnacle 310i (saa7134) and recent kernels

2010-06-26 Thread hermann pitton
Hi Avl,

Am Samstag, den 26.06.2010, 12:08 + schrieb Avl Jawrowski:
 Hi,
 there are some news with 2.6.34 (or previous).
 The IR is detected and the device seems to be created, but it doesn't work.
 
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7134 :01:02.0: PCI INT A - GSI 22 (level, low) - IRQ 22
 saa7133[0]: found at :01:02.0, rev: 209, irq: 22, latency: 32, mmio: 
 xcfddf800
 saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i
 [card=101,autodetected]
 saa7133[0]: board init: gpio is 600c000
 IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
 saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2e 15 13 ff ff
 saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2
 saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 03 c5 e8 9d
 saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 input: i2c IR (Pinnacle PCTV) as /class/input/input5
 Creating IR device irrcv0
 ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-0/0-0047/ir0 [saa7133[0]]
 tuner 0-004b: chip found @ 0x96 (saa7133[0])
 tda829x 0-004b: setting tuner address to 61
 tda829x 0-004b: type set to tda8290+75a
 saa7133[0]: registered device video0 [v4l2]
 saa7133[0]: registered device vbi0
 saa7133[0]: registered device radio0
 dvb_init() allocating 1 frontend
 DVB: registering new adapter (saa7133[0])
 DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)...
 
 And loading it with i2c_debug=1 ir_debug=1 I get a lot of these:
 
 [ 3757.243258] input: i2c IR (Pinnacle PCTV) as /class/input/input6
 [ 3757.243314] Creating IR device irrcv0
 [ 3757.243318] ir-kbd-i2c: i2c IR (Pinnacle PCTV)
 detected at i2c-0/0-0047/ir0 [saa7133[0]]
 [ 3757.243330] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3757.243470] i2c IR (Pinnacle PCTV)/ir: read error
 [ 3757.243512] saa7133[0]: i2c xfer:  10 3c 33 60 
 [ 3757.251420] saa7133[0]: i2c xfer:  84 ERROR: NO_DEVICE
 [ 3757.251599] saa7133[0]: i2c xfer:  86 ERROR: NO_DEVICE
 [ 3757.251777] saa7133[0]: i2c xfer:  94 ERROR: NO_DEVICE
 [ 3757.251955] saa7133[0]: i2c xfer:  96 
 [ 3757.256422] saa7133[0]: i2c xfer:  96 00 
 [ 3757.262970] saa7133[0]: i2c xfer:  97 =01 =01 =00 =11 =01 =04 =01 =85 
 [ 3757.269646] saa7133[0]: i2c xfer:  96 1f 
 [ 3757.276302] saa7133[0]: i2c xfer:  97 =89 
 [ 3757.283045] tuner 0-004b: chip found @ 0x96 (saa7133[0])
 [ 3757.283135] saa7133[0]: i2c xfer:  96 1f 
 [ 3757.289700] saa7133[0]: i2c xfer:  97 =89 
 [ 3757.296308] saa7133[0]: i2c xfer:  96 2f 
 [ 3757.302981] saa7133[0]: i2c xfer:  97 =00 
 [ 3757.309643] saa7133[0]: i2c xfer:  96 21 c0 
 [ 3757.339639] saa7133[0]: i2c xfer:  c1 ERROR: NO_DEVICE
 [ 3757.339818] saa7133[0]: i2c xfer:  c3 =0a 
 [ 3757.346302] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3793.576474] i2c IR (Pinnacle PCTV)/ir: read error
 [ 3793.678145] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3793.678290] i2c IR (Pinnacle PCTV)/ir: read error
 [ 3793.776341] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3793.776481] i2c IR (Pinnacle PCTV)/ir: read error
 [ 3793.876338] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3793.876480] i2c IR (Pinnacle PCTV)/ir: read error
 [ 3793.976343] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3793.976484] i2c IR (Pinnacle PCTV)/ir: read error
 [ 3794.076337] saa7133[0]: i2c xfer:  8f ERROR: NO_DEVICE
 [ 3794.076478] i2c IR (Pinnacle PCTV)/ir: read error
 
 It is an improvement or not?
 Thanks,
 Avl
 

unfortunately no improvement for you.

Jean Delvare just changed i2c to use reads at 0x8f for probing the
device instead of writes at 0x8e previously.

The result for you is the same.

Also no news about how to make any difference between the 310i variants.

Those later ones with some first sort of LNA should still be broken.

All I can say is, some people reported, proved by bisecting, that they
need the old LNA config = 1, Mike Krufky also assured to me, that he
can't say, which of the HVR 1110 needs the new LNA config = 1, but can't
exclude it is needed on some card.

You, obviously with some latest variant of the 

Re: [PATCH] Terratec Cinergy 250 PCI support

2010-06-25 Thread hermann pitton

Am Freitag, den 25.06.2010, 01:43 +0200 schrieb hermann pitton:
 Hi, Jean-Michel,
 
 Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel Grimaldi:
  Hi, I have a Terratec Cinergy 250 PCI video card, and a small
  modification in saa7134-cards.c is needed for it to work. I built the
  patch on 2.6.34 version (I sent the modification to the maintainer in
  early 2009 but got no feedback):
  
  -- saa7134-cards.old.c  2010-06-25 00:31:16.0 +0200
  +++ saa7134-cards.new.c 2010-06-25 00:30:52.0 +0200
  @@ -2833,7 +2833,7 @@
  .tv   = 1,
  },{
  .name = name_svideo,  /* NOT tested */
  -   .vmux = 8,
  +   .vmux = 3,
  .amux = LINE1,
  }},
  .radio = {
  
  Thanks for taking it into account in future kernels.
  
 
 hm, don't know who missed it. After Gerd, the main mover on saa7134 was
 Hartmut, also /me and some well known others cared.
 
 Official maintainer these days is Mauro.
 
 For latest DVB stuff, you also will meet Mike Krufky.
 
 I'm sorry, but your patch is still wrong.
 
 You do have only a Composite signal. S-Video, with separated chroma and
 luma, can only be on vmux 5-9.
 
 NACKED-by: hermann pitton hermann-pit...@arcor.de

Jean-Michel,

do you understand?

You need to add the missing Composite inputs instead.
One of them can be Composite over the S-Video-in connector.

Have a look at other cards in saa7134-cards.c.

Cheers,
Hermann


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


Re: [PATCH] Terratec Cinergy 250 PCI support

2010-06-24 Thread hermann pitton
Hi, Jean-Michel,

Am Freitag, den 25.06.2010, 00:42 +0200 schrieb Jean-Michel Grimaldi:
 Hi, I have a Terratec Cinergy 250 PCI video card, and a small
 modification in saa7134-cards.c is needed for it to work. I built the
 patch on 2.6.34 version (I sent the modification to the maintainer in
 early 2009 but got no feedback):
 
 -- saa7134-cards.old.c2010-06-25 00:31:16.0 +0200
 +++ saa7134-cards.new.c   2010-06-25 00:30:52.0 +0200
 @@ -2833,7 +2833,7 @@
   .tv   = 1,
   },{
   .name = name_svideo,  /* NOT tested */
 - .vmux = 8,
 + .vmux = 3,
   .amux = LINE1,
   }},
   .radio = {
 
 Thanks for taking it into account in future kernels.
 

hm, don't know who missed it. After Gerd, the main mover on saa7134 was
Hartmut, also /me and some well known others cared.

Official maintainer these days is Mauro.

For latest DVB stuff, you also will meet Mike Krufky.

I'm sorry, but your patch is still wrong.

You do have only a Composite signal. S-Video, with separated chroma and
luma, can only be on vmux 5-9.

NACKED-by: hermann pitton hermann-pit...@arcor.de

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: Laptop failing to suspend when WinTV-HVR950 installed.

2010-06-21 Thread hermann pitton
Hi David,

Am Montag, den 21.06.2010, 20:19 -0500 schrieb David Hagood:
 I have a 100% repeatable failure for my laptop runing Lucid 64 bit to
 suspend when my WinTV-HVR950 is installed, and a 100% success rate on it
 suspending when the device is not installed.
 
 If I put the device in, remove the device, and suspend (e.g. by closing
 the lid) it will suspend. There are no processes opening the device (as
 confirmed by lsof | grep dvb).
 
 Additionally, most of the time the failure to suspend occurs, the
 machine becomes unresponsive, and I have to hard power off to get it
 back.
 
 Has anybody else seen this?

just as a hint.

You need some cloud of users, that somebody sticks in.

I still have cases, where a single user claims on the wiki, all Asus
stuff is rubbish, but he still is exactly the only one failing after
years.

I don't deny, that it might fail for him.

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: Laptop failing to suspend when WinTV-HVR950 installed.

2010-06-21 Thread hermann pitton

Am Dienstag, den 22.06.2010, 04:19 +0200 schrieb hermann pitton:
 Hi David,
 
 Am Montag, den 21.06.2010, 20:19 -0500 schrieb David Hagood:
  I have a 100% repeatable failure for my laptop runing Lucid 64 bit to
  suspend when my WinTV-HVR950 is installed, and a 100% success rate on it
  suspending when the device is not installed.
  
  If I put the device in, remove the device, and suspend (e.g. by closing
  the lid) it will suspend. There are no processes opening the device (as
  confirmed by lsof | grep dvb).
  
  Additionally, most of the time the failure to suspend occurs, the
  machine becomes unresponsive, and I have to hard power off to get it
  back.
  
  Has anybody else seen this?
 
 just as a hint.
 
 You need some cloud of users, that somebody sticks in.
 
 I still have cases, where a single user claims on the wiki, all Asus
 stuff is rubbish, but he still is exactly the only one failing after
 years.

To stop joking, well noticed from you.

The dvb subsystem never had any way to suspend and recover reliable.

Cheers,
Hermann


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


Re: [PATCH] Fix av7110 driver name

2010-06-13 Thread hermann pitton
Hi Barry,

Am Sonntag, den 13.06.2010, 12:07 +0200 schrieb BOUWSMA Barry:
 On Sat (Saturday) 12.Jun (June) 2010, 05:10,  VDR User wrote:
 
  This patch simply changes the name of the av7110 driver to AV7110
  instead of the generic dvb it's set to currently.  Although it's
  somewhat trivial, it still seems appropriate to fix the name to be
  descriptive of the driver.
 
 Thanks Derek; I'll just note that as submitted, the trivial patch
 is a ``reversed'' patch, but I'd hope that any tools written for
 auto-patch-handing should be able to detect this and correct this
 issue.
 
 The other patch is in ``proper'' order, so no worries.
 
 
 
  --- v4l-dvb/linux/drivers/media/dvb/ttpci/av7110.c  2010-06-11
  13:24:29.0 -0700
  +++ v4l-dvb.orig/linux/drivers/media/dvb/ttpci/av7110.c 2010-06-11
  12:49:50.0 -0700
 
 
  -   .name   = AV7110,
  +   .name   = dvb,
 
 
 thanks,
 barry bouwsma

the whole situation, dealing with such sort of patches, also given the
noise for nothing previously, is of course somewhat unpleasant.

But out of such, we had best support from people not obviously related
to linux many times and that counts.

So, for my experience, it is always worth to have some rumble.

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


Aw: Re: What ever happened to standardizing signal level?

2010-06-07 Thread hermann-pitton
 
Hi Manu,

- Original Nachricht 
Von: Manu Abraham abraham.m...@gmail.com
An:  hermann pitton hermann-pit...@arcor.de
Datum:   07.06.2010 05:04
Betreff: Re: What ever happened to standardizing signal level?

 On Mon, Jun 7, 2010 at 2:01 AM, hermann pitton hermann-pit...@arcor.de
 wrote:
 
  Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User:
  hermann pitton hermann-pit...@arcor.de, you are contributing
  absolutely nothing to this thread aside of annoying people with your
  by trolling and half incoherent nonsense.  It's quite ironic you
  suggest _I_ am the one trolling when this is a thread _I_ created.
  And further, several people have posted legitimate responses to --
  clearly you are the only one suffering from your delusion.
 
  Dream on.
 
  The question never was, if you are trolling from time to time, but only
  if you are a duplicate of another troll or on your own.
 
  I have talked with Mauro about that and since then I ask you to provide
  your full name or point at least to a patch from you, where you have to
  agree to provide your real name in your SOB line.
 
  There was none and you also did not point to somebody else, to confirm
  for us, that you are known and on kernel development not only as a
  troll.
 
  You did not give an sufficient answer during the last two years.
 
  Additionally you've been stalking me in email as well.  Your behavior
  is not only uncalled for, it's abusive of both this mailing list and
  the people willingly participating in the discussion.  As I understand
  it, this is not the first time you've been the source of harassment.
 
  The opposite again is true, you stalked me by private e-mail and
  therefor my reply went as copy also to Mauro and Manu. If even Manu does
  not have your contact data, who else? Please provide them at least to
  him or someone else you trust and you are free for rants, within
  limitations.
 
 
 Sorry, that I could not reply in-time. I had been traveling and hence.
 Also, with little free time in between additionally. Hermann, what's
 going on ? I don't see the reason for such a long thread, nor can't
 believe that time is so cheap ..
 
 Anyway ... He doesn't do much of coding, or maybe next to nothing. But
 he does test hardware and drivers, from what I know, for quite a long
 time from the time of the FF cards. I know his real name as Derek
 Kelly and on IRC as hotwings. Well, I do appreciate the time he puts
 into testing, as it helps to make realize code better, or identify
 hardware bugs etc. At least a couple of times, I was able to find bugs
 in my own code, thanks to him. But the other side, unlike most people,
 he seemed to not have a taste for taking credits at all (don't know
 why, eventhough I had pointed out to him a few times) ..
 
 Regards,
 Manu

many thanks for your time and help.

Ah. Derek please take some credits.

I suspected him to be a troll only, since for more than two years
he refused to provide at least a full name. There was also no single patch with 
a valid SOB.

This has changed now and there should be no reasons for any further clashes.

His temper and harshness, when me was insisting on a full name, 
did always remind me on Uwe, who is using multiple email accounts 
on his attempts to improve development.

If you trust him, I'll trust him too.

Derek, sorry for have being preemptive on you.

Thanks,
Hermann
















Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im 
Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events
--
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: What ever happened to standardizing signal level?

2010-06-06 Thread hermann pitton

Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User:
 hermann pitton hermann-pit...@arcor.de, you are contributing
 absolutely nothing to this thread aside of annoying people with your
 by trolling and half incoherent nonsense.  It's quite ironic you
 suggest _I_ am the one trolling when this is a thread _I_ created.
 And further, several people have posted legitimate responses to --
 clearly you are the only one suffering from your delusion.

Dream on.

The question never was, if you are trolling from time to time, but only
if you are a duplicate of another troll or on your own.

I have talked with Mauro about that and since then I ask you to provide
your full name or point at least to a patch from you, where you have to
agree to provide your real name in your SOB line.

There was none and you also did not point to somebody else, to confirm
for us, that you are known and on kernel development not only as a
troll.

You did not give an sufficient answer during the last two years.

 Additionally you've been stalking me in email as well.  Your behavior
 is not only uncalled for, it's abusive of both this mailing list and
 the people willingly participating in the discussion.  As I understand
 it, this is not the first time you've been the source of harassment.

The opposite again is true, you stalked me by private e-mail and
therefor my reply went as copy also to Mauro and Manu. If even Manu does
not have your contact data, who else? Please provide them at least to
him or someone else you trust and you are free for rants, within
limitations.

 Do us all a favor -- go find some other thread to infect with your
 childishness, find some other user(s) to harass/stalk/obsess over, or
 simply grow up and stop wasting everyone's time.  In case you haven't
 noticed there has been absolutely nobody supporting your rants.  Take
 a hint.

http://linuxtv.org/wiki/index.php/People_behind_V4L-DVB

I did not put myself on this list and you should take me a little more
serious when asking you to fulfill the minimum requirements for
participating in kernel development.

Also, if you further associate me with illegal drugs, I give you a 100%
guarantee, that this will become _very_ expensive for you.

You also won't make the vine sour I have after working on my linux
hobby.

Now, after wasting my time looking at it, I can see you have a first
alsa patch in 2.6.33 with an invalid SOB, since only Derek, but
corrected to Derek Kelly in 2.6.34.

Missing is still, if you are working as a Hobbyist or if you are paid
for your work. Greg might ask you such soon or did already.

If your name is true, you could have saved yourself and all others most
of all the trouble. Looking at your methods, my doubts are not gone, but
I let it to others now.

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: correction: success

2010-06-06 Thread hermann pitton
Hi Alexander,

Am Freitag, den 04.06.2010, 13:57 +0200 schrieb Alexander Apostolatos:
  Original-Nachricht 
  Datum: Fri, 04 Jun 2010 06:39:30 +0200
  Von: hermann pitton hermann-pit...@arcor.de
  An: Alexander Apostolatos alexander.apostola...@gmx.de
  CC: linux-media@vger.kernel.org
  Betreff: Re: success
 
  Hi,
  
  Am Freitag, den 04.06.2010, 03:59 +0200 schrieb Alexander Apostolatos:
   Hi, had success in activating analog tuner in:
   
   http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards
   Philips TV/Radio Card CTX918, (Medion 7134), PCI 
   
   In my case, device is labeled:
   MEDION
   Type: TV-Tuner 7134
   V.92 Data/Fax Modem
   Rev: CTX918_V2 DVB-T/TV
   P/N: 20024179
   
   
   Label on tuner (other side of PCB) offers info on tuner type:
   Label reads:
   3139 147 22491c#
   FMD1216ME/I H-3
   SV21 6438

mine is SV21 0437. Guess you have 0438 and both should work as tuner=63.

   Made in INONESIA
  
   So I suppose tuner=78 is the compatible type for FMD1216ME/I H-3,
   
   NOT tuner=63 as detected by system. Please check and alter if
  applicable.
   
   Suspect different Hardware revs come with identical hardware ID's.
   Will provide additional info if told hot to obtain (hardware ID or
  whatever), but have to take a nap right now. It's 4 in the morning.
  
  I have such stuff with some known flaws, easily to circumvent.
  
  The CTX918 V2 needs to be in the original dual bus master capable blue
  MSI/Medion PCI slot.
  
  Else, it can become very tricky.
  
  Cheers,
  Hermann
  
 
 Hermann, thanks for the reply. 
 I knew of the blue slot from the manufacturer's website, so the device always 
 was in the blue slot.

Good, that is most important.

 However, I have to correct myself. I double checked last night, instead of 
 having a nap and it turned out, that there are preconditions involved for the 
 function of the card:
 
 in my case, the card works only after provoking a segfault by loading with 
 card=97 Tuner=38 and running eg. tvtime.
 After the ensuing segfault, a modprobe with card=12 and everyone of tuner 38, 
 63 and 78 yields a working device as it seems.
 
 This means that after a segfault, the drive works with the parameters passed 
 by autodetect. I have too look into that, find out what exactly the segfault 
 does. However I have a bit of a learning curve to get there.
 
 I'm currently running ubuntu lucid live and I have to look at the behaviour 
 when installed.
 
 If You'd like to share Your experiences with the card, especially the easily 
 to convent problems, I'd be very grateful. Especially if it involves getting 
 how to get DVB (T) to work or how to enable dma sound instead of using an 
 audio cable.
 
 Your's
 
 Alex

On current kernels the tuner by default is only enabled for DVB-T. 

There are some special bits in tuner core code to enable it for analog
mode, which currently don't come through in the init sequences on first
load.

You will notice in dmesg that the analog IF demodulator tda9887 is
missing. You must reload the driver once and it will be there.

You might set options saa7134 alsa=0 in /etc/modprobe.d/saa7134.conf,
else on recent distros the audio daemons might hold use count on
saa7134-alsa and you can't modprobe -vr saa7134-dvb, which also
unloads saa7134.

On the wiki should be some instructions for saa7134-alsa usage.
http://www.linuxtv.org/wiki/index.php/Saa7134-alsa

On radio autoscan does not work, since the tuner does not provide a
stereo detection bit, but sound is good stereo. Radio sound is better
with audio cable in the red connector.

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: What ever happened to standardizing signal level?

2010-06-06 Thread hermann pitton

Am Montag, den 07.06.2010, 00:12 +0200 schrieb Lars Schotte:
 stop flaming all the time, there are ppl out there like me who have
 some problems w/ their HW, and you are arguing here about nothing.
 
 On Mon, 07 Jun 2010 00:01:22 +0200
 hermann pitton hermann-pit...@arcor.de wrote:
 



  
  If your name is true, you could have saved yourself and all others
  most of all the trouble. Looking at your methods, my doubts are not
  gone, but I let it to others now.
  
  Hermann
  

ugh, seems you start new flaming ;)

Am Sonntag, den 06.06.2010, 21:28 +0200 schrieb Lars Schotte:
 OK,
 i am using w_scan, it scanned and found DVB-S2 channels but szap-s2
 doesnt tune in and there is no data, exactly like i said, so either
 you
 are lying and you have none of this things running or you were paid by
 huappauge to say this.

I fore sure will stay away ...

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: What ever happened to standardizing signal level?

2010-06-03 Thread hermann pitton
Hi,

Am Sonntag, den 30.05.2010, 00:01 -0700 schrieb VDR User:
 On Sat, May 29, 2010 at 10:52 PM, hermann pitton
 hermann-pit...@arcor.de wrote:
 
 ...troll spam removed...
 
 
 Hermann, you're a known troll with clearly nothing to contribute to
 this thread therefore you're comments are unwelcome.  Your mostly
 incoherent rant sounds like the ramblings of somebody who has consumed
 too much alcohol, and you're obviously using this mailing list as a
 cry for attention.  I'll ask you kindly to stop wasting everyones time
 with your moronic nonsense and direct your harassment elsewhere.  I'm
 sure you can find something better to do with your time then polluting
 this mailing list and making yourself look foolish.
 
 To everyone else, please disregard this post and the imbecile in which
 I'm replying to.

I tried in vain, several times, to get the VDR User to some ground.

To participate in development is about patches, as a minimum.

Driver maintainers are on a much higher level and can disregard patches.

If patches go to mainline, one has to allow to be authenticated.

There is no other way to get any stuff in else, with reasons.

If one is acting under some anonymous name and email account, there is
no way to fulfill this first requirement.

So, anything coming in from such, is taken as trolling.

Especially, if one did already qualify for taking it all over, rule
the personal engaged and so on ...

I'm not sure, if we have to improve the wiki for those never ever
sending any patches, since this is the first on what we meet.

But some, taking it all over, seem still to be in urgent need about how
to improve that ;)

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

2010-06-03 Thread hermann pitton
Hi,

Am Freitag, den 04.06.2010, 03:59 +0200 schrieb Alexander Apostolatos:
 Hi, had success in activating analog tuner in:
 
 http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards
 Philips TV/Radio Card CTX918, (Medion 7134), PCI 
 
 In my case, device is labeled:
 MEDION
 Type: TV-Tuner 7134
 V.92 Data/Fax Modem
 Rev: CTX918_V2 DVB-T/TV
 P/N: 20024179
 
 
 Label on tuner (other side of PCB) offers info on tuner type:
 Label reads:
 3139 147 22491c#
 FMD1216ME/I H-3
 SV21 6438
 Made in INONESIA

 So I suppose tuner=78 is the compatible type for FMD1216ME/I H-3,
 
 NOT tuner=63 as detected by system. Please check and alter if applicable.
 
 Suspect different Hardware revs come with identical hardware ID's.
 Will provide additional info if told hot to obtain (hardware ID or whatever), 
 but have to take a nap right now. It's 4 in the morning.

I have such stuff with some known flaws, easily to circumvent.

The CTX918 V2 needs to be in the original dual bus master capable blue
MSI/Medion PCI slot.

Else, it can become very tricky.

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: What ever happened to standardizing signal level?

2010-05-30 Thread hermann-pitton
 


- Original Nachricht 
Von: VDR User user@gmail.com
An:  hermann pitton hermann-pit...@arcor.de
Datum:   30.05.2010 09:01
Betreff: Re: What ever happened to standardizing signal level?

 On Sat, May 29, 2010 at 10:52 PM, hermann pitton
 hermann-pit...@arcor.de wrote:
 
 ...troll spam removed...
 
 
 Hermann, you're a known troll with clearly nothing to contribute to
 this thread therefore you're comments are unwelcome.  

On requests without success

http://linuxtv.org/pipermail/linux-dvb/2009-August/032299.html

you are well known for being in good company soon.

http://linuxtv.org/pipermail/linux-dvb/2008-December/030704.html

I wonder, if this will ever change, but hope so.

Hermann


Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im 
Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events
--
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 for 2.6.34] saa7134: add support for Compro VideoMate M1F

2010-05-30 Thread hermann-pitton
-dvb_orig/drivers/media/video/saa7134/saa7134-input.c2010-05-26
 20:34:09.0 +0300
  +++ v4l-dvb/drivers/media/video/saa7134/saa7134-input.c 2010-05-26
 21:14:54.764339462 +0300
  @@ -815,6 +815,11 @@ int saa7134_input_init1(struct saa7134_d
  mask_keyup   = 0x02;
  polling  = 50; /* ms */
  break;
  +   case SAA7134_BOARD_VIDEOMATE_M1F:
  +   ir_codes = RC_MAP_VIDEOMATE_M1F;
  +   mask_keycode = 0x0ff00;
  +   mask_keyup   = 0x04;
  +   break;
  break;
  }
  if (NULL == ir_codes) {
  diff -uprN v4l-dvb_orig/include/media/rc-map.h
 v4l-dvb/include/media/rc-map.h
  --- v4l-dvb_orig/include/media/rc-map.h 2010-05-26 20:34:11.0
 +0300
  +++ v4l-dvb/include/media/rc-map.h  2010-05-26 21:07:32.494384159
 +0300
  @@ -111,6 +111,7 @@ void rc_map_init(void);
   #define RC_MAP_TERRATEC_CINERGY_XS   rc-terratec-cinergy-xs
   #define RC_MAP_TEVII_NEC rc-tevii-nec
   #define RC_MAP_TT_1500   rc-tt-1500
  +#define RC_MAP_VIDEOMATE_M1F rc-videomate-m1f
   #define RC_MAP_VIDEOMATE_S350rc-videomate-s350
   #define RC_MAP_VIDEOMATE_TV_PVR  rc-videomate-tv-pvr
   #define RC_MAP_WINFAST   rc-winfast
  Signed-off-by: Pavel Osnova pvosn...@gmail.com
  
  
  
  On Wed, 2010-05-26 at 02:00 +0200, hermann pitton wrote:
  Hi Pavel,
 
  Am Dienstag, den 25.05.2010, 20:42 +0300 schrieb Pavel Osnova:
  This patch add support for Compro VideoMate M1F analog TV tuner.
 
  just some small comments.
 
  You must find a way to get patches to patchwork without line breakages.
 
  Patches should be against recent git or mercurial v4l-dvb and you should
  run make checkpatch and review the minor stuff it complains about.
 
  For my knowledge, there is no TUNER_LG_PAL_NEW_TAPC with tda9887.
  The NEW_TAPC uses LG tuner API and those with tda9887 Philips MK3.
 
  They are different for the UHF switch. Did you test on anything in UHF?
 
  We have some stuff in that cruft unfortunately.
 
  Even with extra radio tuner, Composite and S-Video should have the same
  amux.
 
  You set gpios without defining a gpio mask.
 
  Such has no effect.
 
  Cheers,
  Hermann
 
 
 
  diff -urN linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
  linux-2.6.34patched orig/Documentation/video4linux/CARDLIST.saa7134
  --- linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
  2010-05-17 00:17:36.0 +0300
  +++ linux-2.6.34patched
  orig/Documentation/video4linux/CARDLIST.saa71342010-05-24
  13:33:01.915467949 +0300
  @@ -175,3 +175,4 @@
   174 - Asus Europa Hybrid OEM   [1043:4847]
   175 - Leadtek Winfast DTV1000S [107d:6655]
   176 - Beholder BeholdTV 505 RDS[:5051]
  +177 - Compro VideoMate M1F   [185b:c900]
  diff -urN linux-2.6.34/drivers/media/IR/ir-keymaps.c
  linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
  --- linux-2.6.34/drivers/media/IR/ir-keymaps.c2010-05-17
  00:17:36.0 +0300
  +++ linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
  2010-05-24 13:37:59.872106122 +0300
  @@ -3492,3 +3492,65 @@
   .ir_type = IR_TYPE_NEC,
   };
   EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
  +
  +/* Compro VideoMate M1F
  + * Pavel Osnova pvosn...@gmail.com
  + */
  +static struct ir_scancode ir_codes_videomate_m1f[] = {
  +{ 0x01, KEY_POWER },
  +{ 0x31, KEY_TUNER },
  +{ 0x33, KEY_VIDEO },
  +{ 0x2f, KEY_RADIO },
  +{ 0x30, KEY_CAMERA },
  +{ 0x2d, KEY_NEW }, /* TV record button */
  +{ 0x17, KEY_CYCLEWINDOWS },
  +{ 0x2c, KEY_ANGLE },
  +{ 0x2b, KEY_LANGUAGE },
  +{ 0x32, KEY_SEARCH }, /* '...' button */
  +{ 0x11, KEY_UP },
  +{ 0x13, KEY_LEFT },
  +{ 0x15, KEY_OK },
  +{ 0x14, KEY_RIGHT },
  +{ 0x12, KEY_DOWN },
  +{ 0x16, KEY_BACKSPACE },
  +{ 0x02, KEY_ZOOM }, /* WIN key */
  +{ 0x04, KEY_INFO },
  +{ 0x05, KEY_VOLUMEUP },
  +{ 0x03, KEY_MUTE },
  +{ 0x07, KEY_CHANNELUP },
  +{ 0x06, KEY_VOLUMEDOWN },
  +{ 0x08, KEY_CHANNELDOWN },
  +{ 0x0c, KEY_RECORD },
  +{ 0x0e, KEY_STOP },
  +{ 0x0a, KEY_BACK },
  +{ 0x0b, KEY_PLAY },
  +{ 0x09, KEY_FORWARD },
  +{ 0x10, KEY_PREVIOUS },
  +{ 0x0d, KEY_PAUSE },
  +{ 0x0f, KEY_NEXT },
  +{ 0x1e, KEY_1 },
  +{ 0x1f, KEY_2 },
  +{ 0x20, KEY_3 },
  +{ 0x21, KEY_4 },
  +{ 0x22, KEY_5 },
  +{ 0x23, KEY_6 },
  +{ 0x24, KEY_7 },
  +{ 0x25, KEY_8 },
  +{ 0x26, KEY_9 },
  +{ 0x2a, KEY_NUMERIC_STAR }, /* * key */
  +{ 0x1d, KEY_0 },
  +{ 0x29, KEY_SUBTITLE }, /* # key */
  +{ 0x27, KEY_CLEAR },
  +{ 0x34, KEY_SCREEN },
  +{ 0x28, KEY_ENTER },
  +{ 0x19, KEY_RED },
  +{ 0x1a, KEY_GREEN },
  +{ 0x1b, KEY_YELLOW },
  +{ 0x1c, KEY_BLUE },
  +{ 0x18, KEY_TEXT },
  +};
  +struct

Re: [PATCH] Compro Videomate T750F Vista digital+analog support

2010-05-30 Thread hermann pitton

Hi Davor,

Am Montag, den 31.05.2010, 01:48 +0200 schrieb Davor Emard:
 HI!
 
 I have downloaded latest hg v4l and adapted the compro 
 t750f support patch. The patch is the same but v4l code is
 newer so there's some improvement
 
 Restarting VDR is now stable. Tried it cca 10x VDR restarts, 
 DVB-T tuner always worked. Remote still has 10% keys lost.
 
 ALSA device now appears with alsa=1 in the list
 arecord -l (but I haven't tried to capture anything yet)
 
 Someone mentioned that MCE-alike remote is the same to all 
 f-series of the cards so I called it rc-videomate-f.
 
 Here's the patch

likely one of the most difficult cards on that driver during the last
time.

Does't look such bad to me, after all, without having one.

Hmm, somehow its #define in the saa7134.h header is missing?

I'm also wondering, why we don't see the usual three lines offset on the
end of current patches.

Cheers,
Hermann


 diff -r 304cfde05b3f linux/drivers/media/IR/keymaps/Makefile
 --- a/linux/drivers/media/IR/keymaps/Makefile Tue May 25 23:50:51 2010 -0400
 +++ b/linux/drivers/media/IR/keymaps/Makefile Mon May 31 01:18:12 2010 +0200
 @@ -63,5 +63,6 @@
   rc-tt-1500.o \
   rc-videomate-s350.o \
   rc-videomate-tv-pvr.o \
 + rc-videomate-f.o \
   rc-winfast.o \
   rc-winfast-usbii-deluxe.o
 diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-cards.c
 --- a/linux/drivers/media/video/saa7134/saa7134-cards.c   Tue May 25 
 23:50:51 2010 -0400
 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c   Mon May 31 
 01:18:12 2010 +0200
 @@ -4920,12 +4920,14 @@
   },
   [SAA7134_BOARD_VIDEOMATE_T750] = {
   /* John Newbigin j...@it.swin.edu.au */
 + /* Emard 2010-05-10 v18-v4l davorem...@gmail.com */
   .name   = Compro VideoMate T750,
   .audio_clock= 0x00187de7,
   .tuner_type = TUNER_XC2028,
   .radio_type = UNSET,
 - .tuner_addr = ADDR_UNSET,
 + .tuner_addr = 0x61,
   .radio_addr = ADDR_UNSET,
 + .mpeg   = SAA7134_MPEG_DVB,
   .inputs = {{
   .name   = name_tv,
   .vmux   = 3,
 @@ -6752,6 +6754,11 @@
   msleep(10);
   saa7134_set_gpio(dev, 18, 1);
   break;
 + case SAA7134_BOARD_VIDEOMATE_T750:
 + saa7134_set_gpio(dev, 20, 0);
 + msleep(10);
 + saa7134_set_gpio(dev, 20, 1);
 + break;
   }
   return 0;
   }
 @@ -7171,6 +7178,11 @@
   saa_andorl(SAA7134_GPIO_GPMODE0  2,   0xC000, 0xC000);
   saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0xC000, 0xC000);
   break;
 + case SAA7134_BOARD_VIDEOMATE_T750:
 + dev-has_remote = SAA7134_REMOTE_GPIO;
 + saa_andorl(SAA7134_GPIO_GPMODE0  2,   0x8000, 0x8000);
 + saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x8000, 0x8000);
 + break;
   }
   return 0;
  }
 diff -r 304cfde05b3f linux/drivers/media/video/saa7134/saa7134-dvb.c
 --- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue May 25 23:50:51 
 2010 -0400
 +++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon May 31 01:18:12 
 2010 +0200
 @@ -55,6 +55,7 @@
  #include tda8290.h
  
  #include zl10353.h
 +#include qt1010.h
  
  #include zl10036.h
  #include zl10039.h
 @@ -886,6 +887,17 @@
   .disable_i2c_gate_ctrl = 1,
  };
  
 +static struct zl10353_config videomate_t750_zl10353_config = {
 + .demod_address  = 0x0f,
 + .no_tuner = 1,
 + .parallel_ts = 1,
 +};
 +
 +static struct qt1010_config videomate_t750_qt1010_config = {
 + .i2c_address = 0x62
 +};
 +
 +
  /* ==
   * tda10086 based DVB-S cards, helper functions
   */
 @@ -1569,6 +1581,21 @@
   __func__);
  
   break;
 + case SAA7134_BOARD_VIDEOMATE_T750:
 + printk(Compro VideoMate T750 DVB setup\n);
 + fe0-dvb.frontend = dvb_attach(zl10353_attach,
 + videomate_t750_zl10353_config,
 + dev-i2c_adap);
 + if (fe0-dvb.frontend != NULL) {
 + // if there is a gate function then the i2c bus 
 breaks.!
 + fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
 + if (dvb_attach(qt1010_attach,
 + fe0-dvb.frontend,
 + dev-i2c_adap,
 + videomate_t750_qt1010_config) == NULL)
 + wprintk(error attaching QT1010\n);
 + }
 +   

Re: [PATCH] Compro Videomate T750F Vista digital+analog support

2010-05-30 Thread hermann pitton

 
 Hmm, somehow its #define in the saa7134.h header is missing?
 
 I'm also wondering, why we don't see the usual three lines offset on the
 end of current patches.

Forget about the later, is in new file mode.

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: What ever happened to standardizing signal level?

2010-05-30 Thread hermann pitton
Hi,

Am Sonntag, den 30.05.2010, 23:02 -0400 schrieb Michael Krufky:
 Markus Rechberger wrote:
  On Sun, May 30, 2010 at 5:21 PM, Michael Krufky mkru...@linuxtv.org wrote:
  Markus Rechberger wrote:
  Hi,
 
  A little bit more ontopic, did anyone get around to read the
  signallevel of the tda18721?
  I wonder the register does not return any signallevel as indicated in
  the specifications.
 
  Markus
  There is a power level value that can be read from the tda18271 -- I had 
  a
  patch that enabled reading of this value, for testing purposes, but it
  wasn't as useful as I had hoped, so I never bothered to merge it.
 
  If you'd like to play with it, I pushed up some code last year:
 
  http://kernellabs.com/hg/~mkrufky/tda18271-pl/rev/4373874cff29
 
  Let me know how this works for you, or if you choose to change it.  I If 
  you
  find it valuable, we can merge it in somehow.
 
  
  hmm.. I somewhat tried the same but the register kept flipping back
  and the powerlevel register returned 0.
  
  Markus
 
 ...I think it only works on the c2 rev silicon.  Not sure about that, 
 though.
 
 -Mike
 

that is such stuff that really happens and nobody has any intentions
to hide better signal/SNR measurements from the users.

Some multiple subscribed trolls may take it for a next round, but it is
_nowhere_ any better.

Even worse, on S2, the whole previous model of doing so, will come under
pressure, if I'm not totally blind.

Best,
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: What ever happened to standardizing signal level?

2010-05-29 Thread hermann pitton

Am Freitag, den 28.05.2010, 20:09 -0700 schrieb VDR User:
 A lot of people were anticipating this happening but it seems to have
 stalled out.  Does anyone know what the intentions are?  Many users
 were also hoping to _finally_ get a good signal meter for linux as
 well.  If anyone has any info, please share!

Stop sending SPAM to this list.

What should be the intentions?

What should happen? Please reiterate all details!

Intentions of chip manufacturers are simple, sell more and make more
profit than others for others.

Further questions on that?

On what do _you_ have any progress and can contribute?

Is it at least any better on m$?

For sure not!

There is no as well.

Please provide at least one _single_ patch,
showing you have any direction on that ...

What ever happened? Nothing new.

Please try it also from that side then ...

IIRC, XCeive supposed a market, for tuners alone, above 6 billions for
the next year as a starting argument for investors.

Buy whatever you want.

As long, those acting on the markets, even without any freely agreeable
convention for measurements as reference, how can we have any?

Tell from which _instance_  punishing points are allowed and why ...

Since it is such a mass/global market, looking promising, lots jump in,
but often are out again only a little later. Ever looked in details?

To have no proper signal/SNR measurement agreement across all products
is only a side effect, but for sure not related to Open Source ;)

Show me a treaty, _all_ involved parties did sign, and then _eventually_
some prediction on that in some next future for outdated hardware is
feasible.

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: [PATCH] Compro videomate T750F DVB-T mode works now

2010-05-27 Thread hermann pitton
Hi,

Am Donnerstag, den 27.05.2010, 14:17 -0300 schrieb Mauro Carvalho
Chehab:
 Em Sat, 8 May 2010 01:50:24 +0200
 Emard davorem...@gmail.com escreveu:
 
  HI
  
  ... tried to post this few times to thhis list I don't know if
  it has made it maybe this time it will appear on the mailing list
  
  I have european version of Compro Videomate T750F Vista
  hybrid dvb-t + tv (PAL) + FM card. In kernels up to date (2.6.33.3)
  it didn't want to initialize in analog mode (tuner xc2028 always failed).
  
  Here's sligthly adapted patch from
  http://www.linuxtv.org/pipermail/linux-dvb/2008-May/025945.html
  that works for me. It disables analog tuner xc2028 which doesn't
  work (maybe because current driver is only for ntsc version of the
  card) and enables digital tuner that consists of zarlink 10353 and
  qt1010. Tested and works on kernel 2.6.33.3
 
 xc2028 tuner driver supports PAL standards as well. If it is not working fine,
 it is probably because the GPIO's are wrong. You need to run REGSPY.EXE 
 program,
 from DScaler project, to get the proper gpio values for your board.
 
 Btw, please send your Signed-off-by: on your patches.
  
  Best regards, Emard
  
  --- linux-2.6.33.3/drivers/media/video/saa7134/saa7134-cards.c.orig 
  2010-05-02 00:06:45.0 +0200
  +++ linux-2.6.33.3/drivers/media/video/saa7134/saa7134-cards.c  
  2010-05-02 01:20:50.0 +0200
  @@ -4883,10 +4883,11 @@ struct saa7134_board saa7134_boards[] =
  /* John Newbigin j...@it.swin.edu.au */
  .name   = Compro VideoMate T750,
  .audio_clock= 0x00187de7,
  -   .tuner_type = TUNER_XC2028,
  +   .tuner_type = TUNER_ABSENT,
 
 Instead of touching at the existing entry, you should be adding a new one, 
 with
 your board specifics, otherwise your patch would break support for the other
 board variant.
 
  .radio_type = UNSET,
  .tuner_addr = ADDR_UNSET,
  .radio_addr = ADDR_UNSET,
  +   .mpeg   = SAA7134_MPEG_DVB,
  .inputs = {{
  .name   = name_tv,
  .vmux   = 3,
  @@ -7192,6 +7193,7 @@ int saa7134_board_init2(struct saa7134_d
  case SAA7134_BOARD_AVERMEDIA_SUPER_007:
  case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
  case SAA7134_BOARD_CREATIX_CTX953:
  +case SAA7134_BOARD_VIDEOMATE_T750:
  {
  /* this is a hybrid board, initialize to analog mode
   * and configure firmware eeprom address
  --- linux-2.6.33.3/drivers/media/video/saa7134/saa7134-dvb.c.orig   
  2010-05-01 23:57:08.0 +0200
  +++ linux-2.6.33.3/drivers/media/video/saa7134/saa7134-dvb.c
  2010-05-02 00:51:44.0 +0200
  @@ -55,6 +55,7 @@
   #include tda8290.h
   
   #include zl10353.h
  +#include qt1010.h
   
   #include zl10036.h
   #include zl10039.h
  @@ -886,6 +887,17 @@ static struct zl10353_config behold_x7_c
  .disable_i2c_gate_ctrl = 1,
   };
   
  +static struct zl10353_config videomate_t750_zl10353_config = {
  +   .demod_address  = 0x0f,
  +   .no_tuner = 1,
  +   .parallel_ts = 1,
  +};
  +
  +static struct qt1010_config videomate_t750_qt1010_config = {
  +   .i2c_address = 0x62
  +};
  +
  +
   /* ==
* tda10086 based DVB-S cards, helper functions
*/
  @@ -1556,6 +1568,26 @@ static int dvb_init(struct saa7134_dev *
  __func__);
   
  break;
  +/*FIXME: What frontend does Videomate T750 use? */
  +case SAA7134_BOARD_VIDEOMATE_T750:
  +printk(Compro VideoMate T750 DVB setup\n);
  +fe0-dvb.frontend = dvb_attach(zl10353_attach,
  +
  videomate_t750_zl10353_config,
  +dev-i2c_adap);
  +if (fe0-dvb.frontend != NULL) {
  +printk(Attaching pll\n);
  +// if there is a gate function then the i2c bus 
  breaks.!
  +fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
  + 
  +if (dvb_attach(qt1010_attach,
  +   fe0-dvb.frontend,
  +   dev-i2c_adap,
  +   videomate_t750_qt1010_config) == 
  NULL)
  +{
  +wprintk(error attaching QT1010\n);
  +}
  +}
  +break;
  case SAA7134_BOARD_ZOLID_HYBRID_PCI:
  fe0-dvb.frontend = dvb_attach(tda10048_attach,
 zolid_tda10048_config,

just for reference, here is a link about what we tried last summer.

The followups do have also some regspy logs.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg07478.html


Re: v4l-dvb does not compile with kernel 2.6.34

2010-05-25 Thread hermann pitton
Hi Helmut,

Am Dienstag, den 25.05.2010, 23:59 +0200 schrieb Helmut Auer:
 Hello
 
 I just wanted to compile v4l-dvb for my Gen2VDR Ditribution with kernel 
 2.6.34, but it fails
 because many modules are missing:
 
 #include linux/slab.h
 
 and are getting errors like:
 
 /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c: In 
 function
 'free_firmware':
 /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c:252: 
 error: implicit
 declaration of function 'kfree'
 /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c: In 
 function
 'load_all_firmwares':
 /tmp/portage/media-tv/v4l-dvb-hg-0.1-r3/work/v4l-dvb/v4l/tuner-xc2028.c:314: 
 error: implicit
 declaration of function
 
 Am I missing something or is v4l-dvb broken ?
 

I did not test on all, but had some rant few days ago and explanations
followed and I likely missed some RFCs in that direction previously.

If I do get it right now, the released vanilla 2.6.34 should be stable.

For the upcoming 2.6.35, like always, only the first upcoming rc1 is a
potential candidate for some first stability there.

On mercurial v4l-dvb, with all patch porting in this hybrid ;) situation
with mixed up- and backports, after the git branch is official, only
2.6.33 is considered to be stable for now.

There are still compatibility bugs on all earlier kernels I guess,
but /me agreed to have at least four weeks for fixing them.

An average kernel release cycle is about three months.

I asked, if we should not all go to latest stable vanilla and upcoming
rc candidates instead. By that mass of devices we have now, those with
relevant hardware must come back for testing on rc stuff anyway.

The decision for now was to keep backward compat, to allow to have more
testers, this was always my point of view over all the years too.
During all that, we changed a lot these days from hacked drivers to by
chip manufacturers and OEMs fully supported ones.

This is the root cause for going to git and includes to stay in sync
with other subsystems on git level doing the same.

For what is still trickling in from active users, I also have to say,
that this throws one back into time consuming efforts again, even more
time consuming than that times v4l and dvb did go out of sync on every
new kernel in the past and if it is only about to avoid latest vanilla
or upcoming rc stuff and keep staying on older kernels, is it worth it?

Testers will vote with their feet.

In other words, to keep bisecting reliable on Linus' git level is
already a huge task, to keep mercurial v4l-dvb bisecting with all the
compat stuff functional, ugh.

Also, no doubt, Hans' daily build reports are really helpful, but to
assume only seeing warnings there now, after a first fix for some
upper older kernel came in, and previously say eight did error out at
the same point, is no replacement for testing with real devices on every
such later kernel ...

The rest is pure luck and a rare case.

We likely should wait for two/three kernel release cycles, but I predict
Douglas will have a very hard job, if not much more people come in to
support backward compatibility on mercurial level.

Thanks for your report from the upper side ;)

Cheers,
Hermann








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


Re: [PATCH for 2.6.34] saa7134: add support for Compro VideoMate M1F

2010-05-25 Thread hermann pitton
Hi Pavel,

Am Dienstag, den 25.05.2010, 20:42 +0300 schrieb Pavel Osnova:
 This patch add support for Compro VideoMate M1F analog TV tuner.

just some small comments.

You must find a way to get patches to patchwork without line breakages.

Patches should be against recent git or mercurial v4l-dvb and you should
run make checkpatch and review the minor stuff it complains about.

For my knowledge, there is no TUNER_LG_PAL_NEW_TAPC with tda9887.
The NEW_TAPC uses LG tuner API and those with tda9887 Philips MK3.

They are different for the UHF switch. Did you test on anything in UHF?

We have some stuff in that cruft unfortunately.

Even with extra radio tuner, Composite and S-Video should have the same
amux.

You set gpios without defining a gpio mask.

Such has no effect.

Cheers,
Hermann


 
 diff -urN linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
 linux-2.6.34patched orig/Documentation/video4linux/CARDLIST.saa7134
 --- linux-2.6.34/Documentation/video4linux/CARDLIST.saa7134
 2010-05-17 00:17:36.0 +0300
 +++ linux-2.6.34patched
 orig/Documentation/video4linux/CARDLIST.saa71342010-05-24
 13:33:01.915467949 +0300
 @@ -175,3 +175,4 @@
  174 - Asus Europa Hybrid OEM   [1043:4847]
  175 - Leadtek Winfast DTV1000S [107d:6655]
  176 - Beholder BeholdTV 505 RDS[:5051]
 +177 - Compro VideoMate M1F   [185b:c900]
 diff -urN linux-2.6.34/drivers/media/IR/ir-keymaps.c
 linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
 --- linux-2.6.34/drivers/media/IR/ir-keymaps.c2010-05-17
 00:17:36.0 +0300
 +++ linux-2.6.34patched orig/drivers/media/IR/ir-keymaps.c
 2010-05-24 13:37:59.872106122 +0300
 @@ -3492,3 +3492,65 @@
  .ir_type = IR_TYPE_NEC,
  };
  EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
 +
 +/* Compro VideoMate M1F
 + * Pavel Osnova pvosn...@gmail.com
 + */
 +static struct ir_scancode ir_codes_videomate_m1f[] = {
 +{ 0x01, KEY_POWER },
 +{ 0x31, KEY_TUNER },
 +{ 0x33, KEY_VIDEO },
 +{ 0x2f, KEY_RADIO },
 +{ 0x30, KEY_CAMERA },
 +{ 0x2d, KEY_NEW }, /* TV record button */
 +{ 0x17, KEY_CYCLEWINDOWS },
 +{ 0x2c, KEY_ANGLE },
 +{ 0x2b, KEY_LANGUAGE },
 +{ 0x32, KEY_SEARCH }, /* '...' button */
 +{ 0x11, KEY_UP },
 +{ 0x13, KEY_LEFT },
 +{ 0x15, KEY_OK },
 +{ 0x14, KEY_RIGHT },
 +{ 0x12, KEY_DOWN },
 +{ 0x16, KEY_BACKSPACE },
 +{ 0x02, KEY_ZOOM }, /* WIN key */
 +{ 0x04, KEY_INFO },
 +{ 0x05, KEY_VOLUMEUP },
 +{ 0x03, KEY_MUTE },
 +{ 0x07, KEY_CHANNELUP },
 +{ 0x06, KEY_VOLUMEDOWN },
 +{ 0x08, KEY_CHANNELDOWN },
 +{ 0x0c, KEY_RECORD },
 +{ 0x0e, KEY_STOP },
 +{ 0x0a, KEY_BACK },
 +{ 0x0b, KEY_PLAY },
 +{ 0x09, KEY_FORWARD },
 +{ 0x10, KEY_PREVIOUS },
 +{ 0x0d, KEY_PAUSE },
 +{ 0x0f, KEY_NEXT },
 +{ 0x1e, KEY_1 },
 +{ 0x1f, KEY_2 },
 +{ 0x20, KEY_3 },
 +{ 0x21, KEY_4 },
 +{ 0x22, KEY_5 },
 +{ 0x23, KEY_6 },
 +{ 0x24, KEY_7 },
 +{ 0x25, KEY_8 },
 +{ 0x26, KEY_9 },
 +{ 0x2a, KEY_NUMERIC_STAR }, /* * key */
 +{ 0x1d, KEY_0 },
 +{ 0x29, KEY_SUBTITLE }, /* # key */
 +{ 0x27, KEY_CLEAR },
 +{ 0x34, KEY_SCREEN },
 +{ 0x28, KEY_ENTER },
 +{ 0x19, KEY_RED },
 +{ 0x1a, KEY_GREEN },
 +{ 0x1b, KEY_YELLOW },
 +{ 0x1c, KEY_BLUE },
 +{ 0x18, KEY_TEXT },
 +};
 +struct ir_scancode_table ir_codes_videomate_m1f_table = {
 +.scan = ir_codes_videomate_m1f,
 +.size = ARRAY_SIZE(ir_codes_videomate_m1f),
 +};
 +EXPORT_SYMBOL_GPL(ir_codes_videomate_m1f_table);
 diff -urN linux-2.6.34/drivers/media/video/saa7134/saa7134-cards.c
 linux-2.6.34patched orig/drivers/media/video/saa7134/saa7134-cards.c
 --- linux-2.6.34/drivers/media/video/saa7134/saa7134-cards.c
 2010-05-17 00:17:36.0 +0300
 +++ linux-2.6.34patched
 orig/drivers/media/video/saa7134/saa7134-cards.c2010-05-24
 13:44:41.618731443 +0300
 @@ -5355,7 +5355,39 @@
  .amux = LINE2,
  },
  },
 -
 +[SAA7134_BOARD_VIDEOMATE_M1F] = {
 +.name   = Compro VideoMate M1F,
 +.audio_clock= 0x00187de7,
 +.tuner_type = TUNER_LG_PAL_NEW_TAPC,
 +.radio_type = TUNER_TEA5767,
 +.tuner_addr = ADDR_UNSET,
 +.radio_addr = 0x60,
 +.tda9887_conf   = TDA9887_PRESENT,
 +.inputs = {{
 +.name = name_tv,
 +.vmux = 1,
 +.amux = TV,
 +.tv   = 1,
 +},{
 +.name = name_comp1,
 +.vmux = 3,
 +.amux = LINE2,
 +},{
 +.name = name_svideo,
 +.vmux = 8,
 +.amux = LINE1,
 +}},
 +.radio = {
 +.name 

Re: [linux-dvb] Leadtek DVT1000S W/ Phillips saa7134

2010-05-20 Thread hermann pitton
Hi,

Am Freitag, den 21.05.2010, 06:01 +1000 schrieb Nathan Metcalf:
 Thanks Hermann,
 Does this mean I need to apply that patch you linked to me? Then 
 recompile the module and re-insert?
 
 Regards,
 Nathan

depends on your source. The 2.6.32 has no support for that card and it
depends also on further patches for tuner and demodulator

However, all 4 patches in question are in this pull request

   Von: 
Mauro Carvalho Chehab
mche...@redhat.com
An: 
Linus Torvalds
torva...@linux-foundation.org
 Kopie: 
Andrew Morton
a...@linux-foundation.org,
linux-ker...@vger.kernel.org,
linux-media@vger.kernel.org
   Betreff: 
[GIT PULL for 2.6.33] V4L/DVB
updates
 Datum: 
Wed, 9 Dec 2009 02:16:39
-0200 (05:16 CET)

and via Michael Krufky and Michael Obst for the remote.
(add the card, fix the entry, add the remote support, fix some coding
style)

You need a kernel = 2.6.33 or have to build and install mercurial
v4l-dvb from linuxtv.org on older kernels.

The current v4l-dvb is in process to gain deeper compatibility for older
kernels again, see the daily mails.


[cron job] v4l-dvb daily build 
Progress was made from 2.6.33 only a few days ago down to 2.6.25 now. My
latest test was on a 2.6.29. 

Else you can also use a snapshot from May 04 2010, after that backward
compat was limited to 2.6.33 only for a while, see the v4l-dvb daily
build messages. For 2.6.32 the recent is good again.

Cheers,
Hermann


 On 20/05/10 09:28, hermann pitton wrote:
  Hi Nathan,
 
  Am Freitag, den 21.05.2010, 04:48 +1000 schrieb Nathan Metcalf:
 
  Hey Guys,
  I hope this is the correct place, I am trying to get a LEADTEK DVT1000S HD 
  Tuner card working in Ubuntu (Latest)
  When I load the saa7134_dvb kernel module, there are no errors, but 
  /dev/dvb is not created.
 
  I have tried enabling the debug=1 option when loading the module, but 
  don't get any more useful information.
 
  Can someone please assist me? Or direct me to the correct place?
 
  Regards,
  Nathan Metcalf
 
   
  there was some buglet previously, but the card is else supported since
  Nov. 01 2009 on mercurial v4l-dvb and later kernels.
 
  http://linuxtv.org/hg/v4l-dvb/rev/855ee0444e61b8dfe98f495026c4e75c461ce9dd
 
  Support for the remote was also added.
 
  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: [linux-dvb] Leadtek DVT1000S W/ Phillips saa7134

2010-05-19 Thread hermann pitton
Hi Nathan,

Am Freitag, den 21.05.2010, 04:48 +1000 schrieb Nathan Metcalf:
 Hey Guys,
 I hope this is the correct place, I am trying to get a LEADTEK DVT1000S HD 
 Tuner card working in Ubuntu (Latest)
 When I load the saa7134_dvb kernel module, there are no errors, but /dev/dvb 
 is not created.
 
 I have tried enabling the debug=1 option when loading the module, but don't 
 get any more useful information.
 
 Can someone please assist me? Or direct me to the correct place?
 
 Regards,
 Nathan Metcalf
 

there was some buglet previously, but the card is else supported since
Nov. 01 2009 on mercurial v4l-dvb and later kernels.

http://linuxtv.org/hg/v4l-dvb/rev/855ee0444e61b8dfe98f495026c4e75c461ce9dd

Support for the remote was also added.

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: av7110 and budget_av are broken!

2010-05-18 Thread hermann pitton
Hi,

Am Sonntag, den 16.05.2010, 06:21 +0200 schrieb Oliver Endriss:
 On Sunday 16 May 2010 03:53:48 hermann pitton wrote:
  
  Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling
  Landgraf:
   Hello Oliver,
   
   On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote:
On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
  Am 22.3.2010 20:34, schrieb e9hack:
  Am 20.3.2010 22:37, schrieb Hans Verkuil:
  On Saturday 20 March 2010 17:03:01 e9hack wrote:
  OK, I know that. But does the patch I mailed you last time fix 
  this
  problem
  without causing new ones? If so, then I'll post that patch to 
  the list.
 
  With your last patch, I've no problems. I'm using a a TT-C2300 
  and a
  Budget card. If my
  VDR does start, currently I've no chance to determine which 
  module is
  load first, but it
  works. If I unload all modules and load it again, I've no 
  problem. In
  this case, the
  modules for the budget card is load first and the modules for the 
  FF
  loads as second one.
 
  Ping!!

 It's merged in Mauro's fixes tree, but I don't think those pending 
 patches
 have been pushed upstream yet. Mauro, can you verify this? They 
 should be
 pushed to 2.6.34!
   
What about the HG driver?
The v4l-dvb HG repository is broken for 7 weeks...
   
Hi guys,
   
we have May 16th, and the HG driver is broken for 10 weeks now!
   
History:
- The changeset which caused the mess was applied on March 2nd:
 http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
   
- A fix is waiting at fixes.git since March 24th:
 
http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
   
Are there any plans to bring v4ldvb HG to an usable state?
   
   Yes, Now I will collect patches from devel and fixes tree. At least
   until we achieve a better approach on it.
   Sorry the delay.
   
   Sounds good? Any other suggestion?
   
   Let me work on it.
   
   Cheers
   Douglas
  
  
  Hi, Douglas and Oliver,
  
  just as a small comment.
  
  I have not been on latest rc1 and such rcs close to a release for some
  time.
 
  But I was for a long time and v4l-dvb can't be a substitute for such.
 
 Sorry, I do not want to cope with experimental kernels and their bugs on
 my systems. I need a stable and reliable platform, so that I can
 concentrate on 'my' bugs.
 
 Usually I update the kernel every 3..4 releases (which causes enough
 trouble due to changed features, interfaces etc).

that is what everyone does prefer and that I call subsystem developer
service.

In fact, everyone has to be on .rc stuff starting with .rc1 ;)

Failing on being there, than blaming the one doing the backports for
being in delay, likely without any related hardware in his possession,
that can't work.

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: av7110 and budget_av are broken!

2010-05-15 Thread hermann pitton

Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling
Landgraf:
 Hello Oliver,
 
 On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss o.endr...@gmx.de wrote:
  On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
  On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
Am 22.3.2010 20:34, schrieb e9hack:
Am 20.3.2010 22:37, schrieb Hans Verkuil:
On Saturday 20 March 2010 17:03:01 e9hack wrote:
OK, I know that. But does the patch I mailed you last time fix this
problem
without causing new ones? If so, then I'll post that patch to the 
list.
   
With your last patch, I've no problems. I'm using a a TT-C2300 and a
Budget card. If my
VDR does start, currently I've no chance to determine which module is
load first, but it
works. If I unload all modules and load it again, I've no problem. In
this case, the
modules for the budget card is load first and the modules for the FF
loads as second one.
   
Ping!!
  
   It's merged in Mauro's fixes tree, but I don't think those pending 
   patches
   have been pushed upstream yet. Mauro, can you verify this? They should be
   pushed to 2.6.34!
 
  What about the HG driver?
  The v4l-dvb HG repository is broken for 7 weeks...
 
  Hi guys,
 
  we have May 16th, and the HG driver is broken for 10 weeks now!
 
  History:
  - The changeset which caused the mess was applied on March 2nd:
   http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
 
  - A fix is waiting at fixes.git since March 24th:
   
  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
 
  Are there any plans to bring v4ldvb HG to an usable state?
 
 Yes, Now I will collect patches from devel and fixes tree. At least
 until we achieve a better approach on it.
 Sorry the delay.
 
 Sounds good? Any other suggestion?
 
 Let me work on it.
 
 Cheers
 Douglas


Hi, Douglas and Oliver,

just as a small comment.

I have not been on latest rc1 and such rcs close to a release for some
time.

But I was for a long time and v4l-dvb can't be a substitute for such.

Despite of getting more users for testing, on _that_ front does not
happen such much currently, keeping v4l-dvb is mostly a service for
developers this time.

So, contributing on the backports and helping Douglas with such is
really welcome.

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: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

2010-05-14 Thread hermann pitton
Hi,

Am Donnerstag, den 13.05.2010, 15:45 -0300 schrieb Mauro Carvalho
Chehab:
 Mauro Carvalho Chehab wrote:
  hermann pitton wrote:
  
  My view is that the backport tree is very useful to have a broader number
  of people testing V4L/DVB code, as it can be applied against legacy 
  kernels.
  Of course, for this to work, people should quickly fix broken backports
  (that means that not only Douglas should work on it, but other developers
  are welcomed to contribute with backport fixes).
  For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb
  then to provide relevant debug output and eventually patches.
  
  Until Douglas or someone fix the breakages with older kernels, yes.
 
 As the fix patch is really trivial, I found a couple of minutes to write a 
 patch
 for fixing this issue. I haven't test the patch, but, as it uses the same 
 backport
 logic as found at cx2355-ir, I don't expect much troubles on it.

Mauro, fine, it is a start.

Compiles down to to 2.6.30, but has some __check_debug warnings for
three static bool insmod options there. (build cron job of today)

To replace them with some int seems ok, but since no such warnings on
higher kernels for bool, likely some compat issue.

IR oopses on 2.6.30 with Pinnacle 310i on a first try.

Thanks for all explanations of the current sync procedures, Douglas does
well and four weeks without in depth backward compat are hard to avoid
either way.

Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after
the merge window.

Cheers,
Hermann

saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 5-004b: chip found @ 0x96 (saa7133[1])
tda829x 5-004b: setting tuner address to 61
tda829x 5-004b: type set to tda8290+75a
saa7133[1]: registered device video1 [v4l2]
saa7133[1]: registered device vbi1
saa7133[1]: registered device radio1
saa7133[2]: setting pci latency timer to 64
saa7133[2]: found at :02:09.0, rev: 208, irq: 19, latency: 64, mmio: 
0xfdefd000
saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i 
[card=101,autodetected]
saa7133[2]: board init: gpio is 600c000
IRQ 19/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff
saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2
saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9
saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 6-004b: chip found @ 0x96 (saa7133[2])
tda829x 6-004b: setting tuner address to 61
tda829x 6-004b: type set to tda8290+75a
Registered IR keymap rc-pinnacle-color
input: i2c IR (Pinnacle PCTV) as /devices/virtual/input/input8
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core]
PGD 3ecbd067 PUD 2006b067 PMD 0 
Oops:  [#1] SMP 
last sysfs file: /sys/module/saa7134/initstate
CPU 0 
Modules linked in: rc_pinnacle_color ir_kbd_i2c(+) tda827x tda8290 tuner 
saa7134(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg 
videobuf_core ir_common ir_core tveeprom sit tunnel4 fuse bridge stp llc bnep 
sco l2cap bluetooth sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter 
ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput 
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer 
r8169 ppdev snd mii soundcore snd_page_alloc parport_pc shpchp k8temp parport 
hwmon joydev floppy serio_raw pcspkr i2c_nforce2 ata_generic pata_acpi pata_amd 
radeon drm i2c_algo_bit i2c_core [last unloaded: v4l1_compat]
Pid: 3399, comm: modprobe Not tainted 2.6.30.10-105.2.16.fc11.x86_64 #1  
RIP: 0010:[a00e97c7]  [a00e97c7] 
__ir_input_register+0x26d/0x2fd [ir_core]
RSP: 0018:88003b459cb8  EFLAGS: 00010246
RAX

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

2010-05-14 Thread hermann pitton
Hi,

[snip]
 
 Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after
 the merge window.

The saa7134 card=2 gpio remote is OK on 2.6.33.4 with current v4l-dvb.

Sander, let's know about further questions.

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: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

2010-05-13 Thread hermann pitton

Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
 hermann pitton wrote:
  Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
  Sander Pientka wrote:
  Hi Hermann,
 
  I am going to revive this old thread, I completely forgot about it and
  I still want to solve this problem.
 
  Yes, with the IR transmitter not plugged in, the gpio is reported as
  0 by dmesg.
 
  I am aware there is a picture of the backside missing on the wiki, I
  will try to make one a.s.a.p.
 
  NEC IR support seems to be built-in already: 
  drivers/media/IR/ir-nec-decoder.c.
 
  Besides, dmesg outputs a section of error messages I don't understand:
 
  [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
  i2c_transfer returned: -5
  [ 1585.548229] tda18271_toggle_output: error -5 on line 47
  [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
  i2c_transfer returned: -5
  [ 1585.720129] tda18271_init: error -5 on line 826
  [ 1585.720136] tda18271_tune: error -5 on line 904
  [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
  [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
  i2c_transfer returned: -5
  [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
  i2c_transfer returned: -5
  [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
  i2c_transfer returned: -5
  [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
  [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
 
 
  Do you have any idea about the origin of these errors? Do you think
  they affect the IR functionality?
  The above errors won't change anything at IR side. For IR, the better 
  approach
  is to start using raw_decode mode. I've enabled it only for Avermedia 
  M135A, 
  since this is the board I'm using at the IR refactoring tests, but the 
  same approach
  should work fine for any other saa7134 board that uses GPIO18 or GPIO16. 
  For GPIO18,
  all you need is to use something like:
 
  case SAA7134_BOARD_AVERMEDIA_M135A:
  ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
  mask_keydown = 0x004;
  mask_keyup   = 0x004;
  mask_keycode = 0x;
  raw_decode   = 1;
  break;
 
  (Of course, replacing the board name by your board name 
  (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
  and pointing to the proper ir_codes table. You'll likely need to write one 
  table for
  the IR that were shipped with your board.
 
  To do that, you'll need to enable debug at ir_core (modprobe ir_core 
  debug=1), and type every
  key on your keyboard, associating the scancode number with a key name. See 
  http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference 
  of the most comon keycodes.
 
  For example, pressing the power button of an IR I have here (for Leadtek 
  PVR3000), it
  gives this info at the dmesg log:
  ir_nec_decode: NEC scancode 0x0300
 
  All I need to do is to write a new keymap:
 
  add a new media/rc-map.h
 
 
   as, for example:
 drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
  (copying one of the existing keymaps) and add:
 
  static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
 { 0x300, KEY_POWER2 },
 
  for every key that it is there. Then, add the new file at 
  drivers/media/IR/keymaps/Makefile.
 
  I've tried to summarize the above patches on a change I just did at the 
  wiki page. Feel 
  free to improve it, if needed.
 
  Cheers,
  Mauro
  
  Hi Mauro,
  
  what I did try to point to, with some sarcasm involved, is that I can't
  advice any v4l-dvb as reference anymore.
  
  To start to look such up, with all patches involved, per user, who
  likely does not know himself on what he exactly is, find the last
  building kernel for him then, guess on pending pull requests that time,
  and so on, is not making any sense for me.
  
  Should we not state, that is nothing against Douglas at all or Hans with
  his build reports, please be on latest .rc and git to test anything we
  have around?
  
  We are out of sync else.
 
 Hermann,
 
 Sorry, but, sometimes, it is very hard to understand your English. I'm 
 suspecting
 that you're referring to the sync between hg and git.
 
 Short answer:
 
 
  - AFAIK, Douglas finished syncing the trees at the night of May, 12.
 
  - Developers primary reference tree:
   http://git.linuxtv.org/v4l-dvb.git
 
  - Backport tree:
   http://linuxtv.org/hg/v4l-dvb
 
As the backport is manual, some delay is expected at the backport tree. 
 Also,
 backports are made at the best efforts basis. So, nobody can warrant that the
 drivers will behave correctly with an old kernel. Also, eventually, the 
 backport tree
 can break when compiled with an older kernel.
 
Developers are encouraged to use git for development, but patches and pull
 requests against the backport tree are accepted.
 
 Long answer

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

2010-05-13 Thread hermann pitton
Hi,

Am Donnerstag, den 13.05.2010, 09:32 -0300 schrieb Mauro Carvalho
Chehab:
 hermann pitton wrote:
  Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
  Chehab:
  hermann pitton wrote:
  Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
  Sander Pientka wrote:
  Hi Hermann,
 
  I am going to revive this old thread, I completely forgot about it and
  I still want to solve this problem.
 
  Yes, with the IR transmitter not plugged in, the gpio is reported as
  0 by dmesg.
 
  I am aware there is a picture of the backside missing on the wiki, I
  will try to make one a.s.a.p.
 
  NEC IR support seems to be built-in already: 
  drivers/media/IR/ir-nec-decoder.c.
 
  Besides, dmesg outputs a section of error messages I don't understand:
 
  [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
  i2c_transfer returned: -5
  [ 1585.548229] tda18271_toggle_output: error -5 on line 47
  [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
  i2c_transfer returned: -5
  [ 1585.720129] tda18271_init: error -5 on line 826
  [ 1585.720136] tda18271_tune: error -5 on line 904
  [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
  [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
  i2c_transfer returned: -5
  [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
  i2c_transfer returned: -5
  [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
  i2c_transfer returned: -5
  [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
  [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
 
 
  Do you have any idea about the origin of these errors? Do you think
  they affect the IR functionality?
  The above errors won't change anything at IR side. For IR, the better 
  approach
  is to start using raw_decode mode. I've enabled it only for Avermedia 
  M135A, 
  since this is the board I'm using at the IR refactoring tests, but the 
  same approach
  should work fine for any other saa7134 board that uses GPIO18 or GPIO16. 
  For GPIO18,
  all you need is to use something like:
 
  case SAA7134_BOARD_AVERMEDIA_M135A:
  ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
  mask_keydown = 0x004;
  mask_keyup   = 0x004;
  mask_keycode = 0x;
  raw_decode   = 1;
  break;
 
  (Of course, replacing the board name by your board name 
  (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
  and pointing to the proper ir_codes table. You'll likely need to write 
  one table for
  the IR that were shipped with your board.
 
  To do that, you'll need to enable debug at ir_core (modprobe ir_core 
  debug=1), and type every
  key on your keyboard, associating the scancode number with a key name. 
  See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a 
  reference of the most comon keycodes.
 
  For example, pressing the power button of an IR I have here (for Leadtek 
  PVR3000), it
  gives this info at the dmesg log:
  ir_nec_decode: NEC scancode 0x0300
 
  All I need to do is to write a new keymap:
 
  add a new media/rc-map.h
 
 
   as, for example:
   drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
  (copying one of the existing keymaps) and add:
 
  static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
   { 0x300, KEY_POWER2 },
 
  for every key that it is there. Then, add the new file at 
  drivers/media/IR/keymaps/Makefile.
 
  I've tried to summarize the above patches on a change I just did at the 
  wiki page. Feel 
  free to improve it, if needed.
 
  Cheers,
  Mauro
  Hi Mauro,
 
  what I did try to point to, with some sarcasm involved, is that I can't
  advice any v4l-dvb as reference anymore.
 
  To start to look such up, with all patches involved, per user, who
  likely does not know himself on what he exactly is, find the last
  building kernel for him then, guess on pending pull requests that time,
  and so on, is not making any sense for me.
 
  Should we not state, that is nothing against Douglas at all or Hans with
  his build reports, please be on latest .rc and git to test anything we
  have around?
 
  We are out of sync else.
  Hermann,
 
  Sorry, but, sometimes, it is very hard to understand your English. I'm 
  suspecting
  that you're referring to the sync between hg and git.
 
  Short answer:
  
 
   - AFAIK, Douglas finished syncing the trees at the night of May, 12.
 
   - Developers primary reference tree:
 http://git.linuxtv.org/v4l-dvb.git
 
   - Backport tree:
 http://linuxtv.org/hg/v4l-dvb
 
 As the backport is manual, some delay is expected at the backport tree. 
  Also,
  backports are made at the best efforts basis. So, nobody can warrant that 
  the
  drivers will behave correctly with an old kernel. Also, eventually, the 
  backport tree
  can break when compiled with an older kernel.
 
 Developers are encouraged to use git

Re: Remote control at Zolid Hybrid TV Tuner

2010-05-12 Thread hermann pitton
Hi Sander,

Am Samstag, den 08.05.2010, 16:12 +0200 schrieb Sander Pientka:
 Hi Hermann,
 
 I am going to revive this old thread, I completely forgot about it and
 I still want to solve this problem.
 
 Yes, with the IR transmitter not plugged in, the gpio is reported as
 0 by dmesg.
 
 I am aware there is a picture of the backside missing on the wiki, I
 will try to make one a.s.a.p.
 
 NEC IR support seems to be built-in already: 
 drivers/media/IR/ir-nec-decoder.c.
 
 Besides, dmesg outputs a section of error messages I don't understand:
 
 [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
 i2c_transfer returned: -5
 [ 1585.548229] tda18271_toggle_output: error -5 on line 47
 [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
 i2c_transfer returned: -5
 [ 1585.720129] tda18271_init: error -5 on line 826
 [ 1585.720136] tda18271_tune: error -5 on line 904
 [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
 [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
 i2c_transfer returned: -5
 [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
 i2c_transfer returned: -5
 [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
 i2c_transfer returned: -5
 [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
 [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
 
 
 Do you have any idea about the origin of these errors? Do you think
 they affect the IR functionality?
 

you are still welcome with such delayed reports.

But I don't have any influence anymore, how such are treated.

For the tda18271 stuff, you must be on latest and Michael Krufky should
take it on.

For to be on latest, I also can't give any advice anymore.

For the IR/remote stuff, try with Mauro and all others working through.

Cheers,
Hermann

 --
 
 Sander Pientka
 
 2010/2/17 hermann pitton hermann-pit...@arcor.de:
  Hi,
 
  Am Mittwoch, den 17.02.2010, 17:38 +0100 schrieb Sander Pientka:
  Thanks for your answer. If I understand you correctly, I should
  disattach the IR receiver, which is a cable with a diode at the end?
  It is plugged in to a port like the green one for audio.
 
  did you remove the copy to the list by will?
 
  Then I will not complain about top posting here ;)
 
  I think we have only a photo of the frontside of that card.
 
  One line from the IR input connector vanishes to the backside.
 
  If on the backside is not a dedicated IR controller chip, gpio18 might
  be in use for the remote. This gpio is capable of triggering IRQs and is
  also connected to the clock.
 
  On recent Asus saa713x cards it is used for some RC5 protocol derived
  from those IRQs, gpio18 is the up/down button and the only changing gpio
  pin concerning the remote. That pin goes low, if the receiver is not
  plugged on the Asus cards.
 
  Mauro recently added also support for NEC IR protocol also on that gpio.
 
  You should be able to track rc5 and nec support from the mercurial/cvs
  interface or from the lists. Maybe it gets you started.
 
  Cheers,
  Hermann
 
  2010/2/17 hermann pitton hermann-pit...@arcor.de:
   Hi Sander,
  
   Am Dienstag, den 16.02.2010, 20:16 +0100 schrieb Sander Pientka:
   Hi,
  
   my Zolid Hybrid TV Tuner has been working like a charm for over two
   months now. The remote control is not working though, which is a
   showstopper. I don't have experience with remote controls in any kind,
   I've heard of LIRC but I would rather choose a more elegant solution,
   for instance evdev in X11.
  
   It's wiki page: 
   http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner
  
   gpio init of your board is reported as 0x24.
  
   So gpio18/0x4 is high.
  
   Assuming the IR receiver is plugged during that, unplug it on next boot
   and see if gpio init is now only 0x20.
  
   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: Remote control at Zolid Hybrid TV Tuner

2010-05-12 Thread hermann pitton

Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
 Sander Pientka wrote:
  Hi Hermann,
  
  I am going to revive this old thread, I completely forgot about it and
  I still want to solve this problem.
  
  Yes, with the IR transmitter not plugged in, the gpio is reported as
  0 by dmesg.
  
  I am aware there is a picture of the backside missing on the wiki, I
  will try to make one a.s.a.p.
  
  NEC IR support seems to be built-in already: 
  drivers/media/IR/ir-nec-decoder.c.
  
  Besides, dmesg outputs a section of error messages I don't understand:
  
  [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
  i2c_transfer returned: -5
  [ 1585.548229] tda18271_toggle_output: error -5 on line 47
  [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
  i2c_transfer returned: -5
  [ 1585.720129] tda18271_init: error -5 on line 826
  [ 1585.720136] tda18271_tune: error -5 on line 904
  [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
  [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
  i2c_transfer returned: -5
  [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
  i2c_transfer returned: -5
  [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
  i2c_transfer returned: -5
  [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
  [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
  
  
  Do you have any idea about the origin of these errors? Do you think
  they affect the IR functionality?
 
 The above errors won't change anything at IR side. For IR, the better approach
 is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
 since this is the board I'm using at the IR refactoring tests, but the same 
 approach
 should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For 
 GPIO18,
 all you need is to use something like:
 
 case SAA7134_BOARD_AVERMEDIA_M135A:
 ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
 mask_keydown = 0x004;
 mask_keyup   = 0x004;
 mask_keycode = 0x;
 raw_decode   = 1;
 break;
 
 (Of course, replacing the board name by your board name 
 (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
 and pointing to the proper ir_codes table. You'll likely need to write one 
 table for
 the IR that were shipped with your board.
 
 To do that, you'll need to enable debug at ir_core (modprobe ir_core 
 debug=1), and type every
 key on your keyboard, associating the scancode number with a key name. See 
 http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of 
 the most comon keycodes.
 
 For example, pressing the power button of an IR I have here (for Leadtek 
 PVR3000), it
 gives this info at the dmesg log:
 ir_nec_decode: NEC scancode 0x0300
 
 All I need to do is to write a new keymap:
 
 add a new media/rc-map.h
 
 
  as, for example:
   drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
 (copying one of the existing keymaps) and add:
 
 static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
   { 0x300, KEY_POWER2 },
 
 for every key that it is there. Then, add the new file at 
 drivers/media/IR/keymaps/Makefile.
 
 I've tried to summarize the above patches on a change I just did at the wiki 
 page. Feel 
 free to improve it, if needed.
 
 Cheers,
 Mauro

Hi Mauro,

what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.

To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.

Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?

We are out of sync else.

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: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)

2010-05-11 Thread hermann pitton
Hi Thierry,

Am Dienstag, den 11.05.2010, 16:50 +0200 schrieb Thierry LELEGARD:
 I finally gave up using this card. I replaced it with an old
 Hauppauge WinTV Nova-S in the same PCI slot and the same transponder
 is received fine. No discontinuity is observed. Using the Nova-HD-S2
 in the same PCI slot, on the same transponder, gave a lot of
 discontinuities, correlated with the pci_abort errors.
 
 I think that the Hauppauge WinTV Nova-HD-S2 should be marked as
 partially supported only since it seems to work fine on some
 systems and poorly in other systems (mine).
 
 -Thierry
 

I can confirm, that such usage conditions do exist also on other
hardware.

There is not any stable HD and S2 support even on m$.

Hermann


  
  Without knowing if this is appropriate or not, as a test, I replaced
  the 3 occurrences of IRQF_SHARED | IRQF_DISABLED by simply IRQF_SHARED
  in cx88 driver.
  
  The number of pci_abort was considerably reduced but I still get some.
  
  Again, this was just a try, not a patch proposal. And it seems not to
  be a final solution, but it just changed the behavior a little bit.
  
  Any other idea ?
  
  -Thierry
  
   -Message d'origine-
   De : linux-media-ow...@vger.kernel.org 
   [mailto:linux-media-ow...@vger.kernel.org] De la part de
   Thierry LELEGARD
   Envoyé : vendredi 7 mai 2010 11:38
   À : Paul Shepherd; linux-media@vger.kernel.org
   Objet : RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
  
   Hi,
  
   The firmware version can be seen using dmesg the first time
   the tuner is actually used after power up. From dmesg:
  
   cx24116_firmware_ondemand: Waiting for firmware upload 
   (dvb-fe-cx24116.fw)...
   cx88-mpeg driver manager :05:05.2: firmware: requesting 
   dvb-fe-cx24116.fw
   cx24116_firmware_ondemand: Waiting for firmware upload(2)...
   cx24116_load_firmware: FW version 1.26.90.0
   cx24116_firmware_ondemand: Firmware upload complete
  
   By removing or swapping cards on the PCI bus, I can see that
   the number of cx88[0]: irq mpeg [0x8] pci_abort varies.
   From once every 10 seconds, at best, to once per second, at
   worst.
  
   The following message can be interesting:
   IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
  
   After some googling, I saw messages mentioning that this kind
   of message can be the symptom of unexpected behaviors. Could
   this explain the pci_abort ?
  
   Also, some messages suggest that a driver code should not
   request both IRQF_DISABLED and IRQF_SHARED. In the complete
   v4l-dvb source code, this combination is found only 20 times,
   in 12 drivers, including the cx88.
  
   Could this be a problem in the driver ?
  
   -Thierry
  
-Message d'origine-
De : Paul Shepherd [mailto:p...@whitelands.org.uk]
Envoyé : jeudi 6 mai 2010 20:59
À : linux-media@vger.kernel.org
Cc : Thierry LELEGARD
Objet : Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
   
   
On 06/05/2010 16:01, Thierry LELEGARD wrote:
   

 I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system.
 I experience frequent packet loss and pci_abort errors.

 Each time my application detects packet loss (continuity errors
 actually), I get the following messages in dmesg:

 cx88[0]: irq mpeg  [0x8] pci_abort*
 cx88[0]/2-mpeg: general errors: 0x0008

 Such problems occur every few seconds.

 I use firmware file dvb-fe-cx24116.fw version 1.26.90.0.

 Since the IRQ was shared with the nVidia card and a Dektec modulator,
 I swapped some PCI boards. The IRQ is still shared but with another
 Tuner I do not use when using the S2 tuner. After swapping the PCI
 boards, the errors occur less frequently but still happen.

 Assuming that the pci_abort was due to an interrupted DMA transfer, I
 tried to increase the PCI latency timer of the device to 248 but this
 did not change anything (setpci -s 05:05 latency_timer=f8).

 I use the tuner with a custom application which reads the complete
 Transport stream. This application had worked for years using DVB-T
 and DVB-S tuners. I tried to reduce the application read buffer
 input size and it did not change anything at all.

 Note that my application still uses the V3 API, not the S2API. But,
 using DVB-S transponders, it works (except the pci_abort errors).

 I disabled the serial port, the parallel port and the PS/2 ports in 
 the
 BIOS. It did not change anything either.

 Does anyone have an idea, please?
 Thanks a lot in advance for any help.
 -Thierry
   
I have the board working in a Ubuntu 9.10 system, log below shows no pci
errors:
   
 Apr 21 18:32:11 antec300 kernel: [   16.576416] cx88/2: cx2388x 
 MPEG-TS Driver Manager version
   0.0.7
loaded
 Apr 21 18:32:11 antec300 kernel: [   16.576711] cx88[0]: subsystem: 
 0070:6906, board: 

Re: [PATCH] TT S2-1600 allow more current for diseqc

2010-04-30 Thread hermann pitton
Hi,

Am Mittwoch, den 28.04.2010, 17:13 +0400 schrieb Manu Abraham:
 On Wed, Apr 28, 2010 at 12:33 PM, Guy Martin gms...@tuxicoman.be wrote:
  On Wed, 28 Apr 2010 09:45:39 +0200
  André Weidemann andre.weidem...@web.de wrote:
 
  I advise not to pull this change into the kernel sources.
  The card has only been testet with the a maximum current of 515mA.
  Anything above is outside the specification for this card.
 
 
  I'm currently running two of these cards in the same box with this
  patch.
  Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because
  sometimes diseqc wasn't working fine and that seemed to solve the
  problem.
 
 I would advise to not do this: since disabling current limiting etc
 will cause a large problem in the case of a short circuit thereby no
 protection to the hardware. In such an event, it could probably damage
 the tracks carrying power on the card as well as the tracks on the
 motherboard, and in some cases the gold finches themselves and or the
 PCI connector.
 
 Generally, there are only a few devices capable of sourcing  0.5A, So
 I wonder 
 
 Regards,
 Manu

for the few devices I do have, you seem to be for sure right.

All the Creatix stuff drawing up to 900mA on a potentially dual isl6405
has direct voltage from the PSU over an extra floppy connector.

Max. 500mA should be sufficient with a DiSEqC 1.2 compliant rotor.
Nothing else should come above that limit.

I wonder, if someone close in reading specs just now, can tell if 900mA
can be sufficient for two rotors ;)

Andre, BTW, assuming you still have a CTX944 (md8800 Quad), can you
measure if the 16be:0008 device really does switch between 13 and 18V.

Mine does not, but is also not in the original PC and the 0007 and 0008
devices are swapped on the PCI bus compared to that one.

Seen from my limited skills, it should not make any difference. So I
don't know why some did report all is fine on 0008 and I can only say it
hangs on 18V after init from the i2c capable 0007 device and on exit it
powers down properly, that's all, but _never_ is on 13V.

Be aware, that RF loopthrough between the two DVB-S tuners is
enabled ...

Thanks,
Hermann







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


Re: [PATCH] TT S2-1600 allow more current for diseqc

2010-04-30 Thread hermann pitton
Hi André,

Am Freitag, den 30.04.2010, 07:44 +0200 schrieb André Weidemann:
 Hi Hermann,
[snip]
 
  Andre, BTW, assuming you still have a CTX944 (md8800 Quad), can you
  measure if the 16be:0008 device really does switch between 13 and 18V.
 
 You seem to mistake me for someone else. I do not have a CTX944 and 
 never had.
 
 Regards
   André

yes, sorry, over the years with tda10086 questions and those about BBC
HD reception I confused Weidemann with Weymann (Helmut), who had such a
device in 2005.

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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)

2010-04-26 Thread hermann pitton

Am Montag, den 26.04.2010, 21:51 +1000 schrieb 0123pe...@gmail.com:

[snip]

If it is a additional new regression, then mercurial bisect can find 
the
patch in question fairly quick.
   
   That sounds like something that I should be able to do, if only 
   I'd read the instructions.  
   
   It is totally up to you and all others with that hardware.
  
  Can you provide a like for where to start reading?
  
  README.patches.  
  
   Part III - Best Practices
  1. Community best practices
  2. Mercurial specific procedures
  3. Knowing about newer patches committed at the development repositories
  4. Patch submission from the community
  5. Identifying regressions with Mercurial
 
 I have not found the file README.patches.  
 

Peter, for that one.

yum, or whatever, install mercurial.

hg clone http://linuxtv.org/hg/v4l-dvb;
cd v4l-dvb
less README.patches

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: Issue loading SAA7134 module

2010-04-21 Thread hermann pitton

Am Mittwoch, den 21.04.2010, 13:22 -0300 schrieb Donald Bailey:
 I've got a couple of boxes that have two no-name 8-chip SAA713X cards.  
 Both have the same issue: the kernel will only set up the first eight on 
 one board and only two on the second.  It leaves the other six unusable 
 with error -23.  I am unable to figure out what that means.
 
 Sample dmesg as follows.  More (/proc/ioports, /proc/interrupts, etc) 
 can be posted if requested.  Tried kernels 2.6.18 and 2.6.33.2 on CentOS 
 5.4 and Fedora 11 fully updated. The module is loaded as card=0. The 
 following is output for chips 11 through 16.
 
 saa7130[10]: subsystem: 1131:, board: UNKNOWN/GENERIC 
 [card=0,autodetected]
 saa7130[10]: board init: gpio is 1
 saa7130[10]: Huh, no eeprom present (err=-5)?
 saa7130[10]: can't register video device
 saa7134: probe of :05:0f.0 failed with error -23
 

Due to some unknown bug we have ;), it likely works only perfectly with
unidentified devices with more than 128 saa713x chips in a single PCI
slot.

Read on the wiki, about how to add a new device, and feel free to
improve it. 

China is going totally mad. (or is it from somewhere else?)

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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)

2010-04-15 Thread hermann pitton
Hi Peter,

Am Donnerstag, den 15.04.2010, 23:30 +1000 schrieb 0123pe...@gmail.com:
 on Thu, 15 Apr 2010 01:32 pm
 in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure
 hermann pitton wrote:
 
  Hi,
  
  to be honest, there is a little too much delay on those reports.
 
 I have been very slow, sorry.  

no problem, but it becomes also a little hard to me to recap the issues.

As said, Hartmut had the best pointers I guess.

   did not even notice a problem with Trent's prior patch.
   The same is also at vivi.
   
   Should I have a file called /etc/modprobe.d/TVanywhereAD 
   that contains the line, 
   
   options saa7134 card=94 gpio_tracking i2c_debug=1
   
   and then watch the command line output of kaffeine?  
  
  I've found a GUI that allows tweaking lots of module parameters 
  that I have never heard of.  Card=94 in the config file, 
  gpio_tracking and i2c_debug are set to 1 in the GUI.  
  
  Strange things are appearing in dmesg and syslog.  I assume that 
  [snip]
  saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  i2c-adapter i2c-0: Invalid 7-bit address 0x7a
  saa7133[0]: i2c xfer:  8e ERROR: NO_DEVICE
  [snip]
  is significant.  
  
  No, not at all for my knowledge.
 
 Unsurprisingly, that just highlights my ignorance.  
 
   If you want to produce debug output for failing firmware loading from
   file after a cold boot, yes, you might eventually be able to see that
   failing tuner initialization brings down i2c.
   
   If it is a additional new regression, then mercurial bisect can find the
   patch in question fairly quick.
  
  That sounds like something that I should be able to do, if only 
  I'd read the instructions.  
  
  It is totally up to you and all others with that hardware.
 
 Can you provide a like for where to start reading?

README.patches.  

 Part III - Best Practices
1. Community best practices
2. Mercurial specific procedures
3. Knowing about newer patches committed at the development repositories
4. Patch submission from the community
5. Identifying regressions with Mercurial

  Since already in some multiple broken conditions, never working without
  flaws previously, I would suggest not to wait any longer, until some
  sort of hadron collider is available ...
 
 Now I'm discouraged.  It might be a better use of my time to do 
 something else - anything else.  Maybe I'll just put it in a box 
 for a year and see what happens.  

I (un)fortunately ;) don't have such hardware and Hartmut did not have
any at that time either.

Don't just wait, also no need to hurry on next day.

If the problem is described well, someone can take it as a challenge to
work on it. We indeed had people from CERN fixing tuners.

Trying to recap.

You have been interested to add the card to auto detection, but firmware
load was only successful in one of three cases only already that time
and we have not been aware of that flaw in the beginning.

Hartmut assumed later, on such a card is some locking protection needed
during the firmware load, and my guess is the longish tuner
initialization sequence gets corrupted, because of that missing locking,
and all goes doom. (at least well known on all of such before any
support for the tda8275a)

Now, improved, only one of ten tries loads the firmware and keeps the
card in a responding state. That is of course also very unpleasant for
using mercurial bisect, I really do admit.

Also, as reported too now, with two of such kind of cards in one
machine, likely better don't try at all.

OTOH, the m$ driver obviously does manage to load the firmware even for
multiple such cards. (but maybe breaks all others ...)

Which doesn't help us, since rebooting after that only hides our
problem.

Those cards following the Philips/NXP/Trident reference designs do not
have it, but I don't test per day anymore. (we have problems with
different cards with the same PCI subsystem IDs and different LNAs too,
introduced by OEMs)

So, on some first thought, which is only as random as the card's
behavior, debug logs from the time it was added might be useful.
(i2c works/works not)

That it is now even worse, is still a chance to find out something more
and not only a improved regression on something never working properly.

If the hardware is not going out of specs by will, excluding others, OEM
engineers, having more details, can still help to improve it for us too.

Anyway, we should have start with some #ifdef 0 on it.

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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)

2010-04-14 Thread hermann pitton
Hi,

to be honest, there is a little too much delay on those reports.

  did not even notice a problem with Trent's prior patch.
  The same is also at vivi.
  
  Should I have a file called /etc/modprobe.d/TVanywhereAD 
  that contains the line, 
  
  options saa7134 card=94 gpio_tracking i2c_debug=1
  
  and then watch the command line output of kaffeine?  
 
 I've found a GUI that allows tweaking lots of module parameters 
 that I have never heard of.  Card=94 in the config file, 
 gpio_tracking and i2c_debug are set to 1 in the GUI.  
 
 Strange things are appearing in dmesg and syslog.  I assume that 
 [snip]
 saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 i2c-adapter i2c-0: Invalid 7-bit address 0x7a
 saa7133[0]: i2c xfer:  8e ERROR: NO_DEVICE
 [snip]
 is significant.  

No, not at all for my knowledge.

  If you want to produce debug output for failing firmware loading from
  file after a cold boot, yes, you might eventually be able to see that
  failing tuner initialization brings down i2c.
  
  If it is a additional new regression, then mercurial bisect can find the
  patch in question fairly quick.
 
 That sounds like something that I should be able to do, if only 
 I'd read the instructions.  

It is totally up to you and all others with that hardware.

Since already in some multiple broken conditions, never working without
flaws previously, I would suggest not to wait any longer, until some
sort of hadron collider is available ...

First try in all known ways.

We likely don't have the budget for anything else that 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


Re: [PATCH] DVB-T initial scan file for Israel (dvb-utils)

2010-04-09 Thread hermann pitton
Hi Shaul,

Am Samstag, den 10.04.2010, 02:16 +0300 schrieb Shaul Kremer:
 Hi,
 
 Here is an initial scan file for IBA's DVB-T transmitters.
 
 Generated from info at http://www.iba.org.il/reception/ (Hebrew)
 
 # HG changeset patch
 # User Shaul Kremer shau...@gmail.com
 # Date 1270854557 -10800
 # Node ID ac84f6db6f031db82509c247ac1775ca48b0e2f3
 # Parent  7de0663facd92bbb9049aeeda3dcba9601228f30
 Added DVB-T initial tuning tables for Israel.
 
 diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN1
 --- /dev/null   Thu Jan 01 00:00:00 1970 +
 +++ b/util/scan/dvb-t/il-SFN1   Sat Apr 10 02:09:17 2010 +0300
 @@ -0,0 +1,4 @@
 +# Israel, Israel Broadcasting Authority's SFN-1 transmitter (northern Israel)
 +# Generated from list in http://www.iba.org.il/reception/
 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
 +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE
 diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN2
 --- /dev/null   Thu Jan 01 00:00:00 1970 +
 +++ b/util/scan/dvb-t/il-SFN2   Sat Apr 10 02:09:17 2010 +0300
 @@ -0,0 +1,4 @@
 +# Israel, Israel Broadcasting Authority's SFN-2 transmitter (central Israel)
 +# Generated from list in http://www.iba.org.il/reception/
 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
 +T 51400 8MHz 2/3 NONE QAM16 8k 1/4 NONE
 diff -r 7de0663facd9 -r ac84f6db6f03 util/scan/dvb-t/il-SFN3
 --- /dev/null   Thu Jan 01 00:00:00 1970 +
 +++ b/util/scan/dvb-t/il-SFN3   Sat Apr 10 02:09:17 2010 +0300
 @@ -0,0 +1,4 @@
 +# Israel, Israel Broadcasting Authority's SFN-3 transmitter (southern Israel)
 +# Generated from list in http://www.iba.org.il/reception/
 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
 +T 53800 8MHz 2/3 NONE QAM16 8k 1/4 NONE

why you don't put them into one scan file for now?

scan for sure does not know about any difference between northern and
southern Israel from the above and to scan the central transponder too
in one run might cost in worst case a few seconds.

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: [RFC] What are the goals for the architecture of an in-kernel IR system?

2010-04-09 Thread hermann pitton
Hi!

Am Freitag, den 09.04.2010, 20:32 -0300 schrieb Mauro Carvalho Chehab:
 Andy Walls wrote:
  On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
  On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
  [1] Basically, a keycode (like KEY_POWER) could be used to wake up the 
  machine. So, by
  associating some scancode to KEY_POWER via ir-core, the driver can 
  program the hardware
  to wake up the machine with the corresponding scancode. I can't see a 
  need for a change at
  ir-core to implement such behavior. Of course, some attributes at sysfs 
  can be added
  to enable or disable this feature, and to control the associated logic, 
  but we first
  need to implement the wakeup feature at the hardware driver, and then 
  adding some logic
  at ir-core to add the non-hardware specific code there.
  Really?  Have you actually seen any hardware where a particular scan
  code can be used to wake up the hardware?  The only hardware I have
  seen has the ability to unsuspend on arrival of IR traffic, but you
  didn't have the granularity to dictate that it only wake up on
  particular scancodes.
  
  The CX23888 and CX23102 can do it.  Basically any IR pulse pattern your
  heart desires; within reason.  And any carrier freq you want too; within
  reason.
  
  But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere
  near properly supporing suspend/resume for their main video and DMA
  functions, AFAIK.
 
 AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching 
 TV,
 do a suspend and waking the hardware again, and you'll keep seeing the same
 channel (I tested it some time ago, when the proper suspend code were added,
 on analog mode, with alsa enabled). Other drivers can suspend/resume, but
 they won't properly restore the video registers, so, you'll see artifacts when
 it returns.

Yes, that was Maxim with enough testers around and Matthias Schwarzott
had fixes.

To remind, we don't recover from suspend on DVB, needs to reload the
driver once. We are also not MFE ready with mixed init calls through v4l
and dvb.

But yes, analog is on leading edge on that ;)

Cheers,
Hermann

 So, yes, you're right: before any suspend/resume code on those drivers, we
 first need to add some code to properly handle kernel threads and work queues
 during suspend, and to restore all the registers to a sane state at resume,
 before implementing IR wakeup on them.
 
 In the case of mceusb, as there is already an userspace code for it on lirc,
 it would probably not be that hard to make this feature to work with ir-core.
 
 [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software
 decoder, the IR IRQ might be used to wake, but this means that everything,
 even a glitch, would wake the hardware, so this won't work neither.
 

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


Re: RFC: exposing controls in sysfs

2010-04-07 Thread hermann pitton
Hi,

Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch:
 Am 06.04.2010 16:33, schrieb Mike Isely:
[snip]
 
  Mike, do you know of anyone actively using that additional information?
 
  Yes.
 
  The VDR project at one time implemented a plugin to directly interface
  to the pvrusb2 driver in this manner.  I do not know if it is still
  being used since I don't maintain that plugin.
 
   Just FYI:
   The PVR USB2 device is now handled by the pvrinput-plugin, which uses only 
 ioctls. The old pvrusb2-plugin is obsolete.
 
   http://projects.vdr-developer.org/projects/show/plg-pvrinput
 
 Regards,
 Lars.

[snip]

thanks Lars.

Mike is really caring and went out for even any most obscure tuner bit
to help to improve such stuff in the past, when we have been without any
data sheets.

To open second, maybe third and even forth ways for apps to use a
device, likely going out of sync soon, does only load maintenance work
without real gain.

We should stay sharp to discover something others don't want to let us
know about. All other ideas about markets are illusions. Or?

So, debugfs sounds much better than sysfs for my taste.

Any app and any driver, going out of sync on the latter, will remind us
that backward compat _must always be guaranteed_  ...

Or did change anything on that and is sysfs excluded from that rule?

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: RFC: exposing controls in sysfs

2010-04-06 Thread hermann pitton
Hi,

Am Mittwoch, den 07.04.2010, 00:39 +0200 schrieb Hans Verkuil:
 On Tuesday 06 April 2010 17:16:17 Mike Isely wrote:
  On Tue, 6 Apr 2010, Laurent Pinchart wrote:
  
   Hi Andy,
   
   On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
   
   [snip]
[snip]
  code.  I don't know if that same strategy could be done in the V4L core.  
  If it could, then this would probably alleviate a lot of concerns about 
  testing / maintenance going forward.
 
 In other words, yes, it could do this. And with relatively little work and
 completely transparent to all drivers.
 
 But I have a big question mark whether we really want to go that way. The
 good thing about it is that the ioctls remain the primary API, as they should
 be. Anything like this will definitely be a phase 3 (or 4, or...), but it
 is at least nice to realize how easy it would be. That's a good sign of the
 quality of the code.
 
 Regards,
 
   Hans

that all looks really good now and quite promising, also IR/remote.

Maybe too good?

About what might be upcoming problems nobody is talking about currently.

Never seen before ...

I would wonder a lot, if we really should have made it close to such
with a lot of buffering all around ;)

Well, I guess the time on that beach might be short.

Manu gave some pointers previously that HD+ is a serious issue for us,
also it seems, that some lower level of firmware starts to hide GPIO's
and i2c addresses on recent boards.

We likely should stay hackish and able for quick responses and not
over-engineer convenience we do not really have.

Just my two cents.

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


Aw: Re: [RFC] Serialization flag example

2010-04-03 Thread hermann-pitton
 


- Original Nachricht 
Von: Andy Walls awa...@md.metrocast.net
An:  Mauro Carvalho Chehab mche...@redhat.com
Datum:   03.04.2010 02:47
Betreff: Re: [RFC] Serialization flag example

 On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote:
  Devin Heitmueller wrote:
 
  In the case of a V4L x DVB type of lock, this is not to protect some
 memory, but,
  instead, to limit the usage of a hardware that is not capable of
 simultaneously
  provide V4L and DVB streams. This is a common case on almost all devices,
 but, as
  Hermann pointed, there are a few devices that are capable of doing both
 analog
  and digital streams at the same time, but saa7134 driver currently doesn't
 support.

Mauro, to do digital and analog at once is not restricted to a few devices.

The only restriction, except those hybrid tuners do have, is that in dual mode 
only 
packed video formats are allowed for analog, since planar formats are using DMA 
channel five, which is already in use by the TS interface then.

 I know a driver that does:

Me too ;) and Trent tested on cx88xx, IIRC.
 
 cx18 can handle simultaneous streaming of DTV and analog.

Yup. Not to talk about recent PCIe devices.
During I'm writing this I watch DVB-S, DVB-T and Composite at once on a
single saa7231e on vista. Supports also S2 and HDTV, vbi and radio and can
have a dual remote interface.
http://www.creatix.de/produkte/multimedia/ctx1924.htm

 Some cards have both an analog and digital tuner, so both DTV and analog
 can come from an RF source simultaneously.  (No locking needed really.)

We have quite some such cards with two tuners on the saa7134 since 2005.
Also such with three and even four tuners, two of them hybrid.

Even the simplest variant, say with a single DVB-S only tuner, can still have 
external 
analog baseband at once from TV, STB, VCR or whatever.

 Some cards only have one tuner, which means simultaneous streaming is
 limited to DTV from RF and analog from baseband inputs.  Streaming
 analog from an RF source on these cards precludes streaming of DTV.  (An
 odd locking ruleset when you consider MPEG, YUV, PCM, and VBI from the
 bridge chip can independently be streamed from the selected analog
 source to 4 different device nodes.)

On that mentioned Medion Quad md8080/CTX944 it becomes even more interesting.
Each of the two PCI bridges can only handle one digital and one analog stream 
at once.
That one must know.

And if RF loopthrough is enabled or not is another important point for its 
usage configuration.
For the two hybrid tuners it is a manual switch the driver doesn't know about.

For the two DVB-S tuners it could be switchable in software and one of the LNB 
connectors
could even be used as RF out to another device. (Has usage restrictions)

The user can make a lot of decisions how to use such a card and for sure 
doesn't want
to have any limitations only because of the hybrid tuners.

Cheers,
Hermann
 
 Regards,
 Andy
 



Frohe Ostern! Alles für's Fest der Hasen und Lämmer jetzt im Osterspecial auf 
Arcor.de: http://www.arcor.de/rd/footer.ostern
--
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


Aw: Re: V4L-DVB drivers and BKL

2010-04-01 Thread hermann-pitton
 
Hi!

- Original Nachricht 
Von: Mauro Carvalho Chehab mche...@redhat.com
An:  Devin Heitmueller dheitmuel...@kernellabs.com
Datum:   02.04.2010 01:10
Betreff: Re: V4L-DVB drivers and BKL

 Devin Heitmueller wrote:
  On Thu, Apr 1, 2010 at 5:07 PM, Mauro Carvalho Chehab
  mche...@redhat.com wrote:
  Most i2c locks typically are only held for the duration of a single
  i2c transaction.  What you are proposing would likely result in just
  about every function having to explicitly lock/unlock, which just
  seems bound to be error prone.
  The i2c open/close should be part of the transaction. Of course, there's
 no
  need to send a command to open an already opened gate (yet, from some
 sniff
  dumps, it seems that some drivers for other OS's do it for every single
 i2c
  access).
  
  I'm not even talking about i2c gate control, which is a whole separate
  case where it is applied inconsistently across drivers.  Even under
  Linux, we have lots of cases where there are double opens and double
  closes of the i2c gate, depending on whether the developer is
  controlling the gate from the tuner driver or the demodulator.
  
  What I'm getting at though is that the lock granularity today is
  typically at the i2c transaction level, so something like an demod
  driver attempting to set two disparate registers is likely to be two
  i2c transactions.  Without moving the locking into the caller, the
  other half of the driver can take control between those two
  transactions.  And moving the logic into the caller means we will have
  to litter the code all over the place with lock/unlock calls.
 
 I agree with a caller logic.
 
 Yet, even moving to the caller, an i2c lock is still needed. For example,
 i2c IR
 events are polling at interrupt time, so, they can happen anytime,
 including
 in the middle of one i2c transaction (by transaction, I mean gate
 control+i2c
 read/write ops go get/set a single register).
 
  We've got enough power management problems as it is without adding
  lots additional complexity with little benefit and only increasing the
  likelihood of buggy code.
  For sure a lock at the open() is simple, but I suspect that this may
  cause some troubles with applications that may just open everything
  on startup (even letting the device unused). Just as one example of
  such apps, kmix, pulseaudio and other alsa mixers love to keep the
  mixer node opened, even if nobody is using it.
  
  I'm frankly far less worried about the ALSA devices than I am about
  DVB versus V4L Vdeo/VBI, based on all the feedback I see from real
  users.
 
 Ok, but alsa driver may also try to access things like i2c. For example,
 msp34xx audio controls are reached via I2C.
 
  The cases where we are getting continuously burned are MythTV
  users who don't have their input groups properly defined and as a
  result MythTV attempts to use both digital and analog at the same time
  (input groups themselves are really a hack to deal with the fact that
  the Linux kernel doesn't have any way to inform userland of the
  relationships).

We see the same on other OSs as well.

In fact, to use digital and analog at once is totally valid.

It is much too short to think about a device with a single hybrid tuner,
best known meanwhile for causing troubles.

The Medion Quad (md8080) on the saa713x with two hybrid tuners, 
two DVB-S tuners, four digital and two analog demodulators with two dedicated 
PCI 
bridges, with its restrictions too, is already ancient stuff.

  And the more I think about it, we can probably even implement the
  locking itself in the V4L and DVB core (further reducing the risk of
  some bridge maintainer screwing it up).  All the bridge driver would
  have to do is declare the relationship between the DVB and V4L devices
  (both video and vbi), and the enforcement of the locking could be
  abstracted out.

On older dual tuner, triple and quad stuff it needs granularity through each 
driver 
down to the physically existing device.

No app on any OS seems to have it right. In best case they have some framework 
around to ask the user about his knowledge for what is a go and what a no go.

Newer hardware can really do triple stuff at once for example.
Nothing much left to configure wrong from the user and the app.

But, to start simple, if a single bridge can pass DVB-T and DVB-S at once is as 
important to know these days 
as all details about tuners, demodulators and SECs on a given device. 

That mixture of old and new will continue over years anyway 
and to escape with some easy rules doesn't look simple.

Some either digital or analog does not exist, except for a single hybrid tuner.

Even then, on such a simplest hybrid device, the tuner can be in digital mode 
and without 
any problems you can have analog video from external inputs at once.

 I agree on having some sort of resource locking in core, but this type
 of lock between radio/audio/analog/analog mpeg-encoded/digital/vbi/...
 is 

Re: [PATCH] Fix default state Beholder H6 tuner.

2010-03-31 Thread hermann pitton
Hi Dimitry,

Am Mittwoch, den 31.03.2010, 13:14 +1000 schrieb Dmitri Belimov:
 Hi Hermann
 
  Hi,
  
  Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov:
   Hi
   
   The hybrid tuner FMD1216MEX_MK3 after cold start has disabled IF.
   This tuner has internal I2C switch. This switch switch I2C bus
   between DVB-T and IF part. Default state is DVB-T. When module
   saa7134 is load it can't find IF tda9887 and disable analog TV mode.
   
   This patch set internal I2C switch of the tuner to IF by send
   special value to the tuner as for receive analog TV from low band.
   It can be usefule for other cards.
   
   I didn't set configure a tuner by a tuner model because this tuner
   can has different I2C address. May be we can do it later after
   discuss for more robust support a tuners.
  
  just as a reminder. It is the same for the FMD1216ME hybrid MK3.
  After every boot, analog mode fails with missing tda9887.
  
  Currently, after tuner modules are not independent anymore, one has to
  reload the saa7134 driver once.
  
  Relevant code in tuner.core.c.
  
  case TUNER_PHILIPS_FMD1216ME_MK3:
  buffer[0] = 0x0b;
  buffer[1] = 0xdc;
  buffer[2] = 0x9c;
  buffer[3] = 0x60;
  i2c_master_send(c, buffer, 4);
  mdelay(1);
  buffer[2] = 0x86;
  buffer[3] = 0x54;
  i2c_master_send(c, buffer, 4);
  if (!dvb_attach(simple_tuner_attach, t-fe,
  t-i2c-adapter, t-i2c-addr,
  t-type)) goto attach_failed;
  break;
 
 That is good. I'll try add case TUNER_PHILIPS_FMD1216MEX_MK3 here and test.
 This is much better.

it wont work for any what I can tell.

We were forced into such an universal looking solution, but it was
broken only a short time later.

I for sure don't say that this time, late 2005, it was in anyway
perfect, too much random on module load orders and also duplicate
address stuff around meanwhile.

But, however, it seems to be blocked for a global attempt within the
current schemes too.

Cheers,
Hermann

 With my best regards, Dmitry.
 
  Hermann
  
   diff -r 1ef0265456c8
   linux/drivers/media/video/saa7134/saa7134-cards.c ---
   a/linux/drivers/media/video/saa7134/saa7134-cards.c   Fri Mar
   26 00:54:18 2010 -0300 +++
   b/linux/drivers/media/video/saa7134/saa7134-cards.c   Sun Mar
   28 08:21:10 2010 -0400 @@ -7450,6 +7450,21 @@ } break;
 }
   + case SAA7134_BOARD_BEHOLD_H6:
   + {
   + u8 data[] = { 0x09, 0x9f, 0x86, 0x11};
   + struct i2c_msg msg = {.addr = 0x61, .flags =
   0, .buf = data,
   + .len =
   sizeof(data)}; +
   + /* The tuner TUNER_PHILIPS_FMD1216MEX_MK3 after
   hardware*/
   + /* start has disabled IF and enabled DVB-T. When
   saa7134*/
   + /* scan I2C devices it not detect IF tda9887 and
   can`t  */
   + /* watch TV without software reboot. For solve
   this problem */
   + /* switch the tuner to analog TV mode
   manually. */
   + if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
   + printk(KERN_WARNING
   +   %s: Unable to enable IF of
   the tuner.\n,
   +dev-name);
   + break;
   + }
 } /* switch() */

 /* initialize tuner */
   
   Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
   d.beli...@gmail.com
   
   With my best regards, Dmitry.
  

--
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] Fix default state Beholder H6 tuner.

2010-03-30 Thread hermann pitton
Hi,

Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov:
 Hi
 
 The hybrid tuner FMD1216MEX_MK3 after cold start has disabled IF.
 This tuner has internal I2C switch. This switch switch I2C bus between DVB-T 
 and IF part.
 Default state is DVB-T. When module saa7134 is load it can't find IF tda9887 
 and disable
 analog TV mode.
 
 This patch set internal I2C switch of the tuner to IF by send special value 
 to the tuner as for receive
 analog TV from low band. It can be usefule for other cards.
 
 I didn't set configure a tuner by a tuner model because this tuner can has 
 different I2C address.
 May be we can do it later after discuss for more robust support a tuners.

just as a reminder. It is the same for the FMD1216ME hybrid MK3.
After every boot, analog mode fails with missing tda9887.

Currently, after tuner modules are not independent anymore, one has to
reload the saa7134 driver once.

Relevant code in tuner.core.c.

case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
buffer[3] = 0x60;
i2c_master_send(c, buffer, 4);
mdelay(1);
buffer[2] = 0x86;
buffer[3] = 0x54;
i2c_master_send(c, buffer, 4);
if (!dvb_attach(simple_tuner_attach, t-fe,
t-i2c-adapter, t-i2c-addr, t-type))
goto attach_failed;
break;

Hermann

 diff -r 1ef0265456c8 linux/drivers/media/video/saa7134/saa7134-cards.c
 --- a/linux/drivers/media/video/saa7134/saa7134-cards.c   Fri Mar 26 
 00:54:18 2010 -0300
 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c   Sun Mar 28 
 08:21:10 2010 -0400
 @@ -7450,6 +7450,21 @@
   }
   break;
   }
 + case SAA7134_BOARD_BEHOLD_H6:
 + {
 + u8 data[] = { 0x09, 0x9f, 0x86, 0x11};
 + struct i2c_msg msg = {.addr = 0x61, .flags = 0, .buf = data,
 + .len = sizeof(data)};
 +
 + /* The tuner TUNER_PHILIPS_FMD1216MEX_MK3 after hardware*/
 + /* start has disabled IF and enabled DVB-T. When saa7134*/
 + /* scan I2C devices it not detect IF tda9887 and can`t  */
 + /* watch TV without software reboot. For solve this problem */
 + /* switch the tuner to analog TV mode manually. */
 + if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
 + printk(KERN_WARNING
 +   %s: Unable to enable IF of the tuner.\n,
 +dev-name);
 + break;
 + }
   } /* switch() */
  
   /* initialize tuner */
 
 Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
 
 With my best regards, Dmitry.

--
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 v2 2/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers - part 1

2010-03-29 Thread hermann pitton

Am Montag, den 29.03.2010, 08:40 +0200 schrieb Hans Verkuil:
 Hi Xiaolin,
 
 On Sunday 28 March 2010 16:42:30 Zhang, Xiaolin wrote:
  From 1c18c41be33246e4b766d0e95e28a72dded87475 Mon Sep 17 00:00:00 2001
  From: Xiaolin Zhang xiaolin.zh...@intel.com
  Date: Sun, 28 Mar 2010 21:31:24 +0800
  Subject: [PATCH 2/10] This patch is second part of intel moorestown isp 
  driver and c files collection which is v4l2 implementation.
  
 
 
 
  +struct videobuf_dma_contig_memory {
  +   u32 magic;
  +   void *vaddr;
  +   dma_addr_t dma_handle;
  +   unsigned long size;
  +   int is_userptr;
  +};
  +
  +#define MAGIC_DC_MEM 0x0733ac61
  +#define MAGIC_CHECK(is, should)
  \
  +   if (unlikely((is) != (should))) {   
  \
  +   pr_err(magic mismatch: %x expected %x\n, (is), (should)); 
  \
  +   BUG();  
  \
  +   }
 
 I will do a more in-depth review in a few days. However, I did notice that
 you added your own dma_contig implementation. What were the reasons for doing
 this? I've CC-ed Pawel since he will be interested in this as well.
 
 Another question that came up is: what is 'marvin'? It's clearly a codename,
 but a codename for what? This should be documented at the top of some source
 or header. Apologies if it is already documented, I didn't read everything 
 yet.
 
 A final point I noticed: don't cast away a function result:
 
 (void)ci_isp_set_bp_detection(NULL);
 
 No need for (void). The gcc compiler won't warn about this unless the function
 is annotated with __must_check__.
 
 Regards,
 
   Hans

How to avoid this and similar?

you added your own dma_contig implementation

The answer is very simple.

NACK.

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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)

2010-03-29 Thread hermann pitton
Hi Peter,

Am Montag, den 29.03.2010, 23:10 +1100 schrieb 0123pe...@gmail.com:

 
 Hi Hermann,  
 
 I've been fixing my PC to the state that it stopped working.  
 Hence the delay.  
 
  Hi Peter,
  
  Am Samstag, den 20.03.2010, 16:20 +1100 schrieb 0123pe...@gmail.com:

  
  [snip]
   
   unfortunately the problem with these cards is known, but no good
   solution for now.
   
   Best description is from Hartmut and starts here.
   
   http://www.spinics.net/lists/linux-dvb/msg26683.html
   
  [snip]
  
  Interesting link.  I have one of the cards mentioned 
  (an MSI TV(at)nywhere A/D hybrid).  I've decided not to throw it away.  
  
  to not leave you without any response at least.
  
  In hind sight, seeing how unfortunate using such devices can be, mainly
  because of being forced to try at random again with a cold boot after
  some i2c war brought down the tuner, we better should have such only in
  a still experimental league and not as supported.
  
  This was not foreseeable in such rudeness and neither Hartmut nor me
  have such devices.
  
  The Asus triple OEM 3in1 I have does not have any problems with loading
  firmware from file, the others do all get it from eeprom.
  
  So, actually nobody is investigating on it with real hardware.
  
  Maybe you can catch something with gpio_tracking and i2c_debug=1.
  I would expect that the complex analog tuner initialization gets broken
  somehow. This is at least known to be good to bring all down.
  
  Cheers,
  Hermann
 
 There was a patch about alignment that went through recently.  
 Revert V4L/DVB (11906): saa7134: Use v4l bounding/alignment function
 Maybe that was it.  

did not even notice a problem with Trent's prior patch.
The same is also at vivi.

 Should I have a file called /etc/modprobe.d/TVanywhereAD 
 that contains the line, 
 
 options saa7134 card=94 gpio_tracking i2c_debug=1
 
 and then watch the command line output of kaffeine?  

If you want to produce debug output for failing firmware loading from
file after a cold boot, yes, you might eventually be able to see that
failing tuner initialization brings down i2c.

If it is a additional new regression, then mercurial bisect can find the
patch in question fairly quick.

Mauro has a MSI cardbus device using also the card=94 entry, but at home
he has no DVB-T.

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: Avermedia AVerTV GO 007 FM composite input problem

2010-03-26 Thread hermann pitton

Hi,

Am Freitag, den 26.03.2010, 13:10 +0200 schrieb Andras Barna:
 hi i have a Avermedia AVerTV GO 007 FM card , the problem is that i
 get nothing from Composite, i tried different apps (mplayer, tvtime,
 etc) none works. (television input works)
 ideas?

looking it up from 2005 to now, Composite was never reported as tested,
only S-Video.

On the other hand, vmux=0 is what we regularly see on combined S-Video
and Composite inputs where you need an adapter for Composite over
S-Video. The card has no separate Composite-in connector.

Assuming you did not plug by mistake into the radio antenna input, then
you can also try with vmux 3, 2 and 4 for Composite in saa7134-cards.c.

You might have a look at the manual and/or windows driver, since this
information is not provided to us until now. (bttv-gallery/wiki/lists)

Does it come with any simple 4pin adapter or even with a breakout cable
with more pins and a dedicated yellow RCA input?

Cheers,
Hermann


 here're some infos
 
 [9.361212] saa7130/34: v4l2 driver version 0.2.15 loaded
 [9.361631]   alloc irq_desc for 17 on node -1
 [9.361635]   alloc kstat_irqs on node -1
 [9.361648] saa7134 :00:09.0: PCI INT A - GSI 17 (level, low) - IRQ 
 17
 [9.361768] saa7133[0]: found at :00:09.0, rev: 208, irq: 17,
 latency: 32, mmio: 0xcfffc800
 [9.361955] saa7133[0]: subsystem: 1461:f31f, board: Avermedia
 AVerTV GO 007 FM [card=57,autodetected]
 [9.362198] saa7133[0]: board init: gpio is 8
 [9.362424] input: saa7134 IR (Avermedia AVerTV GO as
 /devices/pci:00/:00:09.0/input/input6
 [9.362713] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared 
 IRQs
 [9.501011] saa7133[0]: i2c eeprom 00: 61 14 1f f3 ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.501838] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.502592] saa7133[0]: i2c eeprom 20: ff d2 fe ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.503343] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.504095] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.504842] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.505593] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.506345] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.507097] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.507846] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.508600] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.509354] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.510107] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.510920] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.511672] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [9.512423] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   10.780106] tuner 0-004b: chip found @ 0x96 (saa7133[0])
 [   10.815008] tda829x 0-004b: setting tuner address to 61
 [   11.349012] tda829x 0-004b: type set to tda8290+75
 [   14.869150] saa7133[0]: registered device video0 [v4l2]
 [   14.869305] saa7133[0]: registered device vbi0
 [   14.869447] saa7133[0]: registered device radio0
 [   14.968864] saa7134 ALSA driver for DMA sound loaded
 [   14.970728] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared 
 IRQs
 [   14.970892] saa7133[0]/alsa: saa7133[0] at 0xcfffc800 irq 17
 registered as card -1
 
[snip]

--
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: dmsg dump for Tevion High Speed DVD Maker

2010-03-26 Thread hermann pitton
Hi,

Am Freitag, den 26.03.2010, 23:26 -0400 schrieb OurMail:
 Hi,
 
 Was trying to get a firewire port working in Ubuntu 9.10 when I noticed
 that I had my USB Tevion DVD Maker plugged in and that you had a message
 requesting a copy of the dump for the unidentified DVD Maker. Attached
 is that dump as requested.
 
 Not sure where you are located but a German food store chain operating
 in the US under the name Aldi Food Stores has sold these a couple times
 that I know of. There are at least two versions although they function
 the same. A couple years ago they had them for $40 US. Last fall they
 had them for $20. At that price they should have been popular so should
 be other Linux users with them. Have seen a few users on the boards
 trying to get them going.
 
 They work well under Windows Vista but have never gotten one to work
 under Linux. Have been trying to get away from Windows for video work
 but have not been able to get either the this USB device or my Sony
 DSR-20 DV/DVCAM firewire deck to work under Linux.
 
 Am not all that good at Linux and any help you care to provide would be
 most welcome.
 
 Dave

just a hint. If Aldi stuff is called Medion as well, you usually find
the device at http://www.creatix.de.

If it is called Tevion, it can be some AverMedia Kworld or whatever
clone.

Cheers,
Hermann

 einfaches Textdokument-Anlage (dmesg-dump-ourmailATkconlineDOTcom)
 d...@systemax1:~$ dmesg
 [0.00] Initializing cgroup subsys cpuset
 [0.00] Initializing cgroup subsys cpu
 [0.00] Linux version 2.6.31-20-generic (bui...@palmer) (gcc version 
 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 
 (Ubuntu 2.6.31-20.58-generic)
 [0.00] KERNEL supported cpus:
 [0.00]   Intel GenuineIntel
 [0.00]   AMD AuthenticAMD
 [0.00]   NSC Geode by NSC
 [0.00]   Cyrix CyrixInstead
 [0.00]   Centaur CentaurHauls
 [0.00]   Transmeta GenuineTMx86
 [0.00]   Transmeta TransmetaCPU
 [0.00]   UMC UMC UMC UMC
 [0.00] BIOS-provided physical RAM map:
 [0.00]  BIOS-e820:  - 0009fc00 (usable)
 [0.00]  BIOS-e820: 0009fc00 - 000a (reserved)
 [0.00]  BIOS-e820: 000e - 0010 (reserved)
 [0.00]  BIOS-e820: 0010 - bf6a (usable)
 [0.00]  BIOS-e820: bf6a - bf6ae000 (ACPI data)
 [0.00]  BIOS-e820: bf6ae000 - bf6f (ACPI NVS)
 [0.00]  BIOS-e820: bf6f - bf6fe000 (reserved)
 [0.00]  BIOS-e820: fee0 - fee01000 (reserved)
 [0.00]  BIOS-e820: fff8 - 0001 (reserved)
 [0.00] DMI present.
 [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
 [0.00] e820 update range:  - 0001 
 (usable) == (reserved)
 [0.00] last_pfn = 0xbf6a0 max_arch_pfn = 0x10
 [0.00] MTRR default type: uncachable
 [0.00] MTRR fixed ranges enabled:
 [0.00]   0-9 write-back
 [0.00]   A-B uncachable
 [0.00]   C-CBFFF write-protect
 [0.00]   CC000-D uncachable
 [0.00]   E-E write-through
 [0.00]   F-F write-protect
 [0.00] MTRR variable ranges enabled:
 [0.00]   0 base 0 mask F8000 write-back
 [0.00]   1 base 08000 mask FC000 write-back
 [0.00]   2 base 0BF70 mask 0 uncachable
 [0.00]   3 base 0BF80 mask FFF80 uncachable
 [0.00]   4 disabled
 [0.00]   5 disabled
 [0.00]   6 disabled
 [0.00]   7 disabled
 [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
 0x7010600070106
 [0.00] Scanning 0 areas for low memory corruption
 [0.00] modified physical RAM map:
 [0.00]  modified:  - 0001 (reserved)
 [0.00]  modified: 0001 - 0009fc00 (usable)
 [0.00]  modified: 0009fc00 - 000a (reserved)
 [0.00]  modified: 000e - 0010 (reserved)
 [0.00]  modified: 0010 - bf6a (usable)
 [0.00]  modified: bf6a - bf6ae000 (ACPI data)
 [0.00]  modified: bf6ae000 - bf6f (ACPI NVS)
 [0.00]  modified: bf6f - bf6fe000 (reserved)
 [0.00]  modified: fee0 - fee01000 (reserved)
 [0.00]  modified: fff8 - 0001 (reserved)
 [0.00] initial memory mapped : 0 - 00c0
 [0.00] init_memory_mapping: -377fe000
 [0.00] Using x86 segment limits to approximate NX protection
 [0.00]  00 - 40 page 4k
 [0.00]  40 - 003740 page 

Re: Which of my 3 video capture devices will work best with my PC?

2010-03-25 Thread hermann pitton
Hi Serge,

Am Donnerstag, den 25.03.2010, 00:06 +0100 schrieb hermann pitton:
 Am Mittwoch, den 24.03.2010, 16:45 -0600 schrieb Serge Pontejos:
  Greetings all...
  
  I'm interested in doing video transfer from VCR to PC and want to know
  which of the 3 capture devices I have has the best chance of working
  with my setup? I have 3 different symptoms happening with each.
  
  My PC setup:
  Ubuntu Karmic 9.10/2.6.31-20 generic
  Socket 754 AMD Sempron 3000+ with passive cooling (non AMD64)
  Biostar MB with Nforce3 250Gb chipset
  NV31 GPU (Geforce FX5600 Ultra 128MB) using Nvidia 196 driver
  1GB PC3200 DDR RAM
  34GB SCSI coupled to a Adaptec 19160 card
  Soundblaster Audigy
  dvd+-R floppy etc etc.
  
  The devices in question:
  
  USB: Dazzle Digital Photo Maker, using a USBvision driver recognized
  as a Global Village GV-7000)
  
  --This one recognizes and I can display video but if I try to record
  in either xawtv or Kdenlive the program crashes.
  
  PCI: Hauppauge WinTV model 38101
  --When installed it shows /dev/video0 when I do an ls, but I don't get
  a signal with either composite or coax input.   I tried following
  steps from this link http://howtoubuntu.org/?p=20 but it didn't change
  a thing...
  
  PCI: Aurora Systems Fuse previously used on a Mac
  --This card picks up the ZR36067 driver, but it's saying it can't
  initialize the i2c bus. Thus, no /dev/video* shows
  
  Let me know which I should focus on and then I'll show the query dumps.
 
 I guess you don't get any dog out of the hut with such offers.
 
 ;)

please always provide us with the relevant dmesg output also for cards
with trouble.

Maybe we can fix them or at least others are informed about the issues
too.

The bttv WinTV model 38101 might be just a new revision and maybe the
tuner is just missing in tveeprom?

Old ones.

bttv0: Bt878 (rev 17) at :05:04.0, irq: 18, latency: 66, mmio: 0xf840
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
bttv0: gpio: en=, out= in=00fb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 0-0050: Hauppauge model 38101, rev B410, serial# 1993042
tveeprom 0-0050: tuner model is Philips FI1236 MK2 (idx 10, type 2)
tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 0-0050: audio processor is None (idx 0)
tveeprom 0-0050: has no radio
bttv0: Hauppauge eeprom indicates model#38101

and

bttv0: Bt878 (rev 17) at :05:04.0, irq: 18, latency: 66, mmio: 0xf840
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
bttv0: gpio: en=, out= in=00fb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 0-0050: Hauppauge model 38101, rev B426, serial# 1890608
tveeprom 0-0050: tuner model is Temic 4036FY5 (idx 26, type 8)
tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 0-0050: audio processor is None (idx 0)
tveeprom 0-0050: has no radio
bttv0: Hauppauge eeprom indicates model#38101

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: Which of my 3 video capture devices will work best with my PC?

2010-03-25 Thread hermann pitton
Am Donnerstag, den 25.03.2010, 16:06 -0600 schrieb Serge Pontejos:
 
 
 On Thu, Mar 25, 2010 at 1:18 PM, hermann pitton
 hermann-pit...@arcor.de wrote:
 Hi Serge,
 
 Am Donnerstag, den 25.03.2010, 00:06 +0100 schrieb hermann
 pitton:
 
 
 please always provide us with the relevant dmesg output also
 for cards
 with trouble.
 
 I figured I would try to determine if there was a specific card that
 might have a better chance of working first, then focus on that card's
 problem.  But I'll just supply the dmesg with the BT878 installed
 here...
 
 [   33.150658] Bt87x :02:0a.1: PCI INT A - Link[APC3] - GSI 18
 (level, low) - IRQ 18 
 [   33.150914] bt87x0: Using board 1, analog, digital (rate 32000 Hz) 
 [   33.294887] EMU10K1_Audigy :02:07.0: PCI INT A - Link[APC4] -
 GSI 19 (level, low) - IRQ 19 
 [   33.429554] bttv: driver version 0.9.18 loaded 
 [   33.429559] bttv: using 8 buffers with 2080k (520 pages) each for
 capture 
 [   33.429609] bttv: Bt8xx card found (0). 
 [   33.429629] bttv :02:0a.0: PCI INT A - Link[APC3] - GSI 18
 (level, low) - IRQ 18 
 [   33.429639] bttv0: Bt878 (rev 17) at :02:0a.0, irq: 18,
 latency: 32, mmio: 0xe400 
 [   33.429672] bttv0: detected: Hauppauge WinTV [card=10], PCI
 subsystem ID is 0070:13eb 
 [   33.429675] bttv0: using: Hauppauge (bt878) [card=10,insmod
 option] 
 [   33.429678] IRQ 18/bttv0: IRQF_DISABLED is not guaranteed on shared
 IRQs 
 [   33.429709] bttv0: gpio: en=, out= in=00fb
 [init] 
 [   33.432194] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] 
 [   33.432232] bt878 #0 [sw]: Test OK 
 [   33.475356] tveeprom 3-0050: Hauppauge model 38101, rev B410,
 serial# 1974546 
 [   33.475361] tveeprom 3-0050: tuner model is Philips FI1236 MK2 (idx
 10, type 2) 
 [   33.475365] tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08) 
 [   33.475368] tveeprom 3-0050: audio processor is None (idx 0) 
 [   33.475371] tveeprom 3-0050: has no radio 
 [   33.475373] bttv0: Hauppauge eeprom indicates model#38101 
 [   33.475376] bttv0: tuner type=2 
 [   33.640466] bttv0: audio absent, no audio device found! 
 [   33.671316] tuner 3-0061: chip found @ 0xc2 (bt878 #0 [sw]) 
 [   33.816641] tuner-simple 3-0061: creating new instance 
 [   33.816648] tuner-simple 3-0061: type set to 2 (Philips NTSC
 (FI1236,FM1236 and compatibles)) 
 [   33.817329] bttv0: registered device video1 
 [   33.817357] bttv0: registered device vbi1 
 [   33.817374] bttv0: PLL: 28636363 = 35468950 .. ok 
 
 ...which has similar output to your first dmesg example Serial#
 appears to be a little earlier than your example.
  
 Maybe we can fix them or at least others are informed about
 the issues
 too.
 
 The bttv WinTV model 38101 might be just a new revision and
 maybe the
 tuner is just missing in tveeprom?
 
 Old ones.
 
 bttv0: Bt878 (rev 17) at :05:04.0, irq: 18, latency: 66,
 mmio: 0xf840
 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID
 is 0070:13eb
 bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 bttv0: gpio: en=, out= in=00fb [init]
 bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 tveeprom 0-0050: Hauppauge model 38101, rev B410, serial#
 1993042
 tveeprom 0-0050: tuner model is Philips FI1236 MK2 (idx 10,
 type 2)
 tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
 tveeprom 0-0050: audio processor is None (idx 0)
 tveeprom 0-0050: has no radio
 bttv0: Hauppauge eeprom indicates model#38101
 
 Cheers,
 Hermann
 
 This is the xawtv output:
 
 se...@bracken:~$ xawtv -noxv -device /dev/video0
 This is xawtv-3.95.dfsg.1, running on Linux/i686 (2.6.31-20-generic)
 xinerama 0: 1680x1050+0+0
 WARNING: No DGA direct video mode for this display.
 WARNING: couldn't find framebuffer base address, try manual
  configuration (v4l-conf -a addr)
 v4l2: WARNING: framebuffer base address mismatch
 v4l2: me=(nil) v4l=(nil)
 Warning: Missing charsets in String to FontSet conversion
 Warning: Cannot convert string
 -*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,
 -*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,
 -gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*,
 -efont-biwidth-bold-r-normal--16-*-*-*-*-*-*-*,
 -*-*-bold-r-normal-*-16-*-*-*-m-*-*-*,
 -*-*-bold-r-normal-*-16-*-*-*-c-*-*-*,
 -*-*-*-*-*-*-16-*-*-*-*-*-*-*,* to type FontSet
 Warning: Cannot convert string
 -*-ledfixed-medium-r-*--39-*-*-*-c-*-*-* to type FontStruct
 Warning: Missing charsets in String to FontSet conversion
 Warning: Cannot convert string
 -*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,
 -*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,
 -gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*,
 -efont-biwidth-bold

Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)

2010-03-22 Thread hermann pitton
Hi Peter,

Am Samstag, den 20.03.2010, 16:20 +1100 schrieb 0123pe...@gmail.com:
 on Wed, 17 Mar 2010 09:12 am
 in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure
 hermann pitton wrote:
 
 [snip]
  
  unfortunately the problem with these cards is known, but no good
  solution for now.
  
  Best description is from Hartmut and starts here.
  
  http://www.spinics.net/lists/linux-dvb/msg26683.html
  
 [snip]
 
 Interesting link.  I have one of the cards mentioned 
 (an MSI TV(at)nywhere A/D hybrid).  I've decided not to throw it away.  

to not leave you without any response at least.

In hind sight, seeing how unfortunate using such devices can be, mainly
because of being forced to try at random again with a cold boot after
some i2c war brought down the tuner, we better should have such only in
a still experimental league and not as supported.

This was not foreseeable in such rudeness and neither Hartmut nor me
have such devices.

The Asus triple OEM 3in1 I have does not have any problems with loading
firmware from file, the others do all get it from eeprom.

So, actually nobody is investigating on it with real hardware.

Maybe you can catch something with gpio_tracking and i2c_debug=1.
I would expect that the complex analog tuner initialization gets broken
somehow. This is at least known to be good to bring all down.

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


FM1216ME MK5 radio

2010-03-22 Thread hermann pitton

Hi Dmitry,

please have a look at tveeprom concerning your FM1216ME/I MK5.

It still maps to the MK3 and should break for radio.

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: Add AverTV Studio 509UA

2010-03-21 Thread hermann pitton
Hi,

Am Samstag, den 20.03.2010, 16:08 +0200 schrieb Евгений Бацман:
 2010/3/20 hermann pitton hermann-pit...@arcor.de:
  Hi, Евгений,
 
  is there any reason, why you set the charge pump bit to low and slow
  tuning on a non FM tuner?
 
  Cheers,
  Hermann
 
 
  Am Freitag, den 19.03.2010, 20:32 +0200 schrieb Евгений Бацман:
  A add tv tuner AverTV Studio 509UA but radio now not
  work(tuner_tea5764hn not in kernel)
 
 
 
  diff -r a/linux/drivers/media/common/tuners/tuner-types.c
  --- a/linux/drivers/media/common/tuners/tuner-types.c 2010-03-17
  20:38:10.0 +0200
  +++ b/linux/drivers/media/common/tuners/tuner-types.c 2010-03-19
  14:25:24.0 +0200
  @@ -1353,6 +1353,30 @@
.count  = ARRAY_SIZE(tuner_sony_btf_pxn01z_ranges),
},
   };
  +/*  TUNER_PHILIPS_FQ1216ME_MK5 - Philips PAL  */
  +
  +static struct tuner_range tuner_fq1216me_mk5_pal_ranges[] = {
  + { 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
  + { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
  + { 16 * 999.99, 0x8e, 0x04, },
  +};
  +
  +static struct tuner_params tuner_fq1216me_mk5_params[] = {
  + {
  + .type   = TUNER_PARAM_TYPE_PAL,
  + .ranges = tuner_fq1216me_mk5_pal_ranges,
  + .count  = ARRAY_SIZE(tuner_fq1216me_mk5_pal_ranges),
  + .cb_first_if_lower_freq = 1,
  + .has_tda9887 = 1,
  + .port1_active = 1,
  + .port2_active = 1,
  + .port2_invert_for_secam_lc = 1,
  + .default_top_mid = -2,
  + .default_top_secam_low = -2,
  + .default_top_secam_mid = -2,
  + .default_top_secam_high = -2,
  + },
  +};
 
   /* - 
  */
 
  @@ -1827,6 +1851,11 @@
.params = tuner_sony_btf_pxn01z_params,
.count  = ARRAY_SIZE(tuner_sony_btf_pxn01z_params),
},
  + [TUNER_PHILIPS_FQ1216ME_MK5] = { /* Philips PAL */
  + .name   = Philips PAL/SECAM multi (FQ1216ME MK5),
  + .params = tuner_fq1216me_mk5_params,
  + .count  = ARRAY_SIZE(tuner_fq1216me_mk5_params),
  + },
   };
   EXPORT_SYMBOL(tuners);
 
  diff -r a/linux/drivers/media/video/saa7134/saa7134-cards.c
  --- a/linux/drivers/media/video/saa7134/saa7134-cards.c   2010-03-17
  20:38:10.0 +0200
  +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c   2010-03-19
  16:34:17.0 +0200
  @@ -5411,7 +5411,44 @@
.gpio = 0x389c00,
} },
},
  -
  + [SAA7134_BOARD_AVERMEDIA_STUDIO_509UA] = {
  + /* Evgen Batsman evgenbats...@gmail.com */
  + .name   = Avermedia AVerTV Studio 509UA,
  + .audio_clock= 0x00187de7,
  + .tuner_type = TUNER_PHILIPS_FQ1216ME_MK5,
  + .radio_type = UNSET,
  + .tuner_addr = ADDR_UNSET,
  + .radio_addr = ADDR_UNSET,
  + .tda9887_conf   = TDA9887_PRESENT,
  + .gpiomask   = 0x03,
  + .inputs = { {
  + .name = name_tv,
  + .vmux = 1,
  + .amux = TV,
  + .tv   = 1,
  + .gpio = 0x00,
  + }, {
  + .name = name_comp1,
  + .vmux = 3,
  + .amux = LINE1,
  + .gpio = 0x00,
  + }, {
  + .name = name_svideo,
  + .vmux = 8,
  + .amux = LINE1,
  + .gpio = 0x00,
  + } },
  + .radio = {
  + .name = name_radio,
  + .amux = LINE2,
  + .gpio = 0x01,
  + },
  + .mute  = {
  + .name = name_mute,
  + .amux = LINE1,
  + .gpio = 0x00,
  + },
  + },
   };
 
   const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
  @@ -6567,6 +6604,12 @@
.subvendor= 0x107d,
.subdevice= 0x6655,
.driver_data  = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
  + },{
  + .vendor   = PCI_VENDOR_ID_PHILIPS,
  + .device   = PCI_DEVICE_ID_PHILIPS_SAA7133,
  + .subvendor= 0x1461, /* Avermedia Technologies Inc */
  + .subdevice= 0xa14b,
  + .driver_data  = SAA7134_BOARD_AVERMEDIA_STUDIO_509UA,
}, {
/* --- boards without eeprom + subsystem ID --- */
.vendor   = PCI_VENDOR_ID_PHILIPS,
  diff -r a/linux/drivers/media/video/saa7134/saa7134.h
  --- a/linux/drivers/media/video/saa7134/saa7134.h 2010-03-17
  20:38:10.0 +0200
  +++ b/linux/drivers/media/video/saa7134/saa7134.h 2010-03-19
  13:13

Re: Add AverTV Studio 509UA

2010-03-21 Thread hermann pitton

 
 I think best would be to create two patches.
 
 1/2 adds the new tuner. (tuner-types.c/tuner.h/tveeprom.c)
 2/2 adds the new Avermedia card.
 
 Else it looks fine.

To add some for the record here for those eventually later on it.

We have seen over so many years now, that hundreds of new can tuners
did appear and, IIRC, we got them all with any combination of previous
chips.

The filters, mainly the SAW filters did make a difference to the
original products they follow all in what ever combination concerning
quality.

However, a main annoyance was, that lots of such clones did appear and
some did start to use extra radio tuners on cheap silicon on separate
addresses, hard to track, since hidden under some welded shielding.

This was with all such clones all over Asia and the extra silicon radio
tuner was always Philips/NXP in the beginning.

What is new now, I think, and first seen, is that the last can tuner
flagship MK5 series has a FQ non radio variant on a AverMedia using some
extra silicon from Philips/NXP/Trident _themselves_ to make some extra
profit against a FM MK5 they have.

I would call this a management disaster, but my education might be
outdated.

Cheers,
Hermann






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


Re: [PATCH] saa7134: add capture boards Hawell HW-404M7 and HW-808M7

2010-03-20 Thread hermann pitton
Hi Vladimir,

Am Samstag, den 20.03.2010, 17:58 +0300 schrieb Vladimir Ermakov:
 Hi Hermann.
 
 1. It's my mistake. Fixed.
 2. Dead code. Removed.

thanks for looking at it.

We likely need your SOB line again, since it is a new patch.

Here is my

Reviewed-by: hermann pitton hermann-pit...@arcor.de

Cheers,
Hermann

 # HG changeset patch
 # User Vladimir Ermakov vooon...@gmail.com
 # Date 1269096094 -10800
 # Node ID a91db2cf4f5774866c8c5bf906d9ac4faff9173d
 # Parent  929298149eba4b6d0696124b9880113c25cd0788
 saa7134: fix GPIO HW-404M7
 
 diff -r 929298149eba -r a91db2cf4f57 
 linux/drivers/media/video/saa7134/saa7134-cards.c
 --- a/linux/drivers/media/video/saa7134/saa7134-cards.c   Thu Mar 18 
 23:47:27 2010 -0300
 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c   Sat Mar 20 
 17:41:34 2010 +0300
 @@ -5403,12 +5403,12 @@
   .radio_type= UNSET,
   .tuner_addr   = ADDR_UNSET,
   .radio_addr   = ADDR_UNSET,
 - .gpiomask  = 0x01fc00,
 + .gpiomask  = 0x389c00,
   .inputs   = {{
   .name = name_comp1,
   .vmux = 3,
   .amux = LINE1,
 - .gpio = 0x389c00,
 + .gpio = 0x01fc00,
   } },
   },
  
 diff -r 929298149eba -r a91db2cf4f57 
 linux/drivers/media/video/saa7134/saa7134-input.c
 --- a/linux/drivers/media/video/saa7134/saa7134-input.c   Thu Mar 18 
 23:47:27 2010 -0300
 +++ b/linux/drivers/media/video/saa7134/saa7134-input.c   Sat Mar 20 
 17:41:34 2010 +0300
 @@ -531,7 +531,6 @@
   switch (dev-board) {
   case SAA7134_BOARD_FLYVIDEO2000:
   case SAA7134_BOARD_FLYVIDEO3000:
 - case SAA7134_BOARD_HAWELL_HW_404M7:
   case SAA7134_BOARD_FLYTVPLATINUM_FM:
   case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
   case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
 
 
 В Птн, 19/03/2010 в 00:21 +0100, hermann pitton пишет:
  Hi Vladimir,
  
  thanks, your patch is already accepted, but if have a two comments.
  
  Am Mittwoch, den 10.03.2010, 18:44 +0300 schrieb Vladimir Ermakov:
  This patch adds new capture boards Hawell HW-404M7 and HW-808M7.
  Those cards have 4 or 8 SAA7130 chips and for the work it only needs 
  initialize registers.
  The value of those registers were dumped under Windows using flytest.
  But board haven't EEPROM.
  
  For the first chip:
  
   SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
  
   I2C slave devices found:
   No devices
  
   GPIO pins:
   Mode : 0x00389C00
   Value: 0x00016C00
 
  Later in the code you swapped mode (gpio mask) and value (out status).
 
  This does not cause a functional problem in this case, but is visible
  for example with saa7134 gpio_tracking=1.
 
  Second, you did add the card to the flyvideo remotes in saa7134-input,
  but this is only a line of dead code currently.
 
  If it really has such a remote, you must also add the card to the switch
  case dev-has_remote = SAA7134_REMOTE_GPIO in in the function
  int saa7134_board_init1 in saa7134-cards.c or please remove it from
  saa7134-input.c.
 
  Thanks,
  Hermann
 
   Video input: 3
   Audio input: Analog Line1
  
  For other chips:
  
   SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
  
   I2C slave devices found:
   No devices
  
   GPIO pins:
   Mode : 0x00389200
   Value: 0x0001
  
   Video input: 3
   Audio input: Analog Line1
  
  Signed-off-by: Vladimir Ermakov vooon...@gmail.com
  
  # HG changeset patch
  # User Vladimir Ermakov vooon...@gmail.com
  # Date 1268232221 -10800
  # Node ID 072cd67c6aabe0e700a9e4727b50ad6424cb59f5
  # Parent  7a58d924fb049ff1d318514939b3a7e416670c13
  saa7134: add Hawell HW-404M7  HW-808M7
  
  diff -r 7a58d924fb04 -r 072cd67c6aab 
  linux/Documentation/video4linux/CARDLIST.saa7134
  --- a/linux/Documentation/video4linux/CARDLIST.saa7134 Tue Mar 09 
  23:00:59 2010 -0300
  +++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Wed Mar 10 
  17:43:41 2010 +0300
  @@ -175,3 +175,4 @@
   174 - Asus Europa Hybrid OEM   [1043:4847]
   175 - Leadtek Winfast DTV1000S [107d:6655]
   176 - Beholder BeholdTV 505 RDS[:5051]
  +177 - Hawell HW-404M7 / HW-808M7
  diff -r 7a58d924fb04 -r 072cd67c6aab 
  linux/drivers/media/video/saa7134/saa7134-cards.c
  --- a/linux/drivers/media/video/saa7134/saa7134-cards.cTue Mar 09 
  23:00:59 2010 -0300
  +++ b/linux/drivers/media/video/saa7134/saa7134-cards.cWed Mar 10 
  17:43:41 2010 +0300
  @@ -5394,6 +5394,23 @@
 .amux = LINE2,
 },
 },
  +  [SAA7134_BOARD_HAWELL_HW_404M7] = {
  +  /* Hawell HW-404M7  Hawell HW-808M7  */
  +  /* Bogoslovskiy Viktor bogo...@bk.ru */
  +  .name = Hawell HW-404M7,
  +  .audio_clock   = 0x0020,
  +  .tuner_type= UNSET,
  +  .radio_type= UNSET,
  +  .tuner_addr   = ADDR_UNSET

Re: Add AverTV Studio 509UA

2010-03-19 Thread hermann pitton
Hi, Евгений,

is there any reason, why you set the charge pump bit to low and slow
tuning on a non FM tuner?

Cheers,
Hermann


Am Freitag, den 19.03.2010, 20:32 +0200 schrieb Евгений Бацман:
 A add tv tuner AverTV Studio 509UA but radio now not
 work(tuner_tea5764hn not in kernel)
 
 
 
 diff -r a/linux/drivers/media/common/tuners/tuner-types.c
 --- a/linux/drivers/media/common/tuners/tuner-types.c 2010-03-17
 20:38:10.0 +0200
 +++ b/linux/drivers/media/common/tuners/tuner-types.c 2010-03-19
 14:25:24.0 +0200
 @@ -1353,6 +1353,30 @@
   .count  = ARRAY_SIZE(tuner_sony_btf_pxn01z_ranges),
   },
  };
 +/*  TUNER_PHILIPS_FQ1216ME_MK5 - Philips PAL  */
 +
 +static struct tuner_range tuner_fq1216me_mk5_pal_ranges[] = {
 + { 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
 + { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
 + { 16 * 999.99, 0x8e, 0x04, },
 +};
 +
 +static struct tuner_params tuner_fq1216me_mk5_params[] = {
 + {
 + .type   = TUNER_PARAM_TYPE_PAL,
 + .ranges = tuner_fq1216me_mk5_pal_ranges,
 + .count  = ARRAY_SIZE(tuner_fq1216me_mk5_pal_ranges),
 + .cb_first_if_lower_freq = 1,
 + .has_tda9887 = 1,
 + .port1_active = 1,
 + .port2_active = 1,
 + .port2_invert_for_secam_lc = 1,
 + .default_top_mid = -2,
 + .default_top_secam_low = -2,
 + .default_top_secam_mid = -2,
 + .default_top_secam_high = -2,
 + },
 +};
 
  /* - */
 
 @@ -1827,6 +1851,11 @@
   .params = tuner_sony_btf_pxn01z_params,
   .count  = ARRAY_SIZE(tuner_sony_btf_pxn01z_params),
   },
 + [TUNER_PHILIPS_FQ1216ME_MK5] = { /* Philips PAL */
 + .name   = Philips PAL/SECAM multi (FQ1216ME MK5),
 + .params = tuner_fq1216me_mk5_params,
 + .count  = ARRAY_SIZE(tuner_fq1216me_mk5_params),
 + },
  };
  EXPORT_SYMBOL(tuners);
 
 diff -r a/linux/drivers/media/video/saa7134/saa7134-cards.c
 --- a/linux/drivers/media/video/saa7134/saa7134-cards.c   2010-03-17
 20:38:10.0 +0200
 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c   2010-03-19
 16:34:17.0 +0200
 @@ -5411,7 +5411,44 @@
   .gpio = 0x389c00,
   } },
   },
 -
 + [SAA7134_BOARD_AVERMEDIA_STUDIO_509UA] = {
 + /* Evgen Batsman evgenbats...@gmail.com */
 + .name   = Avermedia AVerTV Studio 509UA,
 + .audio_clock= 0x00187de7,
 + .tuner_type = TUNER_PHILIPS_FQ1216ME_MK5,
 + .radio_type = UNSET,
 + .tuner_addr = ADDR_UNSET,
 + .radio_addr = ADDR_UNSET,
 + .tda9887_conf   = TDA9887_PRESENT,
 + .gpiomask   = 0x03,
 + .inputs = { {
 + .name = name_tv,
 + .vmux = 1,
 + .amux = TV,
 + .tv   = 1,
 + .gpio = 0x00,
 + }, {
 + .name = name_comp1,
 + .vmux = 3,
 + .amux = LINE1,
 + .gpio = 0x00,
 + }, {
 + .name = name_svideo,
 + .vmux = 8,
 + .amux = LINE1,
 + .gpio = 0x00,
 + } },
 + .radio = {
 + .name = name_radio,
 + .amux = LINE2,
 + .gpio = 0x01,
 + },
 + .mute  = {
 + .name = name_mute,
 + .amux = LINE1,
 + .gpio = 0x00,
 + },
 + },
  };
 
  const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
 @@ -6567,6 +6604,12 @@
   .subvendor= 0x107d,
   .subdevice= 0x6655,
   .driver_data  = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
 + },{
 + .vendor   = PCI_VENDOR_ID_PHILIPS,
 + .device   = PCI_DEVICE_ID_PHILIPS_SAA7133,
 + .subvendor= 0x1461, /* Avermedia Technologies Inc */
 + .subdevice= 0xa14b,
 + .driver_data  = SAA7134_BOARD_AVERMEDIA_STUDIO_509UA,
   }, {
   /* --- boards without eeprom + subsystem ID --- */
   .vendor   = PCI_VENDOR_ID_PHILIPS,
 diff -r a/linux/drivers/media/video/saa7134/saa7134.h
 --- a/linux/drivers/media/video/saa7134/saa7134.h 2010-03-17
 20:38:10.0 +0200
 +++ b/linux/drivers/media/video/saa7134/saa7134.h 2010-03-19
 13:13:00.0 +0200
 @@ -302,6 +302,7 @@
  #define SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S 175
  #define SAA7134_BOARD_BEHOLD_505RDS_MK3 176
  #define SAA7134_BOARD_HAWELL_HW_404M7177
 +#define SAA7134_BOARD_AVERMEDIA_STUDIO_509UA 178
 
  

Re: RFC: Drop V4L1 support in V4L2 drivers

2010-03-19 Thread hermann pitton

Am Freitag, den 19.03.2010, 12:04 -0700 schrieb VDR User:
 Keeping v4l1 because some guys are still using some ancient setup is
 not a good reason.  Keeping v4l1 because some app devs still haven't
 bothered to update their apps is not a good reason, especially given
 the amount of time they've had to complete this task.  Keeping v4l1
 because package maintainers haven't bothered to update their packages
 is not a good reason.
 
 To put it simply, v4l1 is just dragging along dead weight.  It has
 been replaced by something better and there's no reasonable excuse to
 keep dragging it along.  There will always be someone complaining
 because there will always be someone neglecting to make the transition
 until the last possible second or resisting change even when it's for
 the better.
 
 App devs that haven't bothered to update -- you've had plenty of time
 to get it done.  If you app breaks, it's not v4l's fault at this
 point.
 
 Users still on ancient hardware -- consider updating to cheap newer
 alternatives but don't expect v4l to be held back because you refuse
 to move forward.  Or politely request old drivers be converted.
 
 Package maintainers -- if it's too much of a hassle to keep your
 package(s) updated, consider giving that responsibility to someone
 else.
 
 The points made in this thread make it pretty obvious that dumping
 v4l1 altogether is easily for the best and has only very minimal
 negative impact.  And the negatives aren't anything that can't be
 resolved completely with a little commitment to do so.
 
 Best regards,
 Derek

If you are so clear and up to date on all,

please share your knowledge with us and tell at least, which vbi/cc and
radio app would still work after your proposal?



--
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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)

2010-03-16 Thread hermann pitton
Hi Alex,

Am Montag, den 08.03.2010, 12:21 +0200 schrieb Alex Kasayev:
 Team,
 
 I would to inform you about my experience with Kworld
 DVB-T 210SE under Linux. It partially works only when I reboot
 computer from Win to Linux. If I power-on and boot Linux first -
 it not working at all and rebooting into win does not help - it not
 working under Win
 also until I power-off and load Win first. I Googled a lot and found
 that  there are
 exactly same problems with DVB-T cards from different vendors which using
 the TDA10046 demodulator (example is recent post from Robin Raiton for
 MSI TV - I got exactly same messages).
 I tried with card=81 and card=114. I have played with different modprobe
 options and found that probably cause of error
 is incorrect TDA10046 initialization - see  logs below (first is for
 power-on Linux boot and second is for reboot from Win).
 Please help me guys to get this card working. I am able to apply
 patches, re-build kernel and test changes.
 
 Now some info:
 
 Operating system: OpenSUSE 11.2 kernel 2.6.31.12
 Card: Kworld DVB-T 210SE
 Chips on the card: SAA7131E/03/G, 8275AC1, HC4052, KS007, TDA10046A,
 ATMLH806.
 Crystals: 32.1 MHz, 20 MHz, 16MHz
 
 Logs and win driver's .inf attached.
 
 Thanks,
 Alex.
 

unfortunately the problem with these cards is known, but no good
solution for now.

Best description is from Hartmut and starts here.

http://www.spinics.net/lists/linux-dvb/msg26683.html

Your card was also never fully tested and validated and thus is not yet
in the driver, even it has it's own PCI subdevice ID.

From your .inf we can see also a configuration difference.

Kworld DVBT 210 17de:7250

[3xHybridK.AddReg]
HKR, I2C Devices, Device 0, Data1,0x00010001,0x21,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data2,0x00010001,0xC2,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data3,0x00010001,0x96,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data4,0x00010001,0x10,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data5,0x00010001,0x03,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data6,0x00010001,0x32,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data7,0x00010001,0x15,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data8,0x00010001,0x06,0x00,0x00,0x00
   
HKR, I2C Devices, Number of I2C Devices,0x00010001,1

Kworld DVBT 210SE 17de:7253

[3xHybridQ.AddReg]
HKR, I2C Devices, Device 0, Data1,0x00010001,0x21,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data2,0x00010001,0xC2,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data3,0x00010001,0x96,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data4,0x00010001,0x10,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data5,0x00010001,0x03,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data6,0x00010001,0x32,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data7,0x00010001,0x15,0x00,0x00,0x00
   
HKR, I2C Devices, Device 0, Data8,0x00010001,0x50,0x00,0x00,0x00
   
HKR, I2C Devices, Number of I2C Devices,0x00010001,1

Data8 differs and I don't know its meaning right now. In your eeprom
is that byte even 0x56 and not 0x50. Maybe it plays some role.
On triple cards we have the address of the DVB-S demod there.

Else, if a previously fully working card is broken, we can find the
patch causing it using mercurial bisect procedures. Does not take very
long.

Around November 2008 have at least been reports with normal log for a
missing firmware file in /lib/firmware and one guy
had DVB-t working in the UK, with some quality limitations, maybe caused
by frequency offsets they use there.

Try to check again. if there is really no second 8pin eeprom close to
the tda10046 for its firmware. Put firmware in /lib/firmware.
Disable early starting apps like myth backend.

If i2c to the tuner is already lost, only a cold boot will help for a
next try.

Eventually disable its initialization for analog mode in
saa7134-cards.c. Comment the card in that case statement.

Good Luck,

Hermann




 ---
 
 Robbin's mail follows (I'm constantly get exactly the same messages) :
 
 Hi List,
 
 Ages ago I wrote about trying to get a MSI TV Anywhere A/D V1.1 to
 work (in my MythBackend, but that part isn't important). Doing a quick
 search notice this was over 2 years ago! The original thread on the
 archives is here:
 
 http://www.mail-archive.com/linux-...@linuxtv.org/msg28514.html
 
 Anyhow, at the time I gave up as it just wouldn't play. As some time
 has passed and was messing around with hardware decided to pull out
 the card and give it another go. It looks promising still, but still
 doesn't work :(
 
 Has anyone managed to get this card working in the mean time, or
 should I give up for sure this time and bin it? :(
 
 Cheers,
 
 Robin
 
 P.S. Some info to help out... dmesg gives this on boot:
 
 saa7130/34: 

Aw: Re: v4l-utils, dvb-utils, xawtv and alevt

2010-03-14 Thread hermann-pitton
 


- Original Nachricht 
Von: Chicken Shack chicken.sh...@gmx.de
An:  hermann pitton hermann-pit...@arcor.de
Datum:   14.03.2010 12:13
Betreff: Re: v4l-utils, dvb-utils, xawtv and alevt

 Am Sonntag, den 14.03.2010, 06:39 +0100 schrieb hermann pitton:
  Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack:
   Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
Hi,

On 03/13/2010 11:15 AM, Chicken Shack wrote:
 Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
 Hi,

 On 03/12/2010 08:10 PM, Chicken Shack wrote:
 1. Alevt 1.7.0 is not just another tool, but it is instead a
 self-contained videotext application consisting of three parts:
 a. alevt, b. alevt-date c. alevt-cap

 While the packed size of alevt is 78770 the complete size of the
 dvb-apps as a whole ranges around 35.

 I am not against hosting this program at linuxtv.org, but if this
 decision is made the decision should be an intelligent one: alevt
 is a
 separate tree, and any other choice is simply a dumb one.
 Alevt-1.7.0 needs a lot of external dependencies, while the
 dvb-apps
 only need the libc6.
  
  More clever would have been never to rename it from alevt-dvb to alevt.
  On the prior you don't have any rights and I seriously doubt you have
  any on the later.
 
 Only a pure brainless idiot who understands less than nothing can rant
 crap like this.
 
 Typical Pitton, typical no-brain quality
 
  
 Good morning Hans,


Good afternoon :)

 Definitely not.
 3.95 is analogue only and thus is discontinued as version.
 4.0 pre is the alpha-state tarball that you can get here:
  
  No, 3.95 is official and right for patching and 4x was never released.
 
 See above.
 
  I pointed to mpeg4ip only as a joke.
  
Ah, ok. Well I must honestly say I've no interest in that I'm doing
package maintenance for the 3.95 release in Fedora and I know it
needs a lot of patching, AFAIK other distros are doing the same,
so it would be good to have / become a new upstream for xawtv 3.95,
to have a place to gather all the distro patches mostly and release
that, and where new patches if needed can accumulate and new
releases can be done from.


 http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz

 Inofficial end of development somewhere in 2005 or 2006, last
 external
 contribution from October 2008.
  
  It was on March 08 2005. You even don't know that?
 
 Completely irrelevant, stupid moron!
 
  http://linux.bytesex.org/v4l2/maintainer.txt
  
  Maybe improve your Pinnacle stuff first, I can point you to a lot on the
  TODO list.
 
 Don't owe no Pinnacle any longer for years now.
 
 I personally took part in flexcop development as well-informed people
 know.
 That's a good driver now, and Patrick is someone you can really work
 with, not unproblematic, but OK so far.
 He's no Abraham, and he's no Pitton


http://www.mail-archive.com/linux-...@linuxtv.org/msg23780.html

There is not any progress with you and likely never will be.

Cheers,
Hermann
 


Topp oder Hopp? Tolle Figur, scharfes Dekolleté oder sehenswertes Tatoo?! 
Bewerten Sie die besten Bilder und zeigen Sie auch selbst, was Sie haben! Jetzt 
reinklicken und mitmachen: http://www.arcor.de/rd/footer.toh
--
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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

2010-03-13 Thread hermann pitton

Am Sonntag, den 14.03.2010, 03:38 +0100 schrieb Daro:
 Hi Jean,
 
 I am back and ready to go :)
 As I am not much experienced Linux user I would apprieciate some more 
 details:
 
 I have few linux kernels installed; which one should I test or it does 
 not matter?
 2.6.31-14-generic
 2.6.31-16-generic
 2.6.31-17-generic
 2.6.31-19-generic
 2.6.31-20-generic
 
 and one I compiled myself
 2.6.32.2
 
 I assume that to proceed with a test I should patch the certain version 
 of kernel and compile it or could it be done other way?
 
 Best regards
 Daro
 
 
 
 W dniu 12.03.2010 10:38, Jean Delvare pisze:
  Hi Daro,
 
  On Fri, 26 Feb 2010 17:19:38 +0100, Daro wrote:
 
  I did not forget I had offered to test the patch however I am now on 
  vacation skiing so I will get back to you as soon I am back home.
   
  Are you back home by now? We are still waiting for your test results.
  We can't push the patch upstream without it, and if it takes too long,
  I'll probably just discard the patch and move to other tasks.
 
 


Hi Daro,

thanks for being back on it.

Damned jokes aside, and not made. Sorry, let know if you have any
problems to get Jeans patch stuff applied.

Jean's review is good and valuable and we might to have to come back to
it, if stuff with the same PCI subsystem and different remotes is
validated to be out. (The LNA hell is even much more burning ;)

It very much looks like that is already the case.

It is a little confusing these days, patch p0, p1, hg or git patches.

I let it to Jean, how to test best for now, but will help to prepare you
with stuff you can test easily under any conditions.

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: v4l-utils, dvb-utils, xawtv and alevt

2010-03-13 Thread hermann pitton

Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack:
 Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
  Hi,
  
  On 03/13/2010 11:15 AM, Chicken Shack wrote:
   Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
   Hi,
  
   On 03/12/2010 08:10 PM, Chicken Shack wrote:
   1. Alevt 1.7.0 is not just another tool, but it is instead a
   self-contained videotext application consisting of three parts:
   a. alevt, b. alevt-date c. alevt-cap
  
   While the packed size of alevt is 78770 the complete size of the
   dvb-apps as a whole ranges around 35.
  
   I am not against hosting this program at linuxtv.org, but if this
   decision is made the decision should be an intelligent one: alevt is a
   separate tree, and any other choice is simply a dumb one.
   Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
   only need the libc6.

More clever would have been never to rename it from alevt-dvb to alevt.
On the prior you don't have any rights and I seriously doubt you have
any on the later.

   Good morning Hans,
  
  
  Good afternoon :)
  
   Definitely not.
   3.95 is analogue only and thus is discontinued as version.
   4.0 pre is the alpha-state tarball that you can get here:

No, 3.95 is official and right for patching and 4x was never released.

I pointed to mpeg4ip only as a joke.

  Ah, ok. Well I must honestly say I've no interest in that I'm doing
  package maintenance for the 3.95 release in Fedora and I know it
  needs a lot of patching, AFAIK other distros are doing the same,
  so it would be good to have / become a new upstream for xawtv 3.95,
  to have a place to gather all the distro patches mostly and release
  that, and where new patches if needed can accumulate and new
  releases can be done from.
  
  
   http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
  
   Inofficial end of development somewhere in 2005 or 2006, last external
   contribution from October 2008.

It was on March 08 2005. You even don't know that?

http://linux.bytesex.org/v4l2/maintainer.txt

Maybe improve your Pinnacle stuff first, I can point you to a lot on the
TODO list.

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: v4l-utils: i2c-id.h and alevt

2010-03-09 Thread hermann pitton
Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
 It's nice to see this new tree, that should be make it easier to develop
 utilities!
 
 After a quick check I noticed that the i2c-id.h header was copied from the
 kernel. This is not necessary. The only utility that includes this is v4l2-dbg
 and that one no longer needs it. Hans, can you remove this?
 
 The second question is whether anyone would object if alevt is moved from
 dvb-apps to v4l-utils? It is much more appropriate to have that tool in
 v4l-utils.

i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.

 Does anyone know of other unmaintained but useful tools that we might merge
 into v4l-utils? E.g. xawtv perhaps?

If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.

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: TBS 6980 Dual DVB-S2 PCIe card

2010-03-05 Thread hermann pitton
Hi Per,

Am Donnerstag, den 04.03.2010, 14:03 +0200 schrieb Per Lundberg:
 Hi Hermann,
 
 On Thu, Mar 4, 2010 at 11:05 AM, hermann pitton hermann-pit...@arcor.de 
 wrote:
 
  Has anyone done any attempt at contacting TBS to see if they can release 
  their
  changes under the GPLv2? Ideally, they would provide a patch themselves, 
  but it
  should be fairly simple to diff the linux/ trees from their provided
  linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in 
  fact, it
  could be that their patch is so trivial that we could just include it in 
  the
  stock Linux kernel without asking them for license clarifications... but
  obviously, if we can get a green sign from them, it would be even better.
 
  It is always the other way round.
 
  In the end they need a green sign from us.
 
 Well... I guess we are both right. :-) They need to assert ownership
 and license the code under the GPL, and we need to ensure that the
 quality of the code is high enough (driver is working and does not
 interfer with other parts of the code base...).

no, they must provide GPLed code accepted by NXP or someone else will do
it. We can't assure quality of code we can't see.

  BTW, the TBS dual seems to be fine on m$, but there are some mysterious
  lockups without any trace, if used in conjunction with some prior
  S2/HDTV cards. I can't tell yet, if that it is evenly distributed over
  amd/ati and nvidia stuff or whatever on win7 ... , but people do spend
  lifetime in vain on it.
 
 This is pretty interesting, do you have any references? (forum links
 or similar)

No, a friend recently bought that card in addition to a Terratec S2 PCI
for his new windows 7 he already had. Likely totally unrelated to linux,
but on his stuff it turned out he can't use both cards at once, single
both are fine.

 In my particular case, I was thinking about using it as the only S2
 card in the machine, later possibly adding a DVB-C card if/when we get
 cable... so, it might not be a problem for me, but it still doesn't
 feel really good. I guess the card is pretty new, so maybe (hopefully)
 it will get fixed by a new firmware release.
 
 Do we have any readers of this list who own the card and use it in
 Linux (with the drivers from TBS)? Could you please share your
 experiences: is the picture quality good? Sound? Does the tuner work
 well? (e.g. can you receive all channels you normally receive...)

Sorry, can't help much yet and can't add anything new.

For now I advised better not to try with binary blobs on linux, he was
already burned enough on win7. He might try later and we will have it
under GPL sooner or later.

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: TBS 6980 Dual DVB-S2 PCIe card

2010-03-04 Thread hermann pitton

Am Donnerstag, den 04.03.2010, 08:19 + schrieb Per Lundberg:
 Hi!
 
 I read the old thread about this card, at
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg12753.html. I've 
 also
 tried downloading the vendor-provided drivers from
 http://www.buydvb.net/download2/TBS6980/tbs6980linuxdriver2.6.32.rar
 
 As someone has already indicated, it seems like TBS (TurboSight) have made 
 their
 own fork of v4l where the drivers for this card is included. I've also
 understood that the card works fine, which is nice (I down own it yet but am
 considering getting one).
 
 Has anyone done any attempt at contacting TBS to see if they can release their
 changes under the GPLv2? Ideally, they would provide a patch themselves, but 
 it
 should be fairly simple to diff the linux/ trees from their provided
 linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in fact, 
 it
 could be that their patch is so trivial that we could just include it in the
 stock Linux kernel without asking them for license clarifications... but
 obviously, if we can get a green sign from them, it would be even better.
 --
 Best regards,
 Per Lundberg
 

It is always the other way round.

In the end they need a green sign from us.

Cheers,
Hermann

BTW, the TBS dual seems to be fine on m$, but there are some mysterious
lockups without any trace, if used in conjunction with some prior
S2/HDTV cards. I can't tell yet, if that it is evenly distributed over
amd/ati and nvidia stuff or whatever on win7 ... , but people do spend
lifetime in vain on 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


Re: saa7231 is anybody trying

2010-03-02 Thread hermann pitton
Hi,

Am Samstag, den 20.02.2010, 09:53 +0100 schrieb Jens Chievitz:
 Hi developers
 Is anybody trying to get this device working under linux?
 I have found some code here:
  http://www.jusst.de/hg/saa7231
 but it it is not finished.
 Regards
   Jens chievitz

got some such fish on the hook, notoriously buying some latest
Medion/Aldi/Tevion/Creatix stuff. That sort was not exactly wanted, but
it has some big NXP on it and else the fuzzy picture was for nothing
good enough ;)

CTX1924_V2

isl6405ezr.
Most important chip on it ;)

saa7231ne

cx24120-13z

24118a12 clock 40.44

tda18271HDC2 clock 16.00

Looks like Manu has a lot already and also Sergey.

filename:   
/lib/modules/2.6.30.1/kernel/drivers/media/dvb/frontends/cx24120.ko
license:GPL
author: Sergey Tyurin
description:DVB Frontend module for Conexant CX24120/CX24118
hardware
srcversion: C9FCDA7FA6E37AED28B5DD8
depends:i2c-core
vermagic:   2.6.30.1 SMP preempt mod_unload
parm:   cx24120_debug:Activates frontend debugging (default:0)
(int)

But still seems to be a long road.

BTW, there are lots of complaints about overheating for that card within
short time on the original machine, what I don't see on my old AMD Quad
machine.

DVB-T looks ok on vista, did not test any analog stuff yet, but DVB-S is
very poor. Not even 50% of the usual services. S2 not tested, need to
move the dish.

Looks like we might import a DVB-S bug from initial m$ drivers again?

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: [IR RC, REGRESSION] Didn't work IR RC

2010-03-01 Thread hermann pitton
Hi,

Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho Chehab: 
 Andy Walls wrote:
  On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
  Hi All
 
  After rework of the IR subsystem, IR RC no more work in our TV cards.
  As I see 
  call saa7134_probe_i2c_ir,
configure i2c
call i2c_new_device
 
  New i2c device not registred.
 
  The module kbd-i2c-ir loaded after i2c_new_device.
  
  Jean,
  
  There was also a problem reported with the cx23885 driver's I2C
  connected IR by Timothy Lenz:
  
  http://www.spinics.net/lists/linux-media/msg15122.html
  
  The failure mode sounds similar to Dmitri's, but maybe they are
  unrelated.
  
  I worked a bit with Timothy on IRC and the remote device fails to be
  detected whether ir-kbd-i2c is loaded before the cx23885 driver or after
  the cx23885 driver.  I haven't found time to do any folow-up and I don't
  have any of the hardware in question.
  
  Do you have any thoughts or a suggested troubleshooting approach?
 
 Andy/Dmitri,
 
 With the current i2c approach, the bridge driver is responsible for binding
 an i2c device into the i2c adapter. In other words, the bridge driver should
 have some logic to know what devices use ir-kbd-i2c, loading it at the right
 i2c address(es). Manually loading IR shouldn't make any difference.

yes, we have info.addr at saa7134-input and Dmitri did add the Beholder
IR address there recently.

 From Andy's comment, I suspect that such logic is missing at cx23885 for the 
 board
 you're referring. Not sure if this is the same case of the boards Dmitri is
 concerned about.

On a first look, Andy seems not to provide the IR addr from the bridge
and without probing it can't work anymore.

 It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so,
 if this is the case, a patch should be sent also to -stable.
 
 In the case of saa7134, Jean worked on a fix for some boards:
   http://patchwork.kernel.org/patch/75883/
 
 He is currently waiting for someone with the affected boards to test it and
 give some return.

That fix should be unrelated and both variants of the patch are not
anywhere yet.

We can fake this single board in question on a P7131 Dual, but my
receiver is broken, else all looked O.K., and it seems not worth yet to
ask Mauro to lose time on faking it, assuming his IR receiver does still
work.

Here we can simply wait for Daro coming back from skiing, or can even
apply already Jean's solution per this card without any risk.

Else, do we not check for kernels  2.6.30 on hg v4l-dvb not using auto
probing anymore? I tested only on two machines with some 2.6.30 and one
with 2.6.29 and recent hg v4l-dvb. There at least all was fine, also
with the patch moving IR init1 to saa7134_input_init2 and also for
ir-kbd-ic2 for a early Pinnacle 310i under all conditions.

Dmitri, on what kernel and/or SCM version of v4l-dvb you discover that
flaw? Maybe I can reproduce it then.

Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but breaks on
2.6.32. Do we already run out of sync?

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: Problems with Pinnacle 310i (saa7134) and recent kernels

2010-02-28 Thread hermann pitton
Hi Avl,

Am Samstag, den 20.02.2010, 11:49 + schrieb Avl Jawrowski:
 Hi, sorry for the late.
 
 hermann pitton hermann-pitton at arcor.de writes:
 
   But I can't see any video.
   With Kaffeine I can see the same channels as well.
  
  My guess is, kaffeine has a bit more trust in error correction,
  but you over all reception quality seems to be on a critical limit.
 
 In Kaffeine I see signal at 72% and SNR at 100% for that channel, so I don't
 think it's so bad.

yes, should be good enough.

  So it is still some sort of 310i, but you should mention the new name
  and that the remote chip on 0x47/0x8e is not detected.
 
 I add a note and some photos:
 
 http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_(310i)
 
 Can I add any other useful information, log or photo?

We most likely need the former Pinnacle devs here, if not already fired.
Maybe Mike and Devin can agree these days on it and it seems some
work-flow does recover.

You can have from me all details for the early device I do have now,
after later ones caused more confusion, and of course can use all that
on the wiki.

Let me know, I'll sent photos off list then.

After latest on wiki stuff, I'm for sure not interested to have an
account and was always in doubt, how to separate developer announces and
user reports there.

I did vote for user reports, if in doubt, since you can't match all
conditions, at least for such cards I was involved, and did stay away,
even on worst wrong stuff you sometimes can read there.

Either that wiki idea works or not. In longer terms it should,
but can also become pretty crufty 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


  1   2   3   4   5   >