Re: [PATCH] v4l2-dbg: report fail reason to the user

[Hans Verkuil]

On Thursday 12 November 2009 08:23:41 Németh Márton wrote:
> From: Márton Németh 
> 
> Report the fail reason to the user when writing a register even if
> the verbose mode is switched off.
> 
> Remove duplicated code ioctl() call which may cause different ioctl()
> function call in case of verbose and non verbose if not handled carefully.
> 
> Signed-off-by: Márton Németh 
> ---
> diff -r 60f784aa071d v4l2-apps/util/v4l2-dbg.cpp
> --- a/v4l2-apps/util/v4l2-dbg.cpp Wed Nov 11 18:28:53 2009 +0100
> +++ b/v4l2-apps/util/v4l2-dbg.cpp Thu Nov 12 08:21:20 2009 +0100
> @@ -353,14 +353,21 @@
>  static int doioctl(int fd, int request, void *parm, const char *name)
>  {
>   int retVal;
> + int ioctl_errno;
> 
>   if (!options[OptVerbose]) return ioctl(fd, request, parm);
>   retVal = ioctl(fd, request, parm);
> - printf("%s: ", name);
> - if (retVal < 0)
> - printf("failed: %s\n", strerror(errno));
> - else
> - printf("ok\n");
> + if (options[OptVerbose]) {
> + /* Save errno because printf() may modify it */
> + ioctl_errno = errno;
> + printf("%s: ", name);
> + if (retVal < 0)
> + printf("failed: %s\n", strerror(errno));
> + else
> + printf("ok\n");

I'm an idiot for not realizing this when I did the first review, but this
can be done without making a copy of errno. Just do this:

if (options[OptVerbose]) {
if (retVal < 0)
printf("%s: failed: %s\n", name, strerror(errno));
else
printf("%s: ok\n", name);

Much simpler :-)

Can you change this and post again? Then I'll add it to my pending pull
request.

Thanks,

Hans

> + /* Restore errno for caller's use */
> + errno = ioctl_errno;
> + }
> 
>   return retVal;
>  }
> @@ -586,8 +593,8 @@
> 
>   printf(" set to 0x%llx\n", set_reg.val);
>   } else {
> - printf("Failed to set register 0x%08llx value 
> 0x%llx\n",
> - set_reg.reg, set_reg.val);
> + printf("Failed to set register 0x%08llx value 
> 0x%llx: %s\n",
> + set_reg.reg, set_reg.val, 
> strerror(errno));
>   }
>   set_reg.reg++;
>   }
> 



-- 
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] v4l2-dbg: report fail reason to the user

[Németh Márton]

From: Márton Németh 

Report the fail reason to the user when writing a register even if
the verbose mode is switched off.

Remove duplicated code ioctl() call which may cause different ioctl()
function call in case of verbose and non verbose if not handled carefully.

Signed-off-by: Márton Németh 
---
diff -r 60f784aa071d v4l2-apps/util/v4l2-dbg.cpp
--- a/v4l2-apps/util/v4l2-dbg.cpp   Wed Nov 11 18:28:53 2009 +0100
+++ b/v4l2-apps/util/v4l2-dbg.cpp   Thu Nov 12 08:21:20 2009 +0100
@@ -353,14 +353,21 @@
 static int doioctl(int fd, int request, void *parm, const char *name)
 {
int retVal;
+   int ioctl_errno;

if (!options[OptVerbose]) return ioctl(fd, request, parm);
retVal = ioctl(fd, request, parm);
-   printf("%s: ", name);
-   if (retVal < 0)
-   printf("failed: %s\n", strerror(errno));
-   else
-   printf("ok\n");
+   if (options[OptVerbose]) {
+   /* Save errno because printf() may modify it */
+   ioctl_errno = errno;
+   printf("%s: ", name);
+   if (retVal < 0)
+   printf("failed: %s\n", strerror(errno));
+   else
+   printf("ok\n");
+   /* Restore errno for caller's use */
+   errno = ioctl_errno;
+   }

return retVal;
 }
@@ -586,8 +593,8 @@

printf(" set to 0x%llx\n", set_reg.val);
} else {
-   printf("Failed to set register 0x%08llx value 
0x%llx\n",
-   set_reg.reg, set_reg.val);
+   printf("Failed to set register 0x%08llx value 
0x%llx: %s\n",
+   set_reg.reg, set_reg.val, 
strerror(errno));
}
set_reg.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: Capturing video and still images using one driver

[Guennadi Liakhovetski]

(removed the deprecated video ML from CC)

On Wed, 11 Nov 2009, Neil Johnson wrote:

> Guennadi,
> 
> Your suggestions do work well, though my implementation is not ideal.
> However, I am now able to switch between high res capture and low res
> capture using S_FMT.  I made the switch to using user-ptr buffers in
> user space, and now I allocate both large still image buffers and
> smaller video buffers when my app starts.  Then, I switch from video
> to still image capture (always using streaming, not read()), and then
> switch back to video when needed.

You meqn you stop streaming in your application, requeue buffers of 
different size and restart capture?

> Unfortunately, I'm not a huge expert at making my code fit the
> video4linux model, so I've basically introduced some hacks that make
> it work for me.  I'll try to get my hackish code up to spec so that it
> will possibly be useful for others.

Yep, try to make it as good as possible and in any case send it in for 
others to have a look.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] decode_tm6000: fix include path

[Németh Márton]

Hans Verkuil wrote:
> On Thursday 12 November 2009 07:52:51 Németh Márton wrote:
>> From: Márton Németh 
>>
>> The include path is changed from ../lib to ../lib4vl2util .
>>
>> Signed-off-by: Márton Németh 
>> ---
>> diff -r 60f784aa071d v4l2-apps/util/decode_tm6000.c
>> --- a/v4l2-apps/util/decode_tm6000.c Wed Nov 11 18:28:53 2009 +0100
>> +++ b/v4l2-apps/util/decode_tm6000.c Thu Nov 12 07:49:43 2009 +0100
>> @@ -16,7 +16,7 @@
>> along with this program; if not, write to the Free Software
>> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>>   */
>> -#include "../lib/v4l2_driver.h"
>> +#include "../libv4l2util/v4l2_driver.h"
>>  #include 
>>  #include 
>>  #include 
>> --
>> 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
>>
> 
> This is already part of my pull request from Monday. So this will hopefully be
> merged soon.

OK. Sorry I missed that one.

Regards,

Márton Németh

--
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] decode_tm6000: fix include path

[Hans Verkuil]

On Thursday 12 November 2009 07:52:51 Németh Márton wrote:
> From: Márton Németh 
> 
> The include path is changed from ../lib to ../lib4vl2util .
> 
> Signed-off-by: Márton Németh 
> ---
> diff -r 60f784aa071d v4l2-apps/util/decode_tm6000.c
> --- a/v4l2-apps/util/decode_tm6000.c  Wed Nov 11 18:28:53 2009 +0100
> +++ b/v4l2-apps/util/decode_tm6000.c  Thu Nov 12 07:49:43 2009 +0100
> @@ -16,7 +16,7 @@
> along with this program; if not, write to the Free Software
> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>   */
> -#include "../lib/v4l2_driver.h"
> +#include "../libv4l2util/v4l2_driver.h"
>  #include 
>  #include 
>  #include 
> --
> 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
> 

This is already part of my pull request from Monday. So this will hopefully be
merged soon.

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] dvb-usb-friio: accept center-shifted frequency

[Akihiro TSUKADA]

From: Akihiro Tsukada 

This patch adds a fix to accept frequency with its center shifted.

The driver used to accept center frequencies of the normal UHF band channels,
but in ISDB-T, center frequency is shifted with 1/7MHz.
It was shifted internally in the driver,
but this patch enables to accept both types of frequency.

Priority: normal

Signed-off-by: Akihiro Tsukada 
---
 friio-fe.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/linux/drivers/media/dvb/dvb-usb/friio-fe.c 
b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
--- a/linux/drivers/media/dvb/dvb-usb/friio-fe.c
+++ b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
@@ -134,11 +134,13 @@ static int jdvbt90502_pll_set_freq(struc
deb_fe("%s: freq=%d, step=%d\n", __func__, freq,
   state->frontend.ops.info.frequency_stepsize);
/* freq -> oscilator frequency conversion. */
-   /* freq: 473,000,000 + n*6,000,000 (no 1/7MHz shift to center freq) */
-   /* add 400[1/7 MHZ] = 57.142857MHz.   57MHz for the IF,  */
-   /*   1/7MHz for center freq shift */
+   /* freq: 473,000,000 + n*6,000,000 [+ 142857 (center freq. shift)] */
f = freq / state->frontend.ops.info.frequency_stepsize;
-   f += 400;
+   /* add 399[1/7 MHZ] = 57MHz for the IF  */
+   f += 399;
+   /* add center frequency shift if necessary */
+   if (f % 7 == 0)
+   f++;
pll_freq_cmd[DEMOD_REDIRECT_REG] = JDVBT90502_2ND_I2C_REG; /* 0xFE */
pll_freq_cmd[ADDRESS_BYTE] = state->config.pll_address << 1;
pll_freq_cmd[DIVIDER_BYTE1] = (f >> 8) & 0x7F;

--
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
--
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] decode_tm6000: fix include path

[Németh Márton]

From: Márton Németh 

The include path is changed from ../lib to ../lib4vl2util .

Signed-off-by: Márton Németh 
---
diff -r 60f784aa071d v4l2-apps/util/decode_tm6000.c
--- a/v4l2-apps/util/decode_tm6000.cWed Nov 11 18:28:53 2009 +0100
+++ b/v4l2-apps/util/decode_tm6000.cThu Nov 12 07:49:43 2009 +0100
@@ -16,7 +16,7 @@
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
-#include "../lib/v4l2_driver.h"
+#include "../libv4l2util/v4l2_driver.h"
 #include 
 #include 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Video events, version 2.3

[Hans Verkuil]

On Wednesday 11 November 2009 22:31:00 Sakari Ailus wrote:
> Hi,
> 
> 
> Here's the version 2.3 of the video events RFC which hopefully will be 
> the final one. It's based on Laurent Pinchart's original RFC and 
> versions 2, 2.1 and 2.2 which I wrote. The old RFC is available here:
> 
> http://www.spinics.net/lists/linux-media/msg11254.html>
> 
> Changes to version 2.2
> 
> 
> - The timestamp has changed from struct timeval (do_gettimeofday()) to 
> struct timespec (clock_getres(CLOCK_MONOTONIC)).
> 
> Interface description
> -
> 
> Event type is either a standard event or private event. Standard events
> will be defined in videodev2.h. Private event types begin from
> V4L2_EVENT_PRIVATE_START. The four topmost bits of the type should not
> be used for the moment.
> 
> #define V4L2_EVENT_ALL0
> #define V4L2_EVENT_PRIVATE_START  0x0800
> 
> VIDIOC_DQEVENT is used to get events. count is number of pending events
> after the current one. sequence is the event type sequence number and
> the data is specific to event type.
> 
> The user will get the information that there's an event through
> exception file descriptors by using select(2). When an event is
> available the poll handler sets POLLPRI which wakes up select. -EINVAL
> will be returned if there are no pending events.
> 
> VIDIOC_SUBSCRIBE_EVENT and VIDIOC_UNSUBSCRIBE_EVENT are used to
> subscribe and unsubscribe from events. The argument is struct
> v4l2_event_subscription which now only contains the type field for the
> event type. Every event can be subscribed or unsubscribed by one ioctl
> by using special type V4L2_EVENT_ALL.
> 
> 
> struct v4l2_event {
>   __u32   count;
>   __u32   type;
>   __u32   sequence;
>   struct timespec timestamp;
>   __u32   reserved[8];
>   __u8data[64];
> };
> 
> struct v4l2_event_subscription {
>   __u32   type;
>   __u32   reserved[8];
> };
> 
> #define VIDIOC_DQEVENT_IOR('V', 84, struct v4l2_event)
> #define VIDIOC_SUBSCRIBE_EVENT_IOW('V', 85, struct
>v4l2_event_subscription)
> #define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 86, struct
> v4l2_event_subscription)
> 
> 
> The size of the event queue is decided by the driver. Which events will
> be discarded on queue overflow depends on the implementation.
> 
> 
> Questions
> -
> 
> None on my side.
> 
> Comments and questions are still very very welcome.
> 

Hi Sakari,

I'm happy with this! Thanks for all your work on this RFC!

Guru, do you think you can start to work on the implementation of this API?

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] V4L: adding digital video timings APIs

