Re: Cleanup proposal for media/gspca
On Sat, 19 Nov 2011 15:59:50 -0300 Ezequiel wrote: > Hi Jef, > > I just sent a patch to linux-media for this little issue. > > I realize it is only a very minor patch, > so I am not sure If I am helping or just annoying the developers ;) > > Anyway, if you could check the patch I would appreciate it. [snip] > Again, hope the patch helps, Hi Ezequiel, It is not a minor patch, but maybe you don't know about object programming. As it is defined, a gspca device _is_ a video device, as a gspca subdriver is a gspca device, and as a video device is a device: each lower structure is contained in a higher one. Your patch defines the gspca structure as a separate entity which is somewhat related to a video device by two reverse pointers. It complexifies the structure accesses, adds more code and hides the nature of a gspca device. No, your patch does not help... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: IR disappearing while ATSC decoder in use
On Tue, Nov 15, 2011 at 11:12 PM, Kyle Strickland wrote: > Hi folks, > > I'm messing around trying to get my Kworld PC150-U ATSC hybrid tuner > card (17de:a134) to work, and I think I'm almost done. I've been able > to get all of the functionality to work on its own: remote control, > FM, NTSC, composite input, and ATSC, but for some reason, whenever I > use the ATSC decoder, the remote control stops working. > > Here's what I know about the card so far: > > Analog Decoder chip: SAA7134HL > Tuner: TDA8290+TDA18271 > ATSC/ClearQAM Decoder: Samsung S5H1411, TS using parallel input, chip > enabled by setting GPIO18 high > Remote control: I2C with GPIO8 going low signalling a key press, > similar to MSI TV@nywhere Plus, but with different GPIO pin used for > signalling. > Previous thread about this card found here: > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25680/ > > Looking at the pictures on newegg, the card looks to be the same as > the MSI Digi@nywhere A/D Plus, except with a green mask instead of > red, a different symbol on the remote control media button, and it > doesn't include batteries for the remote :) The EEPROM contents are > even the same except for the subdevice id at the beginning. > > So, whenever I run VLC to watch DTV, button presses stop showing up > with the GPIO, and if I force it to poll I2C rather than checking > GPIO8, I get a read error of either BUSY or ST_ERR or NO_DEVICE. For > that matter, I get a lot of BUSY and ST_ERR, but not NO_DEVICE, with > the S5H1411 in general, and hacked together a retry loop for reading > and writing registers to get past it. I would suspect just funkiness > on the I2C bus, but GPIO8 rarely registers the key press when watching > DTV. When it does register the key press, I am able to read the key > code over I2C. > > I'm completely new to working with tuner cards (just since I bought > this one a month ago), so I was wondering if any of you out there have > had a similar experience with other cards and might have some advice. > I'd appreciate any help I can get. > > I'll be happy to provide code, but I am not running the latest kernel > yet. I'm just making the modifications to the ubuntu source, to see > whether I could get the thing to work before I go all in building and > running the kernel from source control > > Distribution: Ubuntu 11.10 > uname -a: Linux home 3.0.0-12-generic #20 SMP Tue Nov 1 00:33:52 EDT > 2011 x86_64 x86_64 x86_64 GNU/Linux > Modifications made to s5h1411.ko, saa7134.ko, saa7134-alsa.ko, > saa7134-dvb.ko, tda8290.ko, tda18271.ko and new module > rc_kworld_pc150u.ko. > > Thanks, > Kyle Strickland > In case anyone happens to be looking into this now or in the future ( see http://xkcd.com/979/ ), I found the problem, and it has to do with not reading enough bytes in s5h1411_readreg() in s5h1411.c. When I set .len to 3 (originally 2), it reads one more byte off of the i2c bus and leaves the bus in a working state for the IR device. I haven't figured out why it was set to 2 originally, or what the Right Way is to solve the problem so as not to break s5h1411 working already with other decoder chips. Any ideas? Thanks, Kyle Strickland -- 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
Leadtek PxDVR3200H and mythbuntu 11.04/11.10
Hello All, I have a new Leadtek PxDVR3200H tuner card that I an trying to get working in mythbuntu 11.04/11.10 and with little success. The problem seems to be that the hardware is the version that needs the xc4000 firmware, but the kernel drivers assume that it needs the xc2038-v27 firmware. I have tried downloading clean v4l repositories and trying to patch for xc4000 but I can't get it to compile. As well, I'm in Australia so I need the 7MHz version particular to our transmission type. If anyone else has had success with this, I'd love to find out the sequence of steps that you took to do it. Nothing I have been able to do yet works. The card works in the machine with Windows loaded, so there is no problems with the card, antenna or signal strength, as I'm quite close to the centre of the city of Adelaide. Hoping to hear from someone that can give me some ideas on where to go next. Regards, John Kent -- 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 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
> This API will be used to support YUV frame buffer formats in a standard
> way.
looks like the union is causing problems. With this patch applied I get errors
like this:
CC [M] drivers/auxdisplay/cfag12864bfb.o
drivers/auxdisplay/cfag12864bfb.c:57: error: unknown field ‘red’ specified in
initializer
drivers/auxdisplay/cfag12864bfb.c:57: warning: missing braces around initializer
drivers/auxdisplay/cfag12864bfb.c:57: warning: (near initialization for
‘cfag12864bfb_var..’)
drivers/auxdisplay/cfag12864bfb.c:58: error: unknown field ‘green’ specified in
initializer
drivers/auxdisplay/cfag12864bfb.c:58: warning: braces around scalar initializer
drivers/auxdisplay/cfag12864bfb.c:58: warning: (near initialization for
‘cfag12864bfb_var.nonstd’)
drivers/auxdisplay/cfag12864bfb.c:58: warning: excess elements in scalar
initializer
drivers/auxdisplay/cfag12864bfb.c:58: warning: (near initialization for
‘cfag12864bfb_var.nonstd’)
drivers/auxdisplay/cfag12864bfb.c:58: warning: excess elements in scalar
initializer
drivers/auxdisplay/cfag12864bfb.c:58: warning: (near initialization for
‘cfag12864bfb_var.nonstd’)
drivers/auxdisplay/cfag12864bfb.c:59: error: unknown field ‘blue’ specified in
initializer
drivers/auxdisplay/cfag12864bfb.c:59: warning: braces around scalar initializer
drivers/auxdisplay/cfag12864bfb.c:59: warning: (near initialization for
‘cfag12864bfb_var.activate’)
drivers/auxdisplay/cfag12864bfb.c:59: warning: excess elements in scalar
initializer
drivers/auxdisplay/cfag12864bfb.c:59: warning: (near initialization for
‘cfag12864bfb_var.activate’)
drivers/auxdisplay/cfag12864bfb.c:59: warning: excess elements in scalar
initializer
drivers/auxdisplay/cfag12864bfb.c:59: warning: (near initialization for
‘cfag12864bfb_var.activate’)
make[2]: *** [drivers/auxdisplay/cfag12864bfb.o] Error 1
Any idea?
Best regards,
Florian Tobias Schandinat
>
> Last but not least, create a much needed fbdev API documentation and
> document the format setting APIs.
>
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/fb/api.txt | 317
> ++
> include/linux/fb.h | 28 +++-
> 2 files changed, 339 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/fb/api.txt
>
> diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
> new file mode 100644
> index 000..d842534
> --- /dev/null
> +++ b/Documentation/fb/api.txt
> @@ -0,0 +1,317 @@
> + The Frame Buffer Device API
> + ---
> +
> +Last revised: June 21, 2011
> +
> +
> +0. Introduction
> +---
> +
> +This document describes the frame buffer API used by applications to interact
> +with frame buffer devices. In-kernel APIs between device drivers and the
> frame
> +buffer core are not described.
> +
> +Due to a lack of documentation in the original frame buffer API, drivers
> +behaviours differ in subtle (and not so subtle) ways. This document describes
> +the recommended API implementation, but applications should be prepared to
> +deal with different behaviours.
> +
> +
> +1. Capabilities
> +---
> +
> +Device and driver capabilities are reported in the fixed screen information
> +capabilities field.
> +
> +struct fb_fix_screeninfo {
> + ...
> + __u16 capabilities; /* see FB_CAP_* */
> + ...
> +};
> +
> +Application should use those capabilities to find out what features they can
> +expect from the device and driver.
> +
> +- FB_CAP_FOURCC
> +
> +The driver supports the four character code (FOURCC) based format setting
> API.
> +When supported, formats are configured using a FOURCC instead of manually
> +specifying color components layout.
> +
> +
> +2. Types and visuals
> +
> +
> +Pixels are stored in memory in hardware-dependent formats. Applications need
> +to be aware of the pixel storage format in order to write image data to the
> +frame buffer memory in the format expected by the hardware.
> +
> +Formats are described by frame buffer types and visuals. Some visuals require
> +additional information, which are stored in the variable screen information
> +bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
> +
> +Visuals describe how color information is encoded and assembled to create
> +macropixels. Types describe how macropixels are stored in memory. The
> following
> +types and visuals are supported.
> +
> +- FB_TYPE_PACKED_PIXELS
> +
> +Macropixels are stored contiguously in a single plane. If the number of bits
> +per macropixel is not a multiple of 8, whether macropixels are padded to the
> +next multiple of 8 bits or packed together into bytes depends on the visual.
> +
> +Padding at end of lines may be present and is then reported through the fixed
> +screen information line_length field.
> +
> +- FB_TYPE_PLANES
> +
> +Macropixels are split across mu
Re: [PATCH v2] [media] gspca: replaced static allocation by video_device_alloc/video_device_release
On Sat, 19 Nov 2011 18:46:21 -0300 Ezequiel wrote: > Pushed video_device initialization into a separate function. > Replace static allocation of struct video_device by > video_device_alloc/video_device_release usage. > > Signed-off-by: Ezequiel Garcia > --- Hi Ezequiel, just a general comment on commit messages: when doing some invasive changes it is especially important to explain the WHY next to the WHAT and the high-level HOW. [...] > diff --git a/drivers/media/video/gspca/gspca.c > b/drivers/media/video/gspca/gspca.c > index 881e04c..1f27f05 100644 > --- a/drivers/media/video/gspca/gspca.c > +++ b/drivers/media/video/gspca/gspca.c > @@ -1292,10 +1292,12 @@ static int vidioc_enum_frameintervals(struct file > *filp, void *priv, > [...] Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpFXAtjDN4tQ.pgp Description: PGP signature
[PATCH v2] [media] gspca: replaced static allocation by video_device_alloc/video_device_release
Pushed video_device initialization into a separate function.
Replace static allocation of struct video_device by
video_device_alloc/video_device_release usage.
Signed-off-by: Ezequiel Garcia
---
Previous version was sent stupidly incomplete by mistake.
---
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 881e04c..1f27f05 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1292,10 +1292,12 @@ static int vidioc_enum_frameintervals(struct file
*filp, void *priv,
static void gspca_release(struct video_device *vfd)
{
- struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
+ struct gspca_dev *gspca_dev = video_get_drvdata(vfd);
PDEBUG(D_PROBE, "%s released",
- video_device_node_name(&gspca_dev->vdev));
+ video_device_node_name(gspca_dev->vdev));
+
+ video_device_release(vfd);
kfree(gspca_dev->usb_buf);
kfree(gspca_dev);
@@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
static int dev_open(struct file *file)
{
struct gspca_dev *gspca_dev;
+ struct video_device *vdev;
PDEBUG(D_STREAM, "[%s] open", current->comm);
- gspca_dev = (struct gspca_dev *) video_devdata(file);
+ vdev = video_devdata(file);
+ gspca_dev = video_get_drvdata(vdev);
if (!gspca_dev->present)
return -ENODEV;
@@ -1318,10 +1322,10 @@ static int dev_open(struct file *file)
#ifdef GSPCA_DEBUG
/* activate the v4l2 debug */
if (gspca_debug & D_V4L2)
- gspca_dev->vdev.debug |= V4L2_DEBUG_IOCTL
+ gspca_dev->vdev->debug |= V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG;
else
- gspca_dev->vdev.debug &= ~(V4L2_DEBUG_IOCTL
+ gspca_dev->vdev->debug &= ~(V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG);
#endif
return 0;
@@ -2242,13 +2246,6 @@ static const struct v4l2_ioctl_ops dev_ioctl_ops = {
.vidioc_g_chip_ident= vidioc_g_chip_ident,
};
-static const struct video_device gspca_template = {
- .name = "gspca main driver",
- .fops = &dev_fops,
- .ioctl_ops = &dev_ioctl_ops,
- .release = gspca_release,
-};
-
/* initialize the controls */
static void ctrls_init(struct gspca_dev *gspca_dev)
{
@@ -2265,6 +2262,26 @@ static void ctrls_init(struct gspca_dev *gspca_dev)
}
}
+/* initialize a video_device struct */
+static int vdev_init(struct gspca_dev *dev, struct device *parent)
+{
+ struct video_device *vdev = video_device_alloc();
+ if (vdev == NULL)
+ return -ENOMEM;
+
+ /* fill struct video_device */
+ strlcpy(vdev->name, "gspca main driver", sizeof(vdev->name));
+ vdev->fops = &dev_fops,
+ vdev->ioctl_ops = &dev_ioctl_ops,
+ vdev->release = gspca_release,
+ vdev->parent = parent;
+
+ dev->vdev = vdev;
+ video_set_drvdata(vdev, dev);
+
+ return 0;
+}
+
/*
* probe and create a new gspca device
*
@@ -2343,11 +2360,15 @@ int gspca_dev_probe2(struct usb_interface *intf,
init_waitqueue_head(&gspca_dev->wq);
/* init video stuff */
- memcpy(&gspca_dev->vdev, &gspca_template, sizeof gspca_template);
- gspca_dev->vdev.parent = &intf->dev;
+ ret = vdev_init(gspca_dev, &intf->dev);
+ if (ret < 0) {
+ pr_err("initialize video device err %d\n", ret);
+ goto out;
+ }
+
gspca_dev->module = module;
gspca_dev->present = 1;
- ret = video_register_device(&gspca_dev->vdev,
+ ret = video_register_device(gspca_dev->vdev,
VFL_TYPE_GRABBER,
-1);
if (ret < 0) {
@@ -2356,7 +2377,7 @@ int gspca_dev_probe2(struct usb_interface *intf,
}
usb_set_intfdata(intf, gspca_dev);
- PDEBUG(D_PROBE, "%s created", video_device_node_name(&gspca_dev->vdev));
+ PDEBUG(D_PROBE, "%s created", video_device_node_name(gspca_dev->vdev));
gspca_input_create_urb(gspca_dev);
@@ -2411,7 +2432,7 @@ void gspca_disconnect(struct usb_interface *intf)
#endif
PDEBUG(D_PROBE, "%s disconnect",
- video_device_node_name(&gspca_dev->vdev));
+ video_device_node_name(gspca_dev->vdev));
mutex_lock(&gspca_dev->usb_lock);
gspca_dev->present = 0;
@@ -2436,7 +2457,7 @@ void gspca_disconnect(struct usb_interface *intf)
/* release the device */
/* (this will call gspca_release() immediately or on last close) */
- video_unregister_device(&gspca_dev->vdev);
+ video_unregister_device(gspca_dev->vdev);
/* PDEBUG(D_PROBE, "disconnect complete"); */
}
diff --git a/drivers/media/video/gspca/gspca.h
b/drivers/media/video/gspca/gspca.h
index e444f16..f89b8fb 100644
--- a/dr
Re: [PATCH] [media] gspca: replaced static allocation by video_device_alloc/video_device_release
On Sat, Nov 19, 2011 at 08:20:22PM +0100, Hans de Goede wrote: > Hi, > > On 11/19/2011 07:50 PM, Ezequiel wrote: > > Pushed video_device initialization into a separate function. > > Replaced static allocation of struct video_device by > > video_device_alloc/video_device_release usage. > > NACK! I see a video_device_release call here, but not a > video_device_alloc, also you're messing with quite sensitive code > here (because a usb device can be unplugged at any time, including > when the /dev/video node is open by a process), and changing it > from static to dynamic allocation my have more consequences > then you see at first (I did not analyze all the code paths > for the proposed change, since the last time I audited them for > the current static allocation of the videodevice struct code took > me hours). > > Also static allocation (as part of the driver struct) in general is > better then dynamic as it needs less code and helps avoiding memory > fragmentation. > > All in all I cannot help but feel that you're diving into a piece > of code with some drive by shooting style patch without knowing > the code in question at all, please don't do that! > > Regards, > > Hans > Hi Hans, Sorry, really dont know what happened, I sent an incomplete patch version. (some vim yank-key error). I understand your observations about static vs dynamic, but please could you review the right patch. Thanks, Ezequiel. -- 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] [media] gspca: replaced static allocation by video_device_alloc/video_device_release
Hi,
On 11/19/2011 07:50 PM, Ezequiel wrote:
Pushed video_device initialization into a separate function.
Replaced static allocation of struct video_device by
video_device_alloc/video_device_release usage.
NACK! I see a video_device_release call here, but not a
video_device_alloc, also you're messing with quite sensitive code
here (because a usb device can be unplugged at any time, including
when the /dev/video node is open by a process), and changing it
from static to dynamic allocation my have more consequences
then you see at first (I did not analyze all the code paths
for the proposed change, since the last time I audited them for
the current static allocation of the videodevice struct code took
me hours).
Also static allocation (as part of the driver struct) in general is
better then dynamic as it needs less code and helps avoiding memory
fragmentation.
All in all I cannot help but feel that you're diving into a piece
of code with some drive by shooting style patch without knowing
the code in question at all, please don't do that!
Regards,
Hans
Signed-off-by: Ezequiel Garcia
---
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 881e04c..1f27f05 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1292,10 +1292,12 @@ static int vidioc_enum_frameintervals(struct file
*filp, void *priv,
static void gspca_release(struct video_device *vfd)
{
- struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
+ struct gspca_dev *gspca_dev = video_get_drvdata(vfd);
PDEBUG(D_PROBE, "%s released",
- video_device_node_name(&gspca_dev->vdev));
+ video_device_node_name(gspca_dev->vdev));
+
+ video_device_release(vfd);
kfree(gspca_dev->usb_buf);
kfree(gspca_dev);
@@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
static int dev_open(struct file *file)
{
struct gspca_dev *gspca_dev;
+ struct video_device *vdev;
PDEBUG(D_STREAM, "[%s] open", current->comm);
- gspca_dev = (struct gspca_dev *) video_devdata(file);
+ vdev = video_devdata(file);
+ gspca_dev = video_get_drvdata(vdev);
if (!gspca_dev->present)
return -ENODEV;
@@ -1318,10 +1322,10 @@ static int dev_open(struct file *file)
#ifdef GSPCA_DEBUG
/* activate the v4l2 debug */
if (gspca_debug& D_V4L2)
- gspca_dev->vdev.debug |= V4L2_DEBUG_IOCTL
+ gspca_dev->vdev->debug |= V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG;
else
- gspca_dev->vdev.debug&= ~(V4L2_DEBUG_IOCTL
+ gspca_dev->vdev->debug&= ~(V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG);
--
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: Cleanup proposal for media/gspca
On Thu, Nov 17, 2011 at 11:07:16AM +0100, Jean-Francois Moine wrote:
> On Wed, 16 Nov 2011 15:19:04 -0300
> Ezequiel Garc??a wrote:
>
> > In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
> > I am too dumb to understand it):
> >
> > gspca_dev = (struct gspca_dev *) video_devdata(file);
> >
> > wich is only legal because a struct video_device is the first member
> > of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
> > The thing is the driver is surely working fine and there is no good
> > reasong for the change.
> >
> > Is it ok to submit a patchset to change this? Something like this:
> >
> > diff --git a/drivers/media/video/gspca/gspca.c
> > b/drivers/media/video/gspca/gspca.c
> > index 881e04c..5d962ce 100644
> > --- a/drivers/media/video/gspca/gspca.c
> > +++ b/drivers/media/video/gspca/gspca.c
> > @@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
> > static int dev_open(struct file *file)
> > {
> > struct gspca_dev *gspca_dev;
> > + struct video_device *vdev;
> >
> > PDEBUG(D_STREAM, "[%s] open", current->comm);
> > - gspca_dev = (struct gspca_dev *) video_devdata(file);
> > + vdev = video_devdata(file);
> > + gspca_dev = video_get_drvdata(vdev);
> > if (!gspca_dev->present)
>
> Hi Ezequiel,
>
> You are right, the cast is not a good way (and there are a lot of them
> in the gspca subdrivers), but your patch does not work because the
> 'private_data' of the device is not initialized (there is no call to
> video_set_drvdata).
>
> So, a possible cleanup could be:
>
> > - gspca_dev = (struct gspca_dev *) video_devdata(file);
> > + gspca_dev = container_of(video_devdata(file), struct gspca_dev, vdev);
>
> Is it OK for you?
>
Hi Jef,
I just sent a patch to linux-media for this little issue.
I realize it is only a very minor patch,
so I am not sure If I am helping or just annoying the developers ;)
Anyway, if you could check the patch I would appreciate it.
A few questions arose:
* I made the patch on this tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
not sure if this is ok.
* Should I send gspca's patches to anyone else besides you and the list?
* I have this on my MAINTANIERS file:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
But that repo seems no longer alive, maybe MAINTAINERS need some
updating.
Again, hope the patch helps,
Thanks,
Ezequiel.
--
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] [media] gspca: replaced static allocation by video_device_alloc/video_device_release
Pushed video_device initialization into a separate function.
Replaced static allocation of struct video_device by
video_device_alloc/video_device_release usage.
Signed-off-by: Ezequiel Garcia
---
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 881e04c..1f27f05 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1292,10 +1292,12 @@ static int vidioc_enum_frameintervals(struct file
*filp, void *priv,
static void gspca_release(struct video_device *vfd)
{
- struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
+ struct gspca_dev *gspca_dev = video_get_drvdata(vfd);
PDEBUG(D_PROBE, "%s released",
- video_device_node_name(&gspca_dev->vdev));
+ video_device_node_name(gspca_dev->vdev));
+
+ video_device_release(vfd);
kfree(gspca_dev->usb_buf);
kfree(gspca_dev);
@@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
static int dev_open(struct file *file)
{
struct gspca_dev *gspca_dev;
+ struct video_device *vdev;
PDEBUG(D_STREAM, "[%s] open", current->comm);
- gspca_dev = (struct gspca_dev *) video_devdata(file);
+ vdev = video_devdata(file);
+ gspca_dev = video_get_drvdata(vdev);
if (!gspca_dev->present)
return -ENODEV;
@@ -1318,10 +1322,10 @@ static int dev_open(struct file *file)
#ifdef GSPCA_DEBUG
/* activate the v4l2 debug */
if (gspca_debug & D_V4L2)
- gspca_dev->vdev.debug |= V4L2_DEBUG_IOCTL
+ gspca_dev->vdev->debug |= V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG;
else
- gspca_dev->vdev.debug &= ~(V4L2_DEBUG_IOCTL
+ gspca_dev->vdev->debug &= ~(V4L2_DEBUG_IOCTL
| V4L2_DEBUG_IOCTL_ARG);
--
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: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Nov 19 19:00:16 CET 2011 git hash:e9eb0dadba932940f721f9d27544a7818b2fa1c5 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: ERRORS spec-git: WARNINGS 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: [Linaro-mm-sig] [PATCHv17 0/11] Contiguous Memory Allocator
On Fri, 18 Nov 2011 22:20:48 +0100, sandeep patil wrote: So, i guess my question is, until all the migration failures are tracked down and fixed, is there a plan to retry the contiguous allocation from a new range in the CMA region? 2011/11/18 Michal Nazarewicz : No. Current CMA implementation will stick to the same range of pages also on consequent allocations of the same size. On Sat, 19 Nov 2011 00:30:49 +0100, sandeep patil wrote: Doesn't that mean the drivers that fail to allocate from contiguous DMA region will fail, if the migration fails? Yes. I have some ideas how that could be mitigated. The easiest would be to try another region to allocate from on failure. More complicated could be to try and wait for the I/O transfer to finish. I'll try to work on it during upcoming week. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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] initial support for HAUPPAUGE HVR-930C again...
With this patch I try again to add initial support for HVR930C.
Tested only DVB-T, since in Italy Analog service is stopped.
Actually "scan -a0 -f1", find only about 50 channel while 400 should
be available.
Signed-off-by: Eddi De Pieri
Regards
Eddi
diff -u -N -r linux/drivers/media/common/tuners/xc5000.c linux.patched/drivers/media/common/tuners/xc5000.c
--- linux/drivers/media/common/tuners/xc5000.c 2011-03-31 23:56:49.0 +0200
+++ linux.patched/drivers/media/common/tuners/xc5000.c 2011-11-19 15:37:20.516138695 +0100
@@ -977,6 +977,13 @@
return 0;
}
+static int xc5000_get_if_frequency(struct dvb_frontend *fe, u32 *frequency)
+{
+ struct xc5000_priv *priv = fe->tuner_priv;
+ *frequency = priv->if_khz * 1000;
+ return 0;
+}
+
static int xc5000_get_status(struct dvb_frontend *fe, u32 *status)
{
struct xc5000_priv *priv = fe->tuner_priv;
@@ -996,6 +1003,8 @@
struct xc5000_priv *priv = fe->tuner_priv;
int ret = 0;
+ mutex_lock(&xc5000_list_mutex);
+
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
@@ -1015,6 +1024,8 @@
/* Default to "CABLE" mode */
ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+ mutex_unlock(&xc5000_list_mutex);
+
return ret;
}
@@ -1109,6 +1120,7 @@
.set_analog_params = xc5000_set_analog_params,
.get_frequency = xc5000_get_frequency,
.get_bandwidth = xc5000_get_bandwidth,
+ .get_if_frequency = xc5000_get_if_frequency,
.get_status = xc5000_get_status
};
diff -u -N -r linux/drivers/media/dvb/frontends/drxk.h linux.patched/drivers/media/dvb/frontends/drxk.h
--- linux/drivers/media/dvb/frontends/drxk.h 2011-07-11 20:09:53.0 +0200
+++ linux.patched/drivers/media/dvb/frontends/drxk.h 2011-11-19 15:20:32.119137206 +0100
@@ -25,6 +25,8 @@
bool antenna_dvbt;
u16 antenna_gpio;
+
+ intchunk_size;
const char *microcode_name;
};
diff -u -N -r linux/drivers/media/dvb/frontends/drxk_hard.c linux.patched/drivers/media/dvb/frontends/drxk_hard.c
--- linux/drivers/media/dvb/frontends/drxk_hard.c 2011-09-04 05:45:09.0 +0200
+++ linux.patched/drivers/media/dvb/frontends/drxk_hard.c 2011-11-19 15:20:32.123137210 +0100
@@ -681,7 +681,8 @@
state->m_hasOOB = false;
state->m_hasAudio = false;
- state->m_ChunkSize = 124;
+ if (!state->m_ChunkSize)
+ state->m_ChunkSize = 124;
state->m_oscClockFreq = 0;
state->m_smartAntInverted = false;
@@ -6423,6 +6424,7 @@
state->no_i2c_bridge = config->no_i2c_bridge;
state->antenna_gpio = config->antenna_gpio;
state->antenna_dvbt = config->antenna_dvbt;
+ state->m_ChunkSize = config->chunk_size;
/* NOTE: as more UIO bits will be used, add them to the mask */
state->UIO_mask = config->antenna_gpio;
diff -u -N -r linux/drivers/media/video/em28xx/em28xx-cards.c linux.patched/drivers/media/video/em28xx/em28xx-cards.c
--- linux/drivers/media/video/em28xx/em28xx-cards.c 2011-11-04 05:45:40.0 +0100
+++ linux.patched/drivers/media/video/em28xx/em28xx-cards.c 2011-11-19 15:21:18.247365922 +0100
@@ -336,6 +336,24 @@
{ -1, -1, -1, -1},
};
+static struct em28xx_reg_seq hauppauge_930c_gpio[] = {
+// xc5000 reset
+ {EM2874_R80_GPIO, 0x6f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x4f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x6f, 0xff, 10},
+ {EM2874_R80_GPIO, 0x4f, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+#if 0
+static struct em28xx_reg_seq hauppauge_930c_digital[] = {
+ {EM2874_R80_GPIO, 0xf6, 0xff, 10},
+ {EM2874_R80_GPIO, 0xe6, 0xff, 100},
+ {EM2874_R80_GPIO, 0xa6, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+#endif
+
/*
* Board definitions
*/
@@ -892,6 +910,19 @@
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ [EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C] = {
+ .name = "Hauppauge WinTV HVR 930C",
+ .has_dvb = 1,
+//#if 0
+// .tuner_type = TUNER_XC5000,
+// .tuner_addr = 0x41,
+// .dvb_gpio = hauppauge_930c_digital, /* FIXME: probably wrong */
+ .tuner_gpio = hauppauge_930c_gpio,
+//#endif
+ .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
+EM28XX_I2C_CLK_WAIT_ENABLE |
+EM28XX_I2C_FREQ_400_KHZ,
+ },
[EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900] = {
.name = "Hauppauge WinTV HVR 900",
.tda9887_conf = TDA9887_PRESENT,
@@ -1975,6 +2006,8 @@
.driver_info = EM28174_BOARD_PCTV_290E },
{ USB_DEVICE(0x2013, 0x024c),
.driver_info = EM28174_BOARD_PCTV_460E },
+ { USB_DEVICE(0x2040, 0x1605),
+ .driver_info = EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
@@ -2028,10 +2061,10 @@
int rc = 0;
struct em28xx *dev = ptr;
- if (dev->tuner_type != TUNER_XC2028)
+ if (dev->tuner_type != TUNER_XC2028 && dev->tuner_type != TUNER_XC5000)
return 0;
- if (command != XC2028_TUNER_RESET)
+ if (command != XC2028_TUNER_RESET && command != XC5000_TUNER_RESET)
return 0;
rc = em28xx_gpio_set(dev, dev->board.tuner_gpio);
diff -u -N -r linux/drivers/media/video/em28xx
Card "Pinnacle PCTV usb Stik" Not faund. in not more supported?
daniel@ubuntu-portatil:~$ tail -f /var/log/kern.log Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.268995] em28xx #0: card=77 -> EM2874 Leadership ISDBT Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.268998] em28xx #0: card=78 -> PCTV nanoStick T2 290e Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.269000] em28xx #0: card=79 -> Terratec Cinergy H5 Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.269005] em28xx #0: v4l2 driver version 0.1.3 Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.277303] em28xx #0: V4L2 video device registered as video0 Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.278070] usbcore: registered new interface driver em28xx Nov 19 13:53:28 ubuntu-portatil kernel: [ 757.278074] em28xx driver loaded Nov 19 15:13:13 ubuntu-portatil kernel: [ 5542.060142] usb 1-1: USB disconnect, device number 4 Nov 19 15:13:13 ubuntu-portatil kernel: [ 5542.060241] em28xx #0: disconnecting em28xx #0 video Nov 19 15:13:13 ubuntu-portatil kernel: [ 5542.060248] em28xx #0: V4L2 device video0 deregistered Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.136037] usb 1-1: new high speed USB device number 5 using ehci_hcd Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.272753] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.272816] em28xx #0: chip ID is em2870 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355070] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 70 28 c0 12 81 00 6a 22 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355085] em28xx #0: i2c eeprom 10: 00 00 04 57 02 0d 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355097] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 02 00 00 00 00 00 5b 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355108] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 af 54 57 47 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355119] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355130] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355141] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355153] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355164] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355175] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355186] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355197] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355208] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355219] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355230] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355241] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355254] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xc663edce Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355257] em28xx #0: EEPROM info: Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355259] em28xx #0: No audio on board. Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355261] em28xx #0: 500mA max power Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.355264] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.434571] em28xx #0: found i2c device @ 0xa0 [eeprom] Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.440558] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452444] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452451] em28xx #0: You may try to use card= insmod option to workaround that. Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452454] em28xx #0: Please send an email with this log to: Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452456] em28xx #0: V4L Mailing List Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452459] em28xx #0: Board eeprom hash is 0xc663edce Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452461] em28xx #0: Board i2c devicelist hash is 0x4b800080 Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574.452464] em28xx #0: Here is a list of valid choices for the card= insmod option: Nov 19 15:13:45 ubuntu-portatil kernel: [ 5574
