"failed to open frontend"

[Mikhail Ramendik]

Hello,

I have a DVB-S card, don't remember the brand offhand but the saa7134
driver works for it. I also have Debian lenny, which, with kernel
2.6.30 from backports.org, displayed satelite video successfully.

However, once I installed kernel 2.6.32 from backports.org (which I
needed for certain network hardware), DVB no longer works, even though
the card is unchanged.

I have added saa7134_dvb to /etc/modules and it does load, and is
visible in lsmod. Still, dvbscan shows "failed to open frontend" (even
under root). And /dev/dvb does not exist. It does not even appear when
I boot 2.6.30 - so it seems that the configuration that came with the
2.6.32 package broke things.

How can I make /dev/dvb available again?

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization
--
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: Lost remote after kernel/v4l update cx23885 chipset

[Mark Zimmerman]

For the archives: Working again in 2.6.35


On Sun, Feb 14, 2010 at 02:50:41PM -0700, Mark Zimmerman wrote:
> Greetings:
> 
> I found this 
> in the archives and I am having the exact same problem. Everything
> worked in 2.6.31. Let me know if there is any testing I could do to
> help solve this.
> 
> -- Mark
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] saa7164: Remove pointless conditional and save a few bytes in saa7164_downloadfirmware().

[Jesper Juhl]

Hi,

release_firmware() just does nothing if passed a NULL pointer. So there's 
no reason to test before the call in 
saa7164-fw.c::saa7164_downloadfirmware().

Removing the pointless conditional also saves a few bytes.
before:
   textdata bss dec hex filename
   7943 1122144   1019927d7 drivers/media/video/saa7164/saa7164-fw.o
after:
   textdata bss dec hex filename
   7931 1122136   1017927c3 drivers/media/video/saa7164/saa7164-fw.o


Signed-off-by: Jesper Juhl 
---
 saa7164-fw.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

 compile tested only.

diff --git a/drivers/media/video/saa7164/saa7164-fw.c 
b/drivers/media/video/saa7164/saa7164-fw.c
index 484533c..af71367 100644
--- a/drivers/media/video/saa7164/saa7164-fw.c
+++ b/drivers/media/video/saa7164/saa7164-fw.c
@@ -608,8 +608,6 @@ int saa7164_downloadfirmware(struct saa7164_dev *dev)
ret = 0;
 
 out:
-   if (fw)
-   release_firmware(fw);
-
+   release_firmware(fw);
return ret;
 }



-- 
Jesper Juhl http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.

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

Power frequency detection.

[Theodore Kilgore]

Does anyone know whether, somewhere in the kernel, there exists a scheme 
for detecting whether the external power supply of the computer is using 
50hz or 60hz?

The reason I ask:

A certain camera is marketed with Windows software which requests the user 
to set up the option of 50hz or 60hz power during the setup.

Judging by what exists in videodev2.h, for example, it is evidently 
possible to set up this as a control setting in a Linux driver. I am not 
aware of any streaming app which knows how to access such an option.

Information about which streaming app ought to be used which could take 
advantage of a setting for line frequency would be welcome, too, of 
course. As I said, I do not know of a single one and would therefore have 
trouble with testing any such control setting unless I could find the 
software which can actually present the choice to the user.

But my main question is whether the kernel already does detect the line 
frequency anywhere else, for whatever reason. For, it occurs to me that a 
far more elegant solution -- if the camera really does need to have the 
line frequency detected -- would be do do the job automatically and not to 
bother the user about such a thing.

In other news, in case anyone has any children who are in love with Lego, 
the "Lego Bionicle" camera which is currently on sale has an SQ905C type 
chip in it. I just added its Product number to the Gphoto driver last 
night. And it works perfectly in webcam mode if one adds its product 
number in gspca/sq905c.c. I will get around to doing that formally, of 
course, when I get time. But if anyone wants just to add the number and 
re-compile the Vendor:Product number for the new camera is 0x2770:0x9051.

Merry Christmas.

Theodore Kilgore
--
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Hans Verkuil]

On Saturday, December 18, 2010 16:38:29 Muralidharan Karicheri wrote:
> Hans,
> 
> For davinci drivers, I will be able to do this for vpfe_capture driver
> (DM355/6446/365).

That one already uses unlocked_ioctl. You might want to consider auditing it
to see if converting it to core-assisted locking is better. It is much easier
to verify lock-correctness that way.

> For DM6467, will someone from your company be able
> to take care of this?

I'll see if I can do it and ask a colleague to test for me next week. Otherwise
I can do it in the first week of January.

Regards,

Hans

> 
> Murali
> 
> On Sat, Dec 18, 2010 at 6:31 AM, Hans Verkuil  wrote:
> > Hi all,
> >
> > Now that the BKL patch series has been merged in 2.6.37 it is time to work
> > on replacing .ioctl by .unlocked_ioctl in all v4l drivers.
> >
> > I've made an inventory of all drivers that still use .ioctl and I am looking
> > for volunteers to tackle one or more drivers.
> >
> > I have CCed this email to the maintainers of the various drivers (if I know
> > who it is) in the hope that we can get this conversion done as quickly as
> > possible.
> >
> > If I have added your name to a driver, then please confirm if you are able 
> > to
> > work on it or not. If you can't work on it, but you know someone else, then
> > let me know as well.
> >
> > There is also a list of drivers where I do not know who can do the 
> > conversion.
> > If you can tackle one or more of those, please respond. Unfortunately, those
> > are among the hardest to convert :-(
> >
> > It would be great if we can tackle most of these drivers for 2.6.38. I think
> > we should finish all drivers for 2.6.39 at the latest.
> >
> > There are two ways of doing the conversion: one is to do all the locking 
> > within
> > the driver, the other is to use core-assisted locking. How to do the 
> > core-assisted
> > locking is described in Documentation/video4linux/v4l2-framework.txt, but 
> > I'll
> > repeat the relevant part here:
> >
> > v4l2_file_operations and locking
> > 
> >
> > You can set a pointer to a mutex_lock in struct video_device. Usually this
> > will be either a top-level mutex or a mutex per device node. If you want
> > finer-grained locking then you have to set it to NULL and do you own 
> > locking.
> >
> > If a lock is specified then all file operations will be serialized on that
> > lock. If you use videobuf then you must pass the same lock to the videobuf
> > queue initialize function: if videobuf has to wait for a frame to arrive, 
> > then
> > it will temporarily unlock the lock and relock it afterwards. If your driver
> > also waits in the code, then you should do the same to allow other processes
> > to access the device node while the first process is waiting for something.
> >
> > The implementation of a hotplug disconnect should also take the lock before
> > calling v4l2_device_disconnect.
> >
> >
> > Driver list:
> >
> > saa7146 (Hans Verkuil)
> > mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> > cx23885 (Steve Toth)
> > cx18-alsa (Andy Walls)
> > omap24xxcam (Sakari Ailus or David Cohen)
> > au0828 (Janne Grunau)
> > cpia2 (Andy Walls or Hans Verkuil)
> > cx231xx (Mauro Carvalho Chehab)
> > davinci (Muralidharan Karicheri)
> > saa6588 (Hans Verkuil)
> > pvrusb2 (Mike Isely)
> > usbvision (Hans Verkuil)
> > s5p-fimc (Sylwester Nawrocki)
> > fsl-viu (Anatolij Gustschin)
> > tlg2300 (Mauro Carvalho Chehab)
> > zr364xx (Hans de Goede)
> > soc_camera (Guennadi Liakhovetski)
> > usbvideo/vicam (Hans de Goede)
> > s2255drv (Pete Eberlein)
> > bttv (Mauro Carvalho Chehab)
> > stk-webcam (Hans de Goede)
> > se401 (Hans de Goede)
> > si4713-i2c (Hans Verkuil)
> > dsbr100 (Hans Verkuil)
> >
> > Staging driver list:
> >
> > go7007 (Pete Eberlein)
> > tm6000 (Mauro Carvalho Chehab)
> > (stradis/cpia: will be removed in 2.6.38, so no need to do anything)
> >
> > Unassigned drivers:
> >
> > saa7134
> > em28xx
> > cx88
> > solo6x10 (staging driver)
> >
> > Regards,
> >
> >Hans
> >
> > --
> > Hans Verkuil - video4linux developer - sponsored by Cisco
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Guennadi Liakhovetski]

On Sat, 18 Dec 2010, Hans Verkuil wrote:

