Re: Almost got remote working with my Winfast tv usb II Deluxe box

2009-10-26 Thread Oldřich Jedlička
On Sunday 25 of October 2009 at 21:44:20, Magnus Alm wrote:
 Hi!

Hi Magnus,

 This is on Ubuntu 9.04, kernel 2.6.28-16.
 I get the following in dmesg when pressing channel down on my remote:

 [ 3517.984559] : unknown key: key=0x90 raw=0x90 down=1
 [ 3518.096558] : unknown key: key=0x90 raw=0x90 down=0

 That should correspond with the following row in my keytable in ir-keymaps:

   { 0x90, KEY_CHANNELDOWN},   /* CHANNELDOWN */


That is right. The unknown key gives a hint for your keymap. After you 
define all keys, you should fully enjoy your remote control.

 Do I need to configure lirc also?

The keys are emitted via the evdev subsystem, so the remote control behaves 
like a normal keyboard (when you press 1 you should see 1 on the console 
too). Either you will learn your application to directly understand the key 
presses (just change it's keyboard shortcuts), or you can use the lirc's 
devinput driver (it reads keypresses from evdev) and do it via lirc. It's up 
to you.

Oldrich.

 But since something responds (ir-common ?) to my pressing on the
 remote I thought it shouldn't be necessary.

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


[PATCH, RESEND] Update ALSA capture controls according to selected source.

2009-08-22 Thread Oldřich Jedlička
The patch introduces new snd_saa7134_capsrc_set (code taken from
snd_saa7134_capsrc_put) that updates also the ALSA capture controls during
snd_card_saa7134_capture_prepare and snd_saa7134_capsrc_put.

There can be much more work done in order to unify the control of the card
(now the card's capture source is tuned/switched in saa7134-video.c too), but
I don't have enough time. This work could be a starting point, but it can be
applied as-is too (it doesn't need any further work to make it working).

Signed-off-by: Oldřich Jedlička oldium@seznam.cz

diff --git a/linux/drivers/media/video/saa7134/saa7134-alsa.c 
b/linux/drivers/media/video/saa7134/saa7134-alsa.c
index 504186a..0d9c833 100644
--- a/linux/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/linux/drivers/media/video/saa7134/saa7134-alsa.c
@@ -41,6 +41,7 @@ MODULE_PARM_DESC(debug,enable debug messages [alsa]);
  */
 
 /* defaults */
+#define MIXER_ADDR_UNSELECTED  -1
 #define MIXER_ADDR_TVTUNER 0
 #define MIXER_ADDR_LINE1   1
 #define MIXER_ADDR_LINE2   2
@@ -69,7 +70,9 @@ typedef struct snd_card_saa7134 {
struct snd_card *card;
spinlock_t mixer_lock;
int mixer_volume[MIXER_ADDR_LAST+1][2];
-   int capture_source[MIXER_ADDR_LAST+1][2];
+   int capture_source_addr;
+   int capture_source[2];
+   struct snd_kcontrol *capture_ctl[MIXER_ADDR_LAST+1];
struct pci_dev *pci;
struct saa7134_dev *dev;
 
@@ -319,6 +322,115 @@ static int dsp_buffer_free(struct saa7134_dev *dev)
return 0;
 }
 
+/*
+ * Setting the capture source and updating the ALSA controls
+ */
+static int snd_saa7134_capsrc_set(struct snd_kcontrol *kcontrol,
+ int left, int right, bool force_notify)
+{
+   snd_card_saa7134_t *chip = snd_kcontrol_chip(kcontrol);
+   int change = 0, addr = kcontrol-private_value;
+   int active, old_addr;
+   u32 anabar, xbarin;
+   int analog_io, rate;
+   struct saa7134_dev *dev;
+
+   dev = chip-dev;
+
+   spin_lock_irq(chip-mixer_lock);
+
+   active = left != 0 || right != 0;
+   old_addr = chip-capture_source_addr;
+
+   /* The active capture source cannot be deactivated */
+   if (active) {
+   change = old_addr != addr ||
+chip-capture_source[0] != left ||
+chip-capture_source[1] != right;
+
+   chip-capture_source[0] = left;
+   chip-capture_source[1] = right;
+   chip-capture_source_addr = addr;
+   dev-dmasound.input = addr;
+   }
+   spin_unlock_irq(chip-mixer_lock);
+
+   if (change) {
+   switch (dev-pci-device) {
+
+   case PCI_DEVICE_ID_PHILIPS_SAA7134:
+   switch (addr) {
+   case MIXER_ADDR_TVTUNER:
+   saa_andorb(SAA7134_AUDIO_FORMAT_CTRL,
+  0xc0, 0xc0);
+   saa_andorb(SAA7134_SIF_SAMPLE_FREQ,
+  0x03, 0x00);
+   break;
+   case MIXER_ADDR_LINE1:
+   case MIXER_ADDR_LINE2:
+   analog_io = (MIXER_ADDR_LINE1 == addr) ?
+0x00 : 0x08;
+   rate = (32000 == dev-dmasound.rate) ?
+   0x01 : 0x03;
+   saa_andorb(SAA7134_ANALOG_IO_SELECT,
+  0x08, analog_io);
+   saa_andorb(SAA7134_AUDIO_FORMAT_CTRL,
+  0xc0, 0x80);
+   saa_andorb(SAA7134_SIF_SAMPLE_FREQ,
+  0x03, rate);
+   break;
+   }
+
+   break;
+   case PCI_DEVICE_ID_PHILIPS_SAA7133:
+   case PCI_DEVICE_ID_PHILIPS_SAA7135:
+   xbarin = 0x03; /* adc */
+   anabar = 0;
+   switch (addr) {
+   case MIXER_ADDR_TVTUNER:
+   xbarin = 0; /* Demodulator */
+   anabar = 2; /* DACs */
+   break;
+   case MIXER_ADDR_LINE1:
+   anabar = 0;  /* aux1, aux1 */
+   break;
+   case MIXER_ADDR_LINE2:
+   anabar = 9;  /* aux2, aux2 */
+   break;
+   }
+
+   /* output xbar always main channel */
+   saa_dsp_writel(dev, SAA7133_DIGITAL_OUTPUT_SEL1,
+  0x10);
+
+   if (left || right) {
+   /* We've

[PATCH] Report only 32kHz for ALSA

2009-08-18 Thread Oldřich Jedlička
There are several reasons:

 - SAA7133/35 uses DDEP (DemDec Easy Programming mode), which works in 32kHz
   only
 - SAA7134 for TV mode uses DemDec mode (32kHz)
 - Radio works in 32kHz only
 - When recording 48kHz from Line1/Line2, switching of capture source to TV
   means switching to 32kHz without any frequency translation

Signed-off-by: Oldřich Jedlička oldium@seznam.cz

diff --git a/linux/drivers/media/video/saa7134/saa7134-alsa.c 
b/linux/drivers/media/video/saa7134/saa7134-alsa.c
index c09ec3e..504186a 100644
--- a/linux/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/linux/drivers/media/video/saa7134/saa7134-alsa.c
@@ -440,6 +440,16 @@ snd_card_saa7134_capture_pointer(struct snd_pcm_substream 
* substream)
 
 /*
  * ALSA hardware capabilities definition
+ *
+ *  Report only 32kHz for ALSA:
+ *
+ *  - SAA7133/35 uses DDEP (DemDec Easy Programming mode), which works in 32kHz
+ *only
+ *  - SAA7134 for TV mode uses DemDec mode (32kHz)
+ *  - Radio works in 32kHz only
+ *  - When recording 48kHz from Line1/Line2, switching of capture source to TV
+ *means
+ *switching to 32kHz without any frequency translation
  */
 
 static struct snd_pcm_hardware snd_card_saa7134_capture =
@@ -453,9 +463,9 @@ static struct snd_pcm_hardware snd_card_saa7134_capture =
SNDRV_PCM_FMTBIT_U8 | \
SNDRV_PCM_FMTBIT_U16_LE | \
SNDRV_PCM_FMTBIT_U16_BE,
-   .rates =SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000,
+   .rates =SNDRV_PCM_RATE_32000,
.rate_min = 32000,
-   .rate_max = 48000,
+   .rate_max = 32000,
.channels_min = 1,
.channels_max = 2,
.buffer_bytes_max = (256*1024),
--
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] SAA713x setting audio capture frequency (ALSA)

2009-07-15 Thread Oldřich Jedlička
Hi Hartmut, Ricardo, Dmitri,

(hopefully I have the right addresses, if not - sorry for bothering :-))

Hermann recommended me to contact you for this issue. I would like to ask you 
if any of you (or any other reader!) is working on saa7134-alsa or 
saa7134-tvaudio or have any plans to do so. Also if you find any section 
below interresting, please comment it. I'm seeking for opinions from anybody 
who has more knowledge in saa713x audio programming than me :-)

My main concern is that ALSA reports wrong frequency for TV (48kHz) while it 
can use only 32kHz, second is the correct setting up of 48kHz for LINE1/LINE2 
(doesn't work at the moment). There are possibly also other concerns - ALSA 
controls update for example.

My plan is to come up with few patches after the discussion for another 
discussion.

On Monday 13 of July 2009 at 21:20:38, Oldrich Jedlicka wrote:
 Hi Hermann,

 On Monday 13 of July 2009 at 03:06:41, hermann pitton wrote:
  Hi Oldřich,
 
  this needs to be looked up during day time, preferably with the register
  settings for all involved saa713x devices, which I do not have ...

 You can respond the next day, no need to stay awake :-)

  Am Sonntag, den 12.07.2009, 19:48 +0200 schrieb Oldřich Jedlička:
   Hi all,
  
   I had a look at the audio code in saa7134 directory once again
   (saa7134-alsa.c and saa7134-tvaudio.c). It has one major problem - the
   frequency for SAA7134 isn't set during startup, only during the capture
   source change (that is another problem). But let's start from
   beginning, please comment what you find interresting, I will create a
   patch after the discussion for another discussion :-).
 
  ;)
 
   1. SAA7133/SAA7135
  
   SAA7133/SAA7135 always use DDEP (DemDec Easy Programming) mode which
   runs on 32kHz only. There is no need to change the frequency at all, so
   everything works except that the info coming from ALSA reports both
   frequencies 32kHz and 48kHz as available for recording. This can be
   easily changed in snd_card_saa7134_hw_params to report only 32kHz for
   SAA7133/SAA7135.
 
  So, for now, agreed. But you should try to talk to Ricardo and Hartmut
  in this case. I can tell you about the three years it did not work.

 Do you mean Ricardo Carrillo Cruz and Hartmut Hackmann? I've found them via
 Google (Google knows everyone :-)) I can add them to CC. Do you know if
 they are still working on the code (saa7134-tvaudio, saa7134-alsa)?

   2. SAA7134
  
   SAA7134 is special in the way it programs the frequency by hand. It
   uses 32kHz DemDec mode for TV (DemDec works only in 32kHz mode), 32kHz
   for radio (this is locked), and 32kHz/48kHz for S-Video and Composite
   inputs. ALSA again reports both frequencies 32kHz and 48kHz as
   available for recording - this can be changed accordingly.
 
  Agreed.
 
   The problem is that the frequency is never changed during
   inicialization like it was in OSS code (see 2.6.24 kernel,
   saa7134_oss_init1 calls mixer_recsrc). I think that this responsibility
   is now on the
   snd_card_saa7134_capture_prepare method - it should set the frequency
   in SAA7134_SIF_SAMPLE_FREQ register correctly, possibly also
   SAA7134_ANALOG_IO_SELECT. Note that the tvaudio's mute_input_7134 sets
   the frequency to 32kHz, this can be thrown away I think.
 
  Agreed. If any, that is the only regression to report compared to
  saa7134-oss.
 
   I tried to set SAA7134_SIF_SAMPLE_FREQ in
   snd_card_saa7134_capture_prepare and the capturing works correctly with
   48kHz from my digital camera (Composite input).
 
  OK, that should be previous behaviour then.
 
   3. Changing the capture source
  
   The ALSA interface has three capture sources, all of them have left and
   right channels (boolean values) - LINE1, LINE2 and TV. The user can
   select any source - ALSA calls snd_saa7134_capsrc_put.
 
  Note, without looking any further, LINE1 and LINE2 are left/right
  _pairs_ of stereo inputs. In saa7134-oss it was needed to select them
  card specific.

 I understand that they are left/right pairs. The saa7134-oss code knew
 about TV, LINE1, LINE2 and LINE2_LEFT possibilities. The LINE2_LEFT worked
 only on SAA7134 chip, because it programmed the OCS (output crossbar
 select) to record LINE2's left channel only. I don't see anything special
 in 2.6.24 kernel in saa7134-oss.c for setting the LINE1/LINE2/LINE2_LEFT in
 a card specific manner (other than SAA7133/34/35). Moreover, the _correct_
 output channel selection for LINE2_LEFT wasn't done in saa7134-oss code,
 but in saa7134-tvaudio (which is a little bit strange).

 The biggest problem - when I read the specification that I've found years
 ago - is that I don't know which registers can be changed in the DDEP mode.
 Maybe it would be possible to enable the _real_ left/right-only channel
 selection for all SAA713x chips.

   The ALSA controls are not updated, so it is possible to select both
   LINE1 and LINE2 at the same time, but recording will use only

[RFC] SAA713x setting audio capture frequency (ALSA)

2009-07-12 Thread Oldřich Jedlička
Hi all,

I had a look at the audio code in saa7134 directory once again 
(saa7134-alsa.c and saa7134-tvaudio.c). It has one major problem - the 
frequency for SAA7134 isn't set during startup, only during the capture 
source change (that is another problem). But let's start from beginning, 
please comment what you find interresting, I will create a patch after the 
discussion for another discussion :-).