[Hans Verkuil]

On Wednesday 11 November 2009 22:45:15 Karicheri, Muralidharan wrote:
> Hans,
> 
> >> [MK] Could you explain this to me? In my prototype, I had tvp5146 that
> >> implements S_STD and tvp7002 that implements S_PRESET. Since bridge
> >driver
> >> has all the knowledge about the sub devices and their capabilities, it
> >can
> >> set the flag for each of the input that it supports (currently I am
> >> setting this flag in the board setup file that describes all the inputs
> >using v4l2_input structure). So it is a matter of setting relevant cap flag
> >in this file for each of the input based on what the sub device supports. I
> >am not sure how core can figure this out?
> >
> >The problem is that we don't want to go through all drivers in order to set
> >the input/output capability flags. However, v4l2_ioctl.c can easily check
> >whether the v4l2_ioctl_ops struct has set vidioc_s_std, vidioc_s_dv_preset
> >and/or vidioc_s_dv_timings and fill in the caps accordingly. If this is
> >done
> >before the vidioc_enum_input/output is called, then the driver can override
> >what v4l2_ioctl.c did if that is needed.
> >
> 
> Why do we need to do that? Why not leave it to the bridge driver to set that
> flag since it knows all encoder/decoder connected to it and whether current 
> encoder/decoder has support for S_STD or S_PRESET looking at the sub dev ops.
> If we set them at the core, as you explained, then bridge driver needs to
> override it. That is not clean IMO.

Actually, the bridge driver only needs to override if it has multiple inputs
where the capability flags differ (i.e. some inputs only support S_STD and
others only support S_DV_PRESET).

In all other cases the core will fill it in correctly.

Doing it in the core ensures that the capability flags will be filled in so
drivers don't need to remember doing this. The alternative is that you have to
go through ALL existing drivers and add the new SUPPORTS_STD capability flag.

But even then I am pretty certain that people will forget to set this flag
for new upcoming drivers.

So I prefer to have this set in the core and only drivers that have mixed
inputs/outputs need to do a bit more work.

Regards,

Hans

> 
> Murali
> 
> >Regards,
> >
> > Hans
> >
> >--
> >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
> 
> 
> 



-- 
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: problems receiving channels with technotrend S-3200

[BOUWSMA Barry]

On Wed, 11 Nov 2009, Stefan wrote:

> I'v problems with receiving dvb-s channels especially all the bbc
> channels on freesat (Astra 28.2) .
> The card is working fine for all the dutch channels (canaal digitaal)
> and in windows i have no problem receiving bbc hd
> 
> But as soon as i tune in to for example bbchd or bbc1 i do get a lock
> but no data.
> 
> # dvbstream -f 10847000 -p v -s 22000 -v 5500 -a 5501 -o > bbchd.mpg

> tuning DVB-S to Freq: 1097000, Pol:V Srate=2200, 22kHz tone=off, LNB: 0

> When i try to record bvn (a fta channel)

But not found on the same satellite...


> # dvbstream -f 12574000 -p h -s 22000 -v 515 -a 96 -o > bvn.mpg

> tuning DVB-S to Freq: 1974000, Pol:H Srate=2200, 22kHz tone=off, LNB: 0


These indicate you are attempting to stream from the same DiSEqC
LNB number.  Your BVN is found at Astra 19E2 while the BBC
domestic services are broadcast at Astra 28E2.

