Re: [PATCH v1 1/4] DM365 Platform support for VPFE
neilsi...@ti.com writes:
> From: Neil Sikka
>
> This has platform and board setup changes to support the vpfe capture
> driver for DM365 EVMs.
>
> Reviewed-by: Muralidharan Karicheri
> Mandatory-Reviewer: Hans Verkuil
> Mandatory-Reviewer: Kevin Hilman
> Signed-off-by: Neil Sikka
Signed-off-by: Kevin Hilman
for this patch, but the rest of the series needs to be reviewed by linux-media
folks.
Kevin
> ---
> Applies to Kevin Hilman's linux-davinci repository
> arch/arm/mach-davinci/board-dm365-evm.c| 71
>
> arch/arm/mach-davinci/dm365.c | 68 ++
> arch/arm/mach-davinci/include/mach/dm365.h |2 +
> 3 files changed, 141 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
> b/arch/arm/mach-davinci/board-dm365-evm.c
> index f6adf79..757ad13 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -38,6 +38,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
>
> static inline int have_imager(void)
> @@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
>
> static void __iomem *cpld;
>
> +static struct tvp514x_platform_data tvp5146_pdata = {
> + .clk_polarity = 0,
> + .hs_polarity = 1,
> + .vs_polarity = 1
> +};
>
> /* NOTE: this is geared for the standard config, with a socketed
> * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
> @@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
> return !!(__raw_readb(cpld + CPLD_CARDSTAT) & BIT(module ? 5 : 1));
> }
>
> +#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
> +/* Inputs available at the TVP5146 */
> +static struct v4l2_input tvp5146_inputs[] = {
> + {
> + .index = 0,
> + .name = "Composite",
> + .type = V4L2_INPUT_TYPE_CAMERA,
> + .std = TVP514X_STD_ALL,
> + },
> + {
> + .index = 1,
> + .name = "S-Video",
> + .type = V4L2_INPUT_TYPE_CAMERA,
> + .std = TVP514X_STD_ALL,
> + },
> +};
> +
> +/*
> + * this is the route info for connecting each input to decoder
> + * ouput that goes to vpfe. There is a one to one correspondence
> + * with tvp5146_inputs
> + */
> +static struct vpfe_route tvp5146_routes[] = {
> + {
> + .input = INPUT_CVBS_VI2B,
> + .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
> + },
> +{
> + .input = INPUT_SVIDEO_VI2C_VI1C,
> + .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
> + },
> +};
> +
> +static struct vpfe_subdev_info vpfe_sub_devs[] = {
> +{
> + .module_name = "tvp5146",
> + .grp_id = 0,
> + .num_inputs = ARRAY_SIZE(tvp5146_inputs),
> + .inputs = tvp5146_inputs,
> + .routes = tvp5146_routes,
> + .can_route = 1,
> + .ccdc_if_params = {
> + .if_type = VPFE_BT656,
> + .hdpol = VPFE_PINPOL_POSITIVE,
> + .vdpol = VPFE_PINPOL_POSITIVE,
> + },
> + .board_info = {
> + I2C_BOARD_INFO("tvp5146", 0x5d),
> + .platform_data = &tvp5146_pdata,
> + },
> + }
> +};
> +
> +static struct vpfe_config vpfe_cfg = {
> + .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
> + .sub_devs = vpfe_sub_devs,
> + .card_name = "DM365 EVM",
> + .ccdc = "DM365 ISIF",
> + .num_clocks = 1,
> + .clocks = {"vpss_master"},
> +};
> +
> static struct davinci_mmc_config dm365evm_mmc_config = {
> .get_cd = cpld_mmc_get_cd,
> .get_ro = cpld_mmc_get_ro,
> @@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata
> = {
>
> static void __init dm365_evm_map_io(void)
> {
> + /* setup input configuration for VPFE input devices */
> + dm365_set_vpfe_config(&vpfe_cfg);
> dm365_init();
> }
>
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index f8bac94..aa432d4 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -904,6 +904,62 @@ void __init dm365_init(void)
> davinci_common_init(&davinci_soc_info_dm365);
> }
>
> +static struct resource dm365_vpss_resources[] = {
> + {
> + /* VPSS ISP5 Base address */
> + .name = "vpss",
> + .start = 0x01c7,
> + .end= 0x01c7 + 0xff,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + /* VPSS CLK Base address */
> + .name = "vpss",
> + .start = 0x01c70200,
> + .end= 0x01c70200 + 0xff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device dm365_vpss_device = {
> + .name = "vpss
Re: em28xx DVB modeswitching change: call for testers
Devin Heitmueller ha scritto: Hello all, I have setup a tree that removes the mode switching code when starting/stopping streaming. If you have one of the em28xx dvb devices mentioned in the previous thread and volunteered to test, please try out the following tree: http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch In particular, this should work for those of you who reported problems with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were using that one line change I sent this week. It should also work with Antti's Reddo board without needing his patch to move the demod reset into the tuner_gpio. This also brings us one more step forward to setting up the locking properly so that applications cannot simultaneously open the analog and dvb side of the device. Thanks for your help, Devin Hi Devin, excuse my late, but I've done some test. The scanning now work correctly and without problem, all MUX was tuned and channel recognized. With mplayer no problem, for a new channel I must stop the actual channel viewing and start a new one instance of mplayer. I've a problem with kaffeine, and this problem before was not present (I've not tested with the previous temporary patch). To reproduce the problem, is necessary a channel change, and the two channel must be on a different MUX: the first double click on new channel name display an "Impossible to tune", if I do a new double click the channel was opened. Is like the adapter was resetted, but not reinitialized on new frequency. Logically the problem not appears if I stop the transmission between the channel change or if I change channel that are located on the same MUX. I hope to have explained well the thing. Thanks and bye, Sebastian -- 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: Request driver for cards
Hi Theunis, Am Donnerstag, den 15.10.2009, 11:25 +0200 schrieb Theunis Potgieter: > On 14/10/2009, Theunis Potgieter wrote: > > Hi, what is the procedure to request drivers for specific new, perhaps > > unknown supported cards? > > > > I did have a look at http://www.linuxtv.org/wiki/index.php/Main_Page > > but it didn't contain any information about supported cards. Neither > > did 2.6.30 /usr/src/linux/Documentation/dvb/cards.txt for the > > following brands: > > > > name, site: > > Compro, S300 http://www.comprousa.com/en/product/s300/s300.html > > K-World VS-DVB-S 100/IS, > > > > http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248&modid=6&pcid=46&ifid=16&prodid=98 > > > > Perhaps I shouldn't waste time if I could find a dual/twin tuner card > > for dvb-s or dvb-s2. Are there any recommended twin-tuner pci-e cards > > that is support and can actually be bought by the average consumer? > > > > Thanks > > > I guess this answers the Kworld on 2.6.30: > > /usr/src/linux/drivers/media/dvb/frontends/cx24123.c: * Support for > KWorld DVB-S 100 by Vadim Catana > > But how would I get compro S300 support? > > Is there anybody that knows of a work inprogress or completed twin > tuner type card in either pci or pci-e format? > > Thanks in advance. for the saa7134 driver, the Compro S300 is not a twin DVB-S tuner card. The second RF connector is only RF loop through. The card has support as card=169 with recent code. On saa7134 only the Creatix CTX944 (Medion Quad, card=96 www.creatix.de) has beside two DVB-T/analog hybrid tuners also two DVB-S tuners. S2 is not supported and one of the DVB-S tuners has only support for transponders with 18 Volt currently. This was a problem on prior Philips windows drivers too, but is now fixed there. Maybe we can fix it once too. The second part of the twin LNB supply is not connected to i2c. The voltage must be switched by some gpio pin. Main problems, the card is Medion OEM only, on ebay and similar between 20 - 70€, and one needs a MSI/Medion motherboard with blue or green multi bus master capable PCI slot. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible bug on libv4l read() emulation
I have a program where I use libv4l's read() emulation for simplicity. But with most v4l2 webcams I've tried, I get kernel panics. I have pics of the message if anyone cares to see them, I don't want to flood the mailing list. Basically, the names I see in the kernel panic from a uvcvideo card is: uvc_queue_next_buffer __bad_area_no_semaphore do_page_fault And a lot more. TIA. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Video events, version 2
On Thursday 15 October 2009 23:11:33 Laurent Pinchart wrote:
> Hi Sakari,
>
> On Wednesday 14 October 2009 19:48:33 Hans Verkuil wrote:
> > On Wednesday 14 October 2009 15:02:14 Sakari Ailus wrote:
> > > Here's the second version of the video events RFC. It's based on Laurent
> > > Pinchart's original RFC. My aim is to address the issues found in the
> > > old RFC during the V4L-DVB mini-summit in the Linux plumbers conference
> > > 2009. To get a good grasp of the problem at hand it's probably a good
> > > idea read the original RFC as well:
> > >
> > > http://www.spinics.net/lists/linux-media/msg10217.html>
>
> Thanks for the RFC update.
>
> > > Changes to version 1
> > > --
> > >
> > > struct video_event has been renamed to v4l2_event. The struct is used in
> > > userspace and V4L related structures appear to have v4l2 prefix so that
> > > should be better than video.
>
> In the end we will probably rename that to media_ or something similar in the
> big media controller rename (if that ever happens). For now let's keep v4l2_,
> that will be more consistent.
>
> > > The "entity" field has been removed from the struct v4l2_event since the
> > > subdevices will have their own device nodes --- the events should come
> > > from them instead of the media controller. Video nodes could be used for
> > > events, too.
>
> I would still keep the entity field. It would allow for parents to report
> children events and there could be use cases for that.
We can always convert one of the reserved fields to an entity field in the
future. Adding support in the new API for an even newer and as yet highly
experimental API is not a good idea.
> > > A few reserved fields have been added. There are new ioctls as well for
> > > enumeration and (un)subscribing.
> > >
> > >
> > > Interface description
> > > -
> > >
> > > Event type is either a standard event or private event. Standard events
> > > will be defined in videodev2.h. Private event types begin from
> > > V4L2_EVENT_PRIVATE. Some high order bits could be reserved for future
> > > use.
> > >
> > > #define V4L2_EVENT_PRIVATE_START 0x0800
> > > #define V4L2_EVENT_RESERVED 0x1000
> >
> > Suggestion: use the V4L2_EV_ prefix perhaps instead of the longer
> > V4L2_EVENT?
>
> EV could be confused with electron volt, exposure value, or even escape
> velocity (don't underestimate the use of V4L2 in the spaceship market ;-)).
> On
> a more serious note, while I like to keep identifiers short, is the 3
> characters gain worth it here ?
>
> > > VIDIOC_ENUM_EVENT is used to enumerate the available event types. It
> > > works a bit the same way than VIDIOC_ENUM_FMT i.e. you get the next
> > > event type by calling it with the last type in the type field. The
> > > difference is that the range is not continuous like in querying controls.
> >
> > Question: why do we need an ENUM_EVENT? I don't really see a use-case for
> > this.
> >
> > Also note that there are three methods in use for enumerating within V4L:
> >
> > 1) there is an index field in the struct that starts at 0 and that the
> > application increases by 1 until the ioctl returns an error.
> >
> > 2) old-style controls where just enumerated from CID_BASE to CID_LASTP1,
> > which is very, very ugly.
> >
> > 3) controls new-style allow one to set bit 31 on the control ID and in that
> > case the ioctl will give you the first control with an ID that is higher
> > than the specified ID.
> >
> > 1 or 3 are both valid options IMHO.
> >
> > But again, I don't see why we need it in the first place.
>
> Applications will only subscribe to the events they can handle, so I don't
> think enumeration is really required. We might want to provide "subscribe to
> all" and "subscribe to none" options though, maybe as special events
> (V4L2_EVENT_NONE, V4L2_EVENT_ALL)
Nice idea. Although we only need an EVENT_ALL. 'Subscribe to none' equals
'unsubscribe all' after all :-)
> > > VIDIOC_G_EVENT is used to get events. sequence is the event sequence
> > > number and the data is specific to driver or event type.
>
> For efficiency reasons a V4L2_G_EVENTS ioctl could also be provided to
> retrieve multiple events.
>
> struct v4l2_events {
> __u32 count;
> struct v4l2_event __user *events;
> };
>
> #define VIDIOC_G_EVENTS _IOW('V', xx, struct v4l2_events)
Hmm. Premature optimization. Perhaps as a future extension.
> > > The user will get the information that there's an event through
> > > exception file descriptors by using select(2). When an event is
> > > available the poll handler sets POLLPRI which wakes up select. -EINVAL
> > > will be returned if there are no pending events.
> > >
> > > VIDIOC_SUBSCRIBE_EVENT and VIDIOC_UNSUBSCRIBE_EVENT are used to
> > > subscribe and unsubscribe from events. The argument is event type.
> >
> > Two event types can be defined already (used by ivtv):
> >
> > #define V4L2_EVENT_DECOD
Re: [RFC] Video events, version 2
Hi Sakari,
On Wednesday 14 October 2009 19:48:33 Hans Verkuil wrote:
> On Wednesday 14 October 2009 15:02:14 Sakari Ailus wrote:
> > Here's the second version of the video events RFC. It's based on Laurent
> > Pinchart's original RFC. My aim is to address the issues found in the
> > old RFC during the V4L-DVB mini-summit in the Linux plumbers conference
> > 2009. To get a good grasp of the problem at hand it's probably a good
> > idea read the original RFC as well:
> >
> > http://www.spinics.net/lists/linux-media/msg10217.html>
Thanks for the RFC update.
> > Changes to version 1
> > --
> >
> > struct video_event has been renamed to v4l2_event. The struct is used in
> > userspace and V4L related structures appear to have v4l2 prefix so that
> > should be better than video.
In the end we will probably rename that to media_ or something similar in the
big media controller rename (if that ever happens). For now let's keep v4l2_,
that will be more consistent.
> > The "entity" field has been removed from the struct v4l2_event since the
> > subdevices will have their own device nodes --- the events should come
> > from them instead of the media controller. Video nodes could be used for
> > events, too.
I would still keep the entity field. It would allow for parents to report
children events and there could be use cases for that.
> > A few reserved fields have been added. There are new ioctls as well for
> > enumeration and (un)subscribing.
> >
> >
> > Interface description
> > -
> >
> > Event type is either a standard event or private event. Standard events
> > will be defined in videodev2.h. Private event types begin from
> > V4L2_EVENT_PRIVATE. Some high order bits could be reserved for future
> > use.
> >
> > #define V4L2_EVENT_PRIVATE_START0x0800
> > #define V4L2_EVENT_RESERVED 0x1000
>
> Suggestion: use the V4L2_EV_ prefix perhaps instead of the longer
> V4L2_EVENT?
EV could be confused with electron volt, exposure value, or even escape
velocity (don't underestimate the use of V4L2 in the spaceship market ;-)). On
a more serious note, while I like to keep identifiers short, is the 3
characters gain worth it here ?
> > VIDIOC_ENUM_EVENT is used to enumerate the available event types. It
> > works a bit the same way than VIDIOC_ENUM_FMT i.e. you get the next
> > event type by calling it with the last type in the type field. The
> > difference is that the range is not continuous like in querying controls.
>
> Question: why do we need an ENUM_EVENT? I don't really see a use-case for
> this.
>
> Also note that there are three methods in use for enumerating within V4L:
>
> 1) there is an index field in the struct that starts at 0 and that the
> application increases by 1 until the ioctl returns an error.
>
> 2) old-style controls where just enumerated from CID_BASE to CID_LASTP1,
> which is very, very ugly.
>
> 3) controls new-style allow one to set bit 31 on the control ID and in that
> case the ioctl will give you the first control with an ID that is higher
> than the specified ID.
>
> 1 or 3 are both valid options IMHO.
>
> But again, I don't see why we need it in the first place.
Applications will only subscribe to the events they can handle, so I don't
think enumeration is really required. We might want to provide "subscribe to
all" and "subscribe to none" options though, maybe as special events
(V4L2_EVENT_NONE, V4L2_EVENT_ALL)
> > VIDIOC_G_EVENT is used to get events. sequence is the event sequence
> > number and the data is specific to driver or event type.
For efficiency reasons a V4L2_G_EVENTS ioctl could also be provided to
retrieve multiple events.
struct v4l2_events {
__u32 count;
struct v4l2_event __user *events;
};
#define VIDIOC_G_EVENTS _IOW('V', xx, struct v4l2_events)
> > The user will get the information that there's an event through
> > exception file descriptors by using select(2). When an event is
> > available the poll handler sets POLLPRI which wakes up select. -EINVAL
> > will be returned if there are no pending events.
> >
> > VIDIOC_SUBSCRIBE_EVENT and VIDIOC_UNSUBSCRIBE_EVENT are used to
> > subscribe and unsubscribe from events. The argument is event type.
>
> Two event types can be defined already (used by ivtv):
>
> #define V4L2_EVENT_DECODER_STOPPED 1
> #define V4L2_EVENT_OUTPUT_VSYNC 2
>
> > struct v4l2_eventdesc {
> > __u32 type;
> > __u8description[64];
> > __u32 reserved[4];
> > };
> >
> > struct v4l2_event {
> > __u32 type;
> > __u32 sequence;
> > struct timeval timestamp;
> > __u8data[64];
>
> This should be a union:
>
>
> union {
> enum v4l2_field ev_output_vsync;
> __u8 data[64];
> };
The union will grow pretty big and I'm scared it would soon become a mess.
> > __u32 reserved[4];
> > };
> >
> > #define VIDIOC_ENUM_EVENT
Webcam with high framerate
Hi, I search a webcam which has a higher framerate than 30fps. I have a Philips SPC1030NC which should make up to 60 fps when I believe the package of the camera but luvcview show me a possible framerate of max 30fps... Is there any usb webcam with a higher framerate than 30fps? Regards, Joern -- 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: More about "Winfast TV USB Deluxe"
yay
[ 2478.224015] tda9887 4-0043: configure for: Radio Stereo
[ 2478.224017] tda9887 4-0043: writing: b=0xcc c=0x90 e=0x3d
/Magnus
2009/10/15 Magnus Alm :
> Strange, but changeing the tvaudio_addr = 0xb0 to 88, (half of the
> decimal value of b0) made tvaudio find my tda9874.
>
> [ 1186.725140] tvaudio: TV audio decoder + audio/video mux driver
> [ 1186.725142] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
> tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
> pic16c54 (PV951), ta8874z
> [ 1186.725151] tvaudio 4-0058: chip found @ 0xb0
> [ 1186.736444] tvaudio 4-0058: chip_read2: reg254=0x11
> [ 1186.749704] tvaudio 4-0058: chip_read2: reg255=0x2
> [ 1186.749708] tvaudio 4-0058: tda9874a_checkit(): DIC=0x11, SIC=0x2.
> [ 1186.749710] tvaudio 4-0058: found tda9874a.
> [ 1186.749712] tvaudio 4-0058: tda9874h/a/ah found @ 0xb0 (em28xx #0)
> [ 1186.749714] tvaudio 4-0058: matches:.
> [ 1186.749716] tvaudio 4-0058: chip_write: reg0=0x0
> [ 1186.760012] tvaudio 4-0058: chip_write: reg1=0xc0
> [ 1186.772014] tvaudio 4-0058: chip_write: reg2=0x2
> [ 1186.784013] tvaudio 4-0058: chip_write: reg11=0x80
> [ 1186.796010] tvaudio 4-0058: chip_write: reg12=0x0
> [ 1186.808013] tvaudio 4-0058: chip_write: reg13=0x0
> [ 1186.820012] tvaudio 4-0058: chip_write: reg14=0x1
> [ 1186.832015] tvaudio 4-0058: chip_write: reg15=0x0
> [ 1186.844012] tvaudio 4-0058: chip_write: reg16=0x14
> [ 1186.856018] tvaudio 4-0058: chip_write: reg17=0x50
> [ 1186.868011] tvaudio 4-0058: chip_write: reg18=0xf9
> [ 1186.880745] tvaudio 4-0058: chip_write: reg19=0x80
> [ 1186.892347] tvaudio 4-0058: chip_write: reg20=0x80
> [ 1186.904015] tvaudio 4-0058: chip_write: reg24=0x80
> [ 1186.916011] tvaudio 4-0058: chip_write: reg255=0x0
> [ 1186.928021] tvaudio 4-0058: tda9874a_setup(): A2, B/G [0x00].
> [ 1186.928091] tvaudio 4-0058: thread started
>
> Now I probably need to set some gpio's too
>
> /Magnus
>
> 2009/10/14 Magnus Alm :
>> Loaded em28xx with i2c_scan and i2c_debug and tvaudio with tda9874a
>> option and debug.
>>
>> sudo modprobe -v em28xx i2c_scan=1 i2c_debug=1
>> sudo modprobe -v tvaudio tda9874a=1 debug=1
>>
>> And got this ouput:
>>
>> [91083.588182] em28xx #0: found i2c device @ 0x30 [???]
>> [91083.590179] em28xx #0: found i2c device @ 0x3e [???]
>> [91083.590804] em28xx #0: found i2c device @ 0x42 [???]
>> [91083.600308] em28xx #0: found i2c device @ 0x86 [tda9887]
>> [91083.603805] em28xx #0: found i2c device @ 0xa0 [eeprom]
>> [91083.606183] em28xx #0: found i2c device @ 0xb0 [tda9874]
>> [91083.608808] em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
>> [91083.617682] em28xx #0: Identified as Leadtek Winfast USB II Deluxe
>> (card=28)
>> [91083.617684] em28xx #0:
>> [91083.617684]
>> [91083.617687] em28xx #0: The support for this board weren't valid yet.
>> [91083.617688] em28xx #0: Please send a report of having this working
>> [91083.617690] em28xx #0: not to V4L mailing list (and/or to other addresses)
>> [91083.617691]
>> [91083.980702] saa7115 4-0021: saa7114 found (1f7114d0e00) @ 0x42
>> (em28xx #0)
>> [91086.173114] tvaudio: TV audio decoder + audio/video mux driver
>> [91086.173116] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
>> tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
>> pic16c54 (PV951), ta8874z
>> [91086.173125] tvaudio 4-00b0: chip found @ 0x160
>> [91086.173127] tvaudio 4-00b0: no matching chip description found
>> [91086.173131] tvaudio: probe of 4-00b0 failed with error -5
>>
>>
>> It seems to be a tda9874 there -> em28xx #0: found i2c device @ 0xb0
>> [tda9874]
>>
>> But does tvaudio stop @ 0x160 (decimal value of 0xa0 rigth? ) and
>> doesn't look further?
>> I mean does tvaudio find my boards eeprom, cant talk to it and gives up?
>>
>>
>> /Magnus
>>
>>
>> 2009/10/13 Magnus Alm :
>>> Hi!
>>>
>>> Thanks to Devin's moral support I now have sound in television. ;-)
>>>
>>> Thanks!!
>>>
>>> I pooked around some more managed to get radio to function with these
>>> settings:
>>>
>>> [EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE] = {
>>> .name = "Leadtek Winfast USB II Deluxe",
>>> .valid = EM28XX_BOARD_NOT_VALIDATED,
>>> .tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
>>> .tda9887_conf = TDA9887_PRESENT |
>>> TDA9887_PORT1_ACTIVE,
>>> .decoder = EM28XX_SAA711X,
>>> .input = { {
>>> .type = EM28XX_VMUX_TELEVISION,
>>> .vmux = SAA7115_COMPOSITE4,
>>> .amux = EM28XX_AMUX_AUX,
>>> }, {
>>> .type = EM28XX_VMUX_COMPOSITE1,
>>> .vmux = SAA7115_COMPOSITE5,
>>> .amux = EM28XX_AMUX_LINE_IN,
>>> }, {
>>> .type = EM28XX_VMUX_SVIDEO,
>>> .vmux = SAA7115_SVIDEO3,
>>>
Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
writes:
> From: Santiago Nunez-Corrales
>
> This patch provides support for TVP7002 in architecture definitions
> within DM365.
>
> Signed-off-by: Santiago Nunez-Corrales
> ---
> arch/arm/mach-davinci/board-dm365-evm.c | 170
> ++-
> 1 files changed, 166 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
> b/arch/arm/mach-davinci/board-dm365-evm.c
> index a1d5e7d..6c544d3 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -38,6 +38,11 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
>
>
> static inline int have_imager(void)
> @@ -48,8 +53,11 @@ static inline int have_imager(void)
>
> static inline int have_tvp7002(void)
> {
> - /* REVISIT when it's supported, trigger via Kconfig */
> +#ifdef CONFIG_VIDEO_TVP7002
> + return 1;
> +#else
> return 0;
> +#endif
I've said this before, but I'll say it again. I don't like the
#ifdef-on-Kconfig-option here.
Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata->probe() which could then set a flag
for use by have_tvp7002().
This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.
Kevin
--
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:Thu Oct 15 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13101:3919b17dc88e gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Has anybody tried Freeview HD in UK
On 14/10/09 21:08, Antti Palosaari wrote: In my understanding they will start new DVB-T2 standard and due to that new devices are needed. There is no DVB-T2 devices publicly sold currently. Few vendors like Pace and Humax have public prototypes. Basically new demodulator chips are needed and I don't know if there is any publicly released. Finland will also start DVB-T2 SFN (Single Frequency Network) with h.264 during next year. There is two VHF muxes currently reserved for that. Antti and in a few years we'll be ready for a new switchover! I was hoping to be able to receive it like for the last HD trial. -- 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 5/6 v5] TVP7002 driver for DM365
On Thursday 15 October 2009 16:43:54 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides the implementation of the TVP7002 decoder
> driver for DM365.
>
> Signed-off-by: Santiago Nunez-Corrales
> ---
> drivers/media/video/tvp7002.c | 1585
> +
> 1 files changed, 1585 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/tvp7002.c
>
> diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
> new file mode 100644
> index 000..1452599
> --- /dev/null
> +++ b/drivers/media/video/tvp7002.c
> @@ -0,0 +1,1585 @@
> +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
> + * Digitizer with Horizontal PLL registers
> + *
> + * Copyright (C) 2009 Texas Instruments Inc
> + * Author: Santiago Nunez-Corrales
> + *
> + * This code is partially based upon the TVP5150 driver
> + * written by Mauro Carvalho Chehab (mche...@infradead.org),
> + * the TVP514x driver written by Vaibhav Hiremath
> + * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
> + * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "tvp7002_reg.h"
> +
> +MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
> +MODULE_AUTHOR("Santiago Nunez-Corrales ");
> +MODULE_LICENSE("GPL");
> +
> +/* Module Name */
> +#define TVP7002_MODULE_NAME "tvp7002"
> +
> +/* I2C retry attempts */
> +#define I2C_RETRY_COUNT (5)
> +
> +/* Debug functions */
> +static int debug;
> +module_param(debug, bool, 0644);
> +MODULE_PARM_DESC(debug, "Debug level (0-2)");
> +
> +/* Structure for register values */
> +struct i2c_reg_value {
> + u8 reg;
> + u8 value;
> + u8 type;
> +};
> +
> +/*
> + * Register default values (according to tvp7002 datasheet)
> + * In the case of read-only registers, the value (0xff) is
> + * never written. R/W functionality is controlled by the
> + * writable bit in the register struct definition.
> + */
> +static const struct i2c_reg_value tvp7002_init_default[] = {
> + { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
> + { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
> + { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
> + { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
> + { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
> + { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
> + { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
> + { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
> + { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
> + { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
> + { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
> + { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
> + { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
> + { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
> + { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
> + { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
> + { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
> + { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
> + { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
> + { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
> + { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
> + { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
> + { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
> + { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
> + { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE },
> + { TVP7002_IN_MUX_SEL_1, 0x00, TVP7002_WRITE },
> + { TVP7002_IN_MUX_SEL_2, 0x67, TVP7002_WRITE },
> + { TVP7002_B_AND_G_COARSE_GAIN, 0x77, TVP7002_WRITE },
> + { TVP7002_R_COARSE_GAIN, 0x07, TVP7002_WRITE },
> + { TVP7002_FINE_OFF_LSBS, 0x00, TVP7002_WRITE },
> + { TVP7002_B_COARSE_OFF, 0x10, TVP7002_WRITE },
> + { TVP7002_G_COARSE_OFF, 0x10, TVP7002_WRITE },
> + { TVP7002_R_COARSE_OFF, 0x10, TVP7002_WRITE },
> + { TVP7002_HSOUT_OUT_START, 0x08, TVP7002_WRITE },
> + { TVP7002_MISC_CTL_4, 0x00, TVP7002_WRITE },
> + { TVP7002_B_DGTL_ALC_OUT_LSBS, 0xff, TVP7002_READ },
> + { TVP7002_G_DGTL_ALC_OUT_LSBS, 0xff, TVP7002_READ },
>
[PATCH 1/6] Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales
This patch provides required chip identification definitions
within v4l2. Changed order of THS7353.
Signed-off-by: Santiago Nunez-Corrales
---
include/media/v4l2-chip-ident.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index cf16689..b4b874f 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
+ /* module tvp7002: just ident 7002 */
+ V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
@@ -150,6 +153,12 @@ enum {
/* module adv7343: just ident 7343 */
V4L2_IDENT_ADV7343 = 7343,
+ /* module ths7353: just ident 7353 */
+ V4L2_IDENT_THS7353 = 7353,
+
+ /* module ths8200: just ident 8200 */
+ V4L2_IDENT_THS8200 = 8200,
+
/* module wm8739: just ident 8739 */
V4L2_IDENT_WM8739 = 8739,
--
1.6.0.4
--
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 6/6 v5] Menu support for TVP7002 in DM365
From: Santiago Nunez-Corrales This patch provides menu configuration options for the TVP7002 decoder driver in DM365. Signed-off-by: Santiago Nunez-Corrales --- drivers/media/video/Kconfig | 32 drivers/media/video/Makefile |2 ++ 2 files changed, 34 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e6186b3..f33652e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -392,6 +392,15 @@ config VIDEO_TVP5150 To compile this driver as a module, choose M here: the module will be called tvp5150. +config VIDEO_TVP7002 + tristate "Texas Instruments TVP7002 video decoder" + depends on VIDEO_V4L2 && I2C + ---help--- + Support for the Texas Instruments TVP7002 video decoder. + + To compile this driver as a module, choose M here: the + module will be called tvp7002. + config VIDEO_VPX3220 tristate "vpx3220a, vpx3216b & vpx3214c video decoders" depends on VIDEO_V4L2 && I2C @@ -466,6 +475,29 @@ config VIDEO_THS7303 To compile this driver as a module, choose M here: the module will be called ths7303. +config VIDEO_THS7353 + tristate "THS7353 Video Amplifier" + depends on I2C + help + Support for TI THS7353 video amplifier + + To compile this driver as a module, choose M here: the + module will be called ths7353. + +config VIDEO_THS7353_LUMA_CHANNEL + int "THS7353 channel number for Luma Input" + default 3 + depends on VIDEO_THS7353 + help + Select the luma channel number for the THS7353 input. + + THS7353 has three identical channels. For the component + interface, luma input will be connected to one of these + channels and cb and cr will be connected to other channels + This config option is used to select the luma input channel + number. Possible values for this option are 1,2 or 3. Any + other value will result in value 2. + config VIDEO_ADV7343 tristate "ADV7343 video encoder" depends on I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index e541932..d9a421a 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -53,9 +53,11 @@ obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o obj-$(CONFIG_VIDEO_THS7303) += ths7303.o +obj-$(CONFIG_VIDEO_THS7353) += ths7353.o obj-$(CONFIG_VIDEO_VINO) += indycam.o obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o +obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o obj-$(CONFIG_VIDEO_CS5345) += cs5345.o obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o -- 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] KWORLD 323U, kernel panic when trying to access ALSA interface
2009/9/28 Marios Andreopoulos : > On Monday 28 of September 2009, Devin Heitmueller wrote: >> >> Hello Marios, >> >> I started doing some debugging em28xx audio on the HVR-950 and hit >> what is probably the same panic (which occurs as soon as you run the >> arecord command). I've got a stack dump and am actively debugging the >> issue. >> >> It seems that a regression has been recently introduced. >> >> Devin >> >> > > If there is any way I can help please let me know. > I do not know much about developing or debugging software but I believe I'm > able to follow instructions to get a dump or do some trials if there is a > need. > > Thanks for the really quick reply, > Marios Hello Marios, Sorry about the extended delay on this. Please try out the following tree and see if you still hit a panic: http://www.kernellabs.com/hg/~dheitmueller/em28xx-audio-panic Cheers, 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: Hauppage WinTV-HVR-900H
Bill Davidsen wrote: Is this list to promote video on Linux, or just some particular implementation of it? a particular implementation ie. the set of drivers that are developed around the linuxtv.org web site for inclusion in the linux kernel Is there a better list, where all competing hardware and software can be discussed as solutions without people getting flamed? not that i am aware of -- simon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6 v5] Support for TVP7002 in v4l2 definitions
On Thursday 15 October 2009 16:42:52 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> This patch provides required chip identification definitions
> within v4l2. Removed HD and control defines.
>
> Signed-off-by: Santiago Nunez-Corrales
> ---
> include/media/v4l2-chip-ident.h |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
> index cf16689..691cc72 100644
> --- a/include/media/v4l2-chip-ident.h
> +++ b/include/media/v4l2-chip-ident.h
> @@ -129,6 +129,9 @@ enum {
> V4L2_IDENT_SAA6752HS = 6752,
> V4L2_IDENT_SAA6752HS_AC3 = 6753,
>
> + /* module tvp7002: just ident 7002 */
> + V4L2_IDENT_TVP7002 = 7002,
> +
> /* module adv7170: just ident 7170 */
> V4L2_IDENT_ADV7170 = 7170,
>
> @@ -147,6 +150,9 @@ enum {
> /* module ths7303: just ident 7303 */
> V4L2_IDENT_THS7303 = 7303,
>
> + /* module ths7353: just ident 7353 */
> + V4L2_IDENT_THS7353 = 7353,
> +
> /* module adv7343: just ident 7343 */
> V4L2_IDENT_ADV7343 = 7343,
>
Just a small thing: please add 7353 AFTER 7343.
Regards,
Hans
--
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
Regression: Nebula DigiTV DVB-T (PCI) no longer works
Hi, My Nebula DigiTV DVB-T (PCI) card no longer works. It's on a multi-boot Kubuntu system and works fine when I boot into Intrepid (v2.6.27-11-generic#1 SMP i686), but it does not work with Jaunty (2.6.28-11-generic i686). I've also tried a beta of the latest Kubuntu release Karmic and that also does not work. I've tried both i686 and x64 variants and its the same. I did a clean install and when I try to scan for channels using Kaffeine it gets nothing and displays the following: f...@cartman:/media$ kaffeine kbuildsycoca running... Reusing existing ksycoca /dev/dvb/adapter0/frontend0 : opened ( Zarlink MT352 DVB-T ) 0 EPG plugins loaded for device 0:0. Loaded epg data : 0 events (0 msecs) f...@cartman:/media$ DvbCam::probe(): /dev/dvb/adapter0/ca0: : No such file or directory Using DVB device 0:0 "Zarlink MT352 DVB-T" tuning DVB-T to 17750 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 .FE_READ_STATUS: Remote I/O error Transponders: 1/57 scanMode=0 it's dvb 2! Invalid section length or timeout: pid=17 Invalid section length or timeout: pid=0 Frontend closed Using DVB device 0:0 "Zarlink MT352 DVB-T" tuning DVB-T to 18450 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 .FE_READ_STATUS: Remote I/O error /var/log/messages looks like: Apr 27 21:52:36 cartman kernel: [ 10.928721] bttv: driver version 0.9.17 loaded Apr 27 21:52:36 cartman kernel: [ 10.928726] bttv: using 8 buffers with 2080k (520 pages) each for capture Apr 27 21:52:36 cartman kernel: [ 10.928782] bttv: Bt8xx card found (0). Apr 27 21:52:36 cartman kernel: [ 10.928802] bttv :05:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 Apr 27 21:52:36 cartman kernel: [ 10.928812] bttv0: Bt878 (rev 17) at :05:07.0, irq: 17, latency: 32, mmio: 0xd200 Apr 27 21:52:36 cartman kernel: [ 10.929515] bttv0: detected: Nebula Electronics DigiTV [card=104], PCI subsystem ID is 0071:0101 Apr 27 21:52:36 cartman kernel: [ 10.929520] bttv0: using: Nebula Electronics DigiTV [card=104,autodetected] Apr 27 21:52:36 cartman kernel: [ 10.929654] bttv0: tuner absent Apr 27 21:52:36 cartman kernel: [ 10.929719] bttv0: registered device video1 Apr 27 21:52:36 cartman kernel: [ 10.929742] bttv0: registered device vbi0 Apr 27 21:52:36 cartman kernel: [ 10.929760] bttv0: PLL: 28636363 => 35468950 .. ok Apr 27 21:52:36 cartman kernel: [ 10.961077] bttv0: add subdevice "dvb0" Apr 27 21:52:36 cartman kernel: [ 10.961206] input: bttv IR (card=104) as /devices/pci:00/:00: 09.0/:05:07.0/input/input6 Apr 27 21:52:36 cartman kernel: [ 10.994975] synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume Apr 27 21:52:36 cartman kernel: [ 11.013425] bt878: AUDIO driver version 0.0.0 loaded Apr 27 21:52:36 cartman kernel: [ 11.013628] bt878: Bt878 AUDIO function found (0). Apr 27 21:52:36 cartman kernel: [ 11.013645] bt878 :05:07.1: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 Apr 27 21:52:36 cartman kernel: [ 11.013648] bt878_probe: card id=[0x1010071],[ Nebula Electronics DigiTV ] has DVB functions. Apr 27 21:52:36 cartman kernel: [ 11.013655] bt878(0): Bt878 (rev 17) at 05:07.1, irq: 17, latency: 32, memory: 0xd2001000 Apr 27 21:52:36 cartman kernel: [ 11.018482] scsi 6:0:0:0: Direct-Access VIA-PVT6205-DevB 2.82 PQ: 0 ANSI: 2 Apr 27 21:52:36 cartman kernel: [ 11.019101] scsi 6:0:0:1: Direct-Access VIA-PVT6205-DevM 2.82 PQ: 0 ANSI: 2 Apr 27 21:52:36 cartman kernel: [ 11.021611] sd 6:0:0:0: [sdc] Attached SCSI removable disk Apr 27 21:52:36 cartman kernel: [ 11.021740] sd 6:0:0:0: Attached scsi generic sg4 type 0 Apr 27 21:52:36 cartman kernel: [ 11.022689] sd 6:0:0:1: [sdd] Attached SCSI removable disk Apr 27 21:52:36 cartman kernel: [ 11.022772] sd 6:0:0:1: Attached scsi generic sg5 type 0 Apr 27 21:52:36 cartman kernel: [ 11.050652] DVB: registering new adapter (bttv0) Apr 27 21:52:36 cartman kernel: [ 11.058791] usbcore: registered new interface driver snd-usb-audio Apr 27 21:52:36 cartman kernel: [ 11.142234] ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 Apr 27 21:52:36 cartman kernel: [ 11.142241] Intel ICH :00:04.0: PCI INT A -> Link[APCJ] -> GSI 22 (level, low) -> IRQ 22 Apr 27 21:52:36 cartman kernel: [ 11.308995] DVB: registering adapter 0 frontend 0 (Zarlink MT352 DVB-T)... A . . . Apr 27 21:54:50 cartman kernel: [ 149.693129] mt352_read_register: readreg error (reg=137, ret==-6) Apr 27 21:54:50 cartman kernel: [ 149.693715] mt352_read_register: readreg error (reg=138, ret==-6) Apr 27 21:54:53 cartman kernel: [ 152.692542] mt352_write() to reg 89 failed (err = -6)! Apr 27 21:55:01 cartman kernel: [ 160.599305] mt352_read_register: readreg error (reg=137, ret==-6) Apr 27 21:55:01 cartman kernel: [ 160.599806] mt352_read_register: readreg error (reg=138, ret==-6) Apr 27 21:55:01 cartman kernel: [ 160.600787] mt352_write() to reg 51 failed (err = -6)! Apr 27 21:55:01 cartma
[PATCH 5/6 v5] TVP7002 driver for DM365
From: Santiago Nunez-Corrales
This patch provides the implementation of the TVP7002 decoder
driver for DM365.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002.c | 1585 +
1 files changed, 1585 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/tvp7002.c
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..1452599
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1585 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tvp7002_reg.h"
+
+MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
+MODULE_AUTHOR("Santiago Nunez-Corrales ");
+MODULE_LICENSE("GPL");
+
+/* Module Name */
+#define TVP7002_MODULE_NAME"tvp7002"
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");
+
+/* Structure for register values */
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+ u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+ { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+ { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+ { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+ { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+ { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+ { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+ { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+ { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+ { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+ { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+ { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE },
+ { TVP7002_IN_MUX_SEL_1, 0x00, TVP7002_WRITE },
+ { TVP7002_IN_MUX_SEL_2, 0x67, TVP7002_WRITE },
+ { TVP7002_B_AND_G_COARSE_GAIN, 0x77, TVP7002_WRITE },
+ { TVP7002_R_COARSE_GAIN, 0x07, TVP7002_WRITE },
+ { TVP7002_FINE_OFF_LSBS, 0x00, TVP7002_WRITE },
+ { TVP7002_B_COARSE_OFF, 0x10, TVP7002_WRITE },
+ { TVP7002_G_COARSE_OFF, 0x10, TVP7002_WRITE },
+ { TVP7002_R_COARSE_OFF, 0x10, TVP7002_WRITE },
+ { TVP7002_HSOUT_OUT_START, 0x08, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_4, 0x00, TVP7002_WRITE },
+ { TVP7002_B_DGTL_ALC_OUT_LSBS, 0xff, TVP7002_READ },
+ { TVP7002_G_DGTL_ALC_OUT_LSBS, 0xff, TVP7002_READ },
+ { TVP7002_R_DGTL_ALC_OUT_LSBS, 0xff, TVP7002_READ },
+ { TVP7002_AUTO_LVL_CTL_ENABLE, 0x80, TVP7002_WRITE },
+ { TVP7002_DGTL_ALC_OUT_MSBS, 0xff, TVP7002_READ },
+ { TVP7002_AUTO_LVL_CTL_FILTER, 0x53, TV
[PATCH 6/6 v5] Menu support for TVP7002 in DM365
From: Santiago Nunez-Corrales This patch provides menu configuration options for the TVP7002 decoder driver in DM365. Signed-off-by: Santiago Nunez-Corrales --- drivers/media/video/Kconfig | 32 drivers/media/video/Makefile |2 ++ 2 files changed, 34 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e6186b3..f33652e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -392,6 +392,15 @@ config VIDEO_TVP5150 To compile this driver as a module, choose M here: the module will be called tvp5150. +config VIDEO_TVP7002 + tristate "Texas Instruments TVP7002 video decoder" + depends on VIDEO_V4L2 && I2C + ---help--- + Support for the Texas Instruments TVP7002 video decoder. + + To compile this driver as a module, choose M here: the + module will be called tvp7002. + config VIDEO_VPX3220 tristate "vpx3220a, vpx3216b & vpx3214c video decoders" depends on VIDEO_V4L2 && I2C @@ -466,6 +475,29 @@ config VIDEO_THS7303 To compile this driver as a module, choose M here: the module will be called ths7303. +config VIDEO_THS7353 + tristate "THS7353 Video Amplifier" + depends on I2C + help + Support for TI THS7353 video amplifier + + To compile this driver as a module, choose M here: the + module will be called ths7353. + +config VIDEO_THS7353_LUMA_CHANNEL + int "THS7353 channel number for Luma Input" + default 3 + depends on VIDEO_THS7353 + help + Select the luma channel number for the THS7353 input. + + THS7353 has three identical channels. For the component + interface, luma input will be connected to one of these + channels and cb and cr will be connected to other channels + This config option is used to select the luma input channel + number. Possible values for this option are 1,2 or 3. Any + other value will result in value 2. + config VIDEO_ADV7343 tristate "ADV7343 video encoder" depends on I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index e541932..d9a421a 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -53,9 +53,11 @@ obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o obj-$(CONFIG_VIDEO_THS7303) += ths7303.o +obj-$(CONFIG_VIDEO_THS7353) += ths7353.o obj-$(CONFIG_VIDEO_VINO) += indycam.o obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o +obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o obj-$(CONFIG_VIDEO_CS5345) += cs5345.o obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o -- 1.6.0.4 -- 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 4/6 v5] Definitions for TVP7002 in DM365
From: Santiago Nunez-Corrales This patch provides the required definitions for the TVP7002 driver in DM365. Signed-off-by: Santiago Nunez-Corrales --- drivers/media/video/tvp7002_reg.h | 150 + include/media/tvp7002.h | 84 + 2 files changed, 234 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/tvp7002_reg.h create mode 100644 include/media/tvp7002.h diff --git a/drivers/media/video/tvp7002_reg.h b/drivers/media/video/tvp7002_reg.h new file mode 100644 index 000..0e34ca9 --- /dev/null +++ b/drivers/media/video/tvp7002_reg.h @@ -0,0 +1,150 @@ +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics + * Digitizer with Horizontal PLL registers + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Santiago Nunez-Corrales + * + * This code is partially based upon the TVP5150 driver + * written by Mauro Carvalho Chehab (mche...@infradead.org), + * the TVP514x driver written by Vaibhav Hiremath + * and the TVP7002 driver in the TI LSP 2.10.00.14 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Naming conventions + * -- + * + * FDBK: Feedback + * DIV: Divider + * CTL: Control + * SEL: Select + * IN:Input + * OUT: Output + * R: Red + * G: Green + * B: Blue + * OFF: Offset + * THRS: Threshold + * DGTL: Digital + * LVL: Level + * PWR: Power + * MVIS: Macrovision + * W: Width + * H: Height + * ALGN: Alignment + * CLK: Clocks + * TOL: Tolerance + * BWTH: Bandwidth + * COEF: Coefficient + * STAT: Status + * AUTO: Automatic + * FLD: Field + * L:Line + */ + +#define TVP7002_CHIP_REV 0x00 +#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01 +#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02 +#define TVP7002_HPLL_CRTL 0x03 +#define TVP7002_HPLL_PHASE_SEL 0x04 +#define TVP7002_CLAMP_START0x05 +#define TVP7002_CLAMP_W0x06 +#define TVP7002_HSYNC_OUT_W0x07 +#define TVP7002_B_FINE_GAIN0x08 +#define TVP7002_G_FINE_GAIN0x09 +#define TVP7002_R_FINE_GAIN0x0a +#define TVP7002_B_FINE_OFF_MSBS0x0b +#define TVP7002_G_FINE_OFF_MSBS 0x0c +#define TVP7002_R_FINE_OFF_MSBS 0x0d +#define TVP7002_SYNC_CTL_1 0x0e +#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f +#define TVP7002_SYNC_ON_G_THRS 0x10 +#define TVP7002_SYNC_SEPARATOR_THRS0x11 +#define TVP7002_HPLL_PRE_COAST 0x12 +#define TVP7002_HPLL_POST_COAST0x13 +#define TVP7002_SYNC_DETECT_STAT 0x14 +#define TVP7002_OUT_FORMATTER 0x15 +#define TVP7002_MISC_CTL_1 0x16 +#define TVP7002_MISC_CTL_2 0x17 +#define TVP7002_MISC_CTL_3 0x18 +#define TVP7002_IN_MUX_SEL_1 0x19 +#define TVP7002_IN_MUX_SEL_20x1a +#define TVP7002_B_AND_G_COARSE_GAIN0x1b +#define TVP7002_R_COARSE_GAIN 0x1c +#define TVP7002_FINE_OFF_LSBS 0x1d +#define TVP7002_B_COARSE_OFF 0x1e +#define TVP7002_G_COARSE_OFF0x1f +#define TVP7002_R_COARSE_OFF0x20 +#define TVP7002_HSOUT_OUT_START0x21 +#define TVP7002_MISC_CTL_4 0x22 +#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23 +#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24 +#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25 +#define TVP7002_AUTO_LVL_CTL_ENABLE0x26 +#define TVP7002_DGTL_ALC_OUT_MSBS 0x27 +#define TVP7002_AUTO_LVL_CTL_FILTER0x28 +/* Reserved 0x29*/ +#define TVP7002_FINE_CLAMP_CTL 0x2a +#define TVP7002_PWR_CTL0x2b +#define TVP7002_ADC_SETUP 0x2c +#define TVP7002_COARSE_CLAMP_CTL 0x2d +#define TVP7002_SOG_CLAMP 0x2e +#define TVP7002_RGB_COARSE_CLAMP_CTL 0x2f +#define TVP7002_SOG_COARSE_CLAMP_CTL 0x30 +#define TVP7002_ALC_PLACEMENT 0x31 +/* Reserved 0x32 */ +/* Reserved 0x33 */ +#define TVP7002_MVIS_STRIPPER_W0x34 +#define TVP7002_VSYNC_ALGN 0x35 +#define TVP7002_SYNC_BYPASS0x36 +#define TVP7002_L_FRAME_STAT_LSBS 0x37 +#define TVP7002_L_FRAME_STAT_MSBS 0x38 +#define TVP7002_CLK_L_STAT_LSBS0x39 +#define TVP7002_CLK_L_STAT_MSBS0x3a +#define TV
[PATCH 3/6 v5] Support for TVP7002 in VPFE
From: Santiago Nunez-Corrales
This patch adds support for TVP7002 in the DM365 VPFE inteface.
Added video modes.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/davinci/vpfe_capture.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 402ce43..4820091 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
#include
#include "ccdc_hw_device.h"
@@ -131,6 +132,14 @@ static struct ccdc_config *ccdc_cfg;
const struct vpfe_standard vpfe_standards[] = {
{V4L2_STD_525_60, 720, 480, {11, 10}, 1},
{V4L2_STD_625_50, 720, 576, {54, 59}, 1},
+ {V4L2_STD_525P_60, 720, 480, {11, 10}, 0},
+ {V4L2_STD_625P_50, 720, 576, {54, 59}, 0},
+ {V4L2_STD_720P_50, 1280, 720, {1, 1}, 0},
+ {V4L2_STD_720P_60, 1280, 720, {1, 1}, 0},
+ {V4L2_STD_1080I_50, 1920, 1080, {1, 1}, 1},
+ {V4L2_STD_1080I_60, 1920, 1080, {1, 1}, 1},
+ {V4L2_STD_1080P_50, 1920, 1080, {1, 1}, 0},
+ {V4L2_STD_1080P_60, 1920, 1080, {1, 1}, 0},
};
/* Used when raw Bayer image from ccdc is directly captured to SDRAM */
--
1.6.0.4
--
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 2/6 v5] Support for TVP7002 in dm365 board
From: Santiago Nunez-Corrales
This patch provides support for TVP7002 in architecture definitions
within DM365.
Signed-off-by: Santiago Nunez-Corrales
---
arch/arm/mach-davinci/board-dm365-evm.c | 170 ++-
1 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
{
- /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+ return 1;
+#else
return 0;
+#endif
}
@@ -96,8 +104,26 @@ static inline int have_tvp7002(void)
#define CPLD_CCD_DIR3 CPLD_OFFSET(0x3f,0)
#define CPLD_CCD_IO3 CPLD_OFFSET(0x3f,1)
+#define CPLD_VIDEO_INPUT_MUX_MASK 0x7
+#define CPLD_VIDEO_INPUT_MUX_TVP7002 0x1
+#define CPLD_VIDEO_INPUT_MUX_IMAGER0x2
+#define CPLD_VIDEO_INPUT_MUX_TVP5146 0x5
+
static void __iomem *cpld;
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
+/* tvp7002 platform data, used during reset and probe operations */
+static struct tvp7002_config tvp7002_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 0,
+ .vs_polarity = 0,
+ .fid_polarity = 0,
+};
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -207,6 +233,140 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) & BIT(module ? 5 : 1));
}
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = "S-Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+#define TVP7002_STD_ALL(V4L2_STD_525P_60 | V4L2_STD_625P_50 |\
+ V4L2_STD_NTSC | V4L2_STD_PAL |\
+ V4L2_STD_720P_50 | V4L2_STD_720P_60 |\
+ V4L2_STD_1080I_50 | V4L2_STD_1080I_60 |\
+ V4L2_STD_1080P_50 | V4L2_STD_1080P_60)
+
+/* Inputs available at the TVP7002 */
+static struct v4l2_input tvp7002_inputs[] = {
+ {
+ .index = 0,
+ .name = "Component",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP7002_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+ .module_name = "tvp5146",
+ .grp_id = VPFE_SUBDEV_TVP5146,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5d),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+ {
+ .module_name = "tvp7002",
+ .grp_id = VPFE_SUBDEV_TVP7002,
+ .num_inputs = ARRAY_SIZE(tvp7002_inputs),
+ .inputs = tvp7002_inputs,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT1120,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO("tvp7002", 0x5c),
+ .platform_data = &tvp7002_pdata,
+ },
+ },
+ {
+ .module_name = "ths7353",
+ .board_info = {
+ I2C_BOARD_INFO("ths7353", 0x2e),
+ },
+ },
+};
+
+/* Set the input mux
[PATCH 1/6 v5] Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales
This patch provides required chip identification definitions
within v4l2. Removed HD and control defines.
Signed-off-by: Santiago Nunez-Corrales
---
include/media/v4l2-chip-ident.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index cf16689..691cc72 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
+ /* module tvp7002: just ident 7002 */
+ V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
@@ -147,6 +150,9 @@ enum {
/* module ths7303: just ident 7303 */
V4L2_IDENT_THS7303 = 7303,
+ /* module ths7353: just ident 7353 */
+ V4L2_IDENT_THS7353 = 7353,
+
/* module adv7343: just ident 7343 */
V4L2_IDENT_ADV7343 = 7343,
--
1.6.0.4
--
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 0/6 v5] Support for TVP7002 in DM365
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition in board specific data structures * Linking within the VPFE architecture * Definition of TVP7002 specific data structures * Kconfig and Makefile support The v5 series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P. -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.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: Support on discontinuous planer buffer and stride
Hi,
Forgot to mention that this may need a new memory type as well.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
>-Original Message-
>From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan
>Sent: Thursday, October 15, 2009 10:00 AM
>To: Hans Verkuil; Jun Nie
>Cc: g.liakhovet...@gmx.de; linux-media
>Subject: RE: Support on discontinuous planer buffer and stride
>
>Hans,
>
>>
>>Well, it is definitely not possible to do it in this manner since changing
>>the size of struct v4l2_buffer will break the API. Furthermore, something
>>like
>>this will only work if the DMA engine can handle strides. Is that the case
>>for your hardware? I don't think you mentioned what the hardware is you
>use.
>>
>In fact I was planning to write an RFC for this as well. DM365 Resizer
>allows setting separate buffer address for Y and C plane (For _NV12 pixel
>format) as well as line offsets. Similarly on the display side, VPBE
>provides separate registers for configuring this. Currently we have
>proprietary IOCTL to configure the C-Plane buffer address and is not the
>right way to do it. For planar pixel format like NV12, NV16 etc, where the
>hardware is capable of configuring different address for individual plane,
>current v4l2 API has limitations. So I suggest that Jun Nie work on a RFC
>&implementation that allows application to set buffer addresses for
>individual planes of planar pixel formats. Something like below for userptr
>case (I feel only userptr case to be supported in this case)...
>
>+ struct v4l2_userptr_planar {
>+ /* Number of planes in the pixel format. 2 or 3,
>+ * 2 - for Y & CbCr, 3 for Y, Cb, & Cr
>+ */
>+ __u32 num_planes;
>+ /* Y or R */
>+ unsigned long userptr_yr;
>+ /* Cb or G */
>+ unsigned long userptr_cbg;
>+ /* Cr or B */
>+ unsigned long userptr_crb;
>+ };
>
>struct v4l2_buffer {
> __u32 index;
> enum v4l2_buf_type type;
> __u32 bytesused;
> __u32 flags;
> enum v4l2_field field;
> struct timeval timestamp;
> struct v4l2_timecodetimecode;
> __u32 sequence;
>
> /* memory location */
> enum v4l2_memorymemory;
> union {
> __u32 offset;
> unsigned long userptr;
>+ struct v4l2_userptr_planar userptr_p;
> } m;
> __u32 length;
> __u32 input;
> __u32 reserved;
>};
>
>-Murali
>>Regards,
>>
>> Hans
>>
>>--
>>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>>¢éì¹» ®&Þ~º&¶¬–+-±éݶ¥Šw®žË›±ÊâmébžìfyØšŠ{ayº ʇڙë,j
>¢f£¢·hš‹àz¹ ®w¥¢¸
>>
>>¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾
>«‘êçzZ+ƒùšŽŠÝ¢j"�ú!¶i
>--
>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: Support on discontinuous planer buffer and stride
Hans,
>
>Well, it is definitely not possible to do it in this manner since changing
>the size of struct v4l2_buffer will break the API. Furthermore, something
>like
>this will only work if the DMA engine can handle strides. Is that the case
>for your hardware? I don't think you mentioned what the hardware is you use.
>
In fact I was planning to write an RFC for this as well. DM365 Resizer allows
setting separate buffer address for Y and C plane (For _NV12 pixel format) as
well as line offsets. Similarly on the display side, VPBE provides separate
registers for configuring this. Currently we have proprietary IOCTL to
configure the C-Plane buffer address and is not the right way to do it. For
planar pixel format like NV12, NV16 etc, where the hardware is capable of
configuring different address for individual plane, current v4l2 API has
limitations. So I suggest that Jun Nie work on a RFC &implementation that
allows application to set buffer addresses for individual planes of planar
pixel formats. Something like below for userptr case (I feel only userptr case
to be supported in this case)...
+ struct v4l2_userptr_planar {
+ /* Number of planes in the pixel format. 2 or 3,
+* 2 - for Y & CbCr, 3 for Y, Cb, & Cr
+*/
+ __u32 num_planes;
+ /* Y or R */
+ unsigned long userptr_yr;
+ /* Cb or G */
+ unsigned long userptr_cbg;
+ /* Cr or B */
+ unsigned long userptr_crb;
+ };
struct v4l2_buffer {
__u32 index;
enum v4l2_buf_type type;
__u32 bytesused;
__u32 flags;
enum v4l2_field field;
struct timeval timestamp;
struct v4l2_timecodetimecode;
__u32 sequence;
/* memory location */
enum v4l2_memorymemory;
union {
__u32 offset;
unsigned long userptr;
+ struct v4l2_userptr_planar userptr_p;
} m;
__u32 length;
__u32 input;
__u32 reserved;
};
-Murali
>Regards,
>
> Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>¢éì¹» ®&Þ~º&¶¬–+-±éݶ¥Šw®žË›±ÊâmébžìfyØšŠ{ayº ʇڙë,j
¢f£¢·hš‹àz¹ ®w¥¢¸
>
>¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾
«‘êçzZ+ƒùšŽŠÝ¢j"�ú!¶i
--
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: How to set "nomail" option for the mailing list
On 15/10/09 09:36, Laurent Pinchart wrote: On Thursday 15 October 2009 10:01:39 Andrea wrote: Hi, I read and sometimes post to this mailing list, but I very much prefer to use a newsreader from gmane rather than receiving all the mails. In the old linux-dvb mailing list it was possible to switch off receiving all the emails, is it still possible? I could not find anything in the documentation of majord...@vger.kernel.org The linux-media@vger.kernel.org list is not subscriber-only like the old list. You could just unsubscribe. Thanks. But gmane returns a wrong information then You have sent a message to be posted on the gmane.linux.drivers.video-input-infrastructure newsgroup. This is a non-public mailing list, which means that you have to subscribe to the list to post to it. If you're already subscribed to the list, Gmane can forward the message you sent to the list if you respond to this message. If not, you should sign up to the mailing list first, and then respond to this message, or just forget about it. Many mailing lists have an option to subscribe to a list, but then put it in 'nomail' mode, which means that you won't receive any mail from the list. The mailing list software used for the list in question is majordomo. Mail majord...@vger.kernel.org and say 'subscribe linux-media'. You have to respond within one week. = -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] request driver for cards
On 15/10/2009, H. Langos wrote: > On Wed, Oct 14, 2009 at 03:07:00PM +0200, Theunis Potgieter wrote: > > Hi, what is the procedure to request drivers for specific new, perhaps > > unknown supported cards? > > > The "procedure" is to hit google with something > like "linux " and see what you find. :-) > I meant to say: Where do I ask for a new driver to be written for an unsupported card. Or Perhaps the card is already supported and I just couldn't see it from a singular view. (linuxtv.org, mailing list, Google) > Especially links to mailing list archives like linux-media and linux-dvb > are worth a read. > > I joined linux-...@linuxtv.org recently and I was informed that the mailing list is deprecated and I should join this mailing list instead. (you will see my first mail on their list too) > > > Perhaps I shouldn't waste time if I could find a dual/twin tuner card for > > dvb-s or dvb-s2. Are there any recommended twin-tuner pci-e cards that is > > support and can actually be bought by the average consumer? > > > Did you risk a look at any of those? > > http://www.linuxtv.org/wiki/index.php/DVB-S_PCI_Cards > http://www.linuxtv.org/wiki/index.php/DVB-S_PCIe_Cards > http://www.linuxtv.org/wiki/index.php/DVB-S2_PCI_Cards > http://www.linuxtv.org/wiki/index.php/DVB-S2_PCIe_Cards > I did visit those, and I couldn't find any sellers of the twin tuner cards on http://www.linuxtv.org/wiki/index.php/DVB-S2_PCIe_Cards :( They would be perfect. Exept I can't find where to buy these. Perhaps they are re-branded and somebody here knows this already? This site http://www.linuxtv.org/wiki/index.php/DVB-S_PCI_Cards does not list the Compro S300 neither the KWorld dvb-s 100. I just happened to grep -i kworld /usr/src/linux/drivers/media/dvb/*/* and found KWorld to be somewhat supported. Great so I know that one. How to approach Compro S300? The problem is this: Either I setup my old penium 3 machine with 5 pci slots (which I try to avoid) or buy a new machine with only 2 pci slots and 2 pci-e 1x slots. The options becomes limited on new machines if you want 4 or more tuners in the same machine. So I need some advice if it is feasible to run 5 dvb-s single tuner cards in a pentium3 or 5 tuners (2 twin tuner cards and single card) on an atom based machine? > I suspect they might contain some usable informaion. You should however > take into account that most developers don't care to update a bazillion > different places after they added support for a particular devices. So > in most cases there will be a brief announcment on the developers > mailinglist and the code is the documentation. > I recently joined this mailing list and will be a lookout for anything related to twin tuner cards sent by developers. Or if somebody knows just reply to this thread. Thanks for the help. > cheers > -henrik > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] request driver for cards
On Wed, Oct 14, 2009 at 03:07:00PM +0200, Theunis Potgieter wrote: > Hi, what is the procedure to request drivers for specific new, perhaps > unknown supported cards? The "procedure" is to hit google with something like "linux " and see what you find. :-) Especially links to mailing list archives like linux-media and linux-dvb are worth a read. > Perhaps I shouldn't waste time if I could find a dual/twin tuner card for > dvb-s or dvb-s2. Are there any recommended twin-tuner pci-e cards that is > support and can actually be bought by the average consumer? Did you risk a look at any of those? http://www.linuxtv.org/wiki/index.php/DVB-S_PCI_Cards http://www.linuxtv.org/wiki/index.php/DVB-S_PCIe_Cards http://www.linuxtv.org/wiki/index.php/DVB-S2_PCI_Cards http://www.linuxtv.org/wiki/index.php/DVB-S2_PCIe_Cards I suspect they might contain some usable informaion. You should however take into account that most developers don't care to update a bazillion different places after they added support for a particular devices. So in most cases there will be a brief announcment on the developers mailinglist and the code is the documentation. cheers -henrik -- 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: Request driver for cards
On 14/10/2009, Theunis Potgieter wrote: > Hi, what is the procedure to request drivers for specific new, perhaps > unknown supported cards? > > I did have a look at http://www.linuxtv.org/wiki/index.php/Main_Page > but it didn't contain any information about supported cards. Neither > did 2.6.30 /usr/src/linux/Documentation/dvb/cards.txt for the > following brands: > > name, site: > Compro, S300 http://www.comprousa.com/en/product/s300/s300.html > K-World VS-DVB-S 100/IS, > > http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248&modid=6&pcid=46&ifid=16&prodid=98 > > Perhaps I shouldn't waste time if I could find a dual/twin tuner card > for dvb-s or dvb-s2. Are there any recommended twin-tuner pci-e cards > that is support and can actually be bought by the average consumer? > > Thanks > I guess this answers the Kworld on 2.6.30: /usr/src/linux/drivers/media/dvb/frontends/cx24123.c: * Support for KWorld DVB-S 100 by Vadim Catana But how would I get compro S300 support? Is there anybody that knows of a work inprogress or completed twin tuner type card in either pci or pci-e format? Thanks in advance. -- 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: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
Andy Walls wrote: > Right, the windows driver code for the mxl5005s is better. Inform him > that the linux driver for the mxl5005s could be better. If he has any > contacts at MaxLinear to get the datasheet and programming manual > released to me, I can make the linux driver better. > We don't have contacts that we know of, but we're happy to chase after a datasheet for you if Devin's copy isn't enough - just let me know. > > The MXL5005s is the silicon tuner chip on the Digital TV side of the > HVR-1600. A simple picture for you: > > Cable ---| MXL5005s || CX24227 || CX23418 |--- PCI bus > > Analog Waveform---|Digital Data-- > That's nice and clear, and explains things to me perfectly. Thank you. > > Here's my HVR-1600 related entries from dmesg on startup. I have the > MXL5005S showing up at 9.510: > > [9.510767] MXL5005S: Attached at address 0x63 So basically, I was being blind and/or stupid - with this to hand, I've found the equivalent message in my dmesg. -- Simon Farnsworth -- 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: How to set "nomail" option for the mailing list
On Thursday 15 October 2009 10:01:39 Andrea wrote: > Hi, > > I read and sometimes post to this mailing list, but I very much prefer to > use a newsreader from gmane rather than receiving all the mails. > > In the old linux-dvb mailing list it was possible to switch off receiving > all the emails, is it still possible? > > I could not find anything in the documentation of majord...@vger.kernel.org The linux-media@vger.kernel.org list is not subscriber-only like the old list. You could just unsubscribe. -- 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
How to set "nomail" option for the mailing list
Hi, I read and sometimes post to this mailing list, but I very much prefer to use a newsreader from gmane rather than receiving all the mails. In the old linux-dvb mailing list it was possible to switch off receiving all the emails, is it still possible? I could not find anything in the documentation of majord...@vger.kernel.org Any help? -- 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
DVB-T scan file
I would like to contribute a DVB-T scan file for the transmitter at Goulburn NSW Australia. Who is responsible for this? aF -- 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