1. SAA7133/SAA7135

SAA7133/SAA7135 always use DDEP (DemDec Easy Programming) mode which runs 
on 32kHz only. There is no need to change the frequency at all, so 
everything works except that the info coming from ALSA reports both 
frequencies 32kHz and 48kHz as available for recording. This can be easily 
changed in snd_card_saa7134_hw_params to report only 32kHz for 
SAA7133/SAA7135.

2. SAA7134

SAA7134 is special in the way it programs the frequency by hand. It uses 32kHz 
DemDec mode for TV (DemDec works only in 32kHz mode), 32kHz for radio (this 
is locked), and 32kHz/48kHz for S-Video and Composite inputs. ALSA again 
reports both frequencies 32kHz and 48kHz as available for recording - this 
can be changed accordingly.

The problem is that the frequency is never changed during inicialization like 
it was in OSS code (see 2.6.24 kernel, saa7134_oss_init1 calls mixer_recsrc). 
I think that this responsibility is now on the 
snd_card_saa7134_capture_prepare method - it should set the frequency in 
SAA7134_SIF_SAMPLE_FREQ register correctly, possibly also 
SAA7134_ANALOG_IO_SELECT. Note that the tvaudio's mute_input_7134 sets the 
frequency to 32kHz, this can be thrown away I think.