You need to add a `-D #' to indicate which LNB position your
Astra 28E2 can be received, which is obviously not the default
(A or 1/2 or 1/4 or whatever) in your DiSEqC switch, as part of
your commandline.

Also note that you may need to record more of the stream in
order to properly decode and play the BBC HD file than just
the video payload.  The particular values I used last time I
looked (the BSkyB/Freesat services have a habit of changing
for no good reason) were 0  258  5500  5502  5503  5504  5501
if that helps, including subtitles and all.

Note that there is an active DVB-S transponder at the same
frequency on Astra 19E2, last time I checked (more than a year
ago, sorry) explaining why you are able to lock successfully
on the wrong satellite position for the Freesat services.


thanks
barry bouwsma
--
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: Procmail won't route this list (linux-media) correctly. Help!

[A. F. Cano]

On Wed, Nov 11, 2009 at 10:16:47PM -0500, I wrote:
> Hi,
> 
> This is the only mailing list that I receive that procmail doesn't
> handle properly.  All the others get sent to their own mailboxes.
> What is so strange about the headers of this list?

Arrgh!!!  One change after I sent this email fixed it.  Please ignore
the request for help.

It turns out that I had too much stuff in the procmail recipe.

This works:
> :0:
> * ^TO(linux-...@linuxtv.org|linux-media@vger.kernel.org)
> $LINUXDVBFOLDER

Sorry for the distraction.

A.

--
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

Procmail won't route this list (linux-media) correctly. Help!

[A. F. Cano]

Hi,

This is the only mailing list that I receive that procmail doesn't
handle properly.  All the others get sent to their own mailboxes.
What is so strange about the headers of this list?

This is the procmail recipe I use: (I've tried routing this list's
email through all kinds of headers I have observed in the emails.
In all the other lists I get, the ^TO header is enough)

:0:
* ^TO(linux-...@linuxtv.org|linux-media@vger.kernel.org) |\
  ^Reply-To(linux-media@vger.kernel.org) |\
  ^X-Mailing-List(linux-media@vger.kernel.org) |\
  ^CC(linux-media@vger.kernel.org) |\
  ^LIST-ID(linux-media.vger.kernel.org)
$LINUXDVBFOLDER

Note: I'm trying to put the linux-dvb and linux-media mail in the
same folder.  The same scheme works fine for other lists.

Help!

Augustine

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] DVB: firedtv: port to new firewire driver stack

[Stefan Richter]

Stefan Richter wrote:
> [PATCH 1/4] firedtv: move remote control workqueue handling into rc source 
> file
> [PATCH 2/4] firedtv: reform lock transaction backend call
> [PATCH 3/4] firedtv: add missing include, rename a constant
> [PATCH 4/4] firedtv: port to new firewire core
> 
>  drivers/media/dvb/firewire/Kconfig|7
>  drivers/media/dvb/firewire/Makefile   |1
>  drivers/media/dvb/firewire/firedtv-1394.c |   37 +-
>  drivers/media/dvb/firewire/firedtv-avc.c  |   50 +-
>  drivers/media/dvb/firewire/firedtv-dvb.c  |   15
>  drivers/media/dvb/firewire/firedtv-fw.c   |  385 ++
>  drivers/media/dvb/firewire/firedtv-rc.c   |2
>  drivers/media/dvb/firewire/firedtv.h  |   17
>  8 files changed, 471 insertions(+), 43 deletions(-)

These patches are now also available in the v2.6.31 based "firedtv"
branch at

git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git 
firedtv

This branch is also merged into linux1394-2.6.git for-next and thereby
linux-next.git.
-- 
Stefan Richter
-=-==--= =-== -==--
http://arcgraph.de/sr/

--
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] Global video buffers pool / Samsung SoC's

[Jinsung Yang]

Hi, thank you for your reply.
Harald may be in flight now :)

> One question to your SoCs though - do they have SRAM? usable and
> sufficient for graphics buffers? In any case any such implementation will
> have to be able to handle RAMs other than main system memory too,
> including card memory, NUMA, sparse RAM, etc., which is probably obvious
> anyway.
All Samsung SoCs have no SRAMs for graphic buffers, just having system
memory.
And what is worse, in case of 2 system memory banks,
some kinds of hardware need to allocate buffers to improve performance at
each bank separately.
This is just a kind of sample, Samsung SoCs have many special cases.
(Of course, we are trying to add IOMMU to resolve buffer issues at next SoCs
products)

Best Regards
--
Jinsung, Yang 
AP Development Team
System LSI, Semiconductor Business
SAMSUNG Electronics Co., LTD

--
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: Reprise of YUV frame alignment improvements

[Brandon Jenkins]

On Wed, Nov 11, 2009 at 8:06 PM, Andy Walls  wrote:
> On Wed, 2009-11-11 at 19:38 -0500, Brandon Jenkins wrote:
>> On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls  wrote:

>
> I assume you mean the mxl5005s and s5h1409 changes for clear QAM when
> you say Devin's change.
>
> Regards,
> Andy
>
>

You are correct sir

Brandon
--
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: Reprise of YUV frame alignment improvements

[Andy Walls]

On Wed, 2009-11-11 at 19:38 -0500, Brandon Jenkins wrote:
> On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls  wrote:
> >
> > Could folks give this cx18 code a test to make sure their primary use
> > cases didn't break?
> >
> >
> > Regards,
> > Andy
> >
> Andy,
> 
> I have loaded the drivers (also pulling in Devin's change request too)
> and am running with 3 cards and SageTV. I'll let you know if something
> pops up, but nothing thus far.
> 
> Brandon


Thanks a bunch.  It's nice to have someone with a system capable of
being highly loaded to try to break things. :)

For myself, after 1 day I haven't noticed anything.  Though my normal
use case is simple live Digital TV viewing with MythTV - not terribly
stressing.

I assume you mean the mxl5005s and s5h1409 changes for clear QAM when
you say Devin's change.

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: cx18: Reprise of YUV frame alignment improvements

[Brandon Jenkins]

On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls  wrote:
>
> Could folks give this cx18 code a test to make sure their primary use
> cases didn't break?
>
>
> Regards,
> Andy
>
Andy,

I have loaded the drivers (also pulling in Devin's change request too)
and am running with 3 cards and SageTV. I'll let you know if something
pops up, but nothing thus far.

Brandon
--
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: Capturing video and still images using one driver

[Neil Johnson]

Guennadi,

Your suggestions do work well, though my implementation is not ideal.
However, I am now able to switch between high res capture and low res
capture using S_FMT.  I made the switch to using user-ptr buffers in
user space, and now I allocate both large still image buffers and
smaller video buffers when my app starts.  Then, I switch from video
to still image capture (always using streaming, not read()), and then
switch back to video when needed.

Unfortunately, I'm not a huge expert at making my code fit the
video4linux model, so I've basically introduced some hacks that make
it work for me.  I'll try to get my hackish code up to spec so that it
will possibly be useful for others.

Neil

On Tue, Nov 3, 2009 at 3:13 PM, Neil Johnson  wrote:
>
>
> On Tue, Nov 3, 2009 at 3:02 PM, Guennadi Liakhovetski
>  wrote:
>>
>> On Mon, 2 Nov 2009, Neil Johnson wrote:
>>
>> > video4linux-list,
>> >
>> > I am developing on the OMAP3 system using a micron/aptina mt9p031
>> > 5-megapixel imager.  This CMOs imager supports full image capture at 5
>> > fps
>> > (2592x1944 pixels) or you can capture subregions using skipping and
>> > binning.  We have proven both capabilities, but would like to be able to
>> > capture both VGA sized video and still images without using separate
>> > drivers.
>> >
>> > So far, I have not found any support for capturing large images and
>> > video
>> > through a single driver interface.  Does such a capability exist within
>> > v4l2?  One possible way to solve the problem is to allocate N buffers of
>> > the
>> > full 5-megapixel size (they end up being 10-MB for each buffer since I'm
>> > using 16-bits per pixel), and then using a small portion of that for
>> > video.
>> > These is less desirable since when I'm capturing video, I only need
>> > 640x480
>> > size buffers, and I should only need one snapshot buffer at a time (I'm
>> > not
>> > streaming them in, just take a snapshot and go back to live video
>> > capture).
>> > Is there a way to allocate a side-buffer for the 5-megapixel image and
>> > also
>> > allocate "normal" sized buffers for video within the same driver?  Any
>> > recommendations on how to accomplish such a thing?  I would think that
>> > camera-phones using linux would have run up against this.  Thanks,
>>
>> I came across the same problem when working on the rj54n1cb0c driver.
>> What's even more exciting with that sensor, is that it has separate
>> frame-size settings for preview (video) and still capture.
>
> I'm running into this as well.  The MT9P013 has different capture sizes for
> video preview (can be 720x480, 1280x720, etc), but the full image capture is
> 2592x1944.  The biggest problem is that the hardware I'm using (OMAP3530)
> has an image signal processing (isp) chain that needs to be properly
> configured for the input size and output size.  Right now, the isp gets
> initialized when the driver is opened, and then doesn't get touched until
> it's closed.  However, the isp needs to be reconfigured if the frame size
> changes.  This is getting to be a painful experience.
>
>
>>
>> So far the
>> driver doesn't have any support for those still image frame settings, but
>> I was thinking about implenting it using the read V4L method. I.e., you
>> would use the mmap method just normally to capture video and use read to
>> get still images?
>
> I've considered this, and maybe that's the right way to do it.  The buffer
> size for the read would have to be different than the mmap buffers...but
> maybe that's doable.  Does "read" use videobuf in most circumstances?  Is it
> possible to allocate multiple video buffer queues from a single driver?
>
>>
>> OTOH, with my driver I would need to differentiate
>> between S_FMT for video and still. Would we have to use different inputs
>> for them?
>
> Not sure...maybe that's the way to do it... right now my only option is to
> close the device, reopen it with different settings everytime I switch from
> video to still image.
>>
>> Thanks
>> Guennadi
>> ---
>> Guennadi Liakhovetski, Ph.D.
>> Freelance Open-Source Software Developer
>> http://www.open-technology.de/
>
>
> Thanks for the feedback.  Hopefully this will be a good learning experience
> :)
>
>
> --
--
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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

(lotsa cc's added)

On Mon, 9 Nov 2009 08:59:05 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=14564
> 
>Summary: capture-example sleeping function called from invalid
> context at arch/x86/mm/fault.c
>Product: Memory Management
>Version: 2.5
> Kernel Version: 2.6.31.5
>   Platform: All
> OS/Version: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: high
>   Priority: P1
>  Component: Slab Allocator
> AssignedTo: a...@linux-foundation.org
> ReportedBy: kn...@toaster.net
> Regression: No
> 

Thhis is odd.

> On a DM&P ebox2300sx, 300Mhz Vortex86 cpu, I have a vanilla 2.6.31.5 kernel
> with a pac207 webcam. I run capture-example from the v4l-dvb sample
> applications and it crashes 1 out of 5 times. Let me know if I need to collect
> more data or try anything.
> 
> [r...@x-linux]:~ # capture-example
>   
> ..BUG:
> sleeping function called from invalid context at arch/x86/mm/fault.c:1069 
>   
> in_atomic(): 0, irqs_disabled(): 1, pid: 1178, name: capture-example  
>   
> 4 locks held by capture-example/1178: 
>   
>  #0:  (&gspca_dev->queue_lock){+.+.+.}, at: []
> vidioc_streamoff+0x3b/0xb4 [gspca_main]   
>   
>  #1:  (&gspca_dev->usb_lock){+.+.+.}, at: []
> vidioc_streamoff+0x4e/0xb4 [gspca_main]   
>   
>  #2:  (&ohci->lock){-.-...}, at: [] 
> ohci_endpoint_disable+0x31/0x192  
>  #3:  (&mm->mmap_sem){++}, at: [] do_page_fault+0xc1/0x1fe  
>   
> irq event stamp: 11656
>   
> hardirqs last  enabled at (11655): [] _spin_unlock_irq+0x22/0x26
>   
> hardirqs last disabled at (11656): [] _spin_lock_irqsave+0x10/0x5a  
>   
> softirqs last  enabled at (11610): [] __do_softirq+0x145/0x14d  
>   
> softirqs last disabled at (11605): [] do_softirq+0x2a/0x42  
>   
> Pid: 1178, comm: capture-example Not tainted 2.6.31.5 #2  
>   
> Call Trace:   
>   
>  [] __might_sleep+0xcb/0xd0 
>   
>  [] do_page_fault+0x106/0x1fe   
>   
>  [] ? do_page_fault+0x0/0x1fe   
>   
>  [] error_code+0x63/0x70
>   
>  [] ? do_page_fault+0x0/0x1fe   
>   
>  [] ? td_free+0x23/0x75 
>   
>  [] ohci_endpoint_disable+0x113/0x192   
>   
>  [] usb_hcd_disable_endpoint+0x2e/0x32  
>   
>  [] usb_disable_endpoint+0x6d/0x72  
>   
>  [] usb_disable_interface+0x30/0x3f 
>   
>  [] usb_set_interface+0x11b/0x1a0   
>   
>  [] gspca_set_alt0+0x23/0x46 [gspca_main]   
>   
>  [] gspca_stream_off+0x35/0x5f [gspca_main] 
>   
>  [] vidioc_streamoff+0x59/0xb4 [gspca_main] 
>   
>  [] __video_do_ioctl+0x17af/0x3920 [videodev]   
>   
>  [] ? __lock_acquire+0x6ef/0x755
>   
>  [] ? lock_release_holdtime+0x81/0x86   
>   
>  [] ? lock_release_non_nested+0xab/0x1cf
>   
>  [] ? might_fault+0x3d/0x79 
>   
>  [] ? might_fault+0x3d/0x79 
>   
>  [] ? copy_from_user+0x31/0x54  
>   
>  [] video_ioctl2+0x303/0x3ea [videodev] 
>   
>  [] ? lock_release_holdtime+0x81/0x86   
>   
>  [] ? _spin_unlock_irqrestore+0x36/0x3c 
>   
>  [] ? trace_hardirqs_on_caller+0x104/0x12b  
>   
>  [] ? trace_hardirqs_on+0xb/0xd 
>   
>  [] ? video_ioctl2+0x0/0x3ea [videodev] 
>   
>  [] v4l2_unlocked_ioctl+0x2e/0x32 [videodev]
>   
>  [] ? v4l2_unlocked_ioctl+0x0/0x32 [videodev]   
>   
>  [] vfs_ioctl+0x19/0x50 
>   
>  [] do_vfs_ioctl+0x458/0x4a3
>   
>  [] ? tty_ldisc_deref+0x8/0xa   
>   
>  [] ? tty_write+0x1b1/0x1c2 
>   
>  [] ? n_tty_writ

Re: [PATCH] soc_camera: multiple input capable enum, g & s

[Philipp Wiesner]

> On Tue, 10 Nov 2009, Philipp Wiesner wrote:
> 
> > soc_camera: multiple input capable enum, g & s
> > 
> > From: Philipp Wiesner 
> > 
> > I did some small changes to support soc camera devices with multiple 
> > inputs, e.g. tw9910 (driver doesn't support this yet).
> > soc-camera.c:
> > soc_camera_enum_input: capable of handling multiple inputs.
> > soc_camera_g_input: calls icd's g_input if present.
> > soc_camera_s_input: calls icd's s_input if present.
> > soc-camera.h:
> > struct soc_camera_ops: Added aliases for g_input and s_input functions
> here.
> 
> Thanks for the patch, and yes, supporting multiple inputs would be good, 
> but: 1) we should not add new operations to soc_camera_ops. Any new client
> operations should be implemented using the v4l2-subdev API.

Okay, I somehow expected this. I just thought that there must be a reason that
some of the regular API functions were not carried over to the subdev API.

> 2) we should 
> first decide what we want to use multiple inputs for. There have beed 
> discussions to use inputs for switching between sensors on one interface, 
> or for switching between video and still-image modes... What is your 
> use-case for them?

The tw9910 (analog video decoder/encoder) has four physical video inputs with
one of them being active at a time, so it's real input switching in this case.
I have to admit that I'm not yet very familiar with the direction this API is
going. But I can image situations where enum_input helps to use input switching
for all of those cases.
Whether you switch physical inputs or only 'modes' or 'contexts' IMHO should be
totally up to the driver programmer, whatever is needed for the device. It
doesn't make any difference to the API and all of them can be considered inputs
in a logical way.

Thanks.
Philipp

> Thanks
> Guennadi
> 
> > 
> > Priority: normal
> > 
> > Signed-off-by: Philipp Wiesner 
> > 
> > diff -r 43878f8dbfb0 -r a5254e7d306a
> linux/drivers/media/video/soc_camera.c
> > --- a/linux/drivers/media/video/soc_camera.cSun Nov 01 07:17:46 2009
> -0200
> > +++ b/linux/drivers/media/video/soc_camera.cTue Nov 03 17:17:49 2009
> +0100
> > @@ -119,11 +119,10 @@
> > struct soc_camera_device *icd = icf->icd;
> > int ret = 0;
> >  
> > -   if (inp->index != 0)
> > -   return -EINVAL;
> > -
> > if (icd->ops->enum_input)
> > ret = icd->ops->enum_input(icd, inp);
> > +   else if (inp->index != 0)
> > +   return -EINVAL;
> > else {
> > /* default is camera */
> > inp->type = V4L2_INPUT_TYPE_CAMERA;
> > @@ -136,17 +135,30 @@
> >  
> >  static int soc_camera_g_input(struct file *file, void *priv, unsigned
> int *i)
> >  {
> > -   *i = 0;
> > +   struct soc_camera_file *icf = file->private_data;
> > +   struct soc_camera_device *icd = icf->icd;
> > +   int ret = 0;
> >  
> > -   return 0;
> > +   if (icd->ops->g_input)
> > +   ret = icd->ops->g_input(icd, i);
> > +   else
> > +   *i = 0;
> > +
> > +   return ret;
> >  }
> >  
> >  static int soc_camera_s_input(struct file *file, void *priv, unsigned
> int i)
> >  {
> > -   if (i > 0)
> > +   struct soc_camera_file *icf = file->private_data;
> > +   struct soc_camera_device *icd = icf->icd;
> > +   int ret = 0;
> > +
> > +   if (icd->ops->s_input)
> > +   ret = icd->ops->s_input(icd, i);
> > +   else if (i > 0)
> > return -EINVAL;
> >  
> > -   return 0;
> > +   return ret;
> >  }
> >  
> >  static int soc_camera_s_std(struct file *file, void *priv, v4l2_std_id 
> >
> *a)
> > diff -r 43878f8dbfb0 -r a5254e7d306a linux/include/media/soc_camera.h
> > --- a/linux/include/media/soc_camera.h  Sun Nov 01 07:17:46 2009 -0200
> > +++ b/linux/include/media/soc_camera.h  Tue Nov 03 17:17:49 2009 +0100
> > @@ -197,6 +197,8 @@
> > unsigned long (*query_bus_param)(struct soc_camera_device *);
> > int (*set_bus_param)(struct soc_camera_device *, unsigned long);
> > int (*enum_input)(struct soc_camera_device *, struct v4l2_input *);
> > +   int (*g_input)(struct soc_camera_device *, unsigned int *);
> > +   int (*s_input)(struct soc_camera_device *, unsigned int);
> > const struct v4l2_queryctrl *controls;
> > int num_controls;
> >  };
> > 
> > -- 
> > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> > --
> > 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
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
-- 
DSL-Preisknaller: DSL Komplettpakete von GMX schon für 
16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl01
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More

RE: [PATCH] V4L: adding digital video timings APIs

[Karicheri, Muralidharan]

Hans,

Please see my response to your comment on setting the flag. I still think it is 
cleaner to do it in the bridge driver.

The patch is ready and I need to finish the documentation. I plan to do this in 
a weeks time and push the patch to the list.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Wednesday, November 11, 2009 2:21 AM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com
>Subject: Re: [PATCH] V4L: adding digital video timings APIs
>
>On Thursday 05 November 2009 13:56:29 Hans Verkuil wrote:
>> On Friday 23 October 2009 22:44:34 Karicheri, Muralidharan wrote:
>> > Hans,
>> >
>> > >> following IOCTLS :-
>> > >>
>> > >>  -  verify the new v4l2_input capabilities flag added
>> > >>  -  Enumerate available presets using VIDIOC_ENUM_DV_PRESETS
>> > >>  -  Set one of the supported preset using VIDIOC_S_DV_PRESET
>> > >>  -  Get current preset using VIDIOC_G_DV_PRESET
>> > >>  -  Detect current preset using VIDIOC_QUERY_DV_PRESET
>> > >>  -  Using stub functions in tvp7002, verify VIDIOC_S_DV_TIMINGS
>> > >> and VIDIOC_G_DV_TIMINGS ioctls are received at the sub device.
>> > >>
>> > >> TODOs :
>> > >>
>> > >>  - Test it on a 64bit platform - I need help here since I don't have
>the
>> > >> platform.
>> > >>  - Add documentation (Can someone tell me which file to modify in
>the
>> > >> kernel tree?).
>> > >
>> > >Use the spec in media-spec/v4l.
>> >
>> > [MK] Where can I access this? Is this part of kernel tree (I couldn't
>find
>> > it under Documentation/video4linux/ under the kernel tree? Is it just
>updating a text file or I need to have some tool installed to access
>> > this documentation and update it.
>>
>> This has been moved around quite a bit lately. It is now in
>> linux/Documentation/DocBook/v4l. You build it using 'make media-spec'.
>>
>> > >Please also add support to v4l2-ctl.cpp in v4l2-apps/util! That's
>handy
>> > >for testing.
>> > [MK] Are you referring to the following repository for this?
>> >
>> > http://linuxtv.org/hg/~dougsland/tool/file/5b884b36bbab
>> >
>> > Is there a way I can do a git clone for this?
>>
>> Both the doc and the v4l2-ctl.cpp utility are in the master hg repository
>> (linuxtv.org/hg/v4l-dvb). The utility can be found here: v4l2-apps/util.
>> Build it using 'make apps'. The patches of the timings API, docs and
>utils
>> should all be done against the master hg tree since that is that latest
>and
>> greatest tree.
>>
>> >
>> > >
>> > >Setting the input/output capabilities should be done in v4l2-ioctl.c
>> > >rather than in the drivers. All the info you need to set these bits is
>> > >available in the core after all.
>> > >
>> >
>> > [MK] Could you explain this to me? In my prototype, I had tvp5146 that
>> > implements S_STD and tvp7002 that implements S_PRESET. Since bridge
>driver
>> > has all the knowledge about the sub devices and their capabilities, it
>can
>> > set the flag for each of the input that it supports (currently I am
>> > setting this flag in the board setup file that describes all the inputs
>using v4l2_input structure). So it is a matter of setting relevant cap flag
>in this file for each of the input based on what the sub device supports. I
>am not sure how core can figure this out?
>>
>> The problem is that we don't want to go through all drivers in order to
>set
>> the input/output capability flags. However, v4l2_ioctl.c can easily check
>> whether the v4l2_ioctl_ops struct has set vidioc_s_std,
>vidioc_s_dv_preset
>> and/or vidioc_s_dv_timings and fill in the caps accordingly. If this is
>done
>> before the vidioc_enum_input/output is called, then the driver can
>override
>> what v4l2_ioctl.c did if that is needed.
>>
>> >
>> > >I also noticed that not all new ioctls are part of video_ops. Aren't
>they
>> > >all required?
>> > >
>> > [MK] All new ioctls are supported in video_ops. I am not sure what you
>are
>> > referring to. For sub device ops, only few are required since bridge
>device
>> > can handle the rest.
>>
>> OK.
>>
>> Regards,
>>
>>  Hans
>>
>
>Hi Murali,
>
>What is the status of this? It would be great if we can get this in for
>2.6.33.
>
>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] V4L: adding digital video timings APIs

[Karicheri, Muralidharan]

Hans,

>> [MK] Could you explain this to me? In my prototype, I had tvp5146 that
>> implements S_STD and tvp7002 that implements S_PRESET. Since bridge
>driver
>> has all the knowledge about the sub devices and their capabilities, it
>can
>> set the flag for each of the input that it supports (currently I am
>> setting this flag in the board setup file that describes all the inputs
>using v4l2_input structure). So it is a matter of setting relevant cap flag
>in this file for each of the input based on what the sub device supports. I
>am not sure how core can figure this out?
>
>The problem is that we don't want to go through all drivers in order to set
>the input/output capability flags. However, v4l2_ioctl.c can easily check
>whether the v4l2_ioctl_ops struct has set vidioc_s_std, vidioc_s_dv_preset
>and/or vidioc_s_dv_timings and fill in the caps accordingly. If this is
>done
>before the vidioc_enum_input/output is called, then the driver can override
>what v4l2_ioctl.c did if that is needed.
>

Why do we need to do that? Why not leave it to the bridge driver to set that
flag since it knows all encoder/decoder connected to it and whether current 
encoder/decoder has support for S_STD or S_PRESET looking at the sub dev ops.
If we set them at the core, as you explained, then bridge driver needs to
override it. That is not clean IMO.

Murali

>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

[RFC] Video events, version 2.3

[Sakari Ailus]

Hi,


Here's the version 2.3 of the video events RFC which hopefully will be 
the final one. It's based on Laurent Pinchart's original RFC and 
versions 2, 2.1 and 2.2 which I wrote. The old RFC is available here:


http://www.spinics.net/lists/linux-media/msg11254.html>

Changes to version 2.2


- The timestamp has changed from struct timeval (do_gettimeofday()) to 
struct timespec (clock_getres(CLOCK_MONOTONIC)).


Interface description
-

Event type is either a standard event or private event. Standard events
will be defined in videodev2.h. Private event types begin from
V4L2_EVENT_PRIVATE_START. The four topmost bits of the type should not
be used for the moment.

#define V4L2_EVENT_ALL  0
#define V4L2_EVENT_PRIVATE_START0x0800

VIDIOC_DQEVENT is used to get events. count is number of pending events
after the current one. sequence is the event type sequence number and
the data is specific to event type.

The user will get the information that there's an event through
exception file descriptors by using select(2). When an event is
available the poll handler sets POLLPRI which wakes up select. -EINVAL
will be returned if there are no pending events.

VIDIOC_SUBSCRIBE_EVENT and VIDIOC_UNSUBSCRIBE_EVENT are used to
subscribe and unsubscribe from events. The argument is struct
v4l2_event_subscription which now only contains the type field for the
event type. Every event can be subscribed or unsubscribed by one ioctl
by using special type V4L2_EVENT_ALL.


struct v4l2_event {
__u32   count;
__u32   type;
__u32   sequence;
struct timespec timestamp;
__u32   reserved[8];
__u8data[64];
};

struct v4l2_event_subscription {
__u32   type;
__u32   reserved[8];
};

#define VIDIOC_DQEVENT  _IOR('V', 84, struct v4l2_event)
#define VIDIOC_SUBSCRIBE_EVENT  _IOW('V', 85, struct
 v4l2_event_subscription)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 86, struct
  v4l2_event_subscription)


The size of the event queue is decided by the driver. Which events will
be discarded on queue overflow depends on the implementation.


Questions
-

None on my side.

Comments and questions are still very very welcome.

--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP 3 ISP and N900 sensor driver update

[Sakari Ailus]

Hiremath, Vaibhav wrote:

As far as I know nobody on our side is currently working on the CCDC
driver.
We're focusing on the previewer and resizer first.


[Hiremath, Vaibhav] I believe I should be able to see the current development 
activity on sakari's repo, right?


That's right. Just use the cont branch if you want to pull. Then the log 
will be garbage. The alternative is to use the devel branch but then you 
cannot pull, instead use fetch always and manually reapply local 
changes. Pick your poison. :-)


--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: module ov7670.c

[Ryan Raasch]

Ryan Raasch wrote:



Carlos Lavin wrote:
i am asking that if it is possible to start a module without 
MODULE_INIT function in the body of program.


It looks as though all drivers that use v4l2_i2c_driver_data DO NOT use 
the module_init function.


According to commit 14386c2b7793652a656021a3345cff3b0f6771f9, 
v4l2_subdev is used instead. However, this is different for me also.



Ryan



Ok. I was curious myself, so i looked how it works.

The file v4l2-i2c-drv.h has the module_init() code. So when this header 
file is included, you get the initialization code for free.





2009/11/11 Ryan Raasch >




Carlos Lavin wrote:

i don't know that it pass with this module, ov7670.c , because i
don't see
in the screen of my Pc this modulo when the kernel is load. this
module
haven't the module_init  function , and i don't know if it is
possible to
run it without this function. the version kernel where i work is
2.6.30,
also i have patched this modulo for works with the library
soc_camera.h
can anybody help me? I am rookie in this topics.
thanks.
--

What are you asking?

Ryan

video4linux-list mailing list
Unsubscribe mailto:video4linux-list-requ...@redhat.com
?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list



--
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

[Hans Verkuil]

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:Wed Nov 11 19:00:04 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13327:19c0469c02c3
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: WARNINGS
linux-2.6.23.12-armv5: WARNINGS
linux-2.6.24.7-armv5: WARNINGS
linux-2.6.25.11-armv5: WARNINGS
linux-2.6.26-armv5: WARNINGS
linux-2.6.27-armv5: WARNINGS
linux-2.6.28-armv5: WARNINGS
linux-2.6.29.1-armv5: WARNINGS
linux-2.6.30-armv5: WARNINGS
linux-2.6.31-armv5: WARNINGS
linux-2.6.32-rc6-armv5: ERRORS
linux-2.6.32-rc6-armv5-davinci: ERRORS
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-armv5-ixp: WARNINGS
linux-2.6.31-armv5-ixp: WARNINGS
linux-2.6.32-rc6-armv5-ixp: ERRORS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.31-armv5-omap2: ERRORS
linux-2.6.32-rc6-armv5-omap2: OK
linux-2.6.22.19-i686: WARNINGS
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-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.32-rc6-i686: WARNINGS
linux-2.6.23.12-m32r: WARNINGS
linux-2.6.24.7-m32r: WARNINGS
linux-2.6.25.11-m32r: WARNINGS
linux-2.6.26-m32r: WARNINGS
linux-2.6.27-m32r: WARNINGS
linux-2.6.28-m32r: WARNINGS
linux-2.6.29.1-m32r: WARNINGS
linux-2.6.30-m32r: WARNINGS
linux-2.6.31-m32r: WARNINGS
linux-2.6.32-rc6-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: WARNINGS
linux-2.6.32-rc6-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-powerpc64: WARNINGS
linux-2.6.31-powerpc64: WARNINGS
linux-2.6.32-rc6-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-rc6-x86_64: ERRORS
sparse (linux-2.6.31): OK
sparse (linux-2.6.32-rc6): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: WARNINGS
linux-2.6.19.5-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.5-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The V4L2 specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification failed to build, but the last compiled spec 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: [PATCH] videobuf-dma-contig.c: add missing #include

[Guennadi Liakhovetski]

On Sat, 31 Oct 2009, Martin Michlmayr wrote:

> media/video/videobuf-dma-contig.c fails to compile on ARM Versatile
> like this:
>  | videobuf-dma-contig.c: In function ‘videobuf_dma_contig_user_get’:
>  | videobuf-dma-contig.c:139: error: dereferencing pointer to incomplete type
>  | videobuf-dma-contig.c:184: error: dereferencing pointer to incomplete type
>  | make[8]: *** [drivers/media/video/videobuf-dma-contig.o] Error 1
> 
> Looking at the preprocessed source, I noticed that there was no definition
> for struct task_struct.
> 
> Signed-off-by: Martin Michlmayr 

Mauro, if you decide to apply this one and then only take missing parts 
from 
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d5defdb8768d 
then you can add my

Acked-by: Guennadi Liakhovetski 

to this one.

> 
> --- a/drivers/media/video/videobuf-dma-contig.c   2009-10-31 
> 10:22:42.0 +
> +++ b/drivers/media/video/videobuf-dma-contig.c   2009-10-31 
> 10:24:40.0 +
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct videobuf_dma_contig_memory {
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.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
> 

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] videobuf-dma-contig.c: add missing #include

[Martin Michlmayr]

* Guennadi Liakhovetski  [2009-11-11 19:38]:
> > Are there any comments regarding the build fix I submitted?  This
> > issue is still there, as you can see at
> > http://www.xs4all.nl/~hverkuil/logs/Tuesday.log
> 
> Oh, I'm afraid, I've unwillingly stolen your patch:
> 
> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d5defdb8768d
> 
> Sorry about that. But if your patch landed in patchwork, which it should, 
> thenmaybe yours will be used in the end.

Yes, it's here: http://patchwork.kernel.org/patch/56763/

Maybe you can add your acked-by.
-- 
Martin Michlmayr
http://www.cyrius.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://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

On Wed, Nov 11, 2009 at 8:58 AM, Michael Krufky  wrote:
> On Wed, Nov 11, 2009 at 8:52 AM, Michael Krufky  
> wrote:
>> Mauro,
>>
>> Please pull from:
>>
>> http://kernellabs.com/hg/~mkrufky/cx23885

I added another changeset.  Please pull for:

- cx23885: add digital television support for Hauppauge WinTV-HVR1290
- cx23885: update model matrix for models 85021 and 85721
- cx23885: Enable IR input keypress handling for the Hauppauge WinTV HVR-1290

 Documentation/video4linux/CARDLIST.cx23885  |1
 drivers/media/video/cx23885/cx23885-cards.c |   21 +-
 drivers/media/video/cx23885/cx23885-dvb.c   |1
 drivers/media/video/cx23885/cx23885-input.c |5 ++
 drivers/media/video/cx23885/cx23885.h   |1
 5 files changed, 28 insertions(+), 1 deletion(-)

I don't expect to make any more changes for a while ;-)

Thanks again,

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] videobuf-dma-contig.c: add missing #include

[Guennadi Liakhovetski]

On Wed, 11 Nov 2009, Martin Michlmayr wrote:

> Are there any comments regarding the build fix I submitted?  This
> issue is still there, as you can see at
> http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Oh, I'm afraid, I've unwillingly stolen your patch:

http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d5defdb8768d

Sorry about that. But if your patch landed in patchwork, which it should, 
thenmaybe yours will be used in the end.

> 
> * Martin Michlmayr  [2009-10-31 10:28]:
> > media/video/videobuf-dma-contig.c fails to compile on ARM Versatile
> > like this:
> >  | videobuf-dma-contig.c: In function ‘videobuf_dma_contig_user_get’:
> >  | videobuf-dma-contig.c:139: error: dereferencing pointer to incomplete 
> > type
> >  | videobuf-dma-contig.c:184: error: dereferencing pointer to incomplete 
> > type
> >  | make[8]: *** [drivers/media/video/videobuf-dma-contig.o] Error 1
> > 
> > Looking at the preprocessed source, I noticed that there was no definition
> > for struct task_struct.
> > 
> > Signed-off-by: Martin Michlmayr 
> > 
> > --- a/drivers/media/video/videobuf-dma-contig.c 2009-10-31 
> > 10:22:42.0 +
> > +++ b/drivers/media/video/videobuf-dma-contig.c 2009-10-31 
> > 10:24:40.0 +
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  struct videobuf_dma_contig_memory {

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Global video buffers pool / Samsung SoC's

[Guennadi Liakhovetski]

On Wed, 11 Nov 2009, Harald Welte wrote:

> Hi Guennadi and others,
> 
> first of all sorry for breaking the thread, but I am new to this list
> and could not find the message-id of the original mails nor a .mbox
> format archive for the list :(
> 
> As I was one of the people giving comments to Guennadi's talk at ELCE,
> let me give some feedback here, too.

Adding the author of the RFC to CC.

> I'm currently helping the Samsung System LSI Linux kernel team with
> bringing their various ports for their ARM SoCs mainline.  So far we
> have excluded much of the multimedia related parts due to the complexity
> and lack of kernel infrastructure.
> 
> Let me briefly describe the SoCs in question: They have an ARM9, ARM11
> or Cortex-A8 core and multiple video input and output paths, such as
> * camera interface
> * 2d acceleration engine
> * 3d acceleration engine
> * post-processor (colorspace conversion, scaling, rotating)
> * LCM output for classic digital RGB+sync interfaces
> * TV scaler
> * TV encoder
> * HDMI interface (simple serial-HDMI with DMA from/to system memory)
> * Transport Stream interface (MPEG-transport stream input with PID
>   filter which can DMA to system memory
> * MIPI-HSI LCM output device
> * Multi-Function codec for H.264 and other stuff
> * Hardware JPEG codec.
> plus even some more that I might have missed.
> 
> One of the issues is that, at least in many current and upcoming
> products, all those integrated peripherals can only use physically
> contiguous memory.
> 
> For the classic output path (e.g. Xorg+EXA+XAA+3D), that is fine.  The
> framebuffer driver can simply allocate some large chunk of physical
> system memory at boot time, map that into userspace and be happy.  This
> includes things like Xvideo support in the Xserver.  Also, HDMI output
> and TV output can be handled inside X or switch to a new KMS model.
> 
> However, the input side looks quite different,  On the one hand, we have
> the camera driver, but possibly HDMI input and transport stream input,
> are less easy.
> 
> also, given the plethora of such subsytems in a device, you definitely
> don't want to have one static big boot-time allocation for each of those
> devices.  You don't want to waste that much memory all the time just in
> case at some time you start an application that actually needs this.
> Also, it is unlikely that all of the subsystems will operate at the same
> time.
> 
> So having an in-kernel allocator for physically contiguous memory is
> something that is needed to properly support this hardware.  At boot
> time you allocate one big pool, from which you then on-demand allocate
> and free physically contiguous buffers, even at much later time.
> 
> Furthermore, think of something like the JPEG codec acceleration, which
> you also want to use zero-copy from userspace.  So userpsace (like
> libjpeg for decode, or a camera application for encode)would also need
> to be able to allocate such a buffer inside the kernel for input and
> output data of the codec, mmap it, put its jpeg data into it and then
> run the actual codec.
> 
> How would that relate to the proposed global video buffers pool? Well,
> I think before thinking strictly about video buffers for camera chips,
> we have to think much more generically!
> 
> Also, has anyone investigated if GEM or TTM could be used in unmodified
> or modified form for this?  After all, they are intended to allocate
> (and possibly map) video buffers...

Don't think I can contribute much to the actual matter of the discussion, 
yes, there is a problem, the RFC is trying to address it, there have been 
attempts to implement similar things before (as you write above), so, it 
"just" has to eventually be done.

One question to your SoCs though - do they have SRAM? usable and 
sufficient for graphics buffers? In any case any such implementation will 
have to be able to handle RAMs other than main system memory too, 
including card memory, NUMA, sparse RAM, etc., which is probably obvious 
anyway.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] soc_camera: multiple input capable enum, g & s

[Guennadi Liakhovetski]

On Tue, 10 Nov 2009, Philipp Wiesner wrote:

> soc_camera: multiple input capable enum, g & s
> 
> From: Philipp Wiesner 
> 
> I did some small changes to support soc camera devices with multiple 
> inputs, e.g. tw9910 (driver doesn't support this yet).
> soc-camera.c:
> soc_camera_enum_input: capable of handling multiple inputs.
> soc_camera_g_input: calls icd's g_input if present.
> soc_camera_s_input: calls icd's s_input if present.
> soc-camera.h:
> struct soc_camera_ops: Added aliases for g_input and s_input functions here.

Thanks for the patch, and yes, supporting multiple inputs would be good, 
but: 1) we should not add new operations to soc_camera_ops. Any new client 
operations should be implemented using the v4l2-subdev API. 2) we should 
first decide what we want to use multiple inputs for. There have beed 
discussions to use inputs for switching between sensors on one interface, 
or for switching between video and still-image modes... What is your 
use-case for them?

Thanks
Guennadi

> 
> Priority: normal
> 
> Signed-off-by: Philipp Wiesner 
> 
> diff -r 43878f8dbfb0 -r a5254e7d306a linux/drivers/media/video/soc_camera.c
> --- a/linux/drivers/media/video/soc_camera.c  Sun Nov 01 07:17:46 2009 -0200
> +++ b/linux/drivers/media/video/soc_camera.c  Tue Nov 03 17:17:49 2009 +0100
> @@ -119,11 +119,10 @@
>   struct soc_camera_device *icd = icf->icd;
>   int ret = 0;
>  
> - if (inp->index != 0)
> - return -EINVAL;
> -
>   if (icd->ops->enum_input)
>   ret = icd->ops->enum_input(icd, inp);
> + else if (inp->index != 0)
> + return -EINVAL;
>   else {
>   /* default is camera */
>   inp->type = V4L2_INPUT_TYPE_CAMERA;
> @@ -136,17 +135,30 @@
>  
>  static int soc_camera_g_input(struct file *file, void *priv, unsigned int *i)
>  {
> - *i = 0;
> + struct soc_camera_file *icf = file->private_data;
> + struct soc_camera_device *icd = icf->icd;
> + int ret = 0;
>  
> - return 0;
> + if (icd->ops->g_input)
> + ret = icd->ops->g_input(icd, i);
> + else
> + *i = 0;
> +
> + return ret;
>  }
>  
>  static int soc_camera_s_input(struct file *file, void *priv, unsigned int i)
>  {
> - if (i > 0)
> + struct soc_camera_file *icf = file->private_data;
> + struct soc_camera_device *icd = icf->icd;
> + int ret = 0;
> +
> + if (icd->ops->s_input)
> + ret = icd->ops->s_input(icd, i);
> + else if (i > 0)
>   return -EINVAL;
>  
> - return 0;
> + return ret;
>  }
>  
>  static int soc_camera_s_std(struct file *file, void *priv, v4l2_std_id *a)
> diff -r 43878f8dbfb0 -r a5254e7d306a linux/include/media/soc_camera.h
> --- a/linux/include/media/soc_camera.hSun Nov 01 07:17:46 2009 -0200
> +++ b/linux/include/media/soc_camera.hTue Nov 03 17:17:49 2009 +0100
> @@ -197,6 +197,8 @@
>   unsigned long (*query_bus_param)(struct soc_camera_device *);
>   int (*set_bus_param)(struct soc_camera_device *, unsigned long);
>   int (*enum_input)(struct soc_camera_device *, struct v4l2_input *);
> + int (*g_input)(struct soc_camera_device *, unsigned int *);
> + int (*s_input)(struct soc_camera_device *, unsigned int);
>   const struct v4l2_queryctrl *controls;
>   int num_controls;
>  };
> 
> -- 
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> --
> 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
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

problems receiving channels with technotrend S-3200

[Stefan]

Howdy,

I'v problems with receiving dvb-s channels especially all the bbc
channels on freesat (Astra 28.2) .
The card is working fine for all the dutch channels (canaal digitaal)
and in windows i have no problem receiving bbc hd

But as soon as i tune in to for example bbchd or bbc1 i do get a lock
but no data.

# dvbstream -f 10847000 -p v -s 22000 -v 5500 -a 5501 -o > bbchd.mpg
dvbstream v0.6 - (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://www.linuxstb.org/
Tuning to 10847000 Hz
Using DVB card "STB0899 Multistandard", freq=10847000
tuning DVB-S to Freq: 1097000, Pol:V Srate=2200, 22kHz tone=off, LNB: 0
Setting only tone OFF and voltage 13V
DISEQC SETTING SUCCEDED
Getting frontend status
Event:  Frequency: 10847000
   SymbolRate: 2200
   FEC_inner:  9

Bit error rate: 0
Signal strength: 396
SNR: 134
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
dvbstream will stop after -1 seconds (71582788 minutes)
Output to stdout
Streaming 2 streams
^CCaught signal 2 - closing cleanly.

but the file remains empty

-rw-r--r--  1 root   root   0 2009-11-11 18:17 bbchd.mpg


When i try to record bvn (a fta channel)

# dvbstream -f 12574000 -p h -s 22000 -v 515 -a 96 -o > bvn.mpg
dvbstream v0.6 - (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://www.linuxstb.org/
Tuning to 12574000 Hz
Using DVB card "STB0899 Multistandard", freq=12574000
tuning DVB-S to Freq: 1974000, Pol:H Srate=2200, 22kHz tone=off, LNB: 0
Setting only tone ON and voltage 18V
DISEQC SETTING SUCCEDED
Getting frontend status
Event:  Frequency: 12574000
   SymbolRate: 2200
   FEC_inner:  9

Bit error rate: 0
Signal strength: 226
SNR: 125
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
dvbstream will stop after -1 seconds (71582788 minutes)
Output to stdout
Streaming 2 streams

-rw-r--r--  1 root   root10409560 2009-11-11 19:01 bvn.mpg


[9.920926] saa7146: register extension 'budget_ci dvb'.
[9.921032] budget_ci dvb :03:06.0: PCI INT A -> GSI 21
(level,low) -> IRQ 21
[9.921108] DVB: registering new adapter (TT-Budget S2-3200 PCI)
[9.981192] input: Budget-CI dvb ir receiver saa7146 (0)
as/devices/pci:00/:00:14.4/:03:06.0/input/input5
[   10.883169] DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)...
[   20.031267] dvb_ca adaptor 0: PC card did not respond :(
[   28.201492] dvb_ca adapter 0: DVB CAM detected and initialised successfully

running on
2.6.31-14-generic #48-Ubuntu SMP x86_64 with latest (10-11-2009) v4l dvb drivers
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v3] Add camera support for A780 and A910 EZX phones

[Guennadi Liakhovetski]

Hi Antonio

Still one more nitpick:

On Wed, 11 Nov 2009, Antonio Ospite wrote:

> Signed-off-by: Bart Visscher 
> Signed-off-by: Antonio Ospite 
> 
> ---
> Changes since v2:
> 
>  - Bart's SOB goes first, as he is the original author.
>  - Add MFP_LPM_DRIVE_HIGH to camera gpios, as per Motorola original
>code.
>  - s/pxacamera/camera/ in function names, as they are not used in
>pxacamera_platform_data
>  - Adjust comments about CAM_RST which is active on rising edge
>  - Saner default values for nCAM_EN and CAM_RST gpios
>  - Setup gpios statically at board init.
> 
> Eric, if it is easier for you I can send the three patches together again.
> 
> Thanks,
>Antonio
>  
>  arch/arm/mach-pxa/ezx.c |  172 +-
>  1 files changed, 168 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
> index 588b265..74423a6 100644
> --- a/arch/arm/mach-pxa/ezx.c
> +++ b/arch/arm/mach-pxa/ezx.c
> @@ -17,8 +17,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -29,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "devices.h"
>  #include "generic.h"
> @@ -38,6 +42,9 @@
>  #define GPIO15_A910_FLIP_LID 15
>  #define GPIO12_E680_LOCK_SWITCH  12
>  #define GPIO15_E6_LOCK_SWITCH15
> +#define GPIO50_nCAM_EN   50
> +#define GPIO19_GEN1_CAM_RST  19
> +#define GPIO28_GEN2_CAM_RST  28
>  
>  static struct platform_pwm_backlight_data ezx_backlight_data = {
>   .pwm_id = 0,
> @@ -191,8 +198,8 @@ static unsigned long gen1_pin_config[] __initdata = {
>   GPIO94_CIF_DD_5,
>   GPIO17_CIF_DD_6,
>   GPIO108_CIF_DD_7,
> - GPIO50_GPIO,/* CAM_EN */
> - GPIO19_GPIO,/* CAM_RST */
> + GPIO50_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_EN */
> + GPIO19_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_RST */
>  
>   /* EMU */
>   GPIO120_GPIO,   /* EMU_MUX1 */
> @@ -248,8 +255,8 @@ static unsigned long gen2_pin_config[] __initdata = {
>   GPIO48_CIF_DD_5,
>   GPIO93_CIF_DD_6,
>   GPIO12_CIF_DD_7,
> - GPIO50_GPIO,/* CAM_EN */
> - GPIO28_GPIO,/* CAM_RST */
> + GPIO50_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_EN */
> + GPIO28_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_RST */
>   GPIO17_GPIO,/* CAM_FLASH */
>  };
>  #endif
> @@ -683,8 +690,84 @@ static struct platform_device a780_gpio_keys = {
>   },
>  };
>  
> +/* camera */
> +static int a780_camera_init(void)

This function returns an error but...

> +{
> + int err;
> +
> + /*
> +  * GPIO50_nCAM_EN is active low
> +  * GPIO19_GEN1_CAM_RST is active on rising edge
> +  */
> + err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
> + if (err) {
> + pr_err("%s: Failed to request nCAM_EN\n", __func__);
> + goto fail;
> + }
> +
> + err = gpio_request(GPIO19_GEN1_CAM_RST, "CAM_RST");
> + if (err) {
> + pr_err("%s: Failed to request CAM_RST\n", __func__);
> + goto fail_gpio_cam_rst;
> + }
> +
> + gpio_direction_output(GPIO50_nCAM_EN, 1);
> + gpio_direction_output(GPIO19_GEN1_CAM_RST, 0);
> +
> + return 0;
> +
> +fail_gpio_cam_rst:
> + gpio_free(GPIO50_nCAM_EN);
> +fail:
> + return err;
> +}
> +
> +static int a780_camera_power(struct device *dev, int on)
> +{
> + gpio_set_value(GPIO50_nCAM_EN, !on);
> + return 0;
> +}
> +
> +static int a780_camera_reset(struct device *dev)
> +{
> + gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
> + msleep(10);
> + gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
> +
> + return 0;
> +}
> +
> +struct pxacamera_platform_data a780_pxacamera_platform_data = {
> + .flags  = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
> + PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
> + .mclk_10khz = 5000,
> +};
> +
> +static struct i2c_board_info a780_camera_i2c_board_info = {
> + I2C_BOARD_INFO("mt9m111", 0x5d),
> +};
> +
> +static struct soc_camera_link a780_iclink = {
> + .bus_id = 0,
> + .flags  = SOCAM_SENSOR_INVERT_PCLK,
> + .i2c_adapter_id = 0,
> + .board_info = &a780_camera_i2c_board_info,
> + .module_name= "mt9m111",
> + .power  = a780_camera_power,
> + .reset  = a780_camera_reset,
> +};
> +
> +static struct platform_device a780_camera = {
> + .name   = "soc-camera-pdrv",
> + .id = 0,
> + .dev= {
> + .platform_data = &a780_iclink,
> + },
> +};
> +
>  static struct platform_device *a780_devices[] __initdata = {
>   &a780_gpio_keys,
> + &a780_camera,
>  };
>  
>  static void __init a780_init(void)
> @@ -699,6 +782,9 @@ static void __init a780_init

Re: [RFC] Video events, version 2.2

[Hans Verkuil]

On Wednesday 11 November 2009 18:29:52 Sakari Ailus wrote:
> Hans Verkuil wrote:
> > On Saturday 24 October 2009 23:56:24 Sakari Ailus wrote:
> >> Ivan T. Ivanov wrote:
> >>> Hi Sakari, 
> >> Hi,
> >>
> >>> On Fri, 2009-10-23 at 13:18 +0300, Sakari Ailus wrote:
> >> [clip]
>  struct v4l2_event {
>   __u32   count;
>   __u32   type;
>   __u32   sequence;
>   struct timeval  timestamp;
> >>> Can we use 'struct timespec' here. This will force actual 
> >>> implementation to use high-resolution source if possible, 
> >>> and remove hundreds gettimeofday() in user space, which 
> >>> should be used for event synchronization, with more 
> >>> power friendly clock_getres(CLOCK_MONOTONIC).
> >> Good point. I originally picked timeval since it was used in 
> >> v4l2_buffer. The spec tells to use gettimeofday() for system time but 
> >> clock skewing is causes problems in video encoding. 
> >> clock_getres(CLOCK_MONOTONIC) is free of clock skewing and thus should 
> >> be more suitable for this kind of use.
> >>
> >> I also propose to use timespec instead of timeval.
> >>
> > 
> > Hi Sakari,
> > 
> > What is that status of the event API? It is my impression that it is pretty
> > much finished. Sakari, can you make a final 2.3 RFC? Then Guru can take over
> > and start the implementation.
> 
> Ah.
> 
> One thing that I was still wondering was that are there use cases where 
> other kind of time stamps might be useful? I guess that when the V4L2 
> was designed no-one though of the need for time stamps of different 
> type. So are there use cases where gettimeofday() style stamps would 
> still be better?

If you ever need to relate an event to a specific captured frame, then that
might well be useful. But I can't think of an actual use case, though.

> In that case we might choose to leave it driver's decision to decide 
> what kind of timestamps to use and in that case application would just 
> have to know. The alternative would be to use union and a flag telling 
> what's in there.
> 

Let's go with timespec. If we need to add an event that has to relate to
a specific captured frame then it is always possible to add a struct timeval
as part of the event data for that particular event.

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] videobuf-dma-contig.c: add missing #include

[Hiremath, Vaibhav]

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Martin Michlmayr
> Sent: Wednesday, November 11, 2009 9:24 PM
> To: linux-media@vger.kernel.org
> Cc: Mauro Carvalho Chehab
> Subject: Re: [PATCH] videobuf-dma-contig.c: add missing #include
> 
> Are there any comments regarding the build fix I submitted?  This
> issue is still there, as you can see at
> http://www.xs4all.nl/~hverkuil/logs/Tuesday.log
> 
[Hiremath, Vaibhav] Tested by me, and it is required, since this is breaking 
the build. Should get merged.

Thanks,
Vaibhav

> * Martin Michlmayr  [2009-10-31 10:28]:
> > media/video/videobuf-dma-contig.c fails to compile on ARM
> Versatile
> > like this:
> >  | videobuf-dma-contig.c: In function
> 'videobuf_dma_contig_user_get':
> >  | videobuf-dma-contig.c:139: error: dereferencing pointer to
> incomplete type
> >  | videobuf-dma-contig.c:184: error: dereferencing pointer to
> incomplete type
> >  | make[8]: *** [drivers/media/video/videobuf-dma-contig.o] Error
> 1
> >
> > Looking at the preprocessed source, I noticed that there was no
> definition
> > for struct task_struct.
> >
> > Signed-off-by: Martin Michlmayr 
> >
> > --- a/drivers/media/video/videobuf-dma-contig.c 2009-10-31
> 10:22:42.0 +
> > +++ b/drivers/media/video/videobuf-dma-contig.c 2009-10-31
> 10:24:40.0 +
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  struct videobuf_dma_contig_memory {
> >
> > --
> > Martin Michlmayr
> > http://www.cyrius.com/
> 
> --
> Martin Michlmayr
> http://www.cyrius.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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Video events, version 2.2

[Sakari Ailus]

Hans Verkuil wrote:

On Saturday 24 October 2009 23:56:24 Sakari Ailus wrote:

Ivan T. Ivanov wrote:
Hi Sakari, 

Hi,


On Fri, 2009-10-23 at 13:18 +0300, Sakari Ailus wrote:

[clip]

struct v4l2_event {
__u32   count;
__u32   type;
__u32   sequence;
struct timeval  timestamp;
Can we use 'struct timespec' here. This will force actual 
implementation to use high-resolution source if possible, 
and remove hundreds gettimeofday() in user space, which 
should be used for event synchronization, with more 
power friendly clock_getres(CLOCK_MONOTONIC).
Good point. I originally picked timeval since it was used in 
v4l2_buffer. The spec tells to use gettimeofday() for system time but 
clock skewing is causes problems in video encoding. 
clock_getres(CLOCK_MONOTONIC) is free of clock skewing and thus should 
be more suitable for this kind of use.


I also propose to use timespec instead of timeval.



Hi Sakari,

What is that status of the event API? It is my impression that it is pretty
much finished. Sakari, can you make a final 2.3 RFC? Then Guru can take over
and start the implementation.


Ah.

One thing that I was still wondering was that are there use cases where 
other kind of time stamps might be useful? I guess that when the V4L2 
was designed no-one though of the need for time stamps of different 
type. So are there use cases where gettimeofday() style stamps would 
still be better?


In that case we might choose to leave it driver's decision to decide 
what kind of timestamps to use and in that case application would just 
have to know. The alternative would be to use union and a flag telling 
what's in there.


--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP 3 ISP and N900 sensor driver update

[Hiremath, Vaibhav]

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
> Sent: Monday, November 09, 2009 7:36 PM
> To: Karicheri, Muralidharan
> Cc: Sakari Ailus; linux-media@vger.kernel.org; Hans Verkuil; Cohen
> David Abraham; Koskipää Antti Jussi Petteri; Toivonen Tuukka Olli
> Artturi; Zutshi Vimarsh (Nokia-D-MSW/Helsinki);
> talv...@stanford.edu; Aguirre, Sergio; Ivan Ivanov; Stan Varbanov;
> Valeri Ivanov; Atanas Filipov
> Subject: Re: OMAP 3 ISP and N900 sensor driver update
> 
> Hi Murali,
> 
> On Friday 06 November 2009 16:25:01 Karicheri, Muralidharan wrote:
> > Sakari,
> >
> > Thanks for the update...
> >
> > Who is working on the CCDC driver for OMAP35xx?
> 
> Just for the sake of correctness, we're working on an OMAP34xx, not
> an
> OMAP35xx. I don't think that makes a big difference though.
> 
[Hiremath, Vaibhav] OMAP3430 and OMAP3530 are exactly same devices.

> As far as I know nobody on our side is currently working on the CCDC
> driver.
> We're focusing on the previewer and resizer first.
> 
[Hiremath, Vaibhav] I believe I should be able to see the current development 
activity on sakari's repo, right?

Thanks,
Vaibhav
> > After a week or so, I need to start migrating the CCDC driver to
> sub device
> > interface so that application can directly configure the
> parameters with out
> > having to go through video node. Ultimately it is expected that
> ccdc will
> > have a device node that will allow application to open the device
> and
> > configure the parameters (in the context of Media controller). But
> to begin
> > with I intend to port the existing CCDC driver for DM6446 and
> DM355 to sub
> > device interface. Since the VPFE IPs are common across DM6446 &
> OMAP 35xx,
> > we could use a common sub device across both platforms.
> 
> Coordinating our efforts on that front would indeed be very nice.
> 
> > So I this context, could you please update me on the CCDC
> development
> > on OMAP platform that you work?
> 
> I haven't checked the Davinci VPFE drivers recently. I suppose they
> already
> use the v4l2_subdev interface for their I2C sensors and tuners. If
> not, that
> would be the first step.
> 
> On the OMAP34xx platform, the ISP driver is already somehow
> separated from the
> omap34xxcam driver, although not nicely. In a nutshell, here's the
> current
> plan. Parts 1 and 2 are already implemented and code is available in
> Sakari's
> linux-omap tree.
> 
> 1. Board code registers an omap34xxcam platform device. The platform
> data
> contains an array of v4l2_subdev_i2c_board_info structures filled
> with
> information about all I2C sub-devices (sensor, flash controller,
> lens
> controller, ...).
> 
> 2. The omap34xxcam driver is loaded. Its probe function is called
> with a
> pointer to the platform device. The driver registers a v4l2_device
> and creates
> I2C subdevices using the data supplied through platform data.
> 
> 3. The omap34xxcam driver calls the ISP core with a pointer to the
> v4l2_device
> structure to register all ISP subdevices. The ISP core maintains
> pointers to
> the ISP subdevices.
> 
> As ISP submodules (CCDC, previewer, resizer) are not truly
> independent, we
> were not planning to split them into separate kernel modules. The
> ISP core
> needs to call explicitly into the submodules for instance to
> dispatch
> interrupts.
> 
> It should be possible to use a single CCDC code base across multiple
> platforms. The ISP core module would depend on the CCDC module
> directly. I'm
> not sure how the CCDC module should be called though. An omap prefix
> won't
> work, as it's used on Davinci as well, and an ISP prefix is too
> generic. Do
> you have any internal code name for the ISP device used on Davinci
> and OMAP
> platforms ?
> 
> The code will be pushed to linux-omap when available, but I can't
> commit to
> any deadline. If you start working on the Davinci driver before we
> post
> anything, could you please post patches and/or RFCs on the linux-
> media mailing
> list (and CC'ing us) ? Confronting our ideas as soon as possible
> will
> (hopefully) avoid diverging too much in our implementations.
> 
> --
> Regards,
> 
> Laurent Pinchart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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] sms-cards: make id unsigned in sms_get_board()

[Roel Kluin]

Make id signed so we can't get an invalid pointer
when we pass a negative id.

Signed-off-by: Roel Kluin 
---
 drivers/media/dvb/siano/sms-cards.c |2 +-
 drivers/media/dvb/siano/sms-cards.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/siano/sms-cards.c 
b/drivers/media/dvb/siano/sms-cards.c
index 0420e28..c61f026 100644
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -97,7 +97,7 @@ static struct sms_board sms_boards[] = {
},
 };
 
-struct sms_board *sms_get_board(int id)
+struct sms_board *sms_get_board(unsigned id)
 {
BUG_ON(id >= ARRAY_SIZE(sms_boards));
 
diff --git a/drivers/media/dvb/siano/sms-cards.h 
b/drivers/media/dvb/siano/sms-cards.h
index 38f062f..8f19fc0 100644
--- a/drivers/media/dvb/siano/sms-cards.h
+++ b/drivers/media/dvb/siano/sms-cards.h
@@ -81,7 +81,7 @@ struct sms_board {
int led_power, led_hi, led_lo, lna_ctrl, rf_switch;
 };
 
-struct sms_board *sms_get_board(int id);
+struct sms_board *sms_get_board(unsigned id);
 
 extern struct smscore_device_t *coredev;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)

[Thomas Kernen]

Thomas Kernen wrote:

Hello,

I came across this thread from June 2009 in the news archives about 
Ubuntu Karmic and v4l-dvb compile broken with stock Ubuntu Karmic build:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/7161 



I've just come across this issue myself after an upgrade of a server to 
the Ubuntu Karmic release.


Is there any plans to attempt to mitigate this so that other users would 
not be impacted?


Regards,
Thomas


I don't like answering my own messages but hopefully this will be useful 
to other users too who may come across the same issue as I and didn't do 
enough research before asking the question.


Ubuntu Karmic is missing some Firewire/IEEE1394 files in the 
kernel-headers package.


Workaround:
in the v4l folder, open the .config file, find the line with 
"CONFIG_DVB_FIREDTV=m" and change to "CONFIG_DVB_FIREDTV=n".


Thomas
--
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] videobuf-dma-contig.c: add missing #include

[Martin Michlmayr]

Are there any comments regarding the build fix I submitted?  This
issue is still there, as you can see at
http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

* Martin Michlmayr  [2009-10-31 10:28]:
> media/video/videobuf-dma-contig.c fails to compile on ARM Versatile
> like this:
>  | videobuf-dma-contig.c: In function ‘videobuf_dma_contig_user_get’:
>  | videobuf-dma-contig.c:139: error: dereferencing pointer to incomplete type
>  | videobuf-dma-contig.c:184: error: dereferencing pointer to incomplete type
>  | make[8]: *** [drivers/media/video/videobuf-dma-contig.o] Error 1
> 
> Looking at the preprocessed source, I noticed that there was no definition
> for struct task_struct.
> 
> Signed-off-by: Martin Michlmayr 
> 
> --- a/drivers/media/video/videobuf-dma-contig.c   2009-10-31 
> 10:22:42.0 +
> +++ b/drivers/media/video/videobuf-dma-contig.c   2009-10-31 
> 10:24:40.0 +
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct videobuf_dma_contig_memory {
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/

-- 
Martin Michlmayr
http://www.cyrius.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: Fwd: Hauppauge HVR-1600 cx18 loading problem

[Andy Walls]

On Wed, 2009-11-11 at 00:15 -0500, John Nuszkowski wrote:

> 
> See my comments below.
> 
> On Tue, Nov 10, 2009 at 8:03 PM, Andy Walls  wrote:
> > On Tue, 2009-11-10 at 12:13 -0500, John Nuszkowski wrote:
> >> My new Hauppauge HVR-1600 does not load the firmware.  The driver was
> >> built using the source from over the weekend.  I am using mythbuntu.
> >>
> >> Below is a "modprobe cx18 debug=511" command
> >>
> >> Any help would greatly be appreciated.

> >> [43594.594104] cx18 :00:0c.0: firmware: requesting v4l-cx23418-cpu.fw
> >> [43594.607124] cx18-0: Mismatch at offset 0
> >
> > OK.  That's bad.  From messages previous to this, we can obviously
> > access CX23418 registers.  This "Mismatch at offset 0" message indicates
> > that writes or reads to the memory chip on the HVR-1600 via the PCI bus
> > and the CX23418 are failing.
> >
> > Possible causes are:
> >
> > 1. Repeated PCI bus errors when trying to write or write to the CX23418
> > memory.
> >
> > 2. A new memory chip is is use on the HVR-1600 and the DRR memory
> > configuration parameters in the HVR-1600 entry in cx18-cards.c are
> > wrong.
> >
> > 3. Writes to CX23418 registers to configure the DDR memory parameters
> > failed.
> >
> > 4. Some other device driver or device DMA engine is errantly writing
> > into CX23418 memory space.
> >
> >
> > Some things you can you do:
> >
> > 1. Pull *all* your PCI cards out of your machine, blow the dust out of
> > the PCI slots, reseat all the cards and try again.  This should somewhat
> > mitigate PCI signal problems due to dust and oxidation.
> 
> Nothing changed.  I also moved the card to another PCI slot.

OK.  So much for the easy fix


> > 2. In the file
> >
> >cx18-driver.h
> >
> > change the value of
> >
> >#define CX18_MAX_MMIO_WR_RETRIES 10
> >
> > up from 10 to 20 (or whatever) to increase the number of retries when
> > writing to the CX23418 over the PCI bus.  Recompile and install the cx18
> > driver and test again.
>
> Same result.

OK.  This is a somewhat reasonable indicator that it is not a PCI bus
error.


> 
> 
> > 3. If you still have /dev/video* device nodes after modprobe, even
> > though the firmware load failed; compile the v4l-dbg in the v4l-dvb tree
> > and run these commands as root:
> >
> > # v4l2-dbg -d /dev/video1 -S
> > host0: cx23418revision 0x0101
> > host1: cx23418_843 revision 0x8430
> > i2c 0x4c: cs5345 revision 0x
> >
> 
> 
> # ./v4l2-dbg -D
> Failed to open /dev/video0: No such device or address
> 
> # ls -al /dev/video*
> crw-rw+ 1 root video 81, 0 2009-11-10 21:52 /dev/video0
> crw-rw+ 1 root video 81, 3 2009-11-10 21:52 /dev/video24
> crw-rw+ 1 root video 81, 1 2009-11-10 21:52 /dev/video32
> 
> So basically v4l2-dbg doesn't work with this error.  I wish I could do
> those commands below.

Hmm. OK now I see, since cx18-fileops.c:cx18-serialized_open() will
never get called when there is a firmware load problem, the device nodes
will not be usable.  Sorry for not noticing that earlier.


> > 4. Please provide the output of
> >
> > # lspci -nnvv
> > # cat /proc/iomem
> > # grep Vmalloc /proc/mem
> 
> # lspci -nnvv
> 
> 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] AMD-760
> [IGD4-1P] System Controller [1022:700e] (rev 13)
>Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- SERR- Latency: 32
>Region 0: Memory at d800 (32-bit, prefetchable) [size=64M]
>Region 1: Memory at e3001000 (32-bit, prefetchable) [size=4K]
>Region 2: I/O ports at d000 [disabled] [size=4]
>Capabilities: 
>Kernel driver in use: agpgart-amdk7
>Kernel modules: amd76x_edac, amd-k7-agp

I will note that the 64 MB PCI address region at 0xd800 is directly
below the CX23418 64 MB PCI address region at 0xdc0.

That region is, I'm guessing, somehow involved with some sort of
graphics memory aperature.


> 00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-760
> [IGD4-1P] AGP Bridge [1022:700f]
>Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- SERR- Latency: 32
>Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
>Memory behind bridge: e000-e1ff
>Prefetchable memory behind bridge: d000-d7ff
>Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium
> >TAbort- BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
>PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>Kernel modules: shpchp
> 
> 00:07.0 ISA bridge [0601]: VIA Technologies, Inc. VT82C686 [Apollo
> Super South] [1106:0686] (rev 40)
>Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super
> South] [1106:0686]
> 

DVB-C card

[Ryan Raasch]

Hello,

I am in need of a supported DVB-C pci card (or usb). I have a DVB-T 
card, and am now aware of all the standards, ugg, and so i need a DVB-C 
tuner.


I have found a
TerraTec Cinergy C and it looks like a low profile.

BTW, how is the performance/benifits of the usb encoders to the PCI?

Cheers,
Ryan
--
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://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

On Wed, Nov 11, 2009 at 8:52 AM, Michael Krufky  wrote:
> Mauro,
>
> Please pull from:
>
> http://kernellabs.com/hg/~mkrufky/cx23885
>
> for the following:

There was an extra line that I removed -- sorry for any confusion.
Here's the diffstat:

- cx23885: add digital television support for Hauppauge WinTV-HVR1290
- cx23885: update model matrix for models 85021 and 85721

 Documentation/video4linux/CARDLIST.cx23885  |1
 drivers/media/video/cx23885/cx23885-cards.c |   18 +-
 drivers/media/video/cx23885/cx23885-dvb.c   |1
 drivers/media/video/cx23885/cx23885.h   |1
 4 files changed, 20 insertions(+), 1 deletion(-)

Thanks & regards,

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v3] Add camera support for A780 and A910 EZX phones

[Eric Miao]

On Wed, Nov 11, 2009 at 7:01 PM, Antonio Ospite
 wrote:
> Signed-off-by: Bart Visscher 
> Signed-off-by: Antonio Ospite 
>
> ---
> Changes since v2:
>
>  - Bart's SOB goes first, as he is the original author.
>  - Add MFP_LPM_DRIVE_HIGH to camera gpios, as per Motorola original
>   code.
>  - s/pxacamera/camera/ in function names, as they are not used in
>   pxacamera_platform_data
>  - Adjust comments about CAM_RST which is active on rising edge
>  - Saner default values for nCAM_EN and CAM_RST gpios
>  - Setup gpios statically at board init.
>
> Eric, if it is easier for you I can send the three patches together again.
>

That's OK, I can find the rest two :)

Guennadi,

I need your Acked-by or Reviewed-by please.

> Thanks,
>   Antonio
>
>  arch/arm/mach-pxa/ezx.c |  172 +-
>  1 files changed, 168 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
> index 588b265..74423a6 100644
> --- a/arch/arm/mach-pxa/ezx.c
> +++ b/arch/arm/mach-pxa/ezx.c
> @@ -17,8 +17,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -29,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "devices.h"
>  #include "generic.h"
> @@ -38,6 +42,9 @@
>  #define GPIO15_A910_FLIP_LID           15
>  #define GPIO12_E680_LOCK_SWITCH        12
>  #define GPIO15_E6_LOCK_SWITCH          15
> +#define GPIO50_nCAM_EN                 50
> +#define GPIO19_GEN1_CAM_RST            19
> +#define GPIO28_GEN2_CAM_RST            28
>
>  static struct platform_pwm_backlight_data ezx_backlight_data = {
>        .pwm_id         = 0,
> @@ -191,8 +198,8 @@ static unsigned long gen1_pin_config[] __initdata = {
>        GPIO94_CIF_DD_5,
>        GPIO17_CIF_DD_6,
>        GPIO108_CIF_DD_7,
> -       GPIO50_GPIO,                            /* CAM_EN */
> -       GPIO19_GPIO,                            /* CAM_RST */
> +       GPIO50_GPIO | MFP_LPM_DRIVE_HIGH,       /* CAM_EN */
> +       GPIO19_GPIO | MFP_LPM_DRIVE_HIGH,       /* CAM_RST */
>
>        /* EMU */
>        GPIO120_GPIO,                           /* EMU_MUX1 */
> @@ -248,8 +255,8 @@ static unsigned long gen2_pin_config[] __initdata = {
>        GPIO48_CIF_DD_5,
>        GPIO93_CIF_DD_6,
>        GPIO12_CIF_DD_7,
> -       GPIO50_GPIO,                            /* CAM_EN */
> -       GPIO28_GPIO,                            /* CAM_RST */
> +       GPIO50_GPIO | MFP_LPM_DRIVE_HIGH,       /* CAM_EN */
> +       GPIO28_GPIO | MFP_LPM_DRIVE_HIGH,       /* CAM_RST */
>        GPIO17_GPIO,                            /* CAM_FLASH */
>  };
>  #endif
> @@ -683,8 +690,84 @@ static struct platform_device a780_gpio_keys = {
>        },
>  };
>
> +/* camera */
> +static int a780_camera_init(void)
> +{
> +       int err;
> +
> +       /*
> +        * GPIO50_nCAM_EN is active low
> +        * GPIO19_GEN1_CAM_RST is active on rising edge
> +        */
> +       err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
> +       if (err) {
> +               pr_err("%s: Failed to request nCAM_EN\n", __func__);
> +               goto fail;
> +       }
> +
> +       err = gpio_request(GPIO19_GEN1_CAM_RST, "CAM_RST");
> +       if (err) {
> +               pr_err("%s: Failed to request CAM_RST\n", __func__);
> +               goto fail_gpio_cam_rst;
> +       }
> +
> +       gpio_direction_output(GPIO50_nCAM_EN, 1);
> +       gpio_direction_output(GPIO19_GEN1_CAM_RST, 0);
> +
> +       return 0;
> +
> +fail_gpio_cam_rst:
> +       gpio_free(GPIO50_nCAM_EN);
> +fail:
> +       return err;
> +}
> +
> +static int a780_camera_power(struct device *dev, int on)
> +{
> +       gpio_set_value(GPIO50_nCAM_EN, !on);
> +       return 0;
> +}
> +
> +static int a780_camera_reset(struct device *dev)
> +{
> +       gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
> +       msleep(10);
> +       gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
> +
> +       return 0;
> +}
> +
> +struct pxacamera_platform_data a780_pxacamera_platform_data = {
> +       .flags  = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
> +               PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
> +       .mclk_10khz = 5000,
> +};
> +
> +static struct i2c_board_info a780_camera_i2c_board_info = {
> +       I2C_BOARD_INFO("mt9m111", 0x5d),
> +};
> +
> +static struct soc_camera_link a780_iclink = {
> +       .bus_id         = 0,
> +       .flags          = SOCAM_SENSOR_INVERT_PCLK,
> +       .i2c_adapter_id = 0,
> +       .board_info     = &a780_camera_i2c_board_info,
> +       .module_name    = "mt9m111",
> +       .power          = a780_camera_power,
> +       .reset          = a780_camera_reset,
> +};
> +
> +static struct platform_device a780_camera = {
> +       .name   = "soc-camera-pdrv",
> +       .id     = 0,
> +       .dev    = {
> +               .platform_data = &a780_iclink,
> +       },
> +};
> +
>  static struct platform_device *a780_devices[] __initdata = {
>        &a780_gpio_keys,
> +      

[PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/cx23885

for the following:

- cx23885: add digital television support for Hauppauge WinTV-HVR1290
- cx23885: update model matrix for models 85021 and 85721

 Documentation/video4linux/CARDLIST.cx23885  |1
 drivers/media/video/cx23885/cx23885-cards.c |   19 +-
 drivers/media/video/cx23885/cx23885-dvb.c   |1
 drivers/media/video/cx23885/cx23885.h   |1
 4 files changed, 21 insertions(+), 1 deletion(-)

Cheers,

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: module ov7670.c

[Ryan Raasch]

Carlos Lavin wrote:
i am asking that if it is possible to start a module without MODULE_INIT 
function in the body of program.


It looks as though all drivers that use v4l2_i2c_driver_data DO NOT use 
the module_init function.


According to commit 14386c2b7793652a656021a3345cff3b0f6771f9, 
v4l2_subdev is used instead. However, this is different for me also.



Ryan



2009/11/11 Ryan Raasch >




Carlos Lavin wrote:

i don't know that it pass with this module, ov7670.c , because i
don't see
in the screen of my Pc this modulo when the kernel is load. this
module
haven't the module_init  function , and i don't know if it is
possible to
run it without this function. the version kernel where i work is
2.6.30,
also i have patched this modulo for works with the library
soc_camera.h
can anybody help me? I am rookie in this topics.
thanks.
--

What are you asking?

Ryan

video4linux-list mailing list
Unsubscribe mailto:video4linux-list-requ...@redhat.com
?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list



--
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 1/3 v3] Add camera support for A780 and A910 EZX phones

[Antonio Ospite]

Signed-off-by: Bart Visscher 
Signed-off-by: Antonio Ospite 

---
Changes since v2:

 - Bart's SOB goes first, as he is the original author.
 - Add MFP_LPM_DRIVE_HIGH to camera gpios, as per Motorola original
   code.
 - s/pxacamera/camera/ in function names, as they are not used in
   pxacamera_platform_data
 - Adjust comments about CAM_RST which is active on rising edge
 - Saner default values for nCAM_EN and CAM_RST gpios
 - Setup gpios statically at board init.

Eric, if it is easier for you I can send the three patches together again.

Thanks,
   Antonio
 
 arch/arm/mach-pxa/ezx.c |  172 +-
 1 files changed, 168 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 588b265..74423a6 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -17,8 +17,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -29,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "devices.h"
 #include "generic.h"
@@ -38,6 +42,9 @@
 #define GPIO15_A910_FLIP_LID   15
 #define GPIO12_E680_LOCK_SWITCH12
 #define GPIO15_E6_LOCK_SWITCH  15
+#define GPIO50_nCAM_EN 50
+#define GPIO19_GEN1_CAM_RST19
+#define GPIO28_GEN2_CAM_RST28
 
 static struct platform_pwm_backlight_data ezx_backlight_data = {
.pwm_id = 0,
@@ -191,8 +198,8 @@ static unsigned long gen1_pin_config[] __initdata = {
GPIO94_CIF_DD_5,
GPIO17_CIF_DD_6,
GPIO108_CIF_DD_7,
-   GPIO50_GPIO,/* CAM_EN */
-   GPIO19_GPIO,/* CAM_RST */
+   GPIO50_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_EN */
+   GPIO19_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_RST */
 
/* EMU */
GPIO120_GPIO,   /* EMU_MUX1 */
@@ -248,8 +255,8 @@ static unsigned long gen2_pin_config[] __initdata = {
GPIO48_CIF_DD_5,
GPIO93_CIF_DD_6,
GPIO12_CIF_DD_7,
-   GPIO50_GPIO,/* CAM_EN */
-   GPIO28_GPIO,/* CAM_RST */
+   GPIO50_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_EN */
+   GPIO28_GPIO | MFP_LPM_DRIVE_HIGH,   /* CAM_RST */
GPIO17_GPIO,/* CAM_FLASH */
 };
 #endif
@@ -683,8 +690,84 @@ static struct platform_device a780_gpio_keys = {
},
 };
 
+/* camera */
+static int a780_camera_init(void)
+{
+   int err;
+
+   /*
+* GPIO50_nCAM_EN is active low
+* GPIO19_GEN1_CAM_RST is active on rising edge
+*/
+   err = gpio_request(GPIO50_nCAM_EN, "nCAM_EN");
+   if (err) {
+   pr_err("%s: Failed to request nCAM_EN\n", __func__);
+   goto fail;
+   }
+
+   err = gpio_request(GPIO19_GEN1_CAM_RST, "CAM_RST");
+   if (err) {
+   pr_err("%s: Failed to request CAM_RST\n", __func__);
+   goto fail_gpio_cam_rst;
+   }
+
+   gpio_direction_output(GPIO50_nCAM_EN, 1);
+   gpio_direction_output(GPIO19_GEN1_CAM_RST, 0);
+
+   return 0;
+
+fail_gpio_cam_rst:
+   gpio_free(GPIO50_nCAM_EN);
+fail:
+   return err;
+}
+
+static int a780_camera_power(struct device *dev, int on)
+{
+   gpio_set_value(GPIO50_nCAM_EN, !on);
+   return 0;
+}
+
+static int a780_camera_reset(struct device *dev)
+{
+   gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
+   msleep(10);
+   gpio_set_value(GPIO19_GEN1_CAM_RST, 1);
+
+   return 0;
+}
+
+struct pxacamera_platform_data a780_pxacamera_platform_data = {
+   .flags  = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
+   PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+   .mclk_10khz = 5000,
+};
+
+static struct i2c_board_info a780_camera_i2c_board_info = {
+   I2C_BOARD_INFO("mt9m111", 0x5d),
+};
+
+static struct soc_camera_link a780_iclink = {
+   .bus_id = 0,
+   .flags  = SOCAM_SENSOR_INVERT_PCLK,
+   .i2c_adapter_id = 0,
+   .board_info = &a780_camera_i2c_board_info,
+   .module_name= "mt9m111",
+   .power  = a780_camera_power,
+   .reset  = a780_camera_reset,
+};
+
+static struct platform_device a780_camera = {
+   .name   = "soc-camera-pdrv",
+   .id = 0,
+   .dev= {
+   .platform_data = &a780_iclink,
+   },
+};
+
 static struct platform_device *a780_devices[] __initdata = {
&a780_gpio_keys,
+   &a780_camera,
 };
 
 static void __init a780_init(void)
@@ -699,6 +782,9 @@ static void __init a780_init(void)
 
pxa_set_keypad_info(&a780_keypad_platform_data);
 
+   a780_camera_init();
+   pxa_set_camera_info(&a780_pxacamera_platform_data);
+
platform_add_devices(ARRAY_AND_SIZE(ezx_devices));
platform_add_devices(ARRAY_AND_SIZE(a780_devices));
 }
@@ -864,8 +950,83 @@ static struct platform_device a910_g

Re: ov538-ov7690

[Michael Trimarchi]

Mauro Carvalho Chehab wrote:

Em Tue, 10 Nov 2009 09:09:10 -0800
Randy Dunlap  escreveu:


(**) This is also one of several codes that different kinds of host
controller use to indicate a transfer has failed because of device
disconnect.  In the interval before the hub driver starts disconnect
processing, devices may receive such fault reports for every request.



Ok, this is not a big issue because I can use vlc to test the camera. But 
anybody
knows why camorama, camstream, cheese crash during test. is it driver depend? 
or not?

Could be driver.  Easily could be a device problem too.

I think that it can be a vl2 vl1 problem. Because now I can manage in skype too 
using
the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :(

I don't even know what vl2 vl1 means. ;)


He is probably referring to V4L1 x V4L2 API calls. Very unlikely. What libv4l


Yes


does is to convert userspace calls via V4L1 to a V4L2 call to kernel. So,
you're basically using the same API to communicate to userspace.


Ugly but very usefull in such application like skype, and people want it :(



It should be noticed that, if you're not using libv4l for the other
applications, then you may be using a different format at the driver, since
libv4l has the capability of doing format conversions.

So, it could be possible that the device firmware for some formats are broken.

Another possibility is that maybe libv4l is just discarding such errors.

Or, as Randy mentioned, it can be just a cable or a connector with bad contact.


Change the connector fix the packet problem. So at least the version 
ov538-ov7690
seems ok.

Thanks
--
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