> Hi all,
> 
> Now that the BKL patch series has been merged in 2.6.37 it is time to work
> on replacing .ioctl by .unlocked_ioctl in all v4l drivers.
> 
> I've made an inventory of all drivers that still use .ioctl and I am looking
> for volunteers to tackle one or more drivers.
> 
> I have CCed this email to the maintainers of the various drivers (if I know
> who it is) in the hope that we can get this conversion done as quickly as
> possible.
> 
> If I have added your name to a driver, then please confirm if you are able to
> work on it or not. If you can't work on it, but you know someone else, then
> let me know as well.
> 
> There is also a list of drivers where I do not know who can do the conversion.
> If you can tackle one or more of those, please respond. Unfortunately, those
> are among the hardest to convert :-(
> 
> It would be great if we can tackle most of these drivers for 2.6.38. I think
> we should finish all drivers for 2.6.39 at the latest.
> 
> There are two ways of doing the conversion: one is to do all the locking 
> within
> the driver, the other is to use core-assisted locking. How to do the 
> core-assisted
> locking is described in Documentation/video4linux/v4l2-framework.txt, but I'll
> repeat the relevant part here:
> 
> v4l2_file_operations and locking
> 
> 
> You can set a pointer to a mutex_lock in struct video_device. Usually this
> will be either a top-level mutex or a mutex per device node. If you want
> finer-grained locking then you have to set it to NULL and do you own locking.
> 
> If a lock is specified then all file operations will be serialized on that
> lock. If you use videobuf then you must pass the same lock to the videobuf
> queue initialize function: if videobuf has to wait for a frame to arrive, then
> it will temporarily unlock the lock and relock it afterwards. If your driver
> also waits in the code, then you should do the same to allow other processes
> to access the device node while the first process is waiting for something.
> 
> The implementation of a hotplug disconnect should also take the lock before
> calling v4l2_device_disconnect.
> 
> 
> Driver list:
> 
> saa7146 (Hans Verkuil)
> mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> cx23885 (Steve Toth)
> cx18-alsa (Andy Walls)
> omap24xxcam (Sakari Ailus or David Cohen)
> au0828 (Janne Grunau)
> cpia2 (Andy Walls or Hans Verkuil)
> cx231xx (Mauro Carvalho Chehab)
> davinci (Muralidharan Karicheri)
> saa6588 (Hans Verkuil)
> pvrusb2 (Mike Isely)
> usbvision (Hans Verkuil)
> s5p-fimc (Sylwester Nawrocki)
> fsl-viu (Anatolij Gustschin)
> tlg2300 (Mauro Carvalho Chehab)
> zr364xx (Hans de Goede)
> soc_camera (Guennadi Liakhovetski)

Will have a look.

Thanks
Guennadi

> usbvideo/vicam (Hans de Goede)
> s2255drv (Pete Eberlein)
> bttv (Mauro Carvalho Chehab)
> stk-webcam (Hans de Goede)
> se401 (Hans de Goede)
> si4713-i2c (Hans Verkuil)
> dsbr100 (Hans Verkuil)
> 
> Staging driver list:
> 
> go7007 (Pete Eberlein)
> tm6000 (Mauro Carvalho Chehab)
> (stradis/cpia: will be removed in 2.6.38, so no need to do anything)
> 
> Unassigned drivers:
> 
> saa7134
> em28xx
> cx88
> solo6x10 (staging driver)
> 
> Regards,
> 
>   Hans
> 
> -- 
> Hans Verkuil - video4linux developer - sponsored by Cisco
> 

---
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Hans Verkuil]

On Saturday, December 18, 2010 19:34:00 Mike Isely wrote:
> 
> I'll take care of the pvrusb2 driver.  How soon does this need to be 
> completed?

It would be great if we can finish this in time for 2.6.38. So that's in the
next three weeks.

I have to say that switching drivers to use the core-assisted lock tends to be
pretty easy. So I am hopeful that it is less work than it looks at first sight.

Regards,

hans

> 
>   -Mike
> 
> 
> On Sat, 18 Dec 2010, Hans Verkuil wrote:
> 
> > On Saturday, December 18, 2010 12:31:26 Hans Verkuil wrote:
> > > Driver list:
> > > 
> > > saa7146 (Hans Verkuil)
> > > mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> > > cx23885 (Steve Toth)
> > > cx18-alsa (Andy Walls)
> > > omap24xxcam (Sakari Ailus or David Cohen)
> > > au0828 (Janne Grunau)
> > > cpia2 (Andy Walls or Hans Verkuil)
> > > cx231xx (Mauro Carvalho Chehab)
> > > davinci (Muralidharan Karicheri)
> > > saa6588 (Hans Verkuil)
> > > pvrusb2 (Mike Isely)
> > > usbvision (Hans Verkuil)
> > > s5p-fimc (Sylwester Nawrocki)
> > > fsl-viu (Anatolij Gustschin)
> > > tlg2300 (Mauro Carvalho Chehab)
> > > zr364xx (Hans de Goede)
> > > soc_camera (Guennadi Liakhovetski)
> > > usbvideo/vicam (Hans de Goede)
> > > s2255drv (Pete Eberlein)
> > > bttv (Mauro Carvalho Chehab)
> > > stk-webcam (Hans de Goede)
> > > se401 (Hans de Goede)
> > > si4713-i2c (Hans Verkuil)
> > > dsbr100 (Hans Verkuil)
> > 
> > Oops, si4713-i2c and saa6588 are subdevs, so those two can be removed from
> > this list.
> > 
> > Regards,
> > 
> > Hans
> > 
> > 
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Mike Isely]

I'll take care of the pvrusb2 driver.  How soon does this need to be 
completed?

  -Mike


On Sat, 18 Dec 2010, Hans Verkuil wrote:

> On Saturday, December 18, 2010 12:31:26 Hans Verkuil wrote:
> > Driver list:
> > 
> > saa7146 (Hans Verkuil)
> > mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> > cx23885 (Steve Toth)
> > cx18-alsa (Andy Walls)
> > omap24xxcam (Sakari Ailus or David Cohen)
> > au0828 (Janne Grunau)
> > cpia2 (Andy Walls or Hans Verkuil)
> > cx231xx (Mauro Carvalho Chehab)
> > davinci (Muralidharan Karicheri)
> > saa6588 (Hans Verkuil)
> > pvrusb2 (Mike Isely)
> > usbvision (Hans Verkuil)
> > s5p-fimc (Sylwester Nawrocki)
> > fsl-viu (Anatolij Gustschin)
> > tlg2300 (Mauro Carvalho Chehab)
> > zr364xx (Hans de Goede)
> > soc_camera (Guennadi Liakhovetski)
> > usbvideo/vicam (Hans de Goede)
> > s2255drv (Pete Eberlein)
> > bttv (Mauro Carvalho Chehab)
> > stk-webcam (Hans de Goede)
> > se401 (Hans de Goede)
> > si4713-i2c (Hans Verkuil)
> > dsbr100 (Hans Verkuil)
> 
> Oops, si4713-i2c and saa6588 are subdevs, so those two can be removed from
> this list.
> 
> Regards,
> 
>   Hans
> 
> 

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: WARNINGS

[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:Sat Dec 18 19:00:26 CET 2010
git master:   59365d136d205cc20fe666ca7f89b1c5001b0d5a
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

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

Re: [PATCH 2/3] mx3_camera: Support correctly the YUV222 and BAYER configurations of CSI

[Guennadi Liakhovetski]

Alberto

it would be slowly on the time to address my comments and submit updates. 
While at it, also, please update the subject - you probably meant "YUV422" 
or "YUV444" there, also below:

On Wed, 1 Dec 2010, Guennadi Liakhovetski wrote:

> On Sun, 28 Nov 2010, Alberto Panizzo wrote:
> 
> > This patch is tested and works with the OV2640 camera that output
> > YUV422 (UYVY) and RGB565 data.
> > 
> > The YUV422 format is managed to be converted in IPU internal YUV444 format
> > so this stream could be used in the future to feed directly other IPU
> > blocks.
> > The RGB565 format is managed as GENERIC and can be moved only from CSI
> > to memory.
> > 
> > Signed-off-by: Alberto Panizzo 
> > ---
> > 
> > Before applying, please give me feedback if this break in some way other
> > pixel formats!
> > 
> > 
> >  drivers/media/video/mx3_camera.c |  126 
> > +-
> >  1 files changed, 110 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/media/video/mx3_camera.c 
> > b/drivers/media/video/mx3_camera.c
> > index 29c5fc3..6811d6f 100644
> > --- a/drivers/media/video/mx3_camera.c
> > +++ b/drivers/media/video/mx3_camera.c
> > @@ -55,6 +55,31 @@
> >  #define CSI_SENS_CONF_EXT_VSYNC_SHIFT  15
> >  #define CSI_SENS_CONF_DIVRATIO_SHIFT   16
> >  
> > +/*
> > + * IPU support the following data formatting (44.1.1.3 Data Flows and 
> > Formats):
> > + * 1 YUV 4:4:4 or RGB—8 bits per color component
> > + * 2 YUV 4:4:4 or RGB—10 bits per color component

don't know what characters are those. Please, replace with ASCII.

Thanks
Guennadi

> > + * 3 Generic data (from sensor to the system memory only)
> > + * The formats 1 and 2 are aligned in words of 32 bits, 3 is free and not
> > + * recognized by IPU blocks.
> > + *
> > + * Taking the value of SENS_DATA_FORMAT and DATA_WIDTH, the CSI tries to
> > + * align (or rearrange) the sampled data to fit the IPU supported formats
> > + * as follows:
> > + * - CSI_SENS_CONF_DATA_FMT_RGB_YUV444: It consider the pixel as a 
> > sequence of
> > + * 3 components of width DATA_WIDTH aligning these to a 32 bit word.
> > + * The CSI output in this case can feed other IPU blocks.
> > + * - CSI_SENS_CONF_DATA_FMT_YUV422: It consider the pixel as a sequence of
> > + * 2 components of width DATA_WIDTH were the first is the alternating U V
> 
> s/were/where/
> 
> > + * components and the second is Y. It construct the YUV444 word repeating
> > + * the previous U, V samples aligning the results to a 32 bit word.
> > + * The CSI output in this case can feed other IPU blocks.
> > + * - CSI_SENS_CONF_DATA_FMT_BAYER: No rework is performed in this case.
> > + * The sensor data is given as is, considering _every sample_ as a pixel
> > + * data. This format (combined with the GENERIC IPU pixel formats) can
> > + * carry all the other sensor pixel formats to the system memory.
> > + * The CSI output in this case _can not_ feed other IPU blocks.
> > + */
> >  #define CSI_SENS_CONF_DATA_FMT_RGB_YUV444  (0UL << 
> > CSI_SENS_CONF_DATA_FMT_SHIFT)
> >  #define CSI_SENS_CONF_DATA_FMT_YUV422  (2UL << 
> > CSI_SENS_CONF_DATA_FMT_SHIFT)
> >  #define CSI_SENS_CONF_DATA_FMT_BAYER   (3UL << 
> > CSI_SENS_CONF_DATA_FMT_SHIFT)
> > @@ -323,14 +348,12 @@ static enum pixel_fmt fourcc_to_ipu_pix(__u32 fourcc)
> >  {
> > /* Add more formats as need arises and test possibilities appear... */
> > switch (fourcc) {
> > -   case V4L2_PIX_FMT_RGB565:
> > -   return IPU_PIX_FMT_RGB565;
> > case V4L2_PIX_FMT_RGB24:
> > return IPU_PIX_FMT_RGB24;
> > +   case V4L2_PIX_FMT_UYVY:
> > +   return IPU_PIX_FMT_UYVY;
> > +   case V4L2_PIX_FMT_RGB565:
> > case V4L2_PIX_FMT_RGB332:
> > -   return IPU_PIX_FMT_RGB332;
> > -   case V4L2_PIX_FMT_YUV422P:
> > -   return IPU_PIX_FMT_YVU422P;
> > default:
> > return IPU_PIX_FMT_GENERIC;
> > }
> 
> Ok, so far mx3_camera has only been used with mt9m022 and mt9t031 sensors 
> (from what I can see in the mainline), both are bayer. It can also work 
> with monochrome cameras, and that would be the IPU_PIX_FMT_GENERIC case 
> too. So, I wouldn't mind removing the rest, and only adding / fixing what 
> you've now tested / implemented with your omnivision sensor. If anyone is 
> using mx3_camera with any other formats and thinks, that they work - 
> please, shout now. I'll probably also post a separate mail with this 
> warning.
> 
> > @@ -358,9 +381,25 @@ static void mx3_videobuf_queue(struct videobuf_queue 
> > *vq,
> >  
> > /* This is the configuration of one sg-element */
> > video->out_pixel_fmt= fourcc_to_ipu_pix(fourcc);
> > -   video->out_width= icd->user_width;
> > -   video->out_height   = icd->user_height;
> > -   video->out_stride   = icd->user_width;
> > +
> > +   if (video->out_pixel_fmt == IPU_PIX_FMT_GENERIC) {
> > +   /*
> > +* IPU_PIX_FMT_GENERIC transport bytes, not 

Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera

[Sylwester Nawrocki]

On 12/17/2010 05:35 PM, Sylwester Nawrocki wrote:


Hi HeungJun,

On 12/17/2010 07:42 AM, Kim, HeungJun wrote:

Hi Sylwester,

Thanks for some comments. I'll reflects this comments for the next version
patch. It's clear that there is a few things I missed. It's better to let's
talk about this rest things, as Mr. Park said.

But, I wanna remind one thing, and know your exact thiking. about MACROs.

I re-comments of that. look around and re-re-comments it, plz.


+
+/* MACRO */
+#define e_check_w(fn, cat, byte, val, bitwidth)do {\
+int ret;\
+ret = (int)(fn);\
+if ((ret)<   0) {\
+dev_err(&client->dev, "fail i2c WRITE [%s] - "\
+"category:0x%02x, "\
+"bytes:0x%02x, "\
+"value:0x%02x\n",\
+(bitwidth),\
+(cat), (byte), (u32)val);\
+return ret;\
+}\
+} while (0)
+
+#define e_check_r(fn, cat, byte, val, bitwidth)do {\
+int ret;\
+ret = (int)(fn);\
+if ((ret)<   0) {\
+dev_err(&client->dev, "fail i2c READ [%s] - "\
+"category:0x%02x, "\
+"bytes:0x%02x, "\
+"value:0x%02x\n",\
+(bitwidth),\
+(cat), (byte), (u32)(*val));\
+return ret;\
+}\
+} while (0)
+
+#define REG_W_8(cat, byte, value)\
+e_check_w(m5mols_write_reg(sd, M5MOLS_8BIT, cat, byte, value),\
+cat, byte, value, "8bit")
+#define REG_R_8(cat, byte, value)\
+e_check_r(m5mols_read_reg(sd, M5MOLS_8BIT, cat, byte, value),\
+cat, byte, value, "8bit")
+
+#define e_check_mode(fn, mode)do {\
+int ret;\
+ret = (int)(fn);\
+if (ret<   0) {\
+dev_err(&client->dev, "Failed to %s mode\n",\
+(mode));\
+return ret;\
+}\
+} while (0)


These macros really do not look good. Moreover they all change
the control flow, i.e. return a value. From Documentation/CodingStyle:

"Things to avoid when using macros:

1) macros that affect control flow:

#define FOO(x)  \
 do {\
 if (blah(x)<  0)\
 return -EBUGGERED;  \
 } while(0)

is a _very_ bad idea.  It looks like a function call but exits the
"calling" function; don't break the internal parsers of those who will
read the code."


I know about Documentation/CodingStyle and absolutely know about
the risks of MACRO like upper case. I even know the _very_'s meanings.
But, I think this case is different any other MACRO cases to be concrete
whether use or not. Actually, I've not even found address symbol using T32
debuggers cause of MACROs. I have realized danger before long time.

I know Documentation/CodingStyle is very strong recommandation.
And must keep this style but, it seems to happen the specific case.
The specific means, not general and only used in the M5MOLS code.
The following is my thinking at past.

1. There are a lot of I2C communication is in M5MOLS driver code.
The M5MOLS has 16 category, and about 50 commands in the each category.
If each command need 1 line on the code, the amount to be charged I2C
communication only is 800 lines. What if each command be plused 3~4
error checking code? The code amount is 3200 lines at least. Moreover,
No guarantiee 1 command only 1 time excuetion. So, 3200 more lines
would be added at the future. (The m5mo driver you've seen and used before,
is not yet inserted all controls.)


Then this sensor needs careful design and function partitioning.
Single *.c file should not exceed 1000 lines.
I think we need a separate directory for it, like media/drivers/m5mols/.


ouch, that was supposed to be drivers/media/video/m5mols

--
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] drivers:media:dvb: add USB PIDs for Elgato EyeTV Sat

[sam]

Adds USB PIDs for the Elgato EyeTV Sat device. 
This device is a clone of the Terratec S7.

Signed-off-by: Sam Doshi 

diff -r abd3aac6644e linux/drivers/media/dvb/dvb-usb/az6027.c
--- a/linux/drivers/media/dvb/dvb-usb/az6027.c  Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/az6027.c  Sat Dec 18 15:38:23 2010 +
@@ -1089,6 +1089,7 @@
{ USB_DEVICE(USB_VID_TERRATEC,  USB_PID_TERRATEC_DVBS2CI_V2) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
+   { USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
{ },
};

@@ -1131,7 +1132,7 @@
.rc_query = az6027_rc_query,
.i2c_algo = &az6027_i2c_algo,

-   .num_device_descs = 5,
+   .num_device_descs = 6,
.devices = {
{
.name = "AZUREWAVE DVB-S/S2 USB2.0 (AZ6027)",
@@ -1153,6 +1154,10 @@
.name = "Technisat SkyStar USB 2 HD CI",
.cold_ids = { &az6027_usb_table[4], NULL },
.warm_ids = { NULL },
+   }, {
+   .name = "Elgato EyeTV Sat",
+   .cold_ids = { &az6027_usb_table[5], NULL },
+   .warm_ids = { NULL },
},
{ NULL },
}
diff -r abd3aac6644e linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Fri Jul 02 00:38:54 
2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Dec 18 15:38:23 
2010 +
@@ -294,6 +294,7 @@
#define USB_PID_ELGATO_EYETV_DIVERSITY  0x0011
#define USB_PID_ELGATO_EYETV_DTT0x0021
#define USB_PID_ELGATO_EYETV_DTT_Dlx0x0020
+#define USB_PID_ELGATO_EYETV_SAT   0x002a
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD 0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM 0x5001
#define USB_PID_FRIIO_WHITE 0x0001
--
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: tm6000 and IR

[Stefan Ringel]

Am 18.12.2010 14:56, schrieb Andy Walls:

On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote:



Despite all discussions, we didn't reach an agreement yet.

There are some points to consider whatever solution we do:

1) A keycode table should be able to work with a generic raw decoder. So, on all
drivers, the bit order and the number of bits for a given protocol should be 
the same;