I tried to set SAA7134_SIF_SAMPLE_FREQ in snd_card_saa7134_capture_prepare  
and the capturing works correctly with 48kHz from my digital camera (Composite 
input).

3. Changing the capture source

The ALSA interface has three capture sources, all of them have left and right 
channels (boolean values) - LINE1, LINE2 and TV. The user can select any 
source - ALSA calls snd_saa7134_capsrc_put.

The ALSA controls are not updated, so it is possible to select both LINE1 and 
LINE2 at the same time, but recording will use only one of them - the last 
changed control wins. Moreover the left/right selection doesn't make any 
difference, the code ignores it.

Here comes also the frequency problem of SAA7134. If the user starts with 
LINE1 and 48kHz and tries to switch to TV, the frequency will change to 32kHz 
(DemDec mode) - the application will not know, I guess there will be some 
buffer underruns.

Note that any change of capture source control is overriden by the call to 
snd_card_saa7134_capture_prepare (called by ALSA before the capture source is 
opened) that takes the current input as set by saa7134_tvaudio_setinput 
(called by v4l interface). I think this is actually expected behaviour and 
can stay as it is now.

---

The easiest solution would be to throw away the capture source control and let 
the capture source initialization on the snd_card_saa7134_capture_prepare 
method (the source would be controlled by saa7134_tvaudio_setinput only - 
through v4l interface only), or limit the frequency to 32kHz only so that any 
source can be freely selected on any SAA713x hardware.

