Re: saa7134 and üPD61151 MPEG2 coder
Hi
Some fixes
> On Tuesday 09 February 2010 06:41:50 Dmitri Belimov wrote:
> > Hi Hans
> >
> > This is my last state for review.
> > After small time I'll finish process of initialize the encoder.
> > Configure some register, upload two firmware for video and for
> > audio. Configure the frontends.
> >
> > I have the questions.
> > For configuring audio frontend need know samplerate of audio.
> > saa7134 can only 32kHz
> > saa7131/3/5 on I2S 32кГц from SIF source and 32/44.1/48 from
> > external i.e. RCA stereo audio input.
> >
> > Hardcode 32kHz or need a function for determine mode of audio??
>
> See struct v4l2_subdev_audio_ops: it has a s_clock_freq op for
> precisely that purpose. The saa7134 should call that whenever it sets
> a new samplerate.
This op is not used in saa7134 sources. Now hardcoded 32kHz.
> >
> > Other question. For configure VideoFrontend need know 50 or 60Hz
> > Now I use videomode from h structure. I think more correct detect it
> > on saa7134.
>
> Whether it is 50 or 60 Hz depends on the video standard that you
> receive via the s_std core op. Just implement that and when you get a
> new standard you can use something like this: is_60hz = (std &
> V4L2_STD_525_60) ? 1 : 0;
I do it, if(std & V4L2_STD_625_50) then
This data is not real information about input signal. It's what we set from
end-user programm.
But OK, I used it.
> Some more review comments:
>
> linux/drivers/media/video/saa7134/saa7134.h:
>
> @@ -355,6 +377,10 @@
> unsigned char empress_addr;
> unsigned char rds_addr;
>
> + /* SPI info */
> + struct saa7134_software_spi spi;
> + struct spi_board_info spi_conf;
>
> Make this a struct spi_board_info *. This struct is too large: it is
> only used in one board but all elements of the board array will
> suddenly get this whole struct increasing the memory footprint
> substantially. In this case you can just make it a pointer, that will
> work just as well.
Yes. I don't know what is more good. Now all config data in saa7134-cards
description.
In your case need move spi_board_info to SPI part of code. We will mix code and
data.
For add new cards and devices need edit some files for add configs.
May be it's good in my case.
> +
> unsigned inttda9887_conf;
> unsigned inttuner_config;
>
> linux/drivers/media/video/v4l2-common.c, in v4l2_spi_subdev_init():
>
> + /* initialize name */
> + snprintf(sd->name, sizeof(sd->name), "%s",
> + spi->dev.driver->name);
>
> Use strlcpy here.
Done
> saa7134-spi.c:
>
>
> static inline u32 getmiso(struct spi_device *dev)
> {
> struct saa7134_spi_gpio *sb = to_sb(dev);
> unsigned long status;
>
> status = saa7134_get_gpio(sb->controller_data);
> if ( status & (1 << sb->controller_data->spi.miso))
> return 1;
> else
> return 0;
> }
>
> Simplify to:
>
> static inline u32 getmiso(struct spi_device *dev)
> {
> struct saa7134_spi_gpio *sb = to_sb(dev);
> u32 status;
>
> status = saa7134_get_gpio(sb->controller_data);
> return !!(status & (1 << sb->controller_data->spi.miso));
> }
Thank you.
> Also note that saa7134_get_gpio should return an u32 since unsigned
> long is 64 bits when compiled on a 64-bit kernel, which is probably
> not what you want.
Done
> saa7134_spi_unregister can be a void function as the result code is
> always 0.
Done
> There seems to be some old stuff in upd61151.h. Please remove what is
> not needed.
Done
> In upd61151.c I highly recommend that all functions will use struct
> v4l2_subdev *sd as argument. Only at the lowest level should you go
> from sd to spi. Among others this allows you to use the standard
> v4l2_info/dbg etc. logging functions.
Done
> Don't use RESULT_SUCCESS. Just return 0.
Done
> Remove upd61151_init. The init op is rarely needed and should in
> general not be used.
Done
> Remove those emacs editor comments at the end of the files. That's
> bad practice.
Done
With my best regards, Dmitry.
diff -r b6b82258cf5e linux/drivers/media/video/saa7134/Makefile
--- a/linux/drivers/media/video/saa7134/Makefile Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/saa7134/Makefile Tue Feb 16 10:23:52 2010 +0900
@@ -1,9 +1,9 @@
saa7134-objs := saa7134-cards.o saa7134-core.o saa7134-i2c.o \
saa7134-ts.o saa7134-tvaudio.o saa7134-vbi.o\
- saa7134-video.o saa7134-input.o
+ saa7134-video.o saa7134-input.o saa7134-spi.o
-obj-$(CONFIG_VIDEO_SAA7134) += saa6752hs.o saa7134.o saa7134-empress.o
+obj-$(CONFIG_VIDEO_SAA7134) += saa6752hs.o saa7134.o saa7134-empress.o upd61151.o
obj-$(CONFIG_VIDEO_SAA7134_ALSA) += saa7134-alsa.o
diff -r b6b82258cf5e linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/sa
Compro U80
The Realtek driver (a windows-like driver I got from the manufacturer) only supported the mt2060 and mx5005. I have heard of U80 working. Please give the new driver (alas with no IR remote support) from anttip/rtl2831u If there is a different tuner, that driver is set up so that you can incorporate other tuners easily. James Troup wrote: Hi Jan, someone in the chat channel has told me that the driver does not support the qt1010 tuner that I have. Is this correct? > I am using the hg clone on your driver rtl2831-r2 James > Hi Jan, > > I bought the Compro U80, compiled the driver, > but I don't seem to be able to tune. "tuning failed" > > :~$ scan /usr/share/dvb/dvb-t/au-Adelaide ~/Desktop/channels.conf > scanning /usr/share/dvb/dvb-t/au-Adelaide > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 22650 1 3 9 3 1 1 0 > initial transponder 17750 1 3 9 3 1 1 0 > initial transponder 191625000 1 3 9 3 1 1 0 > initial transponder 21950 1 3 9 3 1 1 0 > initial transponder 56450 1 2 9 3 1 2 0 > >>> tune to: > 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE > WARNING: >>> tuning failed!!! > > Where is the best place to ask questions for this? > -- 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: cx23885
On Mon, 2010-02-15 at 18:22 -0500, Ralph Siemsen wrote: > On Mon, Feb 15, 2010 at 11:56:52PM +0100, Michael wrote: > > > > If anybody can give me a hint, what to include in a patch and what was old > > stuff that has jsut changed in 2.6.31, I'd be grateful. > > Their source tree contains a .hg_archival.txt file which looks like > it can be used to identify the original v4l-dvb tree they used. > > Attached is a diff from that v4l version to the MPX-885 tree. > cx23885/cx23885-cards.c| 90 > cx23885/cx23885-dvb.c | 30 + > cx23885/cx23885-video.c|2 > cx23885/cx23885.h |1 > cx25840/cx25840-core.c | 248 > +++-- > cx25840/cx25840-firmware.c |4 > 6 files changed, 338 insertions(+), 37 deletions(-) > > Hope it helps... > -R That is very helpful. However, changes to the CX25840 module, since their MPX885 changes were developed, are extenesive when it comes to initialization of the CX23885/7/8 A/V decoder. Their changes will be difficult to port. I also see changes which will at least break existing drivers and apps. For example, this one will violate a key assumption made by the ivtv driver: - state->vid_input = CX25840_COMPOSITE7; + state->vid_input = CX25840_COMPOSITE1; This sort of thing is typical of many vendor driver developments: get it working for this part as fast as possible so the product can ship - don't worry about anything else. It is still decent of them to provide a linux driver and the source changes without a hassle. RAR format is inconvenient on linux though. 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: cx23885
On Mon, Feb 15, 2010 at 11:56:52PM +0100, Michael wrote:
>
> If anybody can give me a hint, what to include in a patch and what was old
> stuff that has jsut changed in 2.6.31, I'd be grateful.
Their source tree contains a .hg_archival.txt file which looks like
it can be used to identify the original v4l-dvb tree they used.
Attached is a diff from that v4l version to the MPX-885 tree.
cx23885/cx23885-cards.c| 90
cx23885/cx23885-dvb.c | 30 +
cx23885/cx23885-video.c|2
cx23885/cx23885.h |1
cx25840/cx25840-core.c | 248 +++--
cx25840/cx25840-firmware.c |4
6 files changed, 338 insertions(+), 37 deletions(-)
Hope it helps...
-R
diff -uNr v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c
MPX-885/linux/v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c
--- v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c 2010-02-15
18:19:26.0 -0500
+++ MPX-885/linux/v4l-dvb/linux/drivers/media/video/cx23885/cx23885-cards.c
2009-11-11 09:36:16.0 -0500
@@ -216,6 +216,29 @@
.name = "Compro VideoMate E800",
.portc = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_MPX885] = {
+ .name = "MPX-885",
+.porta = CX23885_ANALOG_VIDEO,
+.portb = CX23885_MPEG_ENCODER,
+.portc = CX23885_MPEG_DVB,
+.input = {{
+.type = CX23885_VMUX_COMPOSITE1,
+.vmux = CX25840_VIN1_CH1,
+.gpio0 = 0,
+}, {
+.type = CX23885_VMUX_COMPOSITE2,
+.vmux = CX25840_VIN2_CH1,
+.gpio0 = 0,
+}, {
+.type = CX23885_VMUX_COMPOSITE3,
+.vmux = CX25840_VIN3_CH1,
+.gpio0 = 0,
+}, {
+.type = CX23885_VMUX_COMPOSITE4,
+.vmux = CX25840_VIN4_CH1,
+.gpio0 = 0,
+} },
+},
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -351,7 +374,11 @@
.subvendor = 0x1858,
.subdevice = 0xe800,
.card = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
- },
+ }, {
+ .subvendor = 0x0,
+.subdevice = 0x0,
+.card = CX23885_BOARD_MPX885,
+},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -798,6 +825,37 @@
/* CX24228 GPIO */
/* Connected to IF / Mux */
break;
+case CX23885_BOARD_MPX885:
+ /* GPIO-0 656_CLK */
+ /* GPIO-1 656_D0 */
+ /* GPIO-2 8295A Reset */
+ /* GPIO-3-10 cx23417 data0-7 */
+ /* GPIO-11-14 cx23417 addr0-3 */
+ /* GPIO-15-18 cx23417 READY, CS, RD, WR */
+ /* GPIO-19 IR_RX */
+
+ /* CX23417 GPIO's */
+ /* EIO15 Zilog Reset */
+ /* EIO14 S5H1409/CX24227 Reset */
+ mc417_gpio_enable(dev, GPIO_15 | GPIO_14, 1);
+
+ /* Put the demod into reset and protect the eeprom */
+ mc417_gpio_clear(dev, GPIO_15 | GPIO_14);
+ mdelay(100);
+
+ /* Bring the demod and blaster out of reset */
+ mc417_gpio_set(dev, GPIO_15 | GPIO_14);
+ mdelay(100);
+
+ /* Force the TDA8295A into reset and back */
+ cx23885_gpio_enable(dev, GPIO_2, 1);
+ cx23885_gpio_set(dev, GPIO_2);
+ mdelay(20);
+ cx23885_gpio_clear(dev, GPIO_2);
+ mdelay(20);
+ cx23885_gpio_set(dev, GPIO_2);
+ mdelay(20);
+ break;
}
}
@@ -827,6 +885,8 @@
case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP:
request_module("ir-kbd-i2c");
break;
+case CX23885_BOARD_MPX885:
+break;
}
return ret;
@@ -887,6 +947,10 @@
if (dev->i2c_bus[0].i2c_rc == 0)
hauppauge_eeprom(dev, eeprom+0xc0);
break;
+case CX23885_BOARD_MPX885:
+ if (dev->i2c_bus[0].i2c_rc == 0)
+ hauppauge_eeprom(dev, eeprom+0xc0);
+break;
}
switch (dev->board) {
@@ -938,6 +1002,22 @@
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+case CX23885_BOARD_MPX885:
+ /* Defaults for VID B - Analog encoder */
+ /* DREQ_POL, SMODE, PUNC_CLK, MCLK_POL Serial bus + punc clk */
+ ts1->gen_ctrl_val= 0x10e;
+ ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+
+ /* APB_TSVALERR_POL (active low)*/
+ ts1->vld_misc_val= 0x
Re: cx23885
On 2/15/10 5:56 PM, Michael wrote: Well, this did not work. The cx23885 driver was not included in kernel 2.6.21, so no diff. The diff of the 2.6.21 cx25840 is twice as big as the 2.6.31 diff. :-( If anybody can give me a hint, what to include in a patch and what was old stuff that has jsut changed in 2.6.31, I'd be grateful. Attached is the diff of cx23885, the commell version against kernel 2.6.31.4. I'm downloading kernel 2.6.21 now and make a diff with these drivers. Start by patching the current cx23885 driver with all of the switch statements related to the new board CX23885_BOARD_MPX885. -cards.c -core.c etc. I already see some issues in their MPX885 additions, driving wrong gpios and assuming the encoder is attached - but it's a good start. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
And here the cx25840 diff, again commell versus 2.6.31.4.
P.S.: I will order a card now. Otherwise I can't test any patches...
diff -u cx25840/cx25840-audio.c cx25840-commell/cx25840-audio.c
--- cx25840/cx25840-audio.c 2010-02-15 23:23:01.0 +0100
+++ cx25840-commell/cx25840-audio.c 2009-11-11 09:36:38.0 +0100
@@ -20,90 +20,141 @@
#include
#include
#include
+#include "compat.h"
#include "cx25840-core.h"
-static int set_audclk_freq(struct i2c_client *client, u32 freq)
+/*
+ * Note: The PLL and SRC parameters are based on a reference frequency that
+ * would ideally be:
+ *
+ * NTSC Color subcarrier freq * 8 = 4.5 MHz/286 * 455/2 * 8 = 28.63636363... MHz
+ *
+ * However, it's not the exact reference frequency that matters, only that the
+ * firmware and modules that comprise the driver for a particular board all
+ * use the same value (close to the ideal value).
+ *
+ * Comments below will note which reference frequency is assumed for various
+ * parameters. They will usually be one of
+ *
+ * ref_freq = 28.636360 MHz
+ * or
+ * ref_freq = 28.636363 MHz
+ */
+
+static int cx25840_set_audclk_freq(struct i2c_client *client, u32 freq)
{
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
- if (freq != 32000 && freq != 44100 && freq != 48000)
- return -EINVAL;
-
- /* common for all inputs and rates */
- /* SA_MCLK_SEL=1, SA_MCLK_DIV=0x10 */
- if (!state->is_cx23885 && !state->is_cx231xx)
- cx25840_write(client, 0x127, 0x50);
-
if (state->aud_input != CX25840_AUDIO_SERIAL) {
switch (freq) {
case 32000:
- if (state->is_cx23885) {
-/* We don't have register values
- * so avoid destroying registers. */
-break;
- }
-
- if (!state->is_cx231xx) {
-/* VID_PLL and AUX_PLL */
-cx25840_write4(client, 0x108, 0x1006040f);
+ /*
+ * VID_PLL Integer = 0x0f, VID_PLL Post Divider = 0x04
+ * AUX_PLL Integer = 0x06, AUX PLL Post Divider = 0x10
+ */
+ cx25840_write4(client, 0x108, 0x1006040f);
+
+ /*
+ * VID_PLL Fraction (register 0x10c) = 0x2be2fe
+ * 28636360 * 0xf.15f17f0/4 = 108 MHz
+ * 432 MHz pre-postdivide
+ */
+
+ /*
+ * AUX_PLL Fraction = 0x1bb39ee
+ * 28636363 * 0x6.dd9cf70/0x10 = 32000 * 384
+ * 196.6 MHz pre-postdivide
+ * FIXME < 200 MHz is out of specified valid range
+ * FIXME 28636363 ref_freq doesn't match VID PLL ref
+ */
+ cx25840_write4(client, 0x110, 0x01bb39ee);
+
+ /*
+ * SA_MCLK_SEL = 1
+ * SA_MCLK_DIV = 0x10 = 384/384 * AUX_PLL post dvivider
+ */
+ cx25840_write(client, 0x127, 0x50);
-/* AUX_PLL_FRAC */
-cx25840_write4(client, 0x110, 0x01bb39ee);
- }
-
- if (state->is_cx25836)
+ if (is_cx2583x(state))
break;
- /* src3/4/6_ctl = 0x0801f77f */
+ /* src3/4/6_ctl */
+ /* 0x1.f77f = (4 * 28636360/8 * 2/455) / 32000 */
cx25840_write4(client, 0x900, 0x0801f77f);
cx25840_write4(client, 0x904, 0x0801f77f);
cx25840_write4(client, 0x90c, 0x0801f77f);
break;
case 44100:
- if (state->is_cx23885) {
-/* We don't have register values
- * so avoid destroying registers. */
-break;
- }
-
- if (!state->is_cx231xx) {
-/* VID_PLL and AUX_PLL */
-cx25840_write4(client, 0x108, 0x1009040f);
-
-/* AUX_PLL_FRAC */
-cx25840_write4(client, 0x110, 0x00ec6bd6);
- }
+ /*
+ * VID_PLL Integer = 0x0f, VID_PLL Post Divider = 0x04
+ * AUX_PLL Integer = 0x09, AUX PLL Post Divider = 0x10
+ */
+ cx25840_write4(client, 0x108, 0x1009040f);
+
+ /*
+ * VID_PLL Fraction (register 0x10c) = 0x2be2fe
+ * 28636360 * 0xf.15f17f0/4 = 108 MHz
+ * 432 MHz pre-postdivide
+ */
+
+ /*
+ * AUX_PLL Fraction = 0x0ec6bd6
+ * 28636363 * 0x9.7635eb0/0x10 = 44100 * 384
+ * 271 MHz pre-postdivide
+ * FIXME 28636363 ref_freq doesn't match VID PLL ref
+ */
+ cx25840_write4(client, 0x110, 0x00ec6bd6);
+
+ /*
+ * SA_MCLK_SEL = 1
+ * SA_MCLK_DIV = 0x10 = 384/384 * AUX_PLL post dvivider
+ */
+ cx25840_write(client, 0x127, 0x50);
- if (state->is_cx25836)
+ if (is_cx2583x(state))
break;
- /* src3/4/6_ctl = 0x08016d59 */
+ /* src3/4/6_ctl */
+ /* 0x1.6d59 = (4 * 28636360/8 * 2/455) / 44100 */
cx25840_write4(client, 0x900, 0x08016d59);
cx25840_write4(client, 0x904, 0x08016d59);
cx25840_write4(client, 0x90c, 0x08016d59);
break;
case 48000:
- if (state->is_cx23885) {
-/* We don't have register values
- * so avoid destroying registers. */
-break;
- }
-
- if (!state->is_cx231xx) {
-/* VID_PLL and AUX_PLL */
-cx25840_write4(client, 0x108, 0x100a040f);
-
-/* AUX_PLL_FRAC */
-cx25840_write4(client, 0x110, 0x0098d6e5);
- }
+ /*
+ * VID_PLL Integer = 0x0f, VID_PLL Post Divider = 0x04
+ * AUX_PLL Integer = 0x0a, AUX PLL Post Divider = 0x10
+ */
+ cx25840_write4(client, 0x108, 0x100a040f);
+
+ /*
+ * VID_PLL Fraction (register 0x10c) = 0x2be2fe
+ * 28636360 * 0xf.15f17f0/4 = 108 MHz
+ * 432 MHz pre-postdi
Re: ATI TV Wonder 650 PCI development
On Mon, Feb 15, 2010 at 5:43 PM, Samuel Cantrell wrote: > Perhaps we could contact Broadcom regarding the Theatre 312? > > Am I making too much of this? I do have a Pinnacle 800i which works > with Linux, I was just also wanting to get this card to work. Should I > just drop it? > Can't hurt to try, but I'm not sure how much luck you'll have. Alex > Thanks. > > Sam > > On Mon, Feb 15, 2010 at 2:37 PM, Alex Deucher wrote: >> On Mon, Feb 15, 2010 at 5:34 PM, Devin Heitmueller >> wrote: >>> On Mon, Feb 15, 2010 at 5:21 PM, Alex Deucher wrote: Who did you contact? gpudriverdevsupport AT amd DOT com is the devel address you probably want. I looked into documentation for the newer theatre chips when I started at AMD, but unfortunately, I'm not sure how much we can release since we sold most of our multimedia IP to Marvell last year. I'm not sure what the status of the theatre chips is now. Documentation for the older theatre and theatre 200 asics was released under NDA years ago which resulted in the theatre support in the opensource radeon Xorg driver and gatos projects. Now that we a proper KMS driver for radeon, someone could port the old userspace theatre code to the kernel for proper v4l support on AIW radeon cards. Alex >>> >>> For what it's worth, I actually did have a contact at the ATI/AMD >>> division that made the Theatre 312/314/316, and I was able to get >>> access to both the docs and reference driver sources under NDA. >>> However, the division in question was sold off to Broadcom, and I >>> couldn't get the rights needed to do a GPL driver nor to get >>> redistribution rights on the firmware. In fact, they couldn't even >>> told me who actually *held* the rights for the reference driver code. >>> >>> At that point, I decided that it just wasn't worth the effort for such >>> an obscure design. >> >> Ah right, I meant Broadcom, not Marvell. >> >> Alex >> > -- 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: cx23885
Well, this did not work. The cx23885 driver was not included in kernel
2.6.21, so no diff. The diff of the 2.6.21 cx25840 is twice as big as the
2.6.31 diff. :-(
If anybody can give me a hint, what to include in a patch and what was old
stuff that has jsut changed in 2.6.31, I'd be grateful.
Attached is the diff of cx23885, the commell version against kernel
2.6.31.4.
>
> I'm downloading kernel 2.6.21 now and make a diff with these drivers.
>
diff -u cx23885/cimax2.c cx23885-commell/cimax2.c
--- cx23885/cimax2.c 2010-02-15 23:22:38.0 +0100
+++ cx23885-commell/cimax2.c 2009-11-11 09:36:16.0 +0100
@@ -75,7 +75,6 @@
void *priv;
};
-struct mutex gpio_mutex;/* Two CiMax's uses same GPIO lines */
int netup_read_i2c(struct i2c_adapter *i2c_adap, u8 addr, u8 reg,
u8 *buf, int len)
@@ -183,10 +182,11 @@
if (ret != 0)
return ret;
- mutex_lock(&gpio_mutex);
+ mutex_lock(&dev->gpio_lock);
/* write addr */
cx_write(MC417_OEN, NETUP_EN_ALL);
+ msleep(2);
cx_write(MC417_RWD, NETUP_CTRL_OFF |
NETUP_ADLO | (0xff & addr));
cx_clear(MC417_RWD, NETUP_ADLO);
@@ -194,9 +194,10 @@
NETUP_ADHI | (0xff & (addr >> 8)));
cx_clear(MC417_RWD, NETUP_ADHI);
- if (read) /* data in */
+ if (read) { /* data in */
cx_write(MC417_OEN, NETUP_EN_ALL | NETUP_DATA);
- else /* data out */
+ msleep(2);
+ } else /* data out */
cx_write(MC417_RWD, NETUP_CTRL_OFF | data);
/* choose chip */
@@ -206,7 +207,7 @@
cx_clear(MC417_RWD, (read) ? NETUP_RD : NETUP_WR);
mem = netup_ci_get_mem(dev);
- mutex_unlock(&gpio_mutex);
+ mutex_unlock(&dev->gpio_lock);
if (!read)
if (mem < 0)
@@ -295,10 +296,18 @@
}
/* work handler */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
+static void netup_read_ci_status(void *_state)
+#else
static void netup_read_ci_status(struct work_struct *work)
+#endif
{
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
+ struct netup_ci_state *state = _state;
+#else
struct netup_ci_state *state =
container_of(work, struct netup_ci_state, work);
+#endif
u8 buf[33];
int ret;
@@ -403,7 +412,6 @@
switch (port->nr) {
case 1:
state->ci_i2c_addr = 0x40;
- mutex_init(&gpio_mutex);
break;
case 2:
state->ci_i2c_addr = 0x41;
@@ -442,7 +450,12 @@
if (0 != ret)
goto err;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
+ INIT_WORK(&state->work, netup_read_ci_status, state);
+#else
INIT_WORK(&state->work, netup_read_ci_status);
+#endif
+ schedule_work(&state->work);
ci_dbg_print("%s: CI initialized!\n", __func__);
diff -u cx23885/cx23885-417.c cx23885-commell/cx23885-417.c
--- cx23885/cx23885-417.c 2010-02-15 23:22:38.0 +0100
+++ cx23885-commell/cx23885-417.c 2009-11-11 09:36:16.0 +0100
@@ -37,6 +37,7 @@
#include
#include "cx23885.h"
+#include "cx23885-ioctl.h"
#define CX23885_FIRM_IMAGE_SIZE 376836
#define CX23885_FIRM_IMAGE_NAME "v4l-cx23885-enc.fw"
@@ -318,7 +319,7 @@
}
}
-static int mc417_register_write(struct cx23885_dev *dev, u16 address, u32 value)
+int mc417_register_write(struct cx23885_dev *dev, u16 address, u32 value)
{
u32 regval;
@@ -382,7 +383,7 @@
return mc417_wait_ready(dev);
}
-static int mc417_register_read(struct cx23885_dev *dev, u16 address, u32 *value)
+int mc417_register_read(struct cx23885_dev *dev, u16 address, u32 *value)
{
int retval;
u32 regval;
@@ -630,6 +631,39 @@
return retval;
}
+void mc417_gpio_set(struct cx23885_dev *dev, u32 mask)
+{
+ u32 val;
+
+ /* Set the gpio value */
+ mc417_register_read(dev, 0x900C, &val);
+ val |= (mask & 0x000);
+ mc417_register_write(dev, 0x900C, val);
+}
+
+void mc417_gpio_clear(struct cx23885_dev *dev, u32 mask)
+{
+ u32 val;
+
+ /* Clear the gpio value */
+ mc417_register_read(dev, 0x900C, &val);
+ val &= ~(mask & 0x);
+ mc417_register_write(dev, 0x900C, val);
+}
+
+void mc417_gpio_enable(struct cx23885_dev *dev, u32 mask, int asoutput)
+{
+ u32 val;
+
+ /* Enable GPIO direction bits */
+ mc417_register_read(dev, 0x9020, &val);
+ if (asoutput)
+ val |= (mask & 0x);
+ else
+ val &= ~(mask & 0x);
+
+ mc417_register_write(dev, 0x9020, val);
+}
/* -- */
/* MPEG encoder API */
@@ -955,25 +989,8 @@
retval |= mc417_register_write(dev, IVTV_REG_HW_BLOCKS,
IVTV_CMD_HW_BLOCKS_RST);
- /* Restore GPIO settings, make sure EIO14 is enabled as an output. */
- dprintk(2, "%s: GPIO output EIO 0-15 was = 0x%x\n",
- __func__, gpio_output);
- /* Power-up seems to have GPIOs AFU. This was causing digital side
- * to fail at power-up. Seems GPIOs should be set to 0x10ff0411 at
- * power-up.
- * gpio_output |= (1<<14);
- */
- /* Note: GPIO14 is specific to the HVR1800 here */
- gpio_output = 0x10ff0411 | (1<<14);
- retval |= mc417_register_write(dev, 0x9020, gpio_output | (1<<14));
- dprintk(2, "%s: GPIO output EIO 0-15 now = 0x%x\n",
- __func__, gpio_output);
-
- dprintk(1, "%s: GPIO value EIO 0-15 was
Re: cx23885
I've done a diff against 2.6.31, but there are too many differences, so I
can't easily tell what they have added and what was changed in the
development between 2.6.21 and 2.6.31.
One thing is clear: They added several "case" instructions with code for the
MPX-885. So I guess, they really got it working.
I'm downloading kernel 2.6.21 now and make a diff with these drivers.
Michael
Michael wrote:
> Now comes the best part:
>
> I found a linux driver on the producers web page. And it is written by ...
> Steven Toth :-)
>
> http://www.commell.com.tw/Product/Surveillance/MPX-885/mpx-885.rar
>
> I am looking at the files to see what they have changed (if anything at
> all).
>
> One thing I found pretty fast is that they added in cx23885-card.c:
>
> [CX23885_BOARD_MPX885] = {
> .name = "MPX-885",
> .porta = CX23885_ANALOG_VIDEO,
> .portb = CX23885_MPEG_ENCODER,
> .portc = CX23885_MPEG_DVB,
> .input = {{
> .type = CX23885_VMUX_COMPOSITE1,
> .vmux = CX25840_VIN1_CH1,
> .gpio0 = 0,
> }, {
> .type = CX23885_VMUX_COMPOSITE2,
> .vmux = CX25840_VIN2_CH1,
> .gpio0 = 0,
> }, {
> .type = CX23885_VMUX_COMPOSITE3,
> .vmux = CX25840_VIN3_CH1,
> .gpio0 = 0,
> }, {
> .type = CX23885_VMUX_COMPOSITE4,
> .vmux = CX25840_VIN4_CH1,
> .gpio0 = 0,
> } }
>
> Now, concerning the rest of the code, I'm afraid my knowledge is far below
> what is needed to understand just a little bit of it. I can try to compile
> the code, but they state it is for kernel 2.6.21, so I don't know whether
> it compiles for 2.6.31 (or newer).
>
> I can try to make a diff, but I guess there will be lots of changes
> between this rather old code and an actual cx23885 version.
>
> But maybe it is a start. What do you think?
>
> Michael
>
> Steven Toth wrote:
>
>>
>>> Well if tvtime runs then mplayer will most probably, too. The question
>>> is, what means "with some work" :-)
>>
>> If you haven't worked on the cx23885 driver in the past, and you're not
>> accustomed to developing tv/video drivers then you're going to struggle,
>> massively.
>>
>> Not that I'm trying to discourage, on the contrary, the more driver
>> developers the better. In reality this isn't something you can fix with
>> an evenings work.
>>
>> However, if you would like to take a shot then look at the existing
>> support for the HVR1800 board in the cx23885 tree. Specifically look at
>> the raw video support in the cx23885-video.c file and you'll also want to
>> investigate the cx25840 driver for configuring the A/V subsystem.
>>
>> Feel free to submit patches.
>>
>> Regards,
>>
>> - Steve
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATI TV Wonder 650 PCI development
Perhaps we could contact Broadcom regarding the Theatre 312? Am I making too much of this? I do have a Pinnacle 800i which works with Linux, I was just also wanting to get this card to work. Should I just drop it? Thanks. Sam On Mon, Feb 15, 2010 at 2:37 PM, Alex Deucher wrote: > On Mon, Feb 15, 2010 at 5:34 PM, Devin Heitmueller > wrote: >> On Mon, Feb 15, 2010 at 5:21 PM, Alex Deucher wrote: >>> Who did you contact? gpudriverdevsupport AT amd DOT com is the devel >>> address you probably want. I looked into documentation for the newer >>> theatre chips when I started at AMD, but unfortunately, I'm not sure >>> how much we can release since we sold most of our multimedia IP to >>> Marvell last year. I'm not sure what the status of the theatre chips >>> is now. >>> >>> Documentation for the older theatre and theatre 200 asics was released >>> under NDA years ago which resulted in the theatre support in the >>> opensource radeon Xorg driver and gatos projects. Now that we a >>> proper KMS driver for radeon, someone could port the old userspace >>> theatre code to the kernel for proper v4l support on AIW radeon cards. >>> >>> Alex >> >> For what it's worth, I actually did have a contact at the ATI/AMD >> division that made the Theatre 312/314/316, and I was able to get >> access to both the docs and reference driver sources under NDA. >> However, the division in question was sold off to Broadcom, and I >> couldn't get the rights needed to do a GPL driver nor to get >> redistribution rights on the firmware. In fact, they couldn't even >> told me who actually *held* the rights for the reference driver code. >> >> At that point, I decided that it just wasn't worth the effort for such >> an obscure design. > > Ah right, I meant Broadcom, not Marvell. > > Alex > -- 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: ATI TV Wonder 650 PCI development
On Mon, Feb 15, 2010 at 5:34 PM, Devin Heitmueller wrote: > On Mon, Feb 15, 2010 at 5:21 PM, Alex Deucher wrote: >> Who did you contact? gpudriverdevsupport AT amd DOT com is the devel >> address you probably want. I looked into documentation for the newer >> theatre chips when I started at AMD, but unfortunately, I'm not sure >> how much we can release since we sold most of our multimedia IP to >> Marvell last year. I'm not sure what the status of the theatre chips >> is now. >> >> Documentation for the older theatre and theatre 200 asics was released >> under NDA years ago which resulted in the theatre support in the >> opensource radeon Xorg driver and gatos projects. Now that we a >> proper KMS driver for radeon, someone could port the old userspace >> theatre code to the kernel for proper v4l support on AIW radeon cards. >> >> Alex > > For what it's worth, I actually did have a contact at the ATI/AMD > division that made the Theatre 312/314/316, and I was able to get > access to both the docs and reference driver sources under NDA. > However, the division in question was sold off to Broadcom, and I > couldn't get the rights needed to do a GPL driver nor to get > redistribution rights on the firmware. In fact, they couldn't even > told me who actually *held* the rights for the reference driver code. > > At that point, I decided that it just wasn't worth the effort for such > an obscure design. Ah right, I meant Broadcom, not Marvell. Alex -- 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: ATI TV Wonder 650 PCI development
On Mon, Feb 15, 2010 at 5:21 PM, Alex Deucher wrote: > Who did you contact? gpudriverdevsupport AT amd DOT com is the devel > address you probably want. I looked into documentation for the newer > theatre chips when I started at AMD, but unfortunately, I'm not sure > how much we can release since we sold most of our multimedia IP to > Marvell last year. I'm not sure what the status of the theatre chips > is now. > > Documentation for the older theatre and theatre 200 asics was released > under NDA years ago which resulted in the theatre support in the > opensource radeon Xorg driver and gatos projects. Now that we a > proper KMS driver for radeon, someone could port the old userspace > theatre code to the kernel for proper v4l support on AIW radeon cards. > > Alex For what it's worth, I actually did have a contact at the ATI/AMD division that made the Theatre 312/314/316, and I was able to get access to both the docs and reference driver sources under NDA. However, the division in question was sold off to Broadcom, and I couldn't get the rights needed to do a GPL driver nor to get redistribution rights on the firmware. In fact, they couldn't even told me who actually *held* the rights for the reference driver code. At that point, I decided that it just wasn't worth the effort for such an obscure design. Devin -- Devin J. Heitmueller - 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
[PATCH] dvb-usb/opera1: misplaced parenthesis
The parenthesis was misplaced, tmp is set to 0 or break occurs,
while debugging opera1_usb_i2c_msgxfer() retval was not shown.
Signed-off-by: Roel Kluin
---
diff --git a/drivers/media/dvb/dvb-usb/opera1.c
b/drivers/media/dvb/dvb-usb/opera1.c
index d4e2309..8305576 100644
--- a/drivers/media/dvb/dvb-usb/opera1.c
+++ b/drivers/media/dvb/dvb-usb/opera1.c
@@ -138,7 +138,7 @@ static int opera1_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg msg[],
(msg[i].addr<<1)|(msg[i].flags&I2C_M_RD?0x01:0),
msg[i].buf,
msg[i].len
- )!= msg[i].len)) {
+ )) != msg[i].len) {
break;
}
if (dvb_usb_opera1_debug & 0x10)
--
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: ATI TV Wonder 650 PCI development
On Mon, Feb 15, 2010 at 3:57 PM, Samuel Cantrell wrote: > Hello, > > I have an ATI TV Wonder 650 PCI card, and have started to work on the > wiki page on LinuxTV.org regarding it. I want to *attempt* to write a > driver for it (more like, take a look at the code and run), and have > printed off some information on the wiki. I need to get pictures up of > the card and lspci output, etc. > > Is there anyone else more experienced at writing drivers that could > perhaps help? > > http: // www.linuxtv.org / pipermail / linux-dvb / 2007-October / > 021228.html says that three pieces of documentation are missing. I've > emailed Samsung regarding the tuner module on the card, as I could not > find it on their website. I checked some of their affiliates as well, > but still had no luck. I've emailed AMD/ATI regarding the card and > technical documentation. > Who did you contact? gpudriverdevsupport AT amd DOT com is the devel address you probably want. I looked into documentation for the newer theatre chips when I started at AMD, but unfortunately, I'm not sure how much we can release since we sold most of our multimedia IP to Marvell last year. I'm not sure what the status of the theatre chips is now. Documentation for the older theatre and theatre 200 asics was released under NDA years ago which resulted in the theatre support in the opensource radeon Xorg driver and gatos projects. Now that we a proper KMS driver for radeon, someone could port the old userspace theatre code to the kernel for proper v4l support on AIW radeon cards. Alex > Is it likely that that the tuner module has an XC3028 in it? In the > same linux-dvb message thread noted above, someone speculated that > there is a XC3028. As the v4l tree has XC3028 support, if this is > true, wouldn't that help at least a little bit? > > Thanks. > > Sam > -- > 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: cx23885
One thing I found pretty fast is that they added in cx23885-card.c: This looks promising. But maybe it is a start. What do you think? I repeat I my original comment below. Feel free to submit patches. ^^^ indeed, good luck. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
Now comes the best part:
I found a linux driver on the producers web page. And it is written by ...
Steven Toth :-)
http://www.commell.com.tw/Product/Surveillance/MPX-885/mpx-885.rar
I am looking at the files to see what they have changed (if anything at
all).
One thing I found pretty fast is that they added in cx23885-card.c:
[CX23885_BOARD_MPX885] = {
.name = "MPX-885",
.porta = CX23885_ANALOG_VIDEO,
.portb = CX23885_MPEG_ENCODER,
.portc = CX23885_MPEG_DVB,
.input = {{
.type = CX23885_VMUX_COMPOSITE1,
.vmux = CX25840_VIN1_CH1,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE2,
.vmux = CX25840_VIN2_CH1,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE3,
.vmux = CX25840_VIN3_CH1,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE4,
.vmux = CX25840_VIN4_CH1,
.gpio0 = 0,
} }
Now, concerning the rest of the code, I'm afraid my knowledge is far below
what is needed to understand just a little bit of it. I can try to compile
the code, but they state it is for kernel 2.6.21, so I don't know whether it
compiles for 2.6.31 (or newer).
I can try to make a diff, but I guess there will be lots of changes between
this rather old code and an actual cx23885 version.
But maybe it is a start. What do you think?
Michael
Steven Toth wrote:
>
>> Well if tvtime runs then mplayer will most probably, too. The question
>> is, what means "with some work" :-)
>
> If you haven't worked on the cx23885 driver in the past, and you're not
> accustomed to developing tv/video drivers then you're going to struggle,
> massively.
>
> Not that I'm trying to discourage, on the contrary, the more driver
> developers the better. In reality this isn't something you can fix with an
> evenings work.
>
> However, if you would like to take a shot then look at the existing
> support for the HVR1800 board in the cx23885 tree. Specifically look at
> the raw video support in the cx23885-video.c file and you'll also want to
> investigate the cx25840 driver for configuring the A/V subsystem.
>
> Feel free to submit patches.
>
> Regards,
>
> - Steve
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: FM radio problem with HVR1120
Hi,
Here the results of tests.
In FM radio mode regspy.exe reports :
GPIO_GPSTATUS 2840001
In Digital TV
GPIO_GPSTATUS 6040001
In Analog TV
GPIO_GPSTATUS 2040001
In saa7134-cards.c, In section of HVR1120, I've replaced 0x0800100 with
0x2840001 in both lines
gpiomask and in
radio = {
.name = name_radio,
.amux = TV,
.gpio = 0x2840001,
The result is the same. No progress.
To check my install method (I am not professional programmer), I have tested
the driver with replacing "audio_clock = 0x00187de7" with "audio_clock =
0x20". The result was worst. I can conclude make and make install are
correct.
All tests have been made today using v4l-dvb-14021dfc00f3.tar.gz
All changes have been followed by computer reboot.
Coul I check anything else ?
Regards,
ftape-jlc
Le mercredi 10 février 2010, vous avez écrit :
> Hi,
>
> ftape-jlc wrote:
> > Hello,
> >
> > I didn't received any message about radio on HVR1120.
> > I just want to know if the use /dev/radio0 is deprecated in v4l2 today.
> > In the mails, I only read messages about video or TV.
>
> No, it is not deprecated.
>
> > Did one user of the mailing list have tested actual v4l2 on /dev/radio0 ?
>
> Yes. It works with several devices. Maybe there's a bug at the radio entry
> for your board.
>
> >> The problem is to listen radio.
> >> With Linux, the command used is
> >> /usr/bin/radio -c /dev/radio0
> >> in association with
> >> sox -t ossdsp -r 32000 -c 2 /dev/dsp1 -t ossdsp /dev/dsp
> >> to listen the sound.
> >>
> >> The result is an unstable frecuency. The station is not tuned. Stereo is
> >> permanently switching to mono.
> >> The 91.5MHz station is mixed permanently with other stations.
>
> This probably means that the GPIO setup for your board is wrong for radio.
> Only someone with a HVR1120 could fix it, since the GPIO's are
> board-specific.
>
> The better is if you could try to do it. It is not hard. Please take a look
> at:
>
> http://linuxtv.org/wiki/index.php/GPIO_pins
>
> You'll need to run the regspy.exe utility (part of Dscaler package), and
> check how the original driver sets the GPIO registers. Then edit them on
> your board entry, at saa78134-cards.c, recompile the driver and test.
>
> The better is to use the out-of-tree mercuiral tree:
> http://linuxtv.org/hg/v4l-dvb
>
> since it allows you to recompile and test without needing to replace your
> kernel.
>
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: ATI TV Wonder 650 PCI development
On Mon, Feb 15, 2010 at 3:57 PM, Samuel Cantrell wrote: > Hello, > > I have an ATI TV Wonder 650 PCI card, and have started to work on the > wiki page on LinuxTV.org regarding it. I want to *attempt* to write a > driver for it (more like, take a look at the code and run), and have > printed off some information on the wiki. I need to get pictures up of > the card and lspci output, etc. > > Is there anyone else more experienced at writing drivers that could > perhaps help? > > http: // www.linuxtv.org / pipermail / linux-dvb / 2007-October / > 021228.html says that three pieces of documentation are missing. I've > emailed Samsung regarding the tuner module on the card, as I could not > find it on their website. I checked some of their affiliates as well, > but still had no luck. I've emailed AMD/ATI regarding the card and > technical documentation. > > Is it likely that that the tuner module has an XC3028 in it? In the > same linux-dvb message thread noted above, someone speculated that > there is a XC3028. As the v4l tree has XC3028 support, if this is > true, wouldn't that help at least a little bit? The big issue with this board is not the tuner itself, but the PCI bridge. Developing the drivers for a bridge can take months of work, and unlike bridges from NXP or Conexant which are used in dozens of products, this bridge is only ever used in this one board by this one vendor. And in the cases of NXP and Conexant bridges, usually the person writing the driver for the bridge has real documentation. It just isn't worth any developer's effort to spend three months reverse engineering a bridge to an older and more obscure product with no supporting documentation (and three months as an estimate is what it would take an *experienced* LinuxTV developer who has worked on other bridges). There are just *much* better uses for developer resources. Also, not only is the bridge not supported, but neither is the demodulator (it's an ATI312). Again, no documentation and it's only used in that one hardware design, so it's not like the work would really help with other more popular products. Devin -- Devin J. Heitmueller - 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
ATI TV Wonder 650 PCI development
Hello, I have an ATI TV Wonder 650 PCI card, and have started to work on the wiki page on LinuxTV.org regarding it. I want to *attempt* to write a driver for it (more like, take a look at the code and run), and have printed off some information on the wiki. I need to get pictures up of the card and lspci output, etc. Is there anyone else more experienced at writing drivers that could perhaps help? http: // www.linuxtv.org / pipermail / linux-dvb / 2007-October / 021228.html says that three pieces of documentation are missing. I've emailed Samsung regarding the tuner module on the card, as I could not find it on their website. I checked some of their affiliates as well, but still had no luck. I've emailed AMD/ATI regarding the card and technical documentation. Is it likely that that the tuner module has an XC3028 in it? In the same linux-dvb message thread noted above, someone speculated that there is a XC3028. As the v4l tree has XC3028 support, if this is true, wouldn't that help at least a little bit? Thanks. Sam -- 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: cx23885
Well if tvtime runs then mplayer will most probably, too. The question is, what means "with some work" :-) If you haven't worked on the cx23885 driver in the past, and you're not accustomed to developing tv/video drivers then you're going to struggle, massively. Not that I'm trying to discourage, on the contrary, the more driver developers the better. In reality this isn't something you can fix with an evenings work. However, if you would like to take a shot then look at the existing support for the HVR1800 board in the cx23885 tree. Specifically look at the raw video support in the cx23885-video.c file and you'll also want to investigate the cx25840 driver for configuring the A/V subsystem. Feel free to submit patches. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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
Working USB DVB staff?
I'm writing to ask about any DVB staff for notebook. I know many models haven't any working drivers, due to many reasons. The question is: Are there any preety good DVB cards which i can use? Which one do you prefere? I don't expect a new model witch DVB- S2. It may be an older model. It should be only usable on linux. I will be very pleased for any anwsers. Best Regards. Dominik Sito -- 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: cx23885
Steven Toth wrote: > The hardware has no mpeg encoder, so if by digitizer you mean raw high > bitrate video frames then yes, and if mplayer is capable of supporting the > v4l mmap interfaces then yes. (I've have zero experience of mplayer with > raw video - not sure if this works). Well, I have mplayer working with a bttv based card sending rawyuv2, if I remember correctly. But this is on a different computer. The board that I want to use has only mini-pci-express and the only card I found so far is this MPX-885. > > It feels like a reach, the design looks like a 'same-old' cx23885/7/8 > which you could potentially use in tvtime - with some work. > Well if tvtime runs then mplayer will most probably, too. The question is, what means "with some work" :-) Michael -- 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: cx23885
Devin Heitmueller wrote: > I would probably advise against using a cx23885 based design for > analog under Linux right now. There is *some* analog support in the > driver, but it is not very mature and has a host of issues/bugs. > Also, there is currently no analog audio support in the driver, so if > you do not have an encoder then it will not work. > Well, I don't need audio, just video. A raw stream is everything I need, as it is displayed by mplayer directly. But you mean that this most probably wouldn't work as the analog support is not good enough for the time being? > In other words, even if all you did need was to add another PCI ID, > you would still be very likely to run into problems. > > We (KernelLabs) have a handful of patches that can eventually get into > the upstream driver, although right now progress is slow on that front > and you certainly shouldn't buy hardware based on the expectation that > the patches are forthcoming. > Well, would these patches help me to get the card working for my purpose (raw video stream)? I don't mind patching the driver. I am no developer, but applying a patch and compiling the driver I should manage. Otherwise do you know another mini-pci-express video capture card that is supported by the linux kernel? Thanks for your help Michael > Devin > -- 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: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
Thanks!
That patch, unchanged is consistently successful in addressing the Zarlink
initialisation error for me.
It also eliminates a no doubt related problem in the lack of detection of some
of the Xceive tuners, a problem I had previously overlooked for some reason and
later discovered when I wanted to see if analogue tuning worked. detail:
i2c_core:i2c_new_probed_device would fairly consistently fail to find/probe
some of the tuners such that 'XX-0061: chip found @ 0xc2 (cx18 i2c driver
#X-1)' logs would only appear against roughly half of my cards - a much more
obvious problem than the one I originally reported!
Briefly I patched my build to ignore the Zarlink frontend initialisation error
and allow the cx18 to proceed to register the v4l device and this helped me
meet my main composite video capture project requirement - this is now
unnecessary.
I'll be testing over the next few days and report anything unexpected / of
interested.
Cheers
Patrick
- Original Message
> From: Andy Walls
> To: Patrick Cairns
> Cc: linux-media@vger.kernel.org
> Sent: Sat, 13 February, 2010 23:28:59
> Subject: Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error
> (reg=127, ret==-6)
>
> On Tue, 2010-02-09 at 07:19 -0800, Patrick Cairns wrote:
> > > On Tue, 2010-02-09 at 03:35 -0800, Patrick Cairns wrote:
>
> > > > I'm testing use of multiple Leadtek WinFast DVR3100 H cards for a
> > > > project. I've had large numbers of them working well in the same
> > > > machine as encoders (haven't been using the DVB-T capabilities).
> > > >
> > > > However if I use more than a few of these cards in the same machine
> > > > then upon startup there are always one or two cards where Zarlink
> > > > zl10353 reading errors are reported preventing their use:-
> > > >
>
>
> > > This was an excellent test to perform. IIRC, only the ZL10353 and
> > > XC3028 are on the second I2C bus (#10-1 in this case), which likely
> > > means one of those two chips is hung.
>
> > > > Can anyone advise how to debug this further or know any fixes to try?
> > > > I'm not quite sure what's going on under the hood.
>
>
> Patrick,
>
> Can you test the patch below? It will reset the XC3028 before the I2C
> bus is first used, and it will try to reset the ZL10353 before the I2C
> bus is first used.
>
> You'll need to recompile and test until you find the GPIO line that
> appears to reset the ZL10353.
>
> #define DVR3100_ZL10353_RESET_GPIO(1 << 8)
> ^
> |
>Change this number
>
> Try GPIO pins 8-15 first, then 3-7, then 16-31, then 0.
> If that doesn't work then try them again, but change more of the patch
> to assume an active high reset for the ZL10353 GPIO line instead of
> active low.
>
>
> There is also an W83601 chip connected to this I2C bus along with the
> XC3028 and ZL10353, but hopefully we won't have to worry about resetting
> that too.
>
> Please let me know if you find a GPIO pin that reliably has all your
> cards working upon modprobe. You should *not* need to cycle power
> between each test.
>
> Regards,
> Andy
>
> diff -r 14021dfc00f3 linux/drivers/media/video/cx18/cx18-cards.c
> --- a/linux/drivers/media/video/cx18/cx18-cards.cThu Feb 11 23:11:30 2010
> -0200
> +++ b/linux/drivers/media/video/cx18/cx18-cards.cSat Feb 13 18:14:32 2010
> -0500
> @@ -452,10 +452,34 @@
> .tune_lane = 0,
> .initial_emrs = 0x2,
> },
> -.gpio_init.initial_value = 0x6,
> -.gpio_init.direction = 0x7,
> -.gpio_audio_input = { .mask = 0x7,
> - .tuner = 0x6, .linein = 0x2, .radio = 0x2 },
> +
> +/*
> + * GPIOs
> + * 0 0x0001 Audio/FM related???
> + * 1 0x0002 XC3028 reset line, active low
> + * 2 0x0004 Audio input multiplexer: 1 - Tuner, 0 - Line-in
> + */
> +#define DVR3100_XC3028_RESET_GPIO(1 << 1)
> +
> +/* FIXME - Try GPIO pins 8-15 first, then 3-7, then 16-31, then 0, */
> +/* then try them again using active high for the reset, until found */
> +#define DVR3100_ZL10353_RESET_GPIO(1 << 8)
> +
> +.gpio_init.direction = 0x5 |
> + DVR3100_XC3028_RESET_GPIO |
> + DVR3100_ZL10353_RESET_GPIO,
> +.gpio_init.initial_value = 0x4 |
> + DVR3100_XC3028_RESET_GPIO |
> + DVR3100_ZL10353_RESET_GPIO,
> +.gpio_audio_input = { .mask = 0x4,
> + .tuner = 0x4, .linein = 0x0, .radio = 0x0 },
> +.gpio_i2c_slave_reset = {
> +.active_hi_mask = 0x0,
> +.active_lo_mask = DVR3100_XC3028_RESET_GPIO |
> + DVR3100_ZL10353_RESET_GPIO,
> +.msecs_asserted = 50, /* ZL10353 requires 50 ms */
> +.msecs_recovery = 50, /* A guess */
> +},
> .xceive_pin = 1,
> .pci_list = cx18_pci_leadtek_dvr3100h,
> .i2c = &cx18_i2c_std,
USB TV stick with 18271HD-C2 chip
Hello, I am trying to get a USB TV stick to work: with Linux - Inside the case, it has a NXP TDA18271HDC2 tuning chip, but no decoder. Shows up as a "Cali TV Card" with idVendor 0x438, idProduct 0xac14 Three devices get created under major 189 minor 6 /dev/char/189:6 DEVPATH=/devices/pci:00/:00:03.3/usb1/1-1 DEVPATH=/devices/pci:00/:00:03.3/usb1/1-1/1-1:1.0 I figure that it requires the 'tda18271' driver to work (v4l-dvb/tda18271-common.c ...), but haven't had much such success trying to use modprobe and lsmod. The product data sheet for the chip is at: http://www.nxp.com/documents/data_sheet/TDA18271HD.pdf Can anyone help? Cheers, Michael -- 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:Mon Feb 15 19:00:07 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14198:14021dfc00f3 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-rc5-armv5-davinci: ERRORS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-rc5-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
Re: [PATCH 01/11] xc2028: tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
Am 15.02.2010 19:36, schrieb Devin Heitmueller:
> On Mon, Feb 15, 2010 at 12:37 PM, wrote:
>
>> From: Stefan Ringel
>>
>> Signed-off-by: Stefan Ringel
>>
>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
>> b/drivers/media/common/tuners/tuner-xc2028.c
>> index ed50168..e051caa 100644
>> --- a/drivers/media/common/tuners/tuner-xc2028.c
>> +++ b/drivers/media/common/tuners/tuner-xc2028.c
>> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>>
>>/* All S-code tables need a 200kHz shift */
>>if (priv->ctrl.demod) {
>> - demod = priv->ctrl.demod + 200;
>> + if ((priv->firm_version == 0x0306) &&
>> + (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
>> + ((type & DTV78) || (type & DTV8)))
>> + demod = priv->ctrl.demod;
>> + else
>> + demod = priv->ctrl.demod + 200;
>>/*
>> * The DTV7 S-code table needs a 700 kHz shift.
>> * Thanks to Terry Wu for reporting
>> this
>>
> I would still like to better understand the origin of this change.
> Was the tm6000 board not locking without it? Was this change based on
> any documented source? What basis are you using when deciding this
> issue is specific only to the zl10353 and not all boards using the
> xc3028L?
>
> We've got a number of boards already supported which use the xc3028L,
> so we need to ensure there is no regression introduced in those boards
> just to get yours working.
>
> Devin
>
>
Devin here in attachment the firmware table. You see, that it is has two
entries for ZARLINK456, one for QAM, DTV6 and DTV7, and one for DTV78
and DTV8. The first have a shift from +200, the second doesn't. I can
test for you without this patch to see what for demodulator status is has.
Stefan Ringel
--
Stefan Ringel
list action
firmware file name: xc3028L-v36.fw
firmware name: xc2028 firmware
version:3.6 (774)
standards: 81
Firmware 0, type: BASE FW F8MHZ (0x0003), id: (), size:
9144
Firmware 1, type: BASE FW F8MHZ MTS (0x0007), id: (),
size: 9030
Firmware 2, type: BASE FW FM (0x0401), id: (), size: 9054
Firmware 3, type: BASE FW FM INPUT1 (0x0c01), id: (),
size: 9068
Firmware 4, type: BASE FW (0x0001), id: (), size: 9132
Firmware 5, type: BASE FW MTS (0x0005), id: (), size:
9006
Firmware 6, type: STD FW(0x), id: PAL/BG (0007), size:
161
Firmware 7, type: STD FWMTS (0x0004), id: PAL/BG (0007),
size: 169
Firmware 8, type: STD FW(0x), id: PAL/BG (0007), size:
161
Firmware 9, type: STD FWMTS (0x0004), id: PAL/BG (0007),
size: 169
Firmware 10, type: STD FW(0x), id: PAL/BG (0007), size:
161
Firmware 11, type: STD FWMTS (0x0004), id: PAL/BG (0007),
size: 169
Firmware 12, type: STD FW(0x), id: PAL/BG (0007), size:
161
Firmware 13, type: STD FWMTS (0x0004), id: PAL/BG (0007),
size: 169
Firmware 14, type: STD FW(0x), id: PAL/DK (00e0), size:
161
Firmware 15, type: STD FWMTS (0x0004), id: PAL/DK (00e0),
size: 169
Firmware 16, type: STD FW(0x), id: PAL/DK (00e0), size:
161
Firmware 17, type: STD FWMTS (0x0004), id: PAL/DK (00e0),
size: 169
Firmware 18, type: STD FW(0x), id: SECAM/K1 (0020),
size: 161
Firmware 19, type: STD FWMTS (0x0004), id: SECAM/K1 (0020),
size: 169
Firmware 20, type: STD FW(0x), id: SECAM/K3 (0400),
size: 161
Firmware 21, type: STD FWMTS (0x0004), id: SECAM/K3 (0400),
size: 169
Firmware 22, type: STD FWD2633 DTV6 ATSC (0x00010030), id:
(), size: 149
Firmware 23, type: STD FWD2620 DTV6 QAM (0x0068), id:
(), size: 149
Firmware 24, type: STD FWD2633 DTV6 QAM (0x0070), id:
(), size: 149
Firmware 25, type: STD FWD2620 DTV7 (0x0088), id: (),
size: 149
Firmware 26, type: STD FWD2633 DTV7 (0x0090), id: (),
size: 149
Firmware 27, type: STD FWD2620 DTV78 (0x0108), id: (),
size: 149
Firmware 28, type: STD FWD2633 DTV78 (0x0110), id: (),
size: 149
Firmware 29, type: STD FWD2620 DTV8 (0x0208), id: (),
size: 149
Firmware 30, type: STD FWD2633 DTV8 (0x0210), id: (),
size: 149
Firmware 31, type: STD FWFM (0x0400), id: (), size: 135
Firmware 32, type: STD FW(0x), id: PAL/I (0010), size:
161
Firmware 33, type: STD FWMTS (0x0004), id: PAL/I
Re: [PATCH 01/11] xc2028: tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
On Mon, Feb 15, 2010 at 12:37 PM, wrote:
> From: Stefan Ringel
>
> Signed-off-by: Stefan Ringel
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
> b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..e051caa 100644
> --- a/drivers/media/common/tuners/tuner-xc2028.c
> +++ b/drivers/media/common/tuners/tuner-xc2028.c
> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>
> /* All S-code tables need a 200kHz shift */
> if (priv->ctrl.demod) {
> - demod = priv->ctrl.demod + 200;
> + if ((priv->firm_version == 0x0306) &&
> + (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
> + ((type & DTV78) || (type & DTV8)))
> + demod = priv->ctrl.demod;
> + else
> + demod = priv->ctrl.demod + 200;
> /*
> * The DTV7 S-code table needs a 700 kHz shift.
> * Thanks to Terry Wu for reporting
> this
I would still like to better understand the origin of this change.
Was the tm6000 board not locking without it? Was this change based on
any documented source? What basis are you using when deciding this
issue is specific only to the zl10353 and not all boards using the
xc3028L?
We've got a number of boards already supported which use the xc3028L,
so we need to ensure there is no regression introduced in those boards
just to get yours working.
Devin
--
Devin J. Heitmueller - 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
[PULL] git: soc-camera patches for 2.6.24
I'm still hoping to get some resolution of my question from http://article.gmane.org/gmane.linux.power-management.general/17462 after which, hopefully, we fix a problem with mt9t031, and, perhaps, in a reasonable generic manner. Another patch "soc_camera: match signedness of soc_camera_limit_side()" is still awaiting confirmation from its original author. Otherwise: The following changes since commit 7e24229d0a2370c6e6aa9e6ffa6ecbaf8d8f091f: Oliver Endriss (1): V4L/DVB: ngene: Fix I2C initialisation are available in the git repository at: ssh://linuxtv.org/git/gliakhovetski/soc-camera.git devel Antonio Ospite (1): pxa_camera: remove init() callback Guennadi Liakhovetski (5): soc-camera: update mt9v022 to take into account board signal routing tw9910: use TABs for indentation soc-camera: adjust coding style to match V4L preferences soc-camera: add support for VIDIOC_S_PARM and VIDIOC_G_PARM ioctls sh_mobile_ceu_camera: pass .set_parm and .get_parm down to subdevices Kuninori Morimoto (1): soc-camera: ov772x: Modify buswidth control Magnus Damm (1): soc-camera: return -ENODEV if sensor is missing arch/arm/mach-pxa/include/mach/camera.h|2 - arch/sh/boards/mach-ap325rxa/setup.c |4 +- arch/sh/boards/mach-migor/setup.c |2 +- drivers/media/video/mt9v022.c | 17 +- drivers/media/video/ov772x.c | 22 - drivers/media/video/pxa_camera.c | 10 -- drivers/media/video/sh_mobile_ceu_camera.c | 18 +++ drivers/media/video/soc_camera.c | 36 ++ drivers/media/video/soc_mediabus.c | 45 ++- drivers/media/video/tw9910.c |8 ++-- include/media/ov772x.h | 10 +++--- include/media/soc_camera.h |2 + include/media/tw9910.h |4 +- 13 files changed, 109 insertions(+), 71 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 10/11] tm6000: remove hack.c hack.h, switch to zl10353 module
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/staging/tm6000/Makefile b/drivers/staging/tm6000/Makefile
index f904d57..8a7faad 100644
--- a/drivers/staging/tm6000/Makefile
+++ b/drivers/staging/tm6000/Makefile
@@ -6,7 +6,6 @@ tm6000-objs := tm6000-cards.o \
ifeq ($(CONFIG_VIDEO_TM6000_DVB),y)
tm6000-objs += tm6000-dvb.o \
- hack.o
endif
obj-$(CONFIG_VIDEO_TM6000) += tm6000.o
diff --git a/drivers/staging/tm6000/hack.c b/drivers/staging/tm6000/hack.c
deleted file mode 100644
index fdc7078..000
--- a/drivers/staging/tm6000/hack.c
+++ /dev/null
@@ -1,406 +0,0 @@
-
-
-
-
-
-
-/*
- hack.h - hackish code that needs to be improved (or removed) at a
- later point
-
- Copyright (C) 2007 Michel Ludwig
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation version 2
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include "hack.h"
-
-#include "tm6000.h"
-
-#include
-
-static inline int tm6000_snd_control_msg(struct tm6000_core *dev, __u8
request, __u16 value, __u16 index, void *data, __u16 size)
-{
- return tm6000_read_write_usb (dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE, request, value, index, data, size);
-}
-
-static int pseudo_zl10353_pll(struct tm6000_core *tm6000_dev, struct
dvb_frontend_parameters *p)
-{
- u8 *data = kzalloc(50*sizeof(u8), GFP_KERNEL);
-
-printk(KERN_ALERT "should set frequency %u\n", p->frequency);
-printk(KERN_ALERT "and bandwith %u\n", p->u.ofdm.bandwidth);
-
- if(tm6000_dev->dvb->frontend->ops.tuner_ops.set_params) {
-
tm6000_dev->dvb->frontend->ops.tuner_ops.set_params(tm6000_dev->dvb->frontend,
p);
- }
- else {
- printk(KERN_ALERT "pseudo zl10353: couldn't set tuner
parameters\n");
- }
-
- // init ZL10353
-/* data[0] = 0x0b;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x501e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x80;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x551e, 0x00, data, 0x1);
- msleep(100);
- data[0] = 0x01;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0xea1e, 0x00, data, 0x1);
- msleep(100);
- data[0] = 0x00;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0xea1e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x1c;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x561e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x40;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x5e1e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x36;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x641e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x67;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x651e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0xe5;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x661e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x19;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x6c1e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0xe9;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x6d1e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x44;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x511e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x46;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x521e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x15;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x531e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x0f;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x541e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x75;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x5c1e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x01;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x701e, 0x00, data, 0x1);
- msleep(15);
- data[0] = 0x00;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x701e, 0x00, data, 0x1);
- msleep(15);
-
- msleep(50);
-
- switch(p->u.ofdm.bandwidth) {
- case BANDWIDTH_8_MHZ:
- data[0] = 0x00;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x701e,
0x00, data, 0x1);
- msleep(15);
- data[0] = 0x36;
- ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x641e,
0x00,
[PATCH 09/11] zl10353: tm6000: bugfix reading problems with tm6000 i2c host
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/media/dvb/frontends/zl10353.c
b/drivers/media/dvb/frontends/zl10353.c
index 8c61271..9716d7e 100644
--- a/drivers/media/dvb/frontends/zl10353.c
+++ b/drivers/media/dvb/frontends/zl10353.c
@@ -74,7 +74,7 @@ static int zl10353_write(struct dvb_frontend *fe, u8 *ibuf,
int ilen)
return 0;
}
-static int zl10353_read_register(struct zl10353_state *state, u8 reg)
+static int zl10353_read1_register(struct zl10353_state *state, u8 reg)
{
int ret;
u8 b0[1] = { reg };
@@ -97,6 +97,41 @@ static int zl10353_read_register(struct zl10353_state
*state, u8 reg)
return b1[0];
}
+static int zl10353_read2_register(struct zl10353_state *state, u8 reg)
+{
+ int ret;
+ u8 b0[1] = { reg - 1 };
+ u8 b1[1] = { 0 };
+ struct i2c_msg msg[2] = { { .addr = state->config.demod_address,
+ .flags = 0,
+ .buf = b0, .len = 1 },
+ { .addr = state->config.demod_address,
+ .flags = I2C_M_RD,
+ .buf = b1, .len = 2 } };
+
+ ret = i2c_transfer(state->i2c, msg, 2);
+
+ if (ret != 2) {
+ printk("%s: readreg error (reg=%d, ret==%i)\n",
+ __func__, reg, ret);
+ return ret;
+ }
+
+ return b1[1];
+}
+
+static int zl10353_read_register(struct zl10353_state *state, u8 reg)
+{
+ int ret;
+
+ if ((state->i2c->id == I2C_HW_B_TM6000) && (reg % 2 == 0))
+ ret = zl10353_read2_register(state, reg);
+ else
+ ret = zl10353_read1_register(state, reg);
+
+ return ret;
+}
+
static void zl10353_dump_regs(struct dvb_frontend *fe)
{
struct zl10353_state *state = fe->demodulator_priv;
--
1.6.6.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
[PATCH 11/11] tm6000: change version to 0.0.2
From: Stefan Ringel Signed-off-by: Stefan Ringel diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h index 8611092..8285c5a 100644 --- a/drivers/staging/tm6000/tm6000.h +++ b/drivers/staging/tm6000/tm6000.h @@ -37,7 +37,7 @@ #include "dvb_frontend.h" #include "dmxdev.h" -#define TM6000_VERSION KERNEL_VERSION(0, 0, 1) +#define TM6000_VERSION KERNEL_VERSION(0, 0, 2) /* Inputs */ -- 1.6.6.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
[PATCH 08/11] tm6000: special request for all tuner
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 9d02674..ef11d48 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -112,7 +112,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
}
i++;
- if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
+ if (addr == dev->tuner_addr) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
@@ -128,7 +128,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = tm6000_i2c_send_byte(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
- if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
+ if (addr == dev->tuner_addr) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
--
1.6.6.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
[PATCH 06/11] tm6000: reset the numbers of feeds to 8
From: Stefan Ringel Signed-off-by: Stefan Ringel diff --git a/drivers/staging/tm6000/tm6000-dvb.c b/drivers/staging/tm6000/tm6000-dvb.c index e16d55e..12a0758 100644 --- a/drivers/staging/tm6000/tm6000-dvb.c +++ b/drivers/staging/tm6000/tm6000-dvb.c @@ -285,8 +285,8 @@ int tm6000_dvb_register(struct tm6000_core *dev) dvb->demux.dmx.capabilities = DMX_TS_FILTERING | DMX_SECTION_FILTERING | DMX_MEMORY_BASED_FILTERING; dvb->demux.priv = dev; - dvb->demux.filternum = 5; /* 256; */ - dvb->demux.feednum = 5; /* 256; */ + dvb->demux.filternum = 8; + dvb->demux.feednum = 8; dvb->demux.start_feed = tm6000_start_feed; dvb->demux.stop_feed = tm6000_stop_feed; dvb->demux.write_to_decoder = NULL; -- 1.6.6.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
[PATCH 04/11] tm6000: add different tuner reset for terratec
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index ff04bba..5a8d716 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -269,12 +269,28 @@ int tm6000_tuner_callback(void *ptr, int component, int
command, int arg)
/* Reset codes during load firmware */
switch (arg) {
case 0:
- tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
- dev->tuner_reset_gpio, 0x00);
- msleep(130);
- tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
- dev->tuner_reset_gpio, 0x01);
- msleep(130);
+ /* newer tuner can faster reset */
+ switch(dev->model) {
+ case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev->tuner_reset_gpio, 0x01);
+ msleep(60);
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev->tuner_reset_gpio, 0x00);
+ msleep(75);
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev->tuner_reset_gpio, 0x01);
+ msleep(60);
+ break;
+ default:
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev->tuner_reset_gpio, 0x00);
+ msleep(130);
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev->tuner_reset_gpio, 0x01);
+ msleep(130);
+ break;
+ }
break;
case 1:
tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT,
--
1.6.6.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
[PATCH 07/11] tm6000: add i2c send recv functions
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 6b17d0b..9d02674 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -42,6 +42,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
printk(KERN_DEBUG "%s at %s: " fmt, \
dev->name, __FUNCTION__ , ##args); } while (0)
+int tm6000_i2c_send_byte (struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb (dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RND, addr | reg << 8, 0, buf, len);
+}
+
+int tm6000_i2c_recv_byte (struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ int rc:
+
+ rc = tm6000_read_write_usb (dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RND, addr | reg << 8, 0, buf, len);
+
+ return rc;
+}
+
+int tm6000_i2c_recv_word (struct tm6000_core *dev, unsigned char addr, __u16
reg, char *buf , int len)
+{
+ int rc;
+
+ rc = tm6000_read_write_usb (dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_14_SET_GET_I2C_WR2_RND, addr, reg, buf, len);
+
+ return rc;
+}
+
static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num)
{
@@ -76,13 +102,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i2c_dprintk(2, "; joined to read %s len=%d:",
i == num - 2 ? "stop" : "nonstop",
msgs[i + 1].len);
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
-: REQ_14_SET_GET_I2C_WR2_RDN,
- addr | msgs[i].buf[0] << 8,
- msgs[i].len == 1 ? 0 : msgs[i].buf[1],
- msgs[i + 1].buf, msgs[i + 1].len);
+
+ if (msgs[i].len == 1) {
+ rc = tm6000_i2c_recv_byte (dev, addr,
msgs[i].buf[0],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ } else {
+ rc = tm6000_i2c_recv_word (dev, addr,
msgs[i].buf[0] << 8 | msgs[i].buf[1],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ }
i++;
if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
@@ -97,10 +124,8 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
if (i2c_debug >= 2)
for (byte = 0; byte < msgs[i].len; byte++)
printk(" %02x", msgs[i].buf[byte]);
- rc = tm6000_read_write_usb(dev,
- USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN,
- addr | msgs[i].buf[0] << 8, 0,
+
+ rc = tm6000_i2c_send_byte(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
if ((dev->dev_type == TM6010) && (addr == 0xc2)) {
--
1.6.6.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
[PATCH 05/11] tm6000: add card setup for terratec cinergy hybrid
From: Stefan Ringel Signed-off-by: Stefan Ringel diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index 5a8d716..7a60e5c 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -332,6 +332,31 @@ int tm6000_cards_setup(struct tm6000_core *dev) tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01); msleep(11); break; + case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE: + /* Turn zarlink zl10353 on */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_4, 0x00); + msleep(15); + /* Reset zarlink zl10353 */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_1, 0x00); + msleep(50); + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_1, 0x01); + msleep(15); + /* Turn zarlink zl10353 off */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_4, 0x01); + msleep(15); + /* ir ? */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_0, 0x01); + msleep(15); + /* Power led on (blue) */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_7, 0x00); + msleep(15); + /* DVB led off (orange) */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_5, 0x01); + msleep(15); + /* Turn zarlink zl10353 on */ + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_4, 0x00); + msleep(15); + break; default: break; } -- 1.6.6.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
[PATCH 03/11] tm6000: add additional init register
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 9d66a3f..2c9eb74 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -414,6 +414,13 @@ struct reg_init tm6010_init_tab[] = {
{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
+ { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+ { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+ { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+ { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+ { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+ { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+
/* set remote wakeup key:any key wakeup */
{ REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
{ REQ_07_SET_GET_AVREG, 0xda, 0xff },
--
1.6.6.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
[PATCH 02/11] tm6000: add i2c bus id for tm6000
From: Stefan Ringel Signed-off-by: Stefan Ringel diff --git a/drivers/staging/tm6000/tm6000-i2c.c b/drivers/staging/tm6000/tm6000-i2c.c index 05df06b..6b17d0b 100644 --- a/drivers/staging/tm6000/tm6000-i2c.c +++ b/drivers/staging/tm6000/tm6000-i2c.c @@ -32,8 +32,6 @@ #include "tuner-xc2028.h" -/*FIXME: Hack to avoid needing to patch i2c-id.h */ -#define I2C_HW_B_TM6000 I2C_HW_B_EM28XX /* --- */ static unsigned int i2c_debug = 0; diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h index e844a0b..09e3a4e 100644 --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h @@ -42,6 +42,7 @@ #define I2C_HW_B_AU08280x010023 /* auvitek au0828 usb bridge */ #define I2C_HW_B_CX231XX 0x010024 /* Conexant CX231XX USB based cards */ #define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */ +#define I2C_HW_B_TM60000x010026 /* TM5600/TM6000/TM6010 media bridge */ /* --- SGI adapters*/ #define I2C_HW_SGI_VINO0x16 -- 1.6.6.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
[PATCH 01/11] xc2028: tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
From: Stefan Ringel
Signed-off-by: Stefan Ringel
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..e051caa 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv->ctrl.demod) {
- demod = priv->ctrl.demod + 200;
+ if ((priv->firm_version == 0x0306) &&
+ (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
+ ((type & DTV78) || (type & DTV8)))
+ demod = priv->ctrl.demod;
+ else
+ demod = priv->ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu for reporting this
--
1.6.6.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
Re: cx23885
On Mon, Feb 15, 2010 at 10:21 AM, Michael wrote: > So, does this imply that you see a chance to get this card running? :-) > > If so, I will order one card and try. There is not much I want to do with > the card. It should simply digitize an external camera signal. I want to > display it with mplayer. It should, however, be reliable and not crash the > system or drop the stream or whatever. > > So far, it seems that this is the only mini-pcie video digitizer card that > exists. I would have taken a bttv based one instead, but as there is none... I would probably advise against using a cx23885 based design for analog under Linux right now. There is *some* analog support in the driver, but it is not very mature and has a host of issues/bugs. Also, there is currently no analog audio support in the driver, so if you do not have an encoder then it will not work. In other words, even if all you did need was to add another PCI ID, you would still be very likely to run into problems. We (KernelLabs) have a handful of patches that can eventually get into the upstream driver, although right now progress is slow on that front and you certainly shouldn't buy hardware based on the expectation that the patches are forthcoming. Devin -- Devin J. Heitmueller - 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: cx23885
On 2/15/10 10:21 AM, Michael wrote: Steven Toth wrote: Is this because the driver does not have the right capabilities or is it "just" a PCI-id missing in the driver? A mixture of both, analog support in the 885 driver is limited. Generally, yes - start by adding the PCI id. So, does this imply that you see a chance to get this card running? :-) If so, I will order one card and try. There is not much I want to do with the card. It should simply digitize an external camera signal. I want to display it with mplayer. It should, however, be reliable and not crash the system or drop the stream or whatever. So far, it seems that this is the only mini-pcie video digitizer card that exists. I would have taken a bttv based one instead, but as there is none... The hardware has no mpeg encoder, so if by digitizer you mean raw high bitrate video frames then yes, and if mplayer is capable of supporting the v4l mmap interfaces then yes. (I've have zero experience of mplayer with raw video - not sure if this works). It feels like a reach, the design looks like a 'same-old' cx23885/7/8 which you could potentially use in tvtime - with some work. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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
Fourcc for multiplanar formats
Hello, we would like to ask for suggestions for new fourcc formats for multiplanar buffers. There are planar formats in V4L2 API, but for all of them, each plane X "immediately follows Y plane in memory". We are in the process of testing formats and V4L2 extensions that relax those requirements and allow each plane to reside in a separate area of memory. I am not sure how we should name those formats though. In our example, we are focusing on the following formats at the moment: - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) Could anyone give any suggestions how we should name such formats and what to pass to the v4l2_fourcc() macro? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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: cx23885
Steven Toth wrote: >> Is this because the driver does not have the right capabilities or is it >> "just" a PCI-id missing in the driver? > > A mixture of both, analog support in the 885 driver is limited. Generally, > yes - start by adding the PCI id. > So, does this imply that you see a chance to get this card running? :-) If so, I will order one card and try. There is not much I want to do with the card. It should simply digitize an external camera signal. I want to display it with mplayer. It should, however, be reliable and not crash the system or drop the stream or whatever. So far, it seems that this is the only mini-pcie video digitizer card that exists. I would have taken a bttv based one instead, but as there is none... Thanks Michael -- 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
Any remotes that work with the pcHDTV HD5500?
Greetings: The pcHDTV HD5500 ships with an IR receiver but no remote. Support seems to be there: input: cx88 IR (pcHDTV HD5500 HDTV) as /devices/pci:00/:00:06.0/:01:07.1/input/input6 Does anyone know of a remote that actually works with it? I have read that it is supposed to be a "Phillips/Magnavox" type, so I tried setting several programmable remotes to the codes for Phillips and Magnavox TVs, but nothing has worked so far. Thanks, -- Mark -- 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: cx23885
On 2/15/10 8:15 AM, Michael wrote: Hi Andy Does anybody know whether this card is currently supported Likely no. I have not checked the source to be sure. Is this because the driver does not have the right capabilities or is it "just" a PCI-id missing in the driver? A mixture of both, analog support in the 885 driver is limited. Generally, yes - start by adding the PCI id. The latter would be quite easy to add, I guess. and if yes, is it by cx88 or by cx23885? http://www.commell.com.tw/Product/Surveillance/MPX-885.htm It is based on the Connexant 23885 chip but uses an Mini-PCIe interface. cx88 handles PCI bridge chips: CX2388[0123] cx23885 handles PCIe bridge chips: CX2388[578] > From the picture of the card from the datasheet it has a CX23885 chip. That means, if a driver might support it, then the cx23885 driver not the cx88, correct? Correct. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
Hi Andy >> Does anybody know whether this card is currently supported > > Likely no. I have not checked the source to be sure. > Is this because the driver does not have the right capabilities or is it "just" a PCI-id missing in the driver? The latter would be quite easy to add, I guess. > >> and if yes, is it >> by cx88 or by cx23885? >> >> http://www.commell.com.tw/Product/Surveillance/MPX-885.htm >> >> It is based on the Connexant 23885 chip but uses an Mini-PCIe interface. > > cx88 handles PCI bridge chips: CX2388[0123] > > cx23885 handles PCIe bridge chips: CX2388[578] > >>From the picture of the card from the datasheet it has a CX23885 chip. > That means, if a driver might support it, then the cx23885 driver not the cx88, correct? Thanks Michael > Regards, > Andy > >> Thanks >> >> Michael -- 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: cx23885
On Mon, 2010-02-15 at 13:20 +0100, Michael wrote: > Hello > > Does anybody know whether this card is currently supported Likely no. I have not checked the source to be sure. > and if yes, is it > by cx88 or by cx23885? > > http://www.commell.com.tw/Product/Surveillance/MPX-885.htm > > It is based on the Connexant 23885 chip but uses an Mini-PCIe interface. cx88 handles PCI bridge chips: CX2388[0123] cx23885 handles PCIe bridge chips: CX2388[578] >From the picture of the card from the datasheet it has a CX23885 chip. Regards, Andy > Thanks > > Michael -- 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 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner
On Mon, 2010-02-15 at 08:10 +0100, Hans Verkuil wrote: > On Sunday 14 February 2010 23:10:48 Andy Walls wrote: > > On Sun, 2010-02-14 at 16:18 +0100, Hans Verkuil wrote: > > > On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote: > > > > On Friday 12 February 2010 23:36:20 Pete Eberlein wrote: > > > > > On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote: > > > After thinking about this a bit more I decided that this tuner should be > > > split > > > up into two drivers: one for the mpx device and one for the actual tuner. > > > This > > > should be fairly easy to do. > > > > > > One other thing that this accomplishes is that it is easier to see > > > whether the > > > tuner code can actually be merged into tuner-types.c. From what I can see > > > now > > > I would say that that is possible for the NTSC_M and NTSC_M_JP models. The > > > PAL/SECAM model is harder since it needs to setup the tuner whenever the > > > standard changes. But it seems that that is also possible by adding code > > > to simple_std_setup() in tuner-simple.c. > > > > > > I'm pretty sure that these tuners can just be folded into tuner-types.c > > > and tuner-simple.c. We probably only need an mpx driver. > > > > > > Andy, can you also take a look? > > > > Sure. It looks like to me you actually have three chips: > > > > - oscillator/mixer (at address 0x60 like a TUA6030) > > - programmable IF PLL demodulator (at address 0x43 like a TDA9887) > > - MPX demodulator/dematrix IC. > > I've been focusing so much on the IF_I2C_ADDR and MPX_I2C_ADDR defines that > I completely missed the fact that there is also the tuner at 0x60 :-( > > You are completely correct: it looks very much like a standard simple > tuner + tda9887. I should mention that I noticed 1. The IF demodulator seems to programmed with an usual take over point: +8 dB, IIRC. A port into the common tuner stuff should lose track of setting like these. 2. This driver has some funny IF offset "IFPCoff" that is applied when calling set freq. tuner-simple and friends may need slight modifications to handle this requirment for these tuner, but it shouldn't be hard. The trend in tuner-simple has been to add a switch() statement when these sorts of exceptions are needed, as it is most expedient. IMHO, this is a bad trend. I think it would be better to modify the tuner information structures to handle this "IFPCoff" value. Just an opinion... 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
cx23885
Hello Does anybody know whether this card is currently supported and if yes, is it by cx88 or by cx23885? http://www.commell.com.tw/Product/Surveillance/MPX-885.htm It is based on the Connexant 23885 chip but uses an Mini-PCIe interface. Thanks Michael -- 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 v4 2/7] V4L: Events: Add new ioctls for events
Hi Hans,
On Monday 15 February 2010 11:28:52 Hans Verkuil wrote:
> > Hi Hans,
> >
> > On Saturday 13 February 2010 14:19:55 Hans Verkuil wrote:
> >> On Wednesday 10 February 2010 15:58:04 Sakari Ailus wrote:
> >> > This patch adds a set of new ioctls to the V4L2 API. The ioctls
> >>
> >> conform
> >>
> >> > to V4L2 Events RFC version 2.3:
> >> I've experimented with the events API to try and support it with ivtv
> >> and
> >> I realized that it had some problems.
> >>
> >> See comments below.
> >>
> >> > http://www.spinics.net/lists/linux-media/msg12033.html>
> >> >
> >> > Signed-off-by: Sakari Ailus
> >> > ---
> >> >
> >> > drivers/media/video/v4l2-compat-ioctl32.c |3 +++
> >> > drivers/media/video/v4l2-ioctl.c |3 +++
> >> > include/linux/videodev2.h | 23
> >>
> >> +++
> >>
> >> > 3 files changed, 29 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> >> > b/drivers/media/video/v4l2-compat-ioctl32.c index 997975d..cba704c
> >> > 100644
> >> > --- a/drivers/media/video/v4l2-compat-ioctl32.c
> >> > +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> >> > @@ -1077,6 +1077,9 @@ long v4l2_compat_ioctl32(struct file *file,
> >> > unsigned int cmd, unsigned long arg)
> >> >
> >> > case VIDIOC_DBG_G_REGISTER:
> >> > case VIDIOC_DBG_G_CHIP_IDENT:
> >> >
> >> > case VIDIOC_S_HW_FREQ_SEEK:
> >> > +case VIDIOC_DQEVENT:
> >> > +case VIDIOC_SUBSCRIBE_EVENT:
> >> >
> >> > +case VIDIOC_UNSUBSCRIBE_EVENT:
> >> > ret = do_video_ioctl(file, cmd, arg);
> >> > break;
> >> >
> >> > diff --git a/drivers/media/video/v4l2-ioctl.c
> >> > b/drivers/media/video/v4l2-ioctl.c index 30cc334..bfc4696 100644
> >> > --- a/drivers/media/video/v4l2-ioctl.c
> >> > +++ b/drivers/media/video/v4l2-ioctl.c
> >> > @@ -283,6 +283,9 @@ static const char *v4l2_ioctls[] = {
> >> >
> >> > [_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = "VIDIOC_DBG_G_CHIP_IDENT",
> >> > [_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = "VIDIOC_S_HW_FREQ_SEEK",
> >> >
> >> > +[_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
> >> > +[_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
> >> > +[_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] =
> >> > "VIDIOC_UNSUBSCRIBE_EVENT",
> >> >
> >> > #endif
> >> > };
> >> > #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
> >> >
> >> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> >> > index 54af357..a19ae89 100644
> >> > --- a/include/linux/videodev2.h
> >> > +++ b/include/linux/videodev2.h
> >> > @@ -1536,6 +1536,26 @@ struct v4l2_streamparm {
> >> >
> >> > };
> >> >
> >> > /*
> >> >
> >> > + * E V E N T S
> >> > + */
> >> > +
> >> > +struct v4l2_event {
> >> > +__u32 count;
> >>
> >> The name 'count' is confusing. Count of what? I think the name 'pending'
> >> might be more understandable. A comment after the definition would also
> >> help.
> >>
> >> > +__u32 type;
> >> > +__u32 sequence;
> >> > +struct timespec timestamp;
> >> > +__u32 reserved[9];
> >> > +__u8data[64];
> >> > +};
> >>
> >> I also think we should reorder the fields and add a union. For ivtv I
> >> would
> >> need this:
> >>
> >> #define V4L2_EVENT_ALL 0
> >> #define V4L2_EVENT_VSYNC1
> >> #define V4L2_EVENT_EOS 2
> >> #define V4L2_EVENT_PRIVATE_START0x0800
> >>
> >> /* Payload for V4L2_EVENT_VSYNC */
> >> struct v4l2_event_vsync {
> >>
> >> /* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */
> >> u8 field;
> >>
> >> } __attribute__ ((packed));
> >>
> >> struct v4l2_event {
> >>
> >> __u32 type;
> >> union {
> >>
> >> struct v4l2_event_vsync vsync;
> >> __u8data[64];
> >>
> >> } u;
> >> __u32 sequence;
> >> struct timespec timestamp;
> >> __u32 pending;
> >> __u32 reserved[9];
> >>
> >> };
> >>
> >> The reason for rearranging the fields has to do with the fact that the
> >> first two fields (type and the union) form the actual event data. The
> >> others are more for administrative purposes. Separating those two makes
> >> sense to me.
> >>
> >> So when I define an event for queuing it is nice if I can do just this:
> >>
> >> static const struct v4l2_event ev_top = {
> >>
> >>.type = V4L2_EVENT_VSYNC,
> >>.u.vsync.field = V4L2_FIELD_TOP,
> >>
> >> };
> >>
> >> I would have preferred to have an anonymous union. Unfortunately gcc has
> >> problems with initializers for fields inside an anonymous union. Hence
> >> the need for a named union.
> >
> > Will all drivers add private events to the union ? This would then soon
> > b
Re: [PATCH v4 4/7] V4L: Events: Support event handling in do_ioctl
> On Saturday 13 February 2010 14:49:31 Hans Verkuil wrote:
>> On Wednesday 10 February 2010 15:58:06 Sakari Ailus wrote:
>> > Add support for event handling to do_ioctl.
>> >
>> > Signed-off-by: Sakari Ailus
>> > ---
>> >
>> > drivers/media/video/Makefile |2 +-
>> > drivers/media/video/v4l2-ioctl.c | 49
>> > ++ include/media/v4l2-ioctl.h
>> > |5
>> > 3 files changed, 55 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/drivers/media/video/Makefile
>> b/drivers/media/video/Makefile
>> > index b888ad1..68253d6 100644
>> > --- a/drivers/media/video/Makefile
>> > +++ b/drivers/media/video/Makefile
>> > @@ -11,7 +11,7 @@ stkwebcam-objs := stk-webcam.o stk-sensor.o
>> >
>> > omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
>> >
>> > videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
>> > v4l2-subdev.o
>> \
>> >
>> > - v4l2-fh.o
>> > + v4l2-fh.o v4l2-event.o
>> >
>> > # V4L2 core modules
>> >
>> > diff --git a/drivers/media/video/v4l2-ioctl.c
>> > b/drivers/media/video/v4l2-ioctl.c index bfc4696..e0b9401 100644
>> > --- a/drivers/media/video/v4l2-ioctl.c
>> > +++ b/drivers/media/video/v4l2-ioctl.c
>> > @@ -25,6 +25,7 @@
>> >
>> > #endif
>> > #include
>> > #include
>> >
>> > +#include
>> >
>> > #include
>> >
>> > #define dbgarg(cmd, fmt, arg...) \
>> >
>> > @@ -1797,7 +1798,55 @@ static long __video_do_ioctl(struct file *file,
>> >
>> >}
>> >break;
>> >
>> >}
>> >
>> > + case VIDIOC_DQEVENT:
>> > + {
>> > + struct v4l2_event *ev = arg;
>> > +
>> > + if (!ops->vidioc_subscribe_event)
>> > + break;
>> > +
>> > + ret = v4l2_event_dequeue(fh, ev);
>> > + if (ret < 0) {
>> > + dbgarg(cmd, "no pending events?");
>> > + break;
>> > + }
>> > + dbgarg(cmd,
>> > + "count=%d, type=0x%8.8x, sequence=%d, "
>> > + "timestamp=%lu.%9.9lu ",
>> > + ev->count, ev->type, ev->sequence,
>> > + ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
>> > + break;
>> > + }
>> > + case VIDIOC_SUBSCRIBE_EVENT:
>> > + {
>> > + struct v4l2_event_subscription *sub = arg;
>> >
>> > + if (!ops->vidioc_subscribe_event)
>> > + break;
>>
>> I know I said that we could use this test to determine if fh is of type
>> v4l2_fh, but that only works in this specific case, but not in the
>> general
>> case. For example, I want to add support for the prio ioctls to v4l2_fh,
>> and then I probably have no vidioc_subscribe_event set since few drivers
>> will need that.
>>
>> Instead I suggest that we add a new flag to v4l2-dev.h:
>>
>> V4L2_FL_USES_V4L2_FH (1)
>>
>> The v4l2_fh_add() function can then set this flag.
>>
>> > +
>> > + ret = ops->vidioc_subscribe_event(fh, sub);
>> > + if (ret < 0) {
>> > + dbgarg(cmd, "failed, ret=%ld", ret);
>> > + break;
>> > + }
>> > + dbgarg(cmd, "type=0x%8.8x", sub->type);
>> > + break;
>> > + }
>> > + case VIDIOC_UNSUBSCRIBE_EVENT:
>> > + {
>> > + struct v4l2_event_subscription *sub = arg;
>> > +
>> > + if (!ops->vidioc_subscribe_event)
>> > + break;
>> > +
>> > + ret = v4l2_event_unsubscribe(fh, sub);
>>
>> We should add an unsubscribe op as well. One reason is to add EVENT_ALL
>> support (see my comments in patch 7/7), the other is that in some cases
>> drivers might need to take some special action in response to
>> subscribing
>> an event. And a driver needs a way to undo that when unsubscribing.
>
> Agreed. Should we allow drivers not to define the unsubscribe operation
> when
> they don't need it ? In that case v4l2_event_unsubscribe should be called
> in
> VIDIOC_UNSUBSCRIBE_EVENT, outside of the operation handler.
Drivers can just use v4l2_event_unsubscribe directly as the ioctl op.
>
> Similarly, shouldn't v4l2_event_subscribe be called in
> VIDIOC_SUBSCRIBE_EVENT,
> outside of the operation handler ?
It can be done, but I am no fan of hiding such things in the core. It's
just a single function, after all.
Regards,
Hans
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 v4 7/7] V4L: Events: Support all events
> Hi Hans,
>
> On Saturday 13 February 2010 15:42:20 Hans Verkuil wrote:
>> On Wednesday 10 February 2010 15:58:09 Sakari Ailus wrote:
>> > Add support for subscribing all events with a special id
>> V4L2_EVENT_ALL.
>> > If V4L2_EVENT_ALL is subscribed, no other events may be subscribed.
>> > Otherwise V4L2_EVENT_ALL is considered just as any other event.
>>
>> We should do this differently. I think that EVENT_ALL should not be used
>> internally (i.e. in the actual list of subscribed events), but just as a
>> special value for the subscribe and unsubscribe ioctls. So when used
>> with
>> unsubscribe you can just unsubscribe all subscribed events and when used
>> with subscribe, then you just subscribe all valid events (valid for that
>> device node).
>>
>> So in v4l2-event.c you will have a v4l2_event_unsubscribe_all() to
>> quickly
>> unsubscribe all events.
>>
>> In order to easily add all events from the driver it would help if the
>> v4l2_event_subscribe and v4l2_event_unsubscribe just take the event type
>> as argument rather than the whole v4l2_event_subscription struct.
>>
>> You will then get something like this in the driver:
>>
>> if (sub->type == V4L2_EVENT_ALL) {
>> int ret = v4l2_event_alloc(fh, 60);
>>
>> ret = ret ? ret : v4l2_event_subscribe(fh, V4L2_EVENT_EOS);
>> ret = ret ? ret : v4l2_event_subscribe(fh, V4L2_EVENT_VSYNC);
>> return ret;
>> }
>>
>> An alternative might be to add a v4l2_event_subscribe_all(fh, const u32
>> *events) where 'events' is a 0 terminated list of events that need to be
>> subscribed.
>
> Then don't call it v4l2_event_subscribe_all if it only subscribes to a set
> of
> event :-)
>
>> For each event this function would then call:
>>
>> fh->vdev->ioctl_ops->vidioc_subscribe_event(fh, sub);
>>
>> The nice thing about that is that in the driver you have a minimum of
>> fuss.
>>
>> I'm leaning towards this second solution due to the simple driver
>> implementation.
>>
>> Handling EVENT_ALL will simplify things substantially IMHO.
>
> I'm wondering if subscribing to all events should be allowed. Do we have
> use
> cases for that ? I'm always a bit cautious when adding APIs with no users,
> as
> that means the API has often not been properly tested against possible use
> cases and mistakes will need to be supported forever (or at least for a
> long
> time).
I think that is a good point. Supporting V4L2_EVENT_ALL makes sense for
unsubscribe, but does it makes sense for subscribe as well? I think it
does not. It just doesn't feel right when I tried to implement it in ivtv.
I also wonder whether the unsubscribe API shouldn't just receive the event
type instead of the big subscription struct. Or get its own struct. I
don't think it makes much sense that they both have the same struct.
Regards,
Hans
>
> --
> Regards,
>
> Laurent Pinchart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 v4 2/7] V4L: Events: Add new ioctls for events
> Hi Hans,
>
> On Saturday 13 February 2010 14:19:55 Hans Verkuil wrote:
>> On Wednesday 10 February 2010 15:58:04 Sakari Ailus wrote:
>> > This patch adds a set of new ioctls to the V4L2 API. The ioctls
>> conform
>> > to V4L2 Events RFC version 2.3:
>> I've experimented with the events API to try and support it with ivtv
>> and
>> I realized that it had some problems.
>>
>> See comments below.
>>
>> > http://www.spinics.net/lists/linux-media/msg12033.html>
>> >
>> > Signed-off-by: Sakari Ailus
>> > ---
>> >
>> > drivers/media/video/v4l2-compat-ioctl32.c |3 +++
>> > drivers/media/video/v4l2-ioctl.c |3 +++
>> > include/linux/videodev2.h | 23
>> +++
>> > 3 files changed, 29 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
>> > b/drivers/media/video/v4l2-compat-ioctl32.c index 997975d..cba704c
>> > 100644
>> > --- a/drivers/media/video/v4l2-compat-ioctl32.c
>> > +++ b/drivers/media/video/v4l2-compat-ioctl32.c
>> > @@ -1077,6 +1077,9 @@ long v4l2_compat_ioctl32(struct file *file,
>> > unsigned int cmd, unsigned long arg)
>> >
>> >case VIDIOC_DBG_G_REGISTER:
>> >case VIDIOC_DBG_G_CHIP_IDENT:
>> >
>> >case VIDIOC_S_HW_FREQ_SEEK:
>> > + case VIDIOC_DQEVENT:
>> > + case VIDIOC_SUBSCRIBE_EVENT:
>> >
>> > + case VIDIOC_UNSUBSCRIBE_EVENT:
>> >ret = do_video_ioctl(file, cmd, arg);
>> >break;
>> >
>> > diff --git a/drivers/media/video/v4l2-ioctl.c
>> > b/drivers/media/video/v4l2-ioctl.c index 30cc334..bfc4696 100644
>> > --- a/drivers/media/video/v4l2-ioctl.c
>> > +++ b/drivers/media/video/v4l2-ioctl.c
>> > @@ -283,6 +283,9 @@ static const char *v4l2_ioctls[] = {
>> >
>> >[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = "VIDIOC_DBG_G_CHIP_IDENT",
>> >[_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = "VIDIOC_S_HW_FREQ_SEEK",
>> >
>> > + [_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
>> > + [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
>> > + [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
>> >
>> > #endif
>> > };
>> > #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
>> >
>> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
>> > index 54af357..a19ae89 100644
>> > --- a/include/linux/videodev2.h
>> > +++ b/include/linux/videodev2.h
>> > @@ -1536,6 +1536,26 @@ struct v4l2_streamparm {
>> >
>> > };
>> >
>> > /*
>> >
>> > + *E V E N T S
>> > + */
>> > +
>> > +struct v4l2_event {
>> > + __u32 count;
>>
>> The name 'count' is confusing. Count of what? I think the name 'pending'
>> might be more understandable. A comment after the definition would also
>> help.
>>
>> > + __u32 type;
>> > + __u32 sequence;
>> > + struct timespec timestamp;
>> > + __u32 reserved[9];
>> > + __u8data[64];
>> > +};
>>
>> I also think we should reorder the fields and add a union. For ivtv I
>> would
>> need this:
>>
>> #define V4L2_EVENT_ALL 0
>> #define V4L2_EVENT_VSYNC1
>> #define V4L2_EVENT_EOS 2
>> #define V4L2_EVENT_PRIVATE_START0x0800
>>
>> /* Payload for V4L2_EVENT_VSYNC */
>> struct v4l2_event_vsync {
>> /* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */
>> u8 field;
>> } __attribute__ ((packed));
>>
>> struct v4l2_event {
>> __u32 type;
>> union {
>> struct v4l2_event_vsync vsync;
>> __u8data[64];
>> } u;
>> __u32 sequence;
>> struct timespec timestamp;
>> __u32 pending;
>> __u32 reserved[9];
>> };
>>
>> The reason for rearranging the fields has to do with the fact that the
>> first two fields (type and the union) form the actual event data. The
>> others are more for administrative purposes. Separating those two makes
>> sense to me.
>>
>> So when I define an event for queuing it is nice if I can do just this:
>>
>> static const struct v4l2_event ev_top = {
>> .type = V4L2_EVENT_VSYNC,
>> .u.vsync.field = V4L2_FIELD_TOP,
>> };
>>
>> I would have preferred to have an anonymous union. Unfortunately gcc has
>> problems with initializers for fields inside an anonymous union. Hence
>> the
>> need for a named union.
>
> Will all drivers add private events to the union ? This would then soon
> become
> a mess. Wouldn't it be better for drivers to define their own event
> structures
> (standard ones could be shared between drivers in videodev2.h) and cast
> the
> pointer to data to a pointer to the appropriate event structure ?
I would prefer to have the actual event type defines in videodev2.h (just
as we do for private control IDs). The actual payload structure can be
defined elsewhere as far as I am concerned.
An alternative in the long run might be to split off the event structs
into a separate public header. I have been thinking along th
Re: Proposal for a V4L2 Media Controller mini-summit
Hans Verkuil wrote: > Hi all, > > During the Linux Plumbers Conference in September 2009 I organized a V4L-DVB > mini-summit. The focus of that summit was on discussing a framework through > which we could support all the functionality that the video hardware of modern > embedded devices provides. > > It was a very successful summit and a lot of work has been done since that > time. See this posting for to get an idea of what was discussed for those > who were not present: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg10136.html > > Since that time we have added a new API to support HDTV formats, a new > event API is almost ready, a lot of work is being done on the media > controller API with omap3 as guinea pig and Samsung has done work on the > memory handling of V4L2. > > From April 12th to 14th the CELF Embedded Linux Conference is held in > San Francisco, and it is co-located with the Linux Foundation Collaboration > Summit (April 14th-16th). Links to these conferences are here: > > http://www.embeddedlinuxconference.com/elc_2010/index.html > http://events.linuxfoundation.org/events/collaboration-summit > > I will be doing a presentation on the new framework during the ELC. > > Since this conference is about 6 months after the mini-summit I consider this > a good time to organize a new V4L2 Media Controller mini-summit to discuss > progress and future work in this area. I think that particular attention > should be given to how we are going to do memory handling. The proposals > from Samsung have received very little attention and we should discuss those > in more detail. > > I do not know on which dates exactly such a summit can take place. There > are three possibilities: > > April 10-11/12 > April 12-14 > April 14/15-16 > > I think that registering for the ELC gives to free access to the Collaboration > Summit, but I'm waiting for a confirmation on that. > > I'm not keen on the center option (12-14 April) since that often means that > you don't see a lot of the conference itself. And the ELC is generally quite > interesting. > > There is another alternative and that is that I organize a mini-summit in May > in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think > that it is more fun to do this during/before/after a conference. If only > because there are a lot of linux kernel experts on hand during such a > conference that you can ask for help if needed. > > Please let me know asap if you are interested in attending such a mini-summit > and what dates are possible for you: > > a: April 10-11 (or 12) > b: April 12-14 > c: April 14 (or 15)-16 > d: Somewhere in May (suggestions for dates are welcome) Hi Hans & others, We at Nokia are very interested indeed in having a mini-summit! The one in the Linux Plumbers Conference was very useful and I've been looking forward for the next one awhile. :-) However, I can't personally commit to any of these dates in April yet. Option D would be more certain for me. I will know more in a few days. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 v4 7/7] V4L: Events: Support all events
Hi Hans,
On Saturday 13 February 2010 15:42:20 Hans Verkuil wrote:
> On Wednesday 10 February 2010 15:58:09 Sakari Ailus wrote:
> > Add support for subscribing all events with a special id V4L2_EVENT_ALL.
> > If V4L2_EVENT_ALL is subscribed, no other events may be subscribed.
> > Otherwise V4L2_EVENT_ALL is considered just as any other event.
>
> We should do this differently. I think that EVENT_ALL should not be used
> internally (i.e. in the actual list of subscribed events), but just as a
> special value for the subscribe and unsubscribe ioctls. So when used with
> unsubscribe you can just unsubscribe all subscribed events and when used
> with subscribe, then you just subscribe all valid events (valid for that
> device node).
>
> So in v4l2-event.c you will have a v4l2_event_unsubscribe_all() to quickly
> unsubscribe all events.
>
> In order to easily add all events from the driver it would help if the
> v4l2_event_subscribe and v4l2_event_unsubscribe just take the event type
> as argument rather than the whole v4l2_event_subscription struct.
>
> You will then get something like this in the driver:
>
> if (sub->type == V4L2_EVENT_ALL) {
> int ret = v4l2_event_alloc(fh, 60);
>
> ret = ret ? ret : v4l2_event_subscribe(fh, V4L2_EVENT_EOS);
> ret = ret ? ret : v4l2_event_subscribe(fh, V4L2_EVENT_VSYNC);
> return ret;
> }
>
> An alternative might be to add a v4l2_event_subscribe_all(fh, const u32
> *events) where 'events' is a 0 terminated list of events that need to be
> subscribed.
Then don't call it v4l2_event_subscribe_all if it only subscribes to a set of
event :-)
> For each event this function would then call:
>
> fh->vdev->ioctl_ops->vidioc_subscribe_event(fh, sub);
>
> The nice thing about that is that in the driver you have a minimum of fuss.
>
> I'm leaning towards this second solution due to the simple driver
> implementation.
>
> Handling EVENT_ALL will simplify things substantially IMHO.
I'm wondering if subscribing to all events should be allowed. Do we have use
cases for that ? I'm always a bit cautious when adding APIs with no users, as
that means the API has often not been properly tested against possible use
cases and mistakes will need to be supported forever (or at least for a long
time).
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/7] V4L: Events: Support event handling in do_ioctl
On Saturday 13 February 2010 14:49:31 Hans Verkuil wrote:
> On Wednesday 10 February 2010 15:58:06 Sakari Ailus wrote:
> > Add support for event handling to do_ioctl.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> >
> > drivers/media/video/Makefile |2 +-
> > drivers/media/video/v4l2-ioctl.c | 49
> > ++ include/media/v4l2-ioctl.h
> > |5
> > 3 files changed, 55 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> > index b888ad1..68253d6 100644
> > --- a/drivers/media/video/Makefile
> > +++ b/drivers/media/video/Makefile
> > @@ -11,7 +11,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
> >
> > omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
> >
> > videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
> > v4l2-subdev.o \
> >
> > - v4l2-fh.o
> > + v4l2-fh.o v4l2-event.o
> >
> > # V4L2 core modules
> >
> > diff --git a/drivers/media/video/v4l2-ioctl.c
> > b/drivers/media/video/v4l2-ioctl.c index bfc4696..e0b9401 100644
> > --- a/drivers/media/video/v4l2-ioctl.c
> > +++ b/drivers/media/video/v4l2-ioctl.c
> > @@ -25,6 +25,7 @@
> >
> > #endif
> > #include
> > #include
> >
> > +#include
> >
> > #include
> >
> > #define dbgarg(cmd, fmt, arg...) \
> >
> > @@ -1797,7 +1798,55 @@ static long __video_do_ioctl(struct file *file,
> >
> > }
> > break;
> >
> > }
> >
> > + case VIDIOC_DQEVENT:
> > + {
> > + struct v4l2_event *ev = arg;
> > +
> > + if (!ops->vidioc_subscribe_event)
> > + break;
> > +
> > + ret = v4l2_event_dequeue(fh, ev);
> > + if (ret < 0) {
> > + dbgarg(cmd, "no pending events?");
> > + break;
> > + }
> > + dbgarg(cmd,
> > + "count=%d, type=0x%8.8x, sequence=%d, "
> > + "timestamp=%lu.%9.9lu ",
> > + ev->count, ev->type, ev->sequence,
> > + ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
> > + break;
> > + }
> > + case VIDIOC_SUBSCRIBE_EVENT:
> > + {
> > + struct v4l2_event_subscription *sub = arg;
> >
> > + if (!ops->vidioc_subscribe_event)
> > + break;
>
> I know I said that we could use this test to determine if fh is of type
> v4l2_fh, but that only works in this specific case, but not in the general
> case. For example, I want to add support for the prio ioctls to v4l2_fh,
> and then I probably have no vidioc_subscribe_event set since few drivers
> will need that.
>
> Instead I suggest that we add a new flag to v4l2-dev.h:
>
> V4L2_FL_USES_V4L2_FH (1)
>
> The v4l2_fh_add() function can then set this flag.
>
> > +
> > + ret = ops->vidioc_subscribe_event(fh, sub);
> > + if (ret < 0) {
> > + dbgarg(cmd, "failed, ret=%ld", ret);
> > + break;
> > + }
> > + dbgarg(cmd, "type=0x%8.8x", sub->type);
> > + break;
> > + }
> > + case VIDIOC_UNSUBSCRIBE_EVENT:
> > + {
> > + struct v4l2_event_subscription *sub = arg;
> > +
> > + if (!ops->vidioc_subscribe_event)
> > + break;
> > +
> > + ret = v4l2_event_unsubscribe(fh, sub);
>
> We should add an unsubscribe op as well. One reason is to add EVENT_ALL
> support (see my comments in patch 7/7), the other is that in some cases
> drivers might need to take some special action in response to subscribing
> an event. And a driver needs a way to undo that when unsubscribing.
Agreed. Should we allow drivers not to define the unsubscribe operation when
they don't need it ? In that case v4l2_event_unsubscribe should be called in
VIDIOC_UNSUBSCRIBE_EVENT, outside of the operation handler.
Similarly, shouldn't v4l2_event_subscribe be called in VIDIOC_SUBSCRIBE_EVENT,
outside of the operation handler ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] V4L: Events: Add new ioctls for events
Hi Hans,
On Saturday 13 February 2010 14:19:55 Hans Verkuil wrote:
> On Wednesday 10 February 2010 15:58:04 Sakari Ailus wrote:
> > This patch adds a set of new ioctls to the V4L2 API. The ioctls conform
> > to V4L2 Events RFC version 2.3:
> I've experimented with the events API to try and support it with ivtv and
> I realized that it had some problems.
>
> See comments below.
>
> > http://www.spinics.net/lists/linux-media/msg12033.html>
> >
> > Signed-off-by: Sakari Ailus
> > ---
> >
> > drivers/media/video/v4l2-compat-ioctl32.c |3 +++
> > drivers/media/video/v4l2-ioctl.c |3 +++
> > include/linux/videodev2.h | 23 +++
> > 3 files changed, 29 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> > b/drivers/media/video/v4l2-compat-ioctl32.c index 997975d..cba704c
> > 100644
> > --- a/drivers/media/video/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> > @@ -1077,6 +1077,9 @@ long v4l2_compat_ioctl32(struct file *file,
> > unsigned int cmd, unsigned long arg)
> >
> > case VIDIOC_DBG_G_REGISTER:
> > case VIDIOC_DBG_G_CHIP_IDENT:
> >
> > case VIDIOC_S_HW_FREQ_SEEK:
> > + case VIDIOC_DQEVENT:
> > + case VIDIOC_SUBSCRIBE_EVENT:
> >
> > + case VIDIOC_UNSUBSCRIBE_EVENT:
> > ret = do_video_ioctl(file, cmd, arg);
> > break;
> >
> > diff --git a/drivers/media/video/v4l2-ioctl.c
> > b/drivers/media/video/v4l2-ioctl.c index 30cc334..bfc4696 100644
> > --- a/drivers/media/video/v4l2-ioctl.c
> > +++ b/drivers/media/video/v4l2-ioctl.c
> > @@ -283,6 +283,9 @@ static const char *v4l2_ioctls[] = {
> >
> > [_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = "VIDIOC_DBG_G_CHIP_IDENT",
> > [_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = "VIDIOC_S_HW_FREQ_SEEK",
> >
> > + [_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
> > + [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
> > + [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
> >
> > #endif
> > };
> > #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
> >
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 54af357..a19ae89 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -1536,6 +1536,26 @@ struct v4l2_streamparm {
> >
> > };
> >
> > /*
> >
> > + * E V E N T S
> > + */
> > +
> > +struct v4l2_event {
> > + __u32 count;
>
> The name 'count' is confusing. Count of what? I think the name 'pending'
> might be more understandable. A comment after the definition would also
> help.
>
> > + __u32 type;
> > + __u32 sequence;
> > + struct timespec timestamp;
> > + __u32 reserved[9];
> > + __u8data[64];
> > +};
>
> I also think we should reorder the fields and add a union. For ivtv I would
> need this:
>
> #define V4L2_EVENT_ALL 0
> #define V4L2_EVENT_VSYNC1
> #define V4L2_EVENT_EOS 2
> #define V4L2_EVENT_PRIVATE_START0x0800
>
> /* Payload for V4L2_EVENT_VSYNC */
> struct v4l2_event_vsync {
> /* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */
> u8 field;
> } __attribute__ ((packed));
>
> struct v4l2_event {
> __u32 type;
> union {
> struct v4l2_event_vsync vsync;
> __u8data[64];
> } u;
> __u32 sequence;
> struct timespec timestamp;
> __u32 pending;
> __u32 reserved[9];
> };
>
> The reason for rearranging the fields has to do with the fact that the
> first two fields (type and the union) form the actual event data. The
> others are more for administrative purposes. Separating those two makes
> sense to me.
>
> So when I define an event for queuing it is nice if I can do just this:
>
> static const struct v4l2_event ev_top = {
> .type = V4L2_EVENT_VSYNC,
> .u.vsync.field = V4L2_FIELD_TOP,
> };
>
> I would have preferred to have an anonymous union. Unfortunately gcc has
> problems with initializers for fields inside an anonymous union. Hence the
> need for a named union.
Will all drivers add private events to the union ? This would then soon become
a mess. Wouldn't it be better for drivers to define their own event structures
(standard ones could be shared between drivers in videodev2.h) and cast the
pointer to data to a pointer to the appropriate event structure ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] hg: pixel format documentation
Hi Mauro I presume, since this patch touches a file outside of linux directory, it has to go via hg, so, here goes: Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following changeset: 01/01: v4l: document new Bayer and monochrome pixel formats http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a22bca56b96c b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 +++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 ++ b/linux/Documentation/DocBook/v4l/pixfmt-y10.xml | 79 linux/Documentation/DocBook/v4l/pixfmt.xml |3 linux/Documentation/DocBook/v4l/videodev2.h.xml | 11 +- media-specs/Makefile |3 6 files changed, 251 insertions(+), 2 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
