Re: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface
On Wednesday, 23 March 2011, at 11:00:06, Guennadi Liakhovetski wrote:
> Hi Janusz
>
> You might want to retest ams-delta with the camera on the current
> (next or
>
> git://linuxtv.org/media_tree.git staging/for_v2.6.39
>
> ) kernel - I suspect, you'll need something similar to
>
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructu
> re/30728
Hi Guennadi,
Thanks for bringing this issue to my attention. However, we alread have
something like
.dev= {
...
.coherent_dma_mask = DMA_BIT_MASK(32),
},
defined inside the platform_device structure registered for our OMAP1
camera device, so shouldn't be affected.
Anyway, I have the camera driver review/upgrade task already sitting in
my todo list for a few weeks, and hope to find some spare time to deal
with it soon, so will verify that as well.
Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] soc-camera: one more patch
Hi Mauro Sorry, would be nice if we could manage to push one more patch for 2.6.39: The following changes since commit f772f016e15a0b93b5aa9680203107ab8cb9bdc6: [media] media-devnode: don't depend on BKL stuff (2011-03-22 19:43:01 -0300) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.39 Guennadi Liakhovetski (1): V4L: soc_camera_platform: add helper functions to manage device instances include/media/soc_camera_platform.h | 50 +++ 1 files changed, 50 insertions(+), 0 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Mar 23 19:00:39 CET 2011 git hash:f772f016e15a0b93b5aa9680203107ab8cb9bdc6 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS 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.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS 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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: S2-3200 switching-timeouts on 2.6.38
Hi list, Follow up to: [1] @Manu: Your argumentation is inconsistent and lacks any proof. Running a full scan of Astra 19.2 E with Kaffeine together with cards model Skystar HD and Twinhan/Azurewave VP-1041 results in a channel list of approx 400 stations only. When I apply my patch then almost all stations are found: patch in tuner: 400 stations found, not usable, patch in tuner + demod: 1127 stations found, better but less than without tuner patch. patch in demod only: 1145 stations found, slightly more than with tuner patch. This proves that the patch in demod stb0899 is still a mandatory must. Discussions in vdr-portal.de [2] have shown that this patch solved the year old problems with these cards for everybody. My conjecture is that maybe your patch in the code of stb6100 tuner might improve the situation for weak signals. With high signal levels as seen from Astra 19.2 the modification of the tuner code does not show any positive effect, while the cards without my patch in the demodulator code are not usable at all!! So I kindly ask to include this patch. Thanks and best regards H .Ellenberger [1] http://www.spinics.net/lists/linux-media/msg30490.html [2] http://www.vdr-portal.de/board/thread.php?threadid=99603 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" wrote: > Hi Dave, > > On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrote: > > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: > >> Adding support for common EDID parsing in kernel. > >> > >> EDID - Extended display identification data is a data structure provided by > >> a digital display to describe its capabilities to a video source, This a > >> standard supported by CEA and VESA. > >> > >> There are several custom implementations for parsing EDID in kernel, some > >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > >> parsing of EDID should be done in a library, which is agnostic of the > >> framework (V4l2, DRM, FB) which is using the functionality, just based on > >> the raw EDID pointer with size/segment information. > >> > >> With other RFC's such as the one below, which tries to standardize HDMI > >> API's > >> It would be better to have a common EDID code in one place.It also helps to > >> provide better interoperability with variety of TV/Monitor may be even by > >> listing out quirks which might get missed with several custom > >> implementation > >> of EDID. > >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > >> > >> This patch tries to add functions to parse some portion EDID (detailed > >> timing, > >> monitor limits, AV delay information, deep color mode support, Audio and > >> VSDB) > >> If we can align on this library approach i can enhance this library to > >> parse > >> other blocks and probably we could also add quirks from other > >> implementation > >> as well. > >> > > > > If you want to take this approach, you need to start from the DRM EDID > > parser, > > its the most well tested and I can guarantee its been plugged into more > > monitors > > than any of the others. There is just no way we would move the DRM parser > > to a > > library one that isn't derived from it + enhancements, as we'd throw away > > the > > years of testing and the regression count would be way too high. > > > I had a look at the DRM EDID code, but for quirks it looks pretty much the > same. > yes i could take quirks and other DRM tested code and enhance, but > still the code has to do away with struct drm_display_mode > which is very much custom to DRM. If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need. Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code. Do you really think the differences between your code and the existing DRM code are irreconcilable? -- Jesse Barnes, Intel Open Source Technology Center -- 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: Future desktop on dumb frame buffers?
On 21 March 2011 21:08, Alex Deucher wrote: > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven > wrote: >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote: >>> On Mon, 21 Mar 2011 19:19:43 + >>> timofonic timofonic wrote: So if KMS is so cool and provides many advantages over fbdev and such... Why isn't more widely used intead of still relying on fbdev? Why still using fbdev emulation (that is partial and somewhat broken, it seems) instead using KMS directly? >>> >>> Used by what? All three major GPU device classes have KMS support >>> (Intel, ATI, and nVidia). If you want it for a particular device, you >>> can always port it over. >> >> The three major GPU device classes on PC... > > Sadly it gets worse. A lot of the SoC vendors are adding an fbdev > emulation layer on top of v4l rather than using fbdev directly or > using KMS and v4l has grown it's own edid, hdmi, and cec handling. > I agree, it is sad that as a SoC vendor there are different kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say a Display controller driver. One must also remember that there are big differences between a desktop/PC multimedia/graphics system and the ones present on an embedded SoC. It is two very different cultures and HW designs now trying to merge into one Linux Kernel. Of course there will be some overlaps but I believe it can be sorted out as soon as we understand each others different possibilities/limitations. Doing duplicate work like HDMI will not benefit any party. Just to list some of the differences. - Developments within V4L2 has mainly been driven by embedded devices while DRM is a result of desktop Graphics cards. And for some extent also solving different problems. - Embedded devices usually have several different hw IP's managing displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, 2D blitters, Open GL ES hw, all of which have a separate device/driver in the kernel, while on a desktop nowadays all this functionality usually resides on ONE graphics card, hence one DRM device for all. - DRM is closely developed in conjunction with desktop/Xorg, while X11 on an embedded device is not very 2011...wayland on the other hand is :-), but do wayland really need the full potential of DRM/DRI or just parts of it. - Copying buffers is really bad for embedded devices due to lower memory bandwidth and power consumption while on a Desktop memory bandwidth is from an other galaxy (copying still bad but accepted it seems), AND embedded devices of today records and plays/displays 1080p content as well. - Not all embedded devices have MMU's for each IP requiring physical contiguous memory, while on a desktop MMU's have been present for ages. - Embedded devices are usually ARM based SoCs while x86 dominates the Desktop/Laptop market, and functionality provided is soon the very same. - yada yadaThe list can grow very longThere are also similarities of course. The outcome is that SoC vendors likes the embedded friendliness of v4l2 and fbdev while "we" also glance at the DRM part due to its de-facto standard on desktop environments. But from an embedded point of view DRM lacks the support for interconnecting multiple devices/drivers mentioned above, GEM/TTM is valid within a DRM device, the execution/context management is not needed,, no overlays(or similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but the rest of DRM will likely not be heavily used on SoCs unless running X11 as well. Most likely this worked on as well within the DRI community. I can see good features all over the place(sometimes duplicated) but not find one single guideline/API that solves all the embedded SoC problems (which involves use-cases optimized for no-copy cross media/drivers). Last but not least... On Linaro there is already discussions ongoing to solve one of the biggest issues from a SoC point of view and that is a "System Wide Memory manager" which manages buffer sharing and resolves no-copy use cases between devices/drivers. Read more on the following thread: http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html. BR /Robert Fekete st-ericsson -- 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] ARM: mach-shmobile: add coherent DMA mask to CEU camera devices
On Wed, Mar 23, 2011 at 10:29:16AM +0100, Guennadi Liakhovetski wrote: > Cameras are currently broken on ARM sh-mobile platforms. They need a > suitable coherent DMA mask. > > Signed-off-by: Guennadi Liakhovetski Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
Hi Paul, On Tue, Mar 22, 2011 at 11:28 PM, Paul Mundt wrote: > On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote: >> Em 22-03-2011 14:32, Mythri P K escreveu: >> > Adding support for common EDID parsing in kernel. >> > >> > EDID - Extended display identification data is a data structure provided by >> > a digital display to describe its capabilities to a video source, This a >> > standard supported by CEA and VESA. >> > >> > There are several custom implementations for parsing EDID in kernel, some >> > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally >> > parsing of EDID should be done in a library, which is agnostic of the >> > framework (V4l2, DRM, FB) which is using the functionality, just based on >> > the raw EDID pointer with size/segment information. >> > >> > With other RFC's such as the one below, which tries to standardize HDMI >> > API's >> > It would be better to have a common EDID code in one place.It also helps to >> > provide better interoperability with variety of TV/Monitor may be even by >> > listing out quirks which might get missed with several custom >> > implementation >> > of EDID. >> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 >> > >> > This patch tries to add functions to parse some portion EDID (detailed >> > timing, >> > monitor limits, AV delay information, deep color mode support, Audio and >> > VSDB) >> > If we can align on this library approach i can enhance this library to >> > parse >> > other blocks and probably we could also add quirks from other >> > implementation >> > as well. >> > >> > Signed-off-by: Mythri P K >> > --- >> > arch/arm/include/asm/edid.h | 243 ++ >> > drivers/video/edid.c | 340 >> > +++ >> >> Hmm... if you want this to be agnostic, the header file should not be inside >> arch/arm, but on some other place, like include/video/. >> > Ironically this adds a drivers/video/edid.c but completely ignores > drivers/video/edid.h which already exists and already contains many of > these definitions. > > I like the idea of a generalized library, but it would be nice to see the > existing edid.h evolved and its users updated incrementally. > well yes , That could be enhanced and that would take care of Mauro's comment too. Thanks and regards, Mythri. -- 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
OMAP3 isp single-shot
Hello, I am successfully using the gumstix overo board together with a camera sensor Aptina MT9V034 with the kernel 2.6.35 and patches from http://git.linuxtv.org/pinchartl/media.git (isp6). I can use the media-ctl program and yavta to take pictures in continous streaming mode. media-ctl -r -l '"mt9034 3-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' media-ctl -f '"mt9v034 3-0048":0[SGRBG10 752x480], "OMAP3 ISP CCDC":1[SGRBG10 752x480] and then: yavta -f SGRBG10 -s 752x480 -n 1 --capture=1 -F /dev/video2 Is there a way to set the ISP in single shot mode? I have tested setting the mt9v034 in snapshot mode and manually trigger the camera, but the ISP does not send a picture. Is there a way to solve this with the current OMAP3 isp code? I have before successfully used the isp parts from the Nokia N900 project.. /Daniel -- 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] zoran: Drop unused module parameters encoder and decoder
The ability to force the encoder or decoder chip was broken by commit
0ab6e1c38d80ab586e3a1ca9e71844131d9f51dc in February 2009. As nobody
complained for over 2 years, I take it that these parameters were no
longer used so we can simply drop them.
Signed-off-by: Jean Delvare
Cc: Hans Verkuil
---
Documentation/video4linux/Zoran|1 -
drivers/media/video/zoran/zoran_card.c |8
2 files changed, 9 deletions(-)
--- linux-2.6.39-rc0.orig/Documentation/video4linux/Zoran 2011-03-23
10:34:22.0 +0100
+++ linux-2.6.39-rc0/Documentation/video4linux/Zoran2011-03-23
13:21:22.0 +0100
@@ -130,7 +130,6 @@ Card number: 4
Note: No module for the mse3000 is available yet
Note: No module for the vpx3224 is available yet
-Note: use encoder=X or decoder=X for non-default i2c chips
===
--- linux-2.6.39-rc0.orig/drivers/media/video/zoran/zoran_card.c
2011-03-21 17:46:15.0 +0100
+++ linux-2.6.39-rc0/drivers/media/video/zoran/zoran_card.c 2011-03-23
13:21:22.0 +0100
@@ -64,14 +64,6 @@ static int card[BUZ_MAX] = { [0 ... (BUZ
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, "Card type");
-static int encoder[BUZ_MAX] = { [0 ... (BUZ_MAX-1)] = -1 };
-module_param_array(encoder, int, NULL, 0444);
-MODULE_PARM_DESC(encoder, "Video encoder chip");
-
-static int decoder[BUZ_MAX] = { [0 ... (BUZ_MAX-1)] = -1 };
-module_param_array(decoder, int, NULL, 0444);
-MODULE_PARM_DESC(decoder, "Video decoder chip");
-
/*
The video mem address of the video card.
The driver has a little database for some videocards
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
Hi Dave, On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrote: > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: >> Adding support for common EDID parsing in kernel. >> >> EDID - Extended display identification data is a data structure provided by >> a digital display to describe its capabilities to a video source, This a >> standard supported by CEA and VESA. >> >> There are several custom implementations for parsing EDID in kernel, some >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally >> parsing of EDID should be done in a library, which is agnostic of the >> framework (V4l2, DRM, FB) which is using the functionality, just based on >> the raw EDID pointer with size/segment information. >> >> With other RFC's such as the one below, which tries to standardize HDMI API's >> It would be better to have a common EDID code in one place.It also helps to >> provide better interoperability with variety of TV/Monitor may be even by >> listing out quirks which might get missed with several custom implementation >> of EDID. >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 >> >> This patch tries to add functions to parse some portion EDID (detailed >> timing, >> monitor limits, AV delay information, deep color mode support, Audio and >> VSDB) >> If we can align on this library approach i can enhance this library to parse >> other blocks and probably we could also add quirks from other implementation >> as well. >> > > If you want to take this approach, you need to start from the DRM EDID parser, > its the most well tested and I can guarantee its been plugged into more > monitors > than any of the others. There is just no way we would move the DRM parser to a > library one that isn't derived from it + enhancements, as we'd throw away the > years of testing and the regression count would be way too high. > I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM. > Dave. > Thanks and regards, Mythri. -- 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] omap3isp: implement ENUM_FMT
Hi Michael, On Wednesday 23 March 2011 12:07:12 Michael Jones wrote: > On 03/23/2011 10:52 AM, Sakari Ailus wrote: > > Michael Jones wrote: > >> From dccbd4a0a717ee72a3271075b1e3456a9c67ca0e Mon Sep 17 00:00:00 2001 > >> From: Michael Jones > >> Date: Tue, 22 Mar 2011 11:47:22 +0100 > >> Subject: [PATCH] omap3isp: implement ENUM_FMT > >> > >> Whatever format is currently being delivered will be declared as the > >> only possible format > >> > >> Signed-off-by: Michael Jones > >> --- > >> > >> Some V4L2 apps require ENUM_FMT, which is a mandatory ioctl for V4L2. > >> This patch doesn't enumerate all of the formats which could possibly be > >> set (as is intended by ENUM_FMT), but at least it reports the one that > >> is currently set. > > > > What would be the purpose of ENUM_FMT in this case? It provides no > > additional information to user space, and the information it provides is > > in fact incomplete. Using other formats is possible, but that requires > > changes to the format configuration on links. > > The only purpose of it was to provide minimum functionality for apps to > be able to fetch frames from the ISP after setting up the ISP pipeline > with media-ctl. By "apps", I mean Gstreamer in my case, which Loïc had > also recently asked Laurent about. > > > As the relevant format configuration is done on the subdevs and not on > > the video nodes, the format configuration on the video nodes is very > > limited and much affected by the state of the formats on the subdev pads > > (which I think is right). This is not limited to ENUM_FMT but all format > > related IOCTLs on the OMAP 3 ISP driver. > > > > My view is that should a generic application want to change (or > > enumerate) the format(s) on a video node, the application would need to > > be using libv4l for that. > > > > A compatibility layer implemented in libv4l (plugin, not the main > > library) needs to configure the links in the first place, so > > implementing ENUM_FMT in the plugin would not be a big deal. It could > > even provide useful information. The possible results of the ENUM_FMT > > would also depend on what kind of pipeline configuration does the plugin > > support, though. > > BTW, my GStreamer is using libv4l, although it looked like it's also > possible to configure GStreamer to use ioctls directly. I can agree > that it would be nice to implement ENUM_FMT and the like in a > compatibility layer in libv4l. That would be in the true spirit of > ENUM_FMT, where the app could actually see different formats it can set. > > But is there any work being done on such a compatibility layer? > > Is there a policy decision that in the future, apps will be required to > use libv4l to get images from the ISP? Are we not intending to support > using e.g. media-ctl + some v4l2 app, as I'm currently doing during > development? Apps should be able to use the V4L2 API directly. However, we can't implement all that API, as most calls don't make sense for the OMA3 ISP driver. Which calls need to be implemented is a grey area at the moment, as there's no detailed semantics on how subdev-level configuration and video device configuration should interact. Your implementation of ENUM_FMT looks correct to me, but the question is whether ENUM_FMT should be implemented. I don't think ENUM_FMT is a required ioctl, so maybe v4l2src shouldn't depend on it. I'm interesting in getting Hans' opinion on this. > In the meantime, I will continue using this patch locally to enable > getting a live image with Gstreamer, and it can at least serve as a help > to Loïc if he's trying to do the same. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] v4l: add fourcc definitons for compressed formats.
(Added Ben to the CC list so he can look at this from the solo6x10
perspective).
On Wednesday, March 23, 2011 12:09:33 Kamil Debski wrote:
> Add fourcc definitions for the following compressed formats:
> H264, H264 without start codes, MPEG1/2/4 ES, DIVX versions
> 3.11, 4, 5.0-5.0.2, 5.03 and up, XVID, VC1 Simple/Main Profile
> and VC1 Advanced profile.
> ---
> Hi,
>
> During the v4l2 brain storming meeting in Warsaw one of the topics was
assigning
> fourcc values for compressed elementary streams.
All these fourcc values are for compressed elementary *video* streams, right?
Because you can also have elementary audio streams (the conexant MPEG encoders
can deliver that, although that isn't implemented in the ivtv/cx18 drivers).
>
> I did some research - which included checking the VC1 and DivX formats. For
> other codecs: Xvid, MPEG1/2/4 and H263 the choice of fourcc values was
clear.
> We have also had discussion regarding the H264 codec, which resulted in
having
> two fourccs - one with start codes and one without.
>
> *** MPEG ***
> 'MPEG' fourcc will remain reserved for transport/program streams. For
elementary
> MPEG streams the proposed fourccs are:
> * 'MPG1' for MPEG1
> * 'MPG2' for MPEG2
> * 'MPG4' for MPEG4
>
> *** H263 ***
> For H263 the ‘H263’ fourcc value is reasonable.
>
> *** Xvid ***
> ‘XVID’ fourcc seems a good choice.
>
> *** H264 ***
> H264 elementary stream can come in two flavours: one with start codes and
one
> without. Following fourccs are proposed:
> * 'H264' for NALUs with start codes (start codes are a fixed pattern used to
> locate packet boundaries). [1]
> * 'AVC1' for NALUs without start codes (framing needs to be provided out of
> band, for instance by providing a length field for each packet). [1]
>
> Links:
> [1] http://msdn.microsoft.com/en-us/library/dd757808%28v=vs.85%29.aspx
>
> *** VC1 ***
> VC1 streams have different content based on the profile. VC1 Advanced
profile
> has start codes and Main and Simple profile relies on the Transport Layer to
> provide frame start and length. For VC1 AP the stream content is defined
> Annex E. For VC1 SP and MP the streamz by Annex J and Annex L of the SMPTE
421M.
>
> "In the advanced profile, pictures and slices shall be byte-aligned and
carried
> in a bitstream data unit (as described in Annex E). Each new picture or a
slice,
> is detected via start-codes as defined in Annex E. In the simple and main
> profiles,pictures shall be byte-aligned. For each coded picture, the pointer
to
> the coded bitstream, and its size shall be communicated to the decoder by
the
> Transport Layer. In simple and main profiles, a picture whose coded size is
less
> than or equal to one byte shall be considered to be a skipped picture."
> SMPTE 421M Draft [2]
>
> Following fourccs are proposed:
> * 'WVC1' for VC1 Advanced Profile [1]
> * 'WMV3' for VC1 Main and Simple profiles [1]
>
> Links:
> [1] http://wiki.multimedia.cx/index.php?title=VC1 - Fourccs used by
Microsoft
> [2] http://multimedia.cx/mirror/s421m.pdf - Proposed SMPTE Standard
>
> *** DivX ***
> It is reasonable that versions 3.11, 4 and 5 should have different fourccs.
> According to the document I have, there also were important changes and
bugfixes
> done in DivX 5.0.3. Hence I propose to have a separate fourcc for DivX
versions
> 5.0.0-5.0.2.
>
> Following fourccs are proposed:
> * 'DIV3' for DivX 3.11
> * 'DIV4' for DivX 4.x
> * 'DX50' for Divx 5.0.0-5.0.2
> * 'DIV5' for Divx 5.0.3 and newer
>
> There are quite a few differences between versions 5.0 - 5.02 and 5.0.3.
Those
> include:
> - quarter pixel motion compensation follows the algorithm described in the
> Corrigendum 2 of the ISO/IEC 14496-2 document. (versions prior to 5.0.3
had
> used the algorithm described in a previous document)
> - new deringing algorithm
> - motion vectors are stored in a different way
>
> I appreciate your comments.
Looks good. I think the spec also needs to be updated with the new fourcc's
(of course), but also the distinction between multiplexed and elementary
streams should be clarified. A note should be added to the STREAM_TYPE and
AUDIO_ENCODING/VIDEO_ENCODING controls that those are specific to multiplexed
streams only.
Regards,
Hans
>
> Best regards,
> --
> Kamil Debski
> Linux Platform Group
> Samsung Poland R&D Center
> ---
> include/linux/videodev2.h | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index aa6c393..5d80e95 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -372,6 +372,19 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
>
*/
> #define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
>
*/
> #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
>
*/
> +#define V4L2_PIX_FMT_H264 v4l2
[RFC/PATCH] v4l: add fourcc definitons for compressed formats.
Add fourcc definitions for the following compressed formats:
H264, H264 without start codes, MPEG1/2/4 ES, DIVX versions
3.11, 4, 5.0-5.0.2, 5.03 and up, XVID, VC1 Simple/Main Profile
and VC1 Advanced profile.
---
Hi,
During the v4l2 brain storming meeting in Warsaw one of the topics was assigning
fourcc values for compressed elementary streams.
I did some research - which included checking the VC1 and DivX formats. For
other codecs: Xvid, MPEG1/2/4 and H263 the choice of fourcc values was clear.
We have also had discussion regarding the H264 codec, which resulted in having
two fourccs - one with start codes and one without.
*** MPEG ***
'MPEG' fourcc will remain reserved for transport/program streams. For elementary
MPEG streams the proposed fourccs are:
* 'MPG1' for MPEG1
* 'MPG2' for MPEG2
* 'MPG4' for MPEG4
*** H263 ***
For H263 the ‘H263’ fourcc value is reasonable.
*** Xvid ***
‘XVID’ fourcc seems a good choice.
*** H264 ***
H264 elementary stream can come in two flavours: one with start codes and one
without. Following fourccs are proposed:
* 'H264' for NALUs with start codes (start codes are a fixed pattern used to
locate packet boundaries). [1]
* 'AVC1' for NALUs without start codes (framing needs to be provided out of
band, for instance by providing a length field for each packet). [1]
Links:
[1] http://msdn.microsoft.com/en-us/library/dd757808%28v=vs.85%29.aspx
*** VC1 ***
VC1 streams have different content based on the profile. VC1 Advanced profile
has start codes and Main and Simple profile relies on the Transport Layer to
provide frame start and length. For VC1 AP the stream content is defined
Annex E. For VC1 SP and MP the streamz by Annex J and Annex L of the SMPTE 421M.
"In the advanced profile, pictures and slices shall be byte-aligned and carried
in a bitstream data unit (as described in Annex E). Each new picture or a slice,
is detected via start-codes as defined in Annex E. In the simple and main
profiles,pictures shall be byte-aligned. For each coded picture, the pointer to
the coded bitstream, and its size shall be communicated to the decoder by the
Transport Layer. In simple and main profiles, a picture whose coded size is less
than or equal to one byte shall be considered to be a skipped picture."
SMPTE 421M Draft [2]
Following fourccs are proposed:
* 'WVC1' for VC1 Advanced Profile [1]
* 'WMV3' for VC1 Main and Simple profiles [1]
Links:
[1] http://wiki.multimedia.cx/index.php?title=VC1 - Fourccs used by Microsoft
[2] http://multimedia.cx/mirror/s421m.pdf - Proposed SMPTE Standard
*** DivX ***
It is reasonable that versions 3.11, 4 and 5 should have different fourccs.
According to the document I have, there also were important changes and bugfixes
done in DivX 5.0.3. Hence I propose to have a separate fourcc for DivX versions
5.0.0-5.0.2.
Following fourccs are proposed:
* 'DIV3' for DivX 3.11
* 'DIV4' for DivX 4.x
* 'DX50' for Divx 5.0.0-5.0.2
* 'DIV5' for Divx 5.0.3 and newer
There are quite a few differences between versions 5.0 - 5.02 and 5.0.3. Those
include:
- quarter pixel motion compensation follows the algorithm described in the
Corrigendum 2 of the ISO/IEC 14496-2 document. (versions prior to 5.0.3 had
used the algorithm described in a previous document)
- new deringing algorithm
- motion vectors are stored in a different way
I appreciate your comments.
Best regards,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center
---
include/linux/videodev2.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..5d80e95 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -372,6 +372,19 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
*/
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
*/
+#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
start codes */
+#define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264
without start codes */
+#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263
*/
+#define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES
*/
+#define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES
*/
+#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /* MPEG-4 ES
*/
+#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /* DivX 3.11
*/
+#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /* DivX 4.12
*/
+#define V4L2_PIX_FMT_DIVX500 v4l2_fourcc('D', 'X', '5', '0') /* DivX 5.00 -
5.02 */
+#define V4L2_PIX_FMT_DIVX5v4l2_fourcc('D', 'I', 'V', '5') /* DivX 5.03 - x
*/
+#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid
*/
+#define V4L2_PIX_FMT_VC1 v4l2_fo
Re: [PATCH] omap3isp: implement ENUM_FMT
Hi Sakari, On 03/23/2011 10:52 AM, Sakari Ailus wrote: > Hi Michael, > > Thanks for the patch. > > Michael Jones wrote: >> From dccbd4a0a717ee72a3271075b1e3456a9c67ca0e Mon Sep 17 00:00:00 2001 >> From: Michael Jones >> Date: Tue, 22 Mar 2011 11:47:22 +0100 >> Subject: [PATCH] omap3isp: implement ENUM_FMT >> >> Whatever format is currently being delivered will be declared as the only >> possible format >> >> Signed-off-by: Michael Jones >> --- >> >> Some V4L2 apps require ENUM_FMT, which is a mandatory ioctl for V4L2. >> This patch doesn't enumerate all of the formats which could possibly be >> set (as is intended by ENUM_FMT), but at least it reports the one that >> is currently set. > > What would be the purpose of ENUM_FMT in this case? It provides no > additional information to user space, and the information it provides is > in fact incomplete. Using other formats is possible, but that requires > changes to the format configuration on links. The only purpose of it was to provide minimum functionality for apps to be able to fetch frames from the ISP after setting up the ISP pipeline with media-ctl. By "apps", I mean Gstreamer in my case, which Loïc had also recently asked Laurent about. > > As the relevant format configuration is done on the subdevs and not on > the video nodes, the format configuration on the video nodes is very > limited and much affected by the state of the formats on the subdev pads > (which I think is right). This is not limited to ENUM_FMT but all format > related IOCTLs on the OMAP 3 ISP driver. > > My view is that should a generic application want to change (or > enumerate) the format(s) on a video node, the application would need to > be using libv4l for that. > > A compatibility layer implemented in libv4l (plugin, not the main > library) needs to configure the links in the first place, so > implementing ENUM_FMT in the plugin would not be a big deal. It could > even provide useful information. The possible results of the ENUM_FMT > would also depend on what kind of pipeline configuration does the plugin > support, though. BTW, my GStreamer is using libv4l, although it looked like it's also possible to configure GStreamer to use ioctls directly. I can agree that it would be nice to implement ENUM_FMT and the like in a compatibility layer in libv4l. That would be in the true spirit of ENUM_FMT, where the app could actually see different formats it can set. But is there any work being done on such a compatibility layer? Is there a policy decision that in the future, apps will be required to use libv4l to get images from the ISP? Are we not intending to support using e.g. media-ctl + some v4l2 app, as I'm currently doing during development? In the meantime, I will continue using this patch locally to enable getting a live image with Gstreamer, and it can at least serve as a help to Loïc if he's trying to do the same. > > (Cc Yordan and Hans.) > > I discussed this with Laurent initially and the conclusion was that more > discussion is required. :-) Hans: do you have an opinion on this? > > Best regards, > thanks for the discussion, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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] radio: wl128x: Update registration process with ST.
From: Manjunatha Halli
As underlying ST driver registration API's have changed with
latest 2.6.38-rc8 kernel this patch will update the FM driver
accordingly.
Signed-off-by: Manjunatha Halli
---
drivers/media/radio/wl128x/fmdrv_common.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
b/drivers/media/radio/wl128x/fmdrv_common.c
index 96a95c5..b09b283 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -1494,12 +1494,17 @@ u32 fmc_prepare(struct fmdev *fmdev)
}
memset(&fm_st_proto, 0, sizeof(fm_st_proto));
- fm_st_proto.type = ST_FM;
fm_st_proto.recv = fm_st_receive;
fm_st_proto.match_packet = NULL;
fm_st_proto.reg_complete_cb = fm_st_reg_comp_cb;
fm_st_proto.write = NULL; /* TI ST driver will fill write pointer */
fm_st_proto.priv_data = fmdev;
+ fm_st_proto.chnl_id = 0x08;
+ fm_st_proto.max_frame_size = 0xff;
+ fm_st_proto.hdr_len = 1;
+ fm_st_proto.offset_len_in_hdr = 0;
+ fm_st_proto.len_size = 1;
+ fm_st_proto.reserve = 1;
ret = st_register(&fm_st_proto);
if (ret == -EINPROGRESS) {
@@ -1532,7 +1537,7 @@ u32 fmc_prepare(struct fmdev *fmdev)
g_st_write = fm_st_proto.write;
} else {
fmerr("Failed to get ST write func pointer\n");
- ret = st_unregister(ST_FM);
+ ret = st_unregister(&fm_st_proto);
if (ret < 0)
fmerr("st_unregister failed %d\n", ret);
return -EAGAIN;
@@ -1586,6 +1591,7 @@ u32 fmc_prepare(struct fmdev *fmdev)
*/
u32 fmc_release(struct fmdev *fmdev)
{
+ static struct st_proto_s fm_st_proto;
u32 ret;
if (!test_bit(FM_CORE_READY, &fmdev->flag)) {
@@ -1604,7 +1610,11 @@ u32 fmc_release(struct fmdev *fmdev)
fmdev->resp_comp = NULL;
fmdev->rx.freq = 0;
- ret = st_unregister(ST_FM);
+ memset(&fm_st_proto, 0, sizeof(fm_st_proto));
+ fm_st_proto.chnl_id = 0x08;
+
+ ret = st_unregister(&fm_st_proto);
+
if (ret < 0)
fmerr("Failed to de-register FM from ST %d\n", ret);
else
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L: sh_mobile_csi2: fix module reloading
If the camera host driver (sh_mobile_ceu_camera.c) is unloaded and then
reloaded, probe will fail, because camera client .set_bus_param() and
.query_bus_param() methods have been set to NULL. Fix this by caching
the original pointers and restoring them on driver-unbind.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/sh_mobile_csi2.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/sh_mobile_csi2.c
b/drivers/media/video/sh_mobile_csi2.c
index 94e575f..9b68a40 100644
--- a/drivers/media/video/sh_mobile_csi2.c
+++ b/drivers/media/video/sh_mobile_csi2.c
@@ -38,6 +38,8 @@ struct sh_csi2 {
void __iomem*base;
struct platform_device *pdev;
struct sh_csi2_client_config*client;
+ unsigned long (*query_bus_param)(struct soc_camera_device *);
+ int (*set_bus_param)(struct soc_camera_device *, unsigned long);
};
static int sh_csi2_try_fmt(struct v4l2_subdev *sd,
@@ -216,6 +218,8 @@ static int sh_csi2_notify(struct notifier_block *nb,
priv->client = pdata->clients + i;
+ priv->set_bus_param = icd->ops->set_bus_param;
+ priv->query_bus_param = icd->ops->query_bus_param;
icd->ops->set_bus_param = sh_csi2_set_bus_param;
icd->ops->query_bus_param = sh_csi2_query_bus_param;
@@ -227,8 +231,10 @@ static int sh_csi2_notify(struct notifier_block *nb,
priv->client = NULL;
/* Driver is about to be unbound */
- icd->ops->set_bus_param = NULL;
- icd->ops->query_bus_param = NULL;
+ icd->ops->set_bus_param = priv->set_bus_param;
+ icd->ops->query_bus_param = priv->query_bus_param;
+ priv->set_bus_param = NULL;
+ priv->query_bus_param = NULL;
v4l2_device_unregister_subdev(&priv->subdev);
--
1.7.2.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] V4L: soc-camera: don't dereference I2C client after it has been removed
i2c_unregister_device() frees the I2C client, so, dereferencing it
afterwards is a bug, that leads to Oopses.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/soc_camera.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index e97be53..2f0fd2f 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -996,10 +996,11 @@ static void soc_camera_free_i2c(struct soc_camera_device
*icd)
{
struct i2c_client *client =
to_i2c_client(to_soc_camera_control(icd));
+ struct i2c_adapter *adap = client->adapter;
dev_set_drvdata(&icd->dev, NULL);
v4l2_device_unregister_subdev(i2c_get_clientdata(client));
i2c_unregister_device(client);
- i2c_put_adapter(client->adapter);
+ i2c_put_adapter(adap);
}
#else
#define soc_camera_init_i2c(icd, icl) (-ENODEV)
--
1.7.2.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] V4L: imx074: return a meaningful error code instead of -1
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/imx074.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 1a11691..0382ea7 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -298,7 +298,7 @@ static unsigned long imx074_query_bus_param(struct
soc_camera_device *icd)
static int imx074_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
- return -1;
+ return -EINVAL;
}
static struct soc_camera_ops imx074_ops = {
--
1.7.2.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] V4L: soc-camera: fix a recent multi-camera breakage on sh-mobile
With the introduction of CSI2 support on sh-mobile, the host driver
switched to using v4l2_device_call_until_err() with grp_id == 0 to
call subdev operations on the sensor and the CSI2 subdev. However,
this has broken multi-client set ups like the one on migor, because
that way all operations get called on both clients. To fix this add
a grp_id and set it to the client private context.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/sh_mobile_ceu_camera.c | 10 +-
drivers/media/video/sh_mobile_csi2.c |1 +
drivers/media/video/soc_camera.c |4 +++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 3fe54bf..d84daf1 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -922,7 +922,7 @@ static int sh_mobile_ceu_get_formats(struct
soc_camera_device *icd, unsigned int
/* Try 2560x1920, 1280x960, 640x480, 320x240 */
mf.width= 2560 >> shift;
mf.height = 1920 >> shift;
- ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, video,
+ ret = v4l2_device_call_until_err(sd->v4l2_dev,
(int)icd, video,
s_mbus_fmt, &mf);
if (ret < 0)
return ret;
@@ -1224,7 +1224,7 @@ static int client_s_fmt(struct soc_camera_device *icd,
struct v4l2_cropcap cap;
int ret;
- ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, video,
+ ret = v4l2_device_call_until_err(sd->v4l2_dev, (int)icd, video,
s_mbus_fmt, mf);
if (ret < 0)
return ret;
@@ -1254,7 +1254,7 @@ static int client_s_fmt(struct soc_camera_device *icd,
tmp_h = min(2 * tmp_h, max_height);
mf->width = tmp_w;
mf->height = tmp_h;
- ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, video,
+ ret = v4l2_device_call_until_err(sd->v4l2_dev, (int)icd, video,
s_mbus_fmt, mf);
dev_geo(dev, "Camera scaled to %ux%u\n",
mf->width, mf->height);
@@ -1658,7 +1658,7 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device
*icd,
mf.code = xlate->code;
mf.colorspace = pix->colorspace;
- ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, video, try_mbus_fmt,
&mf);
+ ret = v4l2_device_call_until_err(sd->v4l2_dev, (int)icd, video,
try_mbus_fmt, &mf);
if (ret < 0)
return ret;
@@ -1682,7 +1682,7 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device
*icd,
*/
mf.width = 2560;
mf.height = 1920;
- ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, video,
+ ret = v4l2_device_call_until_err(sd->v4l2_dev,
(int)icd, video,
try_mbus_fmt, &mf);
if (ret < 0) {
/* Shouldn't actually happen... */
diff --git a/drivers/media/video/sh_mobile_csi2.c
b/drivers/media/video/sh_mobile_csi2.c
index dd1b81b..94e575f 100644
--- a/drivers/media/video/sh_mobile_csi2.c
+++ b/drivers/media/video/sh_mobile_csi2.c
@@ -208,6 +208,7 @@ static int sh_csi2_notify(struct notifier_block *nb,
case BUS_NOTIFY_BOUND_DRIVER:
snprintf(priv->subdev.name, V4L2_SUBDEV_NAME_SIZE, "%s%s",
dev_name(v4l2_dev->dev), ".mipi-csi");
+ priv->subdev.grp_id = (int)icd;
ret = v4l2_device_register_subdev(v4l2_dev, &priv->subdev);
dev_dbg(dev, "%s(%p): ret(register_subdev) = %d\n", __func__,
priv, ret);
if (ret < 0)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..e97be53 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1071,6 +1071,9 @@ static int soc_camera_probe(struct device *dev)
}
}
+ sd = soc_camera_to_subdev(icd);
+ sd->grp_id = (int)icd;
+
/* At this point client .probe() should have run already */
ret = soc_camera_init_user_formats(icd);
if (ret < 0)
@@ -1092,7 +1095,6 @@ static int soc_camera_probe(struct device *dev)
goto evidstart;
/* Try to improve our guess of a reasonable window format */
- sd = soc_camera_to_subdev(icd);
if (!v4l2_subdev_call(sd, video, g_mbus_fmt, &mf)) {
icd->user_width = mf.width;
icd->user_height= mf.height;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe
[PATCH] V4L: fix a macro definition
v4l2_device_unregister_subdev() wrongly uses "arg..." instead of "## arg"
in its body. Fix it.
Signed-off-by: Guennadi Liakhovetski
---
include/media/v4l2-device.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index 0c2bd30..dc0004e 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -149,7 +149,7 @@ v4l2_device_register_subdev_nodes(struct v4l2_device
*v4l2_dev);
({ \
struct v4l2_subdev *__sd; \
__v4l2_device_call_subdevs_until_err_p(v4l2_dev, __sd, cond, o, \
- f, args...);\
+ f , ##args);\
})
/* Call the specified callback for all subdevs matching grp_id (if 0, then
--
1.7.2.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] V4L: fix an error message
buf->size is not yet initialised in videobuf2-dma-contig at the time of
the error message, use "size."
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/videobuf2-dma-contig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 58205d5..a790a5f 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -46,7 +46,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
GFP_KERNEL);
if (!buf->vaddr) {
dev_err(conf->dev, "dma_alloc_coherent of size %ld failed\n",
- buf->size);
+ size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
--
1.7.2.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] V4L: fix videobof2 to correctly identify allocation failures
The videobuf2-dma-contig allocator returns an ERR_PTR() on failure, not
a NULL like all other allocators. Fix videobuf2-core to also correctly
recognise those failures.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/video/videobuf2-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6698c77..71734a4 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -51,7 +51,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb,
for (plane = 0; plane < vb->num_planes; ++plane) {
mem_priv = call_memop(q, plane, alloc, q->alloc_ctx[plane],
plane_sizes[plane]);
- if (!mem_priv)
+ if (IS_ERR_OR_NULL(mem_priv))
goto free;
/* Associate allocator private data with this plane */
--
1.7.2.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: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface
Hi Janusz You might want to retest ams-delta with the camera on the current (next or git://linuxtv.org/media_tree.git staging/for_v2.6.39 ) kernel - I suspect, you'll need something similar to http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/30728 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: implement ENUM_FMT
Hi Michael, Thanks for the patch. Michael Jones wrote: > From dccbd4a0a717ee72a3271075b1e3456a9c67ca0e Mon Sep 17 00:00:00 2001 > From: Michael Jones > Date: Tue, 22 Mar 2011 11:47:22 +0100 > Subject: [PATCH] omap3isp: implement ENUM_FMT > > Whatever format is currently being delivered will be declared as the only > possible format > > Signed-off-by: Michael Jones > --- > > Some V4L2 apps require ENUM_FMT, which is a mandatory ioctl for V4L2. > This patch doesn't enumerate all of the formats which could possibly be > set (as is intended by ENUM_FMT), but at least it reports the one that > is currently set. What would be the purpose of ENUM_FMT in this case? It provides no additional information to user space, and the information it provides is in fact incomplete. Using other formats is possible, but that requires changes to the format configuration on links. As the relevant format configuration is done on the subdevs and not on the video nodes, the format configuration on the video nodes is very limited and much affected by the state of the formats on the subdev pads (which I think is right). This is not limited to ENUM_FMT but all format related IOCTLs on the OMAP 3 ISP driver. My view is that should a generic application want to change (or enumerate) the format(s) on a video node, the application would need to be using libv4l for that. A compatibility layer implemented in libv4l (plugin, not the main library) needs to configure the links in the first place, so implementing ENUM_FMT in the plugin would not be a big deal. It could even provide useful information. The possible results of the ENUM_FMT would also depend on what kind of pipeline configuration does the plugin support, though. (Cc Yordan and Hans.) I discussed this with Laurent initially and the conclusion was that more discussion is required. :-) Hans: do you have an opinion on this? Best regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: mach-shmobile: add coherent DMA mask to CEU camera devices
Cameras are currently broken on ARM sh-mobile platforms. They need a
suitable coherent DMA mask.
Signed-off-by: Guennadi Liakhovetski
---
arch/arm/mach-shmobile/board-ap4evb.c |3 ++-
arch/arm/mach-shmobile/board-mackerel.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index 81d6536..77bf226 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -923,7 +923,8 @@ static struct platform_device ceu_device = {
.num_resources = ARRAY_SIZE(ceu_resources),
.resource = ceu_resources,
.dev= {
- .platform_data = &sh_mobile_ceu_info,
+ .platform_data = &sh_mobile_ceu_info,
+ .coherent_dma_mask = 0x,
},
};
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 063a320..71de352 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -887,7 +887,8 @@ static struct platform_device ceu_device = {
.num_resources = ARRAY_SIZE(ceu_resources),
.resource = ceu_resources,
.dev= {
- .platform_data = &sh_mobile_ceu_info,
+ .platform_data = &sh_mobile_ceu_info,
+ .coherent_dma_mask = 0x,
},
};
--
1.7.2.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/3 v2] V4L: soc_camera_platform: add helper functions to manage device instances
Add helper inline functions to correctly manage dynamic allocation and
freeing of platform devices. This avoids the ugly code to nullify
device objects.
Signed-off-by: Guennadi Liakhovetski
Acked-by: Magnus Damm
---
v2: fix the device link assignment order, reported by Magnus - thanks for
testing!
Now, wondering, if we still can manage to get this into .39 together with
the other 2 patches for the SH and ARM platforms from the series and via
which tree...
include/media/soc_camera_platform.h | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/include/media/soc_camera_platform.h
b/include/media/soc_camera_platform.h
index 0ecefe2..6d7a4fd 100644
--- a/include/media/soc_camera_platform.h
+++ b/include/media/soc_camera_platform.h
@@ -25,4 +25,54 @@ struct soc_camera_platform_info {
int (*set_capture)(struct soc_camera_platform_info *info, int enable);
};
+static inline void soc_camera_platform_release(struct platform_device **pdev)
+{
+ *pdev = NULL;
+}
+
+static inline int soc_camera_platform_add(const struct soc_camera_link *icl,
+ struct device *dev,
+ struct platform_device **pdev,
+ struct soc_camera_link *plink,
+ void (*release)(struct device *dev),
+ int id)
+{
+ struct soc_camera_platform_info *info = plink->priv;
+ int ret;
+
+ if (icl != plink)
+ return -ENODEV;
+
+ if (*pdev)
+ return -EBUSY;
+
+ *pdev = platform_device_alloc("soc_camera_platform", id);
+ if (!*pdev)
+ return -ENOMEM;
+
+ info->dev = dev;
+
+ (*pdev)->dev.platform_data = info;
+ (*pdev)->dev.release = release;
+
+ ret = platform_device_add(*pdev);
+ if (ret < 0) {
+ platform_device_put(*pdev);
+ *pdev = NULL;
+ info->dev = NULL;
+ }
+
+ return ret;
+}
+
+static inline void soc_camera_platform_del(const struct soc_camera_link *icl,
+ struct platform_device *pdev,
+ const struct soc_camera_link *plink)
+{
+ if (icl != plink || !pdev)
+ return;
+
+ platform_device_unregister(pdev);
+}
+
#endif /* __SOC_CAMERA_H__ */
--
1.7.2.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
NEC 32 bits RC codes - was: Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
Em 23-03-2011 05:41, Antti Palosaari escreveu:
> On 03/23/2011 01:00 AM, Mauro Carvalho Chehab wrote:
>> Em 22-03-2011 19:12, Malcolm Priestley escreveu:
>>> On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote:
>
Anyhow, my opinion is still that we *should* make all NEC remotes as 32
bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For
example AF9015 current NEC handling is too complex for that reason... I
don't like how it is implemented currently.
>>>
>>> One of the reasons for using 32 bit was interference from other consumer
>>> remotes. It appears, these near identical bubble remotes originate from
>>> a Chinese factory and supplied with the same product with completely
>>> different key mapping.
>>>
>>> I am not sure how many of these remotes are common to other devices.
>>
>> Drivers should get the 32 bit codes form NEC when hardware provides it.
>> What we currently do is to identify if the code has 16, 24 or 32 bits,
>> but it is probably better to always handle them as if they have 32 bits.
>
> That's how af9015 driver handles it currently.
>
> if (buf[14] == (u8) ~buf[15]) {
> if (buf[12] == (u8) ~buf[13]) {
> /* 16 bit NEC standard */
> priv->rc_keycode = buf[12] << 8 | buf[14];
> } else {
> /* 24 bit NEC extended*/
> priv->rc_keycode = buf[12] << 16 | buf[13] << 8 | buf[14];
> }
> } else {
> /* 32 bit NEC full scancode */
> priv->rc_keycode = buf[12] << 24 | buf[13] << 16 | buf[14] << 8 | buf[15];
> }
>
> I think there is no any better currently.
RC core does the same. I talked with Jarod, and we're thinking on just use 32
bits
for everything. There are two issues however:
1) All NEC tables will need to be replaced. This affects userspace. Not
sure
how to workaround it there, to allow userspace to do the right thing. New
protocol type?
2) Some hardware decoders only provide 16 bits for NEC.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Leadtek Winfast 1800H FM Tuner
Em 22-03-2011 08:54, Andrew Goff escreveu: > On Tue, Mar 22, 2011 at 8:09 AM, Mauro Carvalho Chehab > wrote: >> Em 21-03-2011 17:46, Andrew Goff escreveu: >>> On Tue 22-Mar-2011 4:44 AM, Mauro Carvalho Chehab wrote: Em 21-03-2011 08:35, Andrew Goff escreveu: > On Mon 21-Mar-2011 9:21 PM, Mauro Carvalho Chehab wrote: >> Em 20-03-2011 05:18, Antti Palosaari escreveu: >>> On 03/20/2011 02:56 AM, Andrew Goff wrote: Hi, I hope someone may be able to help me solve a problem or point me in the right direction. I have been using a Leadtek Winfast DTV1800H card (Xceive xc3028 tuner) for a while now without any issues (DTV& Radio have been working well), I recently decided to get another tuner card, Leadtek Winfast DTV2000DS (Tuner: NXP TDA18211, but detected as TDA18271 by V4L drivers, Chipset: AF9015 + AF9013 ) and had to compile and install the V4L drivers to get it working. Now DTV on both cards work well but there is a problem with the radio tuner on the 1800H card. After installing the more recent V4L drivers the radio frequency is 2.7MHz out, so if I want to listen to 104.9 I need to tune the radio to 107.6. Now I could just change all my preset stations but I can not listen to my preferred stations as I need to set the frequency above 108MHz. >>> I think there is something wrong with the FM tuner (xc3028?) or other >>> chipset drivers used for DTV1800H. No relations to the af9015, af9013 >>> or tda18271. tda18211 is same chip as tda18271 but only DVB-T included. >>> If DTV1800H does not contain tda18211 or tda18271 problem cannot be >>> either that. >> Yes, the problem is likely at xc3028. It has to do frequency shift for >> some >> DVB standards, and the shift is dependent on what firmware is loaded. >> >> So, you need to enable load tuner-xc2028 with debug=1, and provide us the >> dmesg. >> >> Mauro. >> > Hi Mauro > > To do this do I just add the line > > options tuner-xc2028 debug=1 > > to the /etc/modules file. > > From my current dmesg file looks like the firmware is version 2.7. > > xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: > xc2028 firmware, ver 2.7 There are about 60 firmwares that are grouped inside xc3028-v27.fw. Please post the complete dmesg. We also need to know what version of the driver you were using when the driver used to work and what you're using when it broke. Thanks Mauro. >>> >>> Mauro, please see dmesg attached, note I have not added debug=1 yet, do I >>> still need to do this. >>> >>> To get the other card working I installed this driver version >>> http://linuxtv.org/hg/v4l-dvb/rev/abd3aac6644e >> >> The mercurial tree is there just due to historic reasons. It has _obsolete_ >> stuff and nobody >> is updating it. Please use, instead, the media_build.git (see linuxtv.org >> wiki). >> >> the dmesg with the debug=1 is required, otherwise, it won't produce any >> error about what's happening at >> the xc3028 driver. >> >> Mauro. >> > > HI Mauro, now using media_build.git and followed the instructions from > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > > have added options tuner-xc2028 debug=1 to the /etc/modules , please > see attached dmesg > > FM tuner has now completely stopped working. Weird: [ 36.654409] xc2028 1-0061: creating new instance [ 36.654414] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 36.654419] xc2028 1-0061: destroying instance [ 36.654489] xc2028 1-0061: creating new instance [ 36.654491] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 36.654494] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 36.745247] cx88_audio :01:06.1: firmware: requesting xc3028-v27.fw [ 36.817868] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 36.817993] cx88[0]: Calling XC2028/3028 callback [ 36.966811] xc2028 1-0061: Loading firmware for type=BASE (1), id . [ 36.966815] cx88[0]: Calling XC2028/3028 callback xc2028 driver didn't try to load a standard-specific firmware... I would expect at least two load firmware lines there... one for NTSC, and another one for one of the radio-specific firmwares, when you tried to run radio on it. Please also load tuner with debug=1. Let's see what happens when you change a frequency on your radio program. AH! Very important! V4L1 API got removed, so, you need to be sure that your radio program is using V4L2 API. I had to fix xawtv3 "radio" program for it to work properly using V4L2 API. So, xawtv 3.95 is broken. If you're using xawtv 3.100, radio application is working fine. We had also a report th
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
On 03/23/2011 01:00 AM, Mauro Carvalho Chehab wrote:
Em 22-03-2011 19:12, Malcolm Priestley escreveu:
On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote:
Anyhow, my opinion is still that we *should* make all NEC remotes as 32
bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For
example AF9015 current NEC handling is too complex for that reason... I
don't like how it is implemented currently.
One of the reasons for using 32 bit was interference from other consumer
remotes. It appears, these near identical bubble remotes originate from
a Chinese factory and supplied with the same product with completely
different key mapping.
I am not sure how many of these remotes are common to other devices.
Drivers should get the 32 bit codes form NEC when hardware provides it.
What we currently do is to identify if the code has 16, 24 or 32 bits,
but it is probably better to always handle them as if they have 32 bits.
That's how af9015 driver handles it currently.
if (buf[14] == (u8) ~buf[15]) {
if (buf[12] == (u8) ~buf[13]) {
/* 16 bit NEC standard */
priv->rc_keycode = buf[12] << 8 | buf[14];
} else {
/* 24 bit NEC extended*/
priv->rc_keycode = buf[12] << 16 | buf[13] << 8 | buf[14];
}
} else {
/* 32 bit NEC full scancode */
priv->rc_keycode = buf[12] << 24 | buf[13] << 16 | buf[14] << 8 |
buf[15];
}
I think there is no any better currently.
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: [RFC PATCH 4/3] remove radio-maestro
At Tue, 22 Mar 2011 15:44:05 -0300, Mauro Carvalho Chehab wrote: > > Hi Takashi, > > Em 19-03-2011 13:23, Ondrej Zary escreveu: > > Remove broken radio-maestro driver as the radio functionality is now > > integrated in the es1968 driver. > > I prefer if you could also add it on your tree, as we want to make sure that > this patch will be applied together with the patches that moved Maestro > support into the es1968 driver. > > I have no means to test if the es1968 changes work with a Maestro radio (as I > don't have this hardware), but I'm OK with this change. So: > > Acked-by: Mauro Carvalho Chehab OK, I removed it in my tree now. Thanks! Takashi -- 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: S2-3200 switching-timeouts on 2.6.38
Hello Manu, you are absolutely right, thanks for pointing this out. Looking forward to the stb0899-patch inclusion. Best Regards, Rico signature.asc Description: OpenPGP digital signature