Any other ideas, comments, corrections (I could be wrong in what I wrote, I'm 
not the SAA713x programming expert!), suggestions?

Cheers,
Oldrich.
--
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-video.c: poll method lose race condition

2009-05-18 Thread Oldřich Jedlička
Hi Figo Zhang,

On Monday 18 of May 2009 at 04:13:13, figo.zhang wrote:
 saa7134-video.c: poll method lose race condition


 Signed-off-by: Figo.zhang figo.zh...@kolorific.com
 ---
 drivers/media/video/saa7134/saa7134-video.c |9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)

 diff --git a/drivers/media/video/saa7134/saa7134-video.c
 b/drivers/media/video/saa7134/saa7134-video.c index 493cad9..95733df 100644
 --- a/drivers/media/video/saa7134/saa7134-video.c
 +++ b/drivers/media/video/saa7134/saa7134-video.c
 @@ -1423,11 +1423,13 @@ video_poll(struct file *file, struct
 poll_table_struct *wait) {
   struct saa7134_fh *fh = file-private_data;
   struct videobuf_buffer *buf = NULL;
 + unsigned int rc = 0;

   if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type)
   return videobuf_poll_stream(file, fh-vbi, wait);

   if (res_check(fh,RESOURCE_VIDEO)) {
 + mutex_lock(fh-cap.vb_lock);
   if (!list_empty(fh-cap.stream))
   buf = list_entry(fh-cap.stream.next, struct 
 videobuf_buffer, stream);
   } else {
 @@ -1446,13 +1448,14 @@ video_poll(struct file *file, struct
 poll_table_struct *wait) }

   if (!buf)
 - return POLLERR;
 + rc = POLLERR;

