Re: [RFC] Merge v4l-utils. dvb-apps and mediactl to media-utils.git
Hi, On 10/07/2011 03:46 PM, Mauro Carvalho Chehab wrote: Em 07-10-2011 10:05, Hans de Goede escreveu: Hi, On 10/07/2011 03:02 PM, Mauro Carvalho Chehab wrote: Em 07-10-2011 03:05, Hans Verkuil escreveu: On Friday, October 07, 2011 04:07:38 Mauro Carvalho Chehab wrote: Em 06-10-2011 14:24, Mauro Carvalho Chehab escreveu: Em 06-10-2011 10:27, Mauro Carvalho Chehab escreveu: Em 06-10-2011 09:23, Hans Verkuil escreveu: Currently we have three repositories containing libraries and utilities that are relevant to the media drivers: dvb-apps (http://linuxtv.org/hg/dvb-apps/) v4l-utils (http://git.linuxtv.org/v4l-utils.git) media-ctl (git://git.ideasonboard.org/media-ctl.git) It makes no sense to me to have three separate repositories, one still using mercurial and one that isn't even on linuxtv.org. I propose to combine them all to one media-utils.git repository. I think it makes a lot of sense to do this. After the switch the other repositories are frozen (with perhaps a README pointing to the new media-utils.git). I'm not sure if there are plans to make new stable releases of either of these repositories any time soon. If there are, then it might make sense to wait until that new stable release before merging. Comments? I like that idea. It helps to have the basic tools into one single repository, and to properly distribute it. Ok, I found some time to do an experimental merge of the repositories. It is available at: http://git.linuxtv.org/mchehab/media-utils.git For now, all dvb-apps stuff is on a separate directory. It makes sense to latter re-organize the directories. Anyway, the configure script will allow disable dvb-apps, v4l-utils and/or libv4l. The default is to have all enabled. One problem I noticed is that the dvb-apps are at version 1.1. So, if we're releasing a new version, we'll need to jump from 0.9 to dvb-apps version + 1. So, IMO, the first version with the merge should be version 1.2. Comments? Strange: $ git clone git://git.linuxtv.org/mchehab/media-utils.git Cloning into media-utils... fatal: The remote end hung up unexpectedly I've no problem with other git trees. Hans, FYI, I'm getting this when compiling from the v4l-utils tree (even before the merge): g++ -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o -L/usr/lib -L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt -L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -lQtCore -lpthread qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)': /home/v4l/work_trees/media-utils/utils/qv4l2/qv4l2.cpp:149: undefined reference to `libv4l2_default_dev_ops' collect2: ld returned 1 exit status Yeah, that is because qmake is stupid and add /usr/lib[64] to the library path and adds it *before* the paths we've specified in its template, so if you've an older libv4l2 installed in /usr/lib[64] when building you get this. To fix it, first do a make; make install in the lib subdir, with LIBDIR setup up to overwrite the old version. Didn't work, as the Fedora package installed it at /usr/lib, while make install installed at /usr/local/lib. (ok, I forced it anyway, by renaming the old library, but this sucks) Agreed (that it sucks). The right thing to do is to get rid of it from qv4l2.pro. I can see two possible solutions: 1) add a logic at the build target that would do something like cat qv4l2.pro|sed s,\-L/usr/lib,,; 2) Don't use -L for the libraries. In this case, we'll need to add some logic to include either the .so or the .a version of the library, depending on the type of the libraries that were generated. We're not adding the -L/usr/lib, qmake is when it generates the Makefile, which is why I gave up after a quick attempt to fix it. Patches welcome :) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Stream degrades when going through CAM
Hej(Hello)! I'm the one that posted about non responding CAM earlier. I got another CAM I had laying around to work but now it's different problems. With this SMIT Conax CAM(Earlier it was a Dilog Conax) I can decode but the resulting mpg-stream degrades fast to something unwatchable. The testprogram I'm using is gnutv: $ gnutv -channels ~/my-channels-v4.conf -timeout 30 -out file t.mpg SVT1 Using frontend Philips TDA10023 DVB-C, type DVB-C status SCVYL | signal f0f0 | snr f3f3 | ber 000f | unc 00ec | FE_HAS_LOCK CAM Application type: 01 CAM Application manufacturer: cafe CAM Manufacturer code: babe CAM Menu string: Conax Conditional Access CAM supports the following ca system ids: 0x0b00 Received new PMT - sending to CAM... The recording always starts up nice but after some time it gets blocky artifacts and mplayer starts outputing errors. These artifacts increases almost exponential making this 30 second recording unwatchable very fast. This of course does not happen when the CAM isn't inserted. So my question is. Is there something in the driver talking with the CAM that degrades the stream? It's almost like when the errors starts displaying it gets more worse by the second. Other errors I see with this CAM inserted are PMT/NIT/STD filter timeouts when scanning with w_scan and filter timeouts(one or many pids) with scan resulting in channels not being found. Other runs may find the missing channels but then others are missing. Sometimes a run completes without errors and all channels are found. If the CAM is not inserted then I do not see these errors. All tests done with the same non-encrypted channel. (encrypted channels show the same problems. HD Channels degrades faster than SD.) If someone with knowledge could help me it would be great. I sure do want to get this working. It is working, sort of. I does decode so something is getting through the CAM but not for long. I did try to search the web and mailing list and I did find people with similar errors all the way back to 2006. The hardware I got is a mystique DVB-C Card but it seems to a KNC1 TV-Station MK3 clone. 08:01.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) Subsystem: KNC One Device [1894:0028] Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fbeffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av The CAM is a SMIT CONAX. Kernel Used: 2.6.38(2.6.38-11-generic. Ubuntu 11.04 SMP) Drivers tested: from latest media_build git -- 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] drivers/media: fix dependencies in video mt9t001/mt9p031
Em 06-10-2011 00:02, Stephen Rothwell escreveu: Hi Mauro, On Fri, 30 Sep 2011 15:38:13 -0700 Randy Dunlaprdun...@xenotime.net wrote: On 09/30/11 14:34, Paul Gortmaker wrote: Both mt9t001.c and mt9p031.c have two identical issues, those being that they will need module.h inclusion for the upcoming cleanup going on there, and that their dependencies don't limit selection of configs that will fail to compile as follows: drivers/media/video/mt9p031.c:457: error: implicit declaration of function ‘v4l2_subdev_get_try_crop’ drivers/media/video/mt9t001.c:787: error: ‘struct v4l2_subdev’ has no member named ‘entity’ The related config options are CONFIG_MEDIA_CONTROLLER and CONFIG_VIDEO_V4L2_SUBDEV_API. Looking at the code, it appears that the driver was never intended to work without these enabled, so add a dependency on CONFIG_VIDEO_V4L2_SUBDEV_API, which in turn already has a dependency on CONFIG_MEDIA_CONTROLLER. Reported-by: Randy Dunlaprdun...@xenotime.net Signed-off-by: Paul Gortmakerpaul.gortma...@windriver.com Acked-by: Randy Dunlaprdun...@xenotime.net Ping? Sorry, I was assuming that this patch would be going together with the other module.h trees. I'll apply it on my tree. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH 1/7] Rename files to match the names of the libraries
Applied :-) -- 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] Merge v4l-utils. dvb-apps and mediactl to media-utils.git
Em 07-10-2011 15:08, Manu Abraham escreveu: On Thu, Oct 6, 2011 at 5:53 PM, Hans Verkuilhverk...@xs4all.nl wrote: Currently we have three repositories containing libraries and utilities that are relevant to the media drivers: dvb-apps (http://linuxtv.org/hg/dvb-apps/) v4l-utils (http://git.linuxtv.org/v4l-utils.git) media-ctl (git://git.ideasonboard.org/media-ctl.git) It makes no sense to me to have three separate repositories, one still using mercurial and one that isn't even on linuxtv.org. We had a discussion earlier on the same subject wrt dvb-apps and the decision at that time was against a merge. That decision still holds. Yes, years ago when v4l-utils tree were created. Since them, there was several major releases of it, and not a single release of dvb-apps, with, btw, still lacks proper support for DVB APIv5. So, why not discuss it again? Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
make error
Hello, I tried to compile the very latest git of v4l-utils. But, I got an error; [...] g++ -m64 -o qv4l2 qv4l2.o general-tab.o ctrl-tab.o v4l2-api.o capture-win.o moc_qv4l2.o moc_general-tab.o moc_capture-win.o qrc_qv4l2.o-L/usr/lib64 -L../../lib/libv4l2 -lv4l2 -L../../lib/libv4lconvert -lv4lconvert -lrt -L../libv4l2util -lv4l2util -ldl -ljpeg -lQtGui -L/usr/lib64 -L/usr/X11R6/lib64 -lQtCore -lpthread qv4l2.o: In function `ApplicationWindow::setDevice(QString const, bool)': /tmp/source/v4l-utils/utils/qv4l2/qv4l2.cpp:156: undefined reference to `libv4l2_default_dev_ops' collect2: ld returned 1 exit status Any hint? Thanks in advance. PS. My system 1. OS : openSUSE 11.3 3.0.6-1.1-default #1 SMP x86_64 GNU/Linux 2. gcc : gcc (SUSE Linux) 4.5.3 20110428 [gcc-4_5-branch revision 173117] 3. ld : GNU ld (GNU Binutils; devel:gcc / openSUSE_11.3) 2.21.1 Regards, --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ Bill! You married with Computers. Not with Me! No..., with money. -- 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] Merge v4l-utils. dvb-apps and mediactl to media-utils.git
On Sat, Oct 8, 2011 at 5:42 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 07-10-2011 15:08, Manu Abraham escreveu: On Thu, Oct 6, 2011 at 5:53 PM, Hans Verkuilhverk...@xs4all.nl wrote: Currently we have three repositories containing libraries and utilities that are relevant to the media drivers: dvb-apps (http://linuxtv.org/hg/dvb-apps/) v4l-utils (http://git.linuxtv.org/v4l-utils.git) media-ctl (git://git.ideasonboard.org/media-ctl.git) It makes no sense to me to have three separate repositories, one still using mercurial and one that isn't even on linuxtv.org. We had a discussion earlier on the same subject wrt dvb-apps and the decision at that time was against a merge. That decision still holds. Yes, years ago when v4l-utils tree were created. Since them, there was several major releases of it, and not a single release of dvb-apps, with, btw, still lacks proper support for DVB APIv5. So, why not discuss it again? - dvb-apps is a repository consisting of simple stand-alone utils, basically meant for raw tests alone. (these tiny test apps don't have any external dependencies, so there exists no issues regarding packaging. for such a development model, a merge with a repository having other dependencies, this merge concept doesn't work well) In fact your own example repository with --disable this --enable that implies that, one needs to download the whole thing, altogether. I don't need to download things that's irrelevant to me. - a repository and how it works depends on the people working with it. (It depends on the comfortability of the people working with/maintaining it. It was found that the existing model works well and needs no change) - just simply making a release number, doesn't make a new release. (That said, a release is very near) - I don't see any significant contributions either from Hans V, the proposer for the merger of dvb-apps, or from you. - API v5 is severely broken in many senses and unusable in the way it is supposed to be used, it is still worked around using the v3 API (I will address this broken issue and try to have a fix in another mail) -- 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: [media-ctl PATCH 1/7] Rename files to match the names of the libraries
On Sat, Oct 08, 2011 at 01:53:07PM +0200, Laurent Pinchart wrote: Applied :-) Thanks! -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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] af9013 Extended monitoring in set_frontend.
On Sat, 2011-10-08 at 09:46 +1100, Jason Hecker wrote: Try this patch, it should stop start up corruption on the same frontend. Thanks. I'll try it today. Have you been able to reproduce any of the corruption issues I and others are having? Yes , I left it recording various programmes overnight, but the symptoms come and go. I noticed last night some recordings on the same card had different levels of corruption depending on the order of tuning Tuner A then tuner B : Tuner A was heavily corrupted. Tuner B was a fine. Tuner B then tuner A: Tuner A had a small corruption every few seconds and the show was watchable, Tuner B was fine. It seems like a lagging effect, as if the devices firmware is slowing down. -- 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] af9013 Extended monitoring in set_frontend.
2011/10/8 Jason Hecker jwhec...@gmail.com: Try this patch, it should stop start up corruption on the same frontend. Thanks. I'll try it today. Have you been able to reproduce any of the corruption issues I and others are having? I noticed last night some recordings on the same card had different levels of corruption depending on the order of tuning Tuner A then tuner B : Tuner A was heavily corrupted. Tuner B was a fine. Tuner B then tuner A: Tuner A had a small corruption every few seconds and the show was watchable, Tuner B was fine. Thanks again, I try the patch and it works well last nigh. This morning one tuner is getting pixeled images and the other can not LOCK. This is the kernel messages: # tail /var/log/messages Oct 8 14:16:06 htpc kernel: [45025.328902] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.333147] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.333637] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.490524] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.491014] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.642858] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.647477] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.647970] mxl5005s I2C write failed Oct 8 14:16:09 htpc kernel: [45027.806477] mxl5005s I2C write failed Oct 8 14:16:09 htpc kernel: [45027.806969] mxl5005s I2C write failed I try to increase the signal timeout from 1000 to 2000 ms and the tuning timeout from 3000 to 6000 ms on mythbackend. Which will be the best value for the Kworld 399U? Thank for your great work on this device. Best regards! -- Josu Lazkano -- 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] af9013 Extended monitoring in set_frontend.
On Sat, 2011-10-08 at 15:13 +0200, Josu Lazkano wrote: 2011/10/8 Jason Hecker jwhec...@gmail.com: Try this patch, it should stop start up corruption on the same frontend. Thanks. I'll try it today. Have you been able to reproduce any of the corruption issues I and others are having? I noticed last night some recordings on the same card had different levels of corruption depending on the order of tuning Tuner A then tuner B : Tuner A was heavily corrupted. Tuner B was a fine. Tuner B then tuner A: Tuner A had a small corruption every few seconds and the show was watchable, Tuner B was fine. Thanks again, I try the patch and it works well last nigh. This morning one tuner is getting pixeled images and the other can not LOCK. This is the kernel messages: # tail /var/log/messages Oct 8 14:16:06 htpc kernel: [45025.328902] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.333147] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.333637] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.490524] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.491014] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.642858] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.647477] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.647970] mxl5005s I2C write failed Oct 8 14:16:09 htpc kernel: [45027.806477] mxl5005s I2C write failed Oct 8 14:16:09 htpc kernel: [45027.806969] mxl5005s I2C write failed I try to increase the signal timeout from 1000 to 2000 ms and the tuning timeout from 3000 to 6000 ms on mythbackend. I have left these at the default settings Which kernels are you all running? uname -rv I think replicate your systems on my test pc. -- 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] af9013 Extended monitoring in set_frontend.
2011/10/8 Malcolm Priestley tvbox...@gmail.com: On Sat, 2011-10-08 at 15:13 +0200, Josu Lazkano wrote: 2011/10/8 Jason Hecker jwhec...@gmail.com: Try this patch, it should stop start up corruption on the same frontend. Thanks. I'll try it today. Have you been able to reproduce any of the corruption issues I and others are having? I noticed last night some recordings on the same card had different levels of corruption depending on the order of tuning Tuner A then tuner B : Tuner A was heavily corrupted. Tuner B was a fine. Tuner B then tuner A: Tuner A had a small corruption every few seconds and the show was watchable, Tuner B was fine. Thanks again, I try the patch and it works well last nigh. This morning one tuner is getting pixeled images and the other can not LOCK. This is the kernel messages: # tail /var/log/messages Oct 8 14:16:06 htpc kernel: [45025.328902] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.333147] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.333637] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.490524] mxl5005s I2C write failed Oct 8 14:16:06 htpc kernel: [45025.491014] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.642858] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.647477] mxl5005s I2C write failed Oct 8 14:16:08 htpc kernel: [45027.647970] mxl5005s I2C write failed Oct 8 14:16:09 htpc kernel: [45027.806477] mxl5005s I2C write failed Oct 8 14:16:09 htpc kernel: [45027.806969] mxl5005s I2C write failed I try to increase the signal timeout from 1000 to 2000 ms and the tuning timeout from 3000 to 6000 ms on mythbackend. I have left these at the default settings Which kernels are you all running? uname -rv I think replicate your systems on my test pc. Hello again, this is my kernel: $ uname -rv 2.6.32-5-686 #1 SMP Fri Sep 9 20:51:05 UTC 2011 This is a Debian Squeeze system. Regards. -- Josu Lazkano -- 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] af9013 Extended monitoring in set_frontend.
I have been following that discussion and hoping you would finally find out the reason. But I want to point out few things; * .set_frontend() is called only when channel changed * .set_params() is called only when channel changed * there is no I2C traffic for tuner after channel changed * there is I2C traffic to tuner only when channel is changed Since generally changes to .set_frontend() will not have effect in normal use, when both devices are already streaming. Only in case of lock is missed and re-tune initialized or channel changed. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
群发软件+买家搜索机+最新广交会买家、海关数据,B2B询盘买家500万。
群发软件+买家搜索机+109届广交会买家、展会买家、海关数据,B2B询盘买家500万。
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，最新全球买家库,共451660条数据。
3，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
4，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
5，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
6，60.8万条最新国外B2B买家询盘。
7，2009年海关提单数据piers版数据 1千万。
8，群发软件，群发软件的部署与安装。
共 500万个买家，每个均有Email.
保证每天都有买家回复。
保证每天都有买家回复。
要的抓紧联系QQ: 1339625218或者立即回复邮箱: 1339625...@qq.com
要的抓紧联系QQ: 1339625218或者立即回复邮箱: 1339625...@qq.com
要的抓紧联系QQ: 1339625218或者立即回复邮箱: 1339625...@qq.com
诚信为本，如果不信任本人,可以走淘宝交易,收货验证后再付款,这是对您最好的保障了。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: omap3-isp status
Hi, On Friday 07 October 2011 11:31:46 Javier Martinez Canillas wrote: On Fri, Oct 7, 2011 at 10:54 AM, Enrico wrote: On Thu, Oct 6, 2011 at 6:05 PM, Javier Martinez Canillas wrote: On Thu, Oct 6, 2011 at 5:25 PM, Enrico wrote: - i don't see Deepthy patches, it seems to be based on the pre-Deepthy-patches driver and fixed (not that this is a bad thing!); i say this because, like Gary, i'm interested in a possible forward porting to a more recent kernel so i was searching for a starting point I didn't know there was a more recent version of Deepthy patches, Since they are not yet in mainline we should decide if we work on top of that or on top of mainline. Deepthy patches are very good to separate bt656 and non-bt656 execution inside the ISP, also add a platform data variable to decide which mode has to be used. But reading the documentation and from my experimental validation I think that there are a few things that can be improved. First the assumption that we can use FLDSTAT to check if a frame is ODD or EVEN I find to not always be true. Also I don't know who sets this value since in the TRM always talks as it is only used with discrete syncs. Yes about FLDSTAT i noticed the same thing. And that's why we need someone that knows the ISP better to help us Great, good to know that I'm not the only one that noticed this behavior. Also, I don't think that we should change the ISP CCDC configuration inside the VD0 interrupt handler. Since the shadowed registers only can be accessed during a frame processing, or more formally the new values are taken at the beginning of a frame execution. By the time we change for example the output address memory for the next buffer in the VD0 handler, the next frame is already being processed so that value won't be used for the CCDC until that frame finish. So It is not behaving as the code expect, since for 3 frames the CCDC output memory address will be the same. That is why I move most of the logic to the VD1 interrupt since there the current frame didn't finish yet and we can configure the CCDC for the next frame. But to do that the buffer for the next frame and the releasing of the last buffer can't happen simultaneously, that is why I decouple these two actions. Again, this is my own observations and what I understood from the TRM and I could be wrong. I can't comment on that, i hope Laurent or Deepthy will join the discussion... I second you on that, we need someone who knows the ISP better than we do. I have to fix this anyway, so it is better if I can do it the right way and the code gos upstream, so we don't have to internally maintain a separate patch-set and forward port for each kernel release we do. Two quick comments, as I haven't had time to look into this recently. 1. I've updated the omap3isp-omap3isp-yuv branch with a new CCDC YUV support patch which should (hopefully) configure the bridge automatically and report correct formats at the CCDC output. The patch hasn't been tested as I still don't have access to YUV hardware. 2. Could you guys please rebase all your patches on top of the omap3isp- omap3isp-yuv branch ? I will then review them. - i don't think that adding the priv field in v4l2-mediabus.h will be accepted, and since it is related to the default cropping you added i think it can be dropped and just let the user choose the appropriate cropping Yes, probably is too much of a hack, but I didn't know of another way that the subdev could report to the ISP of the standard and since v4l2_pix_format has also a priv field, I think it could be at least a temporary solution (remember that we want this to work first and then we plan to do it right for upstream submission). ...and my hope continues here. -- 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: omap3-isp status
On Sat, Oct 8, 2011 at 5:51 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi, On Friday 07 October 2011 11:31:46 Javier Martinez Canillas wrote: On Fri, Oct 7, 2011 at 10:54 AM, Enrico wrote: On Thu, Oct 6, 2011 at 6:05 PM, Javier Martinez Canillas wrote: On Thu, Oct 6, 2011 at 5:25 PM, Enrico wrote: - i don't see Deepthy patches, it seems to be based on the pre-Deepthy-patches driver and fixed (not that this is a bad thing!); i say this because, like Gary, i'm interested in a possible forward porting to a more recent kernel so i was searching for a starting point I didn't know there was a more recent version of Deepthy patches, Since they are not yet in mainline we should decide if we work on top of that or on top of mainline. Deepthy patches are very good to separate bt656 and non-bt656 execution inside the ISP, also add a platform data variable to decide which mode has to be used. But reading the documentation and from my experimental validation I think that there are a few things that can be improved. First the assumption that we can use FLDSTAT to check if a frame is ODD or EVEN I find to not always be true. Also I don't know who sets this value since in the TRM always talks as it is only used with discrete syncs. Yes about FLDSTAT i noticed the same thing. And that's why we need someone that knows the ISP better to help us Great, good to know that I'm not the only one that noticed this behavior. Also, I don't think that we should change the ISP CCDC configuration inside the VD0 interrupt handler. Since the shadowed registers only can be accessed during a frame processing, or more formally the new values are taken at the beginning of a frame execution. By the time we change for example the output address memory for the next buffer in the VD0 handler, the next frame is already being processed so that value won't be used for the CCDC until that frame finish. So It is not behaving as the code expect, since for 3 frames the CCDC output memory address will be the same. That is why I move most of the logic to the VD1 interrupt since there the current frame didn't finish yet and we can configure the CCDC for the next frame. But to do that the buffer for the next frame and the releasing of the last buffer can't happen simultaneously, that is why I decouple these two actions. Again, this is my own observations and what I understood from the TRM and I could be wrong. I can't comment on that, i hope Laurent or Deepthy will join the discussion... I second you on that, we need someone who knows the ISP better than we do. I have to fix this anyway, so it is better if I can do it the right way and the code gos upstream, so we don't have to internally maintain a separate patch-set and forward port for each kernel release we do. Two quick comments, as I haven't had time to look into this recently. 1. I've updated the omap3isp-omap3isp-yuv branch with a new CCDC YUV support patch which should (hopefully) configure the bridge automatically and report correct formats at the CCDC output. The patch hasn't been tested as I still don't have access to YUV hardware. Hello Laurent, I'm glad to see that you are joining the thread :) 2. Could you guys please rebase all your patches on top of the omap3isp- omap3isp-yuv branch ? I will then review them. Yes, I'll cook a patch today on top on your omap3isp-yuv and send for review. I won't be able to test neither since I don't have proper hardware at home. But at least you will get an idea of the approach we are using to solve this and can point possible flaws. - i don't think that adding the priv field in v4l2-mediabus.h will be accepted, and since it is related to the default cropping you added i think it can be dropped and just let the user choose the appropriate cropping Yes, probably is too much of a hack, but I didn't know of another way that the subdev could report to the ISP of the standard and since v4l2_pix_format has also a priv field, I think it could be at least a temporary solution (remember that we want this to work first and then we plan to do it right for upstream submission). ...and my hope continues here. -- Regards, Laurent Pinchart Thanks a lot for your time. -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Oct 8 19:00:17 CEST 2011 git hash:e30528854797f057aa6ffb6dc9f890e923c467fd gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] af9013 Extended monitoring in set_frontend.
Which kernels are you all running? 2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04) -- 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] subdevice PM: .s_power() deprecation?
On Mon, Oct 03, 2011 at 12:57:10PM +0200, Guennadi Liakhovetski wrote: Hi all Hi Guennadi, Thanks for a thoughtful writing on subdev PM! (The original .s_power() author added to cc;-)) Here comes one more Request for Discussion from me. Short: on what events, at which level and how shall subdevice PM be envoked? Subdevices can have varying and arbitrarily complex Power Management methods. On-SoC subdevices would typically be powered on and off by writing to some system registers. External subdevices (sensors etc.) can be powered on or off by something as simple as a GPIO, or can use several power regulators, supplying power to different device circuits. This means, a part of this knowledge belongs directly to the driver, while another part of it comes from platform data. The driver itself knows, whether it can control device's power, using internal capabilities, or it has to request a certain number of regulators. In the latter case, perhaps, it would be sane to assume, that if a certain regulator is not available, then the respective voltage is supplied by the system statically. When to invoke? Subdeices can be used in two cases: for configuration and for data processing (streaming). For configuration the driver can choose one of two approaches: (1) cache all configuration requests and only execute them on STREAMON. Advantages: (a) the device can be kept off all the time during configuration, (b) the order is unimportant: the driver only stores values and applies them in the correct order. Disadvantages: (a) if the result of any such operation cannot be fully predicted by the driver, it cannot be reported to the user immediately after the operation execution but only at the STREAMON time (does anyone know any such volatile operations?), (b) the order is lost (is this important?). (2) execute all operations immediately. Advantages and disadvantages: just invert those from (1) above. So far individual drivers decide themselves which way to go. This way only drivers themselves know, when and what parts of the device they have to power on and off for configuration. The only thing the bridge driver can be sure about is, that all the involved subdevices in the pipeline have to be powered on during streaming. But even then - maybe the driver can and wants to power the i2c circuitry off for that time? The bridge driver can't (nor should) know about the power management requirements of random subdevs. The name of the s_power op is rather poitless in its current state. The power state of the subdev probably even never matters to the bridge --- or do we really have an example of that? In my opinion the bridge driver should instead tell the bridge drivers what they can expect to hear from the bridge --- for example that the bridge can issue set / get controls or fmt ops to the subdev. The subdev may or may not need to be powered for those: only the subdev driver knows. This is analogous to opening the subdev node from user space. Anything else except streaming is allowed. And streaming, which for sure requires powering on the subdev, is already nicely handled by the s_stream op. What do you think? In practice the name of s_power should change, as well as possible implementatio on subdev drivers. All the above makes me think, that .s_power() methods are actually useless in the operation context. The bridge has basically no way to know, when and which parts of the subdevice to power on or off. Subdevice configuration is anyway always performed, using the driver, and for streaming all participating subdevices just have to be informed about streaming begin and end. The only pure PM activity, that subdevice drivers have to be informed about are suspends and resumes. Normal bus PM callbacks are not always usable in our case. E.g., you cannot use i2c PM, because i2c can well be resumed before the bridge and then camera sensors typically still cannot be accessed over i2c. Do you have a bridge that provides a clock to subdevs? The clock should be modelled in the clock framework --- yes, I guess there's still a way to go before that,s universally possible. Therefore I propose to either deprecate (and later remove) .s_power() and add .suspend() and .resume() instead or repurpose .s_power() to be _only_ used for system-wide suspending and resuming. Even for runtime PM the subdevice driver has all the chances to decide itself when and how to save power, so, again, there is no need to be called from outside. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add support to ITU-R BT.656 video data format
This patch-set aims to add support to the ISP CCDC driver to process interlaced video data in ITU-R BT.656 format. The patch-set contains the following patches: [PATCH 1/2] omap3isp: video: Decouple buffer obtaining and set ISP entities format [PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format The first patch decouples next frame buffer obtaining from the last frame buffer releasing. This change is needed by the second patch that moves most of the CCDC buffer management logic to the VD1 interrupt handler. This patch-set is a proof-of-concept and was only compile tested since I don't have the hardware to test right now. It is a forward porting, on top of Laurent's omap3isp-omap3isp-yuv tree, of the changes we made to the ISP driver to get interlaced video working. Also, the patch will brake other configurations since the resizer and previewer also make use of omap3isp_video_buffer() function that now has a different semantic. I'm posting even when the patch-set is not in a merge-able state so you can review what we were doing and make comments. These are not all our changes since we also modified the ISP to forward the [G | S]_FMT and [G | S]_STD V4L2 ioctl commands to the TVP5151 and to only copy the active lines, but those changes are not relevant with the ghosting effect. With these changes we could get the 25 fps but with some sort of artifacts on the images. I hope that together we can find a solution to this issue. Thanks a lot. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
The ITU-R BT.656 standard data format provides interlaced video data.
This patch adds to the ISP CCDC driver the ability to deinterlace the
video data and send progressive frames to user-space applications.
The changes are:
- Maintain two buffers (struct isp_buffer), current and last.
- Decouple next buffer obtaining from last buffer releasing.
- Move most of the logic to the VD1 interrupt handler since the
ISP is not busy there.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.c | 195 ++--
drivers/media/video/omap3isp/ispccdc.h |6 +
include/media/omap3isp.h |3 +
3 files changed, 146 insertions(+), 58 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index c25db54..fff1ae1 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -40,6 +40,7 @@
static struct v4l2_mbus_framefmt *
__ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -893,7 +894,7 @@ static void ccdc_config_outlineoffset(struct
isp_ccdc_device *ccdc,
ISPCCDC_SDOFST_FINV);
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FOFST_4L);
+ ISPCCDC_SDOFST_FOFST_1L);
switch (oddeven) {
case EVENEVEN:
@@ -1010,6 +1011,9 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1115,6 +1119,10 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
+ u32 nph;
+ u32 nlv;
+ u32 vd0;
+ u32 vd1;
pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad-entity);
@@ -1185,26 +1193,44 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
}
ccdc_config_imgattr(ccdc, ccdc_pattern);
+ if (pdata-bt656) {
+ vd0 = nlv = format-height / 2 - 1;
+ vd1 = format-height / 3 - 1;
+ nph = format-width * 2 - 1;
+ } else {
+ vd0 = nlv = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ nph = format-width - 1;
+ }
+
/* Generate VD0 on the last line of the image and VD1 on the
* 2/3 height line.
*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
+ isp_reg_writel(isp, (vd0 ISPCCDC_VDINT_0_SHIFT) |
+ (vd1 ISPCCDC_VDINT_1_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
- ((format-width - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
+ (nph ISPCCDC_HORZ_INFO_NPH_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
+ isp_reg_writel(isp, nlv ISPCCDC_VERT_LINES_NLV_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV0_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- isp_reg_writel(isp, (format-height - 1)
-ISPCCDC_VERT_LINES_NLV_SHIFT,
- OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
+ isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV1_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
+
+ if (pdata-bt656) {
+ ccdc_config_outlineoffset(ccdc, nph, EVENEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, EVENODD, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDODD, 1);
+ } else
+ ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0,
0);
/* CCDC_PAD_SOURCE_VP */
format = ccdc-formats[CCDC_PAD_SOURCE_VP];
@@ -1212,13 +1238,12 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
isp_reg_writel(isp, (0 ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
(format-width ISPCCDC_FMT_HORZ_FMTLNH_SHIFT),
[PATCH 1/2] omap3isp: video: Decouple buffer obtaining and set ISP entities format
The ISP driver release the last buffer (waking up the pending process)
before returning the next buffer to the caller. This is done on the VD0
interrupt handler. But, by the time the CCDC is executing the VD0 interrupt
handler some ISP registers like CCDC_SDR_ADDR are shadowed which means that
the values written to it will not take effect until the next frame starts.
We have to configure the CCDC during the processing of the current frame in
the VD1 interrupt handler. This means the next buffer obtaining and the
last buffer releasing occur at different moments. So we have to decouple
these two actions.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispvideo.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index cc73375..c2d4cd9 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -635,10 +635,6 @@ struct isp_buffer *omap3isp_video_buffer_next(struct
isp_video *video,
else
buf-vbuf.sequence = atomic_read(pipe-frame_number);
- buf-state = error ? ISP_BUF_STATE_ERROR : ISP_BUF_STATE_DONE;
-
- wake_up(buf-wait);
-
if (list_empty(video-dmaqueue)) {
if (queue-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
state = ISP_PIPELINE_QUEUE_OUTPUT
--
1.7.4.1
--
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] drivers/media: fix dependencies in video mt9t001/mt9p031
On Sat, Oct 8, 2011 at 6:52 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 06-10-2011 00:02, Stephen Rothwell escreveu: Hi Mauro, On Fri, 30 Sep 2011 15:38:13 -0700 Randy Dunlaprdun...@xenotime.net wrote: On 09/30/11 14:34, Paul Gortmaker wrote: Both mt9t001.c and mt9p031.c have two identical issues, those being that they will need module.h inclusion for the upcoming cleanup going on there, and that their dependencies don't limit selection of configs that will fail to compile as follows: drivers/media/video/mt9p031.c:457: error: implicit declaration of function ‘v4l2_subdev_get_try_crop’ drivers/media/video/mt9t001.c:787: error: ‘struct v4l2_subdev’ has no member named ‘entity’ The related config options are CONFIG_MEDIA_CONTROLLER and CONFIG_VIDEO_V4L2_SUBDEV_API. Looking at the code, it appears that the driver was never intended to work without these enabled, so add a dependency on CONFIG_VIDEO_V4L2_SUBDEV_API, which in turn already has a dependency on CONFIG_MEDIA_CONTROLLER. Reported-by: Randy Dunlaprdun...@xenotime.net Signed-off-by: Paul Gortmakerpaul.gortma...@windriver.com Acked-by: Randy Dunlaprdun...@xenotime.net Ping? Sorry, I was assuming that this patch would be going together with the other module.h trees. I'll apply it on my tree. Thanks. Since the files in question don't exist on mainline, there is no real way I can have it directly on the module.h tree. If your file(s) needed the export.h file, (which my tree creates) then I'd have carried it as a post-merge delta to get past the chicken-and-egg problem of who's new file comes 1st. But since your file really just needs module.h -- you can add it to your tree right away. Plus the Kconfig change I made really should be SOB by the folks who know the driver restrictions; I just made an educated guess. Paul. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-next in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Support for Sveon STV22 (IT9137)
This device identifies has IdProduct 0xe411 and is a clone of KWorld
UB499-2T T09(IT9137).
This patch simply adds support for this device.
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-09-24 05:45:14.0 +0200
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-10-08 08:23:15.789883877 +0200
@@ -320,6 +320,7 @@
#define USB_PID_TVWAY_PLUS0x0002
#define USB_PID_SVEON_STV200xe39d
#define USB_PID_SVEON_STV220xe401
+#define USB_PID_SVEON_STV22_IT9137 0xe411
#define USB_PID_AZUREWAVE_AZ6027 0x3275
#define USB_PID_TERRATEC_DVBS2CI_V1 0x10a4
#define USB_PID_TERRATEC_DVBS2CI_V2 0x10ac
diff --git a/drivers/media/dvb/dvb-usb/it913x.c b/drivers/media/dvb/dvb-usb/it913x.c
--- a/drivers/media/dvb/dvb-usb/it913x.c 2011-09-24 05:45:14.0 +0200
+++ b/drivers/media/dvb/dvb-usb/it913x.c 2011-10-08 08:32:00.388191986 +0200
@@ -533,6 +533,7 @@
static struct usb_device_id it913x_table[] = {
{ USB_DEVICE(USB_VID_KWORLD_2, USB_PID_KWORLD_UB499_2T_T09) },
+ { USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV22_IT9137) },
{} /* Terminating entry */
};
@@ -608,11 +609,14 @@
.rc_codes = RC_MAP_KWORLD_315U,
},
.i2c_algo = it913x_i2c_algo,
- .num_device_descs = 1,
+ .num_device_descs = 2,
.devices = {
{ Kworld UB499-2T T09(IT9137),
{ it913x_table[0], NULL },
},
+ { Sveon STV22 Dual DVB-T HDTV(IT9137),
+ { it913x_table[1], NULL },
+ },
}
};