2) we should avoid to cause regressions on the existing definitions.

That's said, suggestions to meet the needs are welcome.

Just to throw out some ideas:

It appears to me that what you are looking at are communications
protocols with

a. a common Physical layer (PHY): a pulse distance protocol with a
common carrier freq, bit symbol encoding, leader pulse, trailer pulse,
and repeat sequence.  The number of bits (and the leader pulse length?)
is allowed to vary.

b. differing Data Link layers (LL): the data link address can be
different lengths and in different places; so can the data payload, so
can the checks on address and data payload.

For the end user, I would present each PHY/LL combination a different
protocol.  How the kernel implements it internally doesn't matter much.
It could be one raw decoder handling all the PHY/LL combinations that it
can, or one PHY decoder and several LL decoders.

The keytables should probably be working on cooked LL output from the
raw decoder.  I think that will handle a lot of the issues you mention.
The output from a LL could include

destination address (from the transmitted code),
source address (useful if different remotes can be detected),
payload length,
payload, and
maybe button up/down.

The LL could swallow the automatic repeats, since they are just part of
the button up/down scheme.

Aside from backward compatibility with existing keytables, I don't see
much point in a decoder trying to flip bits from the PHY layer around to
present a pseudo-PHY layer output.  Don't keytables get updated with the
kernel release anyway, or did they all move to userspace utils?


Anyway, just some thoughts.

Regards,
Andy



Thanks,
Mauro



TM5600, TM6000 and TM6010 IR
==

It give two ways to receive data

1. over the control pipe (ep0)
- polling must stop if it loads firmware
- data length are a byte (command)

2. over interrupt pipe (only TM6010)
- data length are two bytes (address << 8 | command)

It has any control registers to configure IR (protocol ...)

TM6010_REQ07_RD8_IR
??, we use 0x2f

TM6010_REQ07_RD8_IR_BSIZE
??

TM6010_REQ07_RD8_IR_WAKEUP_SEL
command mask, I think,   we use here 0xff

TM6010_REQ07_RD8_IR_WAKEUP_ADD
address mask, we use 0xff

TM6010_REQ07_RD8_IR_LEADER1
TM6010_REQ07_RD8_IR_LEADER0
is a 16bit register
for NEC 0xaa30

TM6010_REQ07_RD8_IR_PULSE_CNT1
TM6010_REQ07_RD8_IR_PULSE_CNT0
is a 16bit register
for NEC 0x20d0


Stefan Ringel
--
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Sylwester Nawrocki]

Hi Hans,

On 12/18/2010 12:31 PM, Hans Verkuil wrote:

Hi all,

Now that the BKL patch series has been merged in 2.6.37 it is time to work
on replacing .ioctl by .unlocked_ioctl in all v4l drivers.

I've made an inventory of all drivers that still use .ioctl and I am looking
for volunteers to tackle one or more drivers.

I have CCed this email to the maintainers of the various drivers (if I know
who it is) in the hope that we can get this conversion done as quickly as
possible.

If I have added your name to a driver, then please confirm if you are able to
work on it or not. If you can't work on it, but you know someone else, then
let me know as well.

There is also a list of drivers where I do not know who can do the conversion.
If you can tackle one or more of those, please respond. Unfortunately, those
are among the hardest to convert :-(

It would be great if we can tackle most of these drivers for 2.6.38. I think
we should finish all drivers for 2.6.39 at the latest.

There are two ways of doing the conversion: one is to do all the locking within
the driver, the other is to use core-assisted locking. How to do the 
core-assisted
locking is described in Documentation/video4linux/v4l2-framework.txt, but I'll
repeat the relevant part here:

v4l2_file_operations and locking


You can set a pointer to a mutex_lock in struct video_device. Usually this
will be either a top-level mutex or a mutex per device node. If you want
finer-grained locking then you have to set it to NULL and do you own locking.

If a lock is specified then all file operations will be serialized on that
lock. If you use videobuf then you must pass the same lock to the videobuf
queue initialize function: if videobuf has to wait for a frame to arrive, then
it will temporarily unlock the lock and relock it afterwards. If your driver
also waits in the code, then you should do the same to allow other processes
to access the device node while the first process is waiting for something.

The implementation of a hotplug disconnect should also take the lock before
calling v4l2_device_disconnect.


Driver list:

saa7146 (Hans Verkuil)
mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
cx23885 (Steve Toth)
cx18-alsa (Andy Walls)
omap24xxcam (Sakari Ailus or David Cohen)
au0828 (Janne Grunau)
cpia2 (Andy Walls or Hans Verkuil)
cx231xx (Mauro Carvalho Chehab)
davinci (Muralidharan Karicheri)
saa6588 (Hans Verkuil)
pvrusb2 (Mike Isely)
usbvision (Hans Verkuil)
s5p-fimc (Sylwester Nawrocki)


I've done a conversion of s5p-fimc already. The relevant patch
is included in my last pull request of the driver bugfix changeset
for 2.6.37.

I am not sure what are Mauro's plans about this changeset, I hope it is 
not too late to have it in 2.6.37. If it is, then it would be good to 
pick up at least the commit

7db545a [media] s5p-fimc: BKL lock removal - compilation fix
because without it the driver is not even compiling. The above commit
fixes some integration problem, i.e. I submitted the camera capture
support patches and in parallel there were changes in the v4l core.

Then I have also prepared further patch converting from driver's own
to the core assisted locking, but it's on my queue for 2.6.38.
That was submitted together with the videobuf 2 patches

http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/vb2-mfc-fimc


fsl-viu (Anatolij Gustschin)
tlg2300 (Mauro Carvalho Chehab)
zr364xx (Hans de Goede)
soc_camera (Guennadi Liakhovetski)
usbvideo/vicam (Hans de Goede)
s2255drv (Pete Eberlein)
bttv (Mauro Carvalho Chehab)
stk-webcam (Hans de Goede)
se401 (Hans de Goede)
si4713-i2c (Hans Verkuil)
dsbr100 (Hans Verkuil)

Staging driver list:

go7007 (Pete Eberlein)
tm6000 (Mauro Carvalho Chehab)
(stradis/cpia: will be removed in 2.6.38, so no need to do anything)

Unassigned drivers:

saa7134


I could try converting saa7134 in my spare time, but it is rather
a huge driver and I have no experience with it.
If there is really nobody more familiar to take care of it I would
try it.

I have avermedia E506 TV card on hand, would it be enough for basic testing?

snawro...@thinkpad:~/linux/v4l-dvb$ sudo lspci -vv
16:00.0 Multimedia controller: Philips Semiconductors 
SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)

Subsystem: Avermedia Technologies Inc Device f436
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 64
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 4400 (32-bit, non-prefetchable) [size=2K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: saa7134
Kernel modules: saa7134


em28xx
cx88
solo6x10 (staging driver)

Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Muralidharan Karicheri]

Hans,

For davinci drivers, I will be able to do this for vpfe_capture driver
(DM355/6446/365). For DM6467, will someone from your company be able
to take care of this?

Murali