Just one note (I don't know the future and meaning of this patch). The line 
above will change the meaning of the buf==NULL check. It will not return 
immediately, but call poll_wait with buf-done instead - NULL pointer access.

Cheers,
Oldrich.


   poll_wait(file, buf-done, wait);
   if (buf-state == VIDEOBUF_DONE ||
   buf-state == VIDEOBUF_ERROR)
 - return POLLIN|POLLRDNORM;
 - return 0;
 + rc = POLLIN|POLLRDNORM;
 + mutex_unlock(fh-cap.vb_lock);
 + return rc;

  err:
   mutex_unlock(fh-cap.vb_lock);


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


Re: [PATCH 0/8] ir-kbd-i2c conversion to the new i2c binding model (v3)

2009-05-14 Thread Oldřich Jedlička
On Wednesday 13 of May 2009 at 21:45:59, Jean Delvare wrote:
 Hi all,

 Here comes an update of my conversion of ir-kbd-i2c to the new i2c
 binding model. I've split it into 8 pieces for easier review. Firstly
 there is 1 preliminary patch:


Hi Jean,

works for me, as usual :-) I've used the all-in-one patch and the up-to-date 
v4l-dvb tree (compiled yesterday for completeness).

Cheers,
Oldrich.

 01-ir-kbd-i2c-dont-abuse-client-name.patch

 Then 3 patches doing the actual conversion:

 02-ir-kbd-i2c-convert-to-new-style.patch
 03-configure-ir-receiver.patch
 04-ir-kbd-i2c-dont-bind-to-unsupported-devices.patch

 Then 2 patches cleaning up saa7134-input thanks to the new
 possibilities offered by the conversion:

 05-saa7134-input-cleanup-msi-ir.patch
 06-saa7134-input-cleanup-avermedia-cardbus.patch

 And lastly driver-specific adjustments:
 07-ir-add-lirc-addresses.patch
 08-pvrusb2-enable-ir_video-by-default.patch

 This patch set is against the v4l-dvb repository, but I didn't pay
 attention to the compatibility issues. I simply build-tested it on
 2.6.27, 2.6.29 and 2.6.30-rc5.

 This patch set touches many different drivers and I can't test any of
 them. My only TV card with an IR receiver doesn't make use of
 ir-kbd-i2c. So I would warmly welcome testers. The more testing my
 changes can get, the better.

 And of course I welcome reviews and comments as well. I had to touch
 many drivers I don't know anything about so it is possible that I
 missed something.

 The main difference with my previous patch set is that it is adjusted
 to apply after Mike Isely's recent prvusb2 patches.

 I'll post all 8 patches as replies to this post. They can also be
 temporarily downloaded from:
   http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/
 Additionally I've put a combined patch there, to make testing easier:
  
 http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN
