Re: usb dvb-c tuner status
Hello all, A while back I asked about supported USB dvb-c devices. Meanwhile my search continued and I have extended my list of available devices. Unfortunately, none of them currently are supported by linux. Does anyone have viable solution for me? - Technotrend CT 1200 which is an old device, hard to get. - Technotrend CT-3650 for which there is one report that dvb-c works with a patch,(is this already in-tree?), but dvb-t and CI not - Sundtek MediaTV Pro for which a closed source driver exists. I don't want to go that way. Terratec Cinergy Hybrid H5 which seems to be troubled with a driver for a drx-k or drx-j chip. - Pinnacle 340e, depends on the xc4000 chip, under development by Devin. - Hauppauge WinTV HVR-930C, also drx-j based as far as I can see Regards, Bert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Linuxtv wiki needs email notification/more email-ready users
H. Langos wrote: > Hi there, > > after a while I decided to come back to the linuxtv wiki to finish > organizing the bazillion dvb-t usb devices in a way that helps > a) normal users to find out if a certain device is supported and > b) developers to update information on the drivers they manage. > > Some preview of this can be seen on my playground page: > http://www.linuxtv.org/wiki/index.php/HLPlayground2 > > As this is a more complicated way of storing the information than just plain > tables, I'd like to keep an eye on changes. Not because of fear of > vandalisim but because changes to the templates/date potentially have > effects on a lot of pages. > > There are some people who day by day put a lot of effort and work into the > wiki and I'd like to thank them all for their continuing effort. I myself > have only occasionaly time to update information there and I miss a lot > of changes, even to the pages I watch, because the "watchlist" and "recent > cahnges" reaches only seven days back. Manually going through the pages on > my watchlist (currently 57) is not what I'd call good use of resources. > > It would be great if it was possible to get (immediate/daily/weekly?) change > notifications by email in order not to lose track of what is happening to > the pages that I care about. (I bet this is standard functionality of > mediawiki or at least one of the more common extentions.) > > > Also I'd like to encourage new and existing users to add their email address > to their profile AND to check the "Enable e-mail from other users" box. > Maybe we could change the default to enable that box? > That way it is possible to ask for missing details if somebody adds a new > device, or to send hints if somebody writes in an article that a certain > device doesn't work. Or to simply write a short note when removing some > information like "Hey dude, I just removed some information that you added > to article X because it is already contained in article Y. Instead I've > added a link to Y. Thank you for your help and keep up the good work!..." > > Also developers could ask people who are interested in a device's driver to > check out a new version as soon as it is ready. > > All in all it would improve the user experience and the quality of > information > on the wiki as feedback would not have to go through the "discussion" pages. > > I went that way when talking to some other wiki admins about my efforts to > unify the usb dvb-t data and the experience shows that wiki's are not a > good medium for serious discussions. > > cheers > -henrik > (I've cc'ed the LMML to reach the wider audience nowadays) These are good suggestions that Henrik has made. I would encourage others to also step up and try to find ways to implement them (along with any other improvements that can be made to the wiki and other sources of V4L-DVB documentation and website -- the website, in particular, really could stand for an overhaul). (Note - at present I do not have time to take on further work, nor do I personally really want the responsibility of being the point man for such changes ... as it stands, I'm interested only in finishing off ventures I commenced long ago ... or introducing changes that are personally enjoyable to myself to make) I also note that from prior discussions with Henrik and Jim (and Henrik is absolutely correct that discussing things from within the wiki quickly becomes difficult to follow), and from prior times with Micheal and Devin on irc, that we were touching upon the idea of a database. One such example that I recently came across, and that is worth further investigation by someone (and, again, that someone does not include me), is that model used by dd-wrt for their supported hardware (i would link, but it appears that their server is down at the moment). -- 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: Hw capabilities of the HVR-2200
2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. So I garner from that, that you don't intend to add support for anything (including extra encoding abilities that they don't support in Windows) unless Hauppauge officially does? No, I was referring specifically to your component 'are you sure?' question. I've said many times on and off this mailing list that I'd like to add support for all of the encoder a/v codecs, regardless of the windows driver and it's capabilities. Timeframe for this is unknown. Okay thanks Steven for taking some time to address these Qns, I'm done. -- 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.31] V4L/DVB updates
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the second (and final) part of new stuff for kernel 2.6.31. This series adds two relevant improvements at the multimedia support: 1) Support for ISDB-T (for broadcast TV) and ISDB-S (for satellite transmissions). This means that finally we have support for Digital TV standards used in Japan and Brasil, and being implemented on several countries in South America and maybe in other Asian Countries. 2) Documentation for V4L2 and DVB APIs Since 1999, V4L2 API were used in kernel, and since 2002, DVB API. However, during all those time, there weren't a single document describing DVB API on kernel, and V4L2 API were never added. This situation always bother me since I started maintaining the subsystem. On this series, this gap is finally filled: Both V4L2 and DVB API specs were converted from DocBook v3.1 and LaTex to DocBook XML 4.1.2, and added at Documentation/DocBook. It were converted as an unique document, to be easier to be referenced and used. I hope that this will improve the usage of the API and help to keep it updated with the latest changes at the code. This series also contains several new drivers: - new driver for NXP saa7164; - new driver for gl860 webcams; - new driver for dibcom 80xx chips (ISDB-T); - new driver for Earthsoft PT1 ISDB-T/ISDB-S cards; - new driver for 774 Friio White USB ISDB-T receiver; - new drivers for DaVinci display (vpif, dm646x, vpfe, dm355, dm644x); - new driver for adv7180 analog decoder; - new staging driver for cx25821. This device has 10 simultaneous video input/output into a single PCIe chip, being probably the most complex device currently supported. Help is needed to cleanup the driver and put it into kernel CodingStyle; Also in this patch series: - em28xx: Add support for VBI; - tda18271: several improvements; - gspca - m5602-s5k4aa: several improvements at control capabilities; - dibcom drivers: add support for stk7770p; - soc-camera: converted to v4l dev/subdev model, allowing future share of code with other drivers; - miscelaneous fixes, driver additions, etc; Cheers, Mauro. --- Documentation/DocBook/Makefile | 10 +- Documentation/DocBook/dvb/.gitignore |1 + Documentation/DocBook/dvb/audio.xml| 1473 Documentation/DocBook/dvb/ca.xml | 221 ++ Documentation/DocBook/dvb/demux.xml| 973 Documentation/DocBook/dvb/dvbapi.xml | 87 + Documentation/DocBook/dvb/dvbstb.pdf | Bin 0 -> 1881 bytes Documentation/DocBook/dvb/dvbstb.png | Bin 0 -> 22655 bytes Documentation/DocBook/dvb/examples.xml | 365 +++ Documentation/DocBook/dvb/frontend.xml | 1766 ++ Documentation/DocBook/dvb/intro.xml| 191 ++ Documentation/DocBook/dvb/isdbt.xml| 314 +++ Documentation/DocBook/dvb/kdapi.xml| 2309 ++ Documentation/DocBook/dvb/net.xml | 12 + Documentation/DocBook/dvb/video.xml| 1971 Documentation/DocBook/media-entities.tmpl | 364 +++ Documentation/DocBook/media-indices.tmpl | 85 + Documentation/DocBook/media.tmpl | 112 + Documentation/DocBook/stylesheet.xsl |1 + Documentation/DocBook/v4l/.gitignore |1 + Documentation/DocBook/v4l/biblio.xml | 188 ++ Documentation/DocBook/v4l/capture.c.xml| 659 ++ Documentation/DocBook/v4l/common.xml | 1160 + Documentation/DocBook/v4l/compat.xml | 2457 Documentation/DocBook/v4l/controls.xml | 2049 Documentation/DocBook/v4l/crop.gif | Bin 0 -> 5967 bytes Documentation/DocBook/v4l/crop.pdf | Bin 0 -> 5846 bytes Documentation/DocBook/v4l/dev-capture.xml | 115 + Documentation/DocBook/v4l/dev-codec.xml| 26 + Documentation/DocBook/v4l/dev-effect.xml | 25 + Documentation/DocBook/v4l/dev-osd.xml | 164 ++ Documentation/DocBook/v4l/dev-output.xml | 111 + Documentation/DocBook/v4l/dev-overlay.xml | 379 +++ Documentation/DocBook/v4l/dev-radio.xml| 57 + Documentation/DocBook/v4l/dev-raw-vbi.xml | 347 +++ Documentation/DocBook/v4l/dev-rds.xml | 168 ++ Documentation/DocBook/v4l/dev-sliced-vbi.xml | 708 ++ Documentation/DocBook/v4l/dev-teletext.xml | 40 + Documentation/DocBook/v4l/driver.xml | 208 ++ Documentation/DocBook/v4l/fdl-appendix.xml | 671 ++ Documentation/DocBook/v4l/fieldseq_bt.gif | Bin 0 -> 25430 bytes Documentation/DocBook/v4l/fieldseq_bt.pdf
Diffs between our tree and upstream
Hi Guennadi,
I'm about to send our pull request.
While doing my last checks, I noticed a difference between our tree and
upstream. I'm not sure what happens. Could you please check?
The enclosed patch is the diff from upstream to -hg.
Cheers,
Mauro
diff -upr oldtree/drivers/media/video/sh_mobile_ceu_camera.c
/home/v4l/tokernel/wrk/linux-next/drivers/media/video/sh_mobile_ceu_camera.c
--- oldtree/drivers/media/video/sh_mobile_ceu_camera.c 2009-09-19
01:00:51.0 -0300
+++
/home/v4l/tokernel/wrk/linux-next/drivers/media/video/sh_mobile_ceu_camera.c
2009-09-19 00:56:27.0 -0300
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -93,7 +93,6 @@ struct sh_mobile_ceu_dev {
unsigned int irq;
void __iomem *base;
- struct clk *clk;
unsigned long video_limit;
/* lock used to protect videobuf */
@@ -1649,7 +1648,6 @@ static int __devinit sh_mobile_ceu_probe
struct sh_mobile_ceu_dev *pcdev;
struct resource *res;
void __iomem *base;
- char clk_name[8];
unsigned int irq;
int err = 0;
@@ -1713,13 +1711,9 @@ static int __devinit sh_mobile_ceu_probe
goto exit_release_mem;
}
- snprintf(clk_name, sizeof(clk_name), "ceu%d", pdev->id);
- pcdev->clk = clk_get(&pdev->dev, clk_name);
- if (IS_ERR(pcdev->clk)) {
- dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
- err = PTR_ERR(pcdev->clk);
- goto exit_free_irq;
- }
+ pm_suspend_ignore_children(&pdev->dev, true);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_resume(&pdev->dev);
pcdev->ici.priv = pcdev;
pcdev->ici.v4l2_dev.dev = &pdev->dev;
@@ -1729,12 +1723,10 @@ static int __devinit sh_mobile_ceu_probe
err = soc_camera_host_register(&pcdev->ici);
if (err)
- goto exit_free_clk;
+ goto exit_free_irq;
return 0;
-exit_free_clk:
- clk_put(pcdev->clk);
exit_free_irq:
free_irq(pcdev->irq, pcdev);
exit_release_mem:
@@ -1755,7 +1747,6 @@ static int __devexit sh_mobile_ceu_remov
struct sh_mobile_ceu_dev, ici);
soc_camera_host_unregister(soc_host);
- clk_put(pcdev->clk);
free_irq(pcdev->irq, pcdev);
if (platform_get_resource(pdev, IORESOURCE_MEM, 1))
dma_release_declared_memory(&pdev->dev);
@@ -1764,9 +1755,27 @@ static int __devexit sh_mobile_ceu_remov
return 0;
}
+static int sh_mobile_ceu_runtime_nop(struct device *dev)
+{
+ /* Runtime PM callback shared between ->runtime_suspend()
+* and ->runtime_resume(). Simply returns success.
+*
+* This driver re-initializes all registers after
+* pm_runtime_get_sync() anyway so there is no need
+* to save and restore registers here.
+*/
+ return 0;
+}
+
+static struct dev_pm_ops sh_mobile_ceu_dev_pm_ops = {
+ .runtime_suspend = sh_mobile_ceu_runtime_nop,
+ .runtime_resume = sh_mobile_ceu_runtime_nop,
+};
+
static struct platform_driver sh_mobile_ceu_driver = {
.driver = {
.name = "sh_mobile_ceu",
+ .pm = &sh_mobile_ceu_dev_pm_ops,
},
.probe = sh_mobile_ceu_probe,
.remove = __exit_p(sh_mobile_ceu_remove),
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
Em Fri, 18 Sep 2009 11:03:13 -0400 Steven Toth escreveu: > On 9/18/09 12:24 AM, Mauro Carvalho Chehab wrote: > > Em Thu, 17 Sep 2009 20:05:14 -0400 > > Steven Toth escreveu: > > > >> > >> Mauro, > >> > >> Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-dev > >> > >> - SAA7164: Remove the SAA7164 bus id, no longer required. > >> - SAA7164: Remove the i2c client_attach/detach support, no longer > >> required. > >> - SAA7164: Removed bus registration messages from driver startup > >> > >>drivers/media/video/saa7164/saa7164-i2c.c | 62 -- > >>include/linux/i2c-id.h|1 > >>2 files changed, 1 insertion(+), 62 deletions(-) > >> > >> These fix the i2c attach/detach compilation error and the id assignment > >> we'd > >> previously discussed, as well as reducing slightly the driver verbosity > >> during > >> i2c bus registration. > > > > Ok, now it compiles, but there are still two warnings against upstream, > > with x86_64: > > > > drivers/media/video/saa7164/saa7164-buffer.c: In function > > ‘saa7164_buffer_alloc’: > > drivers/media/video/saa7164/saa7164-buffer.c:110: warning: cast to pointer > > from integer of different size > > drivers/media/video/saa7164/saa7164-buffer.c:112: warning: cast to pointer > > from integer of different size > > Last I checked prior to merge the only 64bit'ism was the warning for the call > to > the kernel software demux. Let me look into this today. Fixed. The error where with i386. > > - Steve > Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/v4l-dvb for the following: - go7007: sound needs compat.hdefault tip - go7007: convert printks to v4l2_info - s2250-board: Implement brightness and contrast controls - s2250-board: Fix memory leaks - go7007: Implement vidioc_g_std and vidioc_querystd - go7007: Merge struct gofh and go declarations - go7007: Fix mpeg controls - go7007: Fix whitespace and line lengths - go7007: Updates to Kconfig and Makefile - radio-si4713: remove #include - video: initial support for ADV7180 - kzalloc failure ignored in au8522_probe() - GSPCA: kmalloc failure ignored in sd_start() - kmalloc failure ignored in lgdt3304_attach() and s921_attach() - kmalloc failure ignored in m920x_firmware_download() - Add support for Compro VideoMate E800 (DVB-T part only) - FM TX: si4713: Kconfig: Fixed two typos. - uvc: introduce missing kfree - Change tuner type of BeholdTV cards Thanks, Douglas -- 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
BIOS date 12/02/2008 needs vflip fix on GX700 for gspca_m5602
Hi, Here is the information you requested when filing a bug report: -Device: ALi (Bison) USB Webcam 5602 integrated into MSI GX700 notebook -Subsystem ID: I'm not sure how to find the subsystem ID in the lsusb -v output, but the Vendor ID is 0402 and the Product ID is 5602 -Environment: Ubuntu 9.04 with kernel 2.6.29-02062904-generic, 64-bit on an MSI GX700 notebook -Using the v4l-dvb driver set, installed via hg on 09/18/2009 -Dmesg output of modprobe: [ 1165.707826] gspca: main v2.7.0 registered [ 1165.710339] gspca: probing 0402:5602 [ 1165.710345] ALi m5602: Probing for a po1030 sensor [ 1165.727361] ALi m5602: Probing for a mt9m111 sensor [ 1165.748111] ALi m5602: Probing for a s5k4aa sensor [ 1165.785596] ALi m5602: Detected a s5k4aa sensor [ 1165.819979] gspca: probe ok [ 1165.820067] usbcore: registered new interface driver ALi m5602 [ 1165.820077] ALi m5602: registered -Using the NTSC TV standard -Steps to reproduce: Load the gspca_m5602 on an MSI GX700 notebook with a BIOS date of 12/02/2008 and notice that the image is vertically-flipped in V4L applications like Cheese -Bugfix: The BIOS date of 12/02/2008 needs to be added to linux/drivers/media/video/gspca/m5602/m5602_s5k4aa.c as indicated at http://linuxtv.org/hg/v4l-dvb/rev/1436152bd9db I worked around the issue by editing m5602_s5k4aa.c and changing 07/19/2007 to 12/02/2008 and re-compiling. I just wanted to submit this bug report so others with the same configuration won't have to edit the source and change it according to their BIOS date. -John Katzmaier -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] choice between MPE and ULE in the code
dvbnet contains a parameter, which lets select MPE or ULE. feedtype 0 or 1 will decide whether the filters in dvb_net will be set for ULE or MPE. Once you activate a dvb data interface you select MPE or ULE for that PID, you want to receive. Am 19.09.2009 um 02:59 schrieb Seyyed Mohammad mohammadzadeh: I have tried the ULE decapsulation part of code. you can find it in the v4l_dvb/linux/driver/media/dvb_core/dvb_net.c you must force ULE decapsulation in the code and there is no media to choose it run-time. The decapsulation code is too bogus and useless. I'm trying to write a new decapsulator based on the original code. 2009/9/18, Sylvain LESAGE : Hi, I am working on ULE (ultra-lightweight encapsulation) and MPE (multi-protocol encapsulation) decapsulation of transport stream packets. I can't find, in the code of linuxDVB, where the choice is done between ULE or MPE when parsing the packets ? Does someone has an idea ? Thank you. Sylvain LESAGE ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux- me...@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] choice between MPE and ULE in the code
Thank you very much for your answer, Seyyed... I was pretty sure there was a place in the code dedicated to this choice between MPE and ULE, but I couldn't find it. I better understand why, now. Sylvain LESAGE Seyyed Mohammad mohammadzadeh a écrit : I have tried the ULE decapsulation part of code. you can find it in the v4l_dvb/linux/driver/media/dvb_core/dvb_net.c you must force ULE decapsulation in the code and there is no media to choose it run-time. The decapsulation code is too bogus and useless. I'm trying to write a new decapsulator based on the original code. 2009/9/18, Sylvain LESAGE : Hi, I am working on ULE (ultra-lightweight encapsulation) and MPE (multi-protocol encapsulation) decapsulation of transport stream packets. I can't find, in the code of linuxDVB, where the choice is done between ULE or MPE when parsing the packets ? Does someone has an idea ? Thank you. Sylvain LESAGE ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] choice between MPE and ULE in the code
I have tried the ULE decapsulation part of code. you can find it in the v4l_dvb/linux/driver/media/dvb_core/dvb_net.c you must force ULE decapsulation in the code and there is no media to choose it run-time. The decapsulation code is too bogus and useless. I'm trying to write a new decapsulator based on the original code. 2009/9/18, Sylvain LESAGE : > Hi, > > I am working on ULE (ultra-lightweight encapsulation) and MPE > (multi-protocol encapsulation) decapsulation of transport stream > packets. I can't find, in the code of linuxDVB, where the choice is done > between ULE or MPE when parsing the packets ? > Does someone has an idea ? > > Thank you. > Sylvain LESAGE > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- 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] uvc: kmalloc failure ignored in uvc_ctrl_add_ctrl()
Produce an error if kmalloc() fails.
Signed-off-by: Roel Kluin
---
Found with sed: http://kernelnewbies.org/roelkluin
Build tested. Please review
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index c3225a5..dda80b5 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1189,7 +1189,7 @@ int uvc_ctrl_resume_device(struct uvc_device *dev)
* Control and mapping handling
*/
-static void uvc_ctrl_add_ctrl(struct uvc_device *dev,
+static int uvc_ctrl_add_ctrl(struct uvc_device *dev,
struct uvc_control_info *info)
{
struct uvc_entity *entity;
@@ -1214,7 +1214,7 @@ static void uvc_ctrl_add_ctrl(struct uvc_device *dev,
}
if (!found)
- return;
+ return 0;
if (UVC_ENTITY_TYPE(entity) == UVC_VC_EXTENSION_UNIT) {
/* Check if the device control information and length match
@@ -1231,7 +1231,7 @@ static void uvc_ctrl_add_ctrl(struct uvc_device *dev,
"control " UVC_GUID_FORMAT "/%u (%d).\n",
UVC_GUID_ARGS(info->entity), info->selector,
ret);
- return;
+ return -EINVAL;
}
if (info->size != le16_to_cpu(size)) {
@@ -1239,7 +1239,7 @@ static void uvc_ctrl_add_ctrl(struct uvc_device *dev,
"/%u size doesn't match user supplied "
"value.\n", UVC_GUID_ARGS(info->entity),
info->selector);
- return;
+ return -EINVAL;
}
ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id,
@@ -1249,7 +1249,7 @@ static void uvc_ctrl_add_ctrl(struct uvc_device *dev,
"control " UVC_GUID_FORMAT "/%u (%d).\n",
UVC_GUID_ARGS(info->entity), info->selector,
ret);
- return;
+ return -EINVAL;
}
flags = info->flags;
@@ -1259,15 +1259,18 @@ static void uvc_ctrl_add_ctrl(struct uvc_device *dev,
UVC_GUID_FORMAT "/%u flags don't match "
"supported operations.\n",
UVC_GUID_ARGS(info->entity), info->selector);
- return;
+ return -EINVAL;
}
}
ctrl->info = info;
ctrl->data = kmalloc(ctrl->info->size * UVC_CTRL_NDATA, GFP_KERNEL);
+ if (ctrl->data == NULL)
+ return -ENOMEM;
uvc_trace(UVC_TRACE_CONTROL, "Added control " UVC_GUID_FORMAT "/%u "
"to device %s entity %u\n", UVC_GUID_ARGS(ctrl->info->entity),
ctrl->info->selector, dev->udev->devpath, entity->id);
+ return 0;
}
/*
@@ -1309,8 +1312,11 @@ int uvc_ctrl_add_info(struct uvc_control_info *info)
}
}
- list_for_each_entry(dev, &uvc_driver.devices, list)
- uvc_ctrl_add_ctrl(dev, info);
+ list_for_each_entry(dev, &uvc_driver.devices, list) {
+ ret = uvc_ctrl_add_ctrl(dev, info);
+ if (ret == -ENOMEM)
+ goto end;
+ }
INIT_LIST_HEAD(&info->mappings);
list_add_tail(&info->list, &uvc_driver.controls);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] staging go7007 cleanup
Hi Everyone, Here are some patches that I've been working on for the go7007 driver. Most are whitespace cleanup and small fixes. I had previously applied these to Hans v4l-dvb-go7007 branch, and required minor changes to apply cleanly to the staging go7007 driver in v4l-dvb. I'm also working on the subdev conversion patch, but it requires a large bit of rework. Comments and review welcome. Pete Eberlein -- 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] GSPCA: kmalloc failure ignored in sd_start()
Prevent NULL dereference if kmalloc() fails. Signed-off-by: Roel Kluin --- Found with sed: http://kernelnewbies.org/roelkluin diff --git a/drivers/media/video/gspca/jeilinj.c b/drivers/media/video/gspca/jeilinj.c index dbfa3ed..a11c97e 100644 --- a/drivers/media/video/gspca/jeilinj.c +++ b/drivers/media/video/gspca/jeilinj.c @@ -312,6 +312,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ dev->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (dev->jpeg_hdr == NULL) + return -ENOMEM; jpeg_define(dev->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x21); /* JPEG 422 */ jpeg_set_qual(dev->jpeg_hdr, dev->quality); -- 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] V4L/DVB (9367): kmalloc failure ignored in lgdt3304_attach()
Prevent NULL dereference if kmalloc() fails. Signed-off-by: Roel Kluin --- Found with sed: http://kernelnewbies.org/roelkluin Build tested. diff --git a/drivers/media/dvb/frontends/lgdt3304.c b/drivers/media/dvb/frontends/lgdt3304.c index eb72a98..e334b5d 100644 --- a/drivers/media/dvb/frontends/lgdt3304.c +++ b/drivers/media/dvb/frontends/lgdt3304.c @@ -363,6 +363,8 @@ struct dvb_frontend* lgdt3304_attach(const struct lgdt3304_config *config, struct lgdt3304_state *state; state = kzalloc(sizeof(struct lgdt3304_state), GFP_KERNEL); + if (state == NULL) + return NULL; state->addr = config->i2c_address; state->i2c = i2c; diff --git a/drivers/media/dvb/frontends/s921_module.c b/drivers/media/dvb/frontends/s921_module.c index 3f5a0e1..3156b64 100644 --- a/drivers/media/dvb/frontends/s921_module.c +++ b/drivers/media/dvb/frontends/s921_module.c @@ -169,6 +169,8 @@ struct dvb_frontend* s921_attach(const struct s921_config *config, struct s921_state *state; state = kzalloc(sizeof(struct s921_state), GFP_KERNEL); + if (state == NULL) + return NULL; state->addr = config->i2c_address; state->i2c = i2c; -- 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] V4L/DVB (11380): kzalloc failure ignored in au8522_probe()
Prevent NULL dereference if kzalloc() fails.
Signed-off-by: Roel Kluin
---
Found with sed: http://kernelnewbies.org/roelkluin
Build tested.
diff --git a/drivers/media/dvb/frontends/au8522_decoder.c
b/drivers/media/dvb/frontends/au8522_decoder.c
index 9e9a755..74981ee 100644
--- a/drivers/media/dvb/frontends/au8522_decoder.c
+++ b/drivers/media/dvb/frontends/au8522_decoder.c
@@ -792,6 +792,11 @@ static int au8522_probe(struct i2c_client *client,
}
demod_config = kzalloc(sizeof(struct au8522_config), GFP_KERNEL);
+ if (demod_config == NULL) {
+ if (instance == 1)
+ kfree(state);
+ return -ENOMEM;
+ }
demod_config->demod_address = 0x8e >> 1;
state->config = demod_config;
--
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] V4L/DVB (7969): kmalloc failure ignored in m920x_firmware_download()
Prevent NULL dereference if kmalloc() fails. Signed-off-by: Roel Kluin --- Found with sed: http://kernelnewbies.org/roelkluin Build tested. diff --git a/drivers/media/dvb/dvb-usb/m920x.c b/drivers/media/dvb/dvb-usb/m920x.c index aec7a19..ef9b7be 100644 --- a/drivers/media/dvb/dvb-usb/m920x.c +++ b/drivers/media/dvb/dvb-usb/m920x.c @@ -337,6 +337,8 @@ static int m920x_firmware_download(struct usb_device *udev, const struct firmwar int i, pass, ret = 0; buff = kmalloc(65536, GFP_KERNEL); + if (buff == NULL) + return -ENOMEM; if ((ret = m920x_read(udev, M9206_FILTER, 0x0, 0x8000, read, 4)) != 0) goto done; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] go7007: Implement vidioc_g_std and vidioc_querystd
Implemented the vidio_g_std and vidio_querystd ioctls.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r c130a089bdfc -r e227a099a9f2 linux/drivers/staging/go7007/go7007-v4l2.c
--- a/linux/drivers/staging/go7007/go7007-v4l2.cFri Sep 18 10:28:27
2009 -0700
+++ b/linux/drivers/staging/go7007/go7007-v4l2.cFri Sep 18 10:37:01
2009 -0700
@@ -1110,6 +1110,24 @@
return 0;
}
+static int vidioc_g_std(struct file *file, void *priv, v4l2_std_id *std)
+{
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
+
+ switch (go->standard) {
+ case GO7007_STD_NTSC:
+ *std = V4L2_STD_NTSC;
+ break;
+ case GO7007_STD_PAL:
+ *std = V4L2_STD_PAL;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *std)
{
struct go7007 *go = ((struct go7007_file *) priv)->go;
@@ -1154,24 +1172,22 @@
return 0;
}
-#if 0 /* keep */
- case VIDIOC_QUERYSTD:
- {
- v4l2_std_id *std = arg;
+static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *std)
+{
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
- if ((go->board_info->flags & GO7007_BOARD_HAS_TUNER) &&
- go->input == go->board_info->num_inputs - 1) {
- if (!go->i2c_adapter_online)
- return -EIO;
- i2c_clients_command(&go->i2c_adapter,
- VIDIOC_QUERYSTD, arg);
- } else if (go->board_info->sensor_flags & GO7007_SENSOR_TV)
- *std = V4L2_STD_NTSC | V4L2_STD_PAL | V4L2_STD_SECAM;
- else
- *std = 0;
- return 0;
- }
-#endif
+ if ((go->board_info->flags & GO7007_BOARD_HAS_TUNER) &&
+ go->input == go->board_info->num_inputs - 1) {
+ if (!go->i2c_adapter_online)
+ return -EIO;
+ i2c_clients_command(&go->i2c_adapter, VIDIOC_QUERYSTD, std);
+ } else if (go->board_info->sensor_flags & GO7007_SENSOR_TV)
+ *std = V4L2_STD_NTSC | V4L2_STD_PAL | V4L2_STD_SECAM;
+ else
+ *std = 0;
+
+ return 0;
+}
static int vidioc_enum_input(struct file *file, void *priv,
struct v4l2_input *inp)
@@ -1768,7 +1784,9 @@
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_g_std = vidioc_g_std,
.vidioc_s_std = vidioc_s_std,
+ .vidioc_querystd = vidioc_querystd,
.vidioc_enum_input= vidioc_enum_input,
.vidioc_g_input = vidioc_g_input,
.vidioc_s_input = vidioc_s_input,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] s2250-board: Fix memory leaks
In some error cases, allocated buffers need to be freed before returning.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r e227a099a9f2 -r bf8ee230f1a0 linux/drivers/staging/go7007/s2250-board.c
--- a/linux/drivers/staging/go7007/s2250-board.cFri Sep 18 10:37:01
2009 -0700
+++ b/linux/drivers/staging/go7007/s2250-board.cFri Sep 18 10:39:03
2009 -0700
@@ -203,10 +203,13 @@
usb = go->hpi_context;
if (mutex_lock_interruptible(&usb->i2c_lock) != 0) {
printk(KERN_INFO "i2c lock failed\n");
+ kfree(buf);
return -EINTR;
}
- if (go7007_usb_vendor_request(go, 0x57, addr, val, buf, 16, 1) < 0)
+ if (go7007_usb_vendor_request(go, 0x57, addr, val, buf, 16, 1) < 0) {
+ kfree(buf);
return -EFAULT;
+ }
mutex_unlock(&usb->i2c_lock);
if (buf[0] == 0) {
@@ -214,6 +217,7 @@
subaddr = (buf[4] << 8) + buf[5];
val_read = (buf[2] << 8) + buf[3];
+ kfree(buf);
if (val_read != val) {
printk(KERN_INFO "invalid fp write %x %x\n",
val_read, val);
@@ -224,8 +228,10 @@
subaddr, addr);
return -EFAULT;
}
- } else
+ } else {
+ kfree(buf);
return -EFAULT;
+ }
/* save last 12b value */
if (addr == 0x12b)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] go7007: Merge struct gofh and go declarations
The declarations for struct go7007_file *gofh and struct go7007 *go can
be merged when gofh isn't used by the function.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r e9801d1d9c6c -r c130a089bdfc linux/drivers/staging/go7007/go7007-v4l2.c
--- a/linux/drivers/staging/go7007/go7007-v4l2.cFri Sep 18 10:26:12
2009 -0700
+++ b/linux/drivers/staging/go7007/go7007-v4l2.cFri Sep 18 10:28:27
2009 -0700
@@ -593,8 +593,7 @@
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
strlcpy(cap->driver, "go7007", sizeof(cap->driver));
strlcpy(cap->card, go->name, sizeof(cap->card));
@@ -641,8 +640,7 @@
static int vidioc_g_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *fmt)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
fmt->fmt.pix.width = go->width;
@@ -660,8 +658,7 @@
static int vidioc_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *fmt)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
return set_capture_size(go, fmt, 1);
}
@@ -669,8 +666,7 @@
static int vidioc_s_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *fmt)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
if (go->streaming)
return -EBUSY;
@@ -976,8 +972,7 @@
static int vidioc_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *query)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
if (!go->i2c_adapter_online)
return -EIO;
@@ -990,8 +985,7 @@
static int vidioc_g_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
struct v4l2_queryctrl query;
if (!go->i2c_adapter_online)
@@ -1010,8 +1004,7 @@
static int vidioc_s_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
struct v4l2_queryctrl query;
if (!go->i2c_adapter_online)
@@ -1030,8 +1023,7 @@
static int vidioc_g_parm(struct file *filp, void *priv,
struct v4l2_streamparm *parm)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
struct v4l2_fract timeperframe = {
.numerator = 1001 * go->fps_scale,
.denominator = go->sensor_framerate,
@@ -1049,8 +1041,7 @@
static int vidioc_s_parm(struct file *filp, void *priv,
struct v4l2_streamparm *parm)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
unsigned int n, d;
if (parm->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
@@ -1082,8 +1073,7 @@
static int vidioc_enum_framesizes(struct file *filp, void *priv,
struct v4l2_frmsizeenum *fsize)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
/* Return -EINVAL, if it is a TV board */
if ((go->board_info->flags & GO7007_BOARD_HAS_TUNER) ||
@@ -1103,8 +1093,7 @@
static int vidioc_enum_frameintervals(struct file *filp, void *priv,
struct v4l2_frmivalenum *fival)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
/* Return -EINVAL, if it is a TV board */
if ((go->board_info->flags & GO7007_BOARD_HAS_TUNER) ||
@@ -1123,8 +1112,7 @@
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *std)
{
- struct go7007_file *gofh = priv;
- struct go7007 *go = gofh->go;
+ struct go7007 *go = ((struct go7007_file *) priv)->go;
if (go->streaming)
return -EBUSY;
@@ -1188,8 +1176,7 @@
static int vidioc_enum_input(struct file *file, void *priv,
struct v4l2_
[PATCH 1/9] go7007: Updates to Kconfig and Makefile
Replace "wierd device" with accurate descriptions. Add menu options and makefile lines for the i2c modules. Added comment about why dvb-usb is included. Added include sound/config.h for Ubuntu 8.04 distro kernel. Priority: normal Signed-off-by: Pete Eberlein diff -r ae90c0408d70 -r a54a706244cf linux/drivers/staging/go7007/Kconfig --- a/linux/drivers/staging/go7007/Kconfig Fri Sep 18 00:49:59 2009 -0300 +++ b/linux/drivers/staging/go7007/Kconfig Fri Sep 18 11:16:14 2009 -0700 @@ -1,5 +1,5 @@ config VIDEO_GO7007 - tristate "Go 7007 support" + tristate "WIS GO7007 MPEG encoder support" depends on VIDEO_DEV && PCI && I2C && INPUT depends on SND select VIDEOBUF_DMA_SG @@ -10,17 +10,19 @@ select CRC32 default N ---help--- - This is a video4linux driver for some weird device... + This is a video4linux driver for the WIS GO7007 MPEG + encoder chip. To compile this driver as a module, choose M here: the module will be called go7007 config VIDEO_GO7007_USB - tristate "Go 7007 USB support" + tristate "WIS GO7007 USB support" depends on VIDEO_GO7007 && USB default N ---help--- - This is a video4linux driver for some weird device... + This is a video4linux driver for the WIS GO7007 MPEG + encoder chip over USB. To compile this driver as a module, choose M here: the module will be called go7007-usb @@ -30,8 +32,78 @@ depends on VIDEO_GO7007_USB && DVB_USB default N ---help--- - This is a video4linux driver for the Sensoray 2250/2251 device + This is a video4linux driver for the Sensoray 2250/2251 device. To compile this driver as a module, choose M here: the - module will be called s2250-board + module will be called s2250 +config VIDEO_GO7007_OV7640 + tristate "OV7640 subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the OV7640 sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-ov7640 + +config VIDEO_GO7007_SAA7113 + tristate "SAA7113 subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the SAA7113 sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-saa7113 + +config VIDEO_GO7007_SAA7115 + tristate "SAA7115 subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the SAA7115 sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-saa7115 + +config VIDEO_GO7007_TW9903 + tristate "TW9903 subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the TW9903 sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-tw9903 + +config VIDEO_GO7007_UDA1342 + tristate "UDA1342 subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the UDA1342 sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-uda1342 + +config VIDEO_GO7007_SONY_TUNER + tristate "Sony tuner subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the Sony Tuner sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-sony-tuner + +config VIDEO_GO7007_TW2804 + tristate "TW2804 subdev support" + depends on VIDEO_GO7007 + default N + ---help--- + This is a video4linux driver for the TW2804 sub-device. + + To compile this driver as a module, choose M here: the + module will be called wis-tw2804 + diff -r ae90c0408d70 -r a54a706244cf linux/drivers/staging/go7007/Makefile --- a/linux/drivers/staging/go7007/Makefile Fri Sep 18 00:49:59 2009 -0300 +++ b/linux/drivers/staging/go7007/Makefile Fri Sep 18 11:16:14 2009 -0700 @@ -6,22 +6,34 @@ obj-$(CONFIG_VIDEO_GO7007) += go7007.o obj-$(CONFIG_VIDEO_GO7007_USB) += go7007-usb.o obj-$(CONFIG_VIDEO_GO7007_USB_S2250_BOARD) += s2250.o +obj-$(CONFIG_VIDEO_GO7007_SAA7113) += wis-saa7113.o +obj-$(CONFIG_VIDEO_GO7007_OV7640) += wis-ov7640.o +obj-$(CONFIG_VIDEO_GO7007_SAA7115) += wis-saa7115.o +obj-$(CONFIG_VIDEO_GO7007_TW9903) += wis-tw9903.o +obj-$(CONFIG_VIDEO_GO7007_UDA1342) += wis-uda1342.o +obj-$(CONFIG_VIDEO_GO7007_SONY_TUNER) += wis-sony-tuner.o +obj-$(CONFIG_VIDEO_GO7007_TW2804) += wis-tw2804.o go7007-objs += go7007-v4l2.o go7007-driver.o go7007-i2c.o go7007-fw.o \ -
Re: [PATCH 1/2] Add the DTV_ISDB_TS_ID property for ISDB_S
Em Sun, 23 Aug 2009 12:49:49 +0900 hiranot...@zng.jp escreveu: > > Add the DTV_ISDB_TS_ID property for ISDB-S > > In ISDB-S, time-devision duplex is used to multiplexing several waves > in the same frequency. Each wave is identified by its own transport > stream ID, or TS ID. We need to provide some way to specify this ID > from user applications to handle ISDB-S frontends. > > This code has been tested with the Earthsoft PT1 driver. Committed, thanks. I had to fix a merge conflict with the ISDB-T API additions. > + u32 isdb_ts_id; > +#define DTV_ISDB_TS_ID 41 I also added an "s" after ISDB to use the same name convention used on other API functions. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb: add driver for 774 Friio White USB ISDB-T receiver
Em Tue, 25 Aug 2009 14:39:51 +0900 Akihiro TSUKADA escreveu: > From: Akihiro Tsukada > > This patch adds driver for 774 Friio White, ISDB-T USB receiver > > Friio White is an USB 2.0 ISDB-T receiver. (http://www.friio.com/) > The device has a GL861 chip and a Comtech JDVBT90502 canned tuner module. > This driver ignores all the frontend_parameters except frequency, > as ISDB-T shares the same parameter configuration across the country > and thus the device can work like an intelligent one. > > As this device does not include a CAM nor hardware descrambling feature, > the driver passes through scrambled TS streams. > > There is Friio Black, a variant for ISDB-S, which shares the same USB > Vendor/Product ID with White, but it is not supported in this driver. > They should be identified in the initialization sequence, > but this feature is not tested. > Committed, thanks. It would be good if you could add support for ISDB-T API [1] at the driver. [1] http://linuxtv.org/downloads/v4l-dvb-apis/ch09s03.html Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add a driver for Earthsoft PT1
Em Sun, 23 Aug 2009 12:51:22 +0900 hiranot...@zng.jp escreveu: > > Add a driver for Earthsoft PT1 > > Eearthsoft PT1 is a PCI card for Japanese broadcasting with two ISDB-S > and ISDB-T demodulators. > > This card has neither MPEG decoder nor conditional access module > onboard. It transmits only compressed and possibly encrypted MPEG data > over the PCI bus, so you need an external software decoder and a > decrypter to watch TV on your computer. > > This driver is originally developed by Tomoaki Ishikawa > by reverse engineering. > Committed, thanks. Please take a look at the ISDB-T API recently added. It would be good to support it on all ISDB-T drivers: http://linuxtv.org/downloads/v4l-dvb-apis/ch09s03.html Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/1] video: initial support for ADV7180
From: Richard Röjfors
This is an initial driver for Analog Devices ADV7180 Video Decoder.
So far it only supports query standard.
[a...@linux-foundation.org: remove unneeded cast]
Signed-off-by: Richard Röjfors
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Signed-off-by: Andrew Morton
---
drivers/media/video/Kconfig |9 +
drivers/media/video/Makefile|1
drivers/media/video/adv7180.c | 202 ++
include/media/v4l2-chip-ident.h |3
4 files changed, 215 insertions(+)
diff -puN drivers/media/video/Kconfig~video-initial-support-for-adv7180
drivers/media/video/Kconfig
--- a/drivers/media/video/Kconfig~video-initial-support-for-adv7180
+++ a/drivers/media/video/Kconfig
@@ -265,6 +265,15 @@ config VIDEO_SAA6588
comment "Video decoders"
+config VIDEO_ADV7180
+ tristate "Analog Devices ADV7180 decoder"
+ depends on VIDEO_V4L2 && I2C
+ ---help---
+ Support for the Analog Devices ADV7180 video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7180.
+
config VIDEO_BT819
tristate "BT819A VideoStream decoder"
depends on VIDEO_V4L2 && I2C
diff -puN drivers/media/video/Makefile~video-initial-support-for-adv7180
drivers/media/video/Makefile
--- a/drivers/media/video/Makefile~video-initial-support-for-adv7180
+++ a/drivers/media/video/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
+obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff -puN /dev/null drivers/media/video/adv7180.c
--- /dev/null
+++ a/drivers/media/video/adv7180.c
@@ -0,0 +1,202 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "adv7180"
+
+#define ADV7180_INPUT_CONTROL_REG 0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM 0x00
+#define ADV7180_AUTODETECT_ENABLE_REG 0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60 0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G 0x40
+#define ADV7180_STATUS1_AUTOD_SECAM0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_5250x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+struct adv7180_state {
+ struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+ u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+ switch (status1 & ADV7180_STATUS1_AUTOD_MASK) {
+ case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+ return V4L2_STD_NTSC_M_JP;
+ case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+ return V4L2_STD_NTSC_443;
+ case ADV7180_STATUS1_AUTOD_PAL_M:
+ return V4L2_STD_PAL_M;
+ case ADV7180_STATUS1_AUTOD_PAL_60:
+ return V4L2_STD_PAL_60;
+ case ADV7180_STATUS1_AUTOD_PAL_B_G:
+ return V4L2_STD_PAL;
+ case ADV7180_STATUS1_AUTOD_SECAM:
+ return V4L2_STD_SECAM;
+ case ADV7180_STATUS1_AUTOD_PAL_COMB:
+ return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+ case ADV7180_STATUS1_AUTOD_SECAM_525:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ *std = determine_norm(client);
+ return 0;
+}
+
+static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ struct i2c_client *clie
Re: Incorrectly detected em28xx device
2009/9/18 Matthias Bläsing : > Hey David, > > thanks for this very fast reply. > > Am Freitag, den 18.09.2009, 15:01 -0400 schrieb Devin Heitmueller: >> 2009/9/18 Matthias Bläsing : >> > Hello, >> > >> > when I plugin my usb video grabber, it is misdetected (this email is the >> > reaction to the request in the module output): >> > >> > [Syslog Entries] >> > > >> The correct functionality can be accessed, when explicitly called with >> > card=35 as paramter: >> > >> > [Syslog Entries] >> > >> > It would be very nice, if this could be auto-detected. If you need more >> > information, please CC me. >> > >> > Greetings >> > >> > Matthias >> >> Hi Matthias, >> >> I fixed this a couple of months ago. Just update to the latest v4l-dvb tree. > > > will/was this be merged to the mainline kernel? I'm currently running > the ubuntu build of 2.6.30 and am about to switch to 2.6.31. > > Thanks for the information so far. > > Matthias It went into v4l-dvb on June 6th, and was submitted upstream to Linus for 2.6.31 on June 16th. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] s2250-board: Implement brightness and contrast controls
The brightness and contrast controls were added to the Sensoray 2250 device.
A read register function was added to set the correct bit fields.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r bf8ee230f1a0 -r beaab56c3599 linux/drivers/staging/go7007/s2250-board.c
--- a/linux/drivers/staging/go7007/s2250-board.cFri Sep 18 10:39:03
2009 -0700
+++ b/linux/drivers/staging/go7007/s2250-board.cFri Sep 18 10:40:54
2009 -0700
@@ -112,7 +112,7 @@
};
struct s2250 {
- int std;
+ v4l2_std_id std;
int input;
int brightness;
int contrast;
@@ -240,6 +240,45 @@
return 0;
}
+static int read_reg_fp(struct i2c_client *client, u16 addr, u16 *val)
+{
+ struct go7007 *go = i2c_get_adapdata(client->adapter);
+ struct go7007_usb *usb;
+ u8 *buf;
+
+ if (go == NULL)
+ return -ENODEV;
+
+ if (go->status == STATUS_SHUTDOWN)
+ return -EBUSY;
+
+ buf = kzalloc(16, GFP_KERNEL);
+
+ if (buf == NULL)
+ return -ENOMEM;
+
+
+
+ memset(buf, 0xcd, 6);
+ usb = go->hpi_context;
+ if (down_interruptible(&usb->i2c_lock) != 0) {
+ printk(KERN_INFO "i2c lock failed\n");
+ kfree(buf);
+ return -EINTR;
+ }
+ if (go7007_usb_vendor_request(go, 0x58, addr, 0, buf, 16, 1) < 0) {
+ kfree(buf);
+ return -EFAULT;
+ }
+ up(&usb->i2c_lock);
+
+ *val = (buf[0] << 8) | buf[1];
+ kfree(buf);
+
+ return 0;
+}
+
+
static int write_regs(struct i2c_client *client, u8 *regs)
{
int i;
@@ -354,14 +393,42 @@
{
struct v4l2_control *ctrl = arg;
int value1;
+ u16 oldvalue;
switch (ctrl->id) {
case V4L2_CID_BRIGHTNESS:
- printk(KERN_INFO "s2250: future setting\n");
- return -EINVAL;
+ if (ctrl->value > 100)
+ dec->brightness = 100;
+ else if (ctrl->value < 0)
+ dec->brightness = 0;
+ else
+ dec->brightness = ctrl->value;
+ value1 = (dec->brightness - 50) * 255 / 100;
+ read_reg_fp(client, VPX322_ADDR_BRIGHTNESS0, &oldvalue);
+ write_reg_fp(client, VPX322_ADDR_BRIGHTNESS0,
+value1 | (oldvalue & ~0xff));
+ read_reg_fp(client, VPX322_ADDR_BRIGHTNESS1, &oldvalue);
+ write_reg_fp(client, VPX322_ADDR_BRIGHTNESS1,
+value1 | (oldvalue & ~0xff));
+ write_reg_fp(client, 0x140, 0x60);
+ break;
case V4L2_CID_CONTRAST:
- printk(KERN_INFO "s2250: future setting\n");
- return -EINVAL;
+ if (ctrl->value > 100)
+ dec->contrast = 100;
+ else if (ctrl->value < 0)
+ dec->contrast = 0;
+ else
+ dec->contrast = ctrl->value;
+ value1 = dec->contrast * 0x40 / 100;
+ if (value1 > 0x3f)
+ value1 = 0x3f; /* max */
+ read_reg_fp(client, VPX322_ADDR_CONTRAST0, &oldvalue);
+ write_reg_fp(client, VPX322_ADDR_CONTRAST0,
+value1 | (oldvalue & ~0x3f));
+ read_reg_fp(client, VPX322_ADDR_CONTRAST1, &oldvalue);
+ write_reg_fp(client, VPX322_ADDR_CONTRAST1,
+value1 | (oldvalue & ~0x3f));
+ write_reg_fp(client, 0x140, 0x60);
break;
case V4L2_CID_SATURATION:
if (ctrl->value > 127)
--
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: Incorrectly detected em28xx device
2009/9/18 Matthias Bläsing : > Hello, > > when I plugin my usb video grabber, it is misdetected (this email is the > reaction to the request in the module output): > > Sep 18 20:27:19 prometheus kernel: [15016.458509] em28xx: New device @ 480 > Mbps (eb1a:2860, interface 0, class 0) > Sep 18 20:27:19 prometheus kernel: [15016.458516] em28xx #0: Identified as > Unknown EM2750/28xx video grabber (card=1) > Sep 18 20:27:19 prometheus kernel: [15016.458563] em28xx #0: chip ID is em2860 > Sep 18 20:27:19 prometheus kernel: [15016.548934] em28xx #0: board has no > eeprom > Sep 18 20:27:19 prometheus kernel: [15016.562331] em28xx #0: found i2c device > @ 0x4a [saa7113h] > Sep 18 20:27:19 prometheus kernel: [15016.595202] em28xx #0: Your board has > no unique USB ID. > Sep 18 20:27:19 prometheus kernel: [15016.595207] em28xx #0: A hint were > successfully done, based on i2c devicelist hash. > Sep 18 20:27:19 prometheus kernel: [15016.595209] em28xx #0: This method is > not 100% failproof. > Sep 18 20:27:19 prometheus kernel: [15016.595210] em28xx #0: If the board > were missdetected, please email this log to: > Sep 18 20:27:19 prometheus kernel: [15016.595212] em28xx #0: ^IV4L Mailing > List > Sep 18 20:27:19 prometheus kernel: [15016.595214] em28xx #0: Board detected > as PointNix Intra-Oral Camera > Sep 18 20:27:19 prometheus kernel: [15016.595217] em28xx #0: Registering > snapshot button... > Sep 18 20:27:19 prometheus kernel: [15016.595289] input: em28xx snapshot > button as /devices/pci:00/:00:1a.7/usb1/1-5/1-5.4/input/input19 > Sep 18 20:27:20 prometheus kernel: [15016.980420] saa7115 0-0025: saa7113 > found (1f7113d0e10) @ 0x4a (em28xx #0) > Sep 18 20:27:21 prometheus kernel: [15017.696774] em28xx #0: Config register > raw data: 0x00 > Sep 18 20:27:21 prometheus kernel: [15017.696777] em28xx #0: No AC97 audio > processor > Sep 18 20:27:21 prometheus kernel: [15017.796516] em28xx #0: v4l2 driver > version 0.1.2 > Sep 18 20:27:21 prometheus kernel: [15018.076600] em28xx #0: V4L2 device > registered as /dev/video1 and /dev/vbi0 > Sep 18 20:27:21 prometheus kernel: [15018.076630] usbcore: registered new > interface driver em28xx > Sep 18 20:27:21 prometheus kernel: [15018.076633] em28xx driver loaded > > The correct functionality can be accessed, when explicitly called with > card=35 as paramter: > > [ 1014.939536] em28xx: New device @ 480 Mbps (eb1a:2860, interface 0, class 0) > [ 1014.939549] em28xx #0: Identified as Typhoon DVD Maker (card=35) > [ 1014.939734] em28xx #0: chip ID is em2860 > [ 1015.029084] em28xx #0: board has no eeprom > [ 1015.393031] saa7115 0-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx > #0) > [ 1016.100782] em28xx #0: Config register raw data: 0x00 > [ 1016.100789] em28xx #0: No AC97 audio processor > [ 1016.204578] em28xx #0: v4l2 driver version 0.1.2 > [ 1016.484275] em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 > > It would be very nice, if this could be auto-detected. If you need more > information, please CC me. > > Greetings > > Matthias Hi Matthias, I fixed this a couple of months ago. Just update to the latest v4l-dvb tree. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] go7007: convert printks to v4l2_info
Use v4l2_info and v4l2_err where appropriate.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r beaab56c3599 -r 1cb2c7d3fa12
linux/drivers/staging/go7007/go7007-driver.c
--- a/linux/drivers/staging/go7007/go7007-driver.c Fri Sep 18 10:40:54
2009 -0700
+++ b/linux/drivers/staging/go7007/go7007-driver.c Fri Sep 18 10:59:26
2009 -0700
@@ -49,7 +49,7 @@
go->hpi_ops->read_interrupt(go);
if (wait_event_timeout(go->interrupt_waitq,
go->interrupt_available, 5*HZ) < 0) {
- printk(KERN_ERR "go7007: timeout waiting for read interrupt\n");
+ v4l2_err(go->video_dev, "timeout waiting for read interrupt\n");
return -1;
}
if (!go->interrupt_available)
@@ -97,13 +97,12 @@
u16 intr_val, intr_data;
if (request_firmware(&fw_entry, fw_name, go->dev)) {
- printk(KERN_ERR
- "go7007: unable to load firmware from file \"%s\"\n",
- fw_name);
+ v4l2_err(go, "unable to load firmware from file "
+ "\"%s\"\n", fw_name);
return -1;
}
if (fw_entry->size < 16 || memcmp(fw_entry->data, "WISGO7007FW", 11)) {
- printk(KERN_ERR "go7007: file \"%s\" does not appear to be "
+ v4l2_err(go, "file \"%s\" does not appear to be "
"go7007 firmware\n", fw_name);
release_firmware(fw_entry);
return -1;
@@ -111,7 +110,7 @@
fw_len = fw_entry->size - 16;
bounce = kmalloc(fw_len, GFP_KERNEL);
if (bounce == NULL) {
- printk(KERN_ERR "go7007: unable to allocate %d bytes for "
+ v4l2_err(go, "unable to allocate %d bytes for "
"firmware transfer\n", fw_len);
release_firmware(fw_entry);
return -1;
@@ -122,7 +121,7 @@
go7007_send_firmware(go, bounce, fw_len) < 0 ||
go7007_read_interrupt(go, &intr_val, &intr_data) < 0 ||
(intr_val & ~0x1) != 0x5a5a) {
- printk(KERN_ERR "go7007: error transferring firmware\n");
+ v4l2_err(go, "error transferring firmware\n");
rv = -1;
}
kfree(bounce);
@@ -316,7 +315,7 @@
if (go7007_send_firmware(go, fw, fw_len) < 0 ||
go7007_read_interrupt(go, &intr_val, &intr_data) < 0) {
- printk(KERN_ERR "go7007: error transferring firmware\n");
+ v4l2_err(go->video_dev, "error transferring firmware\n");
rv = -1;
goto start_error;
}
@@ -325,7 +324,7 @@
go->parse_length = 0;
go->seen_frame = 0;
if (go7007_stream_start(go) < 0) {
- printk(KERN_ERR "go7007: error starting stream transfer\n");
+ v4l2_err(go->video_dev, "error starting stream transfer\n");
rv = -1;
goto start_error;
}
@@ -421,7 +420,7 @@
for (i = 0; i < length; ++i) {
if (go->active_buf != NULL &&
go->active_buf->bytesused >= GO7007_BUF_SIZE - 3) {
- printk(KERN_DEBUG "go7007: dropping oversized frame\n");
+ v4l2_info(go->video_dev, "dropping oversized frame\n");
go->active_buf->offset -= go->active_buf->bytesused;
go->active_buf->bytesused = 0;
go->active_buf->modet_active = 0;
@@ -669,8 +668,8 @@
if (i2c_del_adapter(&go->i2c_adapter) == 0)
go->i2c_adapter_online = 0;
else
- printk(KERN_ERR
- "go7007: error removing I2C adapter!\n");
+ v4l2_err(go->video_dev,
+ "error removing I2C adapter!\n");
}
if (go->audio_enabled)
--
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/Terratec usb id mixup in hg 12889
With latest hg (12994), my "Leadtek Winfast DTV Dongle (STK7700P based)" (0413:6f01) gets detected as a "Terratec Cinergy T USB XXS (HD)". I think "&dib0700_usb_id_table[34]" (the leadtek) got moved by mistake, but "&dib0700_usb_id_table[33]" (a terratec) should have been moved instead (in changeset 12889). hg 12889: http://linuxtv.org/hg/v4l-dvb/rev/cec94ceb4f54 Send instant messages to your online friends http://uk.messenger.yahoo.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
Incorrectly detected em28xx device
Hello, when I plugin my usb video grabber, it is misdetected (this email is the reaction to the request in the module output): Sep 18 20:27:19 prometheus kernel: [15016.458509] em28xx: New device @ 480 Mbps (eb1a:2860, interface 0, class 0) Sep 18 20:27:19 prometheus kernel: [15016.458516] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) Sep 18 20:27:19 prometheus kernel: [15016.458563] em28xx #0: chip ID is em2860 Sep 18 20:27:19 prometheus kernel: [15016.548934] em28xx #0: board has no eeprom Sep 18 20:27:19 prometheus kernel: [15016.562331] em28xx #0: found i2c device @ 0x4a [saa7113h] Sep 18 20:27:19 prometheus kernel: [15016.595202] em28xx #0: Your board has no unique USB ID. Sep 18 20:27:19 prometheus kernel: [15016.595207] em28xx #0: A hint were successfully done, based on i2c devicelist hash. Sep 18 20:27:19 prometheus kernel: [15016.595209] em28xx #0: This method is not 100% failproof. Sep 18 20:27:19 prometheus kernel: [15016.595210] em28xx #0: If the board were missdetected, please email this log to: Sep 18 20:27:19 prometheus kernel: [15016.595212] em28xx #0: ^IV4L Mailing List Sep 18 20:27:19 prometheus kernel: [15016.595214] em28xx #0: Board detected as PointNix Intra-Oral Camera Sep 18 20:27:19 prometheus kernel: [15016.595217] em28xx #0: Registering snapshot button... Sep 18 20:27:19 prometheus kernel: [15016.595289] input: em28xx snapshot button as /devices/pci:00/:00:1a.7/usb1/1-5/1-5.4/input/input19 Sep 18 20:27:20 prometheus kernel: [15016.980420] saa7115 0-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) Sep 18 20:27:21 prometheus kernel: [15017.696774] em28xx #0: Config register raw data: 0x00 Sep 18 20:27:21 prometheus kernel: [15017.696777] em28xx #0: No AC97 audio processor Sep 18 20:27:21 prometheus kernel: [15017.796516] em28xx #0: v4l2 driver version 0.1.2 Sep 18 20:27:21 prometheus kernel: [15018.076600] em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 Sep 18 20:27:21 prometheus kernel: [15018.076630] usbcore: registered new interface driver em28xx Sep 18 20:27:21 prometheus kernel: [15018.076633] em28xx driver loaded The correct functionality can be accessed, when explicitly called with card=35 as paramter: [ 1014.939536] em28xx: New device @ 480 Mbps (eb1a:2860, interface 0, class 0) [ 1014.939549] em28xx #0: Identified as Typhoon DVD Maker (card=35) [ 1014.939734] em28xx #0: chip ID is em2860 [ 1015.029084] em28xx #0: board has no eeprom [ 1015.393031] saa7115 0-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) [ 1016.100782] em28xx #0: Config register raw data: 0x00 [ 1016.100789] em28xx #0: No AC97 audio processor [ 1016.204578] em28xx #0: v4l2 driver version 0.1.2 [ 1016.484275] em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 It would be very nice, if this could be auto-detected. If you need more information, please CC me. Greetings Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Sep 18 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12994:ae90c0408d70 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] go7007: sound needs compat.h
Adding include "compat.h" Priority: normal Signed-off-by: Pete Eberlein diff -r 1cb2c7d3fa12 -r c0babe3ffa70 linux/drivers/staging/go7007/snd-go7007.c --- a/linux/drivers/staging/go7007/snd-go7007.c Fri Sep 18 10:59:26 2009 -0700 +++ b/linux/drivers/staging/go7007/snd-go7007.c Fri Sep 18 11:02:41 2009 -0700 @@ -29,6 +29,7 @@ #include #include #include +#include "compat.h" #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] go7007: Fix mpeg controls
MPEG controls were disabled by Mauro's ioctl conversion patch. They are now
re-enabled and cleaned up.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r 19c623143852 -r e9801d1d9c6c linux/drivers/staging/go7007/go7007-v4l2.c
--- a/linux/drivers/staging/go7007/go7007-v4l2.cFri Sep 18 10:22:27
2009 -0700
+++ b/linux/drivers/staging/go7007/go7007-v4l2.cFri Sep 18 10:26:12
2009 -0700
@@ -383,13 +383,10 @@
}
return 0;
}
+#endif
-static int mpeg_queryctrl(u32 id, struct v4l2_queryctrl *ctrl)
+static int mpeg_queryctrl(struct v4l2_queryctrl *ctrl)
{
- static const u32 user_ctrls[] = {
- V4L2_CID_USER_CLASS,
- 0
- };
static const u32 mpeg_ctrls[] = {
V4L2_CID_MPEG_CLASS,
V4L2_CID_MPEG_STREAM_TYPE,
@@ -401,26 +398,15 @@
0
};
static const u32 *ctrl_classes[] = {
- user_ctrls,
mpeg_ctrls,
NULL
};
- /* The ctrl may already contain the queried i2c controls,
-* query the mpeg controls if the existing ctrl id is
-* greater than the next mpeg ctrl id.
-*/
- id = v4l2_ctrl_next(ctrl_classes, id);
- if (id >= ctrl->id && ctrl->name[0])
- return 0;
-
- memset(ctrl, 0, sizeof(*ctrl));
- ctrl->id = id;
+ ctrl->id = v4l2_ctrl_next(ctrl_classes, ctrl->id);
switch (ctrl->id) {
- case V4L2_CID_USER_CLASS:
case V4L2_CID_MPEG_CLASS:
- return v4l2_ctrl_query_fill_std(ctrl);
+ return v4l2_ctrl_query_fill(ctrl, 0, 0, 0, 0);
case V4L2_CID_MPEG_STREAM_TYPE:
return v4l2_ctrl_query_fill(ctrl,
V4L2_MPEG_STREAM_TYPE_MPEG2_DVD,
@@ -437,20 +423,21 @@
V4L2_MPEG_VIDEO_ASPECT_16x9, 1,
V4L2_MPEG_VIDEO_ASPECT_1x1);
case V4L2_CID_MPEG_VIDEO_GOP_SIZE:
+ return v4l2_ctrl_query_fill(ctrl, 0, 34, 1, 15);
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
- return v4l2_ctrl_query_fill_std(ctrl);
+ return v4l2_ctrl_query_fill(ctrl, 0, 1, 1, 0);
case V4L2_CID_MPEG_VIDEO_BITRATE:
return v4l2_ctrl_query_fill(ctrl,
64000,
1000, 1,
- 980);
+ 150);
default:
- break;
+ return -EINVAL;
}
- return -EINVAL;
+ return 0;
}
-static int mpeg_s_control(struct v4l2_control *ctrl, struct go7007 *go)
+static int mpeg_s_ctrl(struct v4l2_control *ctrl, struct go7007 *go)
{
/* pretty sure we can't change any of these while streaming */
if (go->streaming)
@@ -528,6 +515,8 @@
}
break;
case V4L2_CID_MPEG_VIDEO_GOP_SIZE:
+ if (ctrl->value < 0 || ctrl->value > 34)
+ return -EINVAL;
go->gop_size = ctrl->value;
break;
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
@@ -547,7 +536,7 @@
return 0;
}
-static int mpeg_g_control(struct v4l2_control *ctrl, struct go7007 *go)
+static int mpeg_g_ctrl(struct v4l2_control *ctrl, struct go7007 *go)
{
switch (ctrl->id) {
case V4L2_CID_MPEG_STREAM_TYPE:
@@ -600,7 +589,6 @@
}
return 0;
}
-#endif
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
@@ -996,7 +984,7 @@
i2c_clients_command(&go->i2c_adapter, VIDIOC_QUERYCTRL, query);
- return (!query->name[0]) ? -EINVAL : 0;
+ return (!query->name[0]) ? mpeg_queryctrl(query) : 0;
}
static int vidioc_g_ctrl(struct file *file, void *priv,
@@ -1013,7 +1001,7 @@
query.id = ctrl->id;
i2c_clients_command(&go->i2c_adapter, VIDIOC_QUERYCTRL, &query);
if (query.name[0] == 0)
- return -EINVAL;
+ return mpeg_g_ctrl(ctrl, go);
i2c_clients_command(&go->i2c_adapter, VIDIOC_G_CTRL, ctrl);
return 0;
@@ -1033,7 +1021,7 @@
query.id = ctrl->id;
i2c_clients_command(&go->i2c_adapter, VIDIOC_QUERYCTRL, &query);
if (query.name[0] == 0)
- return -EINVAL;
+ return mpeg_s_ctrl(ctrl, go);
i2c_clients_command(&go->i2c_adapter, VIDIOC_S_CTRL, ctrl);
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] go7007: Fix whitespace and line lengths
Trailing whitespace is removed.
Source lines wrap at 80 columns.
Priority: normal
Signed-off-by: Pete Eberlein
diff -r 17bd971b5c53 -r 19c623143852 linux/drivers/staging/go7007/go7007-usb.c
--- a/linux/drivers/staging/go7007/go7007-usb.c Fri Sep 18 09:42:18 2009 -0700
+++ b/linux/drivers/staging/go7007/go7007-usb.c Fri Sep 18 10:22:27 2009 -0700
@@ -33,7 +33,8 @@
static unsigned int assume_endura;
module_param(assume_endura, int, 0644);
-MODULE_PARM_DESC(assume_endura, "when probing fails, hardware is a Pelco
Endura");
+MODULE_PARM_DESC(assume_endura, "when probing fails, "
+ "hardware is a Pelco Endura");
/* #define GO7007_USB_DEBUG */
/* #define GO7007_I2C_DEBUG */ /* for debugging the EZ-USB I2C adapter */
@@ -44,12 +45,12 @@
/*
* Pipes on EZ-USB interface:
- * 0 snd - Control
- * 0 rcv - Control
- * 2 snd - Download firmware (control)
- * 4 rcv - Read Interrupt (interrupt)
- * 6 rcv - Read Video (bulk)
- * 8 rcv - Read Audio (bulk)
+ * 0 snd - Control
+ * 0 rcv - Control
+ * 2 snd - Download firmware (control)
+ * 4 rcv - Read Interrupt (interrupt)
+ * 6 rcv - Read Video (bulk)
+ * 8 rcv - Read Audio (bulk)
*/
#define GO7007_USB_EZUSB (1<<0)
@@ -97,7 +98,7 @@
},
},
.num_inputs = 2,
- .inputs = {
+ .inputs = {
{
.video_input= 0,
.name = "Composite",
@@ -134,7 +135,7 @@
},
},
.num_inputs = 2,
- .inputs = {
+ .inputs = {
{
.video_input= 0,
.name = "Composite",
@@ -172,7 +173,7 @@
},
},
.num_inputs = 2,
- .inputs = {
+ .inputs = {
{
.video_input= 1,
/* .audio_input= AUDIO_EXTERN, */
@@ -228,7 +229,7 @@
},
},
.num_inputs = 3,
- .inputs = {
+ .inputs = {
{
.video_input= 1,
.audio_input= TVAUDIO_INPUT_EXTERN,
@@ -276,7 +277,7 @@
},
},
.num_inputs = 1,
- .inputs = {
+ .inputs = {
{
.name = "Camera",
},
@@ -309,7 +310,7 @@
},
},
.num_inputs = 2,
- .inputs = {
+ .inputs = {
{
.video_input= 2,
.name = "Composite",
@@ -341,7 +342,7 @@
GO7007_SENSOR_SCALING,
.num_i2c_devs= 0,
.num_inputs = 1,
- .inputs = {
+ .inputs = {
{
.video_input= 0,
.name = "Composite",
@@ -367,7 +368,7 @@
.sensor_h_offset = 8,
.num_i2c_devs= 0,
.num_inputs = 1,
- .inputs = {
+ .inputs = {
{
.name = "Camera",
},
@@ -399,7 +400,7 @@
},
},
.num_inputs = 1,
- .inputs = {
+ .inputs = {
{
.name = "Composite",
},
@@ -430,7 +431,7 @@
},
},
.num_inputs = 2,
- .inputs = {
+ .inputs = {
{
.video_input= 0,
.name = "Composite",
@@ -741,7 +742,8 @@
return;
}
if (status) {
- printk(KERN_ERR "go7007-usb: error in video pipe: %d\n",
status);
+ printk(KERN_ERR "go7007-usb: error in video pipe: %d\n",
+ status);
return;
}
if (urb->actual_length != urb->transfer_buffer_length) {
@@ -762,7 +764,8 @@
if (!go->streaming)
return;
if (status) {
- printk(KERN_ERR "go7007-usb: er
Re: Hw capabilities of the HVR-2200
On 9/18/09 2:13 PM, Jed wrote: 2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. So I garner from that, that you don't intend to add support for anything (including extra encoding abilities that they don't support in Windows) unless Hauppauge officially does? No, I was referring specifically to your component 'are you sure?' question. I've said many times on and off this mailing list that I'd like to add support for all of the encoder a/v codecs, regardless of the windows driver and it's capabilities. Timeframe for this is unknown. -- 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: Hw capabilities of the HVR-2200
2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. So I garner from that, that you don't intend to add support for anything (including extra encoding abilities that they don't support in Windows) unless Hauppauge officially does? 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. Why do you rule it out unequivocally, is it just because I've annoyed you? :-( Raw analog TV isn't a high priority feature on my mental check-list. Analog TV via the encoder is much more interesting and applicable to many people. Fair-enough, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Mauro, This is my final pull request for the 2.6.32 series. It fixes exposure and adds ctrls for the hdcs sensors. Also some minor cleanups are done. Please pull from http://linuxtv.org/hg/~eandren/v4l-dvb for the following 6 changesets: 01/06: gspca - stv06xx: Harmonize the debug macros when tracing writes and reads http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=cea12062ae46 02/06: gspca - stv06xx: Translate swedish comments to english http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=17b23a5c42b5 03/06: gspca - stv06xx: Fix a misindentation http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=9e2ee847996f 04/06: gspca - stv06xx-hdcs: Add exposure and gain ctrls to hdcs_1020 http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=9be864faec51 05/06: gspca - stv06xx-hdcs: Fixup exposure http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=64c41fd29689 06/06: gspca - stv06xx-hdcs: Reduce exposure range http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=f3989cd0eafc stv06xx.c| 19 +++--- stv06xx_hdcs.c | 151 +-- stv06xx_hdcs.h |2 stv06xx_st6422.c | 15 ++--- 4 files changed, 98 insertions(+), 89 deletions(-) Thanks, Erik Andrén -- 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: Hw capabilities of the HVR-2200
2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. Why do you rule it out unequivocally, is it just because I've annoyed you? :-( Raw analog TV isn't a high priority feature on my mental check-list. Analog TV via the encoder is much more interesting and applicable to many people. -- 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: Hw capabilities of the HVR-2200
**a repost because of earlier issues in getting emails to the list** Hi Kernellabs or anyone involved with driver development of the HVR-2200... Hello. You're starting to see me as a nemesis now aren't you? I'm really a nice person, I promise! :-D I know this is a lng way down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in Yes, this exists in hardware on the SAA7164 and therefore the HVR2200 and HVR2250. Thank-you. 2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. Why do you rule it out unequivocally, is it just because I've annoyed you? :-( The only reason I suggest this is because it'd be nice to have the option to offload encoding to some other device or to 'soft-encode'. Of course demand for such functionality would prolly be the lowest, so it's understandable if it's the last thing implemented, if at all. 4) Is Hw encode purely for A/V-in? (hauppauge's site suggests otherwise but it may be a typo) Yes. Thank-you. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
On 9/18/09 4:27 AM, Hot Wheelz wrote: Hi Mauro, What about saa7162 How far from being complete is that? For some reason this email went specifically to me, not Mauro (who I've cc'd in). The saa7164 tree does not support he saa7162, it was never designed to do so. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hw capabilities of the HVR-2200
On 9/18/09 12:24 PM, Jed wrote: **a repost because of earlier issues in getting emails to the list** Hi Kernellabs or anyone involved with driver development of the HVR-2200... Hello. I know this is a lng way down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in Yes, this exists in hardware on the SAA7164 and therefore the HVR2200 and HVR2250. 2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. 4) Is Hw encode purely for A/V-in? (hauppauge's site suggests otherwise but it may be a typo) Yes. -- 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: Hw capabilities of the HVR-2200
**a repost because of earlier issues in getting emails to the list** Hi Kernellabs or anyone involved with driver development of the HVR-2200... I know this is a lng way down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in 2) Component input for the A/V-in 3) Hw encode bypass for A/V-in 4) Is Hw encode purely for A/V-in? (hauppauge's site suggests otherwise but it may be a typo) 5) If not then questions 1) & 3) also apply to RF-in! Here are the reference cards spec sheets again: http://www.picamatic.com/view/5094357_75016126_P1/ http://www.picamatic.com/view/5094364_75016126_P2/ http://www.picamatic.com/view/5094375_75016207_P1/ http://www.picamatic.com/view/5094373_75016207_P2/ I would be proactive in providing feed-back (as needed) for the dev. of such features. Most Sincerely, Jed [Follow-up post] *Delivery issues resolved, although there's still delays of 7hrs or more being investigated with postmasters* Attention Kernellabs devs, I've deliberately delayed these two posts as Steve mentioned he wouldn't have time to respond for at least 1wk. It's now been almost two weeks, do you think you might have 5-minutes to spare now? I realise you might not "know" the answer to some of my questions yet!... :-) All the best, Jed woops sorry, double post, well that was certainly very quick! No more issues with delays apparent... -- 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: Hw capabilities of the HVR-2200
**a repost because of earlier issues in getting emails to the list** Hi Kernellabs or anyone involved with driver development of the HVR-2200... I know this is a lng way down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in 2) Component input for the A/V-in 3) Hw encode bypass for A/V-in 4) Is Hw encode purely for A/V-in? (hauppauge's site suggests otherwise but it may be a typo) 5) If not then questions 1) & 3) also apply to RF-in! Here are the reference cards spec sheets again: http://www.picamatic.com/view/5094357_75016126_P1/ http://www.picamatic.com/view/5094364_75016126_P2/ http://www.picamatic.com/view/5094375_75016207_P1/ http://www.picamatic.com/view/5094373_75016207_P2/ I would be proactive in providing feed-back (as needed) for the dev. of such features. Most Sincerely, Jed [Follow-up post] *Delivery issues resolved, although there's still delays of 7hrs or more being investigated with postmasters* Attention Kernellabs devs, I've deliberately delayed these two posts as Steve mentioned he wouldn't have time to respond for at least 1wk. It's now been almost two weeks, do you think you might have 5-minutes to spare now? I realise you might not "know" the answer to some of my questions yet!... :-) All the best, Jed -- 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: Hw capabilities of the HVR-2200
**a repost because of earlier issues in getting emails to the list** Hi Kernellabs or anyone involved with driver development of the HVR-2200... I know this is a lng way down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in 2) Component input for the A/V-in 3) Hw encode bypass for A/V-in 4) Is Hw encode purely for A/V-in? (hauppauge's site suggests otherwise but it may be a typo) 5) If not then questions 1) & 3) also apply to RF-in! Here are the reference cards spec sheets again: http://www.picamatic.com/view/5094357_75016126_P1/ http://www.picamatic.com/view/5094364_75016126_P2/ http://www.picamatic.com/view/5094375_75016207_P1/ http://www.picamatic.com/view/5094373_75016207_P2/ I would be proactive in providing feed-back (as needed) for the dev. of such features. Most Sincerely, Jed [Follow-up post] *Delivery issues resolved, although there's still delays of 7hrs or more being investigated with postmasters* Attention Kernellabs devs, I've deliberately delayed these two posts as Steve mentioned he wouldn't have time to respond for at least 1wk. It's now been almost two weeks, do you think you might have 5-minutes to spare now? I realise you might not "know" the answer to some of my questions yet!... :-D All the best, Jed -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Video events
Hi everybody,
yet another RFC, probably the last one before the Linux Plumbers Conference.
This RFC describes a way to pass generic events from video drivers to
userspace applications. Even though I've developed the first prototype for a
V4L2 driver, it should be applicable to DVB devices as well with minor
modifications if any. If someone familiar with DVB notices any serious
problem, please let me know.
Purpose
===
Many video devices need to notify userspace applications of various events.
This includes, but is not limited to,
- button press events
- control change events, when the device changes the value of a control
automatically and wants to notify the user
- motor-related events, when the device reaches the end stop (this could be
handled using control change notifications on the motor controls)
- signal detection/loss on inputs
- image-related events, such as vertical sync, frame size or frame rate
change, ...
- stream-related events, such as stream start/end, when a Linux system acting
as a video device to some host (for instance a USB video gadget) receives
control requests from the host
Some of those events can be easily handled by the input subsystem, such as the
button events. Other events could hack their way into some kind of input
device, but that would be abusing the input device API and would probably
confuse some userspace applications.
A dedicated event interface is thus needed for video devices.
Current implementations
===
DVB video events
The ivtv and av7110 drivers use an existing event notification API implemented
for DVB devices. include/linux/dvb/video.h defines the following structure and
ioctl.
struct video_event {
__s32 type;
#define VIDEO_EVENT_SIZE_CHANGED1
#define VIDEO_EVENT_FRAME_RATE_CHANGED 2
#define VIDEO_EVENT_DECODER_STOPPED 3
#define VIDEO_EVENT_VSYNC 4
__kernel_time_t timestamp;
union {
video_size_t size;
unsigned int frame_rate;
unsigned char vsync_field;
} u;
};
#define VIDEO_GET_EVENT_IOR('o', 28, struct video_event)
An application waits for events using the select() function by setting the
file descriptor in the exception file descriptors set. When an event is
available the poll handler sets POLLPRI which wakes up select().
The userspace application then calls ioctl(VIDIO_GET_EVENT) which fills the
struct video_event with an event type, a timestamp and event type specific
data.
UVC gadget events
-
The UVC gadget driver (posted today on the linux-media and linux-usb mailing
lists) uses an independently developed but very similar method.
enum uvc_event_type
{
UVC_EVENT_CONNECT,
UVC_EVENT_DISCONNECT,
UVC_EVENT_STREAMON,
UVC_EVENT_STREAMOFF,
UVC_EVENT_SETUP,
UVC_EVENT_DATA,
};
struct uvc_event_data
{
int length;
__u8 data[64];
};
struct uvc_event
{
enum uvc_event_type type;
union {
enum usb_device_speed speed;
struct usb_ctrlrequest req;
struct uvc_event_data data;
};
};
#define UVCIOC_EVENT_READ _IOR('U', 1, struct uvc_event)
The user is notified through select() and the exception file descriptors set
exactly the same way as for the DVB video events.
ACPI events
---
ACPI reports button events through the input subsystem, and generic events
through netlink. For those not familiar with netlink, it's basically a kernel
<-> userspace message passing interface using sockets.
There are probably other event notification APIs in the Linux kernel, feel
free to mention the ones you know about.
Implementation proposal
===
My proposal is to unify the DVB video and UVC gadget event APIs into a single
video event API.
The following structure lists fields common to all event types. Some of them
(such as the sequence number) might not be required, but I've listed all the
ones I thought of.
struct video_event {
__u32 type;
__u32 sequence;
__u32 entity;
struct timeval timestamp;
__u8 data[64];
};
#define VIDEO_GET_EVENT_IOR('o', 28, struct video_event)
Applications wait for events using the select() function by setting the file
descriptor in the exception file descriptors set. When an event is available
the poll handler sets POLLPRI which wakes up select().
The userspace application then calls ioctl(VIDIO_GET_EVENT) which fills the
struct video_event. Note that the ioctl definition comes from the DVB video.h
header and can be changed to a V4L2 or media controller ioctl.
type: Similarly to V4L2 controls, event types should be defined in the
V4L2/DVB specification. Drivers could also implement private events.
sequence: Event sequence number. This field is incremented by the driver for
every event. It can be u
Re: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
On 9/18/09 12:24 AM, Mauro Carvalho Chehab wrote: Em Thu, 17 Sep 2009 20:05:14 -0400 Steven Toth escreveu: Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-dev - SAA7164: Remove the SAA7164 bus id, no longer required. - SAA7164: Remove the i2c client_attach/detach support, no longer required. - SAA7164: Removed bus registration messages from driver startup drivers/media/video/saa7164/saa7164-i2c.c | 62 -- include/linux/i2c-id.h|1 2 files changed, 1 insertion(+), 62 deletions(-) These fix the i2c attach/detach compilation error and the id assignment we'd previously discussed, as well as reducing slightly the driver verbosity during i2c bus registration. Ok, now it compiles, but there are still two warnings against upstream, with x86_64: drivers/media/video/saa7164/saa7164-buffer.c: In function ‘saa7164_buffer_alloc’: drivers/media/video/saa7164/saa7164-buffer.c:110: warning: cast to pointer from integer of different size drivers/media/video/saa7164/saa7164-buffer.c:112: warning: cast to pointer from integer of different size Last I checked prior to merge the only 64bit'ism was the warning for the call to the kernel software demux. Let me look into this today. - 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: [PATCH 1/3] USB gadget: audio class function driver
Laurent Pinchart wrote:
> +snd_uac_pcm_open(struct snd_pcm_substream *substream, int stream)
> ...
> + substream->runtime->hw = stream == SNDRV_PCM_STREAM_PLAYBACK
> +? snd_uac_playback_hw
> +: snd_uac_capture_hw;
> + substream->runtime->hw.rate_min = uac->rate;
> + substream->runtime->hw.rate_max = uac->rate;
The .rates bit mask is supposed to be consistent with the min/max
values; you can use the snd_pcm_rate_to_rate_bit() helper function for
this.
> +snd_uac_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> ...
> + spin_lock_irqsave(&subs->lock, flags);
> + subs->streaming = 1;
> + spin_unlock_irqrestore(&subs->lock, flags);
The trigger callback is guaranteed to be called with interrupts
disabled; you can use spin_lock/spin_unlock here.
> +int __init uac_audio_init(struct uac_device *uac)
> ...
> + static int dev = 0;
> ...
> + ret = snd_card_create(SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1,
Usually, drivers use index/id module parameters for these parameters.
But if you don't (which is possible), you don't need to count up the
dev variable.
> +uac_audio_encode(struct snd_uac_substream *subs, struct usb_request *req)
> ...
> + if (!subs->streaming) {
> + spin_unlock_irqrestore(&subs->lock, flags);
> + req->length = 0;
> + return;
> + }
> +
> + /* TODO Handle buffer underruns. */
The ALSA framework handles buffer underruns by stopping the stream.
AFAICS this will result in the gadget returning empty packets.
It is also possible for the application (not the driver) to configure
the ALSA PCM device to continue streaming, so that the device plays
either the old contents of the buffer or silence.
The driver doesn't actually get much of an opportunity to handle this.
> +uac_audio_complete(struct usb_ep *ep, struct usb_request *req)
> ...
> + switch (req->status) {
> + case 0:
> + break;
> +
> + case -ECONNRESET:
> + case -ESHUTDOWN:
> + goto requeue;
> +
> + default:
> + INFO(uac->func.config->cdev, "AS request completed with "
> + "status %d.\n", req->status);
> + goto requeue;
> + }
> +
> + uac_audio_encode(subs, req);
Shouldn't the device continue to send packets even if an isochronous
transfer failed?
> +uac_audio_pump(struct uac_device *uac)
> ...
> + /* FIXME TODO Race between uac_audio_pump and requests completion
> + * handler ???
> + */
Indeed. But I guess uac_audio_pump() is called when starting a stream
when you don't yet have any completions?
The USB audio host driver copies samples from the ALSA buffer to the
request buffers only in the request completion handler; streaming gets
started with a bunch of silence packets. This also has the consequence
that data gets taken out of the buffer at a constant rate.
Best regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Global video buffers pool
I'm joining your comments to Vaibhav with your comments to me, in order to avoid duplicating comments. Em Fri, 18 Sep 2009 10:39:17 +0200 Laurent Pinchart escreveu: > > > Different devices may have quite different buffer requirements (size, > > > number of buffers). Would it be safe to have them all allocated from a > > > global pool? I do not feel confident myself that I understand all the > > > implications of a global pool or whether you actually always want that. > > > > This is a problem with the pool concept. Even having the same driver, > > you'll still be needing different resolutions, frame rates, formats and > > bits per pixel on each /dev/video interface. > > That's right (the frame rate doesn't matter though), but not different memory > type (low-mem, non-cacheable, contiguous, ...) requirements. The only thing > that matters in the end is the number of buffers and their size. The pool > doesn't care about the formats and resolutions separately. For raw formats, that's right. However, with some compressed formats, there are other parameters that affect the size of a framebuffer. For example, just knowing the resolution is not enough for h.264/mpeg/jpeg formats. Even frame rate can affect some of them, since they'll affect the temporal estimations. For compressed formats, maybe the right approach would be to allocate buffers based on the maximum allowed bandwidth. > > > I'm not sure how to deal. > > My idea was to have several groups of video buffers. You could allocate on > "large" group of low-resolution buffers for video preview, and a "small" > group > of high-resolution buffers for still image capture. Video devices could then > pick buffers from one of those groups depending on their needs. > > > Maybe we'll need to allocate the buffers considering the worse case that > > can be passed to the driver. For example, in the case of a kernel > > parameter, it could be something like: > > videobuf=buffers=32,size=256K > > To allocate 32 buffers with 256K each. This way, even if application asks > > for a smaller buffer, it will keep reserving 256K for each buffer. If bad > > specified, memory will be wasted, but the memory will be there. > > Eventually, after allocating that memory, some API could be provided for > > example to rearrange the allocated space into 64 x 128K. > > We still need separate groups, otherwise we will waste too much memory. 5MP > sensors are common today, and the size will probably grow in the years to > come. We can't allocate 32 5MP buffers on an embedded system. > > I agree with Mauro here. The only way you can allocate the required memory > > is in general to do it early in the boot sequence. > > I agree with you there as well, but there's one obvious problem with that > approach: the Linux kernel doesn't know how much memory you will need. > Let me take the OMAP3 camera as an example. The sensor has a native 5MP > resolution (2548x1938). When taking a still picture, we want to display live > video on the device's screen in a lower resolution (840x400) and, when the > user presses the camera button, switch to the 5MP resolution and capture 3 > images. > > For this we need a few (let's say 5) 840x400 buffers (672000 bytes each in > YUV) and 3 2548x1938 buffers (9876048 bytes each). Those requirements come > from the product specifications, and the device driver has no way to know > about them. Allocating several huge buffers at boot time big enough for all > use cases will here use 75MB of memory instead of 31.5MB. > > That's why I was thinking about allowing a userspace application to allocate > those buffers very early after boot. One other possible solution would be to > use a kernel command line parameter set to something like > "5x672000,3x9876048". Interesting approach. Another alternative would be to allocate a flat memory block during boot time, and provide a set of controls to control how the memory will be divided. > > So, while I agree that it is not a mandatory requirement to port the > > existing drivers to benefit with the memory pool, by not doing it, those > > drivers will be less reliable than the other drivers on professional > > usage. > > Good point. No need to be too clever though. I think that the memory pool > concept can be restricted to use cases where the user knows in advance what's > going to happen with the hardware. A video monitoring system is one of them, > a > digital camera is another one. Agreed. > In those cases the system designer knows what > resolutions will be streamed at, and how many buffers will be needed. This > information can come from userspace or the kernel command line, and the > memory > pool won't need to become a complete memory management system. An application > that wants to use buffers from the pool will the explicitly which set of > buffers it wants to use. I'm not sure that reserving memory size on userspace would be good enough, even if done to
[PATCH 3/3] USB gadget: Webcam Audio/Video device
This webcam gadget driver combines a UAC microphone (sampling rate
configurable using a module parameter) and a UVC camera (360p and 720p
resolutions in YUYV and MJPEG).
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/Kconfig |9 +-
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/webcam.c | 419 +++
3 files changed, 429 insertions(+), 1 deletions(-)
create mode 100644 drivers/usb/gadget/webcam.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 7f8e83a..38b9481 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -766,8 +766,15 @@ config USB_CDC_COMPOSITE
# put drivers that need isochronous transfer support (for audio
# or video class gadget drivers), or specific hardware, here.
+config USB_G_WEBCAM
+ tristate "USB Webcam Gadget"
+ help
+ The Webcam Gadget acts as a composite USB Audio and Video Class
+ device. It provides a userspace API to process UVC control requests
+ and stream video data to the host.
-# - none yet
+ Say "y" to link the driver statically, or "m" to build a
+ dynamically linked module called "g_webcam".
endchoice
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index e6017e6..4956992 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -40,6 +40,7 @@ gadgetfs-objs := inode.o
g_file_storage-objs:= file_storage.o
g_printer-objs := printer.o
g_cdc-objs := cdc2.o
+g_webcam-objs := webcam.o
obj-$(CONFIG_USB_ZERO) += g_zero.o
obj-$(CONFIG_USB_AUDIO)+= g_audio.o
@@ -50,4 +51,5 @@ obj-$(CONFIG_USB_G_SERIAL)+= g_serial.o
obj-$(CONFIG_USB_G_PRINTER)+= g_printer.o
obj-$(CONFIG_USB_MIDI_GADGET) += g_midi.o
obj-$(CONFIG_USB_CDC_COMPOSITE) += g_cdc.o
+obj-$(CONFIG_USB_G_WEBCAM) += g_webcam.o
diff --git a/drivers/usb/gadget/webcam.c b/drivers/usb/gadget/webcam.c
new file mode 100644
index 000..132bca6
--- /dev/null
+++ b/drivers/usb/gadget/webcam.c
@@ -0,0 +1,420 @@
+/*
+ * webcam.c -- USB webcam gadget driver
+ *
+ * Copyright (C) 2008-2009
+ * Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include
+#include
+#include
+
+#include "f_uvc.h"
+#include "uac.h"
+
+/*
+ * Kbuild is not very cooperative with respect to linking separately
+ * compiled library objects into one module. So for now we won't use
+ * separate compilation ... ensuring init/exit sections work to shrink
+ * the runtime footprint, and giving us at least some parts of what
+ * a "gcc --combine ... part1.c part2.c part3.c ... " build would.
+ */
+#include "composite.c"
+#include "usbstring.c"
+#include "config.c"
+#include "epautoconf.c"
+
+#include "f_uvc.c"
+#include "uvc_queue.c"
+#include "uvc_v4l2.c"
+#include "uvc_video.c"
+
+#include "f_uac.c"
+#include "uac_alsa.c"
+#include "uac_audio.c"
+
+static int webcam_audio_frequency = 0;
+module_param_named(audio_freq, webcam_audio_frequency, int, S_IRUGO);
+MODULE_PARM_DESC(audio_freq, "Audio frequency");
+
+/* --
+ * Device descriptor
+ */
+
+#define WEBCAM_VENDOR_ID 0x1d6b /* Linux Foundation */
+#define WEBCAM_PRODUCT_ID 0x0102 /* Webcam A/V gadget */
+#define WEBCAM_DEVICE_BCD 0x0010 /* 0.10 */
+
+static char webcam_vendor_label[] = "Linux Foundation";
+static char webcam_product_label[] = "Webcam A/V gadget";
+static char webcam_config_label[] = "Audio/Video";
+
+/* string IDs are assigned dynamically */
+
+#define STRING_MANUFACTURER_IDX0
+#define STRING_PRODUCT_IDX 1
+#define STRING_DESCRIPTION_IDX 2
+
+static struct usb_string webcam_strings[] = {
+ [STRING_MANUFACTURER_IDX].s = webcam_vendor_label,
+ [STRING_PRODUCT_IDX].s = webcam_product_label,
+ [STRING_DESCRIPTION_IDX].s = webcam_config_label,
+ { }
+};
+
+static struct usb_gadget_strings webcam_stringtab = {
+ .language = 0x0409, /* en-us */
+ .strings = webcam_strings,
+};
+
+static struct usb_gadget_strings *webcam_device_strings[] = {
+ &webcam_stringtab,
+ NULL,
+};
+
+static struct usb_device_descriptor webcam_device_descriptor = {
+ .bLength= USB_DT_DEVICE_SIZE,
+ .bDescriptorType= USB_DT_DEVICE,
+ .bcdUSB = cpu_to_le16(0x0200),
+ .bDeviceClass = USB_CLASS_MISC,
+ .bDeviceSubClass= 0x02,
+ .bDeviceProtocol= 0x01,
+ .bMaxPacketSize0= 0, /* dy
[PATCH 1/3] USB gadget: audio class function driver
This USB audio class function driver exposes an ALSA interface to userspace
to stream audio data from an application over USB.
Signed-off-by: Laurent Pinchart
---
drivers/usb/gadget/f_uac.c | 654
drivers/usb/gadget/uac.h | 99 ++
drivers/usb/gadget/uac_alsa.c | 348 +
drivers/usb/gadget/uac_audio.c | 238 +++
4 files changed, 1339 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/f_uac.c
create mode 100644 drivers/usb/gadget/uac.h
create mode 100644 drivers/usb/gadget/uac_alsa.c
create mode 100644 drivers/usb/gadget/uac_audio.c
diff --git a/drivers/usb/gadget/f_uac.c b/drivers/usb/gadget/f_uac.c
new file mode 100644
index 000..aaacff1
--- /dev/null
+++ b/drivers/usb/gadget/f_uac.c
@@ -0,0 +1,654 @@
+/*
+ * f_uac.c -- USB Audio class function driver
+ *
+ * Copyright (C) 2009
+ * Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * Based on f_audio.c
+ * Copyright (C) 2008 Bryan Wu
+ * Copyright (C) 2008 Analog Devices, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include "uac.h"
+
+/* I'd like 68 bytes packets, but for some reason the MUSB controller refuses
+ * to transfer 68 bytes isochronous packets. 64 bytes and 70 bytes work though.
+ * Go figure.
+ */
+#define IN_EP_MAX_PACKET_SIZE 70
+
+static int req_buf_size = IN_EP_MAX_PACKET_SIZE;
+module_param(req_buf_size, int, S_IRUGO);
+MODULE_PARM_DESC(req_buf_size, "ISO IN endpoint request buffer size");
+
+static int req_count = 256;
+module_param(req_count, int, S_IRUGO);
+MODULE_PARM_DESC(req_count, "ISO IN endpoint request count");
+
+static int audio_buf_size = 48000;
+module_param(audio_buf_size, int, S_IRUGO);
+MODULE_PARM_DESC(audio_buf_size, "Audio buffer size");
+
+static int generic_set_cmd(struct usb_audio_control *con, u8 cmd, int value);
+static int generic_get_cmd(struct usb_audio_control *con, u8 cmd);
+
+/* --
+ * Function descriptors
+ */
+
+#define INPUT_TERMINAL_ID 1
+#define FEATURE_UNIT_ID2
+#define OUTPUT_TERMINAL_ID 3
+
+static struct usb_interface_assoc_descriptor uac_iad __initdata = {
+ .bLength= USB_DT_INTERFACE_ASSOCIATION_SIZE,
+ .bDescriptorType= USB_DT_INTERFACE_ASSOCIATION,
+ .bFirstInterface= 0,
+ .bInterfaceCount= 2,
+ .bFunctionClass = USB_CLASS_AUDIO,
+ .bFunctionSubClass = USB_SUBCLASS_AUDIOSTREAMING, /* FIXME Where
is this documented ? */
+ .bFunctionProtocol = 0x00,
+ .iFunction = 0,
+};
+
+/* B.3.1 Standard AC Interface Descriptor */
+static struct usb_interface_descriptor ac_interface_desc __initdata = {
+ .bLength= USB_DT_INTERFACE_SIZE,
+ .bDescriptorType= USB_DT_INTERFACE,
+ .bInterfaceNumber = 0, /* dynamic */
+ .bAlternateSetting = 0,
+ .bNumEndpoints = 0,
+ .bInterfaceClass= USB_CLASS_AUDIO,
+ .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
+};
+
+DECLARE_UAC_AC_HEADER_DESCRIPTOR(2);
+
+/* B.3.2 Class-Specific AC Interface Descriptor */
+static struct uac_ac_header_descriptor_2 ac_header_desc = {
+ .bLength= UAC_DT_AC_HEADER_SIZE(1),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubtype = UAC_HEADER,
+ .bcdADC = cpu_to_le16(0x0100),
+ .wTotalLength = cpu_to_le16(UAC_DT_AC_HEADER_SIZE(1) +
+ UAC_DT_INPUT_TERMINAL_SIZE +
+ UAC_DT_FEATURE_UNIT_SIZE(0)),
+ .bInCollection = 1,
+ .baInterfaceNr[0] = 0, /* dynamic */
+};
+
+static struct uac_input_terminal_descriptor input_terminal_desc = {
+ .bLength= UAC_DT_INPUT_TERMINAL_SIZE,
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubtype = UAC_INPUT_TERMINAL,
+ .bTerminalID= INPUT_TERMINAL_ID,
+ .wTerminalType = UAC_INPUT_TERMINAL_MICROPHONE,
+ .bAssocTerminal = 0,
+ .bNrChannels= 1, /* TODO make this dynamic */
+ .wChannelConfig = 0, /* dynamic */
+ .iChannelNames = 0,
+ .iTerminal = 0,
+};
+
+DECLARE_UAC_FEATURE_UNIT_DESCRIPTOR(0);
+
+static struct uac_feature_unit_descriptor_0 feature_unit_desc = {
+ .bLength= UAC_DT_FEATURE_UNIT_SIZE(0),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubtype = UAC_FE
[PATCH 0/3] USB audio and video class gadget drivers
Hi everybody, here are two new gadget function drivers for USB audio class and USB video class as well as a webcam gadget driver that combines both audio and video. All those drivers are work in progress (though not progressing much for the moment, as I'm busy with other development) and should probably not be applied before (at least) v2, but can still be useful as-is. The code was developed and tested on TI DM365 hardware using a MUSB controller. I unfortunately don't have access to the hardware anymore for the time being, but I got an OMAP3-based platform in the meantime. If spare time permits I'll test the driver on the OMAP3 platform. The audio class driver is based on Bryan Wu's work. It requires the "USB gadget: Handle endpoint requests at the function level" patch that I've posted on the list. Only the microphone use case is supported at the moment. If anyone wants to implement speaker support patches are welcome :-) The video class driver reuses some of the UVC host driver code, mostly for video buffers queue management. It currently has its own copy of the code, so there's room for improvement there. If you look closely you will notice that the UVC driver uses the V4L2 device node to forward events (connection/disconnection, UVC request arrival, ...) to userspace. I will soon post an RFC to the linux-media list to document the interface. The webcam driver combines a UAC microphone (at 16kHz) and a UVC camera (at 360p and 720p in YUYV and MJPEG). Comments and ideas are welcome. -- Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Global video buffers pool
Hi Mauro, thanks for the review. A few comments. On Friday 18 September 2009 00:45:42 Mauro Carvalho Chehab wrote: > Em Thu, 17 Sep 2009 23:19:24 +0200 > Hans Verkuil escreveu: [snip] > > > 4) As you've mentioned, a global set of buffers seem to be the better > > > alternative. This means that V4L2 core will take care of controlling > > > the pool, instead of leaving this task to the drivers. This makes > > > easier to have a boot-time parameter specifying the size of the memory > > > pool and will optimize memory usage. We may even have a Kconfig var > > > specifying the default size of the memory pool (although this is not > > > really needed, since new kernels allow specifying default line command > > > parameters). > > > > Different devices may have quite different buffer requirements (size, > > number of buffers). Would it be safe to have them all allocated from a > > global pool? I do not feel confident myself that I understand all the > > implications of a global pool or whether you actually always want that. > > This is a problem with the pool concept. Even having the same driver, > you'll still be needing different resolutions, frame rates, formats and > bits per pixel on each /dev/video interface. That's right (the frame rate doesn't matter though), but not different memory type (low-mem, non-cacheable, contiguous, ...) requirements. The only thing that matters in the end is the number of buffers and their size. The pool doesn't care about the formats and resolutions separately. > I'm not sure how to deal. My idea was to have several groups of video buffers. You could allocate on "large" group of low-resolution buffers for video preview, and a "small" group of high-resolution buffers for still image capture. Video devices could then pick buffers from one of those groups depending on their needs. > Maybe we'll need to allocate the buffers considering the worse case that > can be passed to the driver. For example, in the case of a kernel > parameter, it could be something like: > videobuf=buffers=32,size=256K > To allocate 32 buffers with 256K each. This way, even if application asks > for a smaller buffer, it will keep reserving 256K for each buffer. If bad > specified, memory will be wasted, but the memory will be there. > Eventually, after allocating that memory, some API could be provided for > example to rearrange the allocated space into 64 x 128K. We still need separate groups, otherwise we will waste too much memory. 5MP sensors are common today, and the size will probably grow in the years to come. We can't allocate 32 5MP buffers on an embedded system. > > > 5) The step to have a a global-wide video buffers pool allocation, as > > > you mentioned at the RFC, is to make sure that all drivers will use > > > v4l2 framework to allocate memory. So, this means porting a few drivers > > > (ivtv, uvcvideo, cx18 and gspca) to use videobuf. As videobuf already > > > supports all sorts of different memory types and configs (contig and > > > Scatter/Gather DMA, vmalloced buffers, mmap, userptr, read, overlay > > > modes), it should fits well on the needs. > > > > Why would I want to change ivtv for this? In fact, I see no reason to > > modify any of the existing drivers. A mc-wide or global memory pool is > > only of interest for very complex devices where you want to pass buffers > > around between various sub-devices (and possibly to other media devices > > or DSPs). And yes, they probably will have to use the framework in order > > to be able to coordinate these pools properly. > > The issue here is not necessarely related to device complexity. It can be > motivated by other factors, for example: > > - arch's with non-coherent cache; > - devices that aren't capable of doing DMA scatter/gather; > - high memory fragmentation. > > Just as an example, I used an old laptop with "only" 256 Mb of ram, running > a new distro, when I started developing the tm6000 drivers. On that > hardware, I was needing buffers of about 600 KB each. It were very common > to not be able to allocate such buffers there, due to high memory > fragmentation, since the USB driver were trying to allocate a continuous > buffer on that hardware. > > So, the same argument we used with the EMBEEDED Kconfig option also applies > here: it is not everything black or white. For example, surveillance > systems need to be very reliable. So, the possibility of allocating memory > during boot will help them. > > Just to take a random real usecase, David Liontooth mentioned recently at > the ML his intention of maybe using ivtv hardware to capture TV signals at > remote locations, having the hardware minimally assisted. He mention the > needs of capturing data continuously for 15 hours. That means that the > machine will likely close devices and reopen once a day, during years. In > such application, a video buffer pool will for sure reduce the risk of > memory fragmentat
Re: [RFC] Global video buffers pool
Hi Hans, On Thursday 17 September 2009 23:19:24 Hans Verkuil wrote: > On Thursday 17 September 2009 20:49:49 Mauro Carvalho Chehab wrote: > > Em Wed, 16 Sep 2009 17:46:39 +0200 > > Laurent Pinchart escreveu: > > > Hi everybody, > > > > > > I didn't want to miss this year's pretty flourishing RFC season, so > > > here's another one about a global video buffers pool. > > > > > > All comments are welcome, but please don't trash this proposal too > > > fast. It's a first shot at real problems encountered in real situations > > > with real hardware (namely high resolution still image capture on > > > OMAP3). It's far from perfect, and I'm open to completely different > > > solutions if someone thinks of one. > > First of all, thank you Laurent for working on this! Much appreciated. > > > Some comments about your proposal: > > > > 1) For embedded systems, probably the better is to create it at boot > > time, instead of controlling it via userspace, since as early it is done, > > the better. > > I agree with Mauro here. The only way you can allocate the required memory > is in general to do it early in the boot sequence. I agree with you there as well, but there's one obvious problem with that approach: the Linux kernel doesn't know how much memory you will need. Let me take the OMAP3 camera as an example. The sensor has a native 5MP resolution (2548x1938). When taking a still picture, we want to display live video on the device's screen in a lower resolution (840x400) and, when the user presses the camera button, switch to the 5MP resolution and capture 3 images. For this we need a few (let's say 5) 840x400 buffers (672000 bytes each in YUV) and 3 2548x1938 buffers (9876048 bytes each). Those requirements come from the product specifications, and the device driver has no way to know about them. Allocating several huge buffers at boot time big enough for all use cases will here use 75MB of memory instead of 31.5MB. That's why I was thinking about allowing a userspace application to allocate those buffers very early after boot. One other possible solution would be to use a kernel command line parameter set to something like "5x672000,3x9876048". Another reason to allow applications to allocate buffers in the pool was to be able to "pre-queue" buffers to avoid cache invalidation and memory pinning delays at VIDIOC_QBUF. This is a very important topic that I might not have stressed enough in the RFC. VIDIOC_QBUF currently hurts performances. For the camera use case I've explained above, we need a way to pre-queue the 3 5MP buffers while still streaming video in 840x400. > > 2) As I've posted at the media controller RFC, we should take care to not > > abuse about its usage. Media controller has two specific objetives: > > topology enumeration/change and subdev parameter send. > > True, but perhaps it can also be used for other purposes. I'm not saying we > should, but neither should we stop thinking about it. Someone may come up > with a great idea for which a mc is ideally suited. We are still in the > brainstorming stage, so any idea is welcome. Agreed. The media controller RFC described its intended purpose, but I don't see why it couldn't be extended if we find a use case for which the media controller is ideally suited. > > For the last, as I've explained there, the proper solution is to create > > devices for each v4l subdev that requires control from userspace. > > The proper solution *in your opinion*. I'm still on the fence on that one. > > > In the case of a video buffers memory poll, it is none of the usecases of > > media controller. So, it is needed to think better about where to > > implement it. > > Why couldn't it be one of the use cases? Again, it is your opinion, not a > fact. Note that I share this opinion, but try to avoid presenting opinions > as facts. > > > 3) I don't think that having a buffer pool per media controller will be > > so useful. A media controller groups /dev/video with their audio, IR, > > I2C... resources. On systems with more than one different board (for > > example a cellular phone with a camera and an DVB-H receiver), you'll > > likely have more than one media controller. So, controlling video buffer > > pools at /dev/video or at media controller will give the same results on > > several environments; > > I don't follow the logic here, sorry. > > > 4) As you've mentioned, a global set of buffers seem to be the better > > alternative. This means that V4L2 core will take care of controlling the > > pool, instead of leaving this task to the drivers. This makes easier to > > have a boot-time parameter specifying the size of the memory pool and > > will optimize memory usage. We may even have a Kconfig var specifying the > > default size of the memory pool (although this is not really needed, > > since new kernels allow specifying default line command parameters). > > Different devices may have quite different buffer requirements (size,
RE: LifeView LR307Q Mini PCI
Hi Gabriel, From what I can remember, card=60 and audio_clock_override=0x00187de7 did the trick for analogue PAL-I. See http://marc.info/?l=linux-video&m=116859373521663&w=2 Cheers Paul -Original Message- From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-boun...@redhat.com] On Behalf Of hermann pitton Sent: 17 September 2009 23:56 To: Gabriel Dos Santos Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org Subject: Re: LifeView LR307Q Mini PCI Hi Gabriel, Am Donnerstag, den 17.09.2009, 13:14 + schrieb Gabriel Dos Santos: > > Hi, I recently got a mini PCI LifeView LR307Q Hybrid TV Tuner. > I want to use it to tune analog tv (digital would be a plus but it is not > really important to me). The card works perfectly (Analog and digital) on the > same machine with Windows. Card subsystem is identified as 4e42:4307, which I > didn't find in the list of supported cards by v4l. However, tHis forum > (http://lists.zerezo.com/video4linux/msg15910.html) reports the card to be > working (except for radio) with card=60 and audio_clock_override=0x00187de7 > parameters to the module. > However, I am unable to make sound work . my, this is close to three years back! The only reports we ever had were from Paul and he tried across different cards and it was never finished. It has no radio and only one single RF in connector. BTW, do you know about an extra fan for cooling the tuner? Likely not anymore on a tda8275ac1 and mini PCI. > I am in Spain, which means norm = PAL-BG I think. I am using Ubuntu > 9.04 (kernel 2.6.18-11) That is a nightmare of wasting time. Given that all card entries were still volatile that time, especially for gpio settings, I would to have to dig out on what exactly version Paul was and compare it to an Ubuntu 2.6.18-11. Ugh! On what you really are? They do down port several kernel versions without problems, but card=109 is a few away from vanilla 2.6.18. To add more, AFAIK, in Spain you use NICAM-BG for stereo sound and around that 2.6.18 it might have been broken in favor of NICAM-DK. The module names even did changed a lot, can't even tell the right debug options off hand any more. With saa7134 audio_debug=1 you should at least see, if it fails to detect NICAM-BG and hangs on other audio. > The steps I follow are > > 1) Remove the modules loaded by default with wrong parameters: rmmod > saa7143-alsa;rmmod saa7134 > 2) sudo modprobe saa7134 card=X (I've tried several values of X) > 3) Run scantv -c /dev/video0 -C /dev/vbi0 (norm = 5 , region=5) > 4) open alsamixer in the SAA device and set the volume to 100% for > every control > 5) Run > sox -c 2 -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp& ; mencoder -tv > norm=PAL-BG:driver=v4l2:device=/dev/video0:forceaudio:forcechan=1:adev > ice=/dev/dsp:fps=25:chanlist=europe-west:audiorate=32000:width=320:hei > ght=240 -vf lavcdeint -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=225 > -oac lavc -lavcopts abitrate=32 -o out.avi tv://23 Start simple, say xawtv/tvtime and sox -c 2 -s -w -r 32000 -t ossdsp /dev/dsp1 -t ossdsp -w -r 32000 /dev/dsp > > The results I obtain are as follows > > When using any of the values 2,3,39,54,74, 84,82,94 for the card > number when loading the module, scantv does not detect any channel > > When using any of the values 55,60,81,109 for the card: scantv finds channels > and I get an image (perfect image with 109, there are some glitches with > other values) but only very short pulses of distorted sound. I have also > tried using the parameter audio_clock_override=0x00187de7 when loading the > module with the different card values, but the result is the same. > > I have also tried using the tuner= parameter when loading the module > but this seems to be ignored, since the dmesg always seems to be > loading tuner=54 > > tuner' 0-004b: chip found @ 0x96 (saa7133[0]) > tda829x 0-004b: setting tuner address to 61 > tda829x 0-004b: type set to tda8290+75a Paul later reported that it works for the Philips Tiger S card=109 and it has for sure a LNA config type 2. That explained the better image at that time already with clear symptoms of missing LNA support previously. > > Sorry for the long mail but I wanted to provide as much info as > possible. I have now spent many nights trying to make this work and I > am in the point in which I don't know what else to do. I would really > appreciate to have some hint on what I am doing wrong, It is difficult on 2.6.18. You must upgrade to current mercurial v4l-dvb. Currently it does not even compile on a 2.6.30. CC [M] /mercurial/hg-head/v4l-dvb/v4l/videobuf-dma-sg.o CC [M] /mercurial/hg-head/v4l-dvb/v4l/videobuf-dma-contig.o /mercurial/hg-head/v4l-dvb/v4l/videobuf-dma-contig.c: In function 'videobuf_dma_contig_user_get': /mercurial/hg-head/v4l-dvb/v4l/videobuf-dma-contig.c:164: error: implicit declaration of function 'follow_pfn' make[3]: *** [/mercurial/hg-head/v4l-dvb/v4l/vid
RE: [RFC] Global video buffers pool
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > Sent: Wednesday, September 16, 2009 9:17 PM > To: linux-media@vger.kernel.org; Hans Verkuil; Sakari Ailus; Cohen > David Abraham; Koskipää Antti Jussi Petteri; Zutshi Vimarsh (Nokia- > D-MSW/Helsinki); stefan.k...@nokia.com > Subject: [RFC] Global video buffers pool > > Hi everybody, > > I didn't want to miss this year's pretty flourishing RFC season, so > here's > another one about a global video buffers pool. > > All comments are welcome, but please don't trash this proposal too > fast. It's > a first shot at real problems encountered in real situations with > real > hardware (namely high resolution still image capture on OMAP3). It's > far from > perfect, and I'm open to completely different solutions if someone > thinks of > one. > [Hiremath, Vaibhav] Thanks Laurent for putting this, I believe memory fragmentation is a critical issue for most of new the drivers. We need some sort of solution to address this. Please find some observations/issues/Q below - > > Introduction > > > The V4L2 video buffers handling API makes use of a queue of video > buffers to > exchange data between video devices and userspace applications (the > read > method don't expose the buffers objects directly but uses them > underneath). > Although quite efficient for simple video capture and output use > cases, the > current implementation doesn't scale well when used with complex > hardware and > large video resolutions. This RFC will list the current limitations > of the API > and propose a possible solution. > > The document is at this stage a work in progress. Its main purpose > is to be > used as support material for discussions at the Linux Plumbers > Conference. > > > Limitations > === > > Large buffers allocation > > > Many video devices still require physically contiguous memory. The > introduction of IOMMUs on high-end systems will probably make that a > distant > nightmare in the future, but we have to deal with this situation for > the > moment (I'm not sure if the most recent PCI devices support scatter- > gather > lists, but many embedded systems still require physically contiguous > memory). > > Allocating large amounts of physically contiguous memory needs to be > done as > soon as possible after (or even during) system bootup, otherwise > memory > fragmentation will cause the allocation to fail. > > As the amount of required video memory depends on the frame size and > the > number of buffers, the driver can't pre-allocate the buffers > beforehand. A few > drivers allocate a large chunk of memory when they are loaded and > then use it > when a userspace application requests video buffers to be allocated. > However, > that method requires guessing how much memory will be needed, and > can lead to > waste of system memory (if the guess was too large) or allocation > failures (if > the guess was too low). > [Hiremath, Vaibhav] Could it possible to fine tune this based on use-case. At-least on OMAP Display driver we have boot argument to control number of buffers and size of buffers which user can pass through boot time argument. The default setting is 3 buffers for max resolution (720P). With this it won't be guessing any more, right? > Buffer queuing latency > --- > > VIDIOC_QBUF is becoming a performance bottleneck when capturing > large images > on some systems (especially in the embedded world). When capturing > high > resolution still pictures, the VIDIOC_QBUF delay adds to the shot > latency, > making the camera appear slow to the user. > > The delay is caused by several operations required by DMA transfers > that all > happen when queuing buffers. > > - Cache coherency management > [Hiremath, Vaibhav] Agreed. > When the processor has a non-coherent cache (which is the case with > most > embedded devices, especially ARM-based) the device driver needs to > invalidate > (for video capture) or flush (for video output) the cache (either a > range, or > the whole cache) every time a buffer is queued. This ensures that > stale data > in the cache will not be written back to memory during or after DMA > and that > all data written by the CPU is visible to the device. > > Invalidating the cache for large resolutions take a considerable > amount of > time. Preliminary tests showed that cache invalidation for a 5MP > buffer > requires several hundreds of milliseconds on an OMAP3 platform for > range > invalidation, or several tens of milliseconds when invalidating the > whole D > cache. > > When video buffers are passed between two devices (for instance when > passing > the same USERPTR buffer to a video capture device and a hardware > codec) > without any userspace access to the memory, CPU cache > invalidation/flushing > isn't required on either side (video capture and hardware
Re: Media Controller initial support for ALSA devices
On Fri, Sep 18, 2009 at 1:11 AM, Mauro Carvalho Chehab wrote: > Em Fri, 18 Sep 2009 00:40:34 -0400 > Devin Heitmueller escreveu: > >> Hello Hans, >> >> If you can find a few minutes, please take a look at the following >> tree, where I added initial support for including the ALSA devices in >> the MC enumeration. I also did a bit of cleanup on your example tool, >> properly showing the fields associated with the given node type and >> subtype (before it was always showing fields for the V4L subtype). >> >> http://kernellabs.com/hg/~dheitmueller/v4l-dvb-mc-alsa/ >> >> I've implemented it for em28xx as a prototype, and will probably see >> how the code looks when calling it from au0828 and cx88 as well (to >> judge the quality of the abstraction). >> >> Comments welcome, of course... > > How do you expect that em28xx devices using snd-usb-audio to be enumerated? There are two basic issues your question raises: 1. Finding the correct ALSA device: I wrote some code a few weeks ago that does it by enumerating through the sound card entries and digging through the usb interface pointers to find the one that matches. I'm just not happy with the code yet and wasn't ready to show it to anybody. I've got the same basic issue with au0828, and I've been thinking about it for a while. Certainly the cases where we have vendor audio or DMA audio for PCI devices are much more straightforward. 2. The second issue has to do with the loading sequence. Because each interface is bound separately, I'm not confident I can setup the alsa device so early in the process, since in the case of the snd-usb-audio the driver hasn't been initialized against the device yet. I'm still trying to work out the optimal scheme for this - for example perhaps waiting until the media controller is opened for the first time before doing the lookup. In short, I am certainly aware of both issues and am actively working on finding an optimal solution. Either way though, the prototype code is good enough for us to start exercising the userland interface and evaluate how well it will integrate into applications for common use cases. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
