[PULL] http://kernellabs.com/hg/~mkrufky/fe_ioctl_override
Mauro, As described in the kernellabs.com blog entry, and mail archive links below, my RFC entitled, "[RFC] Allow bridge drivers to have better control over DVB frontend operations" had a very good response on the linux-media mailing list. http://www.kernellabs.com/blog/?p=715 http://www.mail-archive.com/linux-media@vger.kernel.org/msg09183.html Now that the merge window is closed, I'd like to have these changes merged into the master development repository. Please pull from: http://kernellabs.com/hg/~mkrufky/fe_ioctl_override for the following: - create a standard method for dvb adapter drivers to override frontend ioctls - cx23885: define a dvb frontend ioctl override function - dvb-usb: add fe_ioctl_override callback to dvb_usb_adapter_properties drivers/media/dvb/dvb-core/dvb_frontend.c | 20 - drivers/media/dvb/dvb-core/dvbdev.h | 28 +++ drivers/media/dvb/dvb-usb/dvb-usb-dvb.c |1 drivers/media/dvb/dvb-usb/dvb-usb.h |3 drivers/media/video/cx23885/cx23885-dvb.c | 39 +++--- drivers/media/video/cx23885/cx23885.h |4 - drivers/media/video/cx88/cx88-dvb.c |2 drivers/media/video/saa7134/saa7134-dvb.c |2 drivers/media/video/videobuf-dvb.c| 11 ++ include/media/videobuf-dvb.h |4 - 10 files changed, 93 insertions(+), 21 deletions(-) Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~mkrufky/v4l-dvb
Mauro, Included in this pull request are some important fixes to the tda18271 tuner driver. Please include these patches in your next pull request to Linus. Please pull from: http://kernellabs.com/hg/~mkrufky/v4l-dvb for the following: - tda18271: fix overflow in FM radio frequency calculation - tda8290: enable deemphasis_50 module parameter - tda18271: fix signedness issue in tda18271_rf_tracking_filters_init - tda18271: use temporary variables in tda18271_rf_tracking_filters_init - tda18271: more signedness fixes - merge: ~mkrufky/tda18271 - saa7134: add AGC control for Zolid Hybrid PCI card common/tuners/tda18271-fe.c | 84 -- common/tuners/tda18271-priv.h | 22 +++-- common/tuners/tda8290.c |2 video/saa7134/saa7134-cards.c | 25 ++ video/saa7134/saa7134-dvb.c |9 ++ 5 files changed, 94 insertions(+), 48 deletions(-) Cheers, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~mkrufky/dib0070
Mauro, I saw your changeset entitled, "dib0700: not building CONFIG_DVB_TUNER_DIB0070 breaks compilation" -- this works around the problem but does not fix it. In order to build the dib0700 driver without the dib0070 driver selected, I have backed out your change and replaced it with an actual fix. Please pull from: http://kernellabs.com/hg/~mkrufky/dib0070 for the following: - Backed out changeset 936f04b2c17a - dib0070: fix build dependency when driver is disabled dvb-usb/Kconfig |2 +- frontends/dib0070.h |7 ++- 2 files changed, 7 insertions(+), 2 deletions(-) Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part2
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part2 for the following 5 changesets: 01/05: v4l2-subdev: Add v4l2_subdev_ir_ops and IR notify defines for v4l2_device http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=8cbb951bbb9f 02/05: cx23885: Complete CX23888 IR subdev implementation for Rx & almost for Tx http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=a2d8d3d88c6d 03/05: cx23885: Add integrated IR subdevice interrupt and notification handling http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=1eb199665dbc 04/05: ir-functions: Export ir_rc5_decode() for use by the cx23885 module http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=55a1e2e8128f 05/05: cx23885: Add IR input keypress handling and enable for the HVR-1850 http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=b05a093688a2 b/linux/drivers/media/video/cx23885/cx23885-input.c | 422 +++ b/linux/drivers/media/video/cx23885/cx23885-input.h | 30 b/linux/drivers/media/video/cx23885/cx23885-ir.c| 128 ++ b/linux/drivers/media/video/cx23885/cx23885-ir.h| 36 linux/drivers/media/common/ir-functions.c |3 linux/drivers/media/video/cx23885/Makefile |4 linux/drivers/media/video/cx23885/cx23885-cards.c | 23 linux/drivers/media/video/cx23885/cx23885-core.c| 84 + linux/drivers/media/video/cx23885/cx23885-ir.c |4 linux/drivers/media/video/cx23885/cx23885-reg.h |5 linux/drivers/media/video/cx23885/cx23885.h | 13 linux/drivers/media/video/cx23885/cx23888-ir.c | 1139 +++- linux/include/media/ir-common.h |1 linux/include/media/v4l2-subdev.h | 94 + 14 files changed, 1932 insertions(+), 54 deletions(-) This is the remainder of the changes required to get IR Rx input keypress handling working for the HVR-1850. This builds upon my previous pull request for my cx23888-ir-part1 repo, which include Steven's patch. (This cx23888-ir-part2 repo also has all the patches in the cx23888-ir-part1 repo.) The changes to v4l2-subdev.h include the struct v4l2_subdev_ir_ops definition that Hans had OK'ed in previous e-mails plus a few other defines I felt needed to be common eventually. When both this and the previous pull request are merged, I can then work on IR support for CX23885 and CX23418 cards that use essentially the same integrated IR controller. Thanks, 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 1/4] tda18271_set_analog_params major bugfix
On Sun, Sep 27, 2009 at 4:24 PM, wrote:
> On Sun, Sep 27, 2009 at 12:35:00PM -0400, Michael Krufky wrote:
>> On Sun, Sep 27, 2009 at 12:25 PM, Michael Krufky
>> wrote:
>>
>> On a second thought, I see that my above patch loses some precision
>> ... this is even better:
>>
>> diff -r f52640ced9e8 linux/drivers/media/common/tuners/tda18271-fe.c
>> --- a/linux/drivers/media/common/tuners/tda18271-fe.c Tue Sep 15
>> 01:25:35 2009 -0400
>> +++ b/linux/drivers/media/common/tuners/tda18271-fe.c Sun Sep 27
>> 12:33:20 2009 -0400
>> @@ -1001,12 +1001,12 @@
>> struct tda18271_std_map_item *map;
>> char *mode;
>> int ret;
>> - u32 freq = params->frequency * 62500;
>> + u32 freq = params->frequency * 125 *
>> + ((params->mode == V4L2_TUNER_RADIO) ? 1 : 1000) / 2;
>>
>> priv->mode = TDA18271_ANALOG;
>>
>> if (params->mode == V4L2_TUNER_RADIO) {
>> - freq = freq / 1000;
>> map = &std_map->fm_radio;
>> mode = "fm";
>> } else if (params->std & V4L2_STD_MN) {
>>
>> Cheers,
>>
>> Mike
>
> Much better!
>
> Btw. It seems that the tuner is capable of tuning in 1000 Hz steps, is
> there a reason why we are using 62500 Hz steps?
That's the v4l2 analog tuner API. It has nothing to do with the
tda18271 driver internals. If you look on the digital set_params
function, you'll see that this doesnt happen there.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] tda18271_set_analog_params major bugfix
On Sun, Sep 27, 2009 at 12:35:00PM -0400, Michael Krufky wrote:
> On Sun, Sep 27, 2009 at 12:25 PM, Michael Krufky
> wrote:
>
> On a second thought, I see that my above patch loses some precision
> ... this is even better:
>
> diff -r f52640ced9e8 linux/drivers/media/common/tuners/tda18271-fe.c
> --- a/linux/drivers/media/common/tuners/tda18271-fe.c Tue Sep 15
> 01:25:35 2009 -0400
> +++ b/linux/drivers/media/common/tuners/tda18271-fe.c Sun Sep 27
> 12:33:20 2009 -0400
> @@ -1001,12 +1001,12 @@
> struct tda18271_std_map_item *map;
> char *mode;
> int ret;
> - u32 freq = params->frequency * 62500;
> + u32 freq = params->frequency * 125 *
> + ((params->mode == V4L2_TUNER_RADIO) ? 1 : 1000) / 2;
>
> priv->mode = TDA18271_ANALOG;
>
> if (params->mode == V4L2_TUNER_RADIO) {
> - freq = freq / 1000;
> map = &std_map->fm_radio;
> mode = "fm";
> } else if (params->std & V4L2_STD_MN) {
>
> Cheers,
>
> Mike
Much better!
Btw. It seems that the tuner is capable of tuning in 1000 Hz steps, is
there a reason why we are using 62500 Hz steps?
Regards,
Henk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
On Sun, 2009-09-27 at 14:14 -0400, Andy Walls wrote: > On Sun, 2009-09-27 at 12:58 -0400, Steven Toth wrote: > > >>> Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 > > Mauro, > > Please wait on my pull request until we resolve this problem. > > > Steve, > > > Regression testing has highlighted the 885/7/8 detection isn't reliable, > > causing > > a regression for HVR1800 - total loss of sync. (It's detected as a 885). > > I'm installing a mix of 885/7/8 boards now looking for a better detection > > solution. I'm hoping to have a patch available in the next couple of hours. Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 for the following 9 changesets: 01/09: v4l2-chip-ident: Add ID's needed for the cx23885 and cx25840 modules http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5b2b33f2e3d7 02/09: cx23885: Fix support for v4l2-dbg access to CX2388[578] and CX23417 regs http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f652c361b61d 03/09: cx23885: Add skeleton v4l2_subdev for the CX23888 integrated IR controller http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f153c30da5c5 04/09: cx25840: Improve detection of CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=0efbeb807ff0 05/09: cx25840: Convert chip/core family checks to static inline functions http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=80d278a74d8a 06/09: cx25840: Separate set_audclk_freq functionality for the different chips http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5f58b345e32e 07/09: cx25840: Init PLLs properly for CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=b1ebfabe9c60 08/09: cx23885: Enable HVR-1850 CX23888 A/V core to get VID_CLK running for IR http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=7d99cae94fe5 09/09: cx25840: Improvements to the cx23885/7/8 chip detection mechanism. http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=8cab484b0f93 b/linux/drivers/media/video/cx23885/cx23885-ioctl.c | 197 b/linux/drivers/media/video/cx23885/cx23885-ioctl.h | 39 + b/linux/drivers/media/video/cx23885/cx23888-ir.c | 233 + b/linux/drivers/media/video/cx23885/cx23888-ir.h | 28 + linux/drivers/media/video/cx23885/Makefile |3 linux/drivers/media/video/cx23885/cx23885-417.c | 10 linux/drivers/media/video/cx23885/cx23885-cards.c| 12 linux/drivers/media/video/cx23885/cx23885-core.c | 20 linux/drivers/media/video/cx23885/cx23885-ioctl.c| 11 linux/drivers/media/video/cx23885/cx23885-video.c| 34 - linux/drivers/media/video/cx23885/cx23885.h | 12 linux/drivers/media/video/cx25840/cx25840-audio.c| 461 ++- linux/drivers/media/video/cx25840/cx25840-core.c | 279 --- linux/drivers/media/video/cx25840/cx25840-core.h | 22 linux/drivers/media/video/cx25840/cx25840-firmware.c | 10 linux/include/media/v4l2-chip-ident.h| 16 16 files changed, 1158 insertions(+), 229 deletions(-) Many thanks to Steve Toth for testing this and finding and fixing my CX2388[578] detection discrimination problem. Thanks, 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: HVR1800 ATSC regression - Fails to attach DVB
On 9/27/09 3:08 PM, Andy Walls wrote: On Sun, 2009-09-27 at 11:19 -0400, Steven Toth wrote: I'm seeing a regression in tip. A Hauppauge HVR1800 model 78521 fails to have its demod for DTV attached correctly, resulting in a total loss of ATSC/QAM support. I'm looking into this. Thanks, but I don't think this was tip... Sorry for the noise, I had two bad piece of hardware. Please ignore. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR1800 ATSC regression - Fails to attach DVB
On Sun, 2009-09-27 at 11:19 -0400, Steven Toth wrote: > I'm seeing a regression in tip. A Hauppauge HVR1800 model 78521 fails to have > its demod for DTV attached correctly, resulting in a total loss of ATSC/QAM > support. > > I'm looking into this. Thanks, but I don't think this was tip... Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
On Sun, 2009-09-27 at 12:58 -0400, Steven Toth wrote: > >>> Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 Mauro, Please wait on my pull request until we resolve this problem. Steve, > Regression testing has highlighted the 885/7/8 detection isn't reliable, > causing > a regression for HVR1800 - total loss of sync. (It's detected as a 885). Shoot. OK, thanks for testing and finding it. I guess the registers I rely on not to respond to detect a CX23887 are responding anyway, causing my heuristic to declare a CX23885 - bummer. > Hardcoding the detect to return the correct type (887) causes the driver to > work > correctly for video (audio untested). This is very good news. > > I'm installing a mix of 885/7/8 boards now looking for a better detection > solution. I'm hoping to have a patch available in the next couple of hours. OK, thanks. > FYI 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Sun Sep 27 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13044:6b7617d4a0be gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 Regression testing has highlighted the 885/7/8 detection isn't reliable, causing a regression for HVR1800 - total loss of sync. (It's detected as a 885). Hardcoding the detect to return the correct type (887) causes the driver to work correctly for video (audio untested). This is very good news. I'm installing a mix of 885/7/8 boards now looking for a better detection solution. I'm hoping to have a patch available in the next couple of hours. FYI -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] tda18271_set_analog_params major bugfix
On Sun, Sep 27, 2009 at 12:25 PM, Michael Krufky wrote:
> On Thu, Sep 24, 2009 at 5:42 PM, wrote:
>> On Thu, Sep 24, 2009 at 02:46:06PM -0400, Michael Krufky wrote:
>>> On Tue, Sep 22, 2009 at 5:05 PM, wrote:
>>> >
>>> > Multiplication by 62500 causes an overflow in the 32 bits "freq" register
>>> > when
>>> > using radio. FM radio reception on a Zolid Hybrid PCI is now working.
>>> > Other
>>> > tda18271 configurations may also benefit from this change ;)
>>> >
>>> > Signed-off-by: henk.vergo...@gmail.com
>>> >
>>> > diff -r 29e4ba1a09bc linux/drivers/media/common/tuners/tda18271-fe.c
>> ...
>>> > - freq = freq / 1000;
>>> > + freq = params->frequency * 625;
>>> > + freq = freq / 10;
>>
>> Hmm now that I review my own patch:
>>
>> - freq = freq / 1000;
>> + freq = params->frequency * 125;
>> + freq = freq / 2;
>>
>> might even be better...
>
> Henk,
>
> That certainly is better, but I am going to go with an even simpler &
> cleaner approach:
>
> diff -r f52640ced9e8 linux/drivers/media/common/tuners/tda18271-fe.c
> --- a/linux/drivers/media/common/tuners/tda18271-fe.c Tue Sep 15
> 01:25:35 2009 -0400
> +++ b/linux/drivers/media/common/tuners/tda18271-fe.c Sun Sep 27
> 12:21:37 2009 -0400
> @@ -1001,12 +1001,12 @@
> struct tda18271_std_map_item *map;
> char *mode;
> int ret;
> - u32 freq = params->frequency * 62500;
> + u32 freq = params->frequency *
> + ((params->mode == V4L2_TUNER_RADIO) ? 125 / 2 : 62500);
>
> priv->mode = TDA18271_ANALOG;
>
> if (params->mode == V4L2_TUNER_RADIO) {
> - freq = freq / 1000;
> map = &std_map->fm_radio;
> mode = "fm";
> } else if (params->std & V4L2_STD_MN) {
>
>
> You still get the credit for spotting the problem & providing the
> original fix -- thanks again! I'm going to push this along with the
> others today.
On a second thought, I see that my above patch loses some precision
... this is even better:
diff -r f52640ced9e8 linux/drivers/media/common/tuners/tda18271-fe.c
--- a/linux/drivers/media/common/tuners/tda18271-fe.c Tue Sep 15
01:25:35 2009 -0400
+++ b/linux/drivers/media/common/tuners/tda18271-fe.c Sun Sep 27
12:33:20 2009 -0400
@@ -1001,12 +1001,12 @@
struct tda18271_std_map_item *map;
char *mode;
int ret;
- u32 freq = params->frequency * 62500;
+ u32 freq = params->frequency * 125 *
+ ((params->mode == V4L2_TUNER_RADIO) ? 1 : 1000) / 2;
priv->mode = TDA18271_ANALOG;
if (params->mode == V4L2_TUNER_RADIO) {
- freq = freq / 1000;
map = &std_map->fm_radio;
mode = "fm";
} else if (params->std & V4L2_STD_MN) {
Cheers,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] tda18271_set_analog_params major bugfix
On Thu, Sep 24, 2009 at 5:42 PM, wrote:
> On Thu, Sep 24, 2009 at 02:46:06PM -0400, Michael Krufky wrote:
>> On Tue, Sep 22, 2009 at 5:05 PM, wrote:
>> >
>> > Multiplication by 62500 causes an overflow in the 32 bits "freq" register
>> > when
>> > using radio. FM radio reception on a Zolid Hybrid PCI is now working. Other
>> > tda18271 configurations may also benefit from this change ;)
>> >
>> > Signed-off-by: henk.vergo...@gmail.com
>> >
>> > diff -r 29e4ba1a09bc linux/drivers/media/common/tuners/tda18271-fe.c
> ...
>> > - freq = freq / 1000;
>> > + freq = params->frequency * 625;
>> > + freq = freq / 10;
>
> Hmm now that I review my own patch:
>
> - freq = freq / 1000;
> + freq = params->frequency * 125;
> + freq = freq / 2;
>
> might even be better...
Henk,
That certainly is better, but I am going to go with an even simpler &
cleaner approach:
diff -r f52640ced9e8 linux/drivers/media/common/tuners/tda18271-fe.c
--- a/linux/drivers/media/common/tuners/tda18271-fe.c Tue Sep 15
01:25:35 2009 -0400
+++ b/linux/drivers/media/common/tuners/tda18271-fe.c Sun Sep 27
12:21:37 2009 -0400
@@ -1001,12 +1001,12 @@
struct tda18271_std_map_item *map;
char *mode;
int ret;
- u32 freq = params->frequency * 62500;
+ u32 freq = params->frequency *
+ ((params->mode == V4L2_TUNER_RADIO) ? 125 / 2 : 62500);
priv->mode = TDA18271_ANALOG;
if (params->mode == V4L2_TUNER_RADIO) {
- freq = freq / 1000;
map = &std_map->fm_radio;
mode = "fm";
} else if (params->std & V4L2_STD_MN) {
You still get the credit for spotting the problem & providing the
original fix -- thanks again! I'm going to push this along with the
others today.
Cheers,
Mike
--
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
HVR1800 ATSC regression - Fails to attach DVB
I'm seeing a regression in tip. A Hauppauge HVR1800 model 78521 fails to have its demod for DTV attached correctly, resulting in a total loss of ATSC/QAM support. I'm looking into this. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx25840 6.5MHz carrier detection fixes
On Sat, 2009-09-26 at 00:16 +0300, Aleksandr V. Piskunov wrote:
> cx25840:
> Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
> Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
> system DK and L.
>
> Signed-off-by: Aleksandr V. Piskunov
Aleksandr,
Looks good for CX2584[0123] chips.
It is not right for CX2388[578] or CX2310[12] chips, but the original
code doesn't do the right thing anyway for those chips, AFAICT. In
those chips auto-detection of DK vs. L for 6.5 MHz sound carriers
doesn't appear to exist, and hence the bit positions and meanings have
changed slightly. Your fix get us closer to doing the right thing for
those devices. The rest of the fix for those devices is for another
day...
Reviewed-by: Andy Walls
> diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c
> b/linux/drivers/media/video/cx25840/cx25840-core.c
> --- a/linux/drivers/media/video/cx25840/cx25840-core.c
> +++ b/linux/drivers/media/video/cx25840/cx25840-core.c
> @@ -647,13 +647,30 @@
> }
> cx25840_write(client, 0x80b, 0x00);
> } else if (std & V4L2_STD_PAL) {
> - /* Follow tuner change procedure for PAL */
> + /* Autodetect audio standard and audio system */
> cx25840_write(client, 0x808, 0xff);
> - cx25840_write(client, 0x80b, 0x10);
> + /* Since system PAL-L is pretty much non-existant and
> + not used by any public broadcast network, force
> + 6.5 MHz carrier to be interpreted as System DK,
> + this avoids DK audio detection instability */
> + cx25840_write(client, 0x80b, 0x00);
> } else if (std & V4L2_STD_SECAM) {
> - /* Select autodetect for SECAM */
> + /* Autodetect audio standard and audio system */
> cx25840_write(client, 0x808, 0xff);
> - cx25840_write(client, 0x80b, 0x10);
> + /* If only one of SECAM-DK / SECAM-L is required, then force
> + 6.5MHz carrier, else autodetect it */
> + if ((std & V4L2_STD_SECAM_DK) &&
> + !(std & (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
> + /* 6.5 MHz carrier to be interpreted as System DK */
> + cx25840_write(client, 0x80b, 0x00);
> + } else if (!(std & V4L2_STD_SECAM_DK) &&
> + (std & (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
> + /* 6.5 MHz carrier to be interpreted as System L */
> + cx25840_write(client, 0x80b, 0x08);
> + } else {
> + /* 6.5 MHz carrier to be autodetected */
> + cx25840_write(client, 0x80b, 0x10);
> + }
> }
>
> cx25840_and_or(client, 0x810, ~0x01, 0);
>
> --
> 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: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
On 9/27/09 10:10 AM, Andy Walls wrote: On Sun, 2009-09-27 at 21:42 +0800, David T. L. Wong wrote: Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 for the following 8 changesets: 01/08: v4l2-chip-ident: Add ID's needed for the cx23885 and cx25840 modules http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5b2b33f2e3d7 02/08: cx23885: Fix support for v4l2-dbg access to CX2388[578] and CX23417 regs http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f652c361b61d 03/08: cx23885: Add skeleton v4l2_subdev for the CX23888 integrated IR controller http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f153c30da5c5 04/08: cx25840: Improve detection of CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=0efbeb807ff0 05/08: cx25840: Convert chip/core family checks to static inline functions http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=80d278a74d8a 06/08: cx25840: Separate set_audclk_freq functionality for the different chips http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5f58b345e32e 07/08: cx25840: Init PLLs properly for CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=b1ebfabe9c60 08/08: cx23885: Enable HVR-1850 CX23888 A/V core to get VID_CLK running for IR http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=7d99cae94fe5 I am submitting this CX23888 IR work in two parts, instead of one complete set, for two reasons: 1. Steve is waiting on these particular cx25840 module changes to move forward on work for analog video for some cards supported by the cx23885 driver. I don't want to hold up that work. Thank you. Thanks, Andy Andy and the List, I just tested your tree for the cx23885 card MagicPro ProHDTV Extreme 2. I can get it works for Composite PAL. Thanks Andy. Without your patch, PLL doesn't lock well, video not sync. David, Although fixing analog video wasn't my objective, it is good to hear that things have improved. I needed the VID PLL working properly because the IR controller in the CX2388[58] chips use it as a reference clock. Because of that, analog video got a minor fix up as a side effect. Yes, one of the nice side benefits is the video fixups, much appreciated. I'm going to regression test the HVR1800 (cx23887) now. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging
Hi, Mauro
Thank you for your suggestion on this.
Now I have another problem. The ISP needs the following parameters of the
sensor to set the acquisition interface, but I can not find a suitable subdev
ioctls to get them from sensor driver.
bus_width; width of the buss connecting sensor and ISP.
field_sel; field selection, even or odd.
ycseq; YCbCr sequence, YCbCr or YCrCb or CbYCrY or CrYCbY
conv422; subsampling type, co-sited 4:4:4 or non-cosited 4:4:4 or color
interpolation
bpat; bayer sampling sequence, RGRG GBGB or GRGR BGBG or ...
hpol; horizontal sync polarity
vpol; vertical sync polarity
edge; sampling edge
Best Regards
Jinlu Yu
UMG UPSG PRC
INET: 8758 1603
TEL: 86 10 8217 1603
FAX: 86 10 8286 1400
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: 2009年9月24日 19:45
To: Yu, Jinlu
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging
Em Thu, 24 Sep 2009 19:21:40 +0800
"Yu, Jinlu" escreveu:
> Hi, Hans/Guennadi
>
> I am modifying these drivers to comply with v4l2 framework. I have finished
> replacing our buffer managing code with utility function from videobuf-core.c
> and videobuf-dma-contig.c. Now I am working on the subdev. One thing I am
> sure is that each sensor should be registered as a v4l2_subdev and ISP (Image
> Signal Processor) is registered as a v4l2_device acting as the bridge device.
>
> But we have two ways to deal with the relationship of sensor and ISP, and we
> don't know which one is better. Could you help me on this?
>
> No.1. Register the ISP as a video_device (/dev/video0) and treat each of the
> sensor (SOC and RAW) as an input of the ISP. If I want to change the sensor,
> use the VIDIOC_S_INPUT to change input from sensor A to sensor B. But I have
> a concern about this ioctl. Since I didn't find any code related HW pipeline
> status checking and HW register setting in the implement of this ioctl (e.g.
> vino_s_input in /drivers/media/video/vino.c). So don't I have to stream-off
> the HW pipeline and change the HW register setting for the new input? Or is
> it application's responsibility to stream-off the pipeline and renegotiate
> the parameters for the new input?
>
> No.2. Combine the SOC sensor together with the ISP as Channel One and
> register it as /dev/video0, and combine the RAW sensor together with the ISP
> as Channel Two and register it as /dev/video1. Surely, only one channel works
> at a certain time due to HW restriction. When I want to change the sensor
> (e.g. from SOC sensor to RAW sensor), just close /dev/video0 and open
> /dev/video1.
The better seems to be No. 1. As you need to re-negotiate parameters for
switching from one sensor to another, if some app tries to change from one
input to another while streaming, you should just return -EBUSY, if it is not
possible to switch (for example, if the selected format/resolution/frame rate
is incompatible).
Cheers,
Mauro
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w* jg�报 �茛j/�赇z罐���2���ㄨ��&�)摺�a囤�� �G���h��j:+v���w��佶
Re: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
On Sun, 2009-09-27 at 21:42 +0800, David T. L. Wong wrote: > Andy Walls wrote: > > Mauro, > > > > Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 > > > > for the following 8 changesets: > > > > 01/08: v4l2-chip-ident: Add ID's needed for the cx23885 and cx25840 modules > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5b2b33f2e3d7 > > > > 02/08: cx23885: Fix support for v4l2-dbg access to CX2388[578] and CX23417 > > regs > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f652c361b61d > > > > 03/08: cx23885: Add skeleton v4l2_subdev for the CX23888 integrated IR > > controller > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f153c30da5c5 > > > > 04/08: cx25840: Improve detection of CX2388[578] A/V cores > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=0efbeb807ff0 > > > > 05/08: cx25840: Convert chip/core family checks to static inline functions > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=80d278a74d8a > > > > 06/08: cx25840: Separate set_audclk_freq functionality for the different > > chips > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5f58b345e32e > > > > 07/08: cx25840: Init PLLs properly for CX2388[578] A/V cores > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=b1ebfabe9c60 > > > > 08/08: cx23885: Enable HVR-1850 CX23888 A/V core to get VID_CLK running for > > IR > > http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=7d99cae94fe5 > > > > > > I am submitting this CX23888 IR work in two parts, instead of one > > complete set, for two reasons: > > > > 1. Steve is waiting on these particular cx25840 module changes to move > > forward on work for analog video for some cards supported by the cx23885 > > driver. I don't want to hold up that work. > > Thanks, > > Andy > > > Andy and the List, > >I just tested your tree for the cx23885 card MagicPro ProHDTV Extreme > 2. I can get it works for Composite PAL. Thanks Andy. > >Without your patch, PLL doesn't lock well, video not sync. David, Although fixing analog video wasn't my objective, it is good to hear that things have improved. I needed the VID PLL working properly because the IR controller in the CX2388[58] chips use it as a reference clock. Because of that, analog video got a minor fix up as a side effect. I was actually worried I might break analog video for CX23885 cards that were working, as I only have a HVR-1850 (CX23888) with which to test. Thank you for the report. :) >For Composite NTSC, I don't know why VLC get a segmentation fault. > Xawtv incorrectly detect pixel format and size. Based on my shallow glance through the cx23885 driver, it does not surprise me that the cx23885 driver may need some fixes to get analog video working properly and reliably for various cards. In time I suspect it will get done. Regards, Andy > David T.L. Wong -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 for the following 8 changesets: 01/08: v4l2-chip-ident: Add ID's needed for the cx23885 and cx25840 modules http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5b2b33f2e3d7 02/08: cx23885: Fix support for v4l2-dbg access to CX2388[578] and CX23417 regs http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f652c361b61d 03/08: cx23885: Add skeleton v4l2_subdev for the CX23888 integrated IR controller http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f153c30da5c5 04/08: cx25840: Improve detection of CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=0efbeb807ff0 05/08: cx25840: Convert chip/core family checks to static inline functions http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=80d278a74d8a 06/08: cx25840: Separate set_audclk_freq functionality for the different chips http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5f58b345e32e 07/08: cx25840: Init PLLs properly for CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=b1ebfabe9c60 08/08: cx23885: Enable HVR-1850 CX23888 A/V core to get VID_CLK running for IR http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=7d99cae94fe5 b/linux/drivers/media/video/cx23885/cx23885-ioctl.c | 197 b/linux/drivers/media/video/cx23885/cx23885-ioctl.h | 39 + b/linux/drivers/media/video/cx23885/cx23888-ir.c | 233 + b/linux/drivers/media/video/cx23885/cx23888-ir.h | 28 + linux/drivers/media/video/cx23885/Makefile |3 linux/drivers/media/video/cx23885/cx23885-417.c | 10 linux/drivers/media/video/cx23885/cx23885-cards.c| 12 linux/drivers/media/video/cx23885/cx23885-core.c | 20 linux/drivers/media/video/cx23885/cx23885-ioctl.c| 11 linux/drivers/media/video/cx23885/cx23885-video.c| 34 - linux/drivers/media/video/cx23885/cx23885.h | 12 linux/drivers/media/video/cx25840/cx25840-audio.c| 461 ++- linux/drivers/media/video/cx25840/cx25840-core.c | 258 +++--- linux/drivers/media/video/cx25840/cx25840-core.h | 22 linux/drivers/media/video/cx25840/cx25840-firmware.c | 10 linux/include/media/v4l2-chip-ident.h| 16 16 files changed, 1140 insertions(+), 226 deletions(-) These changes are the first part in a set of changes that get IR receive working for the HVR-1850 with the Hauppaugue grey RC-5 remote, and starts laying the foundation for using the integrated IR controller in CX2388[57], CX2310[012], CX2584[0123], and CX23418 chips. I have 25 other small changes to consolidate and clean up, that I will submit as a follow up pull request later that get IR working for the HVR-1850. I am submitting this CX23888 IR work in two parts, instead of one complete set, for two reasons: 1. Steve is waiting on these particular cx25840 module changes to move forward on work for analog video for some cards supported by the cx23885 driver. I don't want to hold up that work. 2. the second half of this set will include my v4l2_subdev_ir_ops definition, which has the potential for discussion or rework (I hope not though). Since this first half of the changes don't depend on that being finalized, I wanted to get these 1366 changes moving forward, before too many unrelated changes happen to the cx25840 and cx23885 modules. Thanks, 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 Andy and the List, I just tested your tree for the cx23885 card MagicPro ProHDTV Extreme 2. I can get it works for Composite PAL. Thanks Andy. Without your patch, PLL doesn't lock well, video not sync. For Composite NTSC, I don't know why VLC get a segmentation fault. Xawtv incorrectly detect pixel format and size. David T.L. Wong -- 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: HVR-2200 Australia DVB-T
Hi Steven, I have just found the official Australian broadcast data (acma.gov.au). I did find something interesting. In all cases except for channel TEN, the analog channel and digital channel are located on adjacent channels. Channel TEN has a huge channel separation. I have confirmed that the channel center frequencies in my channels.conf file are correct. Are we looking at a 7Mhz vs 8Mhz channel separation issue? aF On 15/09/2009, at 11:34 PM, Steven Toth wrote: WIN TV Canberra: 76750 :INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4 :FEC_3_4 :QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE: 33:36:1 r...@kaylee:~/.tzap# tzap "WIN TV Canberra" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/root/.tzap/channels.conf' tuning to 76750 Hz video pid 0x0021, audio pid 0x0024 status 00 | signal a9a9 | snr 002e | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | Any help would be appreciated. Sounds like a tuning issue. Either the Antenna is bad or the channels.conf doesn't represent the actual center frequency or the channel or the tuner / demod code is buggy. Other people are having success with DVB-T HVR2200 so it's either a bug that gets exposed by your environment or something else. mkrufky has some tuner improvements pending for merge which are not in the saa7164 tree yet, you might want to hold for a few days for these. The other thing to double check is that the freqs in your channels conf do actually represent the center of the DVB-T channel. I suspect they do, but double check for good measure using the official Australian DVB-T antenna docs. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L-DVB Summit Day 3
Hi Hans, On Sat, Sep 26, 2009 at 3:22 PM, Hans Verkuil wrote: > Hi all, > > Well, that was another very successful day here in Portland. > > I started off presenting the work we did in the past year and our plans for > the next year during the BoF this morning. It was quite a big crowd and the > talk was well received. > > The presentation is available from my website: > > http://www.xs4all.nl/~hverkuil/lpc/bof.odp > > The nice thing was that this presentation was hot off the press as it > presented all the things we discussed in the two preceding days of the summit. > > Two additional presentations from Samsung regarding their SoCs and their > implementation of a memory pool-like API are also available from my website: > > http://www.xs4all.nl/~hverkuil/lpc/Samsung_SoCs.ppt > http://www.xs4all.nl/~hverkuil/lpc/Unified_media_buffers.pdf > > Unfortunately I couldn't attend the presentation from Hans de Goede and > Brandon Philips, so I can't comment on that. It would be great if someone can > post a report of that presentation (and links to the presentation itself, if > possible). > > During the afternoon we worked on assigning people to the various tasks that > need to be done. > > I made the following list: > > - We created a new mc mailinglist: linux...@googlegroups.com > > This is a temporary mailinglist where we can post and review patches during > prototyping of the mc API. We don't want to flood the linux-media list with > those patches since that is already quite high-volume. > > The mailinglist should be active, although I couldn't find it yet from > www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did > something wrong. > > - implement sensor v4l2_subdev support (Laurent). We are still missing some > v4l2_subdev sensor ops for setting up the bus config and data format. Laurent > will look into implementing those. An RFC for the bus config already exists > and will function as the basis of this. > > - when done, remove the v4l2-int-device API (Nokia, target 2.6.33). It's > important to finally remove this non-standard API. When we can setup sensors > properly using subdevs, then Nokia can convert the final two users of this API > to v4l2_subdev. > > - subdev migration omap3: > - ISP (Laurent) > - video decoder (Vaibhav) > - display (Vaibhav) > > These are the initial test implementations for the media controller: > converting the various parts of the omap3 driver to subdevs and see how these > can be controller via the mc. > > - subdev migration Moorestown (Intel): > - sensors > - LED driver > - video decoder/encoder > - more... > > Intel will do something similar for their Moorestown platform. > > - Samsung: investigate V4L2 API and mc concept. > > Samsung needs to investigate the V4L2 API and the mc proposal first before > they can commit to anything. > BTW I just forgot to ask Marek and Tomasz to ask you guys at mini-summit about can the HDMI device fit into the v4l2 framework. Because as far as my investigation, I found HDMI interface driver from Intel not in the v4l2 drivers but in gpu drivers and totally doesn't seem to be a v4l2 one at all. As you already know, the new arm based SoC from Samsung has HDMI interface and I'm very curious about which approach is better one between v4l2 approach and framebuffer approach. Because that HDMI interface has a mixer feature just like an overlay feature in framebuffer devices. It will be nice if someone points me the right way :) According to your mail, I suppose that this conference was a magnificent and important turning point for v4l2. I wished I could attend the conference but trillions of works were stuck in my queue :'( Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
On 26.09.09 21:33, Devin Heitmueller wrote:
> On Sat, Sep 26, 2009 at 8:23 PM, Uros Vampl wrote:
> > On 26.09.09 16:59, Devin Heitmueller wrote:
> >> On Fri, Sep 25, 2009 at 6:10 PM, Uros Vampl
> >> wrote:
> >> > Alright, success!!!
> >> >
> >> > Since it seems everything for this tuner is set up the same as for the
> >> > Hauppauge WinTV HVR 900, I figured let's set things up *exactly* the
> >> > same. So, like it's there for the Hauppauge, I added .mts_firmware = 1
> >> > to the definition of the hybrid XS em2882. And well, working TV audio!!
> >> >
> >> >
> >> > dmesg output this time:
> >> >
> >> > xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id
> >> > .
> >> > MTS (4), id 00ff:
> >> > xc2028 4-0061: Loading firmware for type=MTS (4), id 00010007.
> >> >
> >> >
> >> > So now with the attached patch, everything (analog, digital, remote)
> >> > works!
> >> >
> >> > Regards,
> >> > Uroš
> >> >
> >>
> >> Hello Uros,
> >>
> >> Please test out the following tree, which has all the relevant fixes
> >> (enabling dvb, your audio fix, proper gpio setting, etc).
> >>
> >> http://kernellabs.com/hg/~dheitmueller/misc-fixes2/
> >>
> >> If you have any trouble, please let me know. Otherwise I would like
> >> to issue a PULL request for this tree.
> >
> >
> > Hi,
> >
> > Your tree does not work, no audio. I quickly found the problem though:
> > gpio is set to default_analog, but it needs to be set to
> > hauppauge_wintv_hvr_900_analog. So I guess treating the EM2880 and
> > EM2882 as the same will not work, because they require different gpio
> > settings.
> >
> > Regards,
> > Uroš
>
> Hmm.. Interesting. That does make me wonder whether the GPIOs are
> setup for audio properly on the em2880 version of the profile, or
> whether the user in question just never tested it. I'll have to go
> back and check the USB trace.
>
> Nonetheless, I'll just check in your version of the patch, and scrap
> my version entirely for now. Could you please add your SOB to the
> patch?
>
> Thanks,
>
> Devin
Ok, here we go...
Make analog audio, dvb and the remote work on a Terratec Cinergy Hybrid
XS (em2882).
Signed-off-by: Uroš Vampl
diff -r 29e4ba1a09bc linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Sep 19 09:45:22
2009 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Sep 26 00:06:37
2009 +0200
@@ -1441,11 +1441,12 @@
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
+ .mts_firmware = 1,
.decoder = EM28XX_TVP5150,
-#if 0 /* FIXME: add an entry at em28xx-dvb */
.has_dvb = 1,
.dvb_gpio = hauppauge_wintv_hvr_900_digital,
-#endif
+ .ir_codes = &ir_codes_terratec_cinergy_xs_table,
+ .xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
@@ -2119,6 +2120,7 @@
switch (dev->model) {
case EM2880_BOARD_EMPIRE_DUAL_TV:
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
+ case EM2882_BOARD_TERRATEC_HYBRID_XS:
ctl->demod = XC3028_FE_ZARLINK456;
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
diff -r 29e4ba1a09bc linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Sat Sep 19 09:45:22
2009 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Sat Sep 26 00:06:37
2009 +0200
@@ -494,6 +494,7 @@
}
break;
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
+ case EM2882_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_EMPIRE_DUAL_TV:
dvb->frontend = dvb_attach(zl10353_attach,
&em28xx_zl10353_xc3028_no_i2c_gate,
--
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