-ONE.patch But for review the individual patches are much better.

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


[PATCH] Added support for AVerMedia Cardbus Plus

2009-04-14 Thread Oldřich Jedlička
Here comes the full support for AVerMedia Cardbus Plus (E501R) - including
remote control. TV, Composite and FM radio tested, I don't have S-Video to 
test. I've figured out that the radio works only with xtal frequency 13MHz.

Signed-off-by: Oldřich Jedlička oldium@seznam.cz
---
diff -r dba0b6fae413 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h   Thu Apr 09 08:21:42 
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134.h   Mon Apr 13 23:21:53 
2009 
+0200
@@ -282,6 +282,7 @@
 #define SAA7134_BOARD_HAUPPAUGE_HVR1120 155
 #define SAA7134_BOARD_HAUPPAUGE_HVR1110R3   156
 #define SAA7134_BOARD_AVERMEDIA_STUDIO_507UA 157
+#define SAA7134_BOARD_AVERMEDIA_CARDBUS_501 158
 
 #define SAA7134_MAXBOARDS 32
 #define SAA7134_INPUT_MAX 8
diff -r dba0b6fae413 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Apr 09 08:21:42 
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon Apr 13 23:21:53 
2009 +0200
@@ -1669,6 +1669,39 @@
.amux = LINE1,
},
},
+   [SAA7134_BOARD_AVERMEDIA_CARDBUS_501] = {
+   /* kees.b...@cwi.nl */
+   .name   = AVerMedia Cardbus TV/Radio (E501R),
+   .audio_clock= 0x187de7,
+   .tuner_type = TUNER_ALPS_TSBE5_PAL,
+   .radio_type = TUNER_TEA5767,
+   .tuner_addr = 0x61,
+   .radio_addr = 0x60,
+   .tda9887_conf   = TDA9887_PRESENT,
+   .gpiomask   = 0x0800,
+   .inputs = {{
+   .name = name_tv,
+   .vmux = 1,
+   .amux = TV,
+   .tv   = 1,
+   .gpio = 0x0800,
+   },{
+   .name = name_comp1,
+   .vmux = 3,
+   .amux = LINE1,
+   .gpio = 0x0800,
+   },{
+   .name = name_svideo,
+   .vmux = 8,
+   .amux = LINE1,
+   .gpio = 0x0800,
+   }},
+   .radio = {
+   .name = name_radio,
+   .amux = LINE2,
+   .gpio = 0x,
+   },
+   },
[SAA7134_BOARD_CINERGY400_CARDBUS] = {
.name   = Terratec Cinergy 400 mobile,
.audio_clock= 0x187de7,
@@ -5104,6 +5137,13 @@
.subdevice= 0xd6ee,
.driver_data  = SAA7134_BOARD_AVERMEDIA_CARDBUS,
},{
+   /* AVerMedia CardBus */
+   .vendor   = PCI_VENDOR_ID_PHILIPS,
+   .device   = PCI_DEVICE_ID_PHILIPS_SAA7134,
+   .subvendor= 0x1461, /* Avermedia Technologies Inc */
+   .subdevice= 0xb7e9,
+   .driver_data  = SAA7134_BOARD_AVERMEDIA_CARDBUS_501,
+   },{
/* TransGear 3000TV */
.vendor   = PCI_VENDOR_ID_PHILIPS,
.device   = PCI_DEVICE_ID_PHILIPS_SAA7130,
@@ -6341,6 +6381,16 @@
saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x, 0x);
msleep(10);
break;
+   case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
+   /* power-down tuner chip */
+   saa_andorl(SAA7134_GPIO_GPMODE0  2,   0x0840, 0x0840);
+   saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x0840, 0);
+   msleep(10);
+   saa_andorl(SAA7134_GPIO_GPMODE0  2,   0x0840, 0x0840);
+   saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x0840, 0x0840);
+   msleep(10);
+   dev-has_remote = SAA7134_REMOTE_I2C;
+   break;
case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
saa7134_set_gpio(dev, 23, 0);
msleep(10);
@@ -6782,6 +6832,7 @@
 