On Sat, Dec 18, 2010 at 6:31 AM, Hans Verkuil  wrote:
> Hi all,
>
> Now that the BKL patch series has been merged in 2.6.37 it is time to work
> on replacing .ioctl by .unlocked_ioctl in all v4l drivers.
>
> I've made an inventory of all drivers that still use .ioctl and I am looking
> for volunteers to tackle one or more drivers.
>
> I have CCed this email to the maintainers of the various drivers (if I know
> who it is) in the hope that we can get this conversion done as quickly as
> possible.
>
> If I have added your name to a driver, then please confirm if you are able to
> work on it or not. If you can't work on it, but you know someone else, then
> let me know as well.
>
> There is also a list of drivers where I do not know who can do the conversion.
> If you can tackle one or more of those, please respond. Unfortunately, those
> are among the hardest to convert :-(
>
> It would be great if we can tackle most of these drivers for 2.6.38. I think
> we should finish all drivers for 2.6.39 at the latest.
>
> There are two ways of doing the conversion: one is to do all the locking 
> within
> the driver, the other is to use core-assisted locking. How to do the 
> core-assisted
> locking is described in Documentation/video4linux/v4l2-framework.txt, but I'll
> repeat the relevant part here:
>
> v4l2_file_operations and locking
> 
>
> You can set a pointer to a mutex_lock in struct video_device. Usually this
> will be either a top-level mutex or a mutex per device node. If you want
> finer-grained locking then you have to set it to NULL and do you own locking.
>
> If a lock is specified then all file operations will be serialized on that
> lock. If you use videobuf then you must pass the same lock to the videobuf
> queue initialize function: if videobuf has to wait for a frame to arrive, then
> it will temporarily unlock the lock and relock it afterwards. If your driver
> also waits in the code, then you should do the same to allow other processes
> to access the device node while the first process is waiting for something.
>
> The implementation of a hotplug disconnect should also take the lock before
> calling v4l2_device_disconnect.
>
>
> Driver list:
>
> saa7146 (Hans Verkuil)
> mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> cx23885 (Steve Toth)
> cx18-alsa (Andy Walls)
> omap24xxcam (Sakari Ailus or David Cohen)
> au0828 (Janne Grunau)
> cpia2 (Andy Walls or Hans Verkuil)
> cx231xx (Mauro Carvalho Chehab)
> davinci (Muralidharan Karicheri)
> saa6588 (Hans Verkuil)
> pvrusb2 (Mike Isely)
> usbvision (Hans Verkuil)
> s5p-fimc (Sylwester Nawrocki)
> fsl-viu (Anatolij Gustschin)
> tlg2300 (Mauro Carvalho Chehab)
> zr364xx (Hans de Goede)
> soc_camera (Guennadi Liakhovetski)
> usbvideo/vicam (Hans de Goede)
> s2255drv (Pete Eberlein)
> bttv (Mauro Carvalho Chehab)
> stk-webcam (Hans de Goede)
> se401 (Hans de Goede)
> si4713-i2c (Hans Verkuil)
> dsbr100 (Hans Verkuil)
>
> Staging driver list:
>
> go7007 (Pete Eberlein)
> tm6000 (Mauro Carvalho Chehab)
> (stradis/cpia: will be removed in 2.6.38, so no need to do anything)
>
> Unassigned drivers:
>
> saa7134
> em28xx
> cx88
> solo6x10 (staging driver)
>
> Regards,
>
>        Hans
>
> --
> Hans Verkuil - video4linux developer - sponsored by Cisco
> --
> 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
>



-- 
Murali Karicheri
mkarich...@gmail.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: TeVii S470 dvb-s2 issues - 2nd try ,)

[Andy Walls]

On Sat, 2010-12-18 at 14:40 +0100, Boris Cuber wrote:
> Am Friday 17 December 2010 schrieben Sie:
> > On Fri, 2010-12-17 at 12:19 +0100, Boris Cuber wrote:
> > > Hello linux-media people!
> > > 
> > > I have to problems with my dvb card ("TeVii S470"). I already
> > > filed 2 bug reports some time ago, but no one seems to have
> > > noticed/read them, so i'm trying it here now.
> > > If you need a "full" dmesg, then please take a look at
> > > https://bugzilla.kernel.org/attachment.cgi?id=40552
> > > 
> > > 1) "TeVii S470 dvbs-2 card (cx23885) is not usable after
> > > pm-suspend/resume" https://bugzilla.kernel.org/show_bug.cgi?id=16467
> > 
> > The cx23885 driver does not implement power management.  It would likely
> > take many, many hours of coding and testing to implement it properly.
> > 
> > If you need resume/suspend, use the power management scripts on your
> > machine to kill all the applications using the TeVii S470, and then
> > unload the cx23885 module just before suspend.
> > 
> > On resume, have the power management scripts reload the cx23885 module.
> >
> Well, this doesn't work. If i did tune a channel before or used the dvb card
> somehow for watching tv, unloading and reloading the cx23885
> module also makes the card unuseable.
> In dmesg there's lots of "do_IRQ: 1.161 No irq handler for vector (irq -1)"
> messages then. This can only be fixed by rebooting the computer.

That is s a known issue with the CX2388[578] chip and PCIe MSI.

The CX2388[578] will not accept a different value for its "MSI Data"
field in its PCI config space, when MSI has been enabled on the hardware
once.

The kernel will always try to give a different value for the "MSI Data"
field to the CX2388[578] chip, on cx23885 module unload and reload.

So suspend and then resume didn't reset the chip hardware?

You can set "pci=nomsi" on your kernel command line to prevent the
cx23885 driver, and your whole system unfortunately, from using MSI.
 
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Steven Toth]

Good work, thanks Hans.

> I've made an inventory of all drivers that still use .ioctl and I am looking
> for volunteers to tackle one or more drivers.

> cx23885 (Steve Toth)
> cx88

I'll take care of these and also the saa7164 driver.

- Steve

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

Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Andy Walls]

On Sat, 2010-12-18 at 12:31 +0100, Hans Verkuil wrote:
> Hi all,
> 
> Now that the BKL patch series has been merged in 2.6.37 it is time to work
> on replacing .ioctl by .unlocked_ioctl in all v4l drivers.
> 
> I've made an inventory of all drivers that still use .ioctl and I am looking
> for volunteers to tackle one or more drivers.

> If I have added your name to a driver, then please confirm if you are able to
> work on it or not. If you can't work on it, but you know someone else, then
> let me know as well.

> There is also a list of drivers where I do not know who can do the conversion.
> If you can tackle one or more of those, please respond. Unfortunately, those
> are among the hardest to convert :-(


> Driver list:
> 
> saa7146 (Hans Verkuil)
> mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> cx23885 (Steve Toth)
> cx18-alsa (Andy Walls)

Ack.  This thing has locking problems between ALSA and /dev/video24
anyway.

> omap24xxcam (Sakari Ailus or David Cohen)
> au0828 (Janne Grunau)
> cpia2 (Andy Walls or Hans Verkuil)

Ack.  But -ENOHARWARE; I only have a cpia1 based device on hand.

The driver is small enough:

$ wc -l *.[ch]
  2534 cpia2_core.c
50 cpia2dev.h
   494 cpia2.h
   476 cpia2_registers.h
   914 cpia2_usb.c
  1776 cpia2_v4l.c
  6244 total

and has a pretty clean coding style, so conversion shouldn't be hard.
It would be nice to have a tester.

> cx231xx (Mauro Carvalho Chehab)
> davinci (Muralidharan Karicheri)
> saa6588 (Hans Verkuil)
> pvrusb2 (Mike Isely)
> usbvision (Hans Verkuil)
> s5p-fimc (Sylwester Nawrocki)
> fsl-viu (Anatolij Gustschin)
> tlg2300 (Mauro Carvalho Chehab)
> zr364xx (Hans de Goede)
> soc_camera (Guennadi Liakhovetski)
> usbvideo/vicam (Hans de Goede)
> s2255drv (Pete Eberlein)
> bttv (Mauro Carvalho Chehab)
> stk-webcam (Hans de Goede)
> se401 (Hans de Goede)
> si4713-i2c (Hans Verkuil)
> dsbr100 (Hans Verkuil)
> 
> Staging driver list:
> 
> go7007 (Pete Eberlein)
> tm6000 (Mauro Carvalho Chehab)
> (stradis/cpia: will be removed in 2.6.38, so no need to do anything)
> 
> Unassigned drivers:
> 
> saa7134
> em28xx
> cx88
> solo6x10 (staging driver)
> 
> Regards,
> 
>   Hans
> 


--
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: tm6000 and IR

[Andy Walls]

On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote:


> Despite all discussions, we didn't reach an agreement yet.
> 
> There are some points to consider whatever solution we do:
> 
> 1) A keycode table should be able to work with a generic raw decoder. So, on 
> all
> drivers, the bit order and the number of bits for a given protocol should be 
> the same;
> 
> 2) we should avoid to cause regressions on the existing definitions.
> 
> That's said, suggestions to meet the needs are welcome.

Just to throw out some ideas:

It appears to me that what you are looking at are communications
protocols with

a. a common Physical layer (PHY): a pulse distance protocol with a
common carrier freq, bit symbol encoding, leader pulse, trailer pulse,
and repeat sequence.  The number of bits (and the leader pulse length?)
is allowed to vary.  

b. differing Data Link layers (LL): the data link address can be
different lengths and in different places; so can the data payload, so
can the checks on address and data payload.

For the end user, I would present each PHY/LL combination a different
protocol.  How the kernel implements it internally doesn't matter much.
It could be one raw decoder handling all the PHY/LL combinations that it
can, or one PHY decoder and several LL decoders.

The keytables should probably be working on cooked LL output from the
raw decoder.  I think that will handle a lot of the issues you mention.
The output from a LL could include

destination address (from the transmitted code),
source address (useful if different remotes can be detected),
payload length,
payload, and
maybe button up/down.

The LL could swallow the automatic repeats, since they are just part of
the button up/down scheme.

Aside from backward compatibility with existing keytables, I don't see
much point in a decoder trying to flip bits from the PHY layer around to
present a pseudo-PHY layer output.  Don't keytables get updated with the
kernel release anyway, or did they all move to userspace utils?


Anyway, just some thoughts.

Regards,
Andy


> Thanks,
> Mauro


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

Re: TeVii S470 dvb-s2 issues - 2nd try ,)

[Boris Cuber]

