Re: [PATCH] ov772x: add support S_CROP operation.
Hi Morimoto-san, On Fri, 30 Jan 2009, morimoto.kunin...@renesas.com wrote: > > > I attached stupid 4 patches. > (snip) > > Thanks for the patches, please, give me a couple of days for review. > (snip) > >> Yes, I'm (going to be) reviewing them, as soon as I find some time. > > If you have not reviewed now, please use attached one. > It use more clever way I think. I'll have to think about it more, but the first impression is - this wouldn't work. At the moment we use the same soc-camera API call set_fmt for both S_FMT and S_CROP calls. But it you look in various instance drivers - host and camera - you will see, that almost all of them have a test "if (pixfmt)," i.e., they have to differentiate between the two cases. And not only because with pixfmt == 0 they cannot configure the stack completely, but because the meaning of these two calls even just with respect to geometry is different: S_FMT specifies scaling, whereas S_CROP preserves the current scaling and only specifies a window using the current scaled coordinates. So, you have to be able to differentiate. The original mt9m001 and mt9v022 drivers didn't support scaling, so, for they just used cropping for both, but the recently added mt9t031 does support scaling, so, it is indeed important. Not sure about mt9m111, and yours ov772x and tw9910. Further, calling set_bus_param() from (or soc_camera_s_fmt_vid_cap()) from S_CROP is not enough too. This lets the capture.c example run, but, I think, we should be able to run with no configuration at all - even without a S_CROP. So, some default configuration has to be set up on open() or on STREAMON if none is set yet (current_fmt == NULL). So, you can either wit until I find time to address this, or try to do something along these lines yourself. But I'm not sure if I manage to propose anything meaningful before FOSDEM (next weekend), so, this might take up to two weeks. But, I think, we have a bit of time before the 2.6.30 merge window:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] bttv driver improvements
On Thu, Jan 29, 2009 at 8:19 PM, Trent Piepho wrote: > Mauro, > > I haven't been able to test this code. It seems my bt848 card doesn't work > with my SATA controller and I sort of need the latter to access the > harddrive. But I think everything should work. It cuts the the bttv > driver to less than half its current size. > > A number of the changes are for specialized cards that likely have few if > any users left. I'm pretty sure some have been broken for quite a while now. > > Please pull from http://linuxtv.org/hg/~tap/bttv > > for the following 11 changesets: > > 01/11: bttv: norm value should be unsigned > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=50f1e731724a > > 02/11: bttv: Fix TDA9880 norm setting code > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=57e9059c7351 > > 03/11: bttv: make tuner card info more consistent > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=e00ad34122b7 > > 04/11: bttv: store card database more efficiently > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=01eb02aea459 > > 05/11: bttv: rework the way digital inputs are indicated > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=0478bab75dc0 > > 06/11: bttv: clean up mux code for IVC-120G > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=c71a94680ca0 > > 07/11: bttv: fix external mux for PHYTEC VD-009 > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=67a52d2c6376 > > 08/11: bttv: fix external mux for RemoteVision MX > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=d2f23dd03aef > > 09/11: bttv: clean up mux code for IDS Eagle > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=944eeb814dd8 > > 10/11: bttv: shrink muxsel data in card database > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=d62cf6dd3da6 > > 11/11: bttv: dynamically allocate device data > http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=b99081ff66cf > > > bttv-cards.c | 1323 > ++ > bttv-driver.c | 90 +-- > bttv-i2c.c|6 > bttv-if.c | 18 > bttv-risc.c |4 > bttv-vbi.c|2 > bttv.h| 84 ++- > bttvp.h | 19 > 8 files changed, 640 insertions(+), 906 deletions(-) > > Thanks, > Trent > -- > 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 > Hello Trent, Perhaps I am misunderstanding what you said in this email, but are you submitting a PULL request for 1500 lines of code that have had no testing? Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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] Broken Tuning on Wintv Nova HD S2
В сообщении от 30 January 2009 02:10:18 gimli написал(а): > Acked-by : Edgar Hucek Explanation of using Signed-off-by, Acked-by and Tested-by. http://kerneltrap.org/node/8329 Sorry yet, but it seems Tested-by :) Anyway, I already included your Tested-by clause. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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] Broken Tuning on Wintv Nova HD S2
В сообщении от 30 January 2009 02:10:18 gimli написал(а): > Igor M. Liplianin schrieb: > > On 29 января 2009, "Igor M. Liplianin" wrote: > >> Igor M. Liplianin schrieb: > >>> п▓ я│п╬п╬п╠я┴п╣п╫п╦п╦ п╬я┌ 29 January 2009 20:07:32 gimli > >>> п╫п╟п©п╦я│п╟п╩(п╟): > Hi, > > your patch seems to work. > >>> > >>> If it works, then I prepare more simple patch. > >> > >> Hi, > >> > >> you can also put my : > >> > >> Signed-off-by: Edgar Hucek > >> > >> to the list. > >> > >> cu > >> > >> Edgar (gimli) Hucek > > > > Does simple patch work ? > > I need your Acked-by :) > > Acked-by : Edgar Hucek > -- > 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 OK Igor -- 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/~mkrufky/fixes
Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/fixes for the following small fixes: - dib0700: add data debug to dib0700_i2c_xfer_new - tveeprom: update to include Hauppauge tuners 151-155 - sms1xxx: add missing usb id 2040:2011 dvb/dvb-usb/dib0700_core.c |7 +++ dvb/siano/sms-cards.c |2 ++ video/tveeprom.c |5 + 3 files changed, 14 insertions(+) Cheers, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
On Thu, 29 Jan 2009 18:44:44 -0500 CityK wrote: > CityK wrote: > > Hans Verkuil wrote: > > > >> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ > >> that calls 'enables the tuner' before loading the module. See if that > >> works. > >> > >> ... > >> > >> I suspect that this might fix the bug. > >> > > > > Hans, > > > > ... it works !! > > I may have found a problem (tvtime works perfectly; other analogue apps > like xawtv/motv, kdetv ... are not working properly now -- you can do a > channel scan with them and everything_appears_to work as expected (i.e. > channels are found and are displayed/played correctly during the scan), > BUT as soon as you actually go to use the app, it does not work > (static). It appears that the issue is related to dga and Xv (as > passing the -nodga -noxv options with xawtv/motv actually works ... > kdetv is hit and miss -- sometimes the v4l1 mode works, other times it > doesn't (likely a pattern there but haven't found it yet), but v4l2 > plugin does NOT work at all (static)). In addition, the nvidia driver > is NOT the source of the error, as the same occurs under the nv driver > as well. I've seen this issue happening with nvidia proprietary driver, on an old machine I had. the open source nv driver were better (e.g. the bug were much less frequent than with the proprietary one). This kind of trouble is not related to the kernel driver. > Will have to do another test to confirm whether this error was > introduced in the KWorld repo. Consequently: > > > Mauro Carvalho Chehab wrote: > > > >> Hans Verkuil wrote: > >> > >>> Note that Mauro merged my saa7134 changes, so these are now in the master > >>> repository. > >>> > >>> > >> Yes. We need to fix it asap, to avoid regressions. It is time to review > >> also > >> the other codes that are touching on i2c gates at _init2(). > >> > >> > > > > Thoughts on merging the changes from Hans' KWorld repo? > > If there were any thoughts on this, please put them on hold until I can > test further. Ok. FYI, I've committed that changeset I've proposed. Could you please confirm that the driver is working with the v4l-dvb tree. 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: Howto obtain sysfs-pathes for DVB devices?
Hi, Am Mittwoch, den 28.01.2009, 16:46 +0100 schrieb Carsten Meier: > Hello again, > > now I've managed to obtain syfs-pathes for v4l2-devices. But what about > dvb? I haven't found something like bus_info in the dvb-api-docs. (I'm > new to it) Any hints for this? > > Thanks, > Carsten I'm also still new on it ... Maybe anything useful here? cat /sys/class/dvb/dvb0.frontend0/uevent MAJOR=212 MINOR=0 PHYSDEVPATH=/devices/pci:00/:00:08.0/:01:07.0 PHYSDEVBUS=pci PHYSDEVDRIVER=saa7134 Cheers, Hermann -- 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] ov772x: add support S_CROP operation.
Dear Guennadi > > I attached stupid 4 patches. (snip) > Thanks for the patches, please, give me a couple of days for review. (snip) >> Yes, I'm (going to be) reviewing them, as soon as I find some time. If you have not reviewed now, please use attached one. It use more clever way I think. 0001-soc_camera-s_crop-call-s_fmt_vid_cap-directly.patch Description: Binary data Best regards -- Kuninori Morimoto
[PULL] bttv driver improvements
Mauro, I haven't been able to test this code. It seems my bt848 card doesn't work with my SATA controller and I sort of need the latter to access the harddrive. But I think everything should work. It cuts the the bttv driver to less than half its current size. A number of the changes are for specialized cards that likely have few if any users left. I'm pretty sure some have been broken for quite a while now. Please pull from http://linuxtv.org/hg/~tap/bttv for the following 11 changesets: 01/11: bttv: norm value should be unsigned http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=50f1e731724a 02/11: bttv: Fix TDA9880 norm setting code http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=57e9059c7351 03/11: bttv: make tuner card info more consistent http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=e00ad34122b7 04/11: bttv: store card database more efficiently http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=01eb02aea459 05/11: bttv: rework the way digital inputs are indicated http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=0478bab75dc0 06/11: bttv: clean up mux code for IVC-120G http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=c71a94680ca0 07/11: bttv: fix external mux for PHYTEC VD-009 http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=67a52d2c6376 08/11: bttv: fix external mux for RemoteVision MX http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=d2f23dd03aef 09/11: bttv: clean up mux code for IDS Eagle http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=944eeb814dd8 10/11: bttv: shrink muxsel data in card database http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=d62cf6dd3da6 11/11: bttv: dynamically allocate device data http://linuxtv.org/hg/~tap/bttv?cmd=changeset;node=b99081ff66cf bttv-cards.c | 1323 ++ bttv-driver.c | 90 +-- bttv-i2c.c|6 bttv-if.c | 18 bttv-risc.c |4 bttv-vbi.c|2 bttv.h| 84 ++- bttvp.h | 19 8 files changed, 640 insertions(+), 906 deletions(-) Thanks, Trent -- 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] Broken Tuning on Wintv Nova HD S2
Igor M. Liplianin schrieb: On 29 января 2009, "Igor M. Liplianin" wrote: Igor M. Liplianin schrieb: п▓ я│п╬п╬п╠я┴п╣п╫п╦п╦ п╬я┌ 29 January 2009 20:07:32 gimli п╫п╟п©п╦я│п╟п╩(п╟): Hi, your patch seems to work. If it works, then I prepare more simple patch. Hi, you can also put my : Signed-off-by: Edgar Hucek to the list. cu Edgar (gimli) Hucek Does simple patch work ? I need your Acked-by :) Acked-by : Edgar Hucek -- 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: KWorld ATSC 115 all static
CityK wrote: > Hans Verkuil wrote: > >> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ >> that calls 'enables the tuner' before loading the module. See if that >> works. >> >> ... >> >> I suspect that this might fix the bug. >> > > Hans, > > ... it works !! I may have found a problem (tvtime works perfectly; other analogue apps like xawtv/motv, kdetv ... are not working properly now -- you can do a channel scan with them and everything_appears_to work as expected (i.e. channels are found and are displayed/played correctly during the scan), BUT as soon as you actually go to use the app, it does not work (static). It appears that the issue is related to dga and Xv (as passing the -nodga -noxv options with xawtv/motv actually works ... kdetv is hit and miss -- sometimes the v4l1 mode works, other times it doesn't (likely a pattern there but haven't found it yet), but v4l2 plugin does NOT work at all (static)). In addition, the nvidia driver is NOT the source of the error, as the same occurs under the nv driver as well. Will have to do another test to confirm whether this error was introduced in the KWorld repo. Consequently: > Mauro Carvalho Chehab wrote: > >> Hans Verkuil wrote: >> >>> Note that Mauro merged my saa7134 changes, so these are now in the master >>> repository. >>> >>> >> Yes. We need to fix it asap, to avoid regressions. It is time to review also >> the other codes that are touching on i2c gates at _init2(). >> >> > > Thoughts on merging the changes from Hans' KWorld repo? If there were any thoughts on this, please put them on hold until I can test further. -- 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] Broken Tuning on Wintv Nova HD S2
В сообщении от 29 January 2009 23:36:43 Mika Laitio написал(а): > >> Edgar (gimli) Hucek > > > > Does simple patch work ? > > I need your Acked-by :) > > Hi, I have only saw one version of your patch in mailing list, > did you send the simpler version somewhere? > > Mika Sorry, send it to Edgar only. But it is unintentionally. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks # HG changeset patch # User Igor M. Liplianin # Date 1233253267 -7200 # Node ID 3542d1c1e03add577ce85175327701c552d14856 # Parent 4086371cea7b7f8b461e1a77513274aa43583c8c Bug fix: Restore HVR-4000 tuning. From: Igor M. Liplianin Some cards uses cx24116 LNB_DC pin for LNB power control, some not uses, some uses it different way, like HVR-4000. Signed-off-by: Igor M. Liplianin diff -r 4086371cea7b -r 3542d1c1e03a linux/drivers/media/dvb/frontends/cx24116.c --- a/linux/drivers/media/dvb/frontends/cx24116.c Sat Jan 17 17:23:31 2009 +0200 +++ b/linux/drivers/media/dvb/frontends/cx24116.c Thu Jan 29 20:21:07 2009 +0200 @@ -1184,7 +1184,12 @@ if (ret != 0) return ret; - return cx24116_diseqc_init(fe); + ret = cx24116_diseqc_init(fe); + if (ret != 0) + return ret; + + /* HVR-4000 needs this */ + return cx24116_set_voltage(fe, SEC_VOLTAGE_13); } /*
tm6010 : strange i2c
Hi, I am trying to make work my hauppauge HVR900H, and I start looking at http://linuxtv.org/hg/~mchehab/tm6010/ drivers and windows usb trace. After some experiment I found that the i2c is very strange : * for the zl10353 demodulator, the register read only seems to work if the register address is odd and we read at least 2 bytes[1]. And the windows driver seems to really do that according usb trace (read always 2 bytes at odd address). * the windows driver read the eeprom in the strange way : it use REQ_14_SET_GET_I2C_WR2_RDN, but setting the offset in the high byte of wIndex. And it does 16 bytes read, 1 bytes read for reading again the last 16th byte, and continue 16 bytes read, 1 byte read. Did the people that worked on the tm6000 driver saw that weird i2c ? Matthieu [1] Doing REQ_16_SET_GET_I2C_WR1_RDN on the demodulator with different register address and read size. 0051: 00 -- 0051: 00 -- 0052: 00 -- 0050: 00 -- 004f: 00 -- 0050: 00 -- 0051: 44 46 -- 0051: 44 46 -- 0052: 46 46 -- 0050: 46 46 -- 004f: 46 0c -- 0050: 0c 0c -- 0051: 44 46 15 0f -- 0051: 44 46 15 0f -- 0052: 0f 0f 00 00 -- 0050: 00 00 00 00 -- 004f: 00 0c 44 46 -- 0050: 46 46 00 00 -- 0051: 44 46 15 0f 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 -- 0052: 00 00 00 00 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 -- 004f: 00 0c 44 46 15 0f 00 00 -- 0050: 00 00 00 00 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 -- 0052: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 004f: 00 0c 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d -- 0050: 0d 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 0061: 4d 0a 0f 0f 0f 0f c2 00 00 80 00 00 00 00 00 00 -- 0051: 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 0d 00 0061: 4d 0a 0f 0f 0f 0f c2 00 00 80 00 00 00 00 00 00 -- 0052: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0062: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 004f: 00 0c 44 46 15 0f 00 00 00 00 00 48 00 75 0d 0d 005f: 0d 00 4d 0a 0f 0f 0f 0f c2 00 00 80 00 00 00 00 -- 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- -- 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: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
On Thu, 29 Jan 2009, Hans Verkuil wrote:
> On Thursday 29 January 2009 08:44:20 DongSoo Kim wrote:
> > Hello.
> >
> > > +#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
> > > v4l2_color_space_conversion) +#define VIDIOC_G_COLOR_SPACE_CONV
> > > _IOR('V', 84, struct v4l2_color_space_conversion)
> >
> > Do you mind if I ask a question about those ioctls?
> > Because as far as I understand, we can use VIDIOC_S_FMT ioctl to convert
> > colorspaces. Setting through colorspace member in v4l2_pix_format, we
> > could change output colorspace.
>
> Colorspace is read-only, you cannot set it. It just gives you the colorspace
> that the hardware uses by default.
Is there a reason it must be read-only?
> If you want to fully control the colorspace, then you need these ioctls.
I don't know about "fully". I don't see anything about gamma correction.
Since there is no documentation, it's also not clear if it can describe the
full range luma the bt848 and cx88 can produce.
--
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: [V4L2] EV control API for digital camera
Thank you. So if V4L2_CID_EXPOSURE is for Exposure Value control, I think there is no api for exposure metering. right? Actually many of APIs for camera are missing I guess. Cheers Nate 2009. 01. 30, 오전 3:35, Guennadi Liakhovetski 작성: [removed redhat list from CC] On Thu, 29 Jan 2009, DongSoo Kim wrote: Hello. When we take pictures, sometimes we don't get satisfied with the exposure of picture. Too dark or too bright. For that reason, we need to bias EV which represents Exposure Value. So..if I want to control digital camera module with V4L2 API, which API should I take for EV control? V4L2 document says that V4L2_CID_BRIGHTNESS is for picture brightness, but it is for "Image properties" and that "image" means the image frame of TV or PVR things.Am I right? There's also V4L2_CID_EXPOSURE If I may, can I use V4L2_CID_BRIGHTNESS for EV control of digital cameras? or..otherwise I should make a new API for that functionality. I'm little bit confused, because I think the brightness of picture could differ from exposure value of digital camera..help me ;( Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] Broken Tuning on Wintv Nova HD S2
Edgar (gimli) Hucek Does simple patch work ? I need your Acked-by :) Hi, I have only saw one version of your patch in mailing list, did you send the simpler version somewhere? Mika -- 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: cx88-dvb broken since 2.6.29-rc1
On Thu, 29 Jan 2009 22:10:12 +0100 Jean Delvare wrote: > Hi folks, > > I have a CX88-based DVB-T adapter which worked fine up to 2.6.28 but is > broken since 2.6.29-rc1 (and not fixed as off 2.6.29-rc3). The problem > is that /dev/dvb isn't created. Presumably the root cause is the > following in the kernel logs as the driver is loaded: I have already a pull request almost ready that will fix this issue. I'll likely send it today or tomorrow. 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
cx88-dvb broken since 2.6.29-rc1
Hi folks, I have a CX88-based DVB-T adapter which worked fine up to 2.6.28 but is broken since 2.6.29-rc1 (and not fixed as off 2.6.29-rc3). The problem is that /dev/dvb isn't created. Presumably the root cause is the following in the kernel logs as the driver is loaded: cx88/0: cx2388x v4l2 driver version 0.0.6 loaded cx8800 :02:04.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 cx88[0]: subsystem: 107d:665f, board: WinFast DTV1000-T [card=35,autodetected], frontend(s): 1 cx88[0]: TV tuner type 4, Radio tuner type -1 cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded intel8x0_measure_ac97_clock: measured 50862 usecs intel8x0: clocking to 48000 i2c-adapter i2c-1: adapter [cx88[0]] registered i2c-adapter i2c-1: master_xfer[0] W, addr=0x50, len=1 i2c-adapter i2c-1: master_xfer[0] R, addr=0x50, len=256 input: cx88 IR (WinFast DTV1000-T) as /devices/pci:00/:00:1e.0/:02:04.0/input/input5 cx88[0]/0: found at :02:04.0, rev: 5, irq: 21, latency: 32, mmio: 0xfc00 IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 cx88[0]/2: cx2388x 8802 Driver Manager cx88-mpeg driver manager :02:04.2: PCI INT A -> GSI 21 (level, low) -> IRQ 21 cx88[0]/2: found at :02:04.2, rev: 5, irq: 21, latency: 32, mmio: 0xfd00 IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs cx88/2: cx2388x dvb driver version 0.0.6 loaded cx88/2: registering cx8802 driver, type: dvb access: shared cx88[0]/2: subsystem: 107d:665f, board: WinFast DTV1000-T [card=35] cx88[0]/2: cx2388x based DVB/ATSC card [ cut here ] WARNING: at kernel/mutex.c:135 mutex_lock_nested+0x268/0x2b2() Hardware name: Modules linked in: cx88_dvb(+) cx88_vp3054_i2c videobuf_dvb dvb_core cx8802 cx8800 cx88xx snd_intel8x0 ir_common snd_ac97_codec snd_pcsp v4l2_common i2c_algo_bit videodev ac97_bus thermal tveeprom v4l1_compat v4l2_compat_ioctl32 snd_pcm btcx_risc processor snd_timer thermal_sys videobuf_dma_sg parport_pc 8139too snd videobuf_core parport sr_mod hwmon mii soundcore i2c_i801 cdrom button snd_page_alloc intel_agp iTCO_wdt sg sd_mod ehci_hcd uhci_hcd usbcore ext3 mbcache jbd ata_piix libata Pid: 1713, comm: modprobe Not tainted 2.6.29-rc3 #60 Call Trace: [] warn_slowpath+0xcd/0x11e [] ? restore_args+0x0/0x30 [] ? trace_hardirqs_on_caller+0x12e/0x17d [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] ? restore_args+0x0/0x30 [] ? _spin_unlock_irqrestore+0x45/0x4a [] ? vprintk+0x16a/0x3f5 [] ? _spin_unlock_irqrestore+0x45/0x4a [] ? vprintk+0x16a/0x3f5 [] ? videobuf_dvb_get_frontend+0x21/0x73 [videobuf_dvb] [] mutex_lock_nested+0x268/0x2b2 [] videobuf_dvb_get_frontend+0x21/0x73 [videobuf_dvb] [] cx8802_dvb_probe+0x113/0x1d61 [cx88_dvb] [] ? kmem_cache_alloc+0x66/0x90 [] ? trace_hardirqs_on+0xd/0xf [] cx8802_register_driver+0x1b0/0x229 [cx8802] [] ? dvb_init+0x0/0x2c [cx88_dvb] [] dvb_init+0x27/0x2c [cx88_dvb] [] _stext+0x33/0x151 [] ? trace_hardirqs_on+0xd/0xf [] sys_init_module+0xa0/0x1de [] system_call_fastpath+0x16/0x1b ---[ end trace c6ad9ed793b52080 ]--- BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] __list_add+0x1f/0x98 PGD 37b79067 PUD 3795d067 PMD 0 Oops: [#1] last sysfs file: /sys/devices/pci:00/:00:1e.0/modalias CPU 0 Modules linked in: cx88_dvb(+) cx88_vp3054_i2c videobuf_dvb dvb_core cx8802 cx8800 cx88xx snd_intel8x0 ir_common snd_ac97_codec snd_pcsp v4l2_common i2c_algo_bit videodev ac97_bus thermal tveeprom v4l1_compat v4l2_compat_ioctl32 snd_pcm btcx_risc processor snd_timer thermal_sys videobuf_dma_sg parport_pc 8139too snd videobuf_core parport sr_mod hwmon mii soundcore i2c_i801 cdrom button snd_page_alloc intel_agp iTCO_wdt sg sd_mod ehci_hcd uhci_hcd usbcore ext3 mbcache jbd ata_piix libata Pid: 1713, comm: modprobe Tainted: GW 2.6.29-rc3 #60 RIP: 0010:[] [] __list_add+0x1f/0x98 RSP: 0018:88003e4d5d38 EFLAGS: 00010046 RAX: RBX: 8800378f75e8 RCX: RDX: 8800378f75e8 RSI: RDI: 88003e4d5d88 RBP: 88003e4d5d58 R08: 0002 R09: 0001 R10: 88003ed670c0 R11: R12: R13: 88003e4d5d88 R14: a0072172 R15: 88003e4d5d88 FS: 7f9c626046f0() GS:80604020() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 378e2000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 1713, threadinfo 88003e4d4000, task 88003ed670c0) Stack: 8800378f75b0 0246 88003ed670c0 88003e4d5de8 8043ab28 a0072172 88003e473018 8800378f75e8 88003e4d5d88 88003e4d5d88 Call Trace: [] mutex_lock_nested+0xcf/0x2b2 [] ? v
Re: [linux-dvb] Broken Tuning on Wintv Nova HD S2
On 29 января 2009, "Igor M. Liplianin" wrote: > Igor M. Liplianin schrieb: > > п▓ я│п╬п╬п╠я┴п╣п╫п╦п╦ п╬я┌ 29 January 2009 20:07:32 gimli > > п╫п╟п©п╦я│п╟п╩(п╟): > >> Hi, > >> > >> your patch seems to work. > > > > If it works, then I prepare more simple patch. > > Hi, > > you can also put my : > > Signed-off-by: Edgar Hucek > > to the list. > > cu > > Edgar (gimli) Hucek Does simple patch work ? I need your Acked-by :) -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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] Support faulty USB IDs on DIBUSB_MC
matthieu castet wrote:
Hi Patrick,
Patrick Boettcher wrote:
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */{ USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the
driver to
allow it to work with a broken card. The better would be to have some
modprobe
option to force it to accept a certain USB ID as a valid ID for the
card.
The most correct way would be to reprogram the eeprom, by simply
writing to 0xa0 (0x50 << 1) I2C address... There was a thread on the
linux-dvb some time ago.
BTW dibusb_i2c_xfer seems to do things very dangerous :
it assumes that it get only write/read request or write request.
That means that read can be understood as write. For example a program
doing
file = open("/dev/i2c-x", O_RDWR);
ioctl(file, I2C_SLAVE, 0x50)
read(file, data, 10)
will corrupt the eeprom as it will be understood as a write.
Now that I think of that, I run sensors-detect on this machine, may be
this is what trash the eeprom ?
Matthieu
--
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: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
Thanks, Vaibhav Hiremath > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Friday, January 30, 2009 1:03 AM > To: Hiremath, Vaibhav > Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Jadav, > Brijesh R; Shah, Hardik > Subject: Re: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card > Support > > On Thursday 29 January 2009 20:22:30 hvaib...@ti.com wrote: > > From: Vaibhav Hiremath > > > > This is second version of OMAP3EVM Mulit-Media/Mass Market > > Daughter Card support. > > > > Fixes: > > - Cleaned unused header files, struct formating, and unused > > comments. > > - Pad/mux configuration handled in mux.ch > > - mux.ch related changes moved to seperate patch > > - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c > > to make more explicit. > > - Added some more meaningful name for Kconfig option > > > > TODO: > > - Camera sensor support (for future development). > > - Driver header file inclusion (dependency on ISP-Camera > patches) > > I am working with Sergio to seperate/move header file to > standard > > location. > > - Still need to fix naming convention for DC > > > > Tested: > > - TVP5146 (BT656) decoder interface on top of > > Sergio's ISP-Camera patches. > > - Loopback application, capturing image through TVP5146 > > and saving it to file per frame. > > What is the status of converting tvp5146 to v4l2_subdev? The longer > it takes > to convert it, the harder it will be now that you are starting to > use this > driver. v4l2_int_device should be phased out, preferably by 2.6.30. > > I'm more than happy to assist in this conversion, but please try to > do this > asap! > [Hiremath, Vaibhav] Hans, I understand your concerns here. The TVP driver has strong dependency on ISP-Camera driver (Master) and without which it really doesn't make sense atleast for me. So actually I was trying to finish the ISP-Camera with V4L2-int and then migrate everything to the sub-devices. I am working with Sergio to finish this as early as possible. As far as sub-device framework is concerned, we have taken pro-active steps. If I understand correctly Davinci team here has already started migrating to the sub-device framework and the patches are under review internally. Soon you will see some patches on v4L mailing list for this. > Thanks, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] Support faulty USB IDs on DIBUSB_MC
Hi Patrick,
Patrick Boettcher wrote:
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */{ USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the
driver to
allow it to work with a broken card. The better would be to have some
modprobe
option to force it to accept a certain USB ID as a valid ID for the card.
The most correct way would be to reprogram the eeprom, by simply writing
to 0xa0 (0x50 << 1) I2C address... There was a thread on the linux-dvb
some time ago.
Why not, I only don't want to maintain a patch for my device.
I wonder why didn't they use WP pin of the eeprom to avoid write.
Do you know what should be written.
After a quick search, I found [1]. Is that ok ?
Matthieu
[1]
EEPROM AddressContents
00xC0
1Vendor ID (VID) L
2Vendor ID (VID) H
3Product ID (PID) L
4Product ID (PID) H
5Device ID (DID) L
6Device ID (DID) H
7Configuration byte
--
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.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - gspca: fix compiler warning - pxa: compile only from 2.6.29 onwards. - v4l2: fix incorrect hue range check - v4l: remove unused I2C_DRIVERIDs. I've respun my patches against the latest v4l-dvb in order to fix the build errors. While working on qv4l2 I also discovered a Hue control range check bug that was copied-and-pasted into four drivers, I've fixed that as well. Thanks, Hans diffstat: linux/drivers/media/video/cs53l32a.c |1 - linux/drivers/media/video/cx18/cx18-av-core.c|2 +- linux/drivers/media/video/cx25840/cx25840-core.c |2 +- linux/drivers/media/video/gspca/t613.c |2 +- linux/drivers/media/video/m52790.c |1 - linux/drivers/media/video/saa5246a.c |1 - linux/drivers/media/video/saa5249.c |1 - linux/drivers/media/video/saa7115.c |2 +- linux/drivers/media/video/saa717x.c |3 +-- linux/drivers/media/video/tda7432.c |1 - linux/drivers/media/video/tda9840.c |1 - linux/drivers/media/video/tda9875.c |1 - linux/drivers/media/video/tea6415c.c |1 - linux/drivers/media/video/tea6420.c |1 - linux/drivers/media/video/tlv320aic23b.c |1 - linux/drivers/media/video/tvmixer.c |1 - linux/drivers/media/video/tvp5150.c |1 - linux/drivers/media/video/upd64031a.c|1 - linux/drivers/media/video/upd64083.c |1 - linux/drivers/media/video/vp27smpx.c |1 - linux/drivers/media/video/wm8739.c |1 - v4l/versions.txt |4 22 files changed, 9 insertions(+), 22 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
On Thursday 29 January 2009 20:22:30 hvaib...@ti.com wrote: > From: Vaibhav Hiremath > > This is second version of OMAP3EVM Mulit-Media/Mass Market > Daughter Card support. > > Fixes: > - Cleaned unused header files, struct formating, and unused > comments. > - Pad/mux configuration handled in mux.ch > - mux.ch related changes moved to seperate patch > - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c > to make more explicit. > - Added some more meaningful name for Kconfig option > > TODO: > - Camera sensor support (for future development). > - Driver header file inclusion (dependency on ISP-Camera patches) > I am working with Sergio to seperate/move header file to standard > location. > - Still need to fix naming convention for DC > > Tested: > - TVP5146 (BT656) decoder interface on top of > Sergio's ISP-Camera patches. > - Loopback application, capturing image through TVP5146 > and saving it to file per frame. What is the status of converting tvp5146 to v4l2_subdev? The longer it takes to convert it, the harder it will be now that you are starting to use this driver. v4l2_int_device should be phased out, preferably by 2.6.30. I'm more than happy to assist in this conversion, but please try to do this asap! Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] Broken Tuning on Wintv Nova HD S2
Igor M. Liplianin schrieb: В сообщении от 29 January 2009 20:07:32 gimli написал(а): Hi, your patch seems to work. If it works, then I prepare more simple patch. Hi, you can also put my : Signed-off-by: Edgar Hucek to the list. cu Edgar (gimli) Hucek -- 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
[REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
From: Vaibhav Hiremath This is second version of OMAP3EVM Mulit-Media/Mass Market Daughter Card support. Fixes: - Cleaned unused header files, struct formating, and unused comments. - Pad/mux configuration handled in mux.ch - mux.ch related changes moved to seperate patch - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c to make more explicit. - Added some more meaningful name for Kconfig option TODO: - Camera sensor support (for future development). - Driver header file inclusion (dependency on ISP-Camera patches) I am working with Sergio to seperate/move header file to standard location. - Still need to fix naming convention for DC Tested: - TVP5146 (BT656) decoder interface on top of Sergio's ISP-Camera patches. - Loopback application, capturing image through TVP5146 and saving it to file per frame. - Basic functionality of HSUSB Transceiver USB-83320 Signed-off-by: Brijesh Jadav Signed-off-by: Hardik Shah Signed-off-by: Vaibhav Hiremath --- arch/arm/mach-omap2/Kconfig |8 +- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3evm-dc-v4l.c | 348 +++ arch/arm/mach-omap2/board-omap3evm-dc.h | 42 4 files changed, 398 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc-v4l.c create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8fa650d..c1cf770 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -113,7 +113,7 @@ config MACH_OMAP_LDP bool "OMAP3 LDP board" depends on ARCH_OMAP3 && ARCH_OMAP34XX -config MACH_OMAP2EVM +config MACH_OMAP2EVM bool "OMAP 2530 EVM board" depends on ARCH_OMAP2 && ARCH_OMAP24XX @@ -125,6 +125,12 @@ config MACH_OMAP3EVM bool "OMAP 3530 EVM board" depends on ARCH_OMAP3 && ARCH_OMAP34XX +config MACH_OMAP3EVM_MMDC + bool "OMAP 3530 EVM Mass Market Daughter Card board" + depends on MACH_OMAP3EVM + help + Set this if you've got a Mass Market Daughter Card board. + config MACH_OMAP3_BEAGLE bool "OMAP3 BEAGLE board" depends on ARCH_OMAP3 && ARCH_OMAP34XX diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 631166d..45f52ca 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ usb-musb.o usb-ehci.o \ board-omap3evm-flash.o \ twl4030-generic-scripts.o +obj-$(CONFIG_MACH_OMAP3EVM_MMDC) += board-omap3evm-dc-v4l.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ usb-musb.o usb-ehci.o \ mmc-twl4030.o \ diff --git a/arch/arm/mach-omap2/board-omap3evm-dc-v4l.c b/arch/arm/mach-omap2/board-omap3evm-dc-v4l.c new file mode 100644 index 000..a7b785e --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-dc-v4l.c @@ -0,0 +1,348 @@ +/* + * arch/arm/mach-omap2/board-omap3evm-dc-v4l.c + * + * Driver for OMAP3 EVM Mass Market Daughter Card + * + * Copyright (C) 2008 Texas Instruments Inc + * Author: Vaibhav Hiremath + * + * Contributors: + * Anuj Aggarwal + * Sivaraj R + * + * This package 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 V4L2 ISP-Camera driver related header file */ +#include <../drivers/media/video/omap34xxcam.h> +#include <../drivers/media/video/isp/ispreg.h> + +#include "board-omap3evm-dc.h" + +#define MODULE_NAME"omap3evmdc" + +/* Macro Definitions */ + +/* GPIO pins */ +#define GPIO134_SEL_TVP_Y (134) +#define GPIO54_SEL_EXP_CAM (54) +#define GPIO136_SEL_CAM(136) + +/* board internal information (BEGIN) */ + +/* I2C bus to which all I2C slave devices are attached */ +#define BOARD_I2C_BUSNUM (3) + +/* I2C address of chips present in board */ +#define TVP5146_I2C_ADDR (0x5D) + +#if defined(CONFIG_VIDEO_TVP514X) || defined(CONFIG_VIDEO_TVP514
[PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media Daughter Card Support
From: Vaibhav Hiremath
On OMAP3EVM Mass Market Daugher Card following GPIO pins are being
used -
GPIO134 --> Enable/Disable TVP5146 interface
GPIO54 --> Enable/Disable Expansion Camera interface
GPIO136 --> Enable/Disable Camera (Sensor) interface
Added entry for the above GPIO's in mux.c and mux.h file
Signed-off-by: Brijesh Jadav
Signed-off-by: Hardik Shah
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/mux.c |6 ++
arch/arm/plat-omap/include/mach/mux.h |5 -
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 1556688..d226d81 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -471,6 +471,12 @@ MUX_CFG_34XX("AF5_34XX_GPIO142", 0x170,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX("AE5_34XX_GPIO143", 0x172,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("AG4_34XX_GPIO134", 0x160,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("U8_34XX_GPIO54", 0x0b4,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("AE4_34XX_GPIO136", 0x164,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
};
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 67fddec..ace037f 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -795,7 +795,10 @@ enum omap34xx_index {
AF6_34XX_GPIO140_UP,
AE6_34XX_GPIO141,
AF5_34XX_GPIO142,
- AE5_34XX_GPIO143
+ AE5_34XX_GPIO143,
+ AG4_34XX_GPIO134,
+ U8_34XX_GPIO54,
+ AE4_34XX_GPIO136,
};
struct omap_mux_cfg {
--
1.5.6
--
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] Broken Tuning on Wintv Nova HD S2
В сообщении от 29 January 2009 20:07:32 gimli написал(а): > Hi, > > your patch seems to work. If it works, then I prepare more simple patch. # HG changeset patch # User Igor M. Liplianin # Date 1233253267 -7200 # Node ID 3542d1c1e03add577ce85175327701c552d14856 # Parent 4086371cea7b7f8b461e1a77513274aa43583c8c Bug fix: Restore HVR-4000 tuning. From: Igor M. Liplianin Some cards uses cx24116 LNB_DC pin for LNB power control, some not uses, some uses it different way, like HVR-4000. Signed-off-by: Igor M. Liplianin diff -r 4086371cea7b -r 3542d1c1e03a linux/drivers/media/dvb/frontends/cx24116.c --- a/linux/drivers/media/dvb/frontends/cx24116.c Sat Jan 17 17:23:31 2009 +0200 +++ b/linux/drivers/media/dvb/frontends/cx24116.c Thu Jan 29 20:21:07 2009 +0200 @@ -1184,7 +1184,12 @@ if (ret != 0) return ret; - return cx24116_diseqc_init(fe); + ret = cx24116_diseqc_init(fe); + if (ret != 0) + return ret; + + /* HVR-4000 needs this */ + return cx24116_set_voltage(fe, SEC_VOLTAGE_13); } /*
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Thu Jan 29 19:00:09 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10402:3541eb5b56f7 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: WARNINGS linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc3-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29-rc3-armv5-ixp: WARNINGS linux-2.6.27-armv5-omap2: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-rc3-armv5-omap2: WARNINGS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29-rc3-i686: ERRORS linux-2.6.16.61-m32r: WARNINGS linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK 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-rc3-m32r: OK linux-2.6.16.61-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29-rc3-powerpc64: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: ERRORS linux-2.6.27-x86_64: ERRORS linux-2.6.28-x86_64: ERRORS linux-2.6.29-rc3-x86_64: ERRORS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc3): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 -- 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: [V4L2] EV control API for digital camera
[removed redhat list from CC] On Thu, 29 Jan 2009, DongSoo Kim wrote: > Hello. > > When we take pictures, sometimes we don't get satisfied with the > exposure of picture. Too dark or too bright. > > For that reason, we need to bias EV which represents Exposure Value. > > So..if I want to control digital camera module with V4L2 API, which > API should I take for EV control? > > V4L2 document says that V4L2_CID_BRIGHTNESS is for picture brightness, > but it is for "Image properties" and that "image" means the image > frame of TV or PVR things.Am I right? There's also V4L2_CID_EXPOSURE > > If I may, can I use V4L2_CID_BRIGHTNESS for EV control of digital cameras? > > or..otherwise I should make a new API for that functionality. > > I'm little bit confused, because I think the brightness of picture > could differ from exposure value of digital camera..help me ;( Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
Patchwork not showing PULL requests
Hello, I recently discovered http://patchwork.kernel.org/project/linux-media/list/ which is a pretty cool idea in terms of being able to keep track of the status for incoming patches. I was just wondering though, is there a way to get it to support PULL requests as well? Regards, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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] Broken Tuning on Wintv Nova HD S2
Hi, your patch seems to work. cu Edgar (gimli) Hucek Igor M. Liplianin schrieb: В сообщении от 27 January 2009 22:39:51 gimli написал(а): Hi, the following changesets breaks Tuning to Vertical Transponders : http://mercurial.intuxication.org/hg/s2-liplianin/rev/1ca67881d96a http://linuxtv.org/hg/v4l-dvb/rev/2cd7efb4cc19 For example : DMAX;BetaDigital:12246:vC34M2O0S0:S19.2E:27500:511:512=deu:32:0:10101:1:109 2:0 cu Edgar ( gimli ) Hucek ___ 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 More likely not polarization, but hi band may broken. Anyway, please, try attached patch. -- 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] Broken Tuning on Wintv Nova HD S2
В сообщении от 27 January 2009 22:39:51 gimli написал(а):
> Hi,
>
> the following changesets breaks Tuning to Vertical Transponders :
>
> http://mercurial.intuxication.org/hg/s2-liplianin/rev/1ca67881d96a
> http://linuxtv.org/hg/v4l-dvb/rev/2cd7efb4cc19
>
> For example :
>
> DMAX;BetaDigital:12246:vC34M2O0S0:S19.2E:27500:511:512=deu:32:0:10101:1:109
>2:0
>
>
> cu
>
> Edgar ( gimli ) Hucek
>
> ___
> 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
More likely not polarization, but hi band may broken.
Anyway, please, try attached patch.
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
# HG changeset patch
# User Igor M. Liplianin
# Date 1233189531 -7200
# Node ID d09924ba6c75233d8212ef79076739d9400d79a8
# Parent 43dbc8ebb5a21c8991df5e5ead54b724c0dc18f4
HVR-4000 Test
diff -r 43dbc8ebb5a2 -r d09924ba6c75 linux/drivers/media/dvb/frontends/cx24116.c
--- a/linux/drivers/media/dvb/frontends/cx24116.c Tue Jan 27 23:47:50 2009 -0200
+++ b/linux/drivers/media/dvb/frontends/cx24116.c Thu Jan 29 02:38:51 2009 +0200
@@ -861,6 +861,7 @@
static int cx24116_set_tone(struct dvb_frontend *fe,
fe_sec_tone_mode_t tone)
{
+ struct cx24116_state *state = fe->demodulator_priv;
struct cx24116_cmd cmd;
int ret;
@@ -870,8 +871,12 @@
return -EINVAL;
}
- /* Wait for LNB ready */
- ret = cx24116_wait_for_lnb(fe);
+ if (state->config->use_lnb_dc != 1)
+ ret = cx24116_set_voltage(fe, SEC_VOLTAGE_13);
+ else
+ /* Wait for LNB ready */
+ ret = cx24116_wait_for_lnb(fe);
+
if (ret != 0)
return ret;
diff -r 43dbc8ebb5a2 -r d09924ba6c75 linux/drivers/media/dvb/frontends/cx24116.h
--- a/linux/drivers/media/dvb/frontends/cx24116.h Tue Jan 27 23:47:50 2009 -0200
+++ b/linux/drivers/media/dvb/frontends/cx24116.h Thu Jan 29 02:38:51 2009 +0200
@@ -35,6 +35,9 @@
/* Need to set MPEG parameters */
u8 mpg_clk_pos_pol:0x02;
+
+ /* Need to set LNB power control */
+ u8 use_lnb_dc;
};
#if defined(CONFIG_DVB_CX24116) || \
diff -r 43dbc8ebb5a2 -r d09924ba6c75 linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c Tue Jan 27 23:47:50 2009 -0200
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c Thu Jan 29 02:38:51 2009 +0200
@@ -334,6 +334,7 @@
static struct cx24116_config dvbworld_cx24116_config = {
.demod_address = 0x05,
+ .use_lnb_dc = 1,
};
static int dvb_register(struct cx23885_tsport *port)
Re: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
On Thu, 29 Jan 2009, Christoph Pfister wrote: > > I intend to take Christoph's files and massage them to add > > bits of info, reviewing the info by hand, adding missing info > I don't mind adding those further bits. They need to be after the main > block in the file, so that they don't get overwritten when those files > are updated e.g. because of a new pdf. Hmm, actually, the first thing I was planning to do would be to sort the entries by, for lack of a better term, provider. That is, roughly, ARD multiplex when appropriate, ZDFmobil, and regional Dritte multiplex everywhere, and in selected regions, the remaining of the seven assigned GE06 allocations or, in short, private providers. This is intended to provide an overview of these allocations and the particular sites where they can be found, as well as to handle the potential cases of frequency re-use in widely- separated areas between two muxes with incompatible parameters -- how often this will occur, I cannot say, as I do not yet have a complete overview. This also can help the case of Tobi, who would prefer to use two or three transmitter-site files, in that it would be easy to see which frequencies would be ``local'' (shades of Royston Vasey here, ``You'll Never Leave''). But I'm not sure how well this would work with a PDF-skimming application... As a concrete example, what I would create, would look like: # DVB-T Sachsen-Anhalt # Created from http://www.ueberallfernsehen.de/data/senderliste_25_11_2008.pdf # mercilessly mangled by hand, please file in /dev/null # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy ### ZDFmobil multiplex; E22, E30, E31 T 48200 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH22 Halle T 54600 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH30 Brocken, Magdeburg, Wittenberg T 55400 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH31 Dequede ### MDR-S-A multiplex; E34, E35, E38 T 57800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH34 Brocken, Dequede, Magdeburg T 58600 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH35 Halle T 61000 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH38 Wittenberg ### ARD multiplex; E24, E29, E41 T 49800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH24 Halle, Wittenberg T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH29 Brocken, Magdeburg T 63400 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH41 Dequede (This also can make it somewhat more 80-column-friendly, for at least some regions) Tobi, if I may ask you -- I have seen use made of, for example, `K21' in german web fora to refer to the frequency spanned by 470 to 478MHz, while in swiss web fora, I often see `E21' for the same. I know that `K' can be both seen as `Kanal' (channel) and `Kabel' (cable), while I would guess that `E' refers to Europe, to differ the 8MHz spacing from that of, say, Australia or some other land whose name I can't remember but which sort of features prominently in parts of Thee Interweb. But in my experience, cable-TV frequencies by channel number do not always match over-the-air frequencies for that channel. Are you familiar with the `E' usage, can you tell me if there is an accepted international usage that covers all languages, as my attempts to search `e' in g00gle were not impressive... Thanks... Anyway, with the above, after I pull out a map, I can say, oh, this group of transmitters (probably) forms a SFN for ZDF, and that group covers mdr, and so on. That overview was one of the things I was trying to obtain earlier, and will be when I really work on Sachsen-Anhalt. And to Christoph, the danger, as I'm sure you know, of pulling from a PDF or other single source of information, is that those will not always be infallible, as we've seen with a centre-frequency ending in `3' and paste-errors for Hamburg between VHF and UHF parameters, as well as absent info for the specific cases of the frequency change in HH; or for BW, the change planned for Aalen plus the to-be-in-service status of Bad Mergentheim. I suppose I ought to write the originator of the PDF to point out errors, but I suspect I'll get at best a reply from TV Licensing saying they have no record of me in their database and that as a non-resident, I have no grounds for criticism of their offering and I should stick to the programmes for which I pay the license fee. (How else can I explain the years-running errors in linking of teletext pages, that are again changed to errors when those pages are relocated? ZDF, I'm looking at you for failing to list your extended programme guide following ttx page 380...) Oops, off-topic again. > They shouldn't be too excessive, Oh dear. The question is, how do I skate the thin line between providing too much information, and failing to include useful information? I guess, it depends on your interest. If all you care about are just the frequencies, and if I were to say to you `ERP' you would say, ``Oh, do excuse yourself, you glutton'', then the existing files are fine. But if you need transmitter sites and info to h
Re: [PATCH] Support faulty USB IDs on DIBUSB_MC
On Thu, 29 Jan 2009 14:08:01 +0100 (CET) Patrick Boettcher wrote: > On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote: > >> We could do that, still I'm not sure if ARRAY_SIZE will work in that > >> situation?! Are you > >> sure, Mauro? > > > > Well, at least here, it is compiling fine. I can't really test it, since I > > don't have any dib0700 devices here. > > Hmm, your patch is shifting the counting problem to another place. Instead > of counting manually the devices-array-elements, one now needs to count > the number of device_properties ;) . > With such a patch we would risk to break some device support and as I > never saw a patch which broke the current num_device_descs-manual-count I > don't see the need to change. Nothing is perfect ;) I suspect that you have more additions at the number of the devices than on the number of device properties. So, the risk of doing bad things seems lower. Also, a simple board addition won't need to touch at the number of devices. IMO, it is really bad to have to explicitly say the number of devices at those arrays. Maybe we may use some macro logic here to avoid such risks, or use a NULL terminated list instead. > > -- >Mail: patrick.boettc...@desy.de >WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ 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: [linux-dvb] SAA716x
Manu Abraham a écrit : Can you please post some pictures of your card ? Regards, Manu Hi, You can find two high resolution pictures here : http://catimimi.free.fr/Pinnacle/ I think that they are too heavy for the wiki. I'm willing to help in any test with this Pinnacle 3010i card. Regards. Michel. -- 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] Support faulty USB IDs on DIBUSB_MC
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote: We could do that, still I'm not sure if ARRAY_SIZE will work in that situation?! Are you sure, Mauro? Well, at least here, it is compiling fine. I can't really test it, since I don't have any dib0700 devices here. Hmm, your patch is shifting the counting problem to another place. Instead of counting manually the devices-array-elements, one now needs to count the number of device_properties ;) . With such a patch we would risk to break some device support and as I never saw a patch which broke the current num_device_descs-manual-count I don't see the need to change. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: [linuxtv-commits] [hg:v4l-dvb] DVB: negative internal->sub_range won't get noticed
On Thu, 29 Jan 2009 14:46:42 +0400 Manu Abraham wrote: > Mauro, > > Please revert this patch as it is incorrect. A correct version is > available at http://jusst.de/hg/v4l-dvb which is undergoing tests. > http://jusst.de/hg/v4l-dvb/rev/368dc6078295 Ok, I'll revert it. Please submit me later the pull request for the correct patch. > Why did you have to hastily apply this patch, especially when i > mentioned this earlier ? I haven't seen any comments about it on the Patchwork thread for this patch: http://patchwork.kernel.org/patch/3065/ -- 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] Support faulty USB IDs on DIBUSB_MC
On Thu, 29 Jan 2009 11:19:32 +0100 (CET)
Patrick Boettcher wrote:
> > It doesn't sound a very good approach the need of recompiling the driver to
> > allow it to work with a broken card. The better would be to have some
> > modprobe
> > option to force it to accept a certain USB ID as a valid ID for the card.
>
> The most correct way would be to reprogram the eeprom, by simply writing
> to 0xa0 (0x50 << 1) I2C address... There was a thread on the linux-dvb some
> time ago.
Yes. Yet, it might be interesting to have some option to allow forcing.
> > The above is really ugly. IMO, we should replace this by
> > ARRAY_SIZE(dibusb_mc_properties.devices). Of course, for this to work,
> > num_device_descs should be bellow devices.
>
> We could do that, still I'm not sure if ARRAY_SIZE will work in that
> situation?! Are you
> sure, Mauro?
Well, at least here, it is compiling fine. I can't really test it, since I
don't have any dib0700 devices here.
Signed-off-by: Mauro Carvalho Chehab
diff -r 39a646207d0c linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Thu Jan 29 09:11:45
2009 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Thu Jan 29 10:04:08
2009 -0200
@@ -1447,7 +1447,7 @@
}
struct dvb_usb_device_properties dib0700_devices[] = {
- {
+ [0] = {
DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 1,
@@ -1460,7 +1460,6 @@
},
},
- .num_device_descs = 8,
.devices = {
{ "DiBcom STK7700P reference design",
{ &dib0700_usb_id_table[0],
&dib0700_usb_id_table[1] },
@@ -1496,11 +1495,13 @@
}
},
+ .num_device_descs = ARRAY_SIZE(dib0700_devices[0].devices),
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dib0700_rc_keys,
.rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
.rc_query = dib0700_rc_query
- }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+ },
+ [1] = { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 2,
.adapter = {
@@ -1517,19 +1518,20 @@
}
},
- .num_device_descs = 1,
.devices = {
{ "Hauppauge Nova-T 500 Dual DVB-T",
{ &dib0700_usb_id_table[2],
&dib0700_usb_id_table[3], NULL },
{ NULL },
},
},
+ .num_device_descs = ARRAY_SIZE(dib0700_devices[1].devices),
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dib0700_rc_keys,
.rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
.rc_query = dib0700_rc_query
- }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+ },
+ [2] = { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 2,
.adapter = {
@@ -1546,7 +1548,6 @@
}
},
- .num_device_descs = 4,
.devices = {
{ "Pinnacle PCTV 2000e",
{ &dib0700_usb_id_table[11], NULL },
@@ -1566,13 +1567,15 @@
},
},
+ .num_device_descs = ARRAY_SIZE(dib0700_devices[2].devices),
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dib0700_rc_keys,
.rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
.rc_query = dib0700_rc_query
- }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+ },
+ [3] = { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 1,
.adapter = {
@@ -1584,7 +1587,6 @@
},
},
- .num_device_descs = 3,
.devices = {
{ "ASUS My Cinema U3000 Mini DVBT Tuner",
{ &dib0700_usb_id_table[23], NULL },
@@ -1599,12 +1601,14 @@
{ NULL },
}
},
+ .num_device_descs = ARRAY_SIZE(dib0700_devices[3].devices),
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dib0700_rc_keys,
.rc_key_map_size = ARRAY_SIZE(dib0700_rc_keys),
.rc_query = dib0700_rc_query
- }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+ },
+ [4] = { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 1,
.adapter = {
@@ -1618,7 +1622,6 @@
},
},
- .num_device_descs = 9,
.devices = {
Re: Compiler warnings in pxa_camera.c
On Thu, 29 Jan 2009, Hans Verkuil wrote: > On Thursday 29 January 2009 11:19:39 Guennadi Liakhovetski wrote: > > > > soc-camera drivers so far only include embedded platforms, and there you > > most usually have to work with complete kernel sources, and, to be > > honest, this backwards compatibility patching only adds work for me - > > when trying to merge patches created with git against a complete kernel > > git tree, because often so created patches don't apply cleanly (or at > > all) because of the compatibility delta. And then this delta has to be > > cleaned up by Mauro again before pushing upstream. Yes, Mauro does use > > scripts for this, still, separating original patches from the > > compatibility code can be non-trivial, I think, and, I guess, those > > scripts do not manage it in 100% of cases - as we have seen with a recent > > breakage exactly with these PXA register definitions. > > > > So, I would be perfectly happy if we find a way to only allow compilation > > of soc-camera drivers against the "current" kernel, and remove all the > > compatibility code from them. > > No problem, I've modified it so that the daily build only compiles this > driver from 2.6.29 and up. Great, thanks. Can we also set this for other soc-camera drivers and remove all backwards compatibility patches from them? I.e. keep them exactly like upstream? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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: Compiler warnings in pxa_camera.c
On Thursday 29 January 2009 11:19:39 Guennadi Liakhovetski wrote: > On Thu, 29 Jan 2009, Hans Verkuil wrote: > > Hi Guennadi, > > Hi Hans, > > > For some time now I see the following warnings in pxa_camera.c under > > kernels 2.6.27 and 2.6.28 in the daily build: > > > > CC [M] /marune/build/v4l-dvb-master/v4l/soc_camera.o > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:54:1: warning: "CICR0" > > redefined In file included from > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:43: > > arch/arm/mach-pxa/include/mach/pxa-regs.h:615:1: warning: this is the > > location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:55:1: warning: "CICR1" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:616:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:56:1: warning: "CICR2" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:617:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:57:1: warning: "CICR3" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:618:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:58:1: warning: "CICR4" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:619:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:59:1: warning: "CISR" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:620:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:60:1: warning: "CIFR" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:621:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:61:1: warning: "CITOR" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:622:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:62:1: warning: "CIBR0" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:623:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:63:1: warning: "CIBR1" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:624:1: warning: > > this is the location of the previous definition > > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:64:1: warning: "CIBR2" > > redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:625:1: warning: > > this is the location of the previous definition > > > > It compiles fine under 2.6.29. > > > > Can you either try to fix this for kernels 2.6.27/28, or can I assume > > that this driver will only compile correctly under 2.6.29? > > I don't have extra time to fix the driver for kernels < 2.6.29 nor do I > know about anyone using soc-camera drivers from mercurial, compiling them > externally. > > soc-camera drivers so far only include embedded platforms, and there you > most usually have to work with complete kernel sources, and, to be > honest, this backwards compatibility patching only adds work for me - > when trying to merge patches created with git against a complete kernel > git tree, because often so created patches don't apply cleanly (or at > all) because of the compatibility delta. And then this delta has to be > cleaned up by Mauro again before pushing upstream. Yes, Mauro does use > scripts for this, still, separating original patches from the > compatibility code can be non-trivial, I think, and, I guess, those > scripts do not manage it in 100% of cases - as we have seen with a recent > breakage exactly with these PXA register definitions. > > So, I would be perfectly happy if we find a way to only allow compilation > of soc-camera drivers against the "current" kernel, and remove all the > compatibility code from them. No problem, I've modified it so that the daily build only compiles this driver from 2.6.29 and up. Regards, Hans > > > I don't know what the status is of this driver for these older kernels, > > so I don't dare touch this without input from you. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thursday 29 January 2009 10:23:57 Hans Verkuil wrote: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the > following: > > - gspca: fix compiler warning > > Thanks, > > Hans > > diffstat: > t613.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Added: - pxa: compile only from 2.6.29 onwards. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] cx88: fix unexpected video resize when setting tv norm
On Thu, 29 Jan 2009, Marton Balint wrote: > The status of this patch has changed to "Changes Requested" in > patchwork, but it's not obvious to me what changes are needed exactly. > Yes, in the comments quite a few questions came up, but we haven't > decided the correct course of action for good, and the patch also makes > sense in it's current form. The most serious problem with the patch is that the current image size may not be valid after changing norms. The driver and v4l2 aren't designed to allow an invalid image size to be selected, yet this patch would allow that to happen. -- 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: [linuxtv-commits] [hg:v4l-dvb] DVB: negative internal->sub_range won't get noticed
Mauro,
Please revert this patch as it is incorrect. A correct version is
available at http://jusst.de/hg/v4l-dvb which is undergoing tests.
http://jusst.de/hg/v4l-dvb/rev/368dc6078295
Why did you have to hastily apply this patch, especially when i
mentioned this earlier ?
Regards,
Manu
Patch from Roel Kluin wrote:
> The patch number 10393 was added via Mauro Carvalho Chehab
>
> to http://linuxtv.org/hg/v4l-dvb master development tree.
>
> Kernel patches in this development tree may be modified to be backward
> compatible with older kernels. Compatibility modifications will be
> removed before inclusion into the mainstream Kernel
>
> If anyone has any objections, please let us know by sending a message to:
> Linux Media Mailing List
>
> --
>
> From: Roel Kluin
> DVB: negative internal->sub_range won't get noticed
>
>
> internal->sub_range is unsigned, a negative won't get noticed.
>
> Signed-off-by: Roel Kluin
> Signed-off-by: Andrew Morton
> Signed-off-by: Mauro Carvalho Chehab
>
>
> ---
>
> linux/drivers/media/dvb/frontends/stb0899_algo.c |9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff -r 6ca70bcb4972 -r d3bfc53d0b67
> linux/drivers/media/dvb/frontends/stb0899_algo.c
> --- a/linux/drivers/media/dvb/frontends/stb0899_algo.cWed Jan 14
> 16:17:59 2009 +
> +++ b/linux/drivers/media/dvb/frontends/stb0899_algo.cSun Jan 18
> 23:31:26 2009 +
> @@ -467,12 +467,13 @@ static void next_sub_range(struct stb089
>
> if (internal->sub_dir > 0) {
> old_sub_range = internal->sub_range;
> - internal->sub_range = MIN((internal->srch_range / 2) -
> + if (internal->tuner_offst + internal->sub_range / 2 >=
> + internal->srch_range / 2)
> + internal->sub_range = 0;
> + else
> + internal->sub_range = MIN((internal->srch_range / 2) -
> (internal->tuner_offst +
> internal->sub_range / 2),
> internal->sub_range);
> -
> - if (internal->sub_range < 0)
> - internal->sub_range = 0;
>
> internal->tuner_offst += (old_sub_range + internal->sub_range)
> / 2;
> }
>
>
> ---
>
> Patch is available at:
> http://linuxtv.org/hg/v4l-dvb/rev/d3bfc53d0b678da495fd2b559e154c5e95584079
>
> ___
> linuxtv-commits mailing list
> linuxtv-comm...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
>
--
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] Upcoming DVB-T channel changes for HH (Hamburg)
2009/1/27 BOUWSMA Barry : > I intend to take Christoph's files and massage them to add > bits of info, reviewing the info by hand, adding missing info > and generally trying to come up with something like the BW > file I created. > > But I want feedback about that file too, rather than to have > my changes be rejected after I've done the review and work. I don't mind adding those further bits. They need to be after the main block in the file, so that they don't get overwritten when those files are updated e.g. because of a new pdf. They shouldn't be too excessive, but for example I prefer if you add the Leipzip transponder to the de-whatever file instead of creating a new de-Leipzig file, so this point shouldn't cause trouble to you. People don't have to scan every day, so it doesn't hurt if the scan time is increased by some seconds. Thanks, Christoph -- 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: Merging the v4l2 spec?
On Thu, 29 Jan 2009 10:37:54 +0100 Hans Verkuil wrote: > On Thursday 29 January 2009 10:30:56 Mauro Carvalho Chehab wrote: > > On Thu, 29 Jan 2009 09:51:04 +0100 > > > > Hans Verkuil wrote: > > > Hi Mauro, > > > > > > Is it possible to merge the v4l2 spec from my tree soon? With all the > > > various new API additions that are being discussed it would help a lot > > > if they can also make patches against the documentation at the same > > > time. > > > > I'd like to give a few more days to Michael Schimek to ack on this. Since > > we are in a period of the year where lots of people gets vacation, it is > > better to give Michael some more time on this. > > I haven't heard from him since my first mail on this subject on December > 7th. That's almost two months ago! Even in Europe people don't have that > much vacation time :-) :) Let's wait until Feb. Then, if we don't have any answer from him, I'll merge it. > > > > BTW, I'm working on improving the qv4l2 tool to make it much more > > > useful for testing. I'm integrating it with the v4lconvert lib and > > > added capture support as well. It should become a proper testbench for > > > drivers. All the other tools around are really crappy, so I decided to > > > extend qv4l2 instead. > > > > Good news! IMO, you should also add the new tool to get sysfs patch > > integrated on it. I was planning to do it later, but, since you're > > already working with qv4l2, maybe you can add this feature on it as well. > > The drawback is that it requires libsysfs-devel in order to compile. > > Maybe this can be an optional feature. > > Can you give me a pointer? I've no idea what you are referring to. v4l2-apps/util/v4l2_sysfs_path.c There were some discussions that started on pvrusb2 about how to uniquely identify a /dev/video that ended on standardizing the way the USB drivers answers at bus_info on VIDIOC_QUERYCAP. With the current status, the above utility is capable of retrieving the proper sysfs path for a given device. Using that info, it is possible not only to know if a device is unique, but also know that the device has DVB, ALSA and INPUT modules associated. > > > I've also bought a bunch of old hardware from ebay. I should be able to > > > test various old v4l1 drivers and convert them to v4l2. I basically > > > want to be able to test pretty much the whole v4l2 API, preferably with > > > qv4l2. Yesterday two webcams came in, so I can now test w9968cf and > > > se401. > > > > Great! IMO, the better would be to make those cams as sub-drivers of > > gspca. > > That was my idea as well. Good. > > > Check out my qv4l2 tree for progress on this tool! > > > > I'll take a look soon. > > > > > Now all I need is lots more time :-( > > > > I know what you're meaning... I'm also needing more time here... I just > > wrote some tools to help me with patchwork stuff. Hopefully, this week, > > I'll have all pending patches (there that aren't being reviewed by > > somebody else) updated. > > Cool. Ok, most of the patches there were already handled. 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] Support faulty USB IDs on DIBUSB_MC
Hi,
sorry for not answering ealier, recently I became the master of
postponing things. :(
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote:
+/* 14 */ { USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+#endif
It doesn't sound a very good approach the need of recompiling the driver to
allow it to work with a broken card. The better would be to have some modprobe
option to force it to accept a certain USB ID as a valid ID for the card.
The most correct way would be to reprogram the eeprom, by simply writing
to 0xa0 (0x50 << 1) I2C address... There was a thread on the linux-dvb some
time ago.
The above is really ugly. IMO, we should replace this by
ARRAY_SIZE(dibusb_mc_properties.devices). Of course, for this to work,
num_device_descs should be bellow devices.
We could do that, still I'm not sure if ARRAY_SIZE will work in that
situation?! Are you
sure, Mauro?
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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: Compiler warnings in pxa_camera.c
On Thu, 29 Jan 2009, Hans Verkuil wrote: > Hi Guennadi, Hi Hans, > For some time now I see the following warnings in pxa_camera.c under > kernels 2.6.27 and 2.6.28 in the daily build: > > CC [M] /marune/build/v4l-dvb-master/v4l/soc_camera.o > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:54:1: warning: "CICR0" redefined > In file included from /marune/build/v4l-dvb-master/v4l/pxa_camera.c:43: > arch/arm/mach-pxa/include/mach/pxa-regs.h:615:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:55:1: warning: "CICR1" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:616:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:56:1: warning: "CICR2" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:617:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:57:1: warning: "CICR3" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:618:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:58:1: warning: "CICR4" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:619:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:59:1: warning: "CISR" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:620:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:60:1: warning: "CIFR" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:621:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:61:1: warning: "CITOR" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:622:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:62:1: warning: "CIBR0" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:623:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:63:1: warning: "CIBR1" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:624:1: warning: this is the > location of the previous definition > /marune/build/v4l-dvb-master/v4l/pxa_camera.c:64:1: warning: "CIBR2" redefined > arch/arm/mach-pxa/include/mach/pxa-regs.h:625:1: warning: this is the > location of the previous definition > > It compiles fine under 2.6.29. > > Can you either try to fix this for kernels 2.6.27/28, or can I assume that > this driver will only compile correctly under 2.6.29? I don't have extra time to fix the driver for kernels < 2.6.29 nor do I know about anyone using soc-camera drivers from mercurial, compiling them externally. soc-camera drivers so far only include embedded platforms, and there you most usually have to work with complete kernel sources, and, to be honest, this backwards compatibility patching only adds work for me - when trying to merge patches created with git against a complete kernel git tree, because often so created patches don't apply cleanly (or at all) because of the compatibility delta. And then this delta has to be cleaned up by Mauro again before pushing upstream. Yes, Mauro does use scripts for this, still, separating original patches from the compatibility code can be non-trivial, I think, and, I guess, those scripts do not manage it in 100% of cases - as we have seen with a recent breakage exactly with these PXA register definitions. So, I would be perfectly happy if we find a way to only allow compilation of soc-camera drivers against the "current" kernel, and remove all the compatibility code from them. > I don't know what the status is of this driver for these older kernels, so I > don't dare touch this without input from you. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] Dallas Texas ATSC scan file
2009/1/28 Michael Krufky : > This is just a small subset of the available frequencies where we may find > ATSC services. > > Although this may be helpful for people scanning in Dallas, TX today, it > will cause problems when the services move to other frequencies. This will > only scan a very limited range of frequencies, so naturally, it will be much > quicker, but you might miss some services. > > Users should use the file, "us-ATSC-center-frequencies-8VSB" , which > contains all of the frequencies below, along with the full frequency table > for ATSC, from channels 2 through 69. > > I wouldn't commit this file, for the same very reason that I deleted the > TWCNYC file. ok. thanks, christoph > Regards, > > Mike > > Christoph Pfister wrote: >> >> Mike, >> >> Can I have your $0.02, please? >> >> Thanks, >> >> Christoph >> >> 2009/1/24 Jorge Canas : >> >>> >>> # DALLAS TX ATSC center frequencies, use if in doubt >>> >>> A 189028615 8VSB >>> A 473028615 8VSB >>> A 497028615 8VSB >>> A 503028615 8VSB >>> A 533028615 8VSB >>> A 569028615 8VSB >>> A 581028615 8VSB >>> A 599028615 8VSB >>> A 605028615 8VSB >>> A 629028615 8VSB >>> A 635028615 8VSB >>> A 641028615 8VSB >>> A 659028615 8VSB >>> A 665028615 8VSB >>> A 677028615 8VSB >>> A 695028615 8VSB -- 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] ov772x: add support S_CROP operation.
On Thu, 29 Jan 2009 11:00:41 +0100 (CET) Guennadi Liakhovetski wrote: > On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote: > > > On Tue, 27 Jan 2009 08:53:23 +0100 (CET) > > Guennadi Liakhovetski wrote: > > > > Hi Guennadi, > > > > I'm understanding that you're reviewing this patch and other ones for > > soc_camera and will send me a PULL request after reviewing those stuff. > > Yes, I'm (going to be) reviewing them, as soon as I find some time. Then > I'll send you two pull requests - fixes for 2.6.29 and 2.6.30 material. > AFAIK, unfortunately, mercurial doesn't support branches, so, I probably > will end up first sending you a pull request with fixes, and after some > time I'll also add 2.6.30 further development to the same tree and send > another pull request. No idea what I do, if after that more 2.6.29 fixes > come... Yes, this is another drawback of hg. For fixes, please add: Priority: high At the body of the description. My scripts will understand this as fix patches. 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] ov772x: add support S_CROP operation.
On Thu, 29 Jan 2009, Mauro Carvalho Chehab wrote: > On Tue, 27 Jan 2009 08:53:23 +0100 (CET) > Guennadi Liakhovetski wrote: > > Hi Guennadi, > > I'm understanding that you're reviewing this patch and other ones for > soc_camera and will send me a PULL request after reviewing those stuff. Yes, I'm (going to be) reviewing them, as soon as I find some time. Then I'll send you two pull requests - fixes for 2.6.29 and 2.6.30 material. AFAIK, unfortunately, mercurial doesn't support branches, so, I probably will end up first sending you a pull request with fixes, and after some time I'll also add 2.6.30 further development to the same tree and send another pull request. No idea what I do, if after that more 2.6.29 fixes come... > I've updated patchwork to reflect this. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] ov772x: add support S_CROP operation.
On Tue, 27 Jan 2009 08:53:23 +0100 (CET) Guennadi Liakhovetski wrote: Hi Guennadi, I'm understanding that you're reviewing this patch and other ones for soc_camera and will send me a PULL request after reviewing those stuff. I've updated patchwork to reflect this. Thanks, Mauro > On Tue, 27 Jan 2009, morimoto.kunin...@renesas.com wrote: > > > Dear Guennadi > > > > > > what is the best way to us ??? > > > > or do I miss understanding ??? > > > > > > Fix behaviour if no S_FMT is done. > > > > I attached stupid 4 patches. > > I would like to hear your opinion. > > please check it. > > > > I wonder is there any soc_camera that works without > > calling S_FMT though set_bus_param is not called ? > > Don't know, never tested that way. Might well be they don't, in which case > they need to be fixed. > > > If soc_camera works without calling S_FMT, > > s_crop should call try_fmt_vid_cap > > and set_bus_param like s_fmt_vid_cap I think. > > > > And I think "current_fmt" is better than 0 to set_fmt > > if user wants only geometry changes on s_crop. > > it mean keep format. > > > > These patches works well on my local environment. > > ov772x and tw9910 work even if without -f option on capture_example. > > > > If you can agree with this idea, > > I will send these as formal patch. > > Thanks for the patches, please, give me a couple of days for review. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > -- > 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 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] Support faulty USB IDs on DIBUSB_MC
On Mon, 19 Jan 2009 21:38:22 +0100
matthieu castet wrote:
> matthieu castet wrote:
> > Hi,
> >
> > I got a LITE-ON USB2.0 DVB-T Tuner that loose it's cold state vid/pid
> > and got FX2 dev kit one (0x04b4, 0x8613).
> >
> > This patch introduce an option similar to the DVB_USB_DIBUSB_MB_FAULTY :
> > it add the FX2 dev kit ids to the DIBUSB_MC driver if
> > DVB_USB_DIBUSB_MC_FAULTY is selected.
> >
> > Signed-off-by: Matthieu CASTET
> >
>
> diff --git a/drivers/media/dvb/dvb-usb/Kconfig
> b/drivers/media/dvb/dvb-usb/Kconfig
> index f00a0eb..a656b9b 100644
> --- a/drivers/media/dvb/dvb-usb/Kconfig
> +++ b/drivers/media/dvb/dvb-usb/Kconfig
> @@ -68,6 +68,12 @@ config DVB_USB_DIBUSB_MC
> Say Y if you own such a device and want to use it. You should build
> it as
> a module.
>
> +config DVB_USB_DIBUSB_MC_FAULTY
> + bool "Support faulty USB IDs"
> + depends on DVB_USB_DIBUSB_MC
> + help
> + Support for faulty USB IDs due to an invalid EEPROM on some LITE-ON
> devices.
> +
> config DVB_USB_DIB0700
> tristate "DiBcom DiB0700 USB DVB devices (see help for supported
> devices)"
> depends on DVB_USB
> diff --git a/drivers/media/dvb/dvb-usb/dibusb-mc.c
> b/drivers/media/dvb/dvb-usb/dibusb-mc.c
> index 059cec9..ab5766a 100644
> --- a/drivers/media/dvb/dvb-usb/dibusb-mc.c
> +++ b/drivers/media/dvb/dvb-usb/dibusb-mc.c
> @@ -42,6 +42,17 @@ static struct usb_device_id dibusb_dib3000mc_table [] = {
> /* 11 */ { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, USB_PID_ARTEC_T14_WARM)
> },
> /* 12 */ { USB_DEVICE(USB_VID_LEADTEK,
> USB_PID_WINFAST_DTV_DONGLE_COLD) },
> /* 13 */ { USB_DEVICE(USB_VID_LEADTEK,
> USB_PID_WINFAST_DTV_DONGLE_WARM) },
> +/*
> + * XXX: Some LITE-ON devices seem to loose their id after some time. Bad
> EEPROM ???.
> + * We don't catch these faulty IDs (namely 'Cypress FX2 USB
> controller') that
> + * have been left on the device. If you don't have such a device but an
> LITE-ON
> + * device that's supposed to work with this driver but is not detected
> by it,
> + * free to enable CONFIG_DVB_USB_DIBUSB_MC_FAULTY via your kernel
> config.
> + */
> +
> +#ifdef CONFIG_DVB_USB_DIBUSB_MC_FAULTY
> +/* 14 */ { USB_DEVICE(USB_VID_CYPRESS,
> USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
> +#endif
It doesn't sound a very good approach the need of recompiling the driver to
allow it to work with a broken card. The better would be to have some modprobe
option to force it to accept a certain USB ID as a valid ID for the card.
> { } /* Terminating entry */
> };
> MODULE_DEVICE_TABLE (usb, dibusb_dib3000mc_table);
> @@ -88,7 +99,11 @@ static struct dvb_usb_device_properties
> dibusb_mc_properties = {
>
> .generic_bulk_ctrl_endpoint = 0x01,
>
> +#ifdef CONFIG_DVB_USB_DIBUSB_MC_FAULTY
> + .num_device_descs = 8,
> +#else
> .num_device_descs = 7,
> +#endif
The above is really ugly. IMO, we should replace this by
ARRAY_SIZE(dibusb_mc_properties.devices). Of course, for this to work,
num_device_descs should be bellow devices.
> .devices = {
> { "DiBcom USB2.0 DVB-T reference design (MOD3000P)",
> { &dibusb_dib3000mc_table[0], NULL },
> @@ -119,6 +134,13 @@ static struct dvb_usb_device_properties
> dibusb_mc_properties = {
> { &dibusb_dib3000mc_table[12], NULL },
> { &dibusb_dib3000mc_table[13], NULL },
> },
> +#ifdef CONFIG_DVB_USB_DIBUSB_MC_FAULTY
> + { "LITE-ON USB2.0 DVB-T Tuner (faulty USB IDs)",
> + /* Also rebranded as Intuix S800, Toshiba */
> + { &dibusb_dib3000mc_table[14], NULL },
> + { NULL },
> + },
> +#endif
> { NULL },
> }
> };
Patrick,
Comments?
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 v2] v4l/tvp514x: make the module aware of rich people
Thanks,
Vaibhav Hiremath
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sebastian Andrzej Siewior
> Sent: Wednesday, January 28, 2009 9:00 PM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab; video4linux-
> l...@redhat.com
> Subject: [PATCH v2] v4l/tvp514x: make the module aware of rich
> people
>
> because they might design two of those chips on a single board.
> You never know.
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> v2: Make the content of the registers (brightness, \ldots) per
> decoder
> and not global.
> v1: Initial version
>
> drivers/media/video/tvp514x.c | 166 ++
> ---
> 1 files changed, 90 insertions(+), 76 deletions(-)
>
[Hiremath, Vaibhav] Sebastian, I have done the basic testing and it seems to be
working for me. I will ack the patch from my side once you fix the comments.
> diff --git a/drivers/media/video/tvp514x.c
> b/drivers/media/video/tvp514x.c
> index 8e23aa5..99cfc40 100644
> --- a/drivers/media/video/tvp514x.c
> +++ b/drivers/media/video/tvp514x.c
> @@ -86,45 +86,8 @@ struct tvp514x_std_info {
> struct v4l2_standard standard;
> };
>
> -/**
--
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: [PATCHv5] Add Freescale MC44S803 tuner driver
Antti,
I'm understanding that you're reviewing this patch and will apply it on your
tree when ready. I'm updating patchwork.kernel.org to reflect my understanding.
Cheers,
Mauro
On Mon, 19 Jan 2009 19:35:42 +0100
Jochen Friedrich wrote:
> Signed-off-by: Jochen Friedrich
> ---
> drivers/media/common/tuners/Kconfig |8 +
> drivers/media/common/tuners/Makefile|1 +
> drivers/media/common/tuners/mc44s803.c | 371
> +++
> drivers/media/common/tuners/mc44s803.h | 46
> drivers/media/common/tuners/mc44s803_priv.h | 208 +++
> 5 files changed, 634 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/common/tuners/mc44s803.c
> create mode 100644 drivers/media/common/tuners/mc44s803.h
> create mode 100644 drivers/media/common/tuners/mc44s803_priv.h
>
> diff --git a/drivers/media/common/tuners/Kconfig
> b/drivers/media/common/tuners/Kconfig
> index 6f92bea..7969b69 100644
> --- a/drivers/media/common/tuners/Kconfig
> +++ b/drivers/media/common/tuners/Kconfig
> @@ -29,6 +29,7 @@ config MEDIA_TUNER
> select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMIZE
> select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMIZE
> select MEDIA_TUNER_TDA9887 if !MEDIA_TUNER_CUSTOMIZE
> + select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMIZE
>
> menuconfig MEDIA_TUNER_CUSTOMIZE
> bool "Customize analog and hybrid tuner modules to build"
> @@ -164,4 +165,11 @@ config MEDIA_TUNER_MXL5007T
> help
> A driver for the silicon tuner MxL5007T from MaxLinear.
>
> +config MEDIA_TUNER_MC44S803
> + tristate "Freescale MC44S803 Low Power CMOS Broadband tuners"
> + depends on VIDEO_MEDIA && I2C
> + default m if DVB_FE_CUSTOMISE
> + help
> + Say Y here to support the Freescale MC44S803 based tuners
> +
> endif # MEDIA_TUNER_CUSTOMIZE
> diff --git a/drivers/media/common/tuners/Makefile
> b/drivers/media/common/tuners/Makefile
> index 4dfbe5b..4132b2b 100644
> --- a/drivers/media/common/tuners/Makefile
> +++ b/drivers/media/common/tuners/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_MEDIA_TUNER_QT1010) += qt1010.o
> obj-$(CONFIG_MEDIA_TUNER_MT2131) += mt2131.o
> obj-$(CONFIG_MEDIA_TUNER_MXL5005S) += mxl5005s.o
> obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
> +obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
>
> EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
> EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
> diff --git a/drivers/media/common/tuners/mc44s803.c
> b/drivers/media/common/tuners/mc44s803.c
> new file mode 100644
> index 000..20c4485
> --- /dev/null
> +++ b/drivers/media/common/tuners/mc44s803.c
> @@ -0,0 +1,371 @@
> +/*
> + * Driver for Freescale MC44S803 Low Power CMOS Broadband Tuner
> + *
> + * Copyright (c) 2009 Jochen Friedrich
> + *
> + * 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.
> + *
> + * 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 "dvb_frontend.h"
> +
> +#include "mc44s803.h"
> +#include "mc44s803_priv.h"
> +
> +#define mc_printk(level, format, arg...) \
> + printk(level "mc44s803: " format , ## arg)
> +
> +/* Writes a single register */
> +static int mc44s803_writereg(struct mc44s803_priv *priv, u32 val)
> +{
> + u8 buf[3];
> + struct i2c_msg msg = {
> + .addr = priv->cfg->i2c_address, .flags = 0, .buf = buf, .len = 3
> + };
> +
> + buf[0] = (val & 0xff) >> 16;
> + buf[1] = (val & 0xff00) >> 8;
> + buf[2] = (val & 0xff);
> +
> + if (i2c_transfer(priv->i2c, &msg, 1) != 1) {
> + mc_printk(KERN_WARNING, "I2C write failed\n");
> + return -EREMOTEIO;
> + }
> + return 0;
> +}
> +
> +/* Reads a single register */
> +static int mc44s803_readreg(struct mc44s803_priv *priv, u8 reg, u32 *val)
> +{
> + u32 wval;
> + u8 buf[3];
> + int ret;
> + struct i2c_msg msg[] = {
> + { .addr = priv->cfg->i2c_address, .flags = I2C_M_RD,
> + .buf = buf, .len = 3 },
> + };
> +
> + wval = MC44S803_REG_SM(MC44S803_REG_DATAREG, MC44S803_ADDR) |
> +MC44S803_REG_SM(reg, MC44S803_D);
> +
> + ret = mc44s803_writereg(priv, wval);
> + if (ret)
> + return ret;
> +
> + if (i2c_transfer(priv->i2c, msg, 1) != 1) {
Re: Merging the v4l2 spec?
On Thursday 29 January 2009 10:30:56 Mauro Carvalho Chehab wrote: > On Thu, 29 Jan 2009 09:51:04 +0100 > > Hans Verkuil wrote: > > Hi Mauro, > > > > Is it possible to merge the v4l2 spec from my tree soon? With all the > > various new API additions that are being discussed it would help a lot > > if they can also make patches against the documentation at the same > > time. > > I'd like to give a few more days to Michael Schimek to ack on this. Since > we are in a period of the year where lots of people gets vacation, it is > better to give Michael some more time on this. I haven't heard from him since my first mail on this subject on December 7th. That's almost two months ago! Even in Europe people don't have that much vacation time :-) > > BTW, I'm working on improving the qv4l2 tool to make it much more > > useful for testing. I'm integrating it with the v4lconvert lib and > > added capture support as well. It should become a proper testbench for > > drivers. All the other tools around are really crappy, so I decided to > > extend qv4l2 instead. > > Good news! IMO, you should also add the new tool to get sysfs patch > integrated on it. I was planning to do it later, but, since you're > already working with qv4l2, maybe you can add this feature on it as well. > The drawback is that it requires libsysfs-devel in order to compile. > Maybe this can be an optional feature. Can you give me a pointer? I've no idea what you are referring to. > > I've also bought a bunch of old hardware from ebay. I should be able to > > test various old v4l1 drivers and convert them to v4l2. I basically > > want to be able to test pretty much the whole v4l2 API, preferably with > > qv4l2. Yesterday two webcams came in, so I can now test w9968cf and > > se401. > > Great! IMO, the better would be to make those cams as sub-drivers of > gspca. That was my idea as well. > > Check out my qv4l2 tree for progress on this tool! > > I'll take a look soon. > > > Now all I need is lots more time :-( > > I know what you're meaning... I'm also needing more time here... I just > wrote some tools to help me with patchwork stuff. Hopefully, this week, > I'll have all pending patches (there that aren't being reviewed by > somebody else) updated. Cool. Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Merging the v4l2 spec?
On Thu, 29 Jan 2009 09:51:04 +0100 Hans Verkuil wrote: > Hi Mauro, > > Is it possible to merge the v4l2 spec from my tree soon? With all the > various new API additions that are being discussed it would help a lot if > they can also make patches against the documentation at the same time. I'd like to give a few more days to Michael Schimek to ack on this. Since we are in a period of the year where lots of people gets vacation, it is better to give Michael some more time on this. > BTW, I'm working on improving the qv4l2 tool to make it much more useful for > testing. I'm integrating it with the v4lconvert lib and added capture > support as well. It should become a proper testbench for drivers. All the > other tools around are really crappy, so I decided to extend qv4l2 instead. Good news! IMO, you should also add the new tool to get sysfs patch integrated on it. I was planning to do it later, but, since you're already working with qv4l2, maybe you can add this feature on it as well. The drawback is that it requires libsysfs-devel in order to compile. Maybe this can be an optional feature. > I've also bought a bunch of old hardware from ebay. I should be able to test > various old v4l1 drivers and convert them to v4l2. I basically want to be > able to test pretty much the whole v4l2 API, preferably with qv4l2. > Yesterday two webcams came in, so I can now test w9968cf and se401. Great! IMO, the better would be to make those cams as sub-drivers of gspca. > Check out my qv4l2 tree for progress on this tool! I'll take a look soon. > Now all I need is lots more time :-( I know what you're meaning... I'm also needing more time here... I just wrote some tools to help me with patchwork stuff. Hopefully, this week, I'll have all pending patches (there that aren't being reviewed by somebody else) updated. 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
Compiler warnings in pxa_camera.c
Hi Guennadi, For some time now I see the following warnings in pxa_camera.c under kernels 2.6.27 and 2.6.28 in the daily build: CC [M] /marune/build/v4l-dvb-master/v4l/soc_camera.o /marune/build/v4l-dvb-master/v4l/pxa_camera.c:54:1: warning: "CICR0" redefined In file included from /marune/build/v4l-dvb-master/v4l/pxa_camera.c:43: arch/arm/mach-pxa/include/mach/pxa-regs.h:615:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:55:1: warning: "CICR1" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:616:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:56:1: warning: "CICR2" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:617:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:57:1: warning: "CICR3" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:618:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:58:1: warning: "CICR4" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:619:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:59:1: warning: "CISR" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:620:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:60:1: warning: "CIFR" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:621:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:61:1: warning: "CITOR" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:622:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:62:1: warning: "CIBR0" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:623:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:63:1: warning: "CIBR1" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:624:1: warning: this is the location of the previous definition /marune/build/v4l-dvb-master/v4l/pxa_camera.c:64:1: warning: "CIBR2" redefined arch/arm/mach-pxa/include/mach/pxa-regs.h:625:1: warning: this is the location of the previous definition It compiles fine under 2.6.29. Can you either try to fix this for kernels 2.6.27/28, or can I assume that this driver will only compile correctly under 2.6.29? I don't know what the status is of this driver for these older kernels, so I don't dare touch this without input from you. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - gspca: fix compiler warning Thanks, Hans diffstat: t613.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: make card signed
On Sun, 18 Jan 2009 15:55:15 +0100
Roel Kluin wrote:
> Is this correct?
No, it isn't. There's no sense on a negative value for a card.
> --->8--8<
> make card signed
>
> Signed-off-by: Roel Kluin
> ---
> diff --git a/drivers/media/video/em28xx/em28xx-cards.c
> b/drivers/media/video/em28xx/em28xx-cards.c
> index ef9bf00..7c7a96c 100644
> --- a/drivers/media/video/em28xx/em28xx-cards.c
> +++ b/drivers/media/video/em28xx/em28xx-cards.c
> @@ -47,7 +47,7 @@ static unsigned int disable_ir;
> module_param(disable_ir, int, 0444);
> MODULE_PARM_DESC(disable_ir, "disable infrared remote support");
>
> -static unsigned int card[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = UNSET };
> +static int card[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = UNSET };
> module_param_array(card, int, NULL, 0444);
> MODULE_PARM_DESC(card, "card type");
>
> --
> 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
--
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] Bttv: move check on unsigned
On Sat, 24 Jan 2009 17:27:09 -0800 (PST) Trent Piepho wrote: > On Mon, 19 Jan 2009, Trent Piepho wrote: > > On Sat, 17 Jan 2009, Roel Kluin wrote: > > > Please review, this patch was not tested. > > > > > > The static function set_tvnorm is called in > > > drivers/media/video/bt8xx/bttv-driver.c: > > > > > > 1355: set_tvnorm(btv, norm); > > > 1868: set_tvnorm(btv, i); > > > 3273: set_tvnorm(btv,btv->tvnorm); > > > > > > in the first two with an unsigned, but bttv->tvnorm is signed. > > > > Probably better to just change bttv->tvnorm is unsigned if we can. > > Here is an improved patch that does a full tvnorm fix for the driver. The > tvnorm value is an index into an array and is never allowed to be negative > or otherwise invalid. Most places it was passed around were unsigned, but > a few structs and functions had signed values. > > I got rid of the "< 0" checks and changed some ">= BTTV_TVNORMS" checks > to BUG_ON(). > > Any problems with this patch Roel? > > Mauro, don't apply as is, I'll send a pull request for a real patch later. Ok. 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
Merging the v4l2 spec?
Hi Mauro, Is it possible to merge the v4l2 spec from my tree soon? With all the various new API additions that are being discussed it would help a lot if they can also make patches against the documentation at the same time. BTW, I'm working on improving the qv4l2 tool to make it much more useful for testing. I'm integrating it with the v4lconvert lib and added capture support as well. It should become a proper testbench for drivers. All the other tools around are really crappy, so I decided to extend qv4l2 instead. I've also bought a bunch of old hardware from ebay. I should be able to test various old v4l1 drivers and convert them to v4l2. I basically want to be able to test pretty much the whole v4l2 API, preferably with qv4l2. Yesterday two webcams came in, so I can now test w9968cf and se401. Check out my qv4l2 tree for progress on this tool! Now all I need is lots more time :-( Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
On Thursday 29 January 2009 09:28:07 Shah, Hardik wrote:
> > -Original Message-
> > From: DongSoo Kim [mailto:dongsoo@gmail.com]
> > Sent: Thursday, January 29, 2009 1:14 PM
> > To: Shah, Hardik
> > Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com
> > Subject: Re: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
> >
> > Hello.
> >
> > > +#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
> >
> > v4l2_color_space_conversion)
> >
> > > +#define VIDIOC_G_COLOR_SPACE_CONV _IOR('V', 84, struct
> >
> > v4l2_color_space_conversion)
> >
> > Do you mind if I ask a question about those ioctls?
> > Because as far as I understand, we can use VIDIOC_S_FMT ioctl to
> > convert colorspaces. Setting through colorspace member in
> > v4l2_pix_format, we could change output colorspace.
> > If there is some different use, can you tell me what it is?
>
> [Shah, Hardik] OMAP Display sub-system supports various pixel formats as
> inputs like YUV, UYVY, RGB24, RGB16 but the compositors which take these
> input format and displays on to the output devices like TV, LCD can only
> understand RGB format. Hardware has provision for converting any data
> taken in YUV or UYVY format to be converted into the RGB formats, before
> giving it to the output devices. To convert this hardware needs to be
> programmed with correct coefficient and offsets to convert from YUV to
> RGB.
Does that mean that when I select a YUV format for output, I still need to
call the color space conversion ioctl? That is not right. Selecting a
format must setup the CSC with decent defaults. I assumed the CSC ioctls
were only meant for fine-grained control: first you call S_FMT to select
the pixelformat which sets up the CSC with defaults, then you call
VIDIOC_G/S_COLOR_SPACE_CONV to modify them if needed.
Regards,
Hans
> These coefficients are pretty standard but still some one may
> require altering it. For this new ioctl is added. Standard equation for
> converting from YUV or UYVY is
>
> | R | | RY RCr RCb | | Y - 16 |
> | G | = 1/K | Gy GCr Gcb | * | Cr - 128 |
> | B | | By BCr BCb | | Cb - 128 |
>
> Where Ry, Rcr, Rcb Gy, Gcr, Gcb, By, Bcr and Bcb are the programmable
> coefficients. But in future offsets like Y-16, Cr-128 or Cb-128 or
> constant like 1/K may also be programmable. So I have added this new
> ioctl.
>
> Regards,
> Hardik Shah
>
> > Regards,
> > Nate
> >
> > --
> >
> > Dong Soo, Kim
> > Engineer
> > Mobile S/W Platform Lab. S/W centre
> > Telecommunication R&D Centre
> > Samsung Electronics CO., LTD.
> > e-mail : dongsoo@gmail.com
> >dongsoo45@samsung.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
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
On Thursday 29 January 2009 08:44:20 DongSoo Kim wrote:
> Hello.
>
> > +#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
> > v4l2_color_space_conversion) +#define VIDIOC_G_COLOR_SPACE_CONV
> > _IOR('V', 84, struct v4l2_color_space_conversion)
>
> Do you mind if I ask a question about those ioctls?
> Because as far as I understand, we can use VIDIOC_S_FMT ioctl to convert
> colorspaces. Setting through colorspace member in v4l2_pix_format, we
> could change output colorspace.
Colorspace is read-only, you cannot set it. It just gives you the colorspace
that the hardware uses by default.
If you want to fully control the colorspace, then you need these ioctls.
Regards,
Hans
> If there is some different use, can you tell me what it is?
>
> Regards,
> Nate
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
> -Original Message-
> From: DongSoo Kim [mailto:dongsoo@gmail.com]
> Sent: Thursday, January 29, 2009 1:14 PM
> To: Shah, Hardik
> Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com
> Subject: Re: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
>
> Hello.
>
> > +#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
> v4l2_color_space_conversion)
> > +#define VIDIOC_G_COLOR_SPACE_CONV _IOR('V', 84, struct
> v4l2_color_space_conversion)
>
> Do you mind if I ask a question about those ioctls?
> Because as far as I understand, we can use VIDIOC_S_FMT ioctl to convert
> colorspaces. Setting through colorspace member in v4l2_pix_format, we
> could change output colorspace.
> If there is some different use, can you tell me what it is?
>
[Shah, Hardik] OMAP Display sub-system supports various pixel formats as inputs
like YUV, UYVY, RGB24, RGB16 but the compositors which take these input format
and displays on to the output devices like TV, LCD can only understand RGB
format. Hardware has provision for converting any data taken in YUV or UYVY
format to be converted into the RGB formats, before giving it to the output
devices. To convert this hardware needs to be programmed with correct
coefficient and offsets to convert from YUV to RGB. These coefficients are
pretty standard but still some one may require altering it. For this new ioctl
is added. Standard equation for converting from YUV or UYVY is
| R | | RY RCr RCb | | Y - 16 |
| G | = 1/K | Gy GCr Gcb | * | Cr - 128 |
| B | | By BCr BCb | | Cb - 128 |
Where Ry, Rcr, Rcb Gy, Gcr, Gcb, By, Bcr and Bcb are the programmable
coefficients. But in future offsets like Y-16, Cr-128 or Cb-128 or constant
like 1/K may also be programmable. So I have added this new ioctl.
Regards,
Hardik Shah
> Regards,
> Nate
>
> --
>
> Dong Soo, Kim
> Engineer
> Mobile S/W Platform Lab. S/W centre
> Telecommunication R&D Centre
> Samsung Electronics CO., LTD.
> e-mail : dongsoo@gmail.com
>dongsoo45@samsung.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: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
Hi Hardik, Just a minor point: it's enough to post to linux-media, no need to post to the video4linux list as well. I assume everyone involved in v4l-dvb has now subscribed to linux-media. On Thursday 29 January 2009 07:57:22 Shah, Hardik wrote: > > -Original Message- > > From: Trent Piepho [mailto:xy...@speakeasy.org] > > Sent: Thursday, January 29, 2009 11:50 AM > > To: Shah, Hardik > > Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com; Jadav, > > Brijesh R; Nagalla, Hari; Hiremath, Vaibhav > > Subject: Re: [PATCHv2] New V4L2 ioctls for OMAP class of Devices > > > > On Thu, 29 Jan 2009, Hardik Shah wrote: > > > 1. Control ID added for rotation. Same as HFLIP. > > > 2. Control ID added for setting background color on > > > output device. > > > 3. New ioctl added for setting the color space conversion from > > > YUV to RGB. > > > 4. Updated the v4l2-common.c file according to comments. > > > > Wasn't there supposed to be some documentation? > > > > > + case V4L2_CID_BG_COLOR: > > > + /* Max value is 2^24 as RGB888 is used for background color */ > > > + return v4l2_ctrl_query_fill(qctrl, 0, 16777216, 1, 0); > > > > Wouldn't it make more sense to set background in the same colorspace as > > the selected format? > > [Shah, Hardik] Background color setting can be done only in the RGB space > as hardware doesn't understand YUV or RGB565 for the background color > setting. And background color and pixel format are not related. If we > want to have the background setting format same as the color format then > driver will have to do the color conversion and that is not optimal. In the case of a chromakey the value is interpreted according to the pixel format of the associated framebuffer. However, if I understand the omap architecture correctly, this background color is pretty much independent from either graphics or videoplane pixel formats. As such it makes sense to fix it to a specific pixel format and let the driver transform it if it needs to. It is similar in that respect to the V4L2_CID_MPEG_VIDEO_MUTE_YUV control. The documentation needs to specify the format precisely, of course. I also noticed this: @@ -548,6 +553,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32 min, s32 max, s32 ste case V4L2_CID_CONTRAST: case V4L2_CID_SATURATION: case V4L2_CID_HUE: + case V4L2_CID_BG_COLOR: qctrl->flags |= V4L2_CTRL_FLAG_SLIDER; break; } BG_COLOR is hardly a slider-like control! It's just a regular integer control. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