switch (dev-board) {
case SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM:
+   case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
{
struct v4l2_priv_tun_config tea5767_cfg;
struct tea5767_ctrl ctl;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Use correct sampling rate for TV/FM radio

2009-04-14 Thread Oldřich Jedlička
Here is the fix for using the 32kHz sampling rate for TV and FM radio (ALSA).
The TV uses 32kHz anyway (mode 0; 32kHz demdec on), radio works only with
32kHz (mode 1; 32kHz baseband). The ALSA wrongly reported 32kHz and 48kHz for
everything (TV, radio, LINE1/2).

Now it should be possible to just use the card without the need to change the
capture rate from 48kHz to 32kHz. Enjoy :-)

Signed-off-by: Oldřich Jedlička oldium@seznam.cz
---
diff -r dba0b6fae413 linux/drivers/media/video/saa7134/saa7134-alsa.c
--- a/linux/drivers/media/video/saa7134/saa7134-alsa.c  Thu Apr 09 08:21:42 
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-alsa.c  Mon Apr 13 23:07:22 
2009 +0200
@@ -465,6 +465,29 @@
.periods_max =  1024,
 };
 
+static struct snd_pcm_hardware snd_card_saa7134_capture_32kHz_only =
+{
+   .info = (SNDRV_PCM_INFO_MMAP | 
SNDRV_PCM_INFO_INTERLEAVED |
+SNDRV_PCM_INFO_BLOCK_TRANSFER |
+SNDRV_PCM_INFO_MMAP_VALID),
+   .formats =  SNDRV_PCM_FMTBIT_S16_LE | \
+   SNDRV_PCM_FMTBIT_S16_BE | \
+   SNDRV_PCM_FMTBIT_S8 | \
+   SNDRV_PCM_FMTBIT_U8 | \
+   SNDRV_PCM_FMTBIT_U16_LE | \
+   SNDRV_PCM_FMTBIT_U16_BE,
+   .rates =SNDRV_PCM_RATE_32000,
+   .rate_min = 32000,
+   .rate_max = 32000,
+   .channels_min = 1,
+   .channels_max = 2,
+   .buffer_bytes_max = (256*1024),
+   .period_bytes_min = 64,
+   .period_bytes_max = (256*1024),
+   .periods_min =  4,
+   .periods_max =  1024,
+};
+
 static void snd_card_saa7134_runtime_free(struct snd_pcm_runtime *runtime)
 {
snd_card_saa7134_pcm_t *pcm = runtime-private_data;
@@ -651,7 +674,13 @@
pcm-substream = substream;
runtime-private_data = pcm;
runtime-private_free = snd_card_saa7134_runtime_free;
-   runtime-hw = snd_card_saa7134_capture;
+
+   if (amux == TV || card(dev).radio == dev-input) {
+   /* TV uses 32kHz sampling, AM/FM radio is locked to 32kHz */
+   runtime-hw = snd_card_saa7134_capture_32kHz_only;
+   } else {
+   runtime-hw = snd_card_saa7134_capture;
+   }
 
if (dev-ctl_mute != 0) {
saa7134-mute_was_on = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html