Am Friday 17 December 2010 schrieben Sie:
> On Fri, 2010-12-17 at 12:19 +0100, Boris Cuber wrote:
> > Hello linux-media people!
> > 
> > I have to problems with my dvb card ("TeVii S470"). I already
> > filed 2 bug reports some time ago, but no one seems to have
> > noticed/read them, so i'm trying it here now.
> > If you need a "full" dmesg, then please take a look at
> > https://bugzilla.kernel.org/attachment.cgi?id=40552
> > 
> > 1) "TeVii S470 dvbs-2 card (cx23885) is not usable after
> > pm-suspend/resume" https://bugzilla.kernel.org/show_bug.cgi?id=16467
> 
> The cx23885 driver does not implement power management.  It would likely
> take many, many hours of coding and testing to implement it properly.
> 
> If you need resume/suspend, use the power management scripts on your
> machine to kill all the applications using the TeVii S470, and then
> unload the cx23885 module just before suspend.
> 
> On resume, have the power management scripts reload the cx23885 module.
>
Well, this doesn't work. If i did tune a channel before or used the dvb card
somehow for watching tv, unloading and reloading the cx23885
module also makes the card unuseable.
In dmesg there's lots of "do_IRQ: 1.161 No irq handler for vector (irq -1)"
messages then. This can only be fixed by rebooting the computer.

[/dmesg]
Dec 18 14:33:09 localhost kernel: [  943.911488] cx23885 driver version 0.0.2 
loaded
Dec 18 14:33:09 localhost kernel: [  943.911525] cx23885 :04:00.0: PCI INT 
A -> GSI 16 (level, low) -> IRQ 16   
Dec 18 14:33:09 localhost kernel: [  943.911949] CORE cx23885[0]: subsystem: 
d470:9022, board: TeVii S470 [card=15,autodetected]
Dec 18 14:33:09 localhost kernel: [  944.039513] cx23885_dvb_register() 
allocating 1 frontend(s)

Dec 18 14:33:09 localhost kernel: [  944.039515] cx23885[0]: cx23885 based dvb 
card 
Dec 18 14:33:09 localhost kernel: [  944.041022] DS3000 chip version: 0.192 
attached.   
Dec 18 14:33:09 localhost kernel: [  944.041025] DVB: registering new adapter 
(cx23885[0])  
Dec 18 14:33:09 localhost kernel: [  944.041027] DVB: registering adapter 0 
frontend 0 (Montage Technology DS3000/TS2020)...
Dec 18 14:33:09 localhost kernel: [  944.069473] TeVii S470 MAC= 
00:18:bd:5b:2d:bc   
   
Dec 18 14:33:09 localhost kernel: [  944.069479] cx23885_dev_checkrevision() 
Hardware revision = 0xb0   
Dec 18 14:33:09 localhost kernel: [  944.069487] cx23885[0]/0: found at 
:04:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xfea0 

Dec 18 14:33:09 localhost kernel: [  944.069496] cx23885 :04:00.0: setting 
latency timer to 64  
Dec 18 14:33:09 localhost kernel: [  944.069572] cx23885 :04:00.0: irq 42 
for MSI/MSI-X  
Dec 18 14:33:09 localhost kernel: [  944.069496] cx23885 :04:00.0: setting 
latency timer to 64  
Dec 18 14:33:09 localhost kernel: [  944.069572] cx23885 :04:00.0: irq 42 
for MSI/MSI-X 
Dec 18 14:33:14 localhost kernel: [  948.624193] do_IRQ: 1.161 No irq handler 
for vector (irq -1)   
Dec 18 14:33:15 localhost kernel: [  949.604243] do_IRQ: 1.161 No irq handler 
for vector (irq -1)   
Dec 18 14:33:16 localhost kernel: [  950.606246] do_IRQ: 2.161 No irq handler 
for vector (irq -1)   
...
[/dmesg]


> > 2) "cx23885: ds3000_writereg: writereg error on =kernel-2.6.36-rc with
> > TeVii" S470 dvb-s2 card
> > -> https://bugzilla.kernel.org/show_bug.cgi?id=18832
> > 
> > These error messages show up in dmesg while switching channels in
> > mplayer/kaffeine.
> > [dmesg output]
> > [  919.789976] ds3000_writereg: writereg error(err == -6, reg == 0x03,
> > value == 0x11)
> 
> They look like I2C bus errors; error -6 is ENXIO, which is probably
> coming from cx23885-i2c.c.
> 
> The device handled by the ds3000 driver is not responding properly to
> the CX23885.  It could be that some other device on that I2C bus is hung
> up or the ds3000 device itself.  Maybe some GPIO settings are set wrong?
> 
> The cx23885 module supports an i2c_probe and i2c_debug module option
> that will turn on some messages related to i2c.
> 
> 
> I really have no other advice, except that if you do a 

Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Hans Verkuil]

On Saturday, December 18, 2010 12:31:26 Hans Verkuil wrote:
> Unassigned drivers:
> 
> saa7134
> em28xx

em28xx was a trivial fix, so this can be removed from the list.

Regards,

Hans

> cx88
> solo6x10 (staging driver)
> 
> Regards,
> 
>   Hans
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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

[GIT PATCHES FOR 2.6.37] em28xx: radio_fops should also use unlocked_ioctl

[Hans Verkuil]

Hi Mauro,

This is an urgent one-liner fix for 2.6.37: em28xx was converted to 
core-assisted
locking, but the .ioctl for radio_fops wasn't replaced by .unlocked_ioctl.

Regards,

Hans


The following changes since commit fcdbff339238c0e0a537f95372ef9782e0d18328:
  Mauro Carvalho Chehab (1):
Merge branch 'v4l_for_linus_bkl_removal' into staging/for_v2.6.38

are available in the git repository at:

  ssh://linuxtv.org/git/hverkuil/media_tree.git bkl-trivial

Hans Verkuil (1):
  em28xx: radio_fops should also use unlocked_ioctl

 drivers/media/video/em28xx/em28xx-video.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: Problem with sound on SAA7134 TV card

[Chris Clayton]

Hi again,

Of course, I should have said that sound on the bttv card works through a patch 
lead from the line out port to the line in port on the on-board (Intel HDA) 
sound system.

I also failed to include the saa713x related messages from dmesg, so here they 
are:

[chris:~]$ dmesg | grep saa7
saa7130/34: v4l2 driver version 0.2.16 loaded
saa7134 :03:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
saa7133[0]: found at :03:00.0, rev: 209, irq: 20, latency: 32, mmio: 
0xe1605000
saa7133[0]: subsystem: 0070:6707, board: Hauppauge WinTV-HVR1120 DVB-T/Hybrid 
[card=156,autodetected]
saa7133[0]: board init: gpio is 440100
saa7133[0]: i2c eeprom 00: 70 00 07 67 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[0]: i2c eeprom 10: ff ff ff 0e ff 20 ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: 01 40 01 32 32 01 01 33 88 ff 00 b0 ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 06 32 97 04 00 20 00 ff ff ff
saa7133[0]: i2c eeprom 50: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: i2c eeprom 80: 84 09 00 04 20 77 00 40 c4 ce 6e f0 73 05 29 00
saa7133[0]: i2c eeprom 90: 84 08 00 06 89 06 01 00 95 39 8d 72 07 70 73 09
saa7133[0]: i2c eeprom a0: 23 5f 73 0a f4 9b 72 0b 2f 72 0e 01 72 0f 45 72
saa7133[0]: i2c eeprom b0: 10 01 72 11 ff 73 13 a2 69 79 95 00 00 00 00 00
saa7133[0]: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
saa7133[0]: hauppauge eeprom: model=67209
tuner 1-004b: chip found @ 0x96 (saa7133[0])
saa7133[0]: dsp access error
saa7133[0]: dsp access error
saa7133[0]: registered device video1 [v4l2]
saa7133[0]: registered device vbi0
saa7133[0]: registered device radio0
DVB: registering new adapter (saa7133[0])
saa7134 ALSA driver for DMA sound loaded
saa7133[0]/alsa: saa7133[0] at 0xe1605000 irq 20 registered as card -1

That last line looks a little suspicious to me with the card being registered 
as -1. The two "dsp access error" lines might mean something too.

With the saa7134_alsa debug parameter set to 1, these two additional messages 
show up in dmesg when I start up mplayer as I described yesterday:

saa7133[0]/alsa: rec_start: afmt=2 ch=2  =>  fmt=0x21 swap=-
saa7133[0]/alsa: rec_start: afmt=2 ch=2  =>  fmt=0x21 swap=-

One question - what does the enable parameter of saa7134_alsa affect? The 
description offered via modinfo, whilst obviuos, doesn't mean much to me. I've 
tried with it set to 1, but there was no noticeable difference to the sound.

Thanks,

Chris



