[GIT PULL for v3.5-rc7] media fixes
Hi Linus, Plese pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for the fixes for the media subsystem, including: - Some regression fixes at the audio part for devices with cx23885/cx25840; - A DMA corruption fix at cx231xx; - two fixes at the winbond IR driver; - Several fixes for the EXYNOS media driver (s5p); - two fixes at the OMAP3 preview driver; - one fix at the dvb core failure path; - an include missing (slab.h) at smiapp-core causing compilation breakage; - em28xx was not loading the IR driver driver anymore. PS.: I'll be out next week due to holidays. Thanks! Mauro Latest commit at the branch: ec3ed85f926f4e900bc48cec6e72abbe6475321f [media] Revert "[media] V4L: JPEG class documentation corrections" The following changes since commit 099987f0aaf28771261b91a41240b9228f2e32b2: [media] smia: Fix compile failures (2012-06-18 19:52:05 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to ec3ed85f926f4e900bc48cec6e72abbe6475321f: [media] Revert "[media] V4L: JPEG class documentation corrections" (2012-07-07 00:12:50 -0300) Anton Blanchard (3): [media] cx23885: Silence unknown command warnings [media] winbond-cir: Fix txandrx module info [media] winbond-cir: Initialise timeout, driver_type and allowed_protos David Dillow (1): [media] cx231xx: don't DMA to random addresses Devin Heitmueller (6): [media] cx25840: fix regression in HVR-1800 analog support [media] cx25840: fix regression in analog support hue/saturation controls [media] cx25840: fix regression in HVR-1800 analog audio [media] cx25840: fix vsrc/hsrc usage on cx23888 designs [media] cx23885: make analog support work for HVR_1250 (cx23885 variant) [media] cx23885: add support for HVR-1255 analog (cx23888 variant) Fengguang Wu (1): [media] pms: fix build error in pms_probe() Kamil Debski (1): [media] s5p-mfc: Fixed setup of custom controls in decoder and encoder Laurent Pinchart (2): [media] omap3isp: preview: Fix output size computation depending on input format [media] omap3isp: preview: Fix contrast and brightness handling Mauro Carvalho Chehab (2): [media] smiapp-core: fix compilation build error [media] em28xx: fix em28xx-rc load Randy Dunlap (1): [media] media: pms.c needs linux/slab.h Sachin Kamat (2): [media] s5p-fimc: Fix compiler warning in fimc-lite.c [media] s5p-fimc: Stop media entity pipeline if fimc_pipeline_validate fails Sakari Ailus (1): [media] s5p-fimc: media_entity_pipeline_start() may fail Santosh Nayak (1): [media] dvb-core: Release semaphore on error path dvb_register_device() Sylwester Nawrocki (10): [media] s5p-fimc: Fix bug in capture node open() [media] s5p-fimc: Don't create multiple active links to same sink entity [media] s5p-fimc: Honour sizeimage in VIDIOC_S_FMT [media] s5p-fimc: Remove superfluous checks for buffer type [media] s5p-fimc: Prevent lock-up in multiple sensor systems [media] s5p-fimc: Fix fimc-lite system wide suspend procedure [media] s5p-fimc: Shorten pixel formats description [media] s5p-fimc: Update to the control handler lock changes [media] s5p-fimc: Add missing FIMC-LITE file operations locking [media] Revert "[media] V4L: JPEG class documentation corrections" Documentation/DocBook/media/v4l/controls.xml |2 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 -- drivers/media/dvb/dvb-core/dvbdev.c|1 + drivers/media/rc/winbond-cir.c |4 +- drivers/media/video/cx231xx/cx231xx-audio.c|4 +- drivers/media/video/cx231xx/cx231xx-vbi.c |2 +- drivers/media/video/cx23885/cx23885-cards.c| 89 +--- drivers/media/video/cx23885/cx23885-dvb.c |6 ++ drivers/media/video/cx23885/cx23885-video.c|9 +- drivers/media/video/cx23885/cx23885.h |1 + drivers/media/video/cx25840/cx25840-core.c | 76 - drivers/media/video/em28xx/em28xx-cards.c |2 +- drivers/media/video/omap3isp/isppreview.c |6 +- drivers/media/video/pms.c |2 + drivers/media/video/s5p-fimc/fimc-capture.c| 69 --- drivers/media/video/s5p-fimc/fimc-core.c | 19 +++-- drivers/media/video/s5p-fimc/fimc-lite.c | 73 +++- drivers/media/video/s5p-fimc/fimc-mdevice.c| 48 +-- drivers/media/video/s5p-fimc/fimc-mdevice.h|2 - drivers/media/video/s5p-mfc/s5p_mfc_dec.c |1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c
Re: [Ksummit-2012-discuss] Device-tree cross-subsystem binding workshop [was Media system Summit]
On 07/13/12 04:20, Olof Johansson wrote: > On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil wrote: >> On Thu July 12 2012 18:48:23 Olof Johansson wrote: >>> On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown >>> wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: > I'd like to add a "Common device tree bindings for media devices" topic to > the agenda for consideration. It'd be nice to get this to join up with ASoC... >>> >>> >>> There's a handful of various subsystems that have similar topics, >>> maybe slice it the other way and do a device-tree/ACPI breakout that >>> cuts across the various areas instead? >>> >>> Communication really needs to be two-way: Crafting good bindings for a >>> complex piece of hardware isn't trivial and having someone know both >>> the subsystem and device tree principles is rare. At least getting all >>> those people into the same room would be good. >> >> I'm not so sure: I think that most decisions that need to be made are >> quite subsystem specific. Trying to figure out how to implement DT for >> multiple subsystems in one workshop seems unlikely to succeed, simply >> because of lack of time. I also don't think there is much overlap between >> subsystems in this respect, so while the DT implementation for one subsystem >> is discussed, the representatives of other subsystems are twiddling their >> thumbs. >> >> It might be more productive to have one or two DT experts around who >> rotate over the various workshops that have to deal with the DT and can >> offer advice. > > One of the real problems right now is the lack of DT reviewers and > general reviewer fatigue. In particular, many of the proposed bindings > tend to have the same issues (focusing too much on how the > platform_data is structured today and not on what the hardware > actually is), and a few other similar things. > > Based on that I don't think it's a better solution to have the same > few people walk from room to room to cover the same thing multiple > times. No one has to sit there the whole day and listen on it all, but > for those who are genuinely interested in how other subsystems will > handle these bindings, I think it would be very useful to learn from > how they made their decisions. Don't work in a vacuum, etc. > > So, I'd like to formally propose this as a mini-summit or workshop or > whatever you might want to call it. I can help organize it together > with Rob and Grant if needed (especially since Grant has a lot of > other things going on at the moment). > > If there's insufficent interest to do this as a separate event we can > try to accomodate for it as part of the ARM mini-summit, but squeezing > all of that in with the rest of the ARM activities in one day will be > hard. +1 -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Device-tree cross-subsystem binding workshop [was Media system Summit]
On 07/12/2012 08:20 PM, Olof Johansson wrote: > On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil wrote: >> On Thu July 12 2012 18:48:23 Olof Johansson wrote: >>> On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown >>> wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: > I'd like to add a "Common device tree bindings for media devices" topic to > the agenda for consideration. It'd be nice to get this to join up with ASoC... >>> >>> >>> There's a handful of various subsystems that have similar topics, >>> maybe slice it the other way and do a device-tree/ACPI breakout that >>> cuts across the various areas instead? >>> >>> Communication really needs to be two-way: Crafting good bindings for a >>> complex piece of hardware isn't trivial and having someone know both >>> the subsystem and device tree principles is rare. At least getting all >>> those people into the same room would be good. >> >> I'm not so sure: I think that most decisions that need to be made are >> quite subsystem specific. Trying to figure out how to implement DT for >> multiple subsystems in one workshop seems unlikely to succeed, simply >> because of lack of time. I also don't think there is much overlap between >> subsystems in this respect, so while the DT implementation for one subsystem >> is discussed, the representatives of other subsystems are twiddling their >> thumbs. >> >> It might be more productive to have one or two DT experts around who >> rotate over the various workshops that have to deal with the DT and can >> offer advice. > > One of the real problems right now is the lack of DT reviewers and > general reviewer fatigue. In particular, many of the proposed bindings > tend to have the same issues (focusing too much on how the > platform_data is structured today and not on what the hardware > actually is), and a few other similar things. Agreed. It's hard to review things spanning across all subsystems and define something which works well across platforms. Often within a single subsystem we repeat things as platforms one by one convert to DT. On the other hand, I guess re-occurring review issues is a common problem across the kernel. Perhaps part of the issue is we're trying to put too much into DT? It's unfortunate that other than the recovering PPC developers now working on ARM, there has not been a lot of review from folks that have worked with DT for a bit longer. > Based on that I don't think it's a better solution to have the same > few people walk from room to room to cover the same thing multiple > times. No one has to sit there the whole day and listen on it all, but > for those who are genuinely interested in how other subsystems will > handle these bindings, I think it would be very useful to learn from > how they made their decisions. Don't work in a vacuum, etc. > > So, I'd like to formally propose this as a mini-summit or workshop or > whatever you might want to call it. I can help organize it together > with Rob and Grant if needed (especially since Grant has a lot of > other things going on at the moment). > > If there's insufficent interest to do this as a separate event we can > try to accomodate for it as part of the ARM mini-summit, but squeezing > all of that in with the rest of the ARM activities in one day will be > hard. I happy to help organize it. I think keeping it separate from ARM mini-summit is better otherwise we may end up with somewhat the same group of ARM developers as past DT discussions. Rob > > -Olof > -- 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
Getting a webcam to work
It's labelled "V-Gear TalkCamPro" from lsusb: Bus 001 Device 012: ID eb1a:2711 eMPIA Technology, Inc. and: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/5p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/7p, 480M |__ Port 1: Dev 12, If 0, Class=vend., Driver=, 480M |__ Port 1: Dev 12, If 1, Class=audio, Driver=snd-usb-audio, 480M |__ Port 1: Dev 12, If 2, Class=audio, Driver=snd-usb-audio, 480M It looks like the audio part is recognised, but the video not. I see in http://lxr.linux.no/linux+*/drivers/media/video/em28xx/em28xx-cards.c that product ids 2710, 2750 and 2751 are recognised by the driver, but not 2711. I'm tempted to add it as a EM2800_BOARD_UNKNOWN and see if it works. Is there some methodology I should follow to get a new webcam to work? Thanks, Alex PS. I'm not subscribed. -- 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: OMAP4 support
Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas wrote: > On 2012-07-10 11:05, Chris Lalancette wrote: >> >> On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas wrote: >>> >>> I'm looking for video support on OMAP4 platforms. I've found the >>> PandaBoard camera project >>> (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) >>> and this is starting to work. That said, I'm having some >>> issues with setting up the pipeline, etc. >>> >>> Can this list help out? >> >> >> I'm not sure exactly what kind of cameras you want to get working, but >> if you are looking to get CSI2 cameras going through the ISS, Sergio >> Aguirre has been working on support. He also works on the media-ctl >> tool, which is used for configuring the media framework pipeline. The >> latest versions that I am aware of are here: >> >> git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git > > > Yes, this is the tree I've been working with (pointed to by the page I > mentioned). > > My kernel can see the camera OV5650 and set up the pipeline. I am able to > grab > the raw SGRBG10 data but I'd like to get the ISS to convert this to a more > usable > UYVY format. Here's what I tried: > media-ctl -r > media-ctl -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS ISP IPIPEIF":0 [1]' > media-ctl -l '"OMAP4 ISS ISP IPIPEIF":1 -> "OMAP4 ISS ISP IPIPEIF > output":0 [1]' > media-ctl -f '"ov5650 3-0036":0 [SGRBG10 2592x1944]' > media-ctl -f '"OMAP4 ISS CSI2a":0 [SGRBG10 2592x1944]' > media-ctl -f '"OMAP4 ISS ISP IPIPEIF":0 [SGRBG10 2592x1944]','"OMAP4 ISS > ISP IPIPEIF":1 [UYVY 2592x1944]' > > Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out > (my reading > of the manual implies that this _should_ be possible). I always see this > pipeline setup: > - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev2 > pad0: Input [SGRBG10 2592x1944] > <- 'OMAP4 ISS CSI2a':pad1 [ACTIVE] > <- 'OMAP4 ISS CSI2b':pad1 [] > pad1: Output [SGRBG10 2592x1944] > -> 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] > pad2: Output [SGRBG10 2592x1944] > -> 'OMAP4 ISS ISP resizer':pad0 [] > > Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10->YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? > > Note: if this is not the appropriate place to ask these questions, please > redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Regards, Sergio > > > Thanks > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > > > -- 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: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 2:05 PM, Guennadi Liakhovetski wrote: > On Thu, 12 Jul 2012, Hans Verkuil wrote: > >> On Thu July 12 2012 18:48:23 Olof Johansson wrote: >> > On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown >> > wrote: >> > > On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: >> > > >> > >> I'd like to add a "Common device tree bindings for media devices" topic >> > >> to >> > >> the agenda for consideration. >> > > >> > > It'd be nice to get this to join up with ASoC... >> > >> > >> > There's a handful of various subsystems that have similar topics, >> > maybe slice it the other way and do a device-tree/ACPI breakout that >> > cuts across the various areas instead? >> > >> > Communication really needs to be two-way: Crafting good bindings for a >> > complex piece of hardware isn't trivial and having someone know both >> > the subsystem and device tree principles is rare. At least getting all >> > those people into the same room would be good. >> >> I'm not so sure: I think that most decisions that need to be made are >> quite subsystem specific. Trying to figure out how to implement DT for >> multiple subsystems in one workshop seems unlikely to succeed, simply >> because of lack of time. I also don't think there is much overlap between >> subsystems in this respect, so while the DT implementation for one subsystem >> is discussed, the representatives of other subsystems are twiddling their >> thumbs. >> >> It might be more productive to have one or two DT experts around who >> rotate over the various workshops that have to deal with the DT and can >> offer advice. > > I'm sure everyone has seen this, but just to have it mentioned here: > > href="http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755";> > shameless self-advertisement I hadn't seen it, since you didn't cc devicetree-discuss. Well, I'm also generally behind on list email right now since I am travelling but I couldn't find it in any list folder I subscribe to. > As for whether or not discuss DT for various subsystems together - why not > do both? First short sessions in each subsystems, of course, this would > only work if proposals have been prepared beforehand and at least > preliminary discussions on the MLs have taken place, and then another > (also short) combined session? Of course, it also depends on how much time > we can and want to dedicate to this. The agenda for such a day should probably be partially broken down per subsystem, yes, and it would make sense for people from the various areas to describe the kind of setup that they need to be able to define, similar to how you did in your writeup above. In some cases it would be a matter of in-person review/discussion/arguments of already proposed bindings, in other cases it would probably be a seeding discussion for upcoming bindings instead. Having the latter piggy-back on hearing what's discussed with the former category would likely be a good idea. -Olof -- 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] Use a named union in struct v4l2_ioctl_info
Hi Hans, On Thu, 12 Jul 2012 18:06:24 +0200 Hans Verkuil wrote: > > struct v4l2_ioctl_info uses an anonymous union, which is initialized > in the v4l2_ioctls table. > > Unfortunately gcc < 4.6 uses a non-standard syntax for that, so trying to > compile v4l2-ioctl.c with an older gcc will fail. > > It is possible to work around this by testing the gcc version, but in this > case it is easier to make the union named since it is used in only a few > places. > > Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem > in linux-next. Since Mauro is still on holiday you'll have to apply it > manually. I have added this as a merge fix for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSuVrtLAYNM.pgp Description: PGP signature
Device-tree cross-subsystem binding workshop [was Media system Summit]
On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil wrote: > On Thu July 12 2012 18:48:23 Olof Johansson wrote: >> On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown >> wrote: >> > On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: >> > >> >> I'd like to add a "Common device tree bindings for media devices" topic to >> >> the agenda for consideration. >> > >> > It'd be nice to get this to join up with ASoC... >> >> >> There's a handful of various subsystems that have similar topics, >> maybe slice it the other way and do a device-tree/ACPI breakout that >> cuts across the various areas instead? >> >> Communication really needs to be two-way: Crafting good bindings for a >> complex piece of hardware isn't trivial and having someone know both >> the subsystem and device tree principles is rare. At least getting all >> those people into the same room would be good. > > I'm not so sure: I think that most decisions that need to be made are > quite subsystem specific. Trying to figure out how to implement DT for > multiple subsystems in one workshop seems unlikely to succeed, simply > because of lack of time. I also don't think there is much overlap between > subsystems in this respect, so while the DT implementation for one subsystem > is discussed, the representatives of other subsystems are twiddling their > thumbs. > > It might be more productive to have one or two DT experts around who > rotate over the various workshops that have to deal with the DT and can > offer advice. One of the real problems right now is the lack of DT reviewers and general reviewer fatigue. In particular, many of the proposed bindings tend to have the same issues (focusing too much on how the platform_data is structured today and not on what the hardware actually is), and a few other similar things. Based on that I don't think it's a better solution to have the same few people walk from room to room to cover the same thing multiple times. No one has to sit there the whole day and listen on it all, but for those who are genuinely interested in how other subsystems will handle these bindings, I think it would be very useful to learn from how they made their decisions. Don't work in a vacuum, etc. So, I'd like to formally propose this as a mini-summit or workshop or whatever you might want to call it. I can help organize it together with Rob and Grant if needed (especially since Grant has a lot of other things going on at the moment). If there's insufficent interest to do this as a separate event we can try to accomodate for it as part of the ARM mini-summit, but squeezing all of that in with the rest of the ARM activities in one day will be hard. -Olof -- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
On 07/13/2012 12:07 AM, Steven Toth wrote: Resend in plaintext, it got bounced from vger. On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth wrote: Is there anyone who could say straight now what is best approach and where to look example? I don't have an answer but the topic does interest me. :) Nobody understands the relationship between the bridge and the sub-component as well as the bridge driver. The current interfaces are limiting in many ways. We solve that today with rather ugly 'attach' structures that are inflexible, for example to set gpios to a default state. Then, once that interface is attached, the bridge effectively loses most of the control to the tuner and/or demod. The result is a large disconnect between the bridge and subcomponents. I agree that mostly. For example that GPIO. It fits very poorly for interfaces that are highly given hardware design dependent like GPIOs. You can code logic like GPIO0 is LED, GPIO0 is tuner reset, GPIO0 is LNA and then set that logic in attach(). Due to that I am looking for better alternative. Why limit any interface extension to GPIOs? Why not make something a little more flexible so we can pass custom messages around? get(int parm, *value) and set(int parm, value) Bridges and demods can define whatever parmid's they like in their attach headers. (Like we do for callbacks currently). For example, some tuners have temperature sensors, I have no ability to read that today from the bridge, other than via I2C - then I'm pulling i2c device specific logic into the bridge. :( Yes! indeed, it is only possibly just like you said. Fortunately this kind of properties are not very common. Temperature is offered by many tuners, but there is no much need for that info in bridge. Maybe force sleep or switch powers totally off by using GPIO to prevent overheat. It would be nice to be able to demod/tunerptr->get(XC5000_PARAM_TEMP, &value), for example. Get/Set I/F is a bit of a classic, between tuners and video decoders. This (at least a while ago) was poorly handled, or not at all. Only the bridge really knows how to deal with odd component configurations like this, yet it has little or no control. IF information is now set tuner on attach() and then tuner delivers that info to demodulator via .get_if_frequency() which is member of tuner ops. Technically that solution works. If hardware design based IFs are not given as parameter on tuner attach() tuner should use tuner default IFs which are likely quite correct. I'd want to see a list of 4 or 5 good get/set use cases though, with some unusual parms, before I'd really believe a generic get/set is more appropriate than a strongly typed set of additional function pointers. Generally speaking for that set/get, I sent mail about ~same issue yesterday. http://www.spinics.net/lists/linux-media/msg50202.html There is set_property() and get_property() callbacks defined for FE already. But those are not used. My opinion is that those callbacks should be changed to deliver data for demodulator and for tuner too instead of current method - which is common huge properties cache structure shared between all sub-drivers. I don't like it all as it is stupid to add stuff that common structure for every standard we has. Lets take example device that supports DVB-C and other device supports ISDB-T. How many common parameters we has? I think only one - frequency. All the others are just waste. What I think I am going to make new RFC which changes that so every parameter from userspace is passed to the demodulator driver (using set_property() - change it current functionality) and not cached to the common cache at all. Shortly: change current common cache based parameter transmission to happen set parameter to demodulator one by one. What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? I sent PATCH RFC for DVB API to add LNA support yesterday. It is new API parameter. User could select ON/OFF/AUTO and on AUTO mode driver should make decision, likely taking signal measurements etc. New callback is added for frontend. If bridge likes to handle LNA it sets that callback in order to get user requests. When bridge gets that set_lna() callback it examines what user request and likely sets GPIOs. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: Add stk1160 new driver
Hans, On Tue, Jul 10, 2012 at 3:39 AM, Hans Verkuil wrote: > > Take a look at the latest videobuf2-core.h: I've added helper functions > that check the owner. You can probably simplify the driver code quite a bit > by using those helpers. > Indeed, using latest vb2_xxx_fop and vb2_ioctl_xxx the driver can be heavily reduced. (Great work, by the way) Almost every function looks like a direct replacement, except for mmap. If you look at current stk1160, I'm taking the lock for mmap: mutex_lock(&dev->v4l_lock); rc = vb2_mmap(&dev->vb_vidq, vma); mutex_unlock(&dev->v4l_lock); However, vb2_fop_mmap does no locking. I'm having a hard time understanding why this is not needed, perhaps you could clarify this a bit? Thanks, Ezequiel. -- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
Resend in plaintext, it got bounced from vger. On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth wrote: >> >> Is there anyone who could say straight now what is best approach and >> where to look example? >> > > I don't have an answer but the topic does interest me. :) > > Nobody understands the relationship between the bridge and the > sub-component as well as the bridge driver. The current interfaces are > limiting in many ways. We solve that today with rather ugly 'attach' > structures that are inflexible, for example to set gpios to a default state. > Then, once that interface is attached, the bridge effectively loses most of > the control to the tuner and/or demod. The result is a large disconnect > between the bridge and subcomponents. > > Why limit any interface extension to GPIOs? Why not make something a > little more flexible so we can pass custom messages around? > > get(int parm, *value) and set(int parm, value) > > Bridges and demods can define whatever parmid's they like in their attach > headers. (Like we do for callbacks currently). > > For example, some tuners have temperature sensors, I have no ability to > read that today from the bridge, other than via I2C - then I'm pulling i2c > device specific logic into the bridge. :( > > It would be nice to be able to demod/tunerptr->get(XC5000_PARAM_TEMP, > &value), for example. > > Get/Set I/F is a bit of a classic, between tuners and video decoders. This > (at least a while ago) was poorly handled, or not at all. Only the bridge > really knows how to deal with odd component configurations like this, yet it > has little or no control. > > I'd want to see a list of 4 or 5 good get/set use cases though, with some > unusual parms, before I'd really believe a generic get/set is more > appropriate than a strongly typed set of additional function pointers. > > What did you ever decide about the enable/disable of the LNA? And, how > would the bridge do that in your proposed solution? Via the proposed GPIO > interface? > > Regards, > > -- > Steven Toth - Kernel Labs > http://www.kernellabs.com > +1.646.355.8490 -- 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: [Ksummit-2012-discuss] Media system Summit
On Thu, 12 Jul 2012, Hans Verkuil wrote: > On Thu July 12 2012 18:48:23 Olof Johansson wrote: > > On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown > > wrote: > > > On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: > > > > > >> I'd like to add a "Common device tree bindings for media devices" topic > > >> to > > >> the agenda for consideration. > > > > > > It'd be nice to get this to join up with ASoC... > > > > > > There's a handful of various subsystems that have similar topics, > > maybe slice it the other way and do a device-tree/ACPI breakout that > > cuts across the various areas instead? > > > > Communication really needs to be two-way: Crafting good bindings for a > > complex piece of hardware isn't trivial and having someone know both > > the subsystem and device tree principles is rare. At least getting all > > those people into the same room would be good. > > I'm not so sure: I think that most decisions that need to be made are > quite subsystem specific. Trying to figure out how to implement DT for > multiple subsystems in one workshop seems unlikely to succeed, simply > because of lack of time. I also don't think there is much overlap between > subsystems in this respect, so while the DT implementation for one subsystem > is discussed, the representatives of other subsystems are twiddling their > thumbs. > > It might be more productive to have one or two DT experts around who > rotate over the various workshops that have to deal with the DT and can > offer advice. I'm sure everyone has seen this, but just to have it mentioned here: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755";> shameless self-advertisement I'm not sure whether the overlap with other subsystems is large or not, but there definitely is some, also with video (fbdev / drm), e.g., http://thread.gmane.org/gmane.linux.drivers.devicetree/17495 As for whether or not discuss DT for various subsystems together - why not do both? First short sessions in each subsystems, of course, this would only work if proposals have been prepared beforehand and at least preliminary discussions on the MLs have taken place, and then another (also short) combined session? Of course, it also depends on how much time we can and want to dedicate to this. Thanks Guennadi > Regards, > > Hans > > > > > There's obvious overlap with ARM here as well, since it's one of the > > current big pushers of DT use, but I think it would be better to hold > > this as a separate breakout from that. > > > > > > -Olof > > -- > > 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 > --- 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
[PATCH 5/5] radio-si470x: Add support for the new band APIs
Signed-off-by: Hans de Goede
---
drivers/media/radio/si470x/radio-si470x-common.c | 215 +-
drivers/media/radio/si470x/radio-si470x-i2c.c|1 +
drivers/media/radio/si470x/radio-si470x-usb.c|1 +
drivers/media/radio/si470x/radio-si470x.h|1 +
4 files changed, 126 insertions(+), 92 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 84ab3d57..9e38132 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -4,6 +4,7 @@
* Driver for radios with Silicon Labs Si470x FM Radio Receivers
*
* Copyright (c) 2009 Tobias Lorenz
+ * Copyright (c) 2012 Hans de Goede
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -127,14 +128,6 @@ static unsigned short space = 2;
module_param(space, ushort, 0444);
MODULE_PARM_DESC(space, "Spacing: 0=200kHz 1=100kHz *2=50kHz*");
-/* Bottom of Band (MHz) */
-/* 0: 87.5 - 108 MHz (USA, Europe)*/
-/* 1: 76 - 108 MHz (Japan wide band) */
-/* 2: 76 - 90 MHz (Japan) */
-static unsigned short band = 1;
-module_param(band, ushort, 0444);
-MODULE_PARM_DESC(band, "Band: 0=87.5..108MHz *1=76..108MHz* 2=76..90MHz");
-
/* De-emphasis */
/* 0: 75 us (USA) */
/* 1: 50 us (Europe, Australia, Japan) */
@@ -152,13 +145,61 @@ static unsigned int seek_timeout = 5000;
module_param(seek_timeout, uint, 0644);
MODULE_PARM_DESC(seek_timeout, "Seek timeout: *5000*");
-
+static const struct v4l2_frequency_band bands[] = {
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 87500 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 1,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 76000 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 2,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 76000 * 16,
+ .rangehigh = 9 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+};
/**
* Generic Functions
**/
/*
+ * si470x_set_band - set the band
+ */
+static int si470x_set_band(struct si470x_device *radio, int band)
+{
+ if (radio->band == band)
+ return 0;
+
+ radio->band = band;
+ radio->registers[SYSCONFIG2] &= ~SYSCONFIG2_BAND;
+ radio->registers[SYSCONFIG2] |= radio->band << 6;
+ return si470x_set_register(radio, SYSCONFIG2);
+}
+
+/*
* si470x_set_chan - set the channel
*/
static int si470x_set_chan(struct si470x_device *radio, unsigned short chan)
@@ -194,48 +235,39 @@ done:
return retval;
}
-
/*
- * si470x_get_freq - get the frequency
+ * si470x_get_step - get channel spacing
*/
-static int si470x_get_freq(struct si470x_device *radio, unsigned int *freq)
+static unsigned int si470x_get_step(struct si470x_device *radio)
{
- unsigned int spacing, band_bottom;
- unsigned short chan;
- int retval;
-
/* Spacing (kHz) */
switch ((radio->registers[SYSCONFIG2] & SYSCONFIG2_SPACE) >> 4) {
/* 0: 200 kHz (USA, Australia) */
case 0:
- spacing = 0.200 * FREQ_MUL; break;
+ return 200 * 16;
/* 1: 100 kHz (Europe, Japan) */
case 1:
- spacing = 0.100 * FREQ_MUL; break;
+ return 100 * 16;
/* 2: 50 kHz */
default:
- spacing = 0.050 * FREQ_MUL; break;
+ return 50 * 16;
};
+}
- /* Bottom of Band (MHz) */
- switch ((radio->registers[SYSCONFIG2] & SYSCONFIG2_BAND) >> 6) {
- /* 0: 87.5 - 108 MHz (USA, Europe) */
- case 0:
- band_bottom = 87.5 * FREQ_MUL; break;
-
[PATCH 3/5] radio-si470x: restore ctrl settings after suspend/resume
Signed-off-by: Hans de Goede
---
drivers/media/radio/si470x/radio-si470x-usb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c
b/drivers/media/radio/si470x/radio-si470x-usb.c
index 40b963c..0204cf4 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -792,11 +792,16 @@ static int si470x_usb_driver_suspend(struct usb_interface
*intf,
static int si470x_usb_driver_resume(struct usb_interface *intf)
{
struct si470x_device *radio = usb_get_intfdata(intf);
+ int ret;
dev_info(&intf->dev, "resuming now...\n");
/* start radio */
- return si470x_start_usb(radio);
+ ret = si470x_start_usb(radio);
+ if (ret == 0)
+ v4l2_ctrl_handler_setup(&radio->hdl);
+
+ return ret;
}
--
1.7.10.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
[PATCH 4/5] radio-si470x: Fix band selection
The mask was wrong resulting in band 0 and 1 always ending up as band 0 in the register. Signed-off-by: Hans de Goede --- drivers/media/radio/si470x/radio-si470x.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/si470x/radio-si470x.h b/drivers/media/radio/si470x/radio-si470x.h index b3b612f..11f14b6 100644 --- a/drivers/media/radio/si470x/radio-si470x.h +++ b/drivers/media/radio/si470x/radio-si470x.h @@ -87,7 +87,7 @@ #define SYSCONFIG2 5 /* System Configuration 2 */ #define SYSCONFIG2_SEEKTH 0xff00 /* bits 15..08: RSSI Seek Threshold */ -#define SYSCONFIG2_BAND0x0080 /* bits 07..06: Band Select */ +#define SYSCONFIG2_BAND0x00c0 /* bits 07..06: Band Select */ #define SYSCONFIG2_SPACE 0x0030 /* bits 05..04: Channel Spacing */ #define SYSCONFIG2_VOLUME 0x000f /* bits 03..00: Volume */ -- 1.7.10.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
[PATCH 2/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
To allow apps to limit a hw-freq-seek to a specific band, for further
info see the documentation this patch adds for these new fields.
Signed-off-by: Hans de Goede
---
.../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 50
include/linux/videodev2.h |5 +-
2 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
index f4db44d..3dd1bec 100644
--- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
@@ -52,11 +52,23 @@
Start a hardware frequency seek from the current frequency.
To do this applications initialize the tuner,
type, seek_upward,
-spacing and
-wrap_around fields, and zero out the
-reserved array of a &v4l2-hw-freq-seek; and
-call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer
-to this structure.
+wrap_around, spacing,
+rangelow and rangehigh
+fields, and zero out the reserved array of a
+&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK
+ioctl with a pointer to this structure.
+
+The rangelow and
+rangehigh fields can be set to a non-zero value to
+tell the driver to search a specific band. If the &v4l2-tuner;
+capability field has the
+V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values
+must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If
+the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set,
+then these values must exactly match those of one of the bands returned by
+&VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall
+within the selected band it will be clamped to fit in the band before the
+seek is started.
If an error is returned, then the original frequency will
be restored.
@@ -102,7 +114,27 @@ field and the &v4l2-tuner;
index field.
__u32
- reserved[7]
+ rangelow
+ If non-zero, the lowest tunable frequency of the band to
+search in units of 62.5 kHz, or if the &v4l2-tuner;
+capability field has the
+V4L2_TUNER_CAP_LOW flag set, in units of 62.5 Hz.
+If rangelow is zero a reasonable default value
+is used.
+
+
+ __u32
+ rangehigh
+ If non-zero, the highest tunable frequency of the band to
+search in units of 62.5 kHz, or if the &v4l2-tuner;
+capability field has the
+V4L2_TUNER_CAP_LOW flag set, in units of 62.5 Hz.
+If rangehigh is zero a reasonable default value
+is used.
+
+
+ __u32
+ reserved[5]
Reserved for future extensions. Applications
must set the array to zero.
@@ -119,8 +151,10 @@ field and the &v4l2-tuner;
index field.
EINVAL
The tuner index is out of
-bounds, the wrap_around value is not supported or the value in the
type field is
-wrong.
+bounds, the wrap_around value is not supported or
+one of the values in the type,
+rangelow or rangehigh
+fields is wrong.
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 9fa822a..1c6aa63 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2029,6 +2029,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
#define V4L2_TUNER_CAP_FREQ_BANDS 0x0400
+#define V4L2_TUNER_CAP_HWSEEK_PROG_LIM 0x0800
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2074,7 +2075,9 @@ struct v4l2_hw_freq_seek {
__u32 seek_upward;
__u32 wrap_around;
__u32 spacing;
- __u32 reserved[7];
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u32 reserved[5];
};
/*
--
1.7.10.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
[PATCH 1/5] v4l2 spec: add VIDIOC_ENUM_FREQ_BANDS documentation.
From: Hans Verkuil Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/compat.xml | 12 ++ Documentation/DocBook/media/v4l/v4l2.xml |6 + .../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 179 .../DocBook/media/v4l/vidioc-g-frequency.xml |7 +- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 26 ++- 5 files changed, 221 insertions(+), 9 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 97b8951..aa28015 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2471,6 +2471,15 @@ that used it. It was originally scheduled for removal in 2.6.35. + + V4L2 in Linux 3.6 + + + Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;. + + + + Relation of V4L2 to other Linux multimedia APIs @@ -2600,6 +2609,9 @@ ioctls. V4L2_CID_AUTO_FOCUS_AREA control. + + Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl. + diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 36bafc4..eee6908 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -140,6 +140,11 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> + 3.6 + 2012-07-02 + hv + Added VIDIOC_ENUM_FREQ_BANDS. + 3.5 2012-05-07 sa, sn @@ -534,6 +539,7 @@ and discussions on the V4L mailing list. &sub-enum-fmt; &sub-enum-framesizes; &sub-enum-frameintervals; +&sub-enum-freq-bands; &sub-enuminput; &sub-enumoutput; &sub-enumstd; diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml new file mode 100644 index 000..6541ba0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -0,0 +1,179 @@ + + +ioctl VIDIOC_ENUM_FREQ_BANDS +&manvol; + + + +VIDIOC_ENUM_FREQ_BANDS +Enumerate supported frequency bands + + + + + + int ioctl + int fd + int request + struct v4l2_frequency_band +*argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_FREQ_BANDS + + + + argp + + + + + + + + +Description + + + Experimental + This is an experimental + interface and may change in the future. + + +Enumerates the frequency bands that a tuner or modulator supports. +To do this applications initialize the tuner, +type and index fields, +and zero out the reserved array of a &v4l2-frequency-band; and +call the VIDIOC_ENUM_FREQ_BANDS ioctl with a pointer +to this structure. + +This ioctl is supported if the V4L2_TUNER_CAP_FREQ_BANDS capability +of the corresponding tuner/modulator is set. + + + struct v4l2_frequency_band + + &cs-str; + + + __u32 + tuner + The tuner or modulator index number. This is the +same value as in the &v4l2-input; tuner +field and the &v4l2-tuner; index field, or +the &v4l2-output; modulator field and the +&v4l2-modulator; index field. + + + __u32 + type + The tuner type. This is the same value as in the +&v4l2-tuner; type field. The type must be set +to V4L2_TUNER_RADIO for /dev/radioX +device nodes, and to V4L2_TUNER_ANALOG_TV +for all others. Set this field to V4L2_TUNER_RADIO for +modulators (currently only radio modulators are supported). +See + + + __u32 + index + Identifies the frequency band, set by the application. + + + __u32 + capability + The tuner/modulator capability flags for +this frequency band, see . The V4L2_TUNER_CAP_LOW +capability must be the same for all frequency bands of the selected tuner/modulator. +So either all bands have that capability set, or none of them have that capability. + + + __u32 + rangelow + The lowest tunable frequency in +units of 62.5 kHz, or if the capability +flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz, for this frequency band. + + + __u32 + rangehigh + The highest tunable frequency in +units of 62.5 kHz, or if the capability +flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz, for this frequency band. + + + __u32 +
RFC: Add support for limiting hw freq seeks to a certain band (v2)
This patchset, which builds on top of hverkuil's bands2 branch, which adds the VIDIOC_ENUM_FREQ_BANDS API, add support for limiting hw freq seeks to one of the bands from VIDIOC_ENUM_FREQ_BANDS, or a subset there of. The first patch introduces the new API and documents its, the other patches are patches to the si470x radio driver, implementing the new API, and removing the band module parameter as this is no longer needed with this new API. A git tree with all hverkuils patches included is here: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.6-wip A git tree of xawtv3 with its radio app modified to support the new API is here: http://git.linuxtv.org/hgoede/xawtv3.git/shortlog/refs/heads/band-support Changes in v2: -improve / clarify the documentation on how the rangelow and rangehigh fields of the v4l2_hw_freq_seek struct are used Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
Hi, On 07/12/2012 11:27 AM, Hans Verkuil wrote: On Wed 11 July 2012 20:37:14 Hans de Goede wrote: 2) What happens if the current frequency is outside the low/high range? The hwseek spec says that the seek starts from the current frequency, so that might mean that hwseek returns -ERANGE in this case. What the si470x code currently does is just clamp the frequency to the new range before seeking, but -ERANGE works for me too. Clamping is a better idea IMHO as long as it is documented. Ok, I've respun this patch to improve the documentation in various parts, I'm resending the entire set right after this email. Regards, Hans p.s. Tomorrow morning I'm leaving for a week of vacation, during which I won't be reading my mail. If everybody agrees on the 2nd revision of this patchset please add it to your bands2 branch, and if you agree that this seems to be it wrt the API for tuner-bands, you could also consider sending a pull-req for it to Mauro for 3.6 :) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
GPIO interface between DVB sub-drivers (bridge, demod, tuner)
I am looking kinda standardized interface for setting GPIOs between the DVB drivers chip drivers. For most typical example there is LNA which is controlled by RF-tuner GPIO. That kind of LNA controlling logic belongs to interface driver thus I will need to call demod driver from bridge in order to set LNA. Simply solution is to add own own callbacks, set_gpio() and get_gpio() for both tuner and demod ops but I will not like to that of there is existing solutions. Grepping Documentation reveals quite much documents, most interesting seems to be: Documentation/gpio.txt Documentation/devicetree/bindings/gpio/gpio.txt Documentation/pinctrl.txt Is there anyone who could say straight now what is best approach and where to look example? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Jul 12 19:00:20 CEST 2012 git hash:b7e386360922a15f943b2fbe8d77a19bb86f2e6f gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: 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-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/01] media: gscaler: Add new driver for generic scaler
Hi Shaik,
A few more remarks...
On 07/05/2012 12:27 PM, Shaik Ameer Basha wrote:
> diff --git a/drivers/media/video/exynos/gsc/gsc-core.c
> b/drivers/media/video/exynos/gsc/gsc-core.c
> new file mode 100644
> index 000..06bd24f
> --- /dev/null
> +++ b/drivers/media/video/exynos/gsc/gsc-core.c
> @@ -0,0 +1,1304 @@
> +/* linux/drivers/media/video/exynos/gsc/gsc-core.c
> + *
> + * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung EXYNOS5 SoC series G-scaler driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published
> + * by the Free Software Foundation, either version 2 of the License,
> + * or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "gsc-core.h"
> +
> +#define GSC_CLOCK_GATE_NAME "gscl"
> +
> +int gsc_dbg;
> +module_param(gsc_dbg, int, 0644);
> +
> +
> +static struct gsc_fmt gsc_formats[] = {
static const
> + {
> + .name = "RGB565",
> + .pixelformat= V4L2_PIX_FMT_RGB565X,
> + .depth = { 16 },
> + .color = GSC_RGB,
> + .num_planes = 1,
> + .num_comp = 1,
> + }, {
...
> +struct gsc_fmt *find_fmt(u32 *pixelformat, u32 *mbus_code, int index)
> +{
> + struct gsc_fmt *fmt, *def_fmt = NULL;
> + unsigned int i;
> +
> + if (index>= ARRAY_SIZE(gsc_formats))
if (index >= (int)ARRAY_SIZE(gsc_formats))
(otherwise negative indexes won't work)
> + return NULL;
> +
> + for (i = 0; i< ARRAY_SIZE(gsc_formats); ++i) {
> + fmt = get_format(i);
> + if (pixelformat&& fmt->pixelformat == *pixelformat)
> + return fmt;
> + if (mbus_code&& fmt->mbus_code == *mbus_code)
> + return fmt;
> + if (index == i)
> + def_fmt = fmt;
> + }
> + return def_fmt;
> +
> +}
...
> +int gsc_enum_fmt_mplane(struct v4l2_fmtdesc *f)
> +{
> + struct gsc_fmt *fmt;
> +
> + fmt = find_fmt(NULL, NULL, f->index);
> + if (!fmt)
> + return -EINVAL;
> +
> + strncpy(f->description, fmt->name, sizeof(f->description) - 1);
strlcpy(f->description, fmt->name, sizeof(f->description));
> + f->pixelformat = fmt->pixelformat;
> +
> + return 0;
> +}
> +
> +u32 get_plane_size(struct gsc_frame *frame, unsigned int plane)
> +{
> + if (!frame || plane>= frame->fmt->num_planes) {
> + gsc_err("Invalid argument");
> + return 0;
> + }
> +
> + return frame->payload[plane];
> +}
> +
> +u32 get_plane_info(struct gsc_frame frm, u32 addr, u32 *index)
Why don't you just pass a pointer to struct gsc_frame ?
It is so inefficient this way...
> +{
> + if (frm.addr.y == addr) {
> + *index = 0;
> + return frm.addr.y;
> + } else if (frm.addr.cb == addr) {
> + *index = 1;
> + return frm.addr.cb;
> + } else if (frm.addr.cr == addr) {
> + *index = 2;
> + return frm.addr.cr;
> + } else {
> + gsc_err("Plane address is wrong");
> + return -EINVAL;
> + }
> +}
> +
> +void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame frm)
Ditto.
> +{
> + u32 f_chk_addr, f_chk_len, s_chk_addr, s_chk_len;
> + f_chk_addr = f_chk_len = s_chk_addr = s_chk_len = 0;
> +
> + f_chk_addr = frm.addr.y;
> + f_chk_len = frm.payload[0];
> + if (frm.fmt->num_planes == 2) {
> + s_chk_addr = frm.addr.cb;
> + s_chk_len = frm.payload[1];
> + } else if (frm.fmt->num_planes == 3) {
> + u32 low_addr, low_plane, mid_addr, mid_plane;
> + u32 high_addr, high_plane;
> + u32 t_min, t_max;
> +
> + t_min = min3(frm.addr.y, frm.addr.cb, frm.addr.cr);
> + low_addr = get_plane_info(frm, t_min,&low_plane);
> + t_max = max3(frm.addr.y, frm.addr.cb, frm.addr.cr);
> + high_addr = get_plane_info(frm, t_max,&high_plane);
> +
> + mid_plane = 3 - (low_plane + high_plane);
> + if (mid_plane == 0)
> + mid_addr = frm.addr.y;
> + else if (mid_plane == 1)
> + mid_addr = frm.addr.cb;
> + else if (mid_plane == 2)
> + mid_addr = frm.addr.cr;
> + else
> + return;
> +
> + f_chk_addr = low_addr;
> + if (mid_addr + frm.payload[mid_plane] - low_addr>
> + high_addr + frm.payload[high_plane] - mid_addr) {
> + f_chk_len = frm.payload[low_plane];
> + s_chk_addr = mid_ad
[Regression 3.1->3.2, bisected] UVC-webcam: kernel panic when starting capturing
Hi,
when I start capturing from the UVC-webcam 2232:1005 ("WebCam
SCB-0385N") of my netbook, I get a kernel panic.
You can find a screenshot of the backtrace here:
http://imageshack.us/photo/my-images/9/img125km.jpg/
This is a regression which has been introduced between kernel 3.2-rc2
and 3.2-rc3 with the following commit:
3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit
commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9
Author: Laurent Pinchart
Date: Thu Nov 3 07:24:34 2011 -0300
[media] uvcvideo: Don't skip erroneous payloads
Instead of skipping the payload completely, which would make the
resulting image corrupted anyway, store the payload normally and mark
the buffer as erroneous. If the no_drop module parameter is set to 1 the
buffer will then be passed to userspace, and tt will then be up to the
application to decide what to do with the buffer.
Signed-off-by: Laurent Pinchart
Signed-off-by: Mauro Carvalho Chehab
Regards,
Frank Schäfer
Output of lsusb -vvv:
device 2232:1005 ("WebCam SCB-0385N")
Bus 001 Device 004: ID 2232:1005
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x2232
idProduct 0x1005
bcdDevice0.07
iManufacturer 1 Image Processor
iProduct2 WebCam SCB-0385N
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 445
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 77
dwClockFrequency 30.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 2
guidExtensionCode {92423946-d10c-e34a-8783-3133f9eaaa3b}
bNumControl 3
bNrPins 1
baSourceID( 0) 1
bControlSize1
bmControls( 0) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 2
wMaxMultiplier 0
bControlSize2
bmControls 0x043f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
Power Line Frequency
iProcessing 0
bmVideoStandards 0x 9
None
SECAM - 625/50
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 3
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes3
Re: [Ksummit-2012-discuss] Media system Summit
On Thu July 12 2012 18:48:23 Olof Johansson wrote: > On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown > wrote: > > On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: > > > >> I'd like to add a "Common device tree bindings for media devices" topic to > >> the agenda for consideration. > > > > It'd be nice to get this to join up with ASoC... > > > There's a handful of various subsystems that have similar topics, > maybe slice it the other way and do a device-tree/ACPI breakout that > cuts across the various areas instead? > > Communication really needs to be two-way: Crafting good bindings for a > complex piece of hardware isn't trivial and having someone know both > the subsystem and device tree principles is rare. At least getting all > those people into the same room would be good. I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. It might be more productive to have one or two DT experts around who rotate over the various workshops that have to deal with the DT and can offer advice. Regards, Hans > > There's obvious overlap with ARM here as well, since it's one of the > current big pushers of DT use, but I think it would be better to hold > this as a separate breakout from that. > > > -Olof > -- > 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: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 09:48:23AM -0700, Olof Johansson wrote: > There's a handful of various subsystems that have similar topics, > maybe slice it the other way and do a device-tree/ACPI breakout that > cuts across the various areas instead? > Communication really needs to be two-way: Crafting good bindings for a > complex piece of hardware isn't trivial and having someone know both > the subsystem and device tree principles is rare. At least getting all > those people into the same room would be good. > There's obvious overlap with ARM here as well, since it's one of the > current big pushers of DT use, but I think it would be better to hold > this as a separate breakout from that. I think this is an excellent idea. -- 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: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown wrote: > On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: > >> I'd like to add a "Common device tree bindings for media devices" topic to >> the agenda for consideration. > > It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. There's obvious overlap with ARM here as well, since it's one of the current big pushers of DT use, but I think it would be better to hold this as a separate breakout from that. -Olof -- 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] Use a named union in struct v4l2_ioctl_info
On 07/12/2012 09:06 AM, Hans Verkuil wrote:
> Hi Mauro,
>
> struct v4l2_ioctl_info uses an anonymous union, which is initialized
> in the v4l2_ioctls table.
>
> Unfortunately gcc < 4.6 uses a non-standard syntax for that, so trying to
> compile v4l2-ioctl.c with an older gcc will fail.
>
> It is possible to work around this by testing the gcc version, but in this
> case it is easier to make the union named since it is used in only a few
> places.
>
> Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem
> in linux-next. Since Mauro is still on holiday you'll have to apply it
> manually.
>
> Regards,
>
> Hans
>
> Signed-off-by: Hans Verkuil
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap
Thanks.
>
> diff --git a/drivers/media/video/v4l2-ioctl.c
> b/drivers/media/video/v4l2-ioctl.c
> index 70e0efb..812beb0 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -1806,7 +1806,7 @@ struct v4l2_ioctl_info {
> u32 offset;
> int (*func)(const struct v4l2_ioctl_ops *ops,
> struct file *file, void *fh, void *p);
> - };
> + } u;
> void (*debug)(const void *arg, bool write_only);
> };
>
> @@ -1831,7 +1831,7 @@ struct v4l2_ioctl_info {
> .ioctl = _ioctl,\
> .flags = _flags | INFO_FL_STD, \
> .name = #_ioctl,\
> - .offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
> + .u.offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
> .debug = _debug,\
> }
>
> @@ -1840,7 +1840,7 @@ struct v4l2_ioctl_info {
> .ioctl = _ioctl,\
> .flags = _flags | INFO_FL_FUNC, \
> .name = #_ioctl,\
> - .func = _func, \
> + .u.func = _func,\
> .debug = _debug,\
> }
>
> @@ -2038,11 +2038,11 @@ static long __video_do_ioctl(struct file *file,
> if (info->flags & INFO_FL_STD) {
> typedef int (*vidioc_op)(struct file *file, void *fh, void *p);
> const void *p = vfd->ioctl_ops;
> - const vidioc_op *vidioc = p + info->offset;
> + const vidioc_op *vidioc = p + info->u.offset;
>
> ret = (*vidioc)(file, fh, arg);
> } else if (info->flags & INFO_FL_FUNC) {
> - ret = info->func(ops, file, fh, arg);
> + ret = info->u.func(ops, file, fh, arg);
> } else if (!ops->vidioc_default) {
> ret = -ENOTTY;
> } else {
>
> --
--
~Randy
--
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: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: > I'd like to add a "Common device tree bindings for media devices" topic to > the agenda for consideration. It'd be nice to get this to join up with ASoC... -- 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 for 3.6] v4l: DocBook: fix version number typo
Signed-off-by: Nicolas Thery --- Documentation/DocBook/media/v4l/compat.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 97b8951..e519ce6 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2460,7 +2460,7 @@ that used it. It was originally scheduled for removal in 2.6.35. - V4L2 in Linux 3.5 + V4L2 in Linux 3.6 Replaced input in -- 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] Use a named union in struct v4l2_ioctl_info
Hi Mauro,
struct v4l2_ioctl_info uses an anonymous union, which is initialized
in the v4l2_ioctls table.
Unfortunately gcc < 4.6 uses a non-standard syntax for that, so trying to
compile v4l2-ioctl.c with an older gcc will fail.
It is possible to work around this by testing the gcc version, but in this
case it is easier to make the union named since it is used in only a few
places.
Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem
in linux-next. Since Mauro is still on holiday you'll have to apply it manually.
Regards,
Hans
Signed-off-by: Hans Verkuil
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..812beb0 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1806,7 +1806,7 @@ struct v4l2_ioctl_info {
u32 offset;
int (*func)(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *p);
- };
+ } u;
void (*debug)(const void *arg, bool write_only);
};
@@ -1831,7 +1831,7 @@ struct v4l2_ioctl_info {
.ioctl = _ioctl,\
.flags = _flags | INFO_FL_STD, \
.name = #_ioctl,\
- .offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
+ .u.offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
.debug = _debug,\
}
@@ -1840,7 +1840,7 @@ struct v4l2_ioctl_info {
.ioctl = _ioctl,\
.flags = _flags | INFO_FL_FUNC, \
.name = #_ioctl,\
- .func = _func, \
+ .u.func = _func,\
.debug = _debug,\
}
@@ -2038,11 +2038,11 @@ static long __video_do_ioctl(struct file *file,
if (info->flags & INFO_FL_STD) {
typedef int (*vidioc_op)(struct file *file, void *fh, void *p);
const void *p = vfd->ioctl_ops;
- const vidioc_op *vidioc = p + info->offset;
+ const vidioc_op *vidioc = p + info->u.offset;
ret = (*vidioc)(file, fh, arg);
} else if (info->flags & INFO_FL_FUNC) {
- ret = info->func(ops, file, fh, arg);
+ ret = info->u.func(ops, file, fh, arg);
} else if (!ops->vidioc_default) {
ret = -ENOTTY;
} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
Hi, On 07/11/2012 08:37 PM, halli manjunatha wrote: On Wed, Jul 11, 2012 at 1:01 PM, Hans Verkuil wrote: Hi Hans, Thanks for the patch. I've CC-ed Halli as well. On Wed July 11 2012 17:47:34 Hans de Goede wrote: To allow apps to limit a hw-freq-seek to a specific band, for further info see the documentation this patch adds for these new fields. Signed-off-by: Hans de Goede --- .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 include/linux/videodev2.h |5 ++- 2 files changed, 40 insertions(+), 9 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index f4db44d..50dc9f8 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -52,11 +52,21 @@ Start a hardware frequency seek from the current frequency. To do this applications initialize the tuner, type, seek_upward, -spacing and -wrap_around fields, and zero out the -reserved array of a &v4l2-hw-freq-seek; and -call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer -to this structure. +wrap_around, spacing, +rangelow and rangehigh +fields, and zero out the reserved array of a +&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK +ioctl with a pointer to this structure. + +The rangelow and +rangehigh fields can be set to a non-zero value to +tell the driver to search a specific band. If the &v4l2-tuner; +capability field has the +V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values +must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If +the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set, +then these values must exactly match those of one of the bands returned by +&VIDIOC-ENUM-FREQ-BANDS;. OK, I have some questions here: 1) If you have a multiband tuner, what should happen if both low and high are zero? Currently it is undefined, other than that the seek should start from the current frequency until it reaches some limit. Halli, what does your hardware do? In particular, is the hwseek limited by the US/Europe or Japan band range or can it do the full range? If I'm not mistaken it is the former, right? You are right... my hardware seek is limited by the japan/US band range If it is the former, then you need to explicitly set low + high to ensure that the hwseek uses the correct range because the driver can't guess which of the overlapping bands to use. Yes in my driver I will take care of this :) I think you misunderstood Hans here, not the driver but userspace will need to fill in the rangelow / rangehigh fields of struct v4l2_hw_freq_seek, because if the current freq is in the overlapping area of the bands, the driver cannot know which band to seek, so it will just have to guess, I think it is best to just leave the band at its current setting in that case. The way the new API works (which was done this way to preserve backward compat) is that the bands returned from ENUM_BANDS are there as information only. userspace never explicitly sets a band, so an old app will just see the entire 76-108 MHZ range in the tuner struct and may do a S_FREQUENCY for any of those frequencies, and the driver must automatically switch bands when necessary. With S_HW_FREQ_SEEK we've the 2 new fields to indicate the band to seek for new apps, but with old apps these fields will be 0, and the driver needs to just pick a band to search on a best effort basis, for the si470x IE, if no band is specified in struct v4l2_hw_freq_seek, I simply always switch to the "Japan wide" band of 76-108 Mhz as that includes all other bands supported by the si470x. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 12 (v4l2-ioctl.c)
On 07/11/2012 11:03 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20120710: on i386 and/or x86_64, drivers/media/video/v4l2-ioctl.c has too many errors to be listed here. This is the beginning few lines of the errors: drivers/media/video/v4l2-ioctl.c:1848:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1848:2: warning: missing braces around initializer drivers/media/video/v4l2-ioctl.c:1848:2: warning: (near initialization for 'v4l2_ioctls[0].') drivers/media/video/v4l2-ioctl.c:1848:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1848:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1848:2: error: (near initialization for 'v4l2_ioctls[0]..offset') drivers/media/video/v4l2-ioctl.c:1849:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1849:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1849:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1849:2: error: (near initialization for 'v4l2_ioctls[2]..offset') drivers/media/video/v4l2-ioctl.c:1850:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1850:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1850:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1850:2: error: (near initialization for 'v4l2_ioctls[4]..offset') drivers/media/video/v4l2-ioctl.c:1851:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1851:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1851:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1851:2: error: (near initialization for 'v4l2_ioctls[5]..offset') drivers/media/video/v4l2-ioctl.c:1852:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1852:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1852:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1852:2: error: (near initialization for 'v4l2_ioctls[8]..offset') drivers/media/video/v4l2-ioctl.c:1853:2: error: unknown field 'func' specified in initializer -- ~Randy -- 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
Vacation hansg July 13th - July 20th
Hi All, I'm going on vacation for a week starting tomorrow, and I will *not* be reading email, etc. during that time. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media] tvp5150: signedness bug in tvp5150_selmux()
tvp5150_read() returns negative error codes so this needs to be an int for the error handling to work. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c index 0d897cb..a751b6c 100644 --- a/drivers/media/video/tvp5150.c +++ b/drivers/media/video/tvp5150.c @@ -257,7 +257,7 @@ static inline void tvp5150_selmux(struct v4l2_subdev *sd) int opmode = 0; struct tvp5150 *decoder = to_tvp5150(sd); int input = 0; - unsigned char val; + int val; if ((decoder->output & TVP5150_BLACK_SCREEN) || !decoder->enable) input = 8; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] [media] s5p-mfc: update MFC v4l2 driver to support MFC6.x
Hi Kamil,
Thank you for the review. Please find my comments inline.
On Tue, Jul 10, 2012 at 8:40 PM, Kamil Debski wrote:
>
> Hi Arun,
>
> Please find some additional comments below.
>
> > From: Arun Kumar K [mailto:arun...@samsung.com]
> > Sent: 06 July 2012 16:00
>
> [snip]
>
>
> > diff --git a/drivers/media/video/s5p-mfc/Makefile
> > b/drivers/media/video/s5p-mfc/Makefile
> > index d066340..0308d74 100644
> > --- a/drivers/media/video/s5p-mfc/Makefile
> > +++ b/drivers/media/video/s5p-mfc/Makefile
> > @@ -1,5 +1,6 @@
> > obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) := s5p-mfc.o
> > -s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o s5p_mfc_opr.o
> > +s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o
> > s5p-mfc-y += s5p_mfc_dec.o s5p_mfc_enc.o
> > -s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_cmd.o
> > -s5p-mfc-y += s5p_mfc_pm.o s5p_mfc_shm.o
> > +s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_pm.o
> > +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V5) += s5p_mfc_opr.o s5p_mfc_cmd.o
> > s5p_mfc_shm.o
> > +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V6) += s5p_mfc_opr_v6.o
> > s5p_mfc_cmd_v6.o
> > diff --git a/drivers/media/video/s5p-mfc/regs-mfc-v6.h
> > b/drivers/media/video/s5p-mfc/regs-mfc-v6.h
> > new file mode 100644
> > index 000..f22a159
>
> This Makefile does not work when compiling the driver as a module.
> (I also wrote about this in my previous email)
>
Yes. I will fix it.
> [snip]
>
> >
> > #endif /* _REGS_FIMV_H */
> > diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
> > b/drivers/media/video/s5p-mfc/s5p_mfc.c
> > index 9bb68e7..bec94bc 100644
> > --- a/drivers/media/video/s5p-mfc/s5p_mfc.c
> > +++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
>
> [snip]
>
> > @@ -285,12 +276,13 @@ static void s5p_mfc_handle_frame(struct
> > s5p_mfc_ctx
> > *ctx,
> >
> > dst_frame_status = s5p_mfc_get_dspl_status()
> > &
> > S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
> > - res_change = s5p_mfc_get_dspl_status()
> > - & S5P_FIMV_DEC_STATUS_RESOLUTION_MASK;
> > + res_change = (s5p_mfc_get_dspl_status()
> > + & S5P_FIMV_DEC_STATUS_RESOLUTION_MASK)
> > + >> S5P_FIMV_DEC_STATUS_RESOLUTION_SHIFT;
> > mfc_debug(2, "Frame Status: %x\n", dst_frame_status);
> > if (ctx->state == MFCINST_RES_CHANGE_INIT)
> > ctx->state = MFCINST_RES_CHANGE_FLUSH;
> > - if (res_change) {
> > + if (res_change && res_change != 3) {
>
> Maybe
> If (res_change == 1 || res_change == 2) {
> would be better, at least it would be more clear.
>
Sure I will change it that way.
> [snip]
>
>
> > diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
> > b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
> > index bd5706a..8c646f4 100644
> > --- a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
> > +++ b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
>
> [snip]
>
> > @@ -499,37 +563,42 @@ struct s5p_mfc_ctx {
> > int display_delay;
> > int display_delay_enable;
> > int after_packed_pb;
> > + int sei_fp_parse;
> >
> > int dpb_count;
> > int total_dpb_count;
> >
> > /* Buffers */
> > - void *ctx_buf;
> > - size_t ctx_phys;
> > - size_t ctx_ofs;
> > - size_t ctx_size;
> > -
> > - void *desc_buf;
> > - size_t desc_phys;
> > -
> > -
> > - void *shm_alloc;
> > - void *shm;
> > - size_t shm_ofs;
> > + unsigned int ctx_size;
> > + struct s5p_mfc_priv_buf ctx;
> > + struct s5p_mfc_priv_buf dsc;
> > + struct s5p_mfc_priv_buf shm;
>
> I think that ctx_size could be integrated in struct s5p_mfc_priv_buf.
> Also - why unsigned int, where in other places you use size_t for size?
> I think it should be consistent. I would choose size_t.
>
Yes. size_t is better. I will change it.
> >
> > struct s5p_mfc_enc_params enc_params;
> >
> > size_t enc_dst_buf_size;
> > + size_t luma_dpb_size;
> > + size_t chroma_dpb_size;
> > + size_t me_buffer_size;
> > + size_t tmv_buffer_size;
> >
>
> ^^ You use size_t here.
>
> [snip]
>
> > diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
> > b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
> > index 08a5cfe..65ff15d 100644
> > --- a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
> > +++ b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
> > @@ -15,7 +15,6 @@
> > #include
> > #include
> > #include
> > -#include "regs-mfc.h"
> > #include "s5p_mfc_cmd.h"
> > #include "s5p_mfc_common.h"
> > #include "s5p_mfc_debug.h"
> > @@ -38,12 +37,12 @@ int s5p_mfc_alloc_and_load_firmware(struct
> > s5p_mfc_dev *dev)
> >* into kernel. */
> > mfc_debug_enter();
> > err = request_firmware((const struct firmware **)&fw_blob,
> > - "s5p-mfc.fw", dev->v4l2_dev.dev);
> > + "mfc_fw.bin", dev->v4l2_dev.dev);
>
> Another name change? This is getting ridiculous. Nein, nein, nein ! ;)
> If you _*really*_ need such a change then go ahead and try to convince
> me, but
Re: [PATCH v2 2/2] [media] s5p-mfc: update MFC v4l2 driver to support MFC6.x
Hi Kyungmin Park, Thank you for the review. Please find my comments inline. On Fri, Jul 6, 2012 at 7:51 PM, Kyungmin Park wrote: > Hi, > > On Fri, Jul 6, 2012 at 11:00 PM, Arun Kumar K wrote: >> From: Jeongtae Park >> >> Multi Format Codec 6.x is a hardware video coding acceleration >> module fount in new Exynos5 SoC series. >> It is capable of handling a range of video codecs and this driver >> provides a V4L2 interface for video decoding and encoding. >> >> Signed-off-by: Jeongtae Park >> Singed-off-by: Janghyuck Kim >> Singed-off-by: Jaeryul Oh >> Signed-off-by: Naveen Krishna Chatradhi >> Signed-off-by: Arun Kumar K >> Cc: Marek Szyprowski >> Cc: Kamil Debski >> --- >> drivers/media/video/Kconfig | 16 +- >> drivers/media/video/s5p-mfc/Makefile |7 +- >> drivers/media/video/s5p-mfc/regs-mfc-v6.h| 676 ++ >> drivers/media/video/s5p-mfc/regs-mfc.h | 29 + >> drivers/media/video/s5p-mfc/s5p_mfc.c| 163 ++- >> drivers/media/video/s5p-mfc/s5p_mfc_cmd.c|6 +- >> drivers/media/video/s5p-mfc/s5p_mfc_cmd.h|3 + >> drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 96 ++ >> drivers/media/video/s5p-mfc/s5p_mfc_common.h | 123 ++- >> drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 160 ++- >> drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h |1 + >> drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 210 +++- >> drivers/media/video/s5p-mfc/s5p_mfc_dec.h|1 + >> drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 191 ++-- >> drivers/media/video/s5p-mfc/s5p_mfc_enc.h|1 + >> drivers/media/video/s5p-mfc/s5p_mfc_intr.c |1 - >> drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 278 +++-- >> drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 25 +- >> drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1697 >> ++ >> drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 140 +++ >> drivers/media/video/s5p-mfc/s5p_mfc_pm.c |6 +- >> drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 28 +- >> drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 13 +- >> drivers/media/video/v4l2-ctrls.c |1 - >> 24 files changed, 3476 insertions(+), 396 deletions(-) > > Doesn't it too big for one patch? Can you split it into several patches? > Ok. I will split it in the next patch. >> create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h >> >> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig >> index 99937c9..0d7fe77 100644 >> --- a/drivers/media/video/Kconfig >> +++ b/drivers/media/video/Kconfig >> @@ -1198,13 +1198,27 @@ config VIDEO_SAMSUNG_S5P_JPEG >> This is a v4l2 driver for Samsung S5P and EXYNOS4 JPEG codec >> >> config VIDEO_SAMSUNG_S5P_MFC >> + bool >> + >> +config VIDEO_SAMSUNG_S5P_MFC_V5 >> tristate "Samsung S5P MFC 5.1 Video Codec" >> - depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P >> + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_EXYNOS4 >> + select VIDEO_SAMSUNG_S5P_MFC >> select VIDEOBUF2_DMA_CONTIG >> default n >> help >> MFC 5.1 driver for V4L2. >> >> +config VIDEO_SAMSUNG_S5P_MFC_V6 > > Yes, I know it's exynos5 series features. however, it's not good idea > to add new config. > It already handled platform device with proper name. > e.g., s5p-mfc-v5, s5p-mfc-v6 and handle it with platform data. > Ok. Code changes are required for compiling both v5 and v6 together. Will incorporate in next patch. [snip] >> -#define MFC_CLKNAME"sclk_mfc" >> +#if defined(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V5) >> +#define MFC_CLKNAME"sclk_mfc" >> +#elif defined(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V6) >> +#define MFC_CLKNAME"aclk_333" > I think it can handle clkname without new config. > Yes I will change it. Regards Arun
[PATCH] [media] videobuf-dma-contig: Use NULL instead of plain integer
Fixes the following sparse warning: drivers/media/video/videobuf-dma-contig.c:59:46: warning: Using plain integer as NULL pointer Signed-off-by: Sachin Kamat --- drivers/media/video/videobuf-dma-contig.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/videobuf-dma-contig.c b/drivers/media/video/videobuf-dma-contig.c index 9b9a06f..a5af8b4 100644 --- a/drivers/media/video/videobuf-dma-contig.c +++ b/drivers/media/video/videobuf-dma-contig.c @@ -56,7 +56,7 @@ static int __videobuf_dc_alloc(struct device *dev, dev_err(dev, "dma_map_single failed\n"); free_pages_exact(mem->vaddr, mem->size); - mem->vaddr = 0; + mem->vaddr = NULL; return err; } } -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v2] i.MX27: Visstrim_M10: Add support for deinterlacing driver.
Visstrim_M10 have a tvp5150 whose video output must be deinterlaced.
The new mem2mem deinterlacing driver is very useful for that purpose.
Signed-off-by: Javier Martin
---
Changes since v1:
- Removed commented out code.
---
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 214e4ff..dbef59d 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -232,7 +232,7 @@ static void __init visstrim_camera_init(void)
static void __init visstrim_reserve(void)
{
/* reserve 4 MiB for mx2-camera */
- mx2_camera_base = arm_memblock_steal(2 * MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base = arm_memblock_steal(3 * MX2_CAMERA_BUF_SIZE,
MX2_CAMERA_BUF_SIZE);
}
@@ -419,6 +419,30 @@ static void __init visstrim_coda_init(void)
return;
}
+/* DMA deinterlace */
+static struct platform_device visstrim_deinterlace = {
+ .name = "m2m-deinterlace",
+ .id = 0,
+};
+
+static void __init visstrim_deinterlace_init(void)
+{
+ int ret = -ENOMEM;
+ struct platform_device *pdev = &visstrim_deinterlace;
+ int dma;
+
+ ret = platform_device_register(pdev);
+
+ dma = dma_declare_coherent_memory(&pdev->dev,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
+ if (!(dma & DMA_MEMORY_MAP))
+ return;
+}
+
+
static void __init visstrim_m10_revision(void)
{
int exp_version = 0;
@@ -481,6 +505,7 @@ static void __init visstrim_m10_board_init(void)
platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
&iclink_tvp5150, sizeof(iclink_tvp5150));
gpio_led_register_device(0, &visstrim_m10_led_data);
+ visstrim_deinterlace_init();
visstrim_camera_init();
visstrim_coda_init();
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] media: Add mem2mem deinterlacing driver.
Some video decoders such as tvp5150 provide separate
video fields (V4L2_FIELD_SEQ_TB/BT). This driver uses
dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB/BT
(weaving) or V4L2_FIELD_NONE (line doubling) so that the
image can be displayed or processed.
Of course there will be combing effect in the image but this
can be accepted for some low quality applications.
Currently YUV420 and YUYV formats are supported but
can be extended later.
Signed-off-by: Javier Martin
---
Changes since v1:
- Added support for V4L2_FIELD_SEQ_BT to V4L2_FIELD_INTERLACED_BT
and V4L2_FIELD_NONE.
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |2 +
drivers/media/video/m2m-deinterlace.c | 1131 +
3 files changed, 1141 insertions(+)
create mode 100644 drivers/media/video/m2m-deinterlace.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9cebf7b..c0b9233 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1188,6 +1188,14 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_MEM2MEM_DEINTERLACE
+ tristate "Deinterlace support"
+ depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ Generic deinterlacing V4L2 driver.
+
config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a04c307..b6a01b1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -189,6 +189,8 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
+
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
diff --git a/drivers/media/video/m2m-deinterlace.c
b/drivers/media/video/m2m-deinterlace.c
new file mode 100644
index 000..4187c80
--- /dev/null
+++ b/drivers/media/video/m2m-deinterlace.c
@@ -0,0 +1,1131 @@
+/*
+ * V4L2 deinterlacing support.
+ *
+ * Copyright (c) 2012 Vista Silicon S.L.
+ * Javier Martin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define MEM2MEM_TEST_MODULE_NAME "mem2mem-deinterlace"
+
+MODULE_DESCRIPTION("mem2mem device which supports deinterlacing using
dmaengine");
+MODULE_AUTHOR("Javier Martin v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+struct deinterlace_fmt {
+ char*name;
+ u32 fourcc;
+ enum v4l2_field field;
+ /* Types the format can be used for */
+ u32 types;
+};
+
+static struct deinterlace_fmt formats[] = {
+ {
+ .name = "YUV 4:2:0 Planar (weaving)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_INTERLACED_TB,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUV 4:2:0 Planar (weaving)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_INTERLACED_BT,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUV 4:2:0 Planar (line doubling)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ /* Line doubling, top field */
+ .field = V4L2_FIELD_NONE,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUYV 4:2:2 (weaving)",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_INTERLACED_TB,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUYV 4:2:2 (weaving)",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_INTERLACED_BT,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUYV 4:2:2 (line doubling)",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ /* Line doubling, top field */
+ .field = V4L2_FIELD_NONE,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUV 4:2:0 Planar (top-bottom)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_SEQ_TB,
+ .types = MEM2MEM_OUTPUT,
+ },
+ {
+ .name = "YUYV 4:2:2 (top-bottom
Re: [PATCH 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
On Wed 11 July 2012 20:37:14 Hans de Goede wrote: > Hi Hans, > > On 07/11/2012 08:01 PM, Hans Verkuil wrote: > > Hi Hans, > > > > Thanks for the patch. > > > > I've CC-ed Halli as well. > > > > On Wed July 11 2012 17:47:34 Hans de Goede wrote: > >> To allow apps to limit a hw-freq-seek to a specific band, for further > >> info see the documentation this patch adds for these new fields. > >> > >> Signed-off-by: Hans de Goede > >> --- > >> .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 > >> > >> include/linux/videodev2.h |5 ++- > >> 2 files changed, 40 insertions(+), 9 deletions(-) > >> > >> diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > >> b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > >> index f4db44d..50dc9f8 100644 > >> --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > >> +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > >> @@ -52,11 +52,21 @@ > >> Start a hardware frequency seek from the current frequency. > >> To do this applications initialize the tuner, > >> type, seek_upward, > >> -spacing and > >> -wrap_around fields, and zero out the > >> -reserved array of a &v4l2-hw-freq-seek; and > >> -call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer > >> -to this structure. > >> +wrap_around, > >> spacing, > >> +rangelow and > >> rangehigh > >> +fields, and zero out the reserved array of a > >> +&v4l2-hw-freq-seek; and call the > >> VIDIOC_S_HW_FREQ_SEEK > >> +ioctl with a pointer to this structure. > >> + > >> +The rangelow and > >> +rangehigh fields can be set to a non-zero > >> value to > >> +tell the driver to search a specific band. If the &v4l2-tuner; > >> +capability field has the > >> +V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values > >> +must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If > >> +the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set, > >> +then these values must exactly match those of one of the bands returned by > >> +&VIDIOC-ENUM-FREQ-BANDS;. > > > > OK, I have some questions here: > > > > 1) If you have a multiband tuner, what should happen if both low and high > > are > > zero? Currently it is undefined, other than that the seek should start from > > the current frequency until it reaches some limit. > > That would be driver specific, we could add the same "If rangelow/high is zero > a reasonable default value is used." language as used for the spacing. For > example for the si470x if both are zero I simply switch to the "Japan wide" > band which covers all frequencies handled by the other bands, but if there > is no such covers all ranges band, then the logical thing todo would just keep > the band as is (so as determined by the last s_freq). > > > Halli, what does your hardware do? In particular, is the hwseek limited by > > the > > US/Europe or Japan band range or can it do the full range? If I'm not > > mistaken > > it is the former, right? > > > > If it is the former, then you need to explicitly set low + high to ensure > > that > > the hwseek uses the correct range because the driver can't guess which of > > the > > overlapping bands to use. > > > > 2) What happens if the current frequency is outside the low/high range? The > > hwseek spec says that the seek starts from the current frequency, so that > > might > > mean that hwseek returns -ERANGE in this case. > > What the si470x code currently does is just clamp the frequency to the new > range before seeking, but -ERANGE works for me too. Clamping is a better idea IMHO as long as it is documented. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
These flags are not used any longer and can be safely removed since the following patch: http://www.spinics.net/lists/linux-media/msg50165.html Signed-off-by: Javier Martin --- arch/arm/plat-mxc/include/mach/mx2_cam.h |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h b/arch/arm/plat-mxc/include/mach/mx2_cam.h index 3c080a3..7ded6f1 100644 --- a/arch/arm/plat-mxc/include/mach/mx2_cam.h +++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h @@ -23,7 +23,6 @@ #ifndef __MACH_MX2_CAM_H_ #define __MACH_MX2_CAM_H_ -#define MX2_CAMERA_SWAP16 (1 << 0) #define MX2_CAMERA_EXT_VSYNC (1 << 1) #define MX2_CAMERA_CCIR(1 << 2) #define MX2_CAMERA_CCIR_INTERLACE (1 << 3) @@ -31,7 +30,6 @@ #define MX2_CAMERA_GATED_CLOCK (1 << 5) #define MX2_CAMERA_INV_DATA(1 << 6) #define MX2_CAMERA_PCLK_SAMPLE_RISING (1 << 7) -#define MX2_CAMERA_PACK_DIR_MSB(1 << 8) /** * struct mx2_camera_platform_data - optional platform data for mx2_camera -- 1.7.9.5 -- 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] media: mx2_camera: Add YUYV output format.
Add explicit conversions from UYVY and YUYV to YUYV so that
csicr1 configuration can be set properly for each format.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 0f01e7b..2a33bcb 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -337,6 +337,34 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
}
},
{
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
+ PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_SWAP16_EN,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
+ PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
.in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
.out_fmt= V4L2_PIX_FMT_YUV420,
.cfg= {
@@ -1146,6 +1174,18 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
}
}
+ if (code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ formats++;
+ if (xlate) {
+ xlate->host_fmt =
+ soc_mbus_get_fmtdesc(V4L2_MBUS_FMT_YUYV8_2X8);
+ xlate->code = code;
+ dev_dbg(dev, "Providing host format %s for sensor code
%d\n",
+ xlate->host_fmt->name, code);
+ xlate++;
+ }
+ }
+
/* Generic pass-trough */
formats++;
if (xlate) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media system Summit
Hi Mauro, On 07/12/2012 05:18 AM, Mauro Carvalho Chehab wrote: > Em 11-07-2012 05:09, James Bottomley escreveu: >> Hi All, >> >> We have set aside the second day of the kernel summit (Tuesday 28 >> August) as mini-summit day. So far we have only the PCI mini summit on >> this day > > Not sure what happened (or maybe my proposal were not clear enough), but > I've submitted a proposal to have a media system summit on KS/2011. > Last year was very productive for media developers, so we'd like to do > it again ;) > > > Message-ID:<4fec74ab.6070...@redhat.com> > Date: Thu, 28 Jun 2012 12:13:47 -0300 > From: Mauro Carvalho Chehab > > [Ksummit-2012-discuss] [ATTEND] media subsystem > > I'd like to have media subsystem discussions this year's at kernel summit. > The media subsystem is one of the most active driver subsystem, and there are > lots of > things there that require face-to-face discussions, not only between > subsystem developers, > but also with other maintainers. In special, during KS/2011, it was > identified the need > of interacting with video and audio system people, in order to solve some > common issues, > like HDMI CEC and audio/video synchronization. > > The increasing complexity of SoC designs used by media devices requires API > extensions at the media APIs in order to proper expose and control all > hardware > functionality on a standard way. A new API to better allow negotiating > userspace > and Kernelspace capabilities seem to be required. > > More discussions with regards to shared resources locking is needed, on > devices that > implement multiple API's, but not a the same time. > > The incompatibility between udev-182 and the existing drivers will also > require lots > of discussions, as that affects 64 media drivers, and changing them to comply > with > the current requirement of using request_firmware_nowait() won't work on > several > drivers. So, a solution (or a set of solutions) needs to be found, in order > to fix > such incompatibility. I'd like to add a "Common device tree bindings for media devices" topic to the agenda for consideration. There were some activities on creating device tree bindings for Samsung and SH Mobile SoCs but this didn't really kick off yet and a face to face discussions could help to bring device tree support in media subsystem to the level many other subsystems already have. -- Thanks, Sylwester -- 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: Make menuconfig doesn't work anymore
2012/7/12 VDR User : > No, the drivers I need were already there but I just checked my > menuconfig and I see: > Multimedia support -> Customize TV tuners -> NXP TDA18212 silicon tuner > > Is that what you're looking for? If so, all you need, I think, is "DVB > for Linux" and "Customize analog and hybrid tuner modules to build" to > get the "Customize TV tuners" option. Thanks for the input, but that's not the driver I need. I need the ddbridge compatible (?) driver, NXP TDA18212 DD [*] DVB/ATSC adapters Digital Devices bridge support [*] Customse the frontend modules to build Customize DVB Frontends → STV 0367 (DD) NXP TDA18212 silicon tuner (DD) -- 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
