On Wed, 6 Jun 2012, Janusz Uzycki wrote: > Hi. > > > Sorry, this is not going to be a very detailed reply. It's been a long > > time since I've worked with VOU and AK8813(4). > > I see. > > > > If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC. > > > > This shouldn't be the case: look at sh_vou_s_std(). Can you try to add > > debugging to the driver to see, whether that function gets called, when > > you run v4l2-ctl? If not - either you're calling it wrongly, or there's a > > bug in it. If it is - see, whether it's not configuring VOUCR properly or > > somehow it gets reset again later. > > Before I turned on CONFIG_VIDEO_ADV_DEBUG only for I2C debug (v4l2-dbg). Now I > turned on dynamic printk (dev_dbg) for sh_vou.c and observed that > sh_vou_open() calls sh_vou_hw_init() what causes VOU reset: > v4l2-ctl -s 5 > sh-vou sh-vou: sh_vou_open() > sh-vou sh-vou: Reset took 1us > sh-vou sh-vou: sh_vou_querycap() > sh-vou sh-vou: sh_vou_s_std(): 0xff > CS495X-set: VOUER was 0x00000000, now SEN and ST bits are set > CS495X set format: 000000ff > CS495X-set: VOUER 0x00000000 restored > sh-vou sh-vou: sh_vou_release() > Standard set to 000000ff > > This is why "v4l2-ctl -s 5" used before my simple test program (modified > capture example with mmap method) finally has no effect for VOU. > When the test program opens video device it causes reset PAL mode in VOU and > does not in TV encoder. Right, this is actually a bug in the VOU driver. It didn't affect me, because I was opening the device only once before all the configuration and streaming. Could you create and submit a patch to save the standard in driver private data and restore it on open() after the reset? I guess, other configuration parameters are lost too, feel free to fix them as well. > Thanks Guennadi for the hints. > (VOUER messages explanation: I have to set SEN and ST bits in CS49X driver > because the chip needs 27MHz clock to I2C block operate) > > > > I noticed that VOU is limited to NTSC resolution: "Maximum destination > > > image > > > size: 720 x 240 per field". > > > > You mean in the datasheet? > > Yes, exactly. > > > I don't have it currently at hand, but I seem > > to remember, that there was a bug and the VOU does actually support a full > > PAL resolution too. I'm not 100% certain, though. > > OK, I will test it. Do you remember how you discovered that? Asked the manufacturer company :) > > > Unfortunately I can't still manage to work video data from VOU to the > > > encoder > > > - green picture only. Do you have any test program for video v4l2 output? > > > > You can use gstreamer, e.g.: > > > > gst-launch -v filesrc location=x.avi ! decodebin ! ffmpegcolorspace ! \ > > video/x-raw-rgb,bpp=24 ! v4l2sink device=/dev/video0 tv-norm=PAL-B > > thanks > > > I also used a (possibly modified) program by Laurent (cc'ed) which either > > I - with his agreement - can re-send to you, or maybe he'd send you the > > original. > > ok, is it media-ctl (git://git.ideasonboard.org/media-ctl.git)? No, I'll send it to you off the list - Laurent agreed. But he also said, it was a preliminary version of his yavta proram, so, you might be able to use that one. > > > Does > > > the idea fb->v4l2 output > > > http://www.spinics.net/lists/linux-fbdev/msg01102.html is alive? > > > > More dead, than alive, I think. > > Ok. Did you find another solution (software/library like DirectFB) for common > and easier video output support in userspace? No, sorry, I did not. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
