[RESEND][GIT PATCHES for 2.6.39] ivtv fixes
Mauro, Please pull the following ivtv patches for 2.6.39. Thanks go to David Alan Gilbert for reporting a problem I failed to clean up properly the first time, and Paul Cassella for providing fixes for long-standing problems in error handling. Regards, Andy The following changes since commit ffd14aab03dbb8bb1bac5284603835f94d833bd6: [media] au0828: fix VBI handling when in V4L2 streaming mode (2011-02-02 12:06:14 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git ivtv_39 Andy Walls (1): ivtv: Fix sparse warning regarding a user pointer in ivtv_write_vbi_from_user() Paul Cassella (3): Documentation: README.ivtv: Remove note that ivtvfb is not yet in the kernel ivtv: udma: handle get_user_pages() returning fewer pages than we asked for ivtv: yuv: handle get_user_pages() -errno returns Documentation/video4linux/README.ivtv |3 +- drivers/media/video/ivtv/ivtv-udma.c |7 - drivers/media/video/ivtv/ivtv-vbi.c |2 +- drivers/media/video/ivtv/ivtv-yuv.c | 52 +--- 4 files changed, 48 insertions(+), 16 deletions(-) -- 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
[UPDATED] [GIT FIXES for 2.6.38] Fix cx23885 and cx25840 regressions, fix ivtv DMA error handling, and add new cx18 board profile.
Mauro, Please pull the following fixes for 2.6.38. This is a resend of my original pull request with two additional patches. Thanks go to Sven Barth for reporting the regression with the CX2583x chips in cx25840 and providing a patch. Thanks also go to Mark Zimmerman for climing the git learning curve and devoting the time perform a git bisect to isolate the cx23885 regression. Thanks go to Michael for perform some excellent reasoning and working up a patch to correct a long standing problem with the way the ivtv driver deals with certain DMA Errors. Thanks also go to Pete for testing Mike's patch. (I have altered Michael's original patch slightly, to clear status errors only when it should be safe to do so without hanging the DMA engine.) Thanks to Devin and Hauppauge for adding a new board profile for the latest HVR-1600 designs having a different DTV tuner and demodulator. I think that's everyone... Regards, Andy The following changes since commit cf720fed25b8078ce0d6a10036dbf7a0baded679: [media] add support for Encore FM3 (2011-01-19 16:42:42 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git cx-fix-38 Andy Walls (2): cx23885: Revert "Check for slave nack on all transactions" cx23885: Remove unused 'err:' labels to quiet compiler warning Devin Heitmueller (1): cx18: Add support for Hauppauge HVR-1600 models with s5h1411 Michael (1): ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang Sven Barth (1): cx25840: fix probing of cx2583x chips drivers/media/video/cx18/cx18-cards.c | 50 +++- drivers/media/video/cx18/cx18-driver.c | 25 +++- drivers/media/video/cx18/cx18-driver.h |3 +- drivers/media/video/cx18/cx18-dvb.c| 38 ++ drivers/media/video/cx23885/cx23885-i2c.c | 10 - drivers/media/video/cx25840/cx25840-core.c |3 +- drivers/media/video/ivtv/ivtv-irq.c| 58 --- 7 files changed, 165 insertions(+), 22 deletions(-) -- 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 06/21]drivers:media:cx23418.h remove one to many l's in the word.
On Thu, 2011-02-24 at 22:11 -0800, Justin P. Mattock wrote: > The patch below removes an extra "l" in the word. > > Signed-off-by: Justin P. Mattock > > --- > drivers/media/video/cx18/cx23418.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/cx18/cx23418.h > b/drivers/media/video/cx18/cx23418.h > index 7e40035..935f557 100644 > --- a/drivers/media/video/cx18/cx23418.h > +++ b/drivers/media/video/cx18/cx23418.h > @@ -477,7 +477,7 @@ > /* The are no buffers ready. Try again soon! */ > #define CXERR_NODATA_AGAIN 0x1E > > -/* The stream is stopping. Function not alllowed now! */ > +/* The stream is stopping. Function not allowed now! */ If the spelling mistake is worthy of a fix, why isn't the egregious grammar mistake also worth fixing? Also, those aren't the only spelling and grammar mistakes in comments in that file. -Andy > #define CXERR_STOPPING_STATUS 0x1F > > /* Trying to access hardware when the power is turned OFF */ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.39] ds3000 frontend, dw2102 driver patches
Git repository was created for better handling long series of patches. It includes dw2102 series and 5'th to 9'th from ds3000 series in right order. Patces 1 to 4 already included in staging/for_v2.6.39 branch. The following changes since commit a26a7a97ddce9c3152fca28e7eaacc96d9207148: [media] pvrusb2: Use sysfs_attr_init() where appropriate (2011-02-24 20:47:36 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git ds3000 Igor M. Liplianin (17): dw2102: Extend keymap parameter for not used remote dw2102: use separate firmwares for Prof 1100, TeVii S630, S660 dw2102: add support for Geniatech SU3000 USB DVB-S2 card. dw2102: Add Terratec Cinergy S2 USB HD dw2102: Prof 7500: Lock LED implemented. dw2102: Prof 7500 remote fix. dw2102: Prof 1100 initialization fix dw2102: unnecessary NULL's removed dw2102: corrections for TeVii s660 LNB power control dw2102: fix TeVii s660 remote control dw2102: add support for the TeVii S480 PCIe. dw2102: Copyright, cards list updated ds3000: clean up in tune procedure ds3000: remove unnecessary dnxt, dcur structures ds3000: add carrier offset calculation ds3000: hardware tune algorithm cx88: add support for TeVii S464 PCI card. drivers/media/dvb/dvb-usb/dw2102.c | 507 +--- drivers/media/dvb/frontends/ds3000.c | 600 +--- drivers/media/dvb/frontends/ds3000.h |3 + drivers/media/dvb/frontends/stv0900.h |2 + drivers/media/dvb/frontends/stv0900_core.c | 23 +- drivers/media/video/cx88/cx88-cards.c | 17 + drivers/media/video/cx88/cx88-dvb.c| 23 + drivers/media/video/cx88/cx88-input.c |1 + drivers/media/video/cx88/cx88.h|1 + 9 files changed, 798 insertions(+), 379 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Fri, 25 Feb 2011, Sakari Ailus wrote: > On Fri, Feb 25, 2011 at 06:08:07PM +0100, Guennadi Liakhovetski wrote: > > Hi Sakari > > Hi Guennadi, > > > On Fri, 25 Feb 2011, Sakari Ailus wrote: > > > I agree with that. Flash synchronisation is just one of the many > > > parameters > > > that would benefit from frame level synchronisation. Exposure time, gain > > > etc. are also such. The sensors provide varying level of hardware support > > > for all these. > > > > Well, that's true, but... From what I've seen so far, many sensors > > synchronise such sensitive configuration changes with their frame readout > > automatically, i.e., you configure some new parameter in a sensor > > register, but it will only become valid with the next frame. On other > > sensors you can issue a "hold" command, perform any needed changed, then > > issue a "commit" and all your changes will be applied atomically. > > At that level it's automatic, but what I meant is synchronising the > application of the settings to the exposure start of a given frame. This is > very similar to flash synchronisation. Right... But I don't think we can do more, than what the sensor supports about this, can we? Only stop the sensor, apply parameters, start the sensor... > > Also, we already _can_ configure gain, exposure and many other parameters, > > but we have no way to use sensor snapshot and flash-synchronisation > > capabilities. > > There is a way to configure them but the interface doesn't allow to specify > when they should take effect. ??? There are V4L ioctl()s to control the flash?... > FCam type applications requires this sort of functionality. > > http://fcam.garage.maemo.org/> > > > What we could also do, we could add an optional callback to subdev (core?) > > operations, which, if activated, the host would call on each frame > > completion. > > It's not quite that simple. The exposure of the next frame has started long > time before that. This requires much more thought probably --- in the case > of lack of hardware support, when the parameters need to be actually given > to the sensor depend somewhat on sensors, I suppose. Yes, that's right. I seem to remember, there was a case, for which such a callback would have been useful... Don't remember what that was though. > > > Flash and indicator power setting can be included to the list of controls > > > above. > > > > As I replied to Laurent, not sure we need to control the power indicator > > from V4L2, unless there are sensors, that have support for that. > > Um, flash controllers, that is. Yes, there are; the ADP1653, which is just > one example. No, not flash controllers, just an indicator, that a capture is running (normally a small red LED). > > > The power management of the camera is > > > preferrably optimised for speed so that the camera related devices need > > > not > > > to be power cycled when using it. If the flash interface is available on a > > > subdev separately the flash can also be easily powered separately without > > > making this a special case --- the rest of the camera related devices > > > (ISP, > > > lens and sensor) should stay powered off. > > > > > > > configure the sensor to react on an external trigger provided by the > > > > flash > > > > controller is needed, and that could be a control on the flash > > > > sub-device. > > > > What we would probably miss is a way to issue a STREAMON with a number > > > > of > > > > frames to capture. A new ioctl is probably needed there. Maybe that > > > > would be > > > > an opportunity to create a new stream-control ioctl that could replace > > > > STREAMON and STREAMOFF in the long term (we could extend the subdev > > > > s_stream > > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl in > > > > video_ioctl2 internally). > > > > > > How would this be different from queueing n frames (in total; count > > > dequeueing, too) and issuing streamon? --- Except that when the last frame > > > is processed the pipeline could be stopped already before issuing > > > STREAMOFF. > > > That does indeed have some benefits. Something else? > > > > Well, you usually see in your host driver, that the videobuffer queue is > > empty (no more free buffers are available), so, you stop streaming > > immediately too. > > That's right. Disabling streaming does save some power but even more is > saved when switching the devices off completely. This is important in > embedded systems that are often battery powered. > > The hardware could be switched off when no streaming takes place. However, > this introduces extra delays to power-up at times they are unwanted --- for > example, when switching from viewfinder to still capture. > > The alternative to this is to add a timer to the driver: power off if no > streaming has taken place for n seconds, for example. I would consider this > much inferior to just providing a simple subdev for the flash chip and not > involve t
Re: [RFC] snapshot mode, flash capabilities and control
On Fri, 25 Feb 2011, Sakari Ailus wrote: > Hi Guennadi, > > Guennadi Liakhovetski wrote: > > In principle - yes, and yes, I do realise, that the couple of controls, > > that I've proposed only cover a very minor subset of the whole flash > > function palette. The purposes of my RFC were: > > Why would there be a different interface for controlling the flash in > simple cases and more complex cases? Sorry, not sure what you mean. Do you mean different APIs when the flash is controlled directly by the sensor and by an external controller? No, of course we need one API, but you either issue those ioctl()s to the sensor (sub)device, or to the dedicated flash (sub)device. If you mean my "minor subset" above, then I was trying to say, that this is a basis, that has to be extended, but not, that we will develop a new API for more complicated cases. > As far as I see it, the way the flash is accessed should be the same in > both cases --- if more complex functionality is required that would be > implemented in using additional ways (controls, for example). Of course, that's what we're discussing here - what functions have to be implemented. > The drivers should use sane defaults for controls like power and length. > I assume things like mode (strobe/continuous) is fairly standard > functionality. Yes, these are all the things, that we shall discuss... > > 1. get things started in the snapshot / flash direction;) > > 2. get access to dedicated snapshot / flash registers, present on many > > sensors and SoCs > > 3. get at least the very basic snapshot / flash functions, common to most > > hardware implementations, but trying to make it future-proof for further > > extensions > > 4. get a basis for a future detailed discussion > > > >> Let's also not forget that, in addition to the flash LEDs itself, devices > >> often feature an indicator LED (a small low-power red LED used to indicate > >> that video capture is ongoing). > > > > Well, this one doesn't seem too special to me? Wouldn't it suffice to just > > toggle it from user-space on streamon / streamoff? > > And what if you want to use the led unconnected to the streaming state? :-) That's even easier, isn't it? Just turn it on and off from your application whenever you want. > >> This doesn't solve the flash/capture synchronization problem though. I > >> don't > >> think we need a dedicated snapshot capture mode at the V4L2 level. A way > >> to > >> configure the sensor to react on an external trigger provided by the flash > >> controller is needed, and that could be a control on the flash sub-device. > > > > Well... Sensors call this a "snapshot mode." I don't care that much how we > > _call_ it, but I do think, that we should be able to use it. > > Some sensors and webcams might have that, but newer camera solutions > tend to contain a raw bayer sensor and and ISP. There is no concept of > snapsnot mode in these sensors. Hm, I am not sure I understand, why sensors with DSPs in them should have no notion of a snapshot mode. Do they have no strobe / trigger pins? And no built in possibility to synchronize with a flash? > > Hm, don't think only the "flash subdevice" has to know about this. First, > > you have to switch the sensor into that mode. Second, it might be either > > external trigger from the flash controller, or a programmed trigger and a > > flash strobe from the sensor to the flash (controller). Third, well, not > > quite sure, but doesn't the host have to know about the snapshot mode? > > I do not favour adding use case type of functionality to interfaces that > do not necessarily need it. Would the concept of a snapshot be > parametrisable on V4L2 level? I am open to this. I don't have a good idea of whether camera hosts have to know about the snapshot mode or not. It's open for discussion. > Otherwise we may end adding interfaces for use case specific things. The > use cases vary a lot more than the individual features that are required > to implement them, suggesting it's relatively easy to add redundant > functionality to the API. Sure, completely agree - if we can sufficiently implement all the needed functionality for those new use-cases with existing API, no need to add anything new. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Fri, Feb 25, 2011 at 06:08:07PM +0100, Guennadi Liakhovetski wrote: > Hi Sakari Hi Guennadi, > On Fri, 25 Feb 2011, Sakari Ailus wrote: > > I agree with that. Flash synchronisation is just one of the many parameters > > that would benefit from frame level synchronisation. Exposure time, gain > > etc. are also such. The sensors provide varying level of hardware support > > for all these. > > Well, that's true, but... From what I've seen so far, many sensors > synchronise such sensitive configuration changes with their frame readout > automatically, i.e., you configure some new parameter in a sensor > register, but it will only become valid with the next frame. On other > sensors you can issue a "hold" command, perform any needed changed, then > issue a "commit" and all your changes will be applied atomically. At that level it's automatic, but what I meant is synchronising the application of the settings to the exposure start of a given frame. This is very similar to flash synchronisation. > Also, we already _can_ configure gain, exposure and many other parameters, > but we have no way to use sensor snapshot and flash-synchronisation > capabilities. There is a way to configure them but the interface doesn't allow to specify when they should take effect. FCam type applications requires this sort of functionality. http://fcam.garage.maemo.org/> > What we could also do, we could add an optional callback to subdev (core?) > operations, which, if activated, the host would call on each frame > completion. It's not quite that simple. The exposure of the next frame has started long time before that. This requires much more thought probably --- in the case of lack of hardware support, when the parameters need to be actually given to the sensor depend somewhat on sensors, I suppose. > > Flash and indicator power setting can be included to the list of controls > > above. > > As I replied to Laurent, not sure we need to control the power indicator > from V4L2, unless there are sensors, that have support for that. Um, flash controllers, that is. Yes, there are; the ADP1653, which is just one example. > > The power management of the camera is > > preferrably optimised for speed so that the camera related devices need not > > to be power cycled when using it. If the flash interface is available on a > > subdev separately the flash can also be easily powered separately without > > making this a special case --- the rest of the camera related devices (ISP, > > lens and sensor) should stay powered off. > > > > > configure the sensor to react on an external trigger provided by the > > > flash > > > controller is needed, and that could be a control on the flash > > > sub-device. > > > What we would probably miss is a way to issue a STREAMON with a number of > > > frames to capture. A new ioctl is probably needed there. Maybe that would > > > be > > > an opportunity to create a new stream-control ioctl that could replace > > > STREAMON and STREAMOFF in the long term (we could extend the subdev > > > s_stream > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl in > > > video_ioctl2 internally). > > > > How would this be different from queueing n frames (in total; count > > dequeueing, too) and issuing streamon? --- Except that when the last frame > > is processed the pipeline could be stopped already before issuing STREAMOFF. > > That does indeed have some benefits. Something else? > > Well, you usually see in your host driver, that the videobuffer queue is > empty (no more free buffers are available), so, you stop streaming > immediately too. That's right. Disabling streaming does save some power but even more is saved when switching the devices off completely. This is important in embedded systems that are often battery powered. The hardware could be switched off when no streaming takes place. However, this introduces extra delays to power-up at times they are unwanted --- for example, when switching from viewfinder to still capture. The alternative to this is to add a timer to the driver: power off if no streaming has taken place for n seconds, for example. I would consider this much inferior to just providing a simple subdev for the flash chip and not involve the ISP at all. Regards, -- Sakari Ailus sakari dot ailus at iki dot fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
Hi Guennadi, Guennadi Liakhovetski wrote: > In principle - yes, and yes, I do realise, that the couple of controls, > that I've proposed only cover a very minor subset of the whole flash > function palette. The purposes of my RFC were: Why would there be a different interface for controlling the flash in simple cases and more complex cases? As far as I see it, the way the flash is accessed should be the same in both cases --- if more complex functionality is required that would be implemented in using additional ways (controls, for example). The drivers should use sane defaults for controls like power and length. I assume things like mode (strobe/continuous) is fairly standard functionality. > 1. get things started in the snapshot / flash direction;) > 2. get access to dedicated snapshot / flash registers, present on many > sensors and SoCs > 3. get at least the very basic snapshot / flash functions, common to most > hardware implementations, but trying to make it future-proof for further > extensions > 4. get a basis for a future detailed discussion > >> Let's also not forget that, in addition to the flash LEDs itself, devices >> often feature an indicator LED (a small low-power red LED used to indicate >> that video capture is ongoing). > > Well, this one doesn't seem too special to me? Wouldn't it suffice to just > toggle it from user-space on streamon / streamoff? And what if you want to use the led unconnected to the streaming state? :-) >> This doesn't solve the flash/capture synchronization problem though. I don't >> think we need a dedicated snapshot capture mode at the V4L2 level. A way to >> configure the sensor to react on an external trigger provided by the flash >> controller is needed, and that could be a control on the flash sub-device. > > Well... Sensors call this a "snapshot mode." I don't care that much how we > _call_ it, but I do think, that we should be able to use it. Some sensors and webcams might have that, but newer camera solutions tend to contain a raw bayer sensor and and ISP. There is no concept of snapsnot mode in these sensors. > Hm, don't think only the "flash subdevice" has to know about this. First, > you have to switch the sensor into that mode. Second, it might be either > external trigger from the flash controller, or a programmed trigger and a > flash strobe from the sensor to the flash (controller). Third, well, not > quite sure, but doesn't the host have to know about the snapshot mode? I do not favour adding use case type of functionality to interfaces that do not necessarily need it. Would the concept of a snapshot be parametrisable on V4L2 level? Otherwise we may end adding interfaces for use case specific things. The use cases vary a lot more than the individual features that are required to implement them, suggesting it's relatively easy to add redundant functionality to the API. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Feb 25 19:00:47 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WinTV HVR-900 (usb 2040:6500) (model 65008) / no audio but clicking noise
Hi! Now I bought a Hauppauge WinTV HVR-900 (USB, DVB-T/analog Hybrid). video is ok... But: Audio sounds almost as bad as before (with that Pinnacle stick): http://www.wgboome.de./hvr900.wav I used this mplayer command: mplayer -tv driver=v4l2:input=0:width=768:height=576:device=/dev/video2:alsa=1:forceaudio=1:adevice=hw.1:audiorate=48000:immediatemode=0:amode=0:norm=pal:chanlist=europe-west:freq=280 tv:// The difference to the Pinnacle thingy is: The correct audio isnt even in the background... I hear just that clicking noise... What did I do wrong? PS: With my PCI PVR-250 i have no problem... Thx. Bye Arne -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
Hi Guennadi and others, Apologies for the late reply... Guennadi Liakhovetski wrote: > On Wed, 23 Feb 2011, Hans Verkuil wrote: > >> On Tuesday, February 22, 2011 22:42:58 Sylwester Nawrocki wrote: >>> Clock values are often being rounded at runtime and do not always reflect >>> exactly >>> the numbers fixed at compile time. And negotiation could help to obtain >>> exact >>> values at both sensor and host side. >> >> The only static data I am concerned about are those that affect signal >> integrity. >> After thinking carefully about this I realized that there is really only one >> setting that is relevant to that: the sampling edge. The polarities do not >> matter in this. > > Ok, this is much better! I'm still not perfectly happy having to punish > all just for the sake of a couple of broken boards, but I can certainly > much better live with this, than with having to hard-code each and every > bit. Thanks, Hans! How much punishing would actually take place without autonegotiation? How many boards do we have in total? I counted around 26 of soc_camera_link declarations under arch/. Are there more? An example of hardware which does care about clock polarity is the N8[01]0. The parallel clock polarity is inverted since this actually does improve reliability. In an ideal hardware this likely wouldn't happen but sometimes the hardware is not exactly ideal. Both the sensor and the camera block support non-inverted and inverted clock signal. So at the very least it should be possible to provide this information in the board code even if both ends share multiple common values for parameters. There have been many comments on the dangers of the autonegotiation and I share those concerns. One of my main concerns is that it creates an unnecessary dependency from all the boards to the negotiation code, the behaviour of which may not change. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
Support for device 0CCD:00B2 ?
Hello, I have now bought a Terratec Cinergy HTC, 0CCD:00B2. Unfortunately I do not know which chipset this device uses, it handles DVB-T,DVB-C and analog cable TV. Is there already a kernel module supporting this device? Thanx Malte -- 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 5/9 v2] ds3000: clean up in tune procedure
В сообщении от 25 февраля 2011 01:33:41 автор Mauro Carvalho Chehab написал: > Em 24-02-2011 17:25, Igor M. Liplianin escreveu: > > В сообщении от 24 февраля 2011 21:11:13 автор Mauro Carvalho Chehab написал: > >> Em 24-02-2011 16:04, Mauro Carvalho Chehab escreveu: > >>> Hi Igor, > >>> > >>> Em 01-02-2011 20:40, Igor M. Liplianin escreveu: > Variable 'retune' does not make sense. > Loop is not needed for only one try. > Remove unnecessary dprintk's. > > Signed-off-by: Igor M. Liplianin > >>> > >>> This patch didn't apply. Please fix and resend. > >> > >> PS.: I won't try to apply patches 7, 8 and 9, as they are all related to > >> tune changes. They'll probably fail to apply, and, even if not failing > >> or if I fix the conflicts, they may be breaking the driver. So, please > >> put them on your next patch series. > >> > >> thanks! > >> Mauro > > > > Hi Mauro, > > > > Will do tonight. > > OK. > > > BTW, Why did you dropp/miss dw2102 patches? > > They was sent before ds3000 series. > > I probably missed, or they are still on my queue. While in general I apply > patches in order, sometimes I reorder them, trying to merge first the more > trivial ones (or the ones that I had already analyzed, like the altera > ones). Please take a look at Patchwork. If they're there, then I'll > probably be handling until the weekend. Otherwise, just re-send them to > me. Patches you already included are OK, but 5 to 9 needs(and depend) to be applied after dw2102 series. I can rebase in differend order, but what's a matter? I will create git tree somwere (probably at assembla), push there and send you pull request. > > That's said, it is probably a good idea if you could have a git repository > somewhere to send me patches. Git works better when there are lots of > patches, so, works better for driver maintainers. If you want, I may > create you an account at LinuxTV (or you may host it on any other place). I will appreciate you very much if you create it for me, as I have a lot of stuff to commit. Thank you in advance. Igor > > Thanks, > Mauro > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [st-ericsson] v4l2 vs omx for camera
2011/2/24 Edward Hervey : > What *needs* to be solved is an API for data allocation/passing at the > kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > userspace (like GStreamer) can pass around, monitor and know about. I think the patches sent out from ST-Ericsson's Johan Mossberg to linux-mm for "HWMEM" (hardware memory) deals exactly with buffer passing, pinning of buffers and so on. The CMA (Contigous Memory Allocator) has been slightly modified to fit hand-in-glove with HWMEM, so CMA provides buffers, HWMEM pass them around. Johan, when you re-spin the HWMEM patchset, can you include linaro-dev and linux-media in the CC? I think there is *much* interest in this mechanism, people just don't know from the name what it really does. Maybe it should be called mediamem or something instead... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
Hi Sakari On Fri, 25 Feb 2011, Sakari Ailus wrote: > On Fri, Feb 25, 2011 at 11:05:05AM +0100, Laurent Pinchart wrote: > > Hi, > > Hi, > > > On Thursday 24 February 2011 18:57:22 Kim HeungJun wrote: > > > Hi Guennadi, > > > > > > I think, it's maybe a good suggestion for current trend! ( I'm not sure > > > this express *trend* is right :)) > > > > > > But, the flash or strobe control connected with sensor can be controlled > > > by > > > user application directly, not in the sensor subdev device. For example, > > > let's think that there is a Flash light application. Its function is just > > > power-up LED. So, in this case, if the flash control mechanism should be > > > used *only* in the V4L2 API belonging through S/G_PARM, this mechanism > > > might be a little complicated, nevertheless it's possible to control > > > led/strobe using S/G_PARM. I mean that we must check the camera must be in > > > the capture state or not, or another setting (like a FPS) should be > > > checked. Namely, for powering up LED, the more procedure is needed. > > > > > > Also, we can think another case. Generally, the LED/STROBE/FLASH is > > > connected with camera sensor directly, but another case can be existed > > > that LED connected with Processor by controlling GPIO. So, In this case, > > > using LED framework look more better I guess, and then user application > > > access LED frame sysfs node eaisly. > > > > The flash is usually handled by a dedicated I2C flash controller (such as > > the > > ADP1653 used in the N900 - http://www.analog.com/static/imported- > > files/data_sheets/ADP1653.pdf), which is in that case mapped to a > > v4l2_subdev. > > Simpler solutions of course exist, such as GPIO LEDs or LEDs connected > > directly to the sensor. We need an API that can support all those hardware > > options. > > > > Let's also not forget that, in addition to the flash LEDs itself, devices > > often feature an indicator LED (a small low-power red LED used to indicate > > that video capture is ongoing). The flash LEDs can also be used during > > video > > capture, and in focus assist mode (pre-flashing also comes to mind). > > > > In addition to the modes, flash controllers can generate strobe signals or > > react on them. Durations are programmable, as well as current limits, and > > sometimes PWM/current source mode selection. The device can usually detect > > faults (such as over-current or over-temperature faults) that need to be > > reported to the user. And we haven't even discussed Xenon flashes. > > > > Given the wide variety of parameters, I think it would make sense to use > > V4L2 > > controls on the sub-device directly. If the flash LEDs are connected > > directly > > to the sensor, controls on the sensor sub-device can be used to select the > > flash parameters. > > > > This doesn't solve the flash/capture synchronization problem though. I > > don't > > think we need a dedicated snapshot capture mode at the V4L2 level. A way to > > I agree with that. Flash synchronisation is just one of the many parameters > that would benefit from frame level synchronisation. Exposure time, gain > etc. are also such. The sensors provide varying level of hardware support > for all these. Well, that's true, but... From what I've seen so far, many sensors synchronise such sensitive configuration changes with their frame readout automatically, i.e., you configure some new parameter in a sensor register, but it will only become valid with the next frame. On other sensors you can issue a "hold" command, perform any needed changed, then issue a "commit" and all your changes will be applied atomically. Also, we already _can_ configure gain, exposure and many other parameters, but we have no way to use sensor snapshot and flash-synchronisation capabilities. What we could also do, we could add an optional callback to subdev (core?) operations, which, if activated, the host would call on each frame completion. > Flash and indicator power setting can be included to the list of controls > above. As I replied to Laurent, not sure we need to control the power indicator from V4L2, unless there are sensors, that have support for that. > One more thing that suggests the flash control should be available as a > separate subdev is to support the use of flash in torch mode without > performing streaming at all. Well, yes, that's what my V4L2_MODE_FLASH_ON was supposed to do - independent from the streaming status. Maybe placing it in v4l2_captureparm::capturemode made it look like it was related to streaming status, but it certainly should be possible without any capture at all. > The power management of the camera is > preferrably optimised for speed so that the camera related devices need not > to be power cycled when using it. If the flash interface is available on a > subdev separately the flash can also be easily powered separately without > making this a special case --- the rest of
Re: [RFC] snapshot mode, flash capabilities and control
Hi Laurent On Fri, 25 Feb 2011, Laurent Pinchart wrote: > Hi, > > On Thursday 24 February 2011 18:57:22 Kim HeungJun wrote: > > Hi Guennadi, > > > > I think, it's maybe a good suggestion for current trend! ( I'm not sure > > this express *trend* is right :)) > > > > But, the flash or strobe control connected with sensor can be controlled by > > user application directly, not in the sensor subdev device. For example, > > let's think that there is a Flash light application. Its function is just > > power-up LED. So, in this case, if the flash control mechanism should be > > used *only* in the V4L2 API belonging through S/G_PARM, this mechanism > > might be a little complicated, nevertheless it's possible to control > > led/strobe using S/G_PARM. I mean that we must check the camera must be in > > the capture state or not, or another setting (like a FPS) should be > > checked. Namely, for powering up LED, the more procedure is needed. > > > > Also, we can think another case. Generally, the LED/STROBE/FLASH is > > connected with camera sensor directly, but another case can be existed > > that LED connected with Processor by controlling GPIO. So, In this case, > > using LED framework look more better I guess, and then user application > > access LED frame sysfs node eaisly. > > The flash is usually handled by a dedicated I2C flash controller (such as the > ADP1653 used in the N900 - http://www.analog.com/static/imported- > files/data_sheets/ADP1653.pdf), which is in that case mapped to a > v4l2_subdev. > Simpler solutions of course exist, such as GPIO LEDs or LEDs connected > directly to the sensor. We need an API that can support all those hardware > options. In principle - yes, and yes, I do realise, that the couple of controls, that I've proposed only cover a very minor subset of the whole flash function palette. The purposes of my RFC were: 1. get things started in the snapshot / flash direction;) 2. get access to dedicated snapshot / flash registers, present on many sensors and SoCs 3. get at least the very basic snapshot / flash functions, common to most hardware implementations, but trying to make it future-proof for further extensions 4. get a basis for a future detailed discussion > Let's also not forget that, in addition to the flash LEDs itself, devices > often feature an indicator LED (a small low-power red LED used to indicate > that video capture is ongoing). Well, this one doesn't seem too special to me? Wouldn't it suffice to just toggle it from user-space on streamon / streamoff? > The flash LEDs can also be used during video > capture, and in focus assist mode (pre-flashing also comes to mind). Sure, so, we have to design an API, that addresses the basic uses, we see immediately in sensors, but also try to make it extensible? Are there sensors, that do that pre-flashing automatically? If not, then you probably use some dedicated controller for that? > In addition to the modes, flash controllers can generate strobe signals or > react on them. Durations are programmable, as well as current limits, and > sometimes PWM/current source mode selection. The device can usually detect > faults (such as over-current or over-temperature faults) that need to be > reported to the user. And we haven't even discussed Xenon flashes. > > Given the wide variety of parameters, I think it would make sense to use V4L2 > controls on the sub-device directly. If the flash LEDs are connected directly > to the sensor, controls on the sensor sub-device can be used to select the > flash parameters. But you're not proposing to handle on-sensor flash controls from a separate subdevice? But isn't it possible, to have this functionality either attached to the sensor subdevice or to a dedicated flash subdevice? Maybe we could just add a flash capability indicator to the subdev API? And flash is not unique here, same holds for some other functions, e.g., shutter / exposure - you can either use on-chip electronic exposure control, or an external mechanical shutter, also possible controlled by a separate IC... Same for lenses, etc? > This doesn't solve the flash/capture synchronization problem though. I don't > think we need a dedicated snapshot capture mode at the V4L2 level. A way to > configure the sensor to react on an external trigger provided by the flash > controller is needed, and that could be a control on the flash sub-device. Well... Sensors call this a "snapshot mode." I don't care that much how we _call_ it, but I do think, that we should be able to use it. Hm, don't think only the "flash subdevice" has to know about this. First, you have to switch the sensor into that mode. Second, it might be either external trigger from the flash controller, or a programmed trigger and a flash strobe from the sensor to the flash (controller). Third, well, not quite sure, but doesn't the host have to know about the snapshot mode? What would host have to know about? A diffe
Re: MT9P031 camera
On Fri, 25 Feb 2011, Ivan Nazarenko wrote: > Dear Dr. Guennadi. > > I have similar set-up as Mr. Valentini - a Beagleboard XM + leopard imaging > mt0p031 camera. > > Could you send me those patches too? Hi Ivan Patches are still at the same location, but they haven't become more useful since then. I plan to wait until MC / omap3isp get pulled in V4L abd then update the patches. Thanks Guennadi > > Regards, > > Ivan > > > > > On Fri, 18 Feb 2011, Juliano Valentini wrote: > > > > > Dears, > > > > > > I'm trying to apply Guennadi's patch > > > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/linux-2.6- > omap3isp-bbxm-mt9p031.gitdiff) > > > to official 2.6.37.1 Kernel version. > > > > No, this cannot work. That kernel patch requires media-controller and > > omap3isp, so, it is based on the omap3isp branch of the development tree > > by Laurent Pinchart: > > > > git://linuxtv.org/pinchartl/media.git > > > > But that tree has been rebased since then, so, I wouldn't expect that > > patch to apply cleanly, porting it to the current kernel would require a > > non-zero development effort. > > > > > I suppose that kernel version is wrong or missing previous patches > > > (see result at the end). > > > I have to make it work: MT9P031 SoC camera module on Beagleboard Xm. > > > Could somebody help me? Where/how can I get the right kernel version? > > > > I'll send you a tarball of those "old" patches off-list. > > > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MT9P031 camera
Dear Dr. Guennadi. I have similar set-up as Mr. Valentini - a Beagleboard XM + leopard imaging mt0p031 camera. Could you send me those patches too? Regards, Ivan > On Fri, 18 Feb 2011, Juliano Valentini wrote: > > > Dears, > > > > I'm trying to apply Guennadi's patch > > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/linux-2.6- omap3isp-bbxm-mt9p031.gitdiff) > > to official 2.6.37.1 Kernel version. > > No, this cannot work. That kernel patch requires media-controller and > omap3isp, so, it is based on the omap3isp branch of the development tree > by Laurent Pinchart: > > git://linuxtv.org/pinchartl/media.git > > But that tree has been rebased since then, so, I wouldn't expect that > patch to apply cleanly, porting it to the current kernel would require a > non-zero development effort. > > > I suppose that kernel version is wrong or missing previous patches > > (see result at the end). > > I have to make it work: MT9P031 SoC camera module on Beagleboard Xm. > > Could somebody help me? Where/how can I get the right kernel version? > > I'll send you a tarball of those "old" patches off-list. > > Thanks > Guennadi > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Fri, Feb 25, 2011 at 11:05:05AM +0100, Laurent Pinchart wrote: > Hi, Hi, > On Thursday 24 February 2011 18:57:22 Kim HeungJun wrote: > > Hi Guennadi, > > > > I think, it's maybe a good suggestion for current trend! ( I'm not sure > > this express *trend* is right :)) > > > > But, the flash or strobe control connected with sensor can be controlled by > > user application directly, not in the sensor subdev device. For example, > > let's think that there is a Flash light application. Its function is just > > power-up LED. So, in this case, if the flash control mechanism should be > > used *only* in the V4L2 API belonging through S/G_PARM, this mechanism > > might be a little complicated, nevertheless it's possible to control > > led/strobe using S/G_PARM. I mean that we must check the camera must be in > > the capture state or not, or another setting (like a FPS) should be > > checked. Namely, for powering up LED, the more procedure is needed. > > > > Also, we can think another case. Generally, the LED/STROBE/FLASH is > > connected with camera sensor directly, but another case can be existed > > that LED connected with Processor by controlling GPIO. So, In this case, > > using LED framework look more better I guess, and then user application > > access LED frame sysfs node eaisly. > > The flash is usually handled by a dedicated I2C flash controller (such as the > ADP1653 used in the N900 - http://www.analog.com/static/imported- > files/data_sheets/ADP1653.pdf), which is in that case mapped to a > v4l2_subdev. > Simpler solutions of course exist, such as GPIO LEDs or LEDs connected > directly to the sensor. We need an API that can support all those hardware > options. > > Let's also not forget that, in addition to the flash LEDs itself, devices > often feature an indicator LED (a small low-power red LED used to indicate > that video capture is ongoing). The flash LEDs can also be used during video > capture, and in focus assist mode (pre-flashing also comes to mind). > > In addition to the modes, flash controllers can generate strobe signals or > react on them. Durations are programmable, as well as current limits, and > sometimes PWM/current source mode selection. The device can usually detect > faults (such as over-current or over-temperature faults) that need to be > reported to the user. And we haven't even discussed Xenon flashes. > > Given the wide variety of parameters, I think it would make sense to use V4L2 > controls on the sub-device directly. If the flash LEDs are connected directly > to the sensor, controls on the sensor sub-device can be used to select the > flash parameters. > > This doesn't solve the flash/capture synchronization problem though. I don't > think we need a dedicated snapshot capture mode at the V4L2 level. A way to I agree with that. Flash synchronisation is just one of the many parameters that would benefit from frame level synchronisation. Exposure time, gain etc. are also such. The sensors provide varying level of hardware support for all these. Flash and indicator power setting can be included to the list of controls above. One more thing that suggests the flash control should be available as a separate subdev is to support the use of flash in torch mode without performing streaming at all. The power management of the camera is preferrably optimised for speed so that the camera related devices need not to be power cycled when using it. If the flash interface is available on a subdev separately the flash can also be easily powered separately without making this a special case --- the rest of the camera related devices (ISP, lens and sensor) should stay powered off. > configure the sensor to react on an external trigger provided by the flash > controller is needed, and that could be a control on the flash sub-device. > What we would probably miss is a way to issue a STREAMON with a number of > frames to capture. A new ioctl is probably needed there. Maybe that would be > an opportunity to create a new stream-control ioctl that could replace > STREAMON and STREAMOFF in the long term (we could extend the subdev s_stream > operation, and easily map STREAMON and STREAMOFF to the new ioctl in > video_ioctl2 internally). How would this be different from queueing n frames (in total; count dequeueing, too) and issuing streamon? --- Except that when the last frame is processed the pipeline could be stopped already before issuing STREAMOFF. That does indeed have some benefits. Something else? Regards, -- Sakari Ailus sakari dot ailus at iki dot fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi,
On Friday 25 February 2011 13:46:01 Kim, HeungJun wrote:
> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>
> Signed-off-by: Heungjun Kim
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/uvc/uvc_ctrl.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..b98b9f1 100644
> --- a/drivers/media/video/uvc/uvc_ctrl.c
> +++ b/drivers/media/video/uvc/uvc_ctrl.c
> @@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
> { { 8, "Aperture Priority Mode" },
> };
>
> +static struct uvc_menu_info focus_auto_controls[] = {
> + { 1, "Auto Mode" },
> + { 0, "Manual Mode" },
Now that manual focus has value 0 and auto focus value 1, the menu entries
need to be the other way around.
> +};
> +
> static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
> __u8 query, const __u8 *data)
> {
> @@ -560,8 +565,10 @@ static struct uvc_control_mapping uvc_ctrl_mappings[]
> = { .selector = UVC_CT_FOCUS_AUTO_CONTROL,
> .size = 1,
> .offset = 0,
> - .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
> + .v4l2_type = V4L2_CTRL_TYPE_MENU,
> .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
> + .menu_info = focus_auto_controls,
> + .menu_count = ARRAY_SIZE(focus_auto_controls),
> },
> {
> .id = V4L2_CID_IRIS_ABSOLUTE,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge Colossus Support
On Friday, February 25, 2011 12:53:20 Brandon Jenkins wrote: > Greetings all, > > My search of the list turned up nothing on planned support for the > Colossus in Linux. Hauppauge has begun shipping the card, and I have > one being shipped today which I am willing to loan to a developer if > it would help. > > Here's a few links on the components: > http://www.vixs.com/briefs/XCode_3111_v2.pdf > http://www.analog.com/en/analog-to-digital-converters/video-decoders/adv7441a/products/product.html An initial driver for the ADV7604 was posted recently. Cisco is working on this. The ADV7441 is quite similar in many respects to the ADV7604, so that should help. In fact, it might well be that the same driver can support both models, but without a careful comparison of the datasheets I cannot be certain. Regards, Hans > http://www.missingremote.com/sites/default/files/imagepicker/629/DSCN2261.jpg > http://hauppauge.com/site/products/data_colossus.html > > Thanks in advance! > > Brandon > -- > 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 Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
Document about the type changes and the enumeration of the auto focus control.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/v4l/controls.xml| 31 +---
Documentation/DocBook/v4l/videodev2.h.xml |6 +
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..889fa84 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1801,12 +1801,35 @@ negative values towards infinity. This is a write-only
control.
-
+
V4L2_CID_FOCUS_AUTO
- boolean
+ enum v4l2_focus_auto_type
Enables automatic focus
-adjustments. The effect of manual focus adjustments while this feature
-is enabled is undefined, drivers should ignore such requests.
+adjustments of the normal or macro or continuous(CAF) mode. The effect of
+manual focus adjustments while this feature is enabled is undefined,
+drivers should ignore such requests. Possible values are:
+
+
+
+
+
+ V4L2_FOCUS_MANUAL
+ Manual focus mode.
+
+
+ V4L2_FOCUS_AUTO
+ Auto focus mode with normal operation.
+
+
+ V4L2_FOCUS_MACRO
+ Auto focus mode with macro operation.
+
+
+
V4L2_FOCUS_CONTINUOUS
+ Auto focus mode with continuous(CAF) operation.
+
+
+
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..ccf6c2b 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1291,6 +1291,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_exposure_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/uvc/uvc_ctrl.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..b98b9f1 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 1, "Auto Mode" },
+ { 0, "Manual Mode" },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -560,8 +565,10 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
.size = 1,
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .menu_info = focus_auto_controls,
+ .menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH RESEND v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
from boolean to menu. And it includes 4 kinds of enumeration types:
V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 11 ++-
include/linux/videodev2.h|6 ++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..da4aa7a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto[] = {
+ "Manual Focus",
+ "Normal Auto Focus",
+ "Macro Auto Focus",
+ "Continuous Auto Focus",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO:
+ return camera_focus_auto;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
case V4L2_CID_MPEG_VIDEO_PULLDOWN:
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
- case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
@@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..959d59e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO(V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH RESEND v2 0/3] v4l2-ctrls: add new focus mode
Hello, Agenda == I faced to the absence of the mode of v4l2 focus for a couple of years. While dealing with some few morebile camera sensors, the focus modes are needed more than the current v4l2 focus mode, like a Macro & Continuous mode. The M-5MOLS camera sensor I dealt with, also support these 2 modes. So, I'm going to suggest supports of more detailed v4l2 focus mode. Version == This is second version patch about auto focus mode. The second version changes are below: 1. switch enumeration value between V4L2_FOCUS_AUTO and V4L2_FOCUS_MACRO, for maintaing previous auto focus mode value. 2. add documentations about the changes of auto focus mode. This RFC series of patch adds new auto focus modes, and documents it. The first patch the boolean type of V4L2_CID_FOCUS_AUTO to menu type, and insert menus 4 enumerations: V4L2_FOCUS_MANUAL, V4L2_FOCUS_AUTO, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS The recent mobile camera sensors with ISP supports Macro & Continuous Auto Focus aka CAF mode, of course normal AUTO mode, even Continuous mode. Changing the type of V4L2_CID_FOCUS_MODE, is able to define more exact focusing mode of camera sensor. The second patch let the uvc driver using V4L2_CID_FOCUS_AUTO by boolean type, be able to use the type of menu. The third patch documentation about changes of the auto focus mode. Thanks for reading this, and I hope any ideas and any comments. Regards, Heungjun Kim -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
2011-02-25 오후 7:25, Laurent Pinchart 쓴 글:
> Hi,
>
> On Friday 25 February 2011 11:18:43 Kim, HeungJun wrote:
>> 2011-02-25 오후 6:20, Laurent Pinchart 쓴 글:
>>> On Friday 25 February 2011 07:21:32 Kim, HeungJun wrote:
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..795fd3f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info
exposure_auto_controls[] = { { 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 2, "Auto Mode" },
+ { 1, "Manual Mode" },
>>>
>>> According to the UVC spec, this should be 0 for manual mode and 1 for
>>> auto mode.
>>
>> OK, I'll modify this values depends on below my question..
>>
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -558,10 +563,12 @@ static struct uvc_control_mapping
uvc_ctrl_mappings[] = { .name = "Focus, Auto",
.entity = UVC_GUID_UVC_CAMERA,
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
- .size = 1,
+ .size = 2,
>>>
>>> Why do you change the control size ?
>>>
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
- .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
+ .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
>>>
>>> The UVC control is still a boolean.
>>
>> You're saying that, the control size should be 1 because it's right to
>> maintain the boolean type, So, then, the uvc driver dosen't needed to be
>> changed. is it right?
>
> You still need to change v4l2_type from V4L2_CTRL_TYPE_BOOLEAN to
> V4L2_CTRL_TYPE_MENU, and add the menu entries. I don't see a need to change
> anything else.
>
Ah ok. I I confused a little. Thanks for the good catch.
Together focus name patch, I'll re-send patch.
Regards,
Heungjun Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
2011-02-25 오후 7:28, Laurent Pinchart 쓴 글:
> On Friday 25 February 2011 10:54:02 Hans Verkuil wrote:
>> On Friday, February 25, 2011 10:21:59 Laurent Pinchart wrote:
>>> On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
Support more modes of autofocus, it changes the type of
V4L2_CID_FOCUS_AUTO from boolean to menu. And it includes 4 kinds of
enumeration types:
V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO,
V4L2_FOCUS_CONTINUOUS
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 11 ++-
include/linux/videodev2.h|6 ++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto[] = {
+ "Manual Mode",
+ "Auto Mode",
+ "Macro Mode",
+ "Continuous Mode",
>>>
>>> This might be nit-picking, but maybe the menu entries should be named
>>> "Manual Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus".
>>> Hans ?
>>
>> Yes, that's better. Although I believe that it should be 'Macro Auto
>> Focus', right?
>
> I suppose so. Heungjun could confirm that.
>
>> But if we change this for 'focus' then we need to do the same for the auto
>> exposure menu which currently also uses the term 'Mode'.
>>
>> Do you agree?
>
> Auto Mode and Manual Mode could be renamed to Auto Exposure and Manual
> Exposure, but Shutter Priority Exposure and Aperture Priority Exposure don't
> sound right.
>
I guess the reason why "Shutter Priority Exposure" dosen't always imply auto
iris
exposure, but the current name "Shutter Prority Mode" can be imagined including
auto iris. The contrary case seems the same.
Although tt's the different story, the exposure be made up 3 factor
(shutter speed/aperture/iso), but there is not the enum name matching iso
factor now.
So, it looks better that the name should be changed all later.
But, it looks good for me the focus name is below:
"Manual Focus"
"Normal Auto Focus"
"Macro Auto Focus"
"Continuous Auto Focus"
If any ideas, I'll re-send the patch series.
Regards,
Heungjun Kim
--
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
Hauppauge Colossus Support
Greetings all, My search of the list turned up nothing on planned support for the Colossus in Linux. Hauppauge has begun shipping the card, and I have one being shipped today which I am willing to loan to a developer if it would help. Here's a few links on the components: http://www.vixs.com/briefs/XCode_3111_v2.pdf http://www.analog.com/en/analog-to-digital-converters/video-decoders/adv7441a/products/product.html http://www.missingremote.com/sites/default/files/imagepicker/629/DSCN2261.jpg http://hauppauge.com/site/products/data_colossus.html Thanks in advance! Brandon -- 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: Sony CXD2099AR decryption failing
Follow up on the trouble with Digital Devices DuoFlex S2, CI, SMIT Viaccess CAM and Bis.tv card. The whole combination works under Windows 7 with Media Center. I have been able to watch and change channels I'm entitled to in the Bis.TV package. Only condition was to disable CI for tuner no 2. If the CI is activated for tuner 1 and tuner 2, Media Center will not be able to change the channels. Anything I can do to make progress for this issue under linux ? Thx -- Issa -- 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: Hello, how to control FrameBuffer device as v4l2 sub-device?
Hi,
There are two solutions. But it never looks nice.
Does anyone have no idea ?
1. Save the struct s3c_fb in the v4l2_subdev.priv like:
In the s3cfb_probe:
v4l2_set_subdevdata(&sfb->sd, sfb);
platform_set_drvdata(pdev, &sfb->sd);
In the s3cfb_remove:
struct v4l2_subdev *sd = platform_get_drvdata(pdev);
struct s3c_fb *sfb = sd->priv;
In the s5p-fimc driver:
sd = dev_get_drvdata(dev);
-> This bothers s3cfb due to s5p-fimc driver.
2. let sd locate top of the struct s3c_fb like:
struct s3c_fb {
struct v4l2_subdev sd;
struct device *dev;
-> and then don't save the sfb->sd in the platform driver data.
It makes s3cfb driver use the platform driver data for its own purpose.
But you can get the v4l2_subdev pointer in s5p-fimc driver using
dev_get_drvdata.
The reason how to get the pointer is that the address of v4l2_subdev is same
with s3cfb's platform driver data.
BRs,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sungchun Kang
> Sent: Wednesday, February 23, 2011 8:17 PM
> To: linux-media@vger.kernel.org
> Subject: Hello, how to control FrameBuffer device as v4l2 sub-device?
>
> FIMC is hardware function like csc, post, rotatin and so on.
> It is necessary to send some data to FB from FIMC.
>
> So, I have registered FB driver as v4l2 sub-device of FIMC.
>
> | v4l2_device |
>
> | fimc-0 |
> |||
> |
> | |
>
> | v4l2_subdev | | v4l2_subdeve |
>
> | FB1| | mipi-csi, |
> | FB2| | senor |
>
> And, it is controlled using platform_get_drvdata and platform_set_drvdata
> between FIMC and FB drvier.
> But, FB driver uses drvdata for its own purpose. If I set v4l2_subdev ptr
> like this :
> platform_set_drvdata(pdev, &sfb->sd); // v4l2_subdev sd;
>
> platform_device ptr is changed.
>
> Because FB driver aleady set like this :
> platform_set_drvdata(pdev, sfb);
>
> So, I wonder how to control data between 2 hardware.
>
> If you have some idea, pls reply.
>
> BRs,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in the
> body
> of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
On Friday 25 February 2011 10:54:02 Hans Verkuil wrote:
> On Friday, February 25, 2011 10:21:59 Laurent Pinchart wrote:
> > On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
> > > Support more modes of autofocus, it changes the type of
> > > V4L2_CID_FOCUS_AUTO from boolean to menu. And it includes 4 kinds of
> > > enumeration types:
> > >
> > > V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO,
> > > V4L2_FOCUS_CONTINUOUS
> > >
> > > Signed-off-by: Heungjun Kim
> > > Signed-off-by: Kyungmin Park
> > > ---
> > >
> > > drivers/media/video/v4l2-ctrls.c | 11 ++-
> > > include/linux/videodev2.h|6 ++
> > > 2 files changed, 16 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/media/video/v4l2-ctrls.c
> > > b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
> > > --- a/drivers/media/video/v4l2-ctrls.c
> > > +++ b/drivers/media/video/v4l2-ctrls.c
> > > @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > >
> > > "Aperture Priority Mode",
> > > NULL
> > >
> > > };
> > >
> > > + static const char * const camera_focus_auto[] = {
> > > + "Manual Mode",
> > > + "Auto Mode",
> > > + "Macro Mode",
> > > + "Continuous Mode",
> >
> > This might be nit-picking, but maybe the menu entries should be named
> > "Manual Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus".
> > Hans ?
>
> Yes, that's better. Although I believe that it should be 'Macro Auto
> Focus', right?
I suppose so. Heungjun could confirm that.
> But if we change this for 'focus' then we need to do the same for the auto
> exposure menu which currently also uses the term 'Mode'.
>
> Do you agree?
Auto Mode and Manual Mode could be renamed to Auto Exposure and Manual
Exposure, but Shutter Priority Exposure and Aperture Priority Exposure don't
sound right.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Hans, and Laurent,
2011-02-25 오후 6:54, Hans Verkuil 쓴 글:
> On Friday, February 25, 2011 10:21:59 Laurent Pinchart wrote:
>> On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
>>> Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
>>> from boolean to menu. And it includes 4 kinds of enumeration types:
>>>
>>> V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
>>>
>>> Signed-off-by: Heungjun Kim
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/media/video/v4l2-ctrls.c | 11 ++-
>>> include/linux/videodev2.h|6 ++
>>> 2 files changed, 16 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/media/video/v4l2-ctrls.c
>>> b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
>>> --- a/drivers/media/video/v4l2-ctrls.c
>>> +++ b/drivers/media/video/v4l2-ctrls.c
>>> @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>> "Aperture Priority Mode",
>>> NULL
>>> };
>>> + static const char * const camera_focus_auto[] = {
>>> + "Manual Mode",
>>> + "Auto Mode",
>>> + "Macro Mode",
>>> + "Continuous Mode",
>>
>> This might be nit-picking, but maybe the menu entries should be named
>> "Manual
>> Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus". Hans ?
>
> Yes, that's better. Although I believe that it should be 'Macro Auto Focus',
> right?
>
> But if we change this for 'focus' then we need to do the same for the auto
> exposure menu which currently also uses the term 'Mode'.
>
> Do you agree?
Although listenning Laurent's opinion first, if my opinion is asked, I agree
using term 'Focus', and agree using term 'Exposure' (is it right??) at the
exposure auto control, too.
If the name is decided, and came to the conclusion, I would modify to maintain
the term 'Focus' in the focus control name.
Regards,
Heungjun Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi,
On Friday 25 February 2011 11:18:43 Kim, HeungJun wrote:
> 2011-02-25 오후 6:20, Laurent Pinchart 쓴 글:
> > On Friday 25 February 2011 07:21:32 Kim, HeungJun wrote:
> >> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
> >> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
> >>
> >> Signed-off-by: Heungjun Kim
> >> Signed-off-by: Kyungmin Park
> >> ---
> >>
> >> drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
> >> 1 files changed, 10 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
> >> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..795fd3f 100644
> >> --- a/drivers/media/video/uvc/uvc_ctrl.c
> >> +++ b/drivers/media/video/uvc/uvc_ctrl.c
> >> @@ -333,6 +333,11 @@ static struct uvc_menu_info
> >> exposure_auto_controls[] = { { 8, "Aperture Priority Mode" },
> >>
> >> };
> >>
> >> +static struct uvc_menu_info focus_auto_controls[] = {
> >> + { 2, "Auto Mode" },
> >> + { 1, "Manual Mode" },
> >
> > According to the UVC spec, this should be 0 for manual mode and 1 for
> > auto mode.
>
> OK, I'll modify this values depends on below my question..
>
> >> +};
> >> +
> >>
> >> static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
> >>
> >>__u8 query, const __u8 *data)
> >>
> >> {
> >>
> >> @@ -558,10 +563,12 @@ static struct uvc_control_mapping
> >> uvc_ctrl_mappings[] = { .name = "Focus, Auto",
> >>
> >>.entity = UVC_GUID_UVC_CAMERA,
> >>.selector = UVC_CT_FOCUS_AUTO_CONTROL,
> >>
> >> - .size = 1,
> >> + .size = 2,
> >
> > Why do you change the control size ?
> >
> >>.offset = 0,
> >>
> >> - .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
> >> - .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
> >> + .v4l2_type = V4L2_CTRL_TYPE_MENU,
> >> + .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
> >
> > The UVC control is still a boolean.
>
> You're saying that, the control size should be 1 because it's right to
> maintain the boolean type, So, then, the uvc driver dosen't needed to be
> changed. is it right?
You still need to change v4l2_type from V4L2_CTRL_TYPE_BOOLEAN to
V4L2_CTRL_TYPE_MENU, and add the menu entries. I don't see a need to change
anything else.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi Laurent,
2011-02-25 오후 6:20, Laurent Pinchart 쓴 글:
> On Friday 25 February 2011 07:21:32 Kim, HeungJun wrote:
>> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
>> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>>
>> Signed-off-by: Heungjun Kim
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
>> 1 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
>> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..795fd3f 100644
>> --- a/drivers/media/video/uvc/uvc_ctrl.c
>> +++ b/drivers/media/video/uvc/uvc_ctrl.c
>> @@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
>> { { 8, "Aperture Priority Mode" },
>> };
>>
>> +static struct uvc_menu_info focus_auto_controls[] = {
>> +{ 2, "Auto Mode" },
>> +{ 1, "Manual Mode" },
>
> According to the UVC spec, this should be 0 for manual mode and 1 for auto
> mode.
OK, I'll modify this values depends on below my question..
>
>> +};
>> +
>> static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
>> __u8 query, const __u8 *data)
>> {
>> @@ -558,10 +563,12 @@ static struct uvc_control_mapping uvc_ctrl_mappings[]
>> = { .name= "Focus, Auto",
>> .entity = UVC_GUID_UVC_CAMERA,
>> .selector = UVC_CT_FOCUS_AUTO_CONTROL,
>> -.size = 1,
>> +.size = 2,
>
> Why do you change the control size ?
>
>> .offset = 0,
>> -.v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
>> -.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
>> +.v4l2_type = V4L2_CTRL_TYPE_MENU,
>> +.data_type = UVC_CTRL_DATA_TYPE_BITMASK,
>
> The UVC control is still a boolean.
You're saying that, the control size should be 1 because it's right to maintain
the boolean type,
So, then, the uvc driver dosen't needed to be changed. is it right?
Thanks for the reviews, and I'll wait answer.
Regards,
Heungjun KIm
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
Hi, On Thursday 24 February 2011 18:57:22 Kim HeungJun wrote: > Hi Guennadi, > > I think, it's maybe a good suggestion for current trend! ( I'm not sure > this express *trend* is right :)) > > But, the flash or strobe control connected with sensor can be controlled by > user application directly, not in the sensor subdev device. For example, > let's think that there is a Flash light application. Its function is just > power-up LED. So, in this case, if the flash control mechanism should be > used *only* in the V4L2 API belonging through S/G_PARM, this mechanism > might be a little complicated, nevertheless it's possible to control > led/strobe using S/G_PARM. I mean that we must check the camera must be in > the capture state or not, or another setting (like a FPS) should be > checked. Namely, for powering up LED, the more procedure is needed. > > Also, we can think another case. Generally, the LED/STROBE/FLASH is > connected with camera sensor directly, but another case can be existed > that LED connected with Processor by controlling GPIO. So, In this case, > using LED framework look more better I guess, and then user application > access LED frame sysfs node eaisly. The flash is usually handled by a dedicated I2C flash controller (such as the ADP1653 used in the N900 - http://www.analog.com/static/imported- files/data_sheets/ADP1653.pdf), which is in that case mapped to a v4l2_subdev. Simpler solutions of course exist, such as GPIO LEDs or LEDs connected directly to the sensor. We need an API that can support all those hardware options. Let's also not forget that, in addition to the flash LEDs itself, devices often feature an indicator LED (a small low-power red LED used to indicate that video capture is ongoing). The flash LEDs can also be used during video capture, and in focus assist mode (pre-flashing also comes to mind). In addition to the modes, flash controllers can generate strobe signals or react on them. Durations are programmable, as well as current limits, and sometimes PWM/current source mode selection. The device can usually detect faults (such as over-current or over-temperature faults) that need to be reported to the user. And we haven't even discussed Xenon flashes. Given the wide variety of parameters, I think it would make sense to use V4L2 controls on the sub-device directly. If the flash LEDs are connected directly to the sensor, controls on the sensor sub-device can be used to select the flash parameters. This doesn't solve the flash/capture synchronization problem though. I don't think we need a dedicated snapshot capture mode at the V4L2 level. A way to configure the sensor to react on an external trigger provided by the flash controller is needed, and that could be a control on the flash sub-device. What we would probably miss is a way to issue a STREAMON with a number of frames to capture. A new ioctl is probably needed there. Maybe that would be an opportunity to create a new stream-control ioctl that could replace STREAMON and STREAMOFF in the long term (we could extend the subdev s_stream operation, and easily map STREAMON and STREAMOFF to the new ioctl in video_ioctl2 internally). > So, IMHO, probably it's the better option for now to make another CID like > V4L2_CID_STROBE clearly, then in the case connected directly with sensor, > we control using I2C or another command method for sensor in the > V4L2_CID_STROBE, OR in the case connected directly with process, we also > using V4L2_CID_STROBE, but the led framework code is in the CID control > functions. > > Actually, because I also think deeply same issue for a long time, so I > wanna very talk about this issues. > > How about dealing with this? > > Regards, > Heungjun Kim > > 2011. 2. 25., 오전 1:07, Guennadi Liakhovetski wrote: > > Hi Hans > > > > Thanks for the review. Perhaps, I should have mentioned it in the > > original post, I've written down this RFC to have a basis for a > > discussion. The specific API proposals in it are nothing solid, of > > course, so, we can freely discuss it here now, or, maybe we get a chance > > to discuss it together with the earlier one, concerning multiple queues, > > if and when we meet personally next time;) Concerning your specific > > comments: > > > > On Thu, 24 Feb 2011, Hans Verkuil wrote: > >> On Thursday, February 24, 2011 13:18:39 Guennadi Liakhovetski wrote: > >>> Agenda. > >>> === > >>> > >>> In a recent RFC [1] I proposed V4L2 API extensions to support fast > >>> switching between multiple capture modes or data formats. However, > >>> this is not sufficient to efficiently leverage snapshot capabilities > >>> of existing hardware - sensors and SoCs, and to satisfy user-space > >>> needs, a few more functions have to be implemented. > >>> > >>> Snapshot and strobe / flash capabilities vary significantly between > >>> sensors. Some of them only capture a single image upon trigger > >>> activation, some can capture several images, re
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
On Friday, February 25, 2011 10:21:59 Laurent Pinchart wrote:
> On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
> > Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
> > from boolean to menu. And it includes 4 kinds of enumeration types:
> >
> > V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
> >
> > Signed-off-by: Heungjun Kim
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/media/video/v4l2-ctrls.c | 11 ++-
> > include/linux/videodev2.h|6 ++
> > 2 files changed, 16 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-ctrls.c
> > b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
> > --- a/drivers/media/video/v4l2-ctrls.c
> > +++ b/drivers/media/video/v4l2-ctrls.c
> > @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > "Aperture Priority Mode",
> > NULL
> > };
> > + static const char * const camera_focus_auto[] = {
> > + "Manual Mode",
> > + "Auto Mode",
> > + "Macro Mode",
> > + "Continuous Mode",
>
> This might be nit-picking, but maybe the menu entries should be named "Manual
> Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus". Hans ?
Yes, that's better. Although I believe that it should be 'Macro Auto Focus',
right?
But if we change this for 'focus' then we need to do the same for the auto
exposure menu which currently also uses the term 'Mode'.
Do you agree?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
> Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
> from boolean to menu. And it includes 4 kinds of enumeration types:
>
> V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
>
> Signed-off-by: Heungjun Kim
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/v4l2-ctrls.c | 11 ++-
> include/linux/videodev2.h|6 ++
> 2 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> "Aperture Priority Mode",
> NULL
> };
> + static const char * const camera_focus_auto[] = {
> + "Manual Mode",
> + "Auto Mode",
> + "Macro Mode",
> + "Continuous Mode",
This might be nit-picking, but maybe the menu entries should be named "Manual
Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus". Hans ?
> + NULL
> + };
> static const char * const colorfx[] = {
> "None",
> "Black & White",
> @@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> return camera_power_line_frequency;
> case V4L2_CID_EXPOSURE_AUTO:
> return camera_exposure_auto;
> + case V4L2_CID_FOCUS_AUTO:
> + return camera_focus_auto;
> case V4L2_CID_COLORFX:
> return colorfx;
> case V4L2_CID_TUNE_PREEMPHASIS:
> @@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type, case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
> case V4L2_CID_MPEG_VIDEO_PULLDOWN:
> case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
> - case V4L2_CID_FOCUS_AUTO:
> case V4L2_CID_PRIVACY:
> case V4L2_CID_AUDIO_LIMITER_ENABLED:
> case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
> @@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type, case V4L2_CID_MPEG_STREAM_TYPE:
> case V4L2_CID_MPEG_STREAM_VBI_FMT:
> case V4L2_CID_EXPOSURE_AUTO:
> + case V4L2_CID_FOCUS_AUTO:
> case V4L2_CID_COLORFX:
> case V4L2_CID_TUNE_PREEMPHASIS:
> *type = V4L2_CTRL_TYPE_MENU;
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index a94c4d5..959d59e 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
> #define V4L2_CID_FOCUS_ABSOLUTE
> (V4L2_CID_CAMERA_CLASS_BASE+10)
> #define V4L2_CID_FOCUS_RELATIVE
> (V4L2_CID_CAMERA_CLASS_BASE+11)
> #define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
> +enum v4l2_focus_auto_type {
> + V4L2_FOCUS_MANUAL = 0,
> + V4L2_FOCUS_AUTO = 1,
> + V4L2_FOCUS_MACRO = 2,
> + V4L2_FOCUS_CONTINUOUS = 3
> +};
>
> #define V4L2_CID_ZOOM_ABSOLUTE
> (V4L2_CID_CAMERA_CLASS_BASE+13)
> #define V4L2_CID_ZOOM_RELATIVE
> (V4L2_CID_CAMERA_CLASS_BASE+14)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
On Friday 25 February 2011 07:21:32 Kim, HeungJun wrote:
> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>
> Signed-off-by: Heungjun Kim
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..795fd3f 100644
> --- a/drivers/media/video/uvc/uvc_ctrl.c
> +++ b/drivers/media/video/uvc/uvc_ctrl.c
> @@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
> { { 8, "Aperture Priority Mode" },
> };
>
> +static struct uvc_menu_info focus_auto_controls[] = {
> + { 2, "Auto Mode" },
> + { 1, "Manual Mode" },
According to the UVC spec, this should be 0 for manual mode and 1 for auto
mode.
> +};
> +
> static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
> __u8 query, const __u8 *data)
> {
> @@ -558,10 +563,12 @@ static struct uvc_control_mapping uvc_ctrl_mappings[]
> = { .name = "Focus, Auto",
> .entity = UVC_GUID_UVC_CAMERA,
> .selector = UVC_CT_FOCUS_AUTO_CONTROL,
> - .size = 1,
> + .size = 2,
Why do you change the control size ?
> .offset = 0,
> - .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
> - .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
> + .v4l2_type = V4L2_CTRL_TYPE_MENU,
> + .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
The UVC control is still a boolean.
> + .menu_info = focus_auto_controls,
> + .menu_count = ARRAY_SIZE(focus_auto_controls),
> },
> {
> .id = V4L2_CID_IRIS_ABSOLUTE,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/5] [media] s5p-tvout: Add S5P TVOUT driver
This patch-set adds support for TV-OUT interface in the EXYNOS4 series of SoCs. TVOUT includes the HDMI interface, analog TV interface, mixer and video processor. This is a full-featured driver providing the following: 1) HDMI Support 2) Analog Support 3) Mixer Support 4) Video Processor Support 5) Hotplug Detect Support 6) HDCP Support 7) CEC Support 8) I2S/SPDIF Support The driver is under development and needs major modifications, as mentioned later in the TODO section, to conform to open source standards. Please have a look at the driver design and offer any suggestions/comments. I) HARDWARE Video processor is responsible for video scaling, de-interlacing, and video post processing of TVOUT data path. It reads reconstructed YCbCr video sequences from DRAM, processes the sequence, and sends it to mixer on-the-fly. Input to VP is NV12 and NV21 (Linear and tiled) format while the output to the mixer is YUV444. Mixer overlaps or blends input data such as graphic, video, background and sends the resulting data to the HDMI or analog TV interface. Along with the YUV444 in- put from VP interface, the mixer can receive two RGB inputs. It allows for layer blending, alpha blending, chroma key, scaling etc. HDMI interface supports 1.3 Tx subsystem V1.0 comprising an HDMI Tx core with I2S input interface, CEC block, and HDCP key block. It receives YUV444 or RGB888 data from the mixer and converts it into HDMI packets. Supports a variety of video formats varying from 480p to 1080p. Analog TV interface supports ITU-R BT 470 and EIA-770 compliant analog TV signals with 1 channel 10bit DAC. Supports PAL-m@60Hz, PAL-60@60Hz, NTSC@60Hz, NTSC-443@60Hz, PAL@50Hz, PAL-n@50Hz and (M)NTSC@60Hz formats for composite output. II) S/W DESIGN === --- VFS --- KERNEL | | V V -- -- V4L2 STACK FB STACKLinux Driver Model -- -- | || =+===++ | || | | +-| | | | | V V V | +---+---+ | | | | | | | - --- | | | Video Ctrl -- Graphics Ctrl -- TVOUT I/F| | | - --- V | | | | ||__ --- | | | | | | HPD Driver | | V V V V(GPIO)| | --- --- --- --- --- | | VP I/F Mixer I/F Analog I/FHDMI I/F | | --- --- --- --- | | | | | | | | DEVICE| | | | | |___ | DRIVER| | | | | | | | | | | | | V V | | | | | | - --| | | | | | CECHDCP | | | | | | - --| | | | | |___|___| | | | | || +--+---+---++ | | | | | | | | =+===+===+= | | | | V V V | --- --- ---| VP > Mixer ---
[PATCH 4/5] [media] s5p-tvout: Add CEC driver for S5P TVOUT
From: KyungHwan Kim
This patch adds support CEC(Consumer Electronic Control) driver
for S5P TVOUT driver.
It allows source device to command and control CEC-enabled sink
devices in case of HDMI. For example, it can send signals like
turning on/off from source device to digital TV.
[based on work originally written by Sangpil Moon ]
Cc: Kukjin Kim
Signed-off-by: Jiun Yu
Signed-off-by: KyungHwan Kim
Signed-off-by: Abhilash Kesavan
---
drivers/media/video/s5p-tvout/hw_if/cec.c | 239
drivers/media/video/s5p-tvout/hw_if/hdcp.c|2 +-
drivers/media/video/s5p-tvout/s5p_tvout_cec.c | 362 +
3 files changed, 602 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/s5p-tvout/hw_if/cec.c
create mode 100644 drivers/media/video/s5p-tvout/s5p_tvout_cec.c
diff --git a/drivers/media/video/s5p-tvout/hw_if/cec.c
b/drivers/media/video/s5p-tvout/hw_if/cec.c
new file mode 100644
index 000..dbff584
--- /dev/null
+++ b/drivers/media/video/s5p-tvout/hw_if/cec.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * CEC for Samsung S5P TVOUT driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include "../s5p_tvout_common_lib.h"
+#include "hw_if.h"
+
+#define S5P_HDMI_FIN 2400
+#define CEC_DIV_RATIO 32
+
+#define CEC_MESSAGE_BROADCAST_MASK 0x0F
+#define CEC_MESSAGE_BROADCAST 0x0F
+#define CEC_FILTER_THRESHOLD 0x15
+
+static struct resource *cec_mem;
+void __iomem *cec_base;
+
+struct cec_rx_struct cec_rx_struct;
+struct cec_tx_struct cec_tx_struct;
+
+void s5p_cec_set_divider(void)
+{
+ u32 div_ratio, reg, div_val;
+
+ div_ratio = (S5P_HDMI_FIN / CEC_DIV_RATIO) - 1;
+
+ reg = readl(S5P_HDMI_PHY_CONTROL);
+ reg = (reg & ~(0x3FF << 16)) | (div_ratio << 16);
+
+ writel(reg, S5P_HDMI_PHY_CONTROL);
+
+ div_val = (CEC_DIV_RATIO * 0.5) - 1;
+
+ writeb(0x0, cec_base + S5P_CEC_DIVISOR_3);
+ writeb(0x0, cec_base + S5P_CEC_DIVISOR_2);
+ writeb(0x0, cec_base + S5P_CEC_DIVISOR_1);
+ writeb(div_val, cec_base + S5P_CEC_DIVISOR_0);
+}
+
+void s5p_cec_enable_rx(void)
+{
+ u8 reg;
+
+ reg = readb(cec_base + S5P_CEC_RX_CTRL);
+ reg |= S5P_CEC_RX_CTRL_ENABLE;
+ writeb(reg, cec_base + S5P_CEC_RX_CTRL);
+}
+
+void s5p_cec_mask_rx_interrupts(void)
+{
+ u8 reg;
+
+ reg = readb(cec_base + S5P_CEC_IRQ_MASK);
+ reg |= S5P_CEC_IRQ_RX_DONE;
+ reg |= S5P_CEC_IRQ_RX_ERROR;
+ writeb(reg, cec_base + S5P_CEC_IRQ_MASK);
+}
+
+void s5p_cec_unmask_rx_interrupts(void)
+{
+ u8 reg;
+
+ reg = readb(cec_base + S5P_CEC_IRQ_MASK);
+ reg &= ~S5P_CEC_IRQ_RX_DONE;
+ reg &= ~S5P_CEC_IRQ_RX_ERROR;
+ writeb(reg, cec_base + S5P_CEC_IRQ_MASK);
+}
+
+void s5p_cec_mask_tx_interrupts(void)
+{
+ u8 reg;
+
+ reg = readb(cec_base + S5P_CEC_IRQ_MASK);
+ reg |= S5P_CEC_IRQ_TX_DONE;
+ reg |= S5P_CEC_IRQ_TX_ERROR;
+ writeb(reg, cec_base + S5P_CEC_IRQ_MASK);
+}
+
+void s5p_cec_unmask_tx_interrupts(void)
+{
+ u8 reg;
+
+ reg = readb(cec_base + S5P_CEC_IRQ_MASK);
+ reg &= ~S5P_CEC_IRQ_TX_DONE;
+ reg &= ~S5P_CEC_IRQ_TX_ERROR;
+ writeb(reg, cec_base + S5P_CEC_IRQ_MASK);
+}
+
+void s5p_cec_tx_reset(void)
+{
+ writeb(S5P_CEC_TX_CTRL_RESET, cec_base + S5P_CEC_TX_CTRL);
+}
+
+void s5p_cec_rx_reset(void)
+{
+ writeb(S5P_CEC_RX_CTRL_RESET, cec_base + S5P_CEC_RX_CTRL);
+}
+
+void s5p_cec_reset(void)
+{
+ s5p_cec_rx_reset();
+ s5p_cec_tx_reset();
+}
+
+void s5p_cec_threshold(void)
+{
+ writeb(CEC_FILTER_THRESHOLD, cec_base + S5P_CEC_RX_FILTER_TH);
+ writeb(0, cec_base + S5P_CEC_RX_FILTER_CTRL);
+}
+
+void s5p_cec_set_tx_state(enum cec_state state)
+{
+ atomic_set(&cec_tx_struct.state, state);
+}
+
+void s5p_cec_set_rx_state(enum cec_state state)
+{
+ atomic_set(&cec_rx_struct.state, state);
+}
+
+void s5p_cec_copy_packet(char *data, size_t count)
+{
+ int i = 0;
+ u8 reg;
+
+ while (i < count) {
+ writeb(data[i], cec_base + (S5P_CEC_TX_BUFF0 + (i * 4)));
+ i++;
+ }
+
+ writeb(count, cec_base + S5P_CEC_TX_BYTES);
+ s5p_cec_set_tx_state(STATE_TX);
+ reg = readb(cec_base + S5P_CEC_TX_CTRL);
+ reg |= S5P_CEC_TX_CTRL_START;
+
+ if ((data[0] & CEC_MESSAGE_BROADCAST_MASK) == CEC_MESSAGE_BROADCAST)
+ reg |= S5P_CEC_TX_CTRL_BCAST;
+ else
+ reg &= ~S5P_CEC_TX_CTRL_BCAST;
+
+ reg |= 0x50;
+ writeb(reg, cec_base + S5P_CEC_TX_CTRL);
+}
+
+void s5p_cec_set_addr(u32 addr)
+{
+ writeb(addr & 0x0F,
[PATCH 5/5] [media] s5p-tvout: Add HPD driver for S5P TVOUT
This patch adds support HPD(Hot-Plug Detection) driver for
S5P TVOUT driver.
HPD driver generates event and send it to application when
user connects/disconnects HDMI cable to/from source and sink
device.
[based on work originally written by Sangpil Moon ]
Cc: Kukjin Kim
Acked-by: KyungHwan Kim
Signed-off-by: Jiun Yu
Signed-off-by: Abhilash Kesavan
---
drivers/media/video/s5p-tvout/s5p_tvout_hpd.c | 405 +
1 files changed, 405 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/s5p-tvout/s5p_tvout_hpd.c
diff --git a/drivers/media/video/s5p-tvout/s5p_tvout_hpd.c
b/drivers/media/video/s5p-tvout/s5p_tvout_hpd.c
new file mode 100644
index 000..f307286
--- /dev/null
+++ b/drivers/media/video/s5p-tvout/s5p_tvout_hpd.c
@@ -0,0 +1,405 @@
+/*
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * HPD(Hot-Plug Detection) Interface for Samsung S5P TVOUT driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "hw_if/hw_if.h"
+#include "s5p_tvout_common_lib.h"
+
+#undef tvout_dbg
+
+#ifdef CONFIG_HPD_DEBUG
+#define tvout_dbg(fmt, ...)\
+ printk(KERN_INFO "\t[HPD] %s(): " fmt, \
+ __func__, ##__VA_ARGS__)
+#else
+#define tvout_dbg(fmt, ...)
+#endif
+
+/* /dev/hpd (Major 10, Minor 243) */
+#define HPD_MINOR 243
+
+#define HPD_LO 0
+#define HPD_HI 1
+
+#define HDMI_ON1
+#define HDMI_OFF 0
+
+struct hpd_struct {
+ spinlock_t lock;
+ wait_queue_head_t waitq;
+ atomic_t state;
+ void (*int_src_hdmi_hpd)(void);
+ void (*int_src_ext_hpd)(void);
+ int (*read_gpio)(void);
+ int irq_n;
+};
+
+static struct hpd_struct hpd_struct;
+
+static int last_hpd_state;
+atomic_t hdmi_status;
+atomic_t poll_state;
+
+static struct kobject *hpd_tvout_kobj, *hpd_video_kobj;
+
+static void s5p_hpd_kobject_uevent(void)
+{
+ int hpd_state = atomic_read(&hpd_struct.state);
+
+ if (hpd_state) {
+ tvout_err("Event] Send UEvent = %d\n", hpd_state);
+ kobject_uevent(hpd_tvout_kobj, KOBJ_ONLINE);
+ kobject_uevent(hpd_video_kobj, KOBJ_ONLINE);
+ } else {
+ tvout_err("Event] Send UEvent = %d\n", hpd_state);
+ kobject_uevent(hpd_tvout_kobj, KOBJ_OFFLINE);
+ kobject_uevent(hpd_video_kobj, KOBJ_OFFLINE);
+ }
+}
+
+static DECLARE_WORK(hpd_work, (void *)s5p_hpd_kobject_uevent);
+
+void s5p_hpd_set_kobj(struct kobject *tvout_kobj, struct kobject *video_kobj)
+{
+ hpd_tvout_kobj = tvout_kobj;
+ hpd_video_kobj = video_kobj;
+}
+
+static int s5p_hpd_open(struct inode *inode, struct file *file)
+{
+ atomic_set(&poll_state, 1);
+
+ return 0;
+}
+
+static int s5p_hpd_release(struct inode *inode, struct file *file)
+{
+ return 0;
+}
+
+static ssize_t s5p_hpd_read(struct file *file, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ ssize_t retval;
+
+ spin_lock_irq(&hpd_struct.lock);
+
+ retval = put_user(atomic_read(&hpd_struct.state),
+ (unsigned int __user *) buffer);
+
+ atomic_set(&poll_state, -1);
+
+ spin_unlock_irq(&hpd_struct.lock);
+
+ return retval;
+}
+
+static unsigned int s5p_hpd_poll(struct file *file, poll_table *wait)
+{
+ poll_wait(file, &hpd_struct.waitq, wait);
+
+ if (atomic_read(&poll_state) != -1)
+ return POLLIN | POLLRDNORM;
+
+ return 0;
+}
+
+static const struct file_operations hpd_fops = {
+ .owner = THIS_MODULE,
+ .open = s5p_hpd_open,
+ .release= s5p_hpd_release,
+ .read = s5p_hpd_read,
+ .poll = s5p_hpd_poll,
+};
+
+static struct miscdevice hpd_misc_device = {
+ .minor = HPD_MINOR,
+ .name = "HPD",
+ .fops = &hpd_fops,
+};
+
+int s5p_hpd_set_hdmiint(void)
+{
+ /* EINT -> HDMI */
+
+ set_irq_type(hpd_struct.irq_n, IRQ_TYPE_NONE);
+
+ if (last_hpd_state)
+ s5p_hdmi_reg_intc_enable(HDMI_IRQ_HPD_UNPLUG, 0);
+ else
+ s5p_hdmi_reg_intc_enable(HDMI_IRQ_HPD_PLUG, 0);
+
+ atomic_set(&hdmi_status, HDMI_ON);
+
+ hpd_struct.int_src_hdmi_hpd();
+
+ s5p_hdmi_reg_hpd_gen();
+
+ if (s5p_hdmi_reg_get_hpd_status())
+ s5p_hdmi_reg_intc_enable(HDMI_IRQ_HPD_UNPLUG, 1);
+ else
+ s5p_hdmi_reg_intc_enable(HDMI_IRQ_HPD_PLUG, 1);
+
+ return 0;
+}
+
+int s5p_hpd_set_eint(void)
+{
+ /* HDMI -> EINT */
+
+ atomic_set(&hdmi_status, HDMI_OFF);
+
+ s5p_hdmi_reg_intc_clear_pending(HDMI_IRQ_HPD_PLUG);
+