On Friday 17 December 2010, Chris Clayton wrote:
> Hi, I hope someone can help me.
>
> Firstly, please cc me on any reply because I'm not subscribed.
>
> I have a Hauppauge HVR-1120 card (I thought I was buying an HVR-1100, but
> 1120 is what was in the box).
>
> Both video and audio for DVB-T work fine but for analogue TV, although the
> video is good, the audio is very poor indeed. By very poor, I mean that
> although the sound is in sync and I can tell that words are being spoken,
> it is very crackly and I have to listen really carefully to make out an odd
> word ort two of what is being said. The analogue signal I am trying to
> watch is from the RF2 output on my Sky satellite box. It is piped round the
> house (and boosted in the loft) and reception if very good on the TV's in
> the adjacent rooms. Indeed, I get good sound and video on my PC through the
> Pinnacle PCTV Pro that I also have installed (bttv driver). The bttv card
> is taking up the other PCI slot that I need it for something else.
>
> I am using mplayer to watch and I call it like this:
>
> mplayer tv:// -tv
> driver=v4l2:device=/dev/wintvvideo:buffersize=32:channel=38:alsa:adevice=hw
>.2,0:amode=1:audiorate=32000:immediatemode=0:forceaudio:norm=PAL -aspect
> 16:9
>
> /dev/wintvvideo is a symlink to /dev/v4l/video1, set up via udev
>
> The output from 'arecord -l' is:
>
>  List of CAPTURE Hardware Devices 
> card 0: Intel [HDA Intel], device 0: ALC888 Analog [ALC888 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: Intel [HDA Intel], device 1: ALC888 Digital [ALC888 Digital]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: Intel [HDA Intel], device 2: ALC888 Analog [ALC888 Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 1: Bt878 [Brooktree Bt878], device 0: Bt87x Digital [Bt87x Digital]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 1: Bt878 [Brooktree Bt878], device 1: Bt87x Analog [Bt87x Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 2: SAA7134 [SAA7134], device 0: SAA7134 PCM [SAA7134

Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Hans Verkuil]

On Saturday, December 18, 2010 13:20:40 Janne Grunau wrote:
> Hi,
> 
> On Sat, Dec 18, 2010 at 12:31:26PM +0100, Hans Verkuil wrote:
> > 
> > Now that the BKL patch series has been merged in 2.6.37 it is time to work
> > on replacing .ioctl by .unlocked_ioctl in all v4l drivers.
> > 
> > I've made an inventory of all drivers that still use .ioctl and I am looking
> > for volunteers to tackle one or more drivers.
> > 
> > I have CCed this email to the maintainers of the various drivers (if I know
> > who it is) in the hope that we can get this conversion done as quickly as
> > possible.
> > 
> > If I have added your name to a driver, then please confirm if you are able 
> > to
> > work on it or not. If you can't work on it, but you know someone else, then
> > let me know as well.
> 
> ...
> 
> > Driver list:
> 
> ...
> 
> > au0828 (Janne Grunau)
> 
> I did only two minor cleanups and don't have the hardware. Steven Toth,
> Devin Heitmueller or Michael Krufky have done major changes to the
> driver.
> 
> Added to CC and trimmed

Hi Janne,

My apologies, for some reason I had it in my head that you maintained that
driver. But I confused au0828 with hdpvr :-(

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Janne Grunau]

Hi,

On Sat, Dec 18, 2010 at 12:31:26PM +0100, Hans Verkuil wrote:
> 
> Now that the BKL patch series has been merged in 2.6.37 it is time to work
> on replacing .ioctl by .unlocked_ioctl in all v4l drivers.
> 
> I've made an inventory of all drivers that still use .ioctl and I am looking
> for volunteers to tackle one or more drivers.
> 
> I have CCed this email to the maintainers of the various drivers (if I know
> who it is) in the hope that we can get this conversion done as quickly as
> possible.
> 
> If I have added your name to a driver, then please confirm if you are able to
> work on it or not. If you can't work on it, but you know someone else, then
> let me know as well.

...

> Driver list:

...

> au0828 (Janne Grunau)

I did only two minor cleanups and don't have the hardware. Steven Toth,
Devin Heitmueller or Michael Krufky have done major changes to the
driver.

Added to CC and trimmed

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

Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Hans Verkuil]

On Saturday, December 18, 2010 12:31:26 Hans Verkuil wrote:
> Driver list:
> 
> saa7146 (Hans Verkuil)
> mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
> cx23885 (Steve Toth)
> cx18-alsa (Andy Walls)
> omap24xxcam (Sakari Ailus or David Cohen)
> au0828 (Janne Grunau)
> cpia2 (Andy Walls or Hans Verkuil)
> cx231xx (Mauro Carvalho Chehab)
> davinci (Muralidharan Karicheri)
> saa6588 (Hans Verkuil)
> pvrusb2 (Mike Isely)
> usbvision (Hans Verkuil)
> s5p-fimc (Sylwester Nawrocki)
> fsl-viu (Anatolij Gustschin)
> tlg2300 (Mauro Carvalho Chehab)
> zr364xx (Hans de Goede)
> soc_camera (Guennadi Liakhovetski)
> usbvideo/vicam (Hans de Goede)
> s2255drv (Pete Eberlein)
> bttv (Mauro Carvalho Chehab)
> stk-webcam (Hans de Goede)
> se401 (Hans de Goede)
> si4713-i2c (Hans Verkuil)
> dsbr100 (Hans Verkuil)

Oops, si4713-i2c and saa6588 are subdevs, so those two can be removed from
this list.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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 v7 2/7] drivers:media:radio: wl128x: fmdrv_v4l2 sources

[Hans Verkuil]

On Friday, December 17, 2010 12:06:31 manjunatha_ha...@ti.com wrote:
> From: Manjunatha Halli 
> 
> This module interfaces V4L2 subsystem and FM common module.
> It registers itself with V4L2 as Radio module.
> 
> Signed-off-by: Manjunatha Halli 
> ---
>  drivers/media/radio/wl128x/fmdrv_v4l2.c |  588 
> +++
>  drivers/media/radio/wl128x/fmdrv_v4l2.h |   33 ++
>  2 files changed, 621 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c
>  create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h
> 
> diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c 
> b/drivers/media/radio/wl128x/fmdrv_v4l2.c
> new file mode 100644
> index 000..623102f
> --- /dev/null
> +++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c



> +static const struct v4l2_file_operations fm_drv_fops = {
> + .owner = THIS_MODULE,
> + .read = fm_v4l2_fops_read,
> + .write = fm_v4l2_fops_write,
> + .poll = fm_v4l2_fops_poll,
> + .ioctl = video_ioctl2,

Please use unlocked_ioctl. The .ioctl call is deprecated since it relied on the
Big Kernel Lock which is in the process of being removed from the kernel. The
BKL serialized all ioctl calls, unlocked_ioctl relies on the driver to serialize
where necessary.

There are two ways of doing the conversion: one is to do all the locking within
the driver, the other is to use core-assisted locking. How to do the 
core-assisted
locking is described in Documentation/video4linux/v4l2-framework.txt, but I'll
repeat the relevant part here:

v4l2_file_operations and locking


You can set a pointer to a mutex_lock in struct video_device. Usually this
will be either a top-level mutex or a mutex per device node. If you want
finer-grained locking then you have to set it to NULL and do you own locking.

If a lock is specified then all file operations will be serialized on that
lock. If you use videobuf then you must pass the same lock to the videobuf
queue initialize function: if videobuf has to wait for a frame to arrive, then
it will temporarily unlock the lock and relock it afterwards. If your driver
also waits in the code, then you should do the same to allow other processes
to access the device node while the first process is waiting for something.

The implementation of a hotplug disconnect should also take the lock before
calling v4l2_device_disconnect.

> + .open = fm_v4l2_fops_open,
> + .release = fm_v4l2_fops_release,
> +};

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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

Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl

[Hans Verkuil]

Hi all,

Now that the BKL patch series has been merged in 2.6.37 it is time to work
on replacing .ioctl by .unlocked_ioctl in all v4l drivers.

I've made an inventory of all drivers that still use .ioctl and I am looking
for volunteers to tackle one or more drivers.

I have CCed this email to the maintainers of the various drivers (if I know
who it is) in the hope that we can get this conversion done as quickly as
possible.

If I have added your name to a driver, then please confirm if you are able to
work on it or not. If you can't work on it, but you know someone else, then
let me know as well.

There is also a list of drivers where I do not know who can do the conversion.
If you can tackle one or more of those, please respond. Unfortunately, those
are among the hardest to convert :-(

It would be great if we can tackle most of these drivers for 2.6.38. I think
we should finish all drivers for 2.6.39 at the latest.

There are two ways of doing the conversion: one is to do all the locking within
the driver, the other is to use core-assisted locking. How to do the 
core-assisted
locking is described in Documentation/video4linux/v4l2-framework.txt, but I'll
repeat the relevant part here:

v4l2_file_operations and locking


You can set a pointer to a mutex_lock in struct video_device. Usually this
will be either a top-level mutex or a mutex per device node. If you want
finer-grained locking then you have to set it to NULL and do you own locking.

If a lock is specified then all file operations will be serialized on that
lock. If you use videobuf then you must pass the same lock to the videobuf
queue initialize function: if videobuf has to wait for a frame to arrive, then
it will temporarily unlock the lock and relock it afterwards. If your driver
also waits in the code, then you should do the same to allow other processes
to access the device node while the first process is waiting for something.

The implementation of a hotplug disconnect should also take the lock before
calling v4l2_device_disconnect.


Driver list:

saa7146 (Hans Verkuil)
mem2mem_testdev (Pawel Osciak or Marek Szyprowski)
cx23885 (Steve Toth)
cx18-alsa (Andy Walls)
omap24xxcam (Sakari Ailus or David Cohen)
au0828 (Janne Grunau)
cpia2 (Andy Walls or Hans Verkuil)
cx231xx (Mauro Carvalho Chehab)
davinci (Muralidharan Karicheri)
saa6588 (Hans Verkuil)
pvrusb2 (Mike Isely)
usbvision (Hans Verkuil)
s5p-fimc (Sylwester Nawrocki)
fsl-viu (Anatolij Gustschin)
tlg2300 (Mauro Carvalho Chehab)
zr364xx (Hans de Goede)
soc_camera (Guennadi Liakhovetski)
usbvideo/vicam (Hans de Goede)
s2255drv (Pete Eberlein)
bttv (Mauro Carvalho Chehab)
stk-webcam (Hans de Goede)
se401 (Hans de Goede)
si4713-i2c (Hans Verkuil)
dsbr100 (Hans Verkuil)

Staging driver list:

go7007 (Pete Eberlein)
tm6000 (Mauro Carvalho Chehab)
(stradis/cpia: will be removed in 2.6.38, so no need to do anything)

Unassigned drivers:

saa7134
em28xx
cx88
solo6x10 (staging driver)

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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 v3] [media] s5p-fimc: fix the value of YUV422 1-plane formats

[Sylwester Nawrocki]

Hi Hyunwoong,

I wish I could apply and test the patch but there are still some
problems with it. Now it doesn't apply and it seem to be mangled
somehow. Even the patchwork didn't accept it, and v2 looks strange:
https://patchwork.kernel.org/patch/412231/
It is better avoided using "==...==" separators in the change log.

Please also make sure it is rebased onto staging/for_v2.6.37-rc1
branch from repository git://linuxtv.org/media_tree.git
or better onto s5p_fimc_fixes_for_2.6.37 branch in repository
git://git.infradead.org/users/kmpark/linux-2.6-samsung

Your second patch
[PATCH][media] s5p-fimc: fix main scaler SFRs depends on FIMC version
looks OK, except it is created against wrong source tree.
Was there any difference in your environment setup while sending those
2 patches?

On 12/17/2010 05:24 AM, Hyunwoong Kim wrote:

Some color formats are mismatched in s5p-fimc driver.
CIOCTRL[1:0], order422_out, should be set 2b'00 not 2b'11
to use V4L2_PIX_FMT_YUYV. Because in V4L2 standard V4L2_PIX_FMT_YUYV means
"start + 0: Y'00 Cb00 Y'01 Cr00 Y'02 Cb01 Y'03 Cr01". According to datasheet
2b'00 is right value for V4L2_PIX_FMT_YUYV.

-
bit |MSBLSB
-
00  |  Cr1Y3Cb1Y2Cr0Y1Cb0Y0
-
01  |  Cb1Y3Cr1Y2Cb0Y1Cr0Y0
-
10  |  Y3Cr1Y2Cb1Y1Cr0Y0Cb0
-
11  |  Y3Cb1Y2Cr1Y1Cb0Y0Cr0
-

V4L2_PIX_FMT_YVYU, V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_VYUY are also mismatched
with datasheet. MSCTRL[17:16], order2p_in, is also mismatched



in V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YVYU.

Signed-off-by: Hyunwoong Kim
Reviewed-by: Jonghun Han
---
Changes since V2:
=
- Correct the name of Output DMA control register
- Change definitions of YUV422 input/outut format with datasheet
   commented by Sylwester Nawrocki.

Changes since V1:
=
- make corrections directly in function fimc_set_yuv_order
   commented by Sylwester Nawrocki.
- remove S5P_FIMC_IN_* and S5P_FIMC_OUT_* definitions from fimc-core.h

  drivers/media/video/s5p-fimc/fimc-core.c |   16 
  drivers/media/video/s5p-fimc/fimc-core.h |   12 
  drivers/media/video/s5p-fimc/regs-fimc.h |   12 ++--
  3 files changed, 14 insertions(+), 26 deletions(-)

diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7f56987..e2b3db1 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -448,34 +448,34 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
/* Set order for 1 plane input formats. */
switch (ctx->s_frame.fmt->color) {
case S5P_FIMC_YCRYCB422:
-   ctx->in_order_1p = S5P_FIMC_IN_YCRYCB;
+   ctx->in_order_1p = S5P_MSCTRL_ORDER422_CBYCRY;
break;
case S5P_FIMC_CBYCRY422:
-   ctx->in_order_1p = S5P_FIMC_IN_CBYCRY;
+   ctx->in_order_1p = S5P_MSCTRL_ORDER422_YCRYCB;
break;
case S5P_FIMC_CRYCBY422:
-   ctx->in_order_1p = S5P_FIMC_IN_CRYCBY;
+   ctx->in_order_1p = S5P_MSCTRL_ORDER422_YCBYCR;
break;
case S5P_FIMC_YCBYCR422:
default:
-   ctx->in_order_1p = S5P_FIMC_IN_YCBYCR;
+   ctx->in_order_1p = S5P_MSCTRL_ORDER422_CRYCBY;
break;
}
dbg("ctx->in_order_1p= %d", ctx->in_order_1p);

switch (ctx->d_frame.fmt->color) {
case S5P_FIMC_YCRYCB422:
-   ctx->out_order_1p = S5P_FIMC_OUT_YCRYCB;
+   ctx->out_order_1p = S5P_CIOCTRL_ORDER422_CBYCRY;
break;
case S5P_FIMC_CBYCRY422:
-   ctx->out_order_1p = S5P_FIMC_OUT_CBYCRY;
+   ctx->out_order_1p = S5P_CIOCTRL_ORDER422_YCRYCB;
break;
case S5P_FIMC_CRYCBY422:
-   ctx->out_order_1p = S5P_FIMC_OUT_CRYCBY;
+   ctx->out_order_1p = S5P_CIOCTRL_ORDER422_YCBYCR;
break;
case S5P_FIMC_YCBYCR422:
default:
-   ctx->out_order_1p = S5P_FIMC_OUT_YCBYCR;
+   ctx->out_order_1p = S5P_CIOCTRL_ORDER422_CRYCBY;
break;
}
dbg("ctx->out_order_1p= %d", ctx->out_order_1p);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h 
b/drivers/media/video/s5p-fimc/fimc-core.h
index 4efc1a1..92cca62 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -95,18 +95,6 @@ enum fimc_color_fmt {

  #define fimc_fmt_is_rgb(x) ((x)&  0x10)

-/* Y/Cb/Cr components orde

Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Hans Verkuil]

On Saturday, December 18, 2010 01:54:41 Laurent Pinchart wrote:
> Hi Mauro,
> 
> On Friday 17 December 2010 18:09:39 Mauro Carvalho Chehab wrote:
> > Em 14-12-2010 08:55, Laurent Pinchart escreveu:
> > > Hi Mauro,
> > > 
> > > Please don't forget this pull request for 2.6.37.
> > 
> > Pull request for upstream sent today.
> 
> Thank you.
> 
> > I didn't find any regressions at the BKL removal patches, but I noticed a
> > few issues with qv4l2, not all related to uvcvideo. The remaining of this
> > email is an attempt to document them for later fixes.
> > 
> > They don't seem to be regressions caused by BKL removal, but the better
> > would be to fix them later.
> > 
> > - with uvcvideo and two video apps, if qv4l2 is started first, the second
> > application doesn't start/capture. I suspect that REQBUFS (used by qv4l2
> > to probe mmap/userptr capabilities) create some resource locking at
> > uvcvideo. The proper way is to lock the resources only if the driver is
> > streaming, as other drivers and videobuf do.
> 
> I don't agree with that. The uvcvideo driver has one buffer queue per device, 
> so if an application requests buffers on one file handle it will lock other 
> applications out. If the driver didn't it would be subject to race conditions.

I agree with Laurent. Once an application calls REQBUFS with non-zero count,
then it should lock the resources needed for streaming. The reason behind that
is that REQBUFS also locks the current selected format in place, since the
format determines the amount of memory needed for the buffers.

The reason a lot of drivers don't do this is partially because for many TV
capture drivers it is highly unlikely that the buffer size will change after
calling REQBUFS (there are basically only two formats: 720x480 or 720x576 and
users will normally never change between the two). However, this is much more
likely to happen for webcams and embedded systems supporting HDTV.

The other reason is probably because driver developers simple do not realize
they need to lock the resources on REQBUFS. I'm sure many existing drivers will
fail miserably if you change the format after calling REQBUFS (particularly
with mmap streaming mode).

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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