[PATCH] zl10353 and qt1010: fix stack corruption bug
This patch fixes stack corruption bug present in dump_regs function of zl10353
and qt1010 drivers:
the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 were provided.
The one byte missing in stack based buffer buf can cause stack corruption
possibly leading to kernel oops, as discovered originally with af9015 driver.
Signed-off-by: Jan Nikitenko
---
Antti Palosaari wrote:
> On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
>> Solved with "[PATCH] af9015: fix stack corruption bug".
>
> This error leads to the zl10353.c and there it was copied to qt1010.c
> and af9015.c.
>
Antti, thanks for pointing out that the same problem was also in zl10353.c and
qt1010.c. Include your Sign-off-by, please.
Best regards,
Jan
linux/drivers/media/common/tuners/qt1010.c |2 +-
linux/drivers/media/dvb/frontends/zl10353.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -r cff06234b725 linux/drivers/media/common/tuners/qt1010.c
--- a/linux/drivers/media/common/tuners/qt1010.cSun May 31 23:07:01
2009 +0300
+++ b/linux/drivers/media/common/tuners/qt1010.cWed Jun 10 07:37:51
2009 +0200
@@ -65,7 +65,7 @@
/* dump all registers */
static void qt1010_dump_regs(struct qt1010_priv *priv)
{
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
diff -r cff06234b725 linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c Sun May 31 23:07:01
2009 +0300
+++ b/linux/drivers/media/dvb/frontends/zl10353.c Wed Jun 10 07:37:51
2009 +0200
@@ -102,7 +102,7 @@
static void zl10353_dump_regs(struct dvb_frontend *fe)
{
struct zl10353_state *state = fe->demodulator_priv;
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
int ret;
u8 reg;
--
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: About the VIDIOC_DQBUF
hi ~~
I have found the problem ~~ The 3'rd partner didn't give us the right
v4l2 driver. Thanks for your help ~~
Best wishes
在 2009-06-09二的 16:41 +0900，Dongsoo, Nathaniel Kim写道：
> Hi,
>
> Sorry I still don't get what the full frame means, but I might
> consider that is the maximum resolution-ed image data coming from
> external camera module. And whatever it is, you might have no problem
> getting data through memcpy with buf.byteused size.
> Cheers,
>
> Nate
>
> On Tue, Jun 9, 2009 at 11:22 AM, xie wrote:
> > hi ~~ Dongsoo, Nathaniel ~
> >
> > I am sorry for disturbing you, and not descripe the question clear ~
> > Thanks very much for your help ~~
> >
> > I know that I must stop preview with streamoff and re-configure with
> > s_fmt ~~ I have asked to you before ~!~
> >
> > The "full frame" means a complete frame ~Because I just need to get the
> > frame data and post it to multimedia framework, so I want to consult to
> > you that if I can get a complete frame with memcpy ~~
> >
> > I want to know that can I get a complete frame from buf.start to the
> > end , and the memory-lenth is buf.byteused ~
> >
> >buf.byteused
> >|-|
> > buf.startend
> >
> >
> >
> >
> >
> >
> >
> > 在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道：
> >> Hi,
> >>
> >> Sorry I'm not an expert, you can expect expertise from maintainers not
> >> from me.
> >> But before answering your question about capturing, I'm not sure about
> >> what the "full frame" means. I just assume that you meant to say the
> >> biggest resolution of image frame, right?
> >>
> >> So, when you are to capture a full resolution data while preview is
> >> working, you need to stop preview with streamoff, re-configure
> >> resolution with s_fmt to external camera module and start capturing
> >> issuing streamon with re-configured resolution. I think you are
> >> well-aware with this, aren't you? And in my opinion, memcpy may be
> >> cool for that. What else are you expecting to use? and for what?
> >> Anyway, I wish you luck.
> >> Cheers,
> >>
> >> Nate
> >>
> >>
> >> On Mon, Jun 8, 2009 at 5:02 PM, xie wrote:
> >> > Hi Dongsoo, Nathaniel ~
> >> > You must be expert on V4l2 ~ Thanks very much for your help and advice
> >> > ~!~
> >> > I used the MXC camera interface driver from Fressscale ,I readed the
> >> > driver interface just now ,and have fouded that the driver not modified
> >> > the buf.lenth but buf.byteused . You are very right , I will use the
> >> > buf.byteused instead of buf.length ~
> >> >
> >> > There is also a problem I want to consult to you ~ Can i get a full
> >> > frame with the below method if the driver have no problem ?
> >> >
> >> > memcpy((mCameraProwave->getPreviewHeap())->base(),
> >> > v4l2Buffer[buf.index].start, buf.byteused) ;
> >> >
> >> > Because I just need to implement a hal for getting the frame data and
> >> > post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
> >> > what about your advice ?
> >> >
> >> > Thanks a lot ~~
> >> >
> >> >
> >> >
> >> > 在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
> >> >> Hello Xie,
> >> >>
> >> >> I'm not sure which camera interface driver you are using, but it seems
> >> >> to be camera interface driver's problem. Let me guess, are you using
> >> >> pxa camera interface driver from Marvell?(proprietary but not in up
> >> >> stream kernel)
> >> >> It just looks like that camera interface driver is not returning
> >> >> proper data in dqbuf.
> >> >>
> >> >> And one more thing. I prefer to use byteused rather than length in
> >> >> buf. because as far as I know the size of preview data from camera is
> >> >> in byte unit which we need to copy to memory. But it should be
> >> >> possible to use length, I guess..
> >> >> Cheers,
> >> >>
> >> >> Nate
> >> >>
> >> >> On Mon, Jun 8, 2009 at 11:05 AM, xie wrote:
> >> >> > Dear all ~~
> >> >> >
> >> >> > I have met a issue when I used the mmap method for previewing . I just
> >> >> > used the standard code as spec to get the image data :
> >> >> > status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
> >> >> > {
> >> >> >LOG_FUNCTION_NAME
> >> >> >int rt ;
> >> >> >unsigned int i ;
> >> >> >fd_set fds ;
> >> >> >struct timeval tv ;
> >> >> >struct v4l2_buffer buf ;
> >> >> >
> >> >> >for(;;){
> >> >> >FD_ZERO(&fds) ;
> >> >> >FD_SET(v4l2Fd, &fds) ;
> >> >> >//now the time is long ,just for debug
> >> >> >tv.tv_sec = 2 ;
> >> >> >tv.tv_usec = 0 ;
> >> >> >
> >> >> >rt = select(v4l2Fd + 1, &fds, NULL, NULL, &tv) ;
> >> >> >LOGD("The value of select return : %d\n", rt) ;
> >> >> >
> >> >> >/** for debug
> >> >> >if(V4L2_NOERROR != v4l2ReadFrame()){
> >> >> >LOGE("READ ERROR") ;
> >> >> >}
> >>
[PATCH] tuner-xc2028: Fix 7 MHz DVB-T when used with zl10353 demod
All,
The following is a patch that gets 7 MHz DVB-T working for the Leadtek
DVR3100 H.
Any comments?
Regards,
Andy
Signed-off-by: Andy Walls
Tested-by: Terry Wu
diff -r fad35ab59848 linux/drivers/media/common/tuners/tuner-xc2028.c
--- a/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Jun 05 08:42:27
2009 -0400
+++ b/linux/drivers/media/common/tuners/tuner-xc2028.c Tue Jun 09 20:10:06
2009 -0400
@@ -1099,8 +1099,13 @@
}
/* All S-code tables need a 200kHz shift */
- if (priv->ctrl.demod)
+ if (priv->ctrl.demod) {
demod = priv->ctrl.demod + 200;
+ /* Terry Wu */
+ if (priv->ctrl.demod == XC3028_FE_ZARLINK456 &&
+ bw == BANDWIDTH_7_MHZ)
+ demod += 500;
+ }
return generic_set_freq(fe, p->frequency,
T_DIGITAL_TV, type, 0, demod);
--
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: AVerTV Volar Black HD: i2c oops in warm state on mips
On 06/10/2009 01:39 AM, Jan Nikitenko wrote: Solved with "[PATCH] af9015: fix stack corruption bug". Jan, Thank you very much. I reviewed your patch and seems to be correct. This error leads to the zl10353.c and there it was copied to qt1010.c and af9015.c. Probably you want also fix those and pick up credits :) regards Antti -- http://palosaari.fi/ -- 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] af9015: fix stack corruption bug
On 06/10/2009 01:31 AM, Jan Nikitenko wrote: This patch fixes stack corruption bug present in af9015_eeprom_dump(): the buffer buf is one byte smaller than required - there is 4 chars for address prefix, 16*3 chars for dump of 16 eeprom bytes per line and 1 byte for zero ending the string required, i.e. 53 bytes, but only 52 are provided. The one byte missing in stack based buffer buf causes following oops on MIPS little endian platform, because i2c_adap pointer in af9015_af9013_frontend_attach() is corrupted by inlined function af9015_eeprom_dump(): Signed-off-by: Jan Nikitenko Acked-by: Antti Palosaari regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 2 changesets: 01/02: cx18: Split LeadTek PVR2100 and DVR3100 H into 2 separate card entries http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ab23b24b09ce 02/02: cx18: Add DVB-T support for the Leadtek WinFast DVR3100 H http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ad7dd34a2b2d cx18-cards.c | 79 ++ cx18-driver.c |3 +- cx18-driver.h |5 ++- cx18-dvb.c| 53 +- 4 files changed, 120 insertions(+), 20 deletions(-) Special thanks goes to Terry Wu of Leadtek who provided the missing information necessary to get DVB-T working for the Leadtek DVR 3100 H! Terry also performed the testing: 6 MHz and 8 MHz DVB-T work now; 7 MHz DVB-T can also work with a change to tuner-xc2028.c which I will post in a follow up. Rusty, This is the first of 3 cards supported by the cx18 driver with a tuner shared by both analog and digital TV. (The Toshiba Qosmio interal and the Yuan MPC718 will be 2 other cards). The cx18 driver currently has no interlock - so maybe this would be a good example case for what you were looking to pursue. I imagine the cx18 driver could implement all the interlocking itself, but I suppose you were looking at some sort of infrastructure to make the job easier for bridge drivers. 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: AVerTV Volar Black HD: i2c oops in warm state on mips
Solved with "[PATCH] af9015: fix stack corruption bug". Best regards, Jan -- 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] af9015: fix stack corruption bug
This patch fixes stack corruption bug present in af9015_eeprom_dump():
the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 are provided.
The one byte missing in stack based buffer buf causes following oops
on MIPS little endian platform, because i2c_adap pointer in
af9015_af9013_frontend_attach() is corrupted by inlined function
af9015_eeprom_dump():
CPU 0 Unable to handle kernel paging request at virtual address , epc ==
803a4488, ra == c049a1c8
Oops[#1]:
Cpu 0
$ 0 : 10003c00 803a4468
$ 4 : 8f17c600 8f067b30 0002 0038
$ 8 : 0001 8faf3e98 11da000d 09010002
$12 : 000a
$16 : 8f17c600 8f067b68 8faf3c00 8f067c04
$20 : 8f067b9c 0100 8f067bf0 80104100
$24 : 2aba9fb0
$28 : 8f066000 8f067af0 802cbc48 c049a1c8
Hi:
Lo:
epc : 803a4488 i2c_transfer+0x20/0x104
Not tainted
ra: c049a1c8 af9013_read_reg+0x78/0xc4 [af9013]
Status: 10003c03KERNEL EXL IE
Cause : 00808008
BadVA :
PrId : 03030200 (Au1550)
Modules linked in: af9013 dvb_usb_af9015(+) dvb_usb dvb_core firmware_class
i2c_au1550 au1550_spi
Process modprobe (pid: 2757, threadinfo=8f066000, task=8fade098, tls=2aad6470)
Stack : c049f5e0 80163090 805ba880 0100 8f067bf0 d733 8f067b68 8faf3c00
8f067c04 c049a1c8 80163bc0 8056a630 8f067b40 80163224 80569fc8 8f0033d7
0038 80140003 8f067b2c 00010038 c0420001 8f067b28 c049f5e0 0004
0004 c049a524 c049d5a8 c049d5a8 803a6700 8f17c600
c042a7a4 8f17c600 c042a7a4 c049c924 0002 613a6c00
...
Call Trace:
[<803a4488>] i2c_transfer+0x20/0x104
[] af9013_read_reg+0x78/0xc4 [af9013]
[] af9013_read_reg_bits+0x2c/0x70 [af9013]
[] af9013_attach+0x98/0x65c [af9013]
[] af9015_af9013_frontend_attach+0x214/0x67c [dvb_usb_af9015]
[] dvb_usb_adapter_frontend_init+0x20/0x12c [dvb_usb]
[] dvb_usb_device_init+0x374/0x6b0 [dvb_usb]
[] af9015_usb_probe+0x4fc/0xfcc [dvb_usb_af9015]
[<80381024>] usb_probe_interface+0xbc/0x218
[<803227fc>] driver_probe_device+0x12c/0x30c
[<80322a80>] __driver_attach+0xa4/0xac
[<80321ed0>] bus_for_each_dev+0x60/0xd0
[<8032162c>] bus_add_driver+0x1e8/0x2a8
[<80322cdc>] driver_register+0x7c/0x17c
[<80380d30>] usb_register_driver+0xa0/0x12c
[] af9015_usb_module_init+0x30/0x6c [dvb_usb_af9015]
[<8010d2a4>] __kprobes_text_end+0x3c/0x1f4
[<80167150>] sys_init_module+0xb8/0x1cc
[<80102370>] stack_done+0x20/0x3c
Code: afb10018 703f 00808021 <8c43> 703f 1060002d 00c09021
8f830014 3c02efff
Signed-off-by: Jan Nikitenko
---
linux/drivers/media/dvb/dvb-usb/af9015.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -r cff06234b725 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Sun May 31 23:07:01 2009 +0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Wed Jun 10 00:25:53 2009 +0200
@@ -541,7 +541,7 @@
/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
{
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
--
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 RFC] adding support for setting bus parameters in sub device
email: m-kariche...@ti.com
>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Tuesday, June 09, 2009 5:03 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; Muralidharan Karicheri
>Subject: Re: [PATCH RFC] adding support for setting bus parameters in sub
>device
>
>On Tuesday 09 June 2009 22:55:53 m-kariche...@ti.com wrote:
>> From: Muralidharan Karicheri
>>
>> re-sending with RFC in the header
>>
>> This patch adds support for setting bus parameters such as bus type
>> (BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
>> and polarities (vsync, hsync, field etc) in sub device. This allows
>> bridge driver to configure the sub device for a specific set of bus
>> parameters through s_bus() function call.
>>
>> Reviewed By "Hans Verkuil".
>> Signed-off-by: Muralidharan Karicheri
>> ---
>> Applies to v4l-dvb repository
>>
>> include/media/v4l2-subdev.h | 36
>> 1 files changed, 36 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
>> index 1785608..c1cfb3b 100644
>> --- a/include/media/v4l2-subdev.h
>> +++ b/include/media/v4l2-subdev.h
>> @@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
>> u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
>service found
>> */ };
>>
>> +/*
>> + * Some sub-devices are connected to the bridge device through a bus
>> that + * carries * the clock, vsync, hsync and data. Some interfaces such
>> as BT.656 + * carries the sync embedded in the data where as others have
>> separate line + * carrying the sync signals. The structure below is used
>> by bridge driver to + * set the desired bus parameters in the sub device
>> to work with it. + */
>> +enum v4l2_subdev_bus_type {
>> +/* BT.656 interface. Embedded sync */
>> +V4L2_SUBDEV_BUS_BT_656,
>> +/* BT.1120 interface. Embedded sync */
>> +V4L2_SUBDEV_BUS_BT_1120,
>> +/* 8 bit muxed YCbCr bus, separate sync and field signals */
>> +V4L2_SUBDEV_BUS_YCBCR_8,
>> +/* 16 bit YCbCr bus, separate sync and field signals */
>> +V4L2_SUBDEV_BUS_YCBCR_16,
>
>Hmm, what do you mean with "8 bit muxed YCbCr bus"? It's not clear to me
>what the format of these YCBCR bus types is exactly.
>
[MK] For YCbCr16, there is separate bus to carry Y and CbCr data, where as on
YCbCr8, both gets multiplexed over same 8 bit bus (Y, Cb, Y, Cr, Y, Cb The
difference between V4L2_SUBDEV_BUS_BT_656 and V4L2_SUBDEV_BUS_YCBCR_8 is that
sync is embedded with data in the former, where as there is dedicated sync
lines for the latter.
>> +/* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
>> +V4L2_SUBDEV_BUS_RAW_BAYER
>> +};
>> +
>> +struct v4l2_subdev_bus {
>> +enum v4l2_subdev_bus_type type;
>> +u8 width;
>> +/* 0 - active low, 1 - active high */
>> +unsigned pol_vsync:1;
>> +/* 0 - active low, 1 - active high */
>> +unsigned pol_hsync:1;
>> +/* 0 - low to high , 1 - high to low */
>> +unsigned pol_field:1;
>> +/* 0 - sample at falling edge , 1 - sample at rising edge */
>> +unsigned pol_pclock:1;
>> +/* 0 - active low , 1 - active high */
>> +unsigned pol_data:1;
>> +};
>> +
>> /* Sub-devices are devices that are connected somehow to the main bridge
>> device. These devices are usually audio/video
>> muxers/encoders/decoders or sensors and webcam controllers.
>> @@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
>> int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
>> int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
>> long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
>> +int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
>
>Make this 'const struct v4l2_subdev_bus *bus'.
>
Ok.
>> #ifdef CONFIG_VIDEO_ADV_DEBUG
>> int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
>> *reg); int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
>> *reg);
>
>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
Re: [PATCH RFC] adding support for setting bus parameters in sub device
On Tuesday 09 June 2009 23:03:01 Hans Verkuil wrote:
> On Tuesday 09 June 2009 22:55:53 m-kariche...@ti.com wrote:
> > From: Muralidharan Karicheri
> >
> > re-sending with RFC in the header
> >
> > This patch adds support for setting bus parameters such as bus type
> > (BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
> > and polarities (vsync, hsync, field etc) in sub device. This allows
> > bridge driver to configure the sub device for a specific set of bus
> > parameters through s_bus() function call.
> >
> > Reviewed By "Hans Verkuil".
> > Signed-off-by: Muralidharan Karicheri
> > ---
> > Applies to v4l-dvb repository
> >
> > include/media/v4l2-subdev.h | 36
> > 1 files changed, 36 insertions(+),
> > 0 deletions(-)
> >
> > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > index 1785608..c1cfb3b 100644
> > --- a/include/media/v4l2-subdev.h
> > +++ b/include/media/v4l2-subdev.h
> > @@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
> > u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
> > service found
> > */ };
> >
> > +/*
> > + * Some sub-devices are connected to the bridge device through a bus
> > that + * carries * the clock, vsync, hsync and data. Some interfaces
> > such as BT.656 + * carries the sync embedded in the data where as
> > others have separate line + * carrying the sync signals. The structure
> > below is used by bridge driver to + * set the desired bus parameters in
> > the sub device to work with it. + */
> > +enum v4l2_subdev_bus_type {
> > + /* BT.656 interface. Embedded sync */
> > + V4L2_SUBDEV_BUS_BT_656,
> > + /* BT.1120 interface. Embedded sync */
> > + V4L2_SUBDEV_BUS_BT_1120,
> > + /* 8 bit muxed YCbCr bus, separate sync and field signals */
> > + V4L2_SUBDEV_BUS_YCBCR_8,
> > + /* 16 bit YCbCr bus, separate sync and field signals */
> > + V4L2_SUBDEV_BUS_YCBCR_16,
>
> Hmm, what do you mean with "8 bit muxed YCbCr bus"? It's not clear to me
> what the format of these YCBCR bus types is exactly.
>
> > + /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
> > + V4L2_SUBDEV_BUS_RAW_BAYER
> > +};
> > +
> > +struct v4l2_subdev_bus {
> > + enum v4l2_subdev_bus_type type;
> > + u8 width;
> > + /* 0 - active low, 1 - active high */
> > + unsigned pol_vsync:1;
> > + /* 0 - active low, 1 - active high */
> > + unsigned pol_hsync:1;
> > + /* 0 - low to high , 1 - high to low */
> > + unsigned pol_field:1;
> > + /* 0 - sample at falling edge , 1 - sample at rising edge */
> > + unsigned pol_pclock:1;
> > + /* 0 - active low , 1 - active high */
> > + unsigned pol_data:1;
> > +};
> > +
> > /* Sub-devices are devices that are connected somehow to the main
> > bridge device. These devices are usually audio/video
> > muxers/encoders/decoders or sensors and webcam controllers.
> > @@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
> > int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
> > int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
> > long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
> > + int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
>
> Make this 'const struct v4l2_subdev_bus *bus'.
And move it to the video ops. This op is only relevant for video, after all.
Yes, I know I said to add it to core initially; so sue me :-)
Regards,
Hans
>
> > #ifdef CONFIG_VIDEO_ADV_DEBUG
> > int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
> > *reg); int (*s_register)(struct v4l2_subdev *sd, struct
> > v4l2_dbg_register *reg);
>
> 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
Re: [PATCH RFC] adding support for setting bus parameters in sub device
On Tuesday 09 June 2009 22:55:53 m-kariche...@ti.com wrote:
> From: Muralidharan Karicheri
>
> re-sending with RFC in the header
>
> This patch adds support for setting bus parameters such as bus type
> (BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
> and polarities (vsync, hsync, field etc) in sub device. This allows
> bridge driver to configure the sub device for a specific set of bus
> parameters through s_bus() function call.
>
> Reviewed By "Hans Verkuil".
> Signed-off-by: Muralidharan Karicheri
> ---
> Applies to v4l-dvb repository
>
> include/media/v4l2-subdev.h | 36
> 1 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 1785608..c1cfb3b 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
> u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
> service found
> */ };
>
> +/*
> + * Some sub-devices are connected to the bridge device through a bus
> that + * carries * the clock, vsync, hsync and data. Some interfaces such
> as BT.656 + * carries the sync embedded in the data where as others have
> separate line + * carrying the sync signals. The structure below is used
> by bridge driver to + * set the desired bus parameters in the sub device
> to work with it. + */
> +enum v4l2_subdev_bus_type {
> + /* BT.656 interface. Embedded sync */
> + V4L2_SUBDEV_BUS_BT_656,
> + /* BT.1120 interface. Embedded sync */
> + V4L2_SUBDEV_BUS_BT_1120,
> + /* 8 bit muxed YCbCr bus, separate sync and field signals */
> + V4L2_SUBDEV_BUS_YCBCR_8,
> + /* 16 bit YCbCr bus, separate sync and field signals */
> + V4L2_SUBDEV_BUS_YCBCR_16,
Hmm, what do you mean with "8 bit muxed YCbCr bus"? It's not clear to me
what the format of these YCBCR bus types is exactly.
> + /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
> + V4L2_SUBDEV_BUS_RAW_BAYER
> +};
> +
> +struct v4l2_subdev_bus {
> + enum v4l2_subdev_bus_type type;
> + u8 width;
> + /* 0 - active low, 1 - active high */
> + unsigned pol_vsync:1;
> + /* 0 - active low, 1 - active high */
> + unsigned pol_hsync:1;
> + /* 0 - low to high , 1 - high to low */
> + unsigned pol_field:1;
> + /* 0 - sample at falling edge , 1 - sample at rising edge */
> + unsigned pol_pclock:1;
> + /* 0 - active low , 1 - active high */
> + unsigned pol_data:1;
> +};
> +
> /* Sub-devices are devices that are connected somehow to the main bridge
> device. These devices are usually audio/video
> muxers/encoders/decoders or sensors and webcam controllers.
> @@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
> int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
> int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
> long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
> + int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
Make this 'const struct v4l2_subdev_bus *bus'.
> #ifdef CONFIG_VIDEO_ADV_DEBUG
> int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
> *reg); int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
> *reg);
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
[PATCH RFC] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri
re-sending with RFC in the header
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By "Hans Verkuil".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the bridge device through a bus that
+ * carries * the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used by bridge driver to
+ * set the desired bus parameters in the sub device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+ int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
--
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] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By "Hans Verkuil".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the bridge device through a bus that
+ * carries * the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used by bridge driver to
+ * set the desired bus parameters in the sub device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+ int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
--
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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
DVB-S (-S2?), CI, CAM, Irdeto (Dragon/T-Rex?)
Hi all, I've been trying to put together a recomendation for the right combination of DVB-S (or S2?), CI, and CAM that can handle Irdeto encryption but after days of searching and finding lots of little pieces of information, I have not been able to find any examples of people running the right combinations of hardware running on Linux. There's plenty examples of it running on other platforms (MCE etc.) but finding the right combination of Tuner Card + CI, and CI + CAM that is all supported on Linux is proving to be a problem. Is any body running a Linux setup based on this? I'd really appreciate any feedback from your valuable experience as I'm really not able to find any examples of people saying "I have this working". Many thanks in advance. Regards -- Brad. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
On Tue, 9 Jun 2009, Mauro Carvalho Chehab wrote: > Em Tue, 9 Jun 2009 18:08:38 +0200 > Hans Verkuil escreveu: > > > > > > Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the > > > > UVC driver and implement a JPEG compression quality control later, or > > > > would you prefer the driver not to implement VIDIOC_S_JPEGCOMP at all ? > > > > As there are existing applications using that ioctl a few users are > > > > pushing for VIDIOC_S_JPEGCOMP support. > > > > > > I prefer the later. Adding a new ioctl support just to deprecate it on > > > the next kernel doesn't seem nice. Let's add directly the newer controls > > > and add a patch marking this as deprecated. > > > > I'm not sure whether we can deprecate JPEGCOMP. It is used in too many > > places. Perhaps we should create a set of JPEG controls that match what is > > in v4l2_jpegcompression and convert all the drivers that use JPEGCOMP to > > these new controls. Then the v4l core can map S/G_JPEGCOMP ioctls to a set > > of control read/writes. I'm working on string control support, so that will > > allow us to handle the APP_data and COM_data fields. > > This seems to be the correct approach. Implement it as controls, and let > video_ioctl2 to handle the calls to the legacy ioctls, while marking it as > deprecate. One problem is that COM and APP segment actually have a string of bytes associated with them. Right now we only have boolean and interger controls. There is no way to set a control to the 32-bytes you want put into a APP segment. Now, if we added NUL terminated string and fixed length byte arrays as control types this could be done. I know that's something I've mentioned before. It would also be a step to allowing drivers to export metadata about captured images (exposured info, focus tracking, etc.) via a control-like interface. -- 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: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth wrote: 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? Devin 30db for the top end of ATSC sounds about right. David, when you ran the windows signal monitor - did it claim QAM64 or 256 when it was reporting 30db? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev
Em Tue, 9 Jun 2009 18:15:41 +0200 Hans Verkuil escreveu: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev for the > following: > > - v4l-dvb: replace the v4l2_i2c_new_*subdev* functions with > v4l2_i2c_new_subdev() No, please! Let's keep the previously agreed strategy of not changing KABI on 2.6.31, in order to help fixing bug fixes that may eventually be present on 2.6.30 due to the large amount of changes due to V4L2 dev/subdev and I2C. We did a really large set of changes on 2.6.30, due to all those dev/subdev stuff. By deprecating functions that will be added on 2.6.30 on the next version (2.6.31), without even waiting for 2.6.30 regression list is not ok. Please come again with this only at the end of 2.6.31 kernel cycle. > - v4l-dvb: add the s_config call to the core ops > - v4l2-device: fix incorrect kernel check > - v4l-dvb: add v4l2_i2c_new_subdev_board call If those are independent of the previous one, and are just adding new code, I'm ok on merging they. Yet, on a quick look at the the diff, it seems that they are changing the behavior of the existing functions [1]. Please double check and be sure that the diff will reflect just the new code addition. [1] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev/rev/ccc05f10e075 > - v4l2: rename V4L2_I2C_ADDRS to I2C_ADDRS This one is OK, but I prefer to do this cleanup also later, to avoid needing to do backports if regressions are found close to this code 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
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth wrote: > > 40db. > > -- > Steven Toth - Kernel Labs > http://www.kernellabs.com > Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? 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: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 2:52 PM, David Ward wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. 39 is very good, exceptional. And did they do as I suggested, which is measure db across the high channels? ... and ideally against your problematic channel? I assume not. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 2:52 PM, David Ward wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. Devin 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 2:52 PM, David Ward wrote: > On 06/09/2009 10:24 AM, Steven Toth wrote: >> >> David has called out Comcast to review his installation. > > After replacing all the connectors and some cables from the pole all the way > to the outlet, their meter ultimately showed 39-40dB at the outlet. My card > is showing the same SNR values as before. Go figure. > I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. 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 2/10 - v2] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
Incorporated review comments against previous patch
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
drivers/media/video/davinci/ccdc_hw_device.h | 110 ++
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include
+#include
+#include
+#include
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* Pointer to function to enable or disable ccdc */
+ void (*enable) (int en);
+ /* reset sbl. only for 6446 */
+ void (*reset) (void);
+ /* enable output to sdram */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw parameters */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+ int (*set_params) (void *params);
+ /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+ int (*get_params) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(u32 *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ u32 (*get_pixel_format) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixel_format) (u32 pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query CCDC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set CCDC control */
+ int (*set_control)(struct v4l2_control *ctrl);
+ /* Get CCDC control */
+ int (*get_control)(struct v4l2_control *ctrl);
+
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[32];
+ /* module owner */
+ struct module *owner;
+ /* hw ops */
+ struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register & unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
+
+#endif
+#endif
--
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.kerne
RE: [PATCH 5/10 - v2] ccdc hw device header file for vpfe capture
Please ignore this, it has wrong series number. I will re-send it soon
email: m-kariche...@ti.com
>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Tuesday, June 09, 2009 2:50 PM
>To: linux-media@vger.kernel.org
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
>Karicheri, Muralidharan
>Subject: [PATCH 5/10 - v2] ccdc hw device header file for vpfe capture
>
>From: Muralidharan Karicheri
>
>CCDC hw device header file
>
>Adds ccdc hw device header for vpfe capture driver
>
>Incorporated review comments against previous patch
>
>Reviewed By "Hans Verkuil".
>Reviewed By "Laurent Pinchart".
>
>Signed-off-by: Muralidharan Karicheri
>---
>Applies to v4l-dvb repository
>
> drivers/media/video/davinci/ccdc_hw_device.h | 110
>++
> 1 files changed, 110 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
>
>diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
>b/drivers/media/video/davinci/ccdc_hw_device.h
>new file mode 100644
>index 000..86b9b35
>--- /dev/null
>+++ b/drivers/media/video/davinci/ccdc_hw_device.h
>@@ -0,0 +1,110 @@
>+/*
>+ * Copyright (C) 2008-2009 Texas Instruments Inc
>+ *
>+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
>USA
>+ *
>+ * ccdc device API
>+ */
>+#ifndef _CCDC_HW_DEVICE_H
>+#define _CCDC_HW_DEVICE_H
>+
>+#ifdef __KERNEL__
>+#include
>+#include
>+#include
>+#include
>+
>+/*
>+ * ccdc hw operations
>+ */
>+struct ccdc_hw_ops {
>+ /* Pointer to initialize function to initialize ccdc device */
>+ int (*open) (struct device *dev);
>+ /* Pointer to deinitialize function */
>+ int (*close) (struct device *dev);
>+ /* set ccdc base address */
>+ void (*set_ccdc_base)(void *base, int size);
>+ /* Pointer to function to enable or disable ccdc */
>+ void (*enable) (int en);
>+ /* reset sbl. only for 6446 */
>+ void (*reset) (void);
>+ /* enable output to sdram */
>+ void (*enable_out_to_sdram) (int en);
>+ /* Pointer to function to set hw parameters */
>+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
>+ /* get interface parameters */
>+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
>+ /*
>+ * Pointer to function to set parameters. Used
>+ * for implementing VPFE_S_CCDC_PARAMS
>+ */
>+ int (*set_params) (void *params);
>+ /*
>+ * Pointer to function to get parameter. Used
>+ * for implementing VPFE_G_CCDC_PARAMS
>+ */
>+ int (*get_params) (void *params);
>+ /* Pointer to function to configure ccdc */
>+ int (*configure) (void);
>+
>+ /* Pointer to function to set buffer type */
>+ int (*set_buftype) (enum ccdc_buftype buf_type);
>+ /* Pointer to function to get buffer type */
>+ enum ccdc_buftype (*get_buftype) (void);
>+ /* Pointer to function to set frame format */
>+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
>+ /* Pointer to function to get frame format */
>+ enum ccdc_frmfmt (*get_frame_format) (void);
>+ /* enumerate hw pix formats */
>+ int (*enum_pix)(u32 *hw_pix, int i);
>+ /* Pointer to function to set buffer type */
>+ u32 (*get_pixel_format) (void);
>+ /* Pointer to function to get pixel format. */
>+ int (*set_pixel_format) (u32 pixfmt);
>+ /* Pointer to function to set image window */
>+ int (*set_image_window) (struct v4l2_rect *win);
>+ /* Pointer to function to set image window */
>+ void (*get_image_window) (struct v4l2_rect *win);
>+ /* Pointer to function to get line length */
>+ unsigned int (*get_line_length) (void);
>+
>+ /* Query CCDC control IDs */
>+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
>+ /* Set CCDC control */
>+ int (*set_control)(struct v4l2_control *ctrl);
>+ /* Get CCDC control */
>+ int (*get_control)(struct v4l2_control *ctrl);
>+
>+ /* Pointer to function to set frame buffer address */
>+ void (*setfbaddr) (unsigned long addr);
>+ /* Pointer to function to get field id */
>+ int (*getfid) (void);
>+};
>+
>+struct ccdc_hw_device {
>+ /* ccdc device name */
>+ char name[32];
>+ /* module owner */
>+ struct module
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. -- 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/10 - v2] common vpss module for video drivers
From: Muralidharan Karicheri
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
This is a new module added for vpss library functions that are
used configuring vpss system module. All video drivers will
include vpss.h header and call functions defined in this module
to configure vpss system module.
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpss.c | 291
include/media/davinci/vpss.h | 69 +
2 files changed, 360 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpss.c
create mode 100644 include/media/davinci/vpss.h
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
new file mode 100644
index 000..9480256
--- /dev/null
+++ b/drivers/media/video/davinci/vpss.c
@@ -0,0 +1,291 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * 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.
+ *
+ * common vpss driver for all video drivers.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* DM644x defines */
+#define DM644X_SBL_PCR_VPSS(4)
+
+/* vpss BL register offsets */
+#define DM355_VPSSBL_CCDCMUX 0x1c
+/* vpss CLK register offsets */
+#define DM355_VPSSCLK_CLKCTRL 0x04
+/* masks and shifts */
+#define VPSS_HSSISEL_SHIFT 4
+
+/*
+ * vpss operations. Depends on platform. Not all functions are available
+ * on all platforms. The api, first check if a functio is available before
+ * invoking it. In the probe, the function ptrs are intialized based on
+ * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
+ */
+struct vpss_hw_ops {
+ /* enable clock */
+ int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
+ /* select input to ccdc */
+ void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
+ /* clear wbl overlflow bit */
+ int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+};
+
+/* vpss configuration */
+struct vpss_oper_config {
+ __iomem void *vpss_bl_regs_base;
+ __iomem void *vpss_regs_base;
+ struct resource *r1;
+ resource_size_t len1;
+ struct resource *r2;
+ resource_size_t len2;
+ char vpss_name[32];
+ spinlock_t vpss_lock;
+ struct vpss_hw_ops hw_ops;
+};
+
+static struct vpss_oper_config oper_cfg;
+
+/* register access routines */
+static inline u32 bl_regr(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline void bl_regw(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline u32 vpss_regr(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base + offset);
+}
+
+static inline void vpss_regw(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+}
+
+static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ bl_regw(src_sel << VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
+}
+
+int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ if (!oper_cfg.hw_ops.select_ccdc_source)
+ return -1;
+
+ dm355_select_ccdc_source(src_sel);
+ return 0;
+}
+EXPORT_SYMBOL(vpss_select_ccdc_source);
+
+static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+ u32 mask = 1, val;
+
+ if (wbl_sel < VPSS_PCR_AEW_WBL_0 ||
+ wbl_sel > VPSS_PCR_CCDC_WBL_O)
+ return -1;
+
+ /* writing a 0 clear the overflow */
+ mask = ~(mask << wbl_sel);
+ val = bl_regr(DM644X_SBL_PCR_VPSS) & mask;
+ bl_regw(val, DM644X_SBL_PCR_VPSS);
+ return 0;
+}
+
+int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+ if (!oper_cfg.hw_ops.clear_wbl_overflow)
+ return -1;
+
+ return oper_cfg.hw_ops.clear_wbl_overflow(wbl_sel);
+}
+EXPORT_SYMBOL(vpss_clear_wbl_overflow);
+
+/*
+ * dm355_enable_clock - Enable VPSS Clock
+ * @clock_sel: CLock to be enabled/disabled
+ * @en: enable/disable flag
+ *
+ * This is called to enable or disable a vpss clock
+ */
+static int dm355_enable_clock(enum vpss_clock_sel clock_sel, int en)
+{
+ unsigned long flag
[PATCH 9/10 - v2] remove outdated video driver files of dm6446
From: Muralidharan Karicheri
Remove outdated driver files from davinci git tree
No change from last patch
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to Davinci GIT Tree
drivers/media/video/ccdc_davinci.c | 124
drivers/media/video/davinci_vpfe.c | 1136
include/media/ccdc_davinci.h | 144 -
include/media/davinci_vpfe.h | 121
4 files changed, 0 insertions(+), 1525 deletions(-)
delete mode 100644 drivers/media/video/ccdc_davinci.c
delete mode 100644 drivers/media/video/davinci_vpfe.c
delete mode 100644 include/media/ccdc_davinci.h
delete mode 100644 include/media/davinci_vpfe.h
diff --git a/drivers/media/video/ccdc_davinci.c
b/drivers/media/video/ccdc_davinci.c
deleted file mode 100644
index d3cd333..000
--- a/drivers/media/video/ccdc_davinci.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- *
- *
- * Copyright (C) 2006 Texas Instruments Inc
- *
- * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-/* ccdc_davinci.c */
-
-#include
-#define debug_print(x...) //printk(x)
-void ccdc_reset()
-{
- int i;
- /* disable CCDC */
- ccdc_enable(0);
- /* set all registers to default value */
- for (i = 0; i <= 0x94; i += 4) {
- regw(0, i);
- }
- regw(0, PCR);
- regw(0, SYN_MODE);
- regw(0, HD_VD_WID);
- regw(0, PIX_LINES);
- regw(0, HORZ_INFO);
- regw(0, VERT_START);
- regw(0, VERT_LINES);
- regw(0x00ff, CULLING);
- regw(0, HSIZE_OFF);
- regw(0, SDOFST);
- regw(0, SDR_ADDR);
- regw(0, VDINT);
- regw(0, REC656IF);
- regw(0, CCDCFG);
- regw(0, FMTCFG);
- regw(0, VP_OUT);
-}
-
-void ccdc_setwin(ccdc_params_ycbcr * params)
-{
- int horz_start, horz_nr_pixels;
- int vert_start, vert_nr_lines;
-
- /* configure horizonal and vertical starts and sizes */
- horz_start = params->win.left << 1;
- horz_nr_pixels = (params->win.width <<1) - 1;
- regw((horz_start << 16) | horz_nr_pixels, HORZ_INFO);
-
- vert_start = params->win.top;
-
- if (params->frm_fmt == CCDC_FRMFMT_INTERLACED) {
- vert_nr_lines = (params->win.height >> 1) - 1;
- vert_start >>= 1;
- } else {
- vert_nr_lines = params->win.height - 1;
- }
- regw((vert_start << 16) | vert_start, VERT_START);
- regw(vert_nr_lines, VERT_LINES);
-}
-
-void ccdc_config_ycbcr(ccdc_params_ycbcr * params)
-{
- u32 syn_mode;
-
- /* first reset the CCDC */
- /* all registers have default values after reset */
- /* This is important since we assume default values to be set in */
- /* a lot of registers that we didn't touch */
- ccdc_reset();
-
- /* configure pixel format */
- syn_mode = (params->pix_fmt & 0x3) << 12;
-
- /* configure video frame format */
- syn_mode |= (params->frm_fmt & 0x1) << 7;
-
- /* setup BT.656 sync mode */
- if (params->bt656_enable) {
- regw(3, REC656IF);
-
- /* configure the FID, VD, HD pin polarity */
- /* fld,hd pol positive, vd negative, 8-bit pack mode */
- syn_mode |= 0x0F04;
- } else {/* y/c external sync mode */
- syn_mode |= ((params->fid_pol & 0x1) << 4);
- syn_mode |= ((params->hd_pol & 0x1) << 3);
- syn_mode |= ((params->vd_pol & 0x1) << 2);
- }
-
- /* configure video window */
- ccdc_setwin(params);
-
- /* configure the order of y cb cr in SD-RAM */
- regw((params->pix_order << 11) | 0x8000, CCDCFG);
-
- /* configure the horizontal line offset */
- /* this is done by rounding up width to a multiple of 16 pixels */
- /* and multiply by two to account for y:cb:cr 4:2:2 data */
- regw(((params->win.width * 2) + 31) & 0xffe0, HSIZE_OFF);
-
- /* configure the memory line offset */
- if (params->buf_type == CCDC_BUFTYPE_FLD_INTERLEAVED) {
- /* two fields are interleaved in memory */
- regw(0x0249, SDOFST);
- }
- /* enable ou
[PATCH 8/10 - v2] DM6446 platform changes for vpfe capture driver
From: Muralidharan Karicheri
DM644x platform and board setup
This adds plarform and board setup changes required to support
vpfe capture driver on DM644x
Added registration of vpss platform driver based on last comment
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm644x-evm.c| 68 ++-
arch/arm/mach-davinci/dm644x.c | 56 ++
arch/arm/mach-davinci/include/mach/dm644x.h |2 +
3 files changed, 124 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d9d4045..13b73a7 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
#include
#include
#include
-
+#include
+#include
#include
#include
@@ -195,6 +196,57 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
+#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 = "SVIDEO",
+ .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 v4l2_routing 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[] = {
+ {
+ .name = "tvp5146",
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ },
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = "DM6446 EVM",
+ .ccdc = "DM6446 CCDC",
+};
+
static struct platform_device rtc_dev = {
.name = "rtc_davinci_evm",
.id = -1,
@@ -447,6 +499,13 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+#define TVP5146_I2C_ADDR (0x5D)
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
/*
* MSP430 supports RTC, card detection, input from IR remote, and
* a bit more. It triggers interrupts on GPIO(7) from pressing
@@ -558,9 +617,12 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO("24c256", 0x50),
.platform_data = &eeprom_info,
},
+ {
+ I2C_BOARD_INFO("tvp5146", TVP5146_I2C_ADDR),
+ .platform_data = &tvp5146_pdata,
+ },
/* ALSO:
* - tvl320aic33 audio codec (0x1b)
-* - tvp5146 video decoder (0x5d)
*/
};
@@ -591,6 +653,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init
davinci_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm644x_set_vpfe_config(&vpfe_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 1b3aec8..444c4df 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -549,6 +549,59 @@ static struct platform_device dm644x_edma_device = {
.resource = edma_resources,
};
+static struct resource dm644x_vpss_resources[] = {
+ {
+ /* VPSS Base address */
+ .name = "vpss",
+ .start = 0x01c73400,
+ .end= 0x01c73400 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm644x_vpss_device = {
+ .name = "vpss",
+ .id = -1,
+ .dev.platform_data = "dm644x_vpss",
+ .num_resources = ARRAY_SIZE(dm644x_vpss_resources),
+ .resource = dm644x_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = IRQ_VDINT0,
+ .end= IRQ_VDINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = IRQ_VDINT1,
+
[PATCH 7/10 - v2] DM355 platform changes for vpfe capture driver
From: Muralidharan Karicheri
DM355 platform and board setup
This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.
Added registration of vpss platform driver based on last review
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm355-evm.c| 72 +++-
arch/arm/mach-davinci/dm355.c | 83
arch/arm/mach-davinci/include/mach/dm355.h |2 +
arch/arm/mach-davinci/include/mach/mux.h |9 +++
4 files changed, 163 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5ac2f56..cf87e21 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -134,12 +136,23 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
+#define TVP5146_I2C_ADDR 0x5D
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
static struct i2c_board_info dm355evm_i2c_info[] = {
- { I2C_BOARD_INFO("dm355evm_msp", 0x25),
+ { I2C_BOARD_INFO("dm355evm_msp", 0x25),
.platform_data = dm355evm_mmcsd_gpios,
- /* plus irq */ },
+ },
+ {
+ I2C_BOARD_INFO("tvp5146", TVP5146_I2C_ADDR),
+ .platform_data = &tvp5146_pdata,
+ },
+ /* { plus irq }, */
/* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
- /* { I2C_BOARD_INFO("tvp5146", 0x5d), }, */
};
static void __init evm_init_i2c(void)
@@ -178,6 +191,57 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
};
+#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 = "SVIDEO",
+ .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 v4l2_routing 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[] = {
+ {
+ .name = "tvp5146",
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = "DM355 EVM",
+ .ccdc = "DM355 CCDC",
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
&dm355evm_dm9000,
&davinci_nand_device,
@@ -189,6 +253,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm355_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm355_set_vpfe_config(&vpfe_cfg);
dm355_init();
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9baeed3..3263af8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@ INT_CFG(DM355, INT_EDMA_TC1_ERR, 4,1,1,
false)
EVT_CFG(DM355, EVT8_ASP1_TX,0,1,0, false)
EVT_CFG(DM355, EVT9_ASP1_RX,1,1,0, false)
EVT_CFG(DM355, EVT26_MMC0_RX, 2,1,0, false)
+
+MUX_CFG(DM355, VIN_PCLK, 0, 14,1,1, false)
+MUX_CFG(DM355, VIN_CAM_WEN,0, 13,1,1, false)
+MUX_CFG(DM355, VIN_CAM_VD, 0, 12,1,1, false)
+MUX_CFG(DM355, VIN_CAM_HD, 0, 11,1,1, false)
+MUX_CFG(DM355, VIN_YIN_EN, 0, 10,1,1, false)
+MUX_CFG(DM355, VIN_CINL_EN,0, 0, 0xff, 0x55,false)
+MUX_CFG(DM355, VIN_CINH_EN,0, 8, 3,3, false)
#endif
};
@@ -623,6 +631,67 @@ static struct platform_device dm355_edma_device = {
.resource = edma_resources,
};
+static struct resource dm355_vpss_resources[] = {
+ {
+ /* VPSS BL Base address */
[PATCH 6/10 - v2] Makefile and config files for vpfe capture driver
From: Muralidharan Karicheri Makefile and config files for the driver This adds Makefile and Kconfig changes to build vpfe capture driver. Added configuration variable for vpss driver based on last review Reviewed By "Hans Verkuil". Reviewed By "Laurent Pinchart". Signed-off-by: Muralidharan Karicheri --- Applies to v4l-dvb repository drivers/media/video/Kconfig | 49 ++ drivers/media/video/Makefile |1 + drivers/media/video/davinci/Makefile |9 ++ 3 files changed, 59 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9d48da2..ee6806c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -479,6 +479,55 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. +config VIDEO_VPSS_SYSTEM + tristate "VPSS System module driver" + depends on ARCH_DAVINCI + help + Support for vpss system module for video driver + default y + +config VIDEO_VPFE_CAPTURE + tristate "VPFE Video Capture Driver" + depends on VIDEO_V4L2 && ARCH_DAVINCI + select VIDEOBUF_DMA_CONTIG + help + Support for DM VPFE based frame grabber. This is the + common V4L2 module for following DMXXX SoCs from Texas + Instruments:- DM6446 & DM355. + + To compile this driver as a module, choose M here: the + module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate "DM6446 CCDC HW module" + depends on ARCH_DAVINCI_DM644x && VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate "DM355 CCDC HW module" + depends on ARCH_DAVINCI_DM355 && VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DM355 CCD hw module. DM355 CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from a slave decoders + + To compile this driver as a module, choose M here: the + module will be called vpfe. + source "drivers/media/video/bt8xx/Kconfig" config VIDEO_PMS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 3f1a035..bc8ac8e 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -147,6 +147,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022)+= mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o +obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ obj-$(CONFIG_VIDEO_AU0828) += au0828/ diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile new file mode 100644 index 000..b84a405 --- /dev/null +++ b/drivers/media/video/davinci/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the davinci video device drivers. +# + +# Capture: DM6446 and DM355 +obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o +obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o +obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o +obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.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 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver
From: Muralidharan Karicheri
common types used across CCDC modules
No change from last version
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
include/media/davinci/ccdc_types.h | 43
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 include/media/davinci/ccdc_types.h
diff --git a/include/media/davinci/ccdc_types.h
b/include/media/davinci/ccdc_types.h
new file mode 100644
index 000..5773874
--- /dev/null
+++ b/include/media/davinci/ccdc_types.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ **/
+#ifndef _CCDC_TYPES_H
+#define _CCDC_TYPES_H
+enum ccdc_pixfmt {
+ CCDC_PIXFMT_RAW,
+ CCDC_PIXFMT_YCBCR_16BIT,
+ CCDC_PIXFMT_YCBCR_8BIT
+};
+
+enum ccdc_frmfmt {
+ CCDC_FRMFMT_PROGRESSIVE,
+ CCDC_FRMFMT_INTERLACED
+};
+
+/* PIXEL ORDER IN MEMORY from LSB to MSB */
+/* only applicable for 8-bit input mode */
+enum ccdc_pixorder {
+ CCDC_PIXORDER_YCBYCR,
+ CCDC_PIXORDER_CBYCRY,
+};
+
+enum ccdc_buftype {
+ CCDC_BUFTYPE_FLD_INTERLEAVED,
+ CCDC_BUFTYPE_FLD_SEPARATED
+};
+#endif
--
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 5/10 - v2] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
Incorporated review comments against previous patch
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
drivers/media/video/davinci/ccdc_hw_device.h | 110 ++
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include
+#include
+#include
+#include
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* Pointer to function to enable or disable ccdc */
+ void (*enable) (int en);
+ /* reset sbl. only for 6446 */
+ void (*reset) (void);
+ /* enable output to sdram */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw parameters */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+ int (*set_params) (void *params);
+ /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+ int (*get_params) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(u32 *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ u32 (*get_pixel_format) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixel_format) (u32 pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query CCDC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set CCDC control */
+ int (*set_control)(struct v4l2_control *ctrl);
+ /* Get CCDC control */
+ int (*get_control)(struct v4l2_control *ctrl);
+
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[32];
+ /* module owner */
+ struct module *owner;
+ /* hw ops */
+ struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register & unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
+
+#endif
+#endif
--
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.kerne
[PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
From: Muralidharan Karicheri
DM355 CCDC hw module
Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.
Following are some of the major comments addressed :-
1) removed vpss configration from this module to a standalone
vpss module that can be used by other video drivers as well
2) replaced magic numbers with #defines
3) cleaned up and refractored ccdc_config_raw()
4) embedded config part of the variables inside
ccdc_params_raw to help in memcpy.
5) avoided generic names for ccdc types in include file by
prefixing with ccdc_
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm355_ccdc.c | 1161 +
drivers/media/video/davinci/dm355_ccdc_regs.h | 310 +++
include/media/davinci/dm355_ccdc.h| 336 +++
3 files changed, 1807 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm355_ccdc.c
create mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h
create mode 100644 include/media/davinci/dm355_ccdc.h
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
new file mode 100644
index 000..1e7152e
--- /dev/null
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -0,0 +1,1161 @@
+/*
+ * Copyright (C) 2005-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM355
+ * --
+ *
+ * This module is for configuring DM355 CCD controller of VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application include dm355_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ * 2) Split module parameter structure to module specific ioctl structs
+ * 3) add support for lense shading correction
+ * 4) investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include
+#include
+#include
+#include
+#include
+#include "dm355_ccdc_regs.h"
+#include "ccdc_hw_device.h"
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = 256,
+ .gb_g = 256,
+ .gr_cy = 256,
+ .b_mg = 256
+ },
+ .config_params = {
+ .datasft = 2,
+ .data_sz = CCDC_DATA_10BITS,
+ .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+ .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+ .alaw = {
+ .gama_wd = 2,
+ },
+ .blk_clamp = {
+ .sample_pixel = 1,
+ .dc_sub = 25
+ },
+ .col_pat_field0 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ .col_pat_field1 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ },
+};
+
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+ .win = CCDC_WIN_PAL,
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+
[PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
From: Muralidharan Karicheri
DM644x CCDC hw module
This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE
Following are some of the major comments addressed :-
1) removed vpss configration from this module to a standalone
vpss module that can be used by other video drivers as well
2) replaced magic numbers with #defines
3) cleaned up and refractored ccdc_config_raw()
4) embedded config part of the variables inside
ccdc_params_raw to help in memcpy.
5) avoided generic names for ccdc types in include file by
prefixing with ccdc_
Reviewed By "Hans Verkuil".
Reviewed By "Laurent Pinchart".
Signed-off-by: Muralidharan Karicheri
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm644x_ccdc.c | 876
drivers/media/video/davinci/dm644x_ccdc_regs.h | 145
include/media/davinci/dm644x_ccdc.h| 184 +
3 files changed, 1205 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm644x_ccdc.c
create mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h
create mode 100644 include/media/davinci/dm644x_ccdc.h
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
new file mode 100644
index 000..4f81f69
--- /dev/null
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -0,0 +1,876 @@
+/*
+ * Copyright (C) 2006-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM6446
+ * --
+ *
+ * This module is for configuring CCD controller of DM6446 VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Raw Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application includes dm644x_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters. This file is named DM644x so that other
+ * variants such DM6443 may be supported using the same module.
+ *
+ * TODO: Test Raw bayer parameter settings and bayer capture
+ * Split module parameter structure to module specific ioctl structs
+ * investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include
+#include
+#include
+#include
+#include
+#include "dm644x_ccdc_regs.h"
+#include "ccdc_hw_device.h"
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .config_params = {
+ .data_sz = CCDC_DATA_10BITS,
+ },
+};
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+#define CCDC_MAX_RAW_YUV_FORMATS 2
+
+/* Raw Bayer formats */
+static u32 ccdc_raw_bayer_pix_formats[] =
+ {V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SBGGR16};
+
+/* Raw YUV formats */
+static u32 ccdc_raw_yuv_pix_formats[] =
+ {V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+
+static void *__iomem ccdc_base_addr;
+static int ccdc_addr_size;
+static enum vpfe_hw_if_type ccdc_if_type;
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+ return __raw_readl(ccdc_base_addr + offset);
+}
+
+static inline void regw(u32 val, u32 offset)
+{
+ __raw_writel(val, ccdc_base_addr + offset);
+}
+
+static void ccdc
[PATCH 0/10 - v2] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
From: Muralidharan Karicheri VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446 This is the version v2 of the patch series. This is the reworked version of the driver based on comments received against the last version of the patch. +++ These patches add support for VPFE (Video Processing Front End) based video capture on DM355 and DM6446 EVMs. For more details on the hardware configuration and capabilities, please refer the vpfe_capture.c header. This patch set consists of following:- Patch 1: VPFE Capture bridge driver Patch 2: CCDC hw device header file Patch 3: DM355 CCDC hw module Patch 4: DM644x CCDC hw module Patch 5: common types used across CCDC modules Patch 6: Makefile and config files for the driver Patch 7: DM355 platform and board setup Patch 8: DM644x platform and board setup Patch 9: Remove outdated driver files from davinci git tree Patch 10: common vpss hw module for video drivers NOTE: Dependent on the TVP514x decoder driver patch for migrating the driver to sub device model from Vaibhav Hiremath Following tests are performed. 1) Capture and display video (PAL & NTSC) from tvp5146 decoder. Displayed using fbdev device driver available on davinci git tree 2) Tested with driver built statically and dynamically Muralidhara Karicheri Reviewed By "Hans Verkuil". Reviewed By "Laurent Pinchart". Signed-off-by: Muralidharan Karicheri -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Tue, 9 Jun 2009 18:08:38 +0200 Hans Verkuil escreveu: > > > Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the > > > UVC driver and implement a JPEG compression quality control later, or > > > would you prefer the driver not to implement VIDIOC_S_JPEGCOMP at all ? > > > As there are existing applications using that ioctl a few users are > > > pushing for VIDIOC_S_JPEGCOMP support. > > > > I prefer the later. Adding a new ioctl support just to deprecate it on > > the next kernel doesn't seem nice. Let's add directly the newer controls > > and add a patch marking this as deprecated. > > I'm not sure whether we can deprecate JPEGCOMP. It is used in too many > places. Perhaps we should create a set of JPEG controls that match what is > in v4l2_jpegcompression and convert all the drivers that use JPEGCOMP to > these new controls. Then the v4l core can map S/G_JPEGCOMP ioctls to a set > of control read/writes. I'm working on string control support, so that will > allow us to handle the APP_data and COM_data fields. This seems to be the correct approach. Implement it as controls, and let video_ioctl2 to handle the calls to the legacy ioctls, while marking it as deprecate. 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
Green screen and barf with HP Webcam (15b8:6002)
I've been trying to get an HP webcam (usbid 15b8:6002) running on my GFs machine. She's running Ubuntu Hardy with 2.6.24-24-generic kernel. I downloaded the mercurial repo for v4l-dvb. It compiled without complaint and the modules load without complaint. I've got it running on Ubuntu Jaunty with 2.6.28-11-generic and it seems to work fine. I've been using Skype as my test platform. I noticed on Jaunty that Skype is now wrapped with the v4l1compat.so library, so I tried doing that, but the results were the same. Is there anything I can try short of upgrading my distro or kernel? James -- 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:Tue Jun 9 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11930:ed3781a79c73 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc7-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc7-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK 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: OK linux-2.6.30-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): 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: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK 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: 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build 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: [RFC] passing bus/interface parameters from bridge driver to sub device
Some typo corrected
>-Original Message-
>From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan
>Sent: Tuesday, June 09, 2009 12:51 PM
>To: Hans Verkuil
>Cc: linux-media@vger.kernel.org
>Subject: RE: [RFC] passing bus/interface parameters from bridge driver to
>sub device
>
>
>Hans,
>
>Thanks for looking into this...
>
>>>
>>> 1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
>>> the v4l2 sub-device from my vpfe capture driver. Currently the api's
>>> available doesn't allow setting platform data in the client before the
>>> sub-device's probe is called. I see that there is discussion about
>adding
>>> i2c_board_info as an argument to the api. I would need this to allow
>>> loading of sub-device from vpfe capture. I have seen patches sent by
>>> Eduardo Valentin & Guennadi Liakhovetski addressing the issue. Do you
>>> have any suggestions for use in my vpfe capture driver?
>>
>>As you have probably seen by now I've made changes to the v4l2 core that
>>make it easy to use an i2c_board_info struct when creating a subdev. So as
>>far as I can tell that solves this issue completely.
>>
>>The code is in my v4l-dvb-subdev tree.
>>
>[MK] Yes. I have been following this and will resolve this.
>>> 2) I need a common structure (preferably in i2c-subdev.h for defining
>and
>>> using bus (interface) parameters in the bridge (vpfe capture) and sub
>>> device (tvp514x or mt9t031) drivers. This will allow bridge driver to
>>> read these values from platform data and set the same in the vpfe
>capture
>>> driver and sub device drivers. Since bus parameters such as interface
>>> type (BT.656, BT.1120, Raw Bayer image data etc), polarity of various
>>> signals etc are used across bridge and sub-devices, it make sense to add
>>> it to i2c-subdev.h. Here is what I have come up with. If this support is
>>> not already planned, I would like to sent a patch for the same.
>>
>>It makes sense to define a struct in v4l2-subdev.h and a core ops to set
>it
>>(s_bus).
>>
>>However, I would pack it differently:
>>
>>struct v4l2_subdev_bus {
>> enum v4l2_subdev_bus_type type;
>> u8 width;
>> unsigned pol_vsync:1;
>> unsigned pol_hsync:1;
>> unsigned pol_field:1;
>> unsigned pol_pclock:1;
>>};
>>
>[MK] Looks good to me. So is it up to the bridge driver and sub devices to
>determine how they interpret the values of pol_xxx fields? Since same sub-
>device might work across multiple bridge drivers, it is worth documenting them
>>as given in my RFC. I would like to add one more field for data polarity :-
> unsigned pol_data:1;
>
>Will you take care of this yourself or expecting me to send a patch for the
>same?
>
>Regards,
>Murali
>>It's more concise this way.
>>
>>Regards,
>>
>> Hans
>>
>>> +/*
>>> + * Some Sub-devices are connected to the bridge device through a bus
>>> + * that carries the clock, vsync, hsync and data. Some interfaces
>>> + * such as BT.656 carries the sync embedded in the data where as others
>>> + * have seperate line carrying the sync signals. This structure is
>>> + * used by bridge driver to set the desired bus parameters in the sub
>>> + * device to work with it.
>>> + */
>>> +enum v4l2_subdev_bus_type {
>>> + /* BT.656 interface. Embedded syncs */
>>> + V4L2_SUBDEV_BUS_BT_656,
>>> + /* BT.1120 interface. Embedded syncs */
>>> + V4L2_SUBDEV_BUS_BT_1120,
>>> + /* 8 bit YCbCr muxed bus, separate sync and field id signals */
>>> + V4L2_SUBDEV_BUS_YCBCR_8,
>>> + /* 16 bit YCbCr bus, separate sync and field id signals */
>>> + V4L2_SUBDEV_BUS_YCBCR_16,
>>> + /* Raw Bayer data bus, 8 - 16 bit wide, sync signals */
>>> + V4L2_SUBDEV_BUS_RAW_BAYER
>>> +};
>>> +
>>> +/* Raw bayer data bus width */
>>> +enum v4l2_subdev_raw_bayer_data_width {
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_8BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_9BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_10BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_11BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_12BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_13BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_14BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_15BIT,
>>> + V4L2_SUBDEV_RAW_BAYER_DATA_16BIT
>>> +};
>>> +
>>> +struct v4l2_subdev_bus_params {
>>> + /* bus type */
>>> + enum v4l2_subdev_bus_type type;
>>> + /* data size for raw bayer data bus */
>>> + enum v4l2_subdev_raw_bayer_data_width width;
>>> + /* polarity of vsync. 0 - active low, 1 - active high */
>>> + u8 vsync_pol;
>>> + /* polarity of hsync. 0 - active low, 1 - active low */
>>> + u8 hsync_pol;
>>> + /* polarity of field id, 0 - low to high, 1 - high to low */
>>> + u8 fid_pol;
>>> + /* polarity of data. 0 - active low, 1 - active high */
>>> + u8 data_pol;
>>> + /* pclk polarity. 0 - sample at falling edge, 1 - sample at rising
>>edge
>>> */ +u8 pclk_pol;
>>> +};
>>> +
>>> Murali Karicheri
>>> email: m-kariche...@ti.com
>>>
>>> --
>>> To unsubscribe f
RE: [RFC] passing bus/interface parameters from bridge driver to sub device
Hans,
Thanks for looking into this...
>>
>> 1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
>> the v4l2 sub-device from my vpfe capture driver. Currently the api's
>> available doesn't allow setting platform data in the client before the
>> sub-device's probe is called. I see that there is discussion about adding
>> i2c_board_info as an argument to the api. I would need this to allow
>> loading of sub-device from vpfe capture. I have seen patches sent by
>> Eduardo Valentin & Guennadi Liakhovetski addressing the issue. Do you
>> have any suggestions for use in my vpfe capture driver?
>
>As you have probably seen by now I've made changes to the v4l2 core that
>make it easy to use an i2c_board_info struct when creating a subdev. So as
>far as I can tell that solves this issue completely.
>
>The code is in my v4l-dvb-subdev tree.
>
[MK] Yes. I have been following this and will resolve this.
>> 2) I need a common structure (preferably in i2c-subdev.h for defining and
>> using bus (interface) parameters in the bridge (vpfe capture) and sub
>> device (tvp514x or mt9t031) drivers. This will allow bridge driver to
>> read these values from platform data and set the same in the vpfe capture
>> driver and sub device drivers. Since bus parameters such as interface
>> type (BT.656, BT.1120, Raw Bayer image data etc), polarity of various
>> signals etc are used across bridge and sub-devices, it make sense to add
>> it to i2c-subdev.h. Here is what I have come up with. If this support is
>> not already planned, I would like to sent a patch for the same.
>
>It makes sense to define a struct in v4l2-subdev.h and a core ops to set it
>(s_bus).
>
>However, I would pack it differently:
>
>struct v4l2_subdev_bus {
> enum v4l2_subdev_bus_type type;
> u8 width;
> unsigned pol_vsync:1;
> unsigned pol_hsync:1;
> unsigned pol_field:1;
> unsigned pol_pclock:1;
>};
>
[MK] Looks good to me. So is it up to the bridge and sub device to determine
how they interpret the values of pol_xxx fields? Since same sub-device might
work across multiple sub device, it is worth documenting them as given in my
RFC. I would like to add one more field for data polarity :-
unsigned pol_data:1;
Will you take care of this yourself or expecting me to send a patch for the
same?
Regards,
Murali
>It's more concise this way.
>
>Regards,
>
> Hans
>
>> +/*
>> + * Some Sub-devices are connected to the bridge device through a bus
>> + * that carries the clock, vsync, hsync and data. Some interfaces
>> + * such as BT.656 carries the sync embedded in the data where as others
>> + * have seperate line carrying the sync signals. This structure is
>> + * used by bridge driver to set the desired bus parameters in the sub
>> + * device to work with it.
>> + */
>> +enum v4l2_subdev_bus_type {
>> +/* BT.656 interface. Embedded syncs */
>> +V4L2_SUBDEV_BUS_BT_656,
>> +/* BT.1120 interface. Embedded syncs */
>> +V4L2_SUBDEV_BUS_BT_1120,
>> +/* 8 bit YCbCr muxed bus, separate sync and field id signals */
>> +V4L2_SUBDEV_BUS_YCBCR_8,
>> +/* 16 bit YCbCr bus, separate sync and field id signals */
>> +V4L2_SUBDEV_BUS_YCBCR_16,
>> +/* Raw Bayer data bus, 8 - 16 bit wide, sync signals */
>> +V4L2_SUBDEV_BUS_RAW_BAYER
>> +};
>> +
>> +/* Raw bayer data bus width */
>> +enum v4l2_subdev_raw_bayer_data_width {
>> +V4L2_SUBDEV_RAW_BAYER_DATA_8BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_9BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_10BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_11BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_12BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_13BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_14BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_15BIT,
>> +V4L2_SUBDEV_RAW_BAYER_DATA_16BIT
>> +};
>> +
>> +struct v4l2_subdev_bus_params {
>> +/* bus type */
>> +enum v4l2_subdev_bus_type type;
>> +/* data size for raw bayer data bus */
>> +enum v4l2_subdev_raw_bayer_data_width width;
>> +/* polarity of vsync. 0 - active low, 1 - active high */
>> +u8 vsync_pol;
>> +/* polarity of hsync. 0 - active low, 1 - active low */
>> +u8 hsync_pol;
>> +/* polarity of field id, 0 - low to high, 1 - high to low */
>> +u8 fid_pol;
>> +/* polarity of data. 0 - active low, 1 - active high */
>> +u8 data_pol;
>> +/* pclk polarity. 0 - sample at falling edge, 1 - sample at rising
>edge
>> */ + u8 pclk_pol;
>> +};
>> +
>> Murali Karicheri
>> email: m-kariche...@ti.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
>
>
>
>--
>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
Re: [RFC] passing bus/interface parameters from bridge driver to sub device
On Tuesday 02 June 2009 19:08:01 Karicheri, Muralidharan wrote:
> Hi,
>
> 1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
> the v4l2 sub-device from my vpfe capture driver. Currently the api's
> available doesn't allow setting platform data in the client before the
> sub-device's probe is called. I see that there is discussion about adding
> i2c_board_info as an argument to the api. I would need this to allow
> loading of sub-device from vpfe capture. I have seen patches sent by
> Eduardo Valentin & Guennadi Liakhovetski addressing the issue. Do you
> have any suggestions for use in my vpfe capture driver?
As you have probably seen by now I've made changes to the v4l2 core that
make it easy to use an i2c_board_info struct when creating a subdev. So as
far as I can tell that solves this issue completely.
The code is in my v4l-dvb-subdev tree.
> 2) I need a common structure (preferably in i2c-subdev.h for defining and
> using bus (interface) parameters in the bridge (vpfe capture) and sub
> device (tvp514x or mt9t031) drivers. This will allow bridge driver to
> read these values from platform data and set the same in the vpfe capture
> driver and sub device drivers. Since bus parameters such as interface
> type (BT.656, BT.1120, Raw Bayer image data etc), polarity of various
> signals etc are used across bridge and sub-devices, it make sense to add
> it to i2c-subdev.h. Here is what I have come up with. If this support is
> not already planned, I would like to sent a patch for the same.
It makes sense to define a struct in v4l2-subdev.h and a core ops to set it
(s_bus).
However, I would pack it differently:
struct v4l2_subdev_bus {
enum v4l2_subdev_bus_type type;
u8 width;
unsigned pol_vsync:1;
unsigned pol_hsync:1;
unsigned pol_field:1;
unsigned pol_pclock:1;
};
It's more concise this way.
Regards,
Hans
> +/*
> + * Some Sub-devices are connected to the bridge device through a bus
> + * that carries the clock, vsync, hsync and data. Some interfaces
> + * such as BT.656 carries the sync embedded in the data where as others
> + * have seperate line carrying the sync signals. This structure is
> + * used by bridge driver to set the desired bus parameters in the sub
> + * device to work with it.
> + */
> +enum v4l2_subdev_bus_type {
> + /* BT.656 interface. Embedded syncs */
> + V4L2_SUBDEV_BUS_BT_656,
> + /* BT.1120 interface. Embedded syncs */
> + V4L2_SUBDEV_BUS_BT_1120,
> + /* 8 bit YCbCr muxed bus, separate sync and field id signals */
> + V4L2_SUBDEV_BUS_YCBCR_8,
> + /* 16 bit YCbCr bus, separate sync and field id signals */
> + V4L2_SUBDEV_BUS_YCBCR_16,
> + /* Raw Bayer data bus, 8 - 16 bit wide, sync signals */
> + V4L2_SUBDEV_BUS_RAW_BAYER
> +};
> +
> +/* Raw bayer data bus width */
> +enum v4l2_subdev_raw_bayer_data_width {
> + V4L2_SUBDEV_RAW_BAYER_DATA_8BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_9BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_10BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_11BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_12BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_13BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_14BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_15BIT,
> + V4L2_SUBDEV_RAW_BAYER_DATA_16BIT
> +};
> +
> +struct v4l2_subdev_bus_params {
> + /* bus type */
> + enum v4l2_subdev_bus_type type;
> + /* data size for raw bayer data bus */
> + enum v4l2_subdev_raw_bayer_data_width width;
> + /* polarity of vsync. 0 - active low, 1 - active high */
> + u8 vsync_pol;
> + /* polarity of hsync. 0 - active low, 1 - active low */
> + u8 hsync_pol;
> + /* polarity of field id, 0 - low to high, 1 - high to low */
> + u8 fid_pol;
> + /* polarity of data. 0 - active low, 1 - active high */
> + u8 data_pol;
> + /* pclk polarity. 0 - sample at falling edge, 1 - sample at rising edge
> */ + u8 pclk_pol;
> +};
> +
> Murali Karicheri
> email: m-kariche...@ti.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
--
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev for the following: - v4l-dvb: replace the v4l2_i2c_new_*subdev* functions with v4l2_i2c_new_subdev() - v4l-dvb: add the s_config call to the core ops - v4l2-device: fix incorrect kernel check - v4l-dvb: add v4l2_i2c_new_subdev_board call - v4l2: rename V4L2_I2C_ADDRS to I2C_ADDRS I would prefer to see this go into 2.6.31 since this will help the development of embedded v4l drivers, but if you prefer to delay this until the 2.6.31 window closes, then that is OK by me. But I do not know if that is also OK by Guennadi, Eduardo and Karicheri. All three (and probably others I missed as well) are waiting for this functionality. Having this in the 2.6.31 mainline will probably simplify their work. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 28 +- linux/drivers/media/video/au0828/au0828-cards.c |4 linux/drivers/media/video/bt8xx/bttv-cards.c| 57 ++-- linux/drivers/media/video/cafe_ccic.c |2 linux/drivers/media/video/cx18/cx18-i2c.c | 15 - linux/drivers/media/video/cx231xx/cx231xx-cards.c |4 linux/drivers/media/video/cx23885/cx23885-cards.c |2 linux/drivers/media/video/cx23885/cx23885-video.c | 10 linux/drivers/media/video/cx88/cx88-cards.c | 14 - linux/drivers/media/video/cx88/cx88-video.c | 10 linux/drivers/media/video/em28xx/em28xx-cards.c | 26 - linux/drivers/media/video/ivtv/ivtv-i2c.c | 22 - linux/drivers/media/video/mxb.c | 14 - linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c | 10 linux/drivers/media/video/saa7134/saa7134-cards.c | 12 linux/drivers/media/video/saa7134/saa7134-core.c| 10 linux/drivers/media/video/usbvision/usbvision-i2c.c | 12 linux/drivers/media/video/v4l2-common.c | 270 ++-- linux/drivers/media/video/v4l2-device.c |2 linux/drivers/media/video/vino.c| 12 linux/drivers/media/video/w9968cf.c |4 linux/drivers/media/video/zoran/zoran_card.c|8 linux/include/media/v4l2-common.h | 44 ++- linux/include/media/v4l2-subdev.h |7 v4l/compat.h|6 25 files changed, 322 insertions(+), 283 deletions(-) -- 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
[PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/ for the following 5 changesets: uvcvideo: Add generic control blacklist. uvcvideo: Don't accept to change the format when buffers are allocated. uvcvideo: Add support for Aveo Technology webcams uvcvideo: Add support for FSC V30S webcams uvcvideo: Ignore non-UVC trailing interface descriptors. uvc_ctrl.c | 35 +++ uvc_driver.c | 25 + uvc_queue.c | 14 ++ uvc_v4l2.c |2 +- uvcvideo.h |2 +- 5 files changed, 52 insertions(+), 26 deletions(-) I've removed the VIDIOC_[GS]_JPEGCOMP patch and I'll implement JPEG compression quality setting through a V4L2 control. Thanks, 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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
On Tuesday 09 June 2009 17:56:01 Mauro Carvalho Chehab wrote:
> Em Tue, 9 Jun 2009 17:29:58 +0200
>
> Laurent Pinchart escreveu:
> > > Since uvc is part of the kernel, in fact, it is uvcvideo that is
> > > adding more exceptions to the Kernel style.
> >
> > Damn, I hoped you wouldn't notice that ;-)
> >
> :)
> :
> > I find the
> >
> > if ((ret = function()) < 0)
> >
> > more compact (which can't be debated) and as easy to read as the
> > alternative, if not easier (now this can be debated). As this point of
> > view seems to be minority I'll try to adjust my coding style
> > accordingly. Of course I'll blame you personally for any bug that it
> > would introduce ;-)
>
> It is more compact, and I used to write codes like above in the past.
> Yet, we should stick on Kernel style at the kernelspace stuff.
>
> About the readability, a code like:
>
> ret = function;
> if (ret < 0)
>
> is just a little more readable than on a single line. However, if codes
> like the above are accepted, it should be accepted things like:
>
> if ((ret = functionX() * functionY() + 3) < 5 + 2 * functionZ())
>
> that would be more complex to read than when broken into two separate
> statements:
>
> ret = functionX() * functionY() + 3;
> if (ret < 5 + 2 * functionZ())
>
> Anyway, since Coding Style is global to the kernel as a hole, it is out
> of topic to discuss about the rationale behind each rule, or proposing
> improvements here. The proper forum for it is LKML.
>
> > > > > Also, I have a few comments, from API POV.
> > > > >
> > > > > It doesn't seem that those ioctls are properly implemented. There
> > > > > are some things there that sounded obfuscated for me, and it you
> > > > > aren't implementing. Probably because it is not clear enough.
> > > >
> > > > The UVC standard doesn't specify a way to add/remove specific JPEG
> > > > segments. As MJPEG has not COM, DRI and DHT segments, I've
> > > > hardcoded flags to DQT.
> > > >
> > > > > Also, we used to have a similar set of ioctls for MPEG, that were
> > > > > removed, in favor of the usage of extended controls, with a
> > > > > cleaner interface.
> > > > >
> > > > > That's said, instead of adding more support for this obfuscated
> > > > > API, maybe we could deprecate those in favor of some controls
> > > > > that could make more sense, and let vidio_ioctl2 provide backward
> > > > > compat for it by calling the proper controls, just to preserve
> > > > > binary compatibility with legacy applications.
> > > >
> > > > I have mixed feelings about this. On one hand I agree that
> > > > VIDIOC_S_JPEGCOMP is under-specified and should be either properly
> > > > document, or deprecate it in favor of a control. On the other hand,
> > > > the uvcvideo driver assumes that controls can all be read and
> > > > written while streaming is in progress. I suppose other drivers
> > > > (probably non-MPEG ones) were written with the same assumption in
> > > > mind. Using a control to set JPEG compression would mean that a
> > > > proper infrastructure would need to be put in place in those
> > > > drivers to handle controls that influence video streaming. I'd
> > > > appreciate your opinion on that.
> > >
> > > I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
> > >
> > > The issue you've described of changing the format while streaming
> > > exists, being it a control, or an ioctl. So, it deserves a separate
> > > discussion.
> > >
> > > -
> > >
> > > The MPEG drivers block trials of changing the MPEG format that can't
> > > be done while streaming. On the other hand, user preference controls,
> > > like bright, contrast, (auto)gain, exposure, etc can be done anytime.
> > > As most drivers just exposes such controls, they don't need a logic
> > > to block a control while streaming.
> > >
> > > The case of JPEG/MJPEG is similar to MPEG: there are some changes
> > > that may not be possible while streaming. So, such changes should, in
> > > thesis, be blocked.
> > >
> > > On the other hand, from users perspective, it seems interesting for
> > > they to start an application and, for example, change the JPEG
> > > quality while streaming, to see what better fits his needs.
> > >
> > > Since JPEG is just a set of independent jpeg images, in thesis, it is
> > > possible to change the encoding while streaming, without breaking for
> > > userspace, assuming that the allocated buffers are large enough to
> > > support such changes.
> > >
> > > So, IMO, we should try to allow such changes where possible, even by
> > > doing something like this, at the loop that fills the video buffer:
> > >
> > > if (streaming && frame_is_complete && quality_changed) {
> > > stop_streaming();
> > > change_quality();
> > > start_streaming();
> > > }
> >
> > This can only be done if the allocated buffers are big enough. As the
> > device reports the required buffer size the driver would have to query
> > the device before deciding if it allows to change the quality during
> > streaming. Given the usefulness of cha
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Tue, 9 Jun 2009 17:29:58 +0200
Laurent Pinchart escreveu:
>
> > Since uvc is part of the kernel, in fact, it is uvcvideo that is adding
> > more exceptions to the Kernel style.
>
> Damn, I hoped you wouldn't notice that ;-)
:)
>
> I find the
>
> if ((ret = function()) < 0)
>
> more compact (which can't be debated) and as easy to read as the alternative,
> if not easier (now this can be debated). As this point of view seems to be
> minority I'll try to adjust my coding style accordingly. Of course I'll blame
> you personally for any bug that it would introduce ;-)
It is more compact, and I used to write codes like above in the past. Yet, we
should stick on Kernel style at the kernelspace stuff.
About the readability, a code like:
ret = function;
if (ret < 0)
is just a little more readable than on a single line. However, if codes like
the above are accepted, it should be accepted things like:
if ((ret = functionX() * functionY() + 3) < 5 + 2 * functionZ())
that would be more complex to read than when broken into two separate
statements:
ret = functionX() * functionY() + 3;
if (ret < 5 + 2 * functionZ())
Anyway, since Coding Style is global to the kernel as a hole, it is out of
topic to discuss about the rationale behind each rule, or proposing
improvements here. The proper forum for it is LKML.
> > > > Also, I have a few comments, from API POV.
> > > >
> > > > It doesn't seem that those ioctls are properly implemented. There are
> > > > some things there that sounded obfuscated for me, and it you aren't
> > > > implementing. Probably because it is not clear enough.
> > >
> > > The UVC standard doesn't specify a way to add/remove specific JPEG
> > > segments. As MJPEG has not COM, DRI and DHT segments, I've hardcoded
> > > flags to DQT.
> > >
> > > > Also, we used to have a similar set of ioctls for MPEG, that were
> > > > removed, in favor of the usage of extended controls, with a cleaner
> > > > interface.
> > > >
> > > > That's said, instead of adding more support for this obfuscated API,
> > > > maybe we could deprecate those in favor of some controls that could
> > > > make more sense, and let vidio_ioctl2 provide backward compat for it by
> > > > calling the proper controls, just to preserve binary compatibility with
> > > > legacy applications.
> > >
> > > I have mixed feelings about this. On one hand I agree that
> > > VIDIOC_S_JPEGCOMP is under-specified and should be either properly
> > > document, or deprecate it in favor of a control. On the other hand, the
> > > uvcvideo driver assumes that controls can all be read and written while
> > > streaming is in progress. I suppose other drivers (probably non-MPEG
> > > ones) were written with the same assumption in mind. Using a control to
> > > set JPEG compression would mean that a proper infrastructure would need
> > > to be put in place in those drivers to handle controls that influence
> > > video streaming. I'd appreciate your opinion on that.
> >
> > I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
> >
> > The issue you've described of changing the format while streaming exists,
> > being it a control, or an ioctl. So, it deserves a separate discussion.
> >
> > -
> >
> > The MPEG drivers block trials of changing the MPEG format that can't be
> > done while streaming. On the other hand, user preference controls, like
> > bright, contrast, (auto)gain, exposure, etc can be done anytime. As most
> > drivers just exposes such controls, they don't need a logic to block a
> > control while streaming.
> >
> > The case of JPEG/MJPEG is similar to MPEG: there are some changes that may
> > not be possible while streaming. So, such changes should, in thesis, be
> > blocked.
> >
> > On the other hand, from users perspective, it seems interesting for they to
> > start an application and, for example, change the JPEG quality while
> > streaming, to see what better fits his needs.
> >
> > Since JPEG is just a set of independent jpeg images, in thesis, it is
> > possible to change the encoding while streaming, without breaking for
> > userspace, assuming that the allocated buffers are large enough to support
> > such changes.
> >
> > So, IMO, we should try to allow such changes where possible, even by doing
> > something like this, at the loop that fills the video buffer:
> >
> > if (streaming && frame_is_complete && quality_changed) {
> > stop_streaming();
> > change_quality();
> > start_streaming();
> > }
>
> This can only be done if the allocated buffers are big enough. As the device
> reports the required buffer size the driver would have to query the device
> before deciding if it allows to change the quality during streaming. Given
> the
> usefulness of changing MJPEG compression quality during streaming, and given
> how most webcams seem to ignore the quality anyway, I don't think it would be
> worth it at the moment.
Ok.
> Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the UVC
> driver and imp
Re: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
On Tuesday 09 June 2009 14:02:01 Hans Verkuil wrote:
> On Tuesday 09 June 2009 13:11:11 Eduardo Valentin wrote:
> > Hi Hans,
> >
> > On Tue, Jun 09, 2009 at 12:41:38PM +0200, ext Hans Verkuil wrote:
>
>
>
> > > > +static struct v4l2_ioctl_ops radio_si4713_ioctl_ops = {
> > > > + .vidioc_g_input = radio_si4713_vidioc_g_input,
> > > > + .vidioc_s_input = radio_si4713_vidioc_s_input,
> > > > + .vidioc_g_audio = radio_si4713_vidioc_g_audio,
> > > > + .vidioc_s_audio = radio_si4713_vidioc_s_audio,
> > > > + .vidioc_querycap= radio_si4713_vidioc_querycap,
> > > > + .vidioc_queryctrl = radio_si4713_vidioc_queryctrl,
> > > > + .vidioc_g_ext_ctrls = radio_si4713_vidioc_g_ext_ctrls,
> > > > + .vidioc_s_ext_ctrls = radio_si4713_vidioc_s_ext_ctrls,
> > > > + .vidioc_g_ctrl = radio_si4713_vidioc_g_ctrl,
> > > > + .vidioc_s_ctrl = radio_si4713_vidioc_s_ctrl,
> > > > + .vidioc_g_tuner = radio_si4713_vidioc_g_tuner,
> > > > + .vidioc_s_tuner = radio_si4713_vidioc_s_tuner,
> > >
> > > It's a modulator device, so it should implement g/s_modulator rather
> > > than g/s_tuner.
> > >
> > > Now, here I am running into a problem: looking at section 1.6.2 in
> > > the v4l2 spec I see that in QUERYCAP you are supposed to return
> > > CAP_TUNER and rely on ENUMOUTPUT to determine which output has a
> > > modulator. I think it is nuts that there is no CAP_MODULATOR. I
> > > propose adding this. There are currently NO modulator drivers in
> > > v4l-dvb, nor have I ever heard from out-of-tree modulator drivers
> > > (not that I particularly care about that), so it should be safe to
> > > add it.
> > >
> > > The next problem is that ENUMOUTPUT does not apply to a radio
> > > modulator. This problem is actually also present on radio tuners.
> > > Currently all radio tuner drivers implement g/s_input and g/s_audio
> > > but no enuminput or enumaudio.
> > >
> > > I think g/s_input is bogus since these devices have no video inputs.
> > > However, neither g/s_audio nor enumaudio can currently tell the
> > > application whether the audio input is connected to a tuner. Only
> > > enuminput can do that currently. This would be an argument for using
> > > g/s_input if it wasn't for the fact that none of the radio drivers
> > > actually implements enuminput.
> > >
> > > I propose adding a V4L2_AUDCAP_TUNER capability telling this
> > > application that the audio input is connected to a tuner, and adding
> > > a
> > > V4L2_AUDOUTCAP_MODULATOR capability for struct v4l2_audioout to do
> > > the same for a modulator.
> > >
> > > Comments?
> >
> > Ok. Here comes the real needed changes to support the radio modulator.
> > You may not remember, but in previous versions of this series I
> > commented that this driver was fully based on fm receiver existing
> > drivers.
> >
> > I think that's why I went in the mistake of implementing g_audio,
> > s_audio instead of g_audout, s_audout. Also, the same mistake of
> > implementing the s,g_input done in fm receiver drivers was repeated
> > here.
> >
> > Also, I think another thing has biased me to add this wrong callbacks.
> > I use fmtools to test the driver, for setting fm freq for instance.
> >
> > I admit, there are wrong callbacks.
> >
> > So, I'd ask which application to use to test the driver ?
>
> You have the honor of adding the first modulator driver to the kernel, so
> there are no apps yet. That said, I suggest adding support for
> g/s_modulator to the v4l2-ctl tool (in v4l2-apps/util). It's the swiss
> army knife utility of v4l2 and can call most ioctls from the command
> line.
>
> > About the suggested changes (adding V4L2_AUDCAP_TUNER and
> > V4L2_AUDOUTCAP_MODULATOR), I think it is a reasonable way to do it.
> > However, it'd be nice to hear more opinions. But, if I understood
> > correctly, this would be the method to determine if the driver is a fm
> > transmitter (aka modulator) ?
>
> The CAP_MODULATOR capability is used to determine if the driver supports
> a modulator, and the new capabilities for v4l2_audio and v4l2_audioout
> can be used to determine which audio input/output is hooked up to a tuner
> or modulator. In theory there may be multiple inputs and outputs where
> some are connected to a tuner/modulator and others are straight
> inputs/outputs.
>
> It is common for video capture cards (tuner input vs. Composite/Line-In
> inputs), but there is a case to be made that this is very unlikely for
> radio tuners/modulators. So perhaps I'm paranoid :-)
>
> Actually, looking at it a bit closer it is not enough to just set the
> capability, you also need to set the index of the associated tuner or
> modulatory, which would mean using one of the reserved fields.
>
> Hmm, this is getting complicated. Perhaps we should just add a
> CAP_MODULATOR capability and leave it at that for now. I think the
> MODULATOR capability is really needed, otherwise there is
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Hi Mauro,
On Tuesday 09 June 2009 17:01:14 Mauro Carvalho Chehab wrote:
> Em Mon, 8 Jun 2009 16:15:57 +0200
>
> Laurent Pinchart escreveu:
> > On Monday 08 June 2009 03:52:12 Mauro Carvalho Chehab wrote:
> > > ERROR: do not use assignment in if condition
> > > #64: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:376:
> > > + if ((ret = uvc_probe_video(video, &probe)) < 0)
> > >
> > > ERROR: do not use assignment in if condition
> > > #80: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:872:
> > > + if ((ret = uvc_acquire_privileges(handle)) < 0)
> > >
> > > total: 2 errors, 0 warnings, 81 lines checked
> > >
> > > Please, one statement per line.
> >
> > Is there any way I can convince you to accept the
> >
> > if ((ret = function(...) < 0)
>
> I prefer if you fix it, although I won't nack your pull just due to that.
I'll fix the syntax.
> > syntax on the basis that it's used throughout the rest of the driver ?
> > :-)
> >
> > $ find . -type f -name \*.c -exec grep -l 'if (([a-zA-Z]\+ \?= \?[a-zA-
> > Z_]\+([a-zA-Z0-9 ,*]*)) \?[<>=]\+ \?[a-zA-Z0-9]\+)' {} \; | wc
> > 307 3079204
> >
> > I might have missed a few cases. Not that many occurrences.
>
> Try to count the proper coding style over the kernel source code. I bet
> they you'll find much more cases of:
>
> ret = function();
> if (ret < 0) /* and other similar tests, like ret == NULL, ret,
> !ret, etc
> */ foo;
>
> Since uvc is part of the kernel, in fact, it is uvcvideo that is adding
> more exceptions to the Kernel style.
Damn, I hoped you wouldn't notice that ;-)
I find the
if ((ret = function()) < 0)
more compact (which can't be debated) and as easy to read as the alternative,
if not easier (now this can be debated). As this point of view seems to be
minority I'll try to adjust my coding style accordingly. Of course I'll blame
you personally for any bug that it would introduce ;-)
> > > Also, I have a few comments, from API POV.
> > >
> > > It doesn't seem that those ioctls are properly implemented. There are
> > > some things there that sounded obfuscated for me, and it you aren't
> > > implementing. Probably because it is not clear enough.
> >
> > The UVC standard doesn't specify a way to add/remove specific JPEG
> > segments. As MJPEG has not COM, DRI and DHT segments, I've hardcoded
> > flags to DQT.
> >
> > > Also, we used to have a similar set of ioctls for MPEG, that were
> > > removed, in favor of the usage of extended controls, with a cleaner
> > > interface.
> > >
> > > That's said, instead of adding more support for this obfuscated API,
> > > maybe we could deprecate those in favor of some controls that could
> > > make more sense, and let vidio_ioctl2 provide backward compat for it by
> > > calling the proper controls, just to preserve binary compatibility with
> > > legacy applications.
> >
> > I have mixed feelings about this. On one hand I agree that
> > VIDIOC_S_JPEGCOMP is under-specified and should be either properly
> > document, or deprecate it in favor of a control. On the other hand, the
> > uvcvideo driver assumes that controls can all be read and written while
> > streaming is in progress. I suppose other drivers (probably non-MPEG
> > ones) were written with the same assumption in mind. Using a control to
> > set JPEG compression would mean that a proper infrastructure would need
> > to be put in place in those drivers to handle controls that influence
> > video streaming. I'd appreciate your opinion on that.
>
> I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
>
> The issue you've described of changing the format while streaming exists,
> being it a control, or an ioctl. So, it deserves a separate discussion.
>
> -
>
> The MPEG drivers block trials of changing the MPEG format that can't be
> done while streaming. On the other hand, user preference controls, like
> bright, contrast, (auto)gain, exposure, etc can be done anytime. As most
> drivers just exposes such controls, they don't need a logic to block a
> control while streaming.
>
> The case of JPEG/MJPEG is similar to MPEG: there are some changes that may
> not be possible while streaming. So, such changes should, in thesis, be
> blocked.
>
> On the other hand, from users perspective, it seems interesting for they to
> start an application and, for example, change the JPEG quality while
> streaming, to see what better fits his needs.
>
> Since JPEG is just a set of independent jpeg images, in thesis, it is
> possible to change the encoding while streaming, without breaking for
> userspace, assuming that the allocated buffers are large enough to support
> such changes.
>
> So, IMO, we should try to allow such changes where possible, even by doing
> something like this, at the loop that fills the video buffer:
>
> if (streaming && frame_is_complete && quality_changed) {
> stop_streaming();
> change_quality();
> start_streaming();
> }
This can only be done if the allocated buffers are big enough. As the
Re: [PATCH 2/2] se401: Fix coding style
> > - adr += PAGE_SIZE; > > - size -= PAGE_SIZE; > > + adr += PAGE_SIZE; > > + size -= PAGE_SIZE; > > Why 2 spaces are better here? Regexps need tweaking a tiny bit I guess. I'll post a follow up patch at some point when I'm back dealing with ultra-low priority tweaks (although it does now pass codingstyle like that anyway). -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Mon, 8 Jun 2009 16:15:57 +0200
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Monday 08 June 2009 03:52:12 Mauro Carvalho Chehab wrote:
> > Em Thu, 4 Jun 2009 14:39:52 +0200
> >
> > Laurent Pinchart escreveu:
> > > Mauro,
> > >
> > > Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
> > >
> > > for the following 3 changesets:
> > >
> > > uvcvideo: Add generic control blacklist.
> > > uvcvideo: Don't accept to change the format when buffers are allocated.
> > > uvcvideo: Implement VIDIOC_[GS]_JPEGCOMP
> >
> > I have a few comments about the code of the last patch:
>
> I'll have to drop the tree, clone v4l-dvb and re-apply patches. git ? :-)
> (don't take this too seriously, I would love to switch to git, but it doesn't
> bother me *that* much for now as I don't have to rework patches too often).
With hg, there aren't any alternatives, AFAIK, since "hg push -f" won't delete
an object that were removed locally with hg strip (or changed via hg mq).
>
> > + jpeg->quality = video->streaming->ctrl.wCompQuality / 100;
> >
> > Wouldn't be better to round it to the closest value instead of just
> > truncating?
>
> Ok. I don't think it will really make a difference given how webcams handle
> JPEG compression quality, but better being correct anyway.
Ok.
>
> > + memcpy(&probe, &video->streaming->ctrl, sizeof probe);
> >
> > Please use sizeof(probe) instead.
>
> Oops sorry. I'm used to the 'sizeof variable' syntax. Seems checkpatch
> doesn't
> catch this. I'll fix that.
Checkpatch doesn't catch all problems (and, sometimes, a new version "forgets"
to report some errors that previous versions used to report).
>
> > ERROR: do not use assignment in if condition
> > #64: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:376:
> > + if ((ret = uvc_probe_video(video, &probe)) < 0)
> >
> > ERROR: do not use assignment in if condition
> > #80: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:872:
> > + if ((ret = uvc_acquire_privileges(handle)) < 0)
> >
> > total: 2 errors, 0 warnings, 81 lines checked
> >
> > Please, one statement per line.
>
> Is there any way I can convince you to accept the
>
> if ((ret = function(...) < 0)
I prefer if you fix it, although I won't nack your pull just due to that.
>
> syntax on the basis that it's used throughout the rest of the driver ? :-)
>
> $ find . -type f -name \*.c -exec grep -l 'if (([a-zA-Z]\+ \?= \?[a-zA-
> Z_]\+([a-zA-Z0-9 ,*]*)) \?[<>=]\+ \?[a-zA-Z0-9]\+)' {} \; | wc
> 307 3079204
>
> I might have missed a few cases. Not that many occurrences.
Try to count the proper coding style over the kernel source code. I bet
they you'll find much more cases of:
ret = function();
if (ret < 0)/* and other similar tests, like ret == NULL, ret,
!ret, etc */
foo;
Since uvc is part of the kernel, in fact, it is uvcvideo that is adding more
exceptions to the Kernel style.
> > Also, I have a few comments, from API POV.
> >
> > It doesn't seem that those ioctls are properly implemented. There are some
> > things there that sounded obfuscated for me, and it you aren't
> > implementing. Probably because it is not clear enough.
>
> The UVC standard doesn't specify a way to add/remove specific JPEG segments.
> As MJPEG has not COM, DRI and DHT segments, I've hardcoded flags to DQT.
>
> > Also, we used to have a similar set of ioctls for MPEG, that were removed,
> > in favor of the usage of extended controls, with a cleaner interface.
> >
> > That's said, instead of adding more support for this obfuscated API, maybe
> > we could deprecate those in favor of some controls that could make more
> > sense, and let vidio_ioctl2 provide backward compat for it by calling the
> > proper controls, just to preserve binary compatibility with legacy
> > applications.
>
> I have mixed feelings about this. On one hand I agree that VIDIOC_S_JPEGCOMP
> is under-specified and should be either properly document, or deprecate it in
> favor of a control. On the other hand, the uvcvideo driver assumes that
> controls can all be read and written while streaming is in progress. I
> suppose
> other drivers (probably non-MPEG ones) were written with the same assumption
> in mind. Using a control to set JPEG compression would mean that a proper
> infrastructure would need to be put in place in those drivers to handle
> controls that influence video streaming. I'd appreciate your opinion on that.
I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
The issue you've described of changing the format while streaming exists, being
it a control, or an ioctl. So, it deserves a separate discussion.
-
The MPEG drivers block trials of changing the MPEG format that can't be done
while
streaming. On the other hand, user preference controls, like bright, contrast,
(auto)gain, exposure, etc can be done anytime. As most drivers just exposes
such controls, they don't need a logic to block a control while streaming.
The case of JPEG/MJ
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Tue, 9 Jun 2009 15:04:36 +0200, Hans Verkuil wrote:
> Here it is:
>
> --- linux-git/include/linux/i2c.h.orig2009-06-09 14:53:32.0
> +0200
> +++ linux-git/include/linux/i2c.h 2009-06-09 15:03:24.0 +0200
> @@ -412,6 +412,10 @@
> /* The numbers to use to set I2C bus address */
> #define ANY_I2C_BUS 0x
>
> +/* Construct an I2C_CLIENT_END-terminated array of i2c addresses */
> +#define I2C_ADDRS(addr, addrs...) \
> + ((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
> +
>
> /* - functions exported by i2c.o */
>
>
> Signed-off-by: Hans Verkuil
>
> Note that this can also be used to initialize an array:
>
> static const unsigned short addrs[] = I2C_ADDRS(0x2a, 0x2c);
>
> Whether you want to is another matter, but it works. This functionality is
> also available in the oldest supported gcc (3.2).
Applied, thanks.
--
Jean Delvare
--
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: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth wrote: I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - Kernel Labs http://www.kernellabs.com I agree it's high, but certainly possible. I've got a 30 dB signal, but my situation is a bit unusual. I spent all of last night working on another issue, but I am hoping to get back to it this week. David has called out Comcast to review his installation. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth wrote: > I ruled out 30db on ATSC because that sounds incredibly high, I assumed > cable because that would be consistent with the numbers. You could well be > right. > > -- > Steven Toth - Kernel Labs > http://www.kernellabs.com I agree it's high, but certainly possible. I've got a 30 dB signal, but my situation is a bit unusual. I spent all of last night working on another issue, but I am hoping to get back to it this week. 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: cx18, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 04:36 PM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 4:20 PM, Steven Toth wrote: We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Comcast is coming tomorrow to check out the signal quality. They said that they expect to deliver SNR in the range of 33dB - 45dB to the premises. I will let you know how that affects Linux captures. 33 should be fine for any Linux TV device. Make sure the engineer checks for 33db across a range of the higher (80 thru 100) rf channels (where rf falloff of common). Let us know how you get on. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
Steven, One thing that is interesting is that he is getting BER/UNC errors even on ATSC, when he has a 30.2 dB signal. While I agree that the cable company could be sending a weak signal, 30 dB should be plenty for ATSC. Also, it's possible that the playback application/codec in question poorly handles recovery from MPEG errors such as discontinuity, which results in the experience appearing to be worse under Linux. I'm going to see if I can find some cycles to do some testing here with s5h1409/s5h1411 and see if I can reproduce what David is seeing. Thanks. I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] se401: Fix coding style
Alan Cox wrote:
> From: Alan Cox
>
> Having fixed the sprintfs I decided a quick clean wouldn't do any harm so
> it was actually easy to read in future.
>
> Signed-off-by: Alan Cox
> ---
>
> drivers/media/video/se401.c | 876
> ++-
> drivers/media/video/se401.h |7
> 2 files changed, 452 insertions(+), 431 deletions(-)
>
>
> diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
> index 08129a8..c8f0529 100644
> --- a/drivers/media/video/se401.c
> +++ b/drivers/media/video/se401.c
[...]
> @@ -78,8 +79,8 @@ static void *rvmalloc(unsigned long size)
> adr = (unsigned long) mem;
> while (size > 0) {
> SetPageReserved(vmalloc_to_page((void *)adr));
> - adr += PAGE_SIZE;
> - size -= PAGE_SIZE;
> + adr += PAGE_SIZE;
> + size -= PAGE_SIZE;
Why 2 spaces are better here?
> }
>
> return mem;
--
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: funny colors from XC5000 on big endian systems
On Mon, Jun 8, 2009 at 7:09 PM, W. Michael Petullo wrote: > I have a VCR connected to my 950Q using the coaxial interface. > > Kernel is 2.6.29.4. > > I am using streamer from Fedora's xawtv-3.95-11.fc11.ppc: > > v4lctl setchannel 3 > streamer -r 30 -s 640x480 -f jpeg -i Television -n NTSC-M -c /dev/video0 -o > ~/Desktop/foo.avi -t 00:60:00 > > I am using gstreamer-plugins-good-0.10.14-2.fc11.ppc: > > gst-launch v4l2src ! ffmpegcolorspace ! ximagesink > > Mike Hello Mike, Just a quick follow up, I was up until 1am debugging this issue. It appears that a couple of the ioctl calls are failing when negotiating the capabilities of the analog support. As a result, the gstreamer v4l code is falling back to a default colorspace. The command I sent you should be good enough for it to work for you, but I obviously need to debug this further so that the autonegotiation works properly. 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: [PATCH 00/10 v2] soc-camera conversions
On Mon, Jun 08, 2009 at 09:19:50PM +0200, Guennadi Liakhovetski wrote: > On Tue, 19 May 2009, Paul Mundt wrote: > > > On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote: > > > this is the next round of soc-camera conversions. Run-tested on i.MX31, > > > PXA270, SH7722, compile-tested only for i.MX1. It should have been a > > > "straight-forward" port of the previous version to a more current tree, > > > but then I started converting soc_camera_platform, and things became a > > > bit > > > more complex... As a bonus, now soc-camera can handle not only i2c > > > subdevices, and we can even drop the CONFIG_I2C dependency again. I'll > > > also upload a comlpete stack somewhere a bit later, for example for > > > those, > > > wishing to test it on i.MX31, otherwise the series will not apply > > > cleanly. > > > > > > I'd like to push the first 8 of them asap, 9 and 10 will still have to be > > > reworked > > > > > > Paul, I put you on "cc" on all patches, because, unfortunately, several > > > of > > > them affect arch/sh. But I'll mention it explicitly in each such patch. > > > > > Looks ok to me, there shouldn't be any problems with taking these all > > through the v4l tree. Feel free to add my Acked-by if you like. I guess > > we will find out in -next if there are any conflicts or not :-) > > Yes, can do this, thanks, but first these 3 patches (including Magnus' > ack) have to be applied to sh: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg05223.html > which in turn depend on > http://www.mail-archive.com/linux-media@vger.kernel.org/msg04724.html > and the latter one is already in the next tree. Would you like me to also > merge and pull the above three patches via v4l or would you be applying > them yourself? > I can take care of them once the dependent patch is merged. -- 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: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Monday 08 June 2009 14:39:32 Jean Delvare wrote:
> Hi Hans,
>
> On Sat, 6 Jun 2009 15:00:48 +0200, Hans Verkuil wrote:
> > For video4linux we sometimes need to probe for a single i2c address.
> > Normally you would do it like this:
> >
> > static const unsigned short addrs[] = {
> > addr, I2C_CLIENT_END
> > };
> >
> > client = i2c_new_probed_device(adapter, &info, addrs);
> >
> > This is a bit awkward and I came up with this macro:
> >
> > #define V4L2_I2C_ADDRS(addr, addrs...) \
> > ((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
> >
> > This can construct a list of one or more i2c addresses on the fly. But
> > this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
> >
> > With this macro we can just do:
> >
> > client = i2c_new_probed_device(adapter, &info, I2C_ADDRS(addr));
> >
> > Comments?
>
> I'm not a big fan of macros which hide how things work, but if this
> makes your life easier, why not. Just send a patch and I'll queue it up
> for 2.6.31.
Hi Jean,
Here it is:
--- linux-git/include/linux/i2c.h.orig 2009-06-09 14:53:32.0 +0200
+++ linux-git/include/linux/i2c.h 2009-06-09 15:03:24.0 +0200
@@ -412,6 +412,10 @@
/* The numbers to use to set I2C bus address */
#define ANY_I2C_BUS0x
+/* Construct an I2C_CLIENT_END-terminated array of i2c addresses */
+#define I2C_ADDRS(addr, addrs...) \
+ ((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
+
/* - functions exported by i2c.o */
Signed-off-by: Hans Verkuil
Note that this can also be used to initialize an array:
static const unsigned short addrs[] = I2C_ADDRS(0x2a, 0x2c);
Whether you want to is another matter, but it works. This functionality is
also available in the oldest supported gcc (3.2).
Thanks,
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
[PATCH 2/2] se401: Fix coding style
From: Alan Cox
Having fixed the sprintfs I decided a quick clean wouldn't do any harm so
it was actually easy to read in future.
Signed-off-by: Alan Cox
---
drivers/media/video/se401.c | 876 ++-
drivers/media/video/se401.h |7
2 files changed, 452 insertions(+), 431 deletions(-)
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 08129a8..c8f0529 100644
--- a/drivers/media/video/se401.c
+++ b/drivers/media/video/se401.c
@@ -38,7 +38,7 @@ static const char version[] = "0.24";
static int flickerless;
static int video_nr = -1;
-static struct usb_device_id device_table [] = {
+static struct usb_device_id device_table[] = {
{ USB_DEVICE(0x03e8, 0x0004) },/* Endpoints/Aox SE401 */
{ USB_DEVICE(0x0471, 0x030b) },/* Philips PCVC665K */
{ USB_DEVICE(0x047d, 0x5001) },/* Kensington 67014 */
@@ -53,7 +53,8 @@ MODULE_AUTHOR("Jeroen Vreeken ");
MODULE_DESCRIPTION("SE401 USB Camera Driver");
MODULE_LICENSE("GPL");
module_param(flickerless, int, 0);
-MODULE_PARM_DESC(flickerless, "Net frequency to adjust exposure time to
(0/50/60)");
+MODULE_PARM_DESC(flickerless,
+ "Net frequency to adjust exposure time to (0/50/60)");
module_param(video_nr, int, 0);
static struct usb_driver se401_driver;
@@ -78,8 +79,8 @@ static void *rvmalloc(unsigned long size)
adr = (unsigned long) mem;
while (size > 0) {
SetPageReserved(vmalloc_to_page((void *)adr));
- adr += PAGE_SIZE;
- size -= PAGE_SIZE;
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
}
return mem;
@@ -95,8 +96,8 @@ static void rvfree(void *mem, unsigned long size)
adr = (unsigned long) mem;
while ((long) size > 0) {
ClearPageReserved(vmalloc_to_page((void *)adr));
- adr += PAGE_SIZE;
- size -= PAGE_SIZE;
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
}
vfree(mem);
}
@@ -112,7 +113,7 @@ static void rvfree(void *mem, unsigned long size)
static int se401_sndctrl(int set, struct usb_se401 *se401, unsigned short req,
unsigned short value, unsigned char *cp, int size)
{
- return usb_control_msg (
+ return usb_control_msg(
se401->dev,
set ? usb_sndctrlpipe(se401->dev, 0) :
usb_rcvctrlpipe(se401->dev, 0),
req,
@@ -132,7 +133,7 @@ static int se401_set_feature(struct usb_se401 *se401,
unsigned short selector,
and the param in index, but in the logs of the windows driver they do
this the other way around...
*/
- return usb_control_msg (
+ return usb_control_msg(
se401->dev,
usb_sndctrlpipe(se401->dev, 0),
SE401_REQ_SET_EXT_FEATURE,
@@ -152,7 +153,7 @@ static unsigned short se401_get_feature(struct usb_se401
*se401,
wrong here to
*/
unsigned char cp[2];
- usb_control_msg (
+ usb_control_msg(
se401->dev,
usb_rcvctrlpipe(se401->dev, 0),
SE401_REQ_GET_EXT_FEATURE,
@@ -175,46 +176,51 @@ static unsigned short se401_get_feature(struct usb_se401
*se401,
static int se401_send_pict(struct usb_se401 *se401)
{
- se401_set_feature(se401, HV7131_REG_TITL, se401->expose_l);/*
integration time low */
- se401_set_feature(se401, HV7131_REG_TITM, se401->expose_m);/*
integration time mid */
- se401_set_feature(se401, HV7131_REG_TITU, se401->expose_h);/*
integration time mid */
- se401_set_feature(se401, HV7131_REG_ARLV, se401->resetlevel);/* reset
level value */
- se401_set_feature(se401, HV7131_REG_ARCG, se401->rgain);/* red color
gain */
- se401_set_feature(se401, HV7131_REG_AGCG, se401->ggain);/* green color
gain */
- se401_set_feature(se401, HV7131_REG_ABCG, se401->bgain);/* blue color
gain */
+ /* integration time low */
+ se401_set_feature(se401, HV7131_REG_TITL, se401->expose_l);
+ /* integration time mid */
+ se401_set_feature(se401, HV7131_REG_TITM, se401->expose_m);
+ /* integration time mid */
+ se401_set_feature(se401, HV7131_REG_TITU, se401->expose_h);
+ /* reset level value */
+ se401_set_feature(se401, HV7131_REG_ARLV, se401->resetlevel);
+ /* red color gain */
+ se401_set_feature(se401, HV7131_REG_ARCG, se401->rgain);
+ /* green color gain */
+ se401_set_feature(se401, HV7131_REG_AGCG, se401->ggain);
+ /* blue color gain */
+ se401_set_feature(se401, HV7131_REG_ABCG, se401->bgain);
return 0;
}
static void se401_set_exposure(struct usb_se401 *se401, int brightness)
{
- int integration=brightness<<5;
-
- if (flickerless==50) {
- integration=integration-integration%106667;
- }
- if (flickerless==60) {
-
Re: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
On Tuesday 09 June 2009 13:11:11 Eduardo Valentin wrote:
> Hi Hans,
>
> On Tue, Jun 09, 2009 at 12:41:38PM +0200, ext Hans Verkuil wrote:
> > > +static struct v4l2_ioctl_ops radio_si4713_ioctl_ops = {
> > > + .vidioc_g_input = radio_si4713_vidioc_g_input,
> > > + .vidioc_s_input = radio_si4713_vidioc_s_input,
> > > + .vidioc_g_audio = radio_si4713_vidioc_g_audio,
> > > + .vidioc_s_audio = radio_si4713_vidioc_s_audio,
> > > + .vidioc_querycap= radio_si4713_vidioc_querycap,
> > > + .vidioc_queryctrl = radio_si4713_vidioc_queryctrl,
> > > + .vidioc_g_ext_ctrls = radio_si4713_vidioc_g_ext_ctrls,
> > > + .vidioc_s_ext_ctrls = radio_si4713_vidioc_s_ext_ctrls,
> > > + .vidioc_g_ctrl = radio_si4713_vidioc_g_ctrl,
> > > + .vidioc_s_ctrl = radio_si4713_vidioc_s_ctrl,
> > > + .vidioc_g_tuner = radio_si4713_vidioc_g_tuner,
> > > + .vidioc_s_tuner = radio_si4713_vidioc_s_tuner,
> >
> > It's a modulator device, so it should implement g/s_modulator rather than
> > g/s_tuner.
> >
> > Now, here I am running into a problem: looking at section 1.6.2 in the v4l2
> > spec I see that in QUERYCAP you are supposed to return CAP_TUNER and rely on
> > ENUMOUTPUT to determine which output has a modulator. I think it is nuts
> > that
> > there is no CAP_MODULATOR. I propose adding this. There are currently NO
> > modulator drivers in v4l-dvb, nor have I ever heard from out-of-tree
> > modulator drivers (not that I particularly care about that), so it should be
> > safe to add it.
> >
> > The next problem is that ENUMOUTPUT does not apply to a radio modulator.
> > This problem is actually also present on radio tuners. Currently all radio
> > tuner drivers implement g/s_input and g/s_audio but no enuminput or
> > enumaudio.
> >
> > I think g/s_input is bogus since these devices have no video inputs.
> > However, neither g/s_audio nor enumaudio can currently tell the application
> > whether the audio input is connected to a tuner. Only enuminput can do that
> > currently. This would be an argument for using g/s_input if it wasn't for
> > the fact that none of the radio drivers actually implements enuminput.
> >
> > I propose adding a V4L2_AUDCAP_TUNER capability telling this application
> > that the audio input is connected to a tuner, and adding a
> > V4L2_AUDOUTCAP_MODULATOR capability for struct v4l2_audioout to do the same
> > for a modulator.
> >
> > Comments?
>
> Ok. Here comes the real needed changes to support the radio modulator.
> You may not remember, but in previous versions of this series I commented
> that this driver was fully based on fm receiver existing drivers.
>
> I think that's why I went in the mistake of implementing g_audio, s_audio
> instead of g_audout, s_audout. Also, the same mistake of implementing
> the s,g_input done in fm receiver drivers was repeated here.
>
> Also, I think another thing has biased me to add this wrong callbacks. I use
> fmtools to test the driver, for setting fm freq for instance.
>
> I admit, there are wrong callbacks.
>
> So, I'd ask which application to use to test the driver ?
You have the honor of adding the first modulator driver to the kernel, so
there are no apps yet. That said, I suggest adding support for g/s_modulator
to the v4l2-ctl tool (in v4l2-apps/util). It's the swiss army knife utility
of v4l2 and can call most ioctls from the command line.
> About the suggested changes (adding V4L2_AUDCAP_TUNER and
> V4L2_AUDOUTCAP_MODULATOR),
> I think it is a reasonable way to do it. However, it'd be nice to hear more
> opinions.
> But, if I understood correctly, this would be the method to determine
> if the driver is a fm transmitter (aka modulator) ?
The CAP_MODULATOR capability is used to determine if the driver supports a
modulator, and the new capabilities for v4l2_audio and v4l2_audioout can be
used to determine which audio input/output is hooked up to a tuner or
modulator. In theory there may be multiple inputs and outputs where some
are connected to a tuner/modulator and others are straight inputs/outputs.
It is common for video capture cards (tuner input vs. Composite/Line-In
inputs), but there is a case to be made that this is very unlikely for
radio tuners/modulators. So perhaps I'm paranoid :-)
Actually, looking at it a bit closer it is not enough to just set the
capability, you also need to set the index of the associated tuner or
modulatory, which would mean using one of the reserved fields.
Hmm, this is getting complicated. Perhaps we should just add a CAP_MODULATOR
capability and leave it at that for now. I think the MODULATOR capability
is really needed, otherwise there is no easy way to check whether it is a
tuner or modulator device.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media"
[PATCH 1/2] se401: Fix unsafe use of sprintf with identical source/destination
From: Alan Cox
Closes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=13435
Signed-off-by: Alan Cox
---
drivers/media/video/se401.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 5990ab3..08129a8 100644
--- a/drivers/media/video/se401.c
+++ b/drivers/media/video/se401.c
@@ -1244,17 +1244,18 @@ static int se401_init(struct usb_se401 *se401, int
button)
int i=0, rc;
unsigned char cp[0x40];
char temp[200];
+ int slen;
/* led on */
se401_sndctrl(1, se401, SE401_REQ_LED_CONTROL, 1, NULL, 0);
/* get camera descriptor */
rc=se401_sndctrl(0, se401, SE401_REQ_GET_CAMERA_DESCRIPTOR, 0, cp,
sizeof(cp));
- if (cp[1]!=0x41) {
+ if (cp[1] != 0x41) {
err("Wrong descriptor type");
return 1;
}
- sprintf (temp, "ExtraFeatures: %d", cp[3]);
+ slen = snprintf(temp, 200, "ExtraFeatures: %d", cp[3]);
se401->sizes=cp[4]+cp[5]*256;
se401->width=kmalloc(se401->sizes*sizeof(int), GFP_KERNEL);
@@ -1269,9 +1270,10 @@ static int se401_init(struct usb_se401 *se401, int
button)
se401->width[i]=cp[6+i*4+0]+cp[6+i*4+1]*256;
se401->height[i]=cp[6+i*4+2]+cp[6+i*4+3]*256;
}
- sprintf (temp, "%s Sizes:", temp);
+ slen += snprintf (temp + slen, 200 - slen, " Sizes:");
for (i=0; isizes; i++) {
- sprintf(temp, "%s %dx%d", temp, se401->width[i],
se401->height[i]);
+ slen += snprintf(temp + slen, 200 - slen,
+ " %dx%d", se401->width[i], se401->height[i]);
}
dev_info(&se401->dev->dev, "%s\n", temp);
se401->maxframesize=se401->width[se401->sizes-1]*se401->height[se401->sizes-1]*3;
--
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/2] SE401 clean up
Tidy up the SE401 driver --- Alan Cox (2): se401: Fix unsafe use of sprintf with identical source/destination se401: Fix coding style drivers/media/video/se401.c | 882 ++- drivers/media/video/se401.h |7 2 files changed, 456 insertions(+), 433 deletions(-) -- I'd prefer the trees to be separate for testing purposes: it doens't make much sense to have SMP support as a normal kernel feature when most people won't have SMP anyway" -- Linus Torvalds -- 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 review] gspca - stv06xx: remove needless if check and goto
2009/6/9 Alexey Klimov : > Hello, Jean-Francois and Erik André > > What do you think about such small change? > Looks like the code doesn't need if-check and goto here in stv06xx_stopN > function. The code after label "out" does this. > > -- > Patch removes needless if check and goto. > > > Signed-off-by: Alexey Klimov Looks sane. Thank you for reporting. Best regards, Erik Reviewed-by: Erik Andrén > -- > diff -r ed3781a79c73 linux/drivers/media/video/gspca/stv06xx/stv06xx.c > --- a/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Sat Jun 06 16:31:34 > 2009 +0400 > +++ b/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Tue Jun 09 14:49:04 > 2009 +0400 > @@ -293,8 +293,6 @@ > goto out; > > err = sd->sensor->stop(sd); > - if (err < 0) > - goto out; > > out: > if (err < 0) > > > -- > Best regards, Klimov Alexey > > -- 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: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
Hi Hans,
On Tue, Jun 09, 2009 at 12:41:38PM +0200, ext Hans Verkuil wrote:
> On Monday 08 June 2009 10:18:05 Eduardo Valentin wrote:
> > From: Eduardo Valentin
> >
> > # HG changeset patch
> > # User "Eduardo Valentin "
> > # Date 126611 -10800
> > # Node ID 92ec243dd1882c136a588898dd5b7a1913ca0f4b
> > # Parent 2456c8fc506ecf928d2e95da36d611d094c0ec55
> > This patch adds files which creates the radio interface
> > for si4713 FM transmitter devices.
> >
> > Priority: normal
> >
> > Signed-off-by: "Eduardo Valentin "
> >
> > diff -r 2456c8fc506e -r 92ec243dd188
> > linux/drivers/media/radio/radio-si4713.c
> > --- /dev/null Thu Jan 01 00:00:00 1970 +
> > +++ b/linux/drivers/media/radio/radio-si4713.cMon Jun 08 10:36:51
> > 2009 +0300
> > @@ -0,0 +1,332 @@
> > +/*
> > + * drivers/media/radio/radio-si4713.c
> > + *
> > + * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
> > + *
> > + * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
> > + * Contact: Eduardo Valentin
> > + *
> > + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "radio-si4713.h"
> > +#include "si4713.h"
> > +
> > +/* module parameters */
> > +static int radio_nr = -1;/* radio device minor (-1 ==> auto assign) */
> > +
> > +/* radio_si4713_fops - file operations interface */
> > +static const struct v4l2_file_operations radio_si4713_fops = {
> > + .owner = THIS_MODULE,
> > + .ioctl = video_ioctl2,
> > +};
> > +
> > +/* Video4Linux Interface */
> > +static int radio_si4713_vidioc_g_audio(struct file *file, void *priv,
> > + struct v4l2_audio *audio)
> > +{
> > + if (audio->index > 1)
> > + return -EINVAL;
> > +
> > + strncpy(audio->name, "Radio", 32);
> > + audio->capability = V4L2_AUDCAP_STEREO;
> > +
> > + return 0;
> > +}
> > +
> > +static int radio_si4713_vidioc_s_audio(struct file *file, void *priv,
> > + struct v4l2_audio *audio)
> > +{
> > + if (audio->index != 0)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
>
> This is a transmitter (aka modulator) device, so it should implement g_audout,
> s_audout and enumaudout rather than s_audio and g_audio.
>
> > +
> > +static int radio_si4713_vidioc_g_input(struct file *file, void *priv,
> > + unsigned int *i)
> > +{
> > + *i = 0;
> > +
> > + return 0;
> > +}
> > +
> > +static int radio_si4713_vidioc_s_input(struct file *file, void *priv,
> > + unsigned int i)
> > +{
> > + if (i != 0)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
>
> These are not needed: it is an audio only device, so no video. Since g/s_input
> deals with video inputs these are not relevant. And even if it was, then it
> would have to be g/s_output :-)
>
> > +
> > +/* radio_si4713_vidioc_querycap - query device capabilities */
> > +static int radio_si4713_vidioc_querycap(struct file *file, void *priv,
> > + struct v4l2_capability *capability)
> > +{
> > + struct radio_si4713_device *rsdev;
> > +
> > + rsdev = video_get_drvdata(video_devdata(file));
> > +
> > + strlcpy(capability->driver, "radio-si4713",
> > sizeof(capability->driver));
> > + strlcpy(capability->card, "Silicon Labs Si4713 FM Radio Transmitter",
> > + sizeof(capability->card));
> > + capability->capabilities = V4L2_CAP_TUNER;
> > +
> > + return 0;
> > +}
> > +
> > +/* radio_si4713_vidioc_queryctrl - enumerate control items */
> > +static int radio_si4713_vidioc_queryctrl(struct file *file, void *priv,
> > + struct v4l2_queryctrl *qc)
> > +{
> > +
> > + /* Must be sorted from low to high control ID! */
> > + static const u32 user_ctrls[] = {
> > + V4L2_CID_USER_CLASS,
> > + V4L2_CID_AUDIO_VOLUME,
> > + V4L2_CID_AUDIO_BALANCE,
> > + V4L2_CID_AUDIO_BASS,
> > + V4L2_CID_AUDIO_TREBL
[patch review] gspca - stv06xx: remove needless if check and goto
Hello, Jean-Francois and Erik André What do you think about such small change? Looks like the code doesn't need if-check and goto here in stv06xx_stopN function. The code after label "out" does this. -- Patch removes needless if check and goto. Signed-off-by: Alexey Klimov -- diff -r ed3781a79c73 linux/drivers/media/video/gspca/stv06xx/stv06xx.c --- a/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Sat Jun 06 16:31:34 2009 +0400 +++ b/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Tue Jun 09 14:49:04 2009 +0400 @@ -293,8 +293,6 @@ goto out; err = sd->sensor->stop(sd); - if (err < 0) - goto out; out: if (err < 0) -- Best regards, Klimov Alexey -- 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: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
On Monday 08 June 2009 10:18:05 Eduardo Valentin wrote:
> From: Eduardo Valentin
>
> # HG changeset patch
> # User "Eduardo Valentin "
> # Date 126611 -10800
> # Node ID 92ec243dd1882c136a588898dd5b7a1913ca0f4b
> # Parent 2456c8fc506ecf928d2e95da36d611d094c0ec55
> This patch adds files which creates the radio interface
> for si4713 FM transmitter devices.
>
> Priority: normal
>
> Signed-off-by: "Eduardo Valentin "
>
> diff -r 2456c8fc506e -r 92ec243dd188 linux/drivers/media/radio/radio-si4713.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/linux/drivers/media/radio/radio-si4713.cMon Jun 08 10:36:51
> 2009 +0300
> @@ -0,0 +1,332 @@
> +/*
> + * drivers/media/radio/radio-si4713.c
> + *
> + * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
> + *
> + * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
> + * Contact: Eduardo Valentin
> + *
> + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "radio-si4713.h"
> +#include "si4713.h"
> +
> +/* module parameters */
> +static int radio_nr = -1;/* radio device minor (-1 ==> auto assign) */
> +
> +/* radio_si4713_fops - file operations interface */
> +static const struct v4l2_file_operations radio_si4713_fops = {
> + .owner = THIS_MODULE,
> + .ioctl = video_ioctl2,
> +};
> +
> +/* Video4Linux Interface */
> +static int radio_si4713_vidioc_g_audio(struct file *file, void *priv,
> + struct v4l2_audio *audio)
> +{
> + if (audio->index > 1)
> + return -EINVAL;
> +
> + strncpy(audio->name, "Radio", 32);
> + audio->capability = V4L2_AUDCAP_STEREO;
> +
> + return 0;
> +}
> +
> +static int radio_si4713_vidioc_s_audio(struct file *file, void *priv,
> + struct v4l2_audio *audio)
> +{
> + if (audio->index != 0)
> + return -EINVAL;
> +
> + return 0;
> +}
This is a transmitter (aka modulator) device, so it should implement g_audout,
s_audout and enumaudout rather than s_audio and g_audio.
> +
> +static int radio_si4713_vidioc_g_input(struct file *file, void *priv,
> + unsigned int *i)
> +{
> + *i = 0;
> +
> + return 0;
> +}
> +
> +static int radio_si4713_vidioc_s_input(struct file *file, void *priv,
> + unsigned int i)
> +{
> + if (i != 0)
> + return -EINVAL;
> +
> + return 0;
> +}
These are not needed: it is an audio only device, so no video. Since g/s_input
deals with video inputs these are not relevant. And even if it was, then it
would have to be g/s_output :-)
> +
> +/* radio_si4713_vidioc_querycap - query device capabilities */
> +static int radio_si4713_vidioc_querycap(struct file *file, void *priv,
> + struct v4l2_capability *capability)
> +{
> + struct radio_si4713_device *rsdev;
> +
> + rsdev = video_get_drvdata(video_devdata(file));
> +
> + strlcpy(capability->driver, "radio-si4713", sizeof(capability->driver));
> + strlcpy(capability->card, "Silicon Labs Si4713 FM Radio Transmitter",
> + sizeof(capability->card));
> + capability->capabilities = V4L2_CAP_TUNER;
> +
> + return 0;
> +}
> +
> +/* radio_si4713_vidioc_queryctrl - enumerate control items */
> +static int radio_si4713_vidioc_queryctrl(struct file *file, void *priv,
> + struct v4l2_queryctrl *qc)
> +{
> +
> + /* Must be sorted from low to high control ID! */
> + static const u32 user_ctrls[] = {
> + V4L2_CID_USER_CLASS,
> + V4L2_CID_AUDIO_VOLUME,
> + V4L2_CID_AUDIO_BALANCE,
> + V4L2_CID_AUDIO_BASS,
> + V4L2_CID_AUDIO_TREBLE,
> + V4L2_CID_AUDIO_LOUDNESS,
> + V4L2_CID_AUDIO_MUTE,
> + 0
> + };
> +
> + /* Must be sorted from low to high control ID! */
> + static const u32 fmtx_ctrls[] = {
> + V4L2_CID_FMTX_CLASS,
> + V4L2_CID_RDS_ENABLED,
> + V4L2_CID_RDS_PI,
> + V4L2_CID_RDS_PTY,
> +
Re: Haupauge Nova-T 500 2.6.28 regression dib0700
Hi, cc-ed linux-media On Mon, Jun 01, 2009 at 12:48:33PM +0200, Hubert Hafner wrote: > > I've read your message on mail-archive.com on the linux-media section. > > The same problem seems to be valid for the Haupauge Nova-TD (a dual > receiver). After a few minutes the ehci_hcd core is halted. > > Have you got any ideas how to solve this? I've read setting URB to 1 > (?) should solve this issue - but where to set this parameter and did > it work out? There's a patch on the linux-media list. Search for a thread with "dib0700 Nova-TD-Stick problem" as subject. > disable_rc_polling does not solve the problem. At least at my Ubuntu > Server 8.10 with kernel 2.6.27-7. Seems to be different problem than. At least kernel 2.6.27.x works here without problems. Janne -- 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: About the VIDIOC_DQBUF
Hi,
Sorry I still don't get what the full frame means, but I might
consider that is the maximum resolution-ed image data coming from
external camera module. And whatever it is, you might have no problem
getting data through memcpy with buf.byteused size.
Cheers,
Nate
On Tue, Jun 9, 2009 at 11:22 AM, xie wrote:
> hi ~~ Dongsoo, Nathaniel ~
>
> I am sorry for disturbing you, and not descripe the question clear ~
> Thanks very much for your help ~~
>
> I know that I must stop preview with streamoff and re-configure with
> s_fmt ~~ I have asked to you before ~!~
>
> The "full frame" means a complete frame ~Because I just need to get the
> frame data and post it to multimedia framework, so I want to consult to
> you that if I can get a complete frame with memcpy ~~
>
> I want to know that can I get a complete frame from buf.start to the
> end , and the memory-lenth is buf.byteused ~
>
>buf.byteused
>|-|
> buf.startend
>
>
>
>
>
>
>
> 在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道：
>> Hi,
>>
>> Sorry I'm not an expert, you can expect expertise from maintainers not from
>> me.
>> But before answering your question about capturing, I'm not sure about
>> what the "full frame" means. I just assume that you meant to say the
>> biggest resolution of image frame, right?
>>
>> So, when you are to capture a full resolution data while preview is
>> working, you need to stop preview with streamoff, re-configure
>> resolution with s_fmt to external camera module and start capturing
>> issuing streamon with re-configured resolution. I think you are
>> well-aware with this, aren't you? And in my opinion, memcpy may be
>> cool for that. What else are you expecting to use? and for what?
>> Anyway, I wish you luck.
>> Cheers,
>>
>> Nate
>>
>>
>> On Mon, Jun 8, 2009 at 5:02 PM, xie wrote:
>> > Hi Dongsoo, Nathaniel ~
>> > You must be expert on V4l2 ~ Thanks very much for your help and advice
>> > ~!~
>> > I used the MXC camera interface driver from Fressscale ,I readed the
>> > driver interface just now ,and have fouded that the driver not modified
>> > the buf.lenth but buf.byteused . You are very right , I will use the
>> > buf.byteused instead of buf.length ~
>> >
>> > There is also a problem I want to consult to you ~ Can i get a full
>> > frame with the below method if the driver have no problem ?
>> >
>> > memcpy((mCameraProwave->getPreviewHeap())->base(),
>> > v4l2Buffer[buf.index].start, buf.byteused) ;
>> >
>> > Because I just need to implement a hal for getting the frame data and
>> > post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
>> > what about your advice ?
>> >
>> > Thanks a lot ~~
>> >
>> >
>> >
>> > 在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
>> >> Hello Xie,
>> >>
>> >> I'm not sure which camera interface driver you are using, but it seems
>> >> to be camera interface driver's problem. Let me guess, are you using
>> >> pxa camera interface driver from Marvell?(proprietary but not in up
>> >> stream kernel)
>> >> It just looks like that camera interface driver is not returning
>> >> proper data in dqbuf.
>> >>
>> >> And one more thing. I prefer to use byteused rather than length in
>> >> buf. because as far as I know the size of preview data from camera is
>> >> in byte unit which we need to copy to memory. But it should be
>> >> possible to use length, I guess..
>> >> Cheers,
>> >>
>> >> Nate
>> >>
>> >> On Mon, Jun 8, 2009 at 11:05 AM, xie wrote:
>> >> > Dear all ~~
>> >> >
>> >> > I have met a issue when I used the mmap method for previewing . I just
>> >> > used the standard code as spec to get the image data :
>> >> > status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
>> >> > {
>> >> >LOG_FUNCTION_NAME
>> >> >int rt ;
>> >> >unsigned int i ;
>> >> >fd_set fds ;
>> >> >struct timeval tv ;
>> >> >struct v4l2_buffer buf ;
>> >> >
>> >> >for(;;){
>> >> >FD_ZERO(&fds) ;
>> >> >FD_SET(v4l2Fd, &fds) ;
>> >> >//now the time is long ,just for debug
>> >> >tv.tv_sec = 2 ;
>> >> >tv.tv_usec = 0 ;
>> >> >
>> >> >rt = select(v4l2Fd + 1, &fds, NULL, NULL, &tv) ;
>> >> >LOGD("The value of select return : %d\n", rt) ;
>> >> >
>> >> >/** for debug
>> >> >if(V4L2_NOERROR != v4l2ReadFrame()){
>> >> >LOGE("READ ERROR") ;
>> >> >}
>> >> >***/
>> >> >
>> >> >if(-1 == rt){
>> >> >LOGE("there is something wrong in select
>> >> > function(select)") ;
>> >> >//no defined error manage
>> >> >return V4L2_IOCTL_ERROR ;
>> >> >}
>> >> >if(0 == rt){
>> >> >LOGE("wait for data timeout in select") ;
>> >> >
