Re: [alsa-devel] [PATCH] MEDIA: Fix non-ISA_DMA_API link failure of sound code
At Fri, 24 Jun 2011 14:30:09 +0100, Ralf Baechle wrote: A build with ISA ISA_DMA !ISA_DMA_API results in: CC sound/isa/es18xx.o sound/isa/es18xx.c: In function ‘snd_es18xx_playback1_prepare’: sound/isa/es18xx.c:501:9: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es18xx.c: In function ‘snd_es18xx_playback_pointer’: sound/isa/es18xx.c:818:3: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/es18xx.o] Error 1 CC sound/isa/sscape.o sound/isa/sscape.c: In function ‘upload_dma_data’: sound/isa/sscape.c:481:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/sscape.o] Error 1 CC sound/isa/ad1816a/ad1816a_lib.o sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_prepare’: sound/isa/ad1816a/ad1816a_lib.c:244:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_pointer’: sound/isa/ad1816a/ad1816a_lib.c:302:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_free’: sound/isa/ad1816a/ad1816a_lib.c:544:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/ad1816a/ad1816a_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/ad1816a] Error 2 CC sound/isa/es1688/es1688_lib.o sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_prepare’: sound/isa/es1688/es1688_lib.c:417:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_pointer’: sound/isa/es1688/es1688_lib.c:509:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/es1688/es1688_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/es1688] Error 2 CC sound/isa/gus/gus_dma.o sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_program’: sound/isa/gus/gus_dma.c:79:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_done’: sound/isa/gus/gus_dma.c:177:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_dma.o] Error 1 CC sound/isa/gus/gus_pcm.o sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_prepare’: sound/isa/gus/gus_pcm.c:591:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_pointer’: sound/isa/gus/gus_pcm.c:619:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_pcm.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/gus] Error 2 CC sound/isa/sb/sb16_csp.o sound/isa/sb/sb16_csp.c: In function ‘snd_sb_csp_ioctl’: sound/isa/sb/sb16_csp.c:228:227: error: case label does not reduce to an integer constant make[3]: *** [sound/isa/sb/sb16_csp.o] Error 1 CC sound/isa/sb/sb16_main.o sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_prepare’: sound/isa/sb/sb16_main.c:276:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_pointer’: sound/isa/sb/sb16_main.c:456:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb16_main.o] Error 1 CC sound/isa/sb/sb8_main.o sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_prepare’: sound/isa/sb/sb8_main.c:172:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_pointer’: sound/isa/sb/sb8_main.c:425:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb8_main.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/sb] Error 2 CC
debugging dib0700
Hi All, I want to debug my problems with the dib0700 dvb-t driver. I have never debugged anything in the kernel before. I know howto code in C. Where should I start? What articles should I read? Where can I ask questions? Best regards, Cedric -- 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] [media] Stop using linux/version.h on most drivers
On Friday, June 24, 2011 20:25:26 Mauro Carvalho Chehab wrote: All the modified drivers didn't have any version increment since Jan, 1 2011. Several of them didn't have any version increment for a long time, even having new features and important bug fixes happening. As we're now filling the QUERYCAP version with the current Kernel Release, we don't need to maintain a per-driver version control anymore. So, let's just use the default. In order to preserve the Kernel module version history, a KERNEL_VERSION() macro were added to all modified drivers, and the extraver number were incremented. I opted to preserve the per-driver version control to a few drivers: cx18, davinci, fsl-viu, gspca, ivtv, m5mols, soc_camera, pwc, s2255, s5p-fimc and sh_vou. The rationale is that the per-driver version control seems to be actively maintained on those. A few drivers are still using the legacy way to handle ioctl's. So, we can't do such change on them, otherwise, they'll break. Those are: uvc, pvrusb2, et61x251 and sn9c102. Yet, I think that the better for them would be to just use the default version numbering, instead of doing that by themselves. While here, removed a few not needed include linux/version.h. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Sorry, but I have to say NACK to this. If we do this, then we should do this consistently. I thought it over and filling it with the current kernel version would work well with one exception: the pwc driver has a major number of 10 which is larger than the kernel's major number. (cpia2 has a version of 3.0.0, so that just works). I am inclined to sort of close my eyes for that one and just replace it as well, but that's just me :-) The only thing that needs to be done is that media_build needs some hack to set the version field to the source git tree kernel version instead of the target's kernel version. To simplify that and to accomodate the four ioctl-legacy drivers we can make a simple include/media/version.h header that defines a V4L2_API_VERSION define. An alternative is to just add an api_version field to v4l2_querycap. That would work fine too. One reason for doing that may be to help out-of-tree drivers: for those a driver version *does* make sense. I know, we shouldn't have to care about out-of-tree drivers, but on the other hand why make life hard for them without a good reason? The more I think about it, the more I like the idea of an api_version field. It would keep pwc happy, it wouldn't require many changes to drivers, and it will not affect out-of-tree drivers. Regards, Hans --- Note: This patch assumes that cap-version = LINUX_VERSION_CODE is filled inside v4l2-ioctl [1] [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg33547.html drivers/media/video/arv.c |5 ++--- drivers/media/video/au0828/au0828-core.c|1 + drivers/media/video/au0828/au0828-video.c |5 - drivers/media/video/bt8xx/bttv-driver.c | 14 -- drivers/media/video/bt8xx/bttvp.h |3 --- drivers/media/video/bw-qcam.c |3 +-- drivers/media/video/c-qcam.c|3 +-- drivers/media/video/cpia2/cpia2.h |5 - drivers/media/video/cpia2/cpia2_v4l.c | 12 drivers/media/video/cx231xx/cx231xx-video.c | 14 -- drivers/media/video/cx231xx/cx231xx.h |1 - drivers/media/video/cx23885/altera-ci.c |1 - drivers/media/video/cx23885/cx23885-417.c |1 - drivers/media/video/cx23885/cx23885-core.c | 13 +++-- drivers/media/video/cx23885/cx23885-video.c |1 - drivers/media/video/cx23885/cx23885.h |3 +-- drivers/media/video/cx88/cx88-alsa.c| 19 --- drivers/media/video/cx88/cx88-blackbird.c | 20 +++- drivers/media/video/cx88/cx88-dvb.c | 18 +++--- drivers/media/video/cx88/cx88-mpeg.c| 11 +++ drivers/media/video/cx88/cx88-video.c | 21 +++-- drivers/media/video/cx88/cx88.h |4 ++-- drivers/media/video/em28xx/em28xx-video.c | 14 +- drivers/media/video/gspca/gl860/gl860.h |1 - drivers/media/video/hdpvr/hdpvr-core.c |1 + drivers/media/video/hdpvr/hdpvr-video.c |2 -- drivers/media/video/hdpvr/hdpvr.h |6 -- drivers/media/video/mem2mem_testdev.c |4 +--- drivers/media/video/pms.c |4 +--- drivers/media/video/pwc/pwc-ioctl.h |1 - drivers/media/video/pwc/pwc.h |8 drivers/media/video/saa7134/saa7134-core.c | 12 drivers/media/video/saa7134/saa7134-empress.c |1 -
Re: [alsa-devel] [PATCH] MEDIA: Fix non-ISA_DMA_API link failure of sound code
Em 25-06-2011 04:21, Takashi Iwai escreveu: At Fri, 24 Jun 2011 14:30:09 +0100, Ralf Baechle wrote: A build with ISA ISA_DMA !ISA_DMA_API results in: CC sound/isa/es18xx.o sound/isa/es18xx.c: In function ‘snd_es18xx_playback1_prepare’: sound/isa/es18xx.c:501:9: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es18xx.c: In function ‘snd_es18xx_playback_pointer’: sound/isa/es18xx.c:818:3: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/es18xx.o] Error 1 CC sound/isa/sscape.o sound/isa/sscape.c: In function ‘upload_dma_data’: sound/isa/sscape.c:481:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/sscape.o] Error 1 CC sound/isa/ad1816a/ad1816a_lib.o sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_prepare’: sound/isa/ad1816a/ad1816a_lib.c:244:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_pointer’: sound/isa/ad1816a/ad1816a_lib.c:302:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_free’: sound/isa/ad1816a/ad1816a_lib.c:544:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/ad1816a/ad1816a_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/ad1816a] Error 2 CC sound/isa/es1688/es1688_lib.o sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_prepare’: sound/isa/es1688/es1688_lib.c:417:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_pointer’: sound/isa/es1688/es1688_lib.c:509:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/es1688/es1688_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/es1688] Error 2 CC sound/isa/gus/gus_dma.o sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_program’: sound/isa/gus/gus_dma.c:79:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_done’: sound/isa/gus/gus_dma.c:177:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_dma.o] Error 1 CC sound/isa/gus/gus_pcm.o sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_prepare’: sound/isa/gus/gus_pcm.c:591:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_pointer’: sound/isa/gus/gus_pcm.c:619:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_pcm.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/gus] Error 2 CC sound/isa/sb/sb16_csp.o sound/isa/sb/sb16_csp.c: In function ‘snd_sb_csp_ioctl’: sound/isa/sb/sb16_csp.c:228:227: error: case label does not reduce to an integer constant make[3]: *** [sound/isa/sb/sb16_csp.o] Error 1 CC sound/isa/sb/sb16_main.o sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_prepare’: sound/isa/sb/sb16_main.c:276:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_pointer’: sound/isa/sb/sb16_main.c:456:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb16_main.o] Error 1 CC sound/isa/sb/sb8_main.o sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_prepare’: sound/isa/sb/sb8_main.c:172:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_pointer’: sound/isa/sb/sb8_main.c:425:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb8_main.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]:
Re: debugging dib0700
On Sat, 2011-06-25 at 12:07 +0200, cedric.dew...@telfort.nl wrote: Hi All, I want to debug my problems with the dib0700 dvb-t driver. I have never debugged anything in the kernel before. I know howto code in C. Where should I start? What articles should I read? Where can I ask questions? http://linuxtv.org/wiki/index.php/User_Information http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers http://git.linuxtv.org/media_build.git http://git.linuxtv.org/media_tree.git http://linuxtv.org/wiki/index.php/Developer_Section http://linuxtv.org/downloads/v4l-dvb-apis/ http://lwn.net/Kernel/LDD3/ http://linuxtv.org/lists.php Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] Stop using linux/version.h on most drivers
Em 25-06-2011 07:09, Hans Verkuil escreveu: On Friday, June 24, 2011 20:25:26 Mauro Carvalho Chehab wrote: All the modified drivers didn't have any version increment since Jan, 1 2011. Several of them didn't have any version increment for a long time, even having new features and important bug fixes happening. As we're now filling the QUERYCAP version with the current Kernel Release, we don't need to maintain a per-driver version control anymore. So, let's just use the default. In order to preserve the Kernel module version history, a KERNEL_VERSION() macro were added to all modified drivers, and the extraver number were incremented. I opted to preserve the per-driver version control to a few drivers: cx18, davinci, fsl-viu, gspca, ivtv, m5mols, soc_camera, pwc, s2255, s5p-fimc and sh_vou. The rationale is that the per-driver version control seems to be actively maintained on those. A few drivers are still using the legacy way to handle ioctl's. So, we can't do such change on them, otherwise, they'll break. Those are: uvc, pvrusb2, et61x251 and sn9c102. Yet, I think that the better for them would be to just use the default version numbering, instead of doing that by themselves. While here, removed a few not needed include linux/version.h. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Sorry, but I have to say NACK to this. If we do this, then we should do this consistently. IMO, all drivers should stop reporting its own version via V4L2 API: people forget to maintain it on a consistent way. That was my original proposal, and it can still be implemented later. This patch does it on a consistent way: on places were version is not updated for more than 6 months (2 kernel releases) and use video_ioctl2, the version string were replaced by a number that it is greater than the previous value. My original proposal were to replace it on every place, but you and Devin argued against. So, this approach is a mid-term: let's do it initially where it makes more sense, and discuss what will be done with the remaining drivers that implement their own version control. With the mid-term approach taken by this patch, we warrant that, when newer V4L2 core API changes are applied, the version number will also be incremented, reflecting that changes could have affected the driver. I thought it over and filling it with the current kernel version would work well with one exception: the pwc driver has a major number of 10 which is larger than the kernel's major number. (cpia2 has a version of 3.0.0, so that just works). That's what I've explained on my first email about this subject: the only driver that has a numbering 3.0.0 is the pwc driver, and it does that on a not consistent way: when you've removed the V4L1 API, you've incremented the version string, but you forgot to upgrade the caps-version. So, if any application is relying on it for pwc, the check is currently broken. I am inclined to sort of close my eyes for that one and just replace it as well, but that's just me :-) I like the idea of replacing pwc version to 3.0.0. We moved it into drivers/media at 2006-03-25. On that time, the version was: 9.0.2-unofficial, and only the V4L1 API was implemented. In other words, the pwc driver never returned version 3.0.0 to VIDIOC_QUERYCAP. So, it is safe to just use 3.x.y. Assuming that we'll be incrementing Kernel major versions on every 10 years, the namespace conflicts will happen 70 years from now ;) Seriously, I don't think we need to be concerned with a conflict with 10.0.x. numbering that will happen on lots of years in the future (also, because we probably won't use the extraver numbering). The only thing that needs to be done is that media_build needs some hack to set the version field to the source git tree kernel version instead of the target's kernel version. Yes. After applying those patches, we'll need to fix the out-of-tree media_build. It shouldn't be hard: a patch can just add a logic that uses a V4L2_VERSION version defined on v4l/v4l2-version.h, for example. To simplify that and to accomodate the four ioctl-legacy drivers we can make a simple include/media/version.h header that defines a V4L2_API_VERSION define. I would not care much about those. The current situation is: - et61x251: only one USB ID is currently supported there: 102c:6251, using the TAS5130D1B sensor. The gspca etoms driver supports the same USB ID with the same sensor. IMO, we can just move this driver to staging and remove it. - sn9c102: I think that there are still a few USB ID's there that aren't yet at the gspca/sonix* drivers, but Jean-François/Hans could give us a better status. Anyway, no new features or bug fixes are added there for a long time, and core changes should likely not affect this driver, as it doesn't use the subdev layer nor video_ioctl2. So, we can just keep its version there until its removal; - pvrusb2:
[PATCH] Make Compro VideoMate Vista T750F actually work
Based on the work of John Newbigin, Davor Emard and others who contributed
on the mailing lists.
The previous 'support' for this card was a partial merge of John's changes
that, as far as I can tell, never actually got the thing working (no DVB-T,
analog tuner not initialised).
Initialise the analog tuner properly and hook up the DVB tuner and demodulator.
DVB-T and analog now work (though I can't tune every DVB channel, but I think
there's an issue with the aerial and signal boosters here that is causing
me problems).
Signed-off-by: Carlos Corbacho car...@strangeworlds.co.uk
---
I've dropped remote control support for now - I need to re-review the original
patches in more detail and also differentiate between the T750 and T750F (I
know how to do this based on the eeprom, but that'll take some time to get
ready and getting the rest of the card working first is more important).
drivers/media/video/saa7134/saa7134-cards.c | 13 -
drivers/media/video/saa7134/saa7134-dvb.c | 25 +
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index e2062b2..0f9fb99 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -4951,8 +4951,9 @@ struct saa7134_board saa7134_boards[] = {
.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,
@@ -6992,6 +6993,11 @@ static int saa7134_xc2028_callback(struct saa7134_dev
*dev,
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;
}
@@ -7451,6 +7457,11 @@ int saa7134_board_init1(struct saa7134_dev *dev)
saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x0e05, 0x0c05);
saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x0e05, 0x0c05);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ /* enable the analog tuner */
+ saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000);
+ saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000);
+ break;
}
return 0;
}
diff --git a/drivers/media/video/saa7134/saa7134-dvb.c
b/drivers/media/video/saa7134/saa7134-dvb.c
index 996a206..1e4ef16 100644
--- a/drivers/media/video/saa7134/saa7134-dvb.c
+++ b/drivers/media/video/saa7134/saa7134-dvb.c
@@ -56,6 +56,7 @@
#include lgs8gxx.h
#include zl10353.h
+#include qt1010.h
#include zl10036.h
#include zl10039.h
@@ -939,6 +940,18 @@ static struct zl10353_config behold_x7_config = {
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config videomate_t750_zl10353_config = {
+ .demod_address = 0x0f,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .disable_i2c_gate_ctrl = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+ .i2c_address = 0x62
+};
+
+
/* ==
* tda10086 based DVB-S cards, helper functions
*/
@@ -1650,6 +1663,18 @@ static int dvb_init(struct saa7134_dev *dev)
__func__);
break;
+ case SAA7134_BOARD_VIDEOMATE_T750:
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+ videomate_t750_zl10353_config,
+ dev-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ 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,
--
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
RFC tuner-core: how to set vt-type in g_tuner?
Hi all, The tuner-core.c implementation does this at the start of g_tuner: if (check_mode(t, vt-type) == -EINVAL) return 0; vt-type = t-mode; The idea is that the vt-type is set depending on whether the VIDIOC_G_TUNER ioctl is called from a radio device node or a video device node. If we have a tuner that can do both radio and TV, then the type is set to whatever the current tuner mode is. This seems reasonable, but it will actually run into problems when g_tuner is called for audio demodulators like msp3400 or cx25840. These need to know the correct vt-type in order to fill in the right fields. The problem here is that the tuner subdevices are not necessarily called first. In fact, the msp3400/cx25840 are actually called first by ivtv. So the msp3400 will get called with type TV, and later the tuner may change that to type RADIO. This causes inconsistencies. This has actually been observed when testing with ivtv and a PVR-500. There are two solutions: 1) Audit the drivers and ensure that the tuner subdevices are registered first. 2) Do not allow the tuner to switch the type. The problem with 1 is that this will be hard to enforce in the long term. Another problem with 1 is that I do think it is a bit unexpected from an application PoV that the type is suddenly inconsistent with the node the ioctl is called from. The problem with 2 is that some sensible defaults need to be filled in if the a radio/TV tuner is called with vt-type set to a different mode than the current mode. I do not think that is very hard though: afc/signal can be 0, ditto for rxsubchans. The audmode field should just report the value last set with s_tuner. g_frequency has the same problem as g_tuner. I believe g_frequency shouldn't change the type either. Since it already has the last set frequency for tv or radio it can just report it. I think the second solution is the easiest to implement and the most intuitive as well. Comments? Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC tuner-core: how to set vt-type in g_tuner?
Em 25-06-2011 11:02, Hans Verkuil escreveu: Hi all, The tuner-core.c implementation does this at the start of g_tuner: if (check_mode(t, vt-type) == -EINVAL) return 0; vt-type = t-mode; The idea is that the vt-type is set depending on whether the VIDIOC_G_TUNER ioctl is called from a radio device node or a video device node. If we have a tuner that can do both radio and TV, then the type is set to whatever the current tuner mode is. This seems reasonable, but it will actually run into problems when g_tuner is called for audio demodulators like msp3400 or cx25840. These need to know the correct vt-type in order to fill in the right fields. The problem here is that the tuner subdevices are not necessarily called first. In fact, the msp3400/cx25840 are actually called first by ivtv. So the msp3400 will get called with type TV, and later the tuner may change that to type RADIO. This causes inconsistencies. This has actually been observed when testing with ivtv and a PVR-500. There are two solutions: 1) Audit the drivers and ensure that the tuner subdevices are registered first. 2) Do not allow the tuner to switch the type. (2) is the right thing to do. A VIDIOC_GET_foo should not change anything. They are supposed to be read only access. The problem with 1 is that this will be hard to enforce in the long term. Another problem with 1 is that I do think it is a bit unexpected from an application PoV that the type is suddenly inconsistent with the node the ioctl is called from. The problem with 2 is that some sensible defaults need to be filled in if the a radio/TV tuner is called with vt-type set to a different mode than the current mode. I do not think that is very hard though: afc/signal can be 0, ditto for rxsubchans. The audmode field should just report the value last set with s_tuner. g_frequency has the same problem as g_tuner. I believe g_frequency shouldn't change the type either. Since it already has the last set frequency for tv or radio it can just report it. I think the second solution is the easiest to implement and the most intuitive as well. Comments? Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 tuner-core: how to set vt-type in g_tuner?
On Saturday, June 25, 2011 16:17:18 Mauro Carvalho Chehab wrote:
Em 25-06-2011 11:02, Hans Verkuil escreveu:
Hi all,
The tuner-core.c implementation does this at the start of g_tuner:
if (check_mode(t, vt-type) == -EINVAL)
return 0;
vt-type = t-mode;
The idea is that the vt-type is set depending on whether the VIDIOC_G_TUNER
ioctl is called from a radio device node or a video device node. If we have
a
tuner that can do both radio and TV, then the type is set to whatever the
current tuner mode is.
This seems reasonable, but it will actually run into problems when g_tuner
is called for audio demodulators like msp3400 or cx25840. These need to know
the correct vt-type in order to fill in the right fields.
The problem here is that the tuner subdevices are not necessarily called
first.
In fact, the msp3400/cx25840 are actually called first by ivtv.
So the msp3400 will get called with type TV, and later the tuner may change
that
to type RADIO. This causes inconsistencies. This has actually been observed
when
testing with ivtv and a PVR-500.
There are two solutions:
1) Audit the drivers and ensure that the tuner subdevices are registered
first.
2) Do not allow the tuner to switch the type.
(2) is the right thing to do. A VIDIOC_GET_foo should not change anything.
They are
supposed to be read only access.
Great!
Can you review this patch? This implements solution 2. I think it's correct, but
it's tuner code, so you never know :-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 9006c9a..706fc11 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1119,8 +1119,7 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
if (check_mode(t, f-type) == -EINVAL)
return 0;
- f-type = t-mode;
- if (fe_tuner_ops-get_frequency !t-standby) {
+ if (f-type == t-mode fe_tuner_ops-get_frequency !t-standby) {
u32 abs_freq;
fe_tuner_ops-get_frequency(t-fe, abs_freq);
@@ -1128,7 +1127,7 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
DIV_ROUND_CLOSEST(abs_freq * 2, 125) :
DIV_ROUND_CLOSEST(abs_freq, 62500);
} else {
- f-frequency = (V4L2_TUNER_RADIO == t-mode) ?
+ f-frequency = (V4L2_TUNER_RADIO == f-type) ?
t-radio_freq : t-tv_freq;
}
return 0;
@@ -1152,32 +1151,33 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
if (check_mode(t, vt-type) == -EINVAL)
return 0;
- vt-type = t-mode;
- if (analog_ops-get_afc)
+ if (vt-type == t-mode analog_ops-get_afc)
vt-afc = analog_ops-get_afc(t-fe);
- if (t-mode == V4L2_TUNER_ANALOG_TV)
+ if (vt-type == V4L2_TUNER_ANALOG_TV)
vt-capability |= V4L2_TUNER_CAP_NORM;
- if (t-mode != V4L2_TUNER_RADIO) {
+ if (vt-type != V4L2_TUNER_RADIO) {
vt-rangelow = tv_range[0] * 16;
vt-rangehigh = tv_range[1] * 16;
return 0;
}
/* radio mode */
- vt-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
- if (fe_tuner_ops-get_status) {
- u32 tuner_status;
-
- fe_tuner_ops-get_status(t-fe, tuner_status);
- vt-rxsubchans =
- (tuner_status TUNER_STATUS_STEREO) ?
- V4L2_TUNER_SUB_STEREO :
- V4L2_TUNER_SUB_MONO;
+ if (vt-type == t-mode) {
+ vt-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
+ if (fe_tuner_ops-get_status) {
+ u32 tuner_status;
+
+ fe_tuner_ops-get_status(t-fe, tuner_status);
+ vt-rxsubchans =
+ (tuner_status TUNER_STATUS_STEREO) ?
+ V4L2_TUNER_SUB_STEREO :
+ V4L2_TUNER_SUB_MONO;
+ }
+ if (analog_ops-has_signal)
+ vt-signal = analog_ops-has_signal(t-fe);
+ vt-audmode = t-audmode;
}
- if (analog_ops-has_signal)
- vt-signal = analog_ops-has_signal(t-fe);
vt-capability |= V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
- vt-audmode = t-audmode;
vt-rangelow = radio_range[0] * 16000;
vt-rangehigh = radio_range[1] * 16000;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jun 25 19:00:32 CEST 2011 git hash:7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pctv452e.c: switch rc handling to rc.core
This is on top of the submitted pctv452e.c driver and was done similar
to how ttusb2 works. Tested with lirc (devinput) and ir-keytable(1).
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb/dvb-usb/pctv452e.c
+++ b/drivers/media/dvb/dvb-usb/pctv452e.c
@@ -98,6 +98,7 @@ struct pctv452e_state {
u8 c; /* transaction counter, wraps around... */
u8 initialized; /* set to 1 if 0x15 has been sent */
+ u16 last_rc_key;
};
static int
@@ -535,83 +536,10 @@ int pctv452e_power_ctrl(struct dvb_usb_d
return 0;
}
-/* Remote control stuff */
-static struct rc_map_table pctv452e_rc_keys[] = {
- {0x0700, KEY_MUTE},
- {0x0701, KEY_VENDOR}, // pinnacle logo (top middle)
- {0x0739, KEY_POWER},
- {0x0703, KEY_VOLUMEUP},
- {0x0709, KEY_VOLUMEDOWN},
- {0x0706, KEY_CHANNELUP},
- {0x070c, KEY_CHANNELDOWN},
- {0x070f, KEY_1},
- {0x0715, KEY_2},
- {0x0710, KEY_3},
- {0x0718, KEY_4},
- {0x071b, KEY_5},
- {0x071e, KEY_6},
- {0x0711, KEY_7},
- {0x0721, KEY_8},
- {0x0712, KEY_9},
- {0x0727, KEY_0},
- {0x0724, KEY_TV}, // left of '0'
- {0x072a, KEY_T}, // right of '0'
- {0x072d, KEY_REWIND},
- {0x0733, KEY_FORWARD},
- {0x0730, KEY_PLAY},
- {0x0736, KEY_RECORD},
- {0x073c, KEY_STOP},
- {0x073f, KEY_HELP}
-};
-
-/* Remote Control Stuff fo S2-3600 (copied from TT-S1500): */
-static struct rc_map_table tt_connect_s2_3600_rc_key[] = {
- {0x1501, KEY_POWER},
- {0x1502, KEY_SHUFFLE}, /* ? double-arrow key */
- {0x1503, KEY_1},
- {0x1504, KEY_2},
- {0x1505, KEY_3},
- {0x1506, KEY_4},
- {0x1507, KEY_5},
- {0x1508, KEY_6},
- {0x1509, KEY_7},
- {0x150a, KEY_8},
- {0x150b, KEY_9},
- {0x150c, KEY_0},
- {0x150d, KEY_UP},
- {0x150e, KEY_LEFT},
- {0x150f, KEY_OK},
- {0x1510, KEY_RIGHT},
- {0x1511, KEY_DOWN},
- {0x1512, KEY_INFO},
- {0x1513, KEY_EXIT},
- {0x1514, KEY_RED},
- {0x1515, KEY_GREEN},
- {0x1516, KEY_YELLOW},
- {0x1517, KEY_BLUE},
- {0x1518, KEY_MUTE},
- {0x1519, KEY_TEXT},
- {0x151a, KEY_MODE}, /* ? TV/Radio */
- {0x1521, KEY_OPTION},
- {0x1522, KEY_EPG},
- {0x1523, KEY_CHANNELUP},
- {0x1524, KEY_CHANNELDOWN},
- {0x1525, KEY_VOLUMEUP},
- {0x1526, KEY_VOLUMEDOWN},
- {0x1527, KEY_SETUP},
- {0x153a, KEY_RECORD},/* these keys are only in the black remote */
- {0x153b, KEY_PLAY},
- {0x153c, KEY_STOP},
- {0x153d, KEY_REWIND},
- {0x153e, KEY_PAUSE},
- {0x153f, KEY_FORWARD}
-};
-
-static int pctv452e_rc_query(struct dvb_usb_device *d, u32 *keyevent, int
*keystate) {
+static int pctv452e_rc_query(struct dvb_usb_device *d) {
struct pctv452e_state *state = (struct pctv452e_state *)d-priv;
u8 b[CMD_BUFFER_SIZE];
u8 rx[PCTV_ANSWER_LEN];
- u8 keybuf[5];
int ret, i;
u8 id = state-c++;
@@ -621,8 +549,6 @@ static int pctv452e_rc_query(struct dvb_
b[2] = PCTV_CMD_IR;
b[3] = 0;
- *keystate = REMOTE_NO_KEY_PRESSED;
-
/* send ir request */
ret = dvb_usb_generic_rw(d, b, 4, rx, PCTV_ANSWER_LEN, 0);
if (ret != 0) return ret;
@@ -637,16 +563,14 @@ static int pctv452e_rc_query(struct dvb_
if ((rx[3] == 9) (rx[12] 0x01)) {
/* got a press event */
+ state-last_rc_key = (rx[7] 8) | rx[6];
if (debug 2) {
printk(%s: cmd=0x%02x sys=0x%02x\n, __func__, rx[6],
rx[7]);
}
- keybuf[0] = 0x01;// DVB_USB_RC_NEC_KEY_PRESSED; why is this
#define'd privately?
- keybuf[1] = rx[7];
- keybuf[2] = ~keybuf[1]; // fake checksum
- keybuf[3] = rx[6];
- keybuf[4] = ~keybuf[3]; // fake checksum
- dvb_usb_nec_rc_key_to_event(d, keybuf, keyevent, keystate);
-
+ rc_keydown(d-rc_dev, state-last_rc_key, 0);
+ } else if (state-last_rc_key) {
+ rc_keyup(d-rc_dev);
+ state-last_rc_key = 0;
}
return 0;
@@ -1294,11 +1218,11 @@ static struct dvb_usb_device_properties
/* Untested. */
/* .read_mac_address = pctv452e_read_mac_address, */
- .rc.legacy = {
- .rc_map_table = pctv452e_rc_keys,
- .rc_map_size = ARRAY_SIZE(pctv452e_rc_keys),
+ .rc.core = {
+ .rc_interval = 100, /* Less than IR_KEYPRESS_TIMEOUT */
+ .rc_codes = RC_MAP_DIB0700_RC5_TABLE,
.rc_query = pctv452e_rc_query,
- .rc_interval = 100,
+ .allowed_protos = RC_TYPE_UNKNOWN,
},
.num_adapters = 1,
@@ -1352,11 +1276,11 @@ static struct dvb_usb_device_properties
Re: DM04 USB DVB-S TUNER
On Wed, 2011-06-08 at 16:20 +0100, Malcolm Priestley wrote: On Wed, 2011-06-08 at 14:18 +0300, Mehmet Altan Pire wrote: 07-06-2011 22:34, Malcolm Priestley yazmış: On Tue, 2011-06-07 at 06:31 +0100, Malcolm Priestley wrote: On Tue, 2011-06-07 at 02:28 +0300, Mehmet Altan Pire wrote: 06-06-2011 00:47, Malcolm Priestley yazmış: On Sun, 2011-06-05 at 21:42 +0100, Malcolm Priestley wrote: On Sun, 2011-06-05 at 19:34 +0300, Mehmet Altan Pire wrote: 05-06-2011 17:16, Malcolm Priestley yazmış: On Sun, 2011-06-05 at 03:35 +0300, Mehmet Altan Pire wrote: Hi, I have DM04 USB DVBS TUNER, using ubuntu with v4l media-build drivers/modules but device doesn't working (unknown device). lsusb message: ID 3344:22f0 under of the box: DM04P2011050176 Yes, i have windows xp driver, name is US2B0D.sys I sending it, attached in this mail. Thanks. Here is a modified lmedm04.c and lme2510b_fw.sh using the US2B0D.sys to modify the interrupt return. Ok, i tested it. Device recognized on WinXP with original driver, but tv application says no lock. I'm not sure it worked on WinXP but driver cd is original and succesfully loaded and recognized. Again tested on ubuntu with new lmedm04.c and lme2510b_fw.sh than make, make install, and restart. lsusb says: Bus 001 Device 008: ID 3344:1120 (changes 22f0 to 1120) dmesg says: Yes this should happen. The firmware will reboot with the correct id. My device different or chip is damaged? Label, box and driver cd title writes DM04P. DM04 and DM04P different devices? I think the id of the chip is faulty or default. I will test the firmware with LG tuner later. It is not the LG, s7395 or S0194 tuner. So the id is intentional. How does it identify itself in windows? tvboxspy 3. Tests :WinXP Test: I'm sure it worked on WinXP now. Tested with ProgDVB application. Signal, channel search and watching tv as succesfully. My Device working without problems on WinXP and it's not damaged. When device running on stream, green led is active, if not running, green led is passive (red led is power led and it's always active). Driver Info: LME_PCTV_DVBS_RS2000 VID3344 PID22F0 22f0 this number correct... I need to find out what exactly the RS2000 tuner is. So currently the linux driver is not supported with your device. A little update... I now have one of these devices. The chip is actually a M8BRS2000 which is a combi frontend/tuner device. The ID is confirmed as 3344:22f0, it appears to be patched by the Windows Driver as 3344:1120 devices try wrongly to use the RS2000 driver. There is no Linux frontend driver for this device. I will start to write one shortly, so support could be several months away. Regards Malcolm -- 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
