Re: Remote that breaks current system
On Mon, Aug 16, 2010 at 11:30 PM, Mauro Carvalho Chehab wrote: > Em 16-08-2010 21:14, Jarod Wilson escreveu: > >>> Just one minor nitpick. >>> You could 'use' the original RC5 decoder, but add a knob to it to make >>> it accept 15 bits instead of 14. >>> However, this will require some interface changes. >> >> Well, I think that still falls down if someone, for some reason, wants >> to use both an old RC5 remote and the Streamzap remote at the same >> time. I think a parallel decoder is probably the best situation for >> the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded >> simultaneously. > > One option could be to change rc5 decoder to work with 3 different modes, > controlled by a sysfs node: > 1) just 14 bits code; > 2) just 15 bits code; > 3) both 14 and 15 bits code. > > For (3), it will need a timeout logic for a short period (like 2T), for the > 15th bit. If nothing happens, it will assume it is 14 bits, producing a code > and resetting the finite-state machine. > > By default, it would be working on 14-bits mode for normal RC decoders, and > on 15-bits mode for Streamzap. > > Yet, IMHO, the better is to commit what you have currently. Just my 2 cents. Yeah, I don't doubt that we *could* come up with some way to make them coexist in the same decoder, but I think its probably not worth the effort or added complexity over simply having a separate parallel decoder (which is only loaded by default if the receiver bundled with the funky remote is plugged in). -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote that breaks current system
Em 16-08-2010 21:14, Jarod Wilson escreveu: >> Just one minor nitpick. >> You could 'use' the original RC5 decoder, but add a knob to it to make >> it accept 15 bits instead of 14. >> However, this will require some interface changes. > > Well, I think that still falls down if someone, for some reason, wants > to use both an old RC5 remote and the Streamzap remote at the same > time. I think a parallel decoder is probably the best situation for > the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded > simultaneously. One option could be to change rc5 decoder to work with 3 different modes, controlled by a sysfs node: 1) just 14 bits code; 2) just 15 bits code; 3) both 14 and 15 bits code. For (3), it will need a timeout logic for a short period (like 2T), for the 15th bit. If nothing happens, it will assume it is 14 bits, producing a code and resetting the finite-state machine. By default, it would be working on 14-bits mode for normal RC decoders, and on 15-bits mode for Streamzap. Yet, IMHO, the better is to commit what you have currently. Just my 2 cents. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch for lifeview hybrid mini
Hi, Am Sonntag, den 15.08.2010, 07:20 +0200 schrieb tomloh...@gmail.com: > Hi, > > the proposed patch is 6 month old and the owner of the card does not > give any more sign of life for the support of the radio. > can someone review it and push it as is? > > Cheers, > > Signed-off-by: thomas genty > Thomas, just some quick notes, since nobody else cares. The m$ regspy gpio logs do show only gpio22 changing for analog and DVB-T and this should be the out of reference AGC control on a hopefully single hybrid tuner on that device called DUO. Remember, gpios not set in the mask of the analog part of the device do not change/switch anything, but those set there will change to zero even without explicit gpio define for that specific analog input. Out of historical reasons, we don't have this in our logs for DVB, also else they would be littered by the changing gpios for the TS/MPEG interface, but should be OK. We don't need to mark DVB related gpio stuff in the analog gpio mask, since we need to use some sort of hack to switch gpios on saa713x in DVB mode. dvb and v4l still don't know much about what each other subsystem does on that, but we have some progress. So, for now, I don't know for what gpio21 high in analog TV mode should be good, since the m$ driver seems not to do anything on that one, for what we have so far. Also it is common on later LifeView stuff (arrgh), but always is present in related logs then too. If ever needed, despite of that line inputs and muxes are also totally unconfirmed, and radio is plain madness ... drop the radio support for now, mark the external inputs as untested and I give some reviewed by so far with headaches. If we can't get more from here anymore, we must let it bounce. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote that breaks current system
On Mon, Aug 16, 2010 at 4:41 PM, Maxim Levitsky wrote: > On Mon, 2010-08-16 at 00:04 -0400, Jarod Wilson wrote: >> On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus >> wrote: >> ... >> >> So I spent a while beating on things the past few nights for giggles >> >> (and for a sanity break from "vacation" with too many kids...). I >> >> ended up doing a rather large amount of somewhat invasive work to the >> >> streamzap driver itself, but the end result is functional in-kernel >> >> decoding, and lirc userspace decode continues to behave correctly. RFC >> >> patch here: >> >> >> >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch >> >> >> >> Core changes to streamzap.c itself: >> >> >> >> - had to enable reporting of a long space at the conclusion of each >> >> signal (which is what the lirc driver would do w/timeout_enabled set), >> >> otherwise I kept having issues with key bounce and/or old data being >> >> buffered (i.e., press up, cursor moves up. push down, cursor moves up >> >> then down, press left, it moves down, then left, etc.). Still not >> >> quite sure what the real problem is there, the lirc userspace decoder >> >> has no problems with it either way. >> >> >> >> - removed streamzap's internal delay buffer, as the ir-core kfifo >> >> seems to provide the necessary signal buffering just fine by itself. >> >> Can't see any significant difference in decode performance either >> >> in-kernel or via lirc with it removed, anyway. (Christoph, can you >> >> perhaps expand a bit on why the delay buffer was originally needed/how >> >> to reproduce the problem it was intended to solve? Maybe I'm just not >> >> triggering it yet.) >> > >> > Should be fine. Current lircd with timeout support shouldn't have a >> > problem with that anymore. I was already thinking of suggesting to remove >> > the delay buffer. >> >> Cool, sounds like a plan then, I'll go ahead with it. >> >> >> Other fun stuff to note: >> >> >> >> - currently, loading up an rc5-sz decoder unconditionally, have >> >> considered only auto-loading it from the streamzap driver itself. Its >> >> a copy of the rc5 decoder with relatively minor tweaks to deal with >> >> the extra bit and resulting slightly different bit layout. Might >> >> actually be possible to merge back into the rc5 decoder itself, >> >> haven't really looked into that yet (should be entirely doable if >> >> there's an easy way to figure out early on if we need to grab 14 >> >> bits). >> > >> > There is no way until you see the 14th bit. >> >> Hm. Was afraid of that. I gave it a shot to see if I could make that >> work, pretty shaky results. About 2/3 of the keys get decoded as >> 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't >> match anything in the keytable (and often duplicate one another). So >> it looks like at least for the time being, a separate parallel decoder >> is the way to go. I'm thinking that I like the approach of only >> explicitly loading it from the streamzap driver though. > > Just one minor nitpick. > You could 'use' the original RC5 decoder, but add a knob to it to make > it accept 15 bits instead of 14. > However, this will require some interface changes. Well, I think that still falls down if someone, for some reason, wants to use both an old RC5 remote and the Streamzap remote at the same time. I think a parallel decoder is probably the best situation for the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded simultaneously. -- Jarod Wilson ja...@wilsonet.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
strange way to make my dvb device works...
Hello, I use a Bestbuy easy-tv hybrid pro usb dongle as my dvb-t device based on em28xx for watching tv. I got the latest code from v4l-dvb hg repository recently (thx Douglas) and works perfectly under 2.6.35 custom kernel with firmware xc3028-v27 extracted with the perl script as wiki said. But I have an issue to report... This device isn't recognized automatically and dmesg suggests my to choose one card. Curiously, I have to write this commands (as one user recommends) to make it work correctly: * sudo rmmod em28xx * sudo modprobe em28xx card=10 * sudo rmmod em28xx-dvb *sudo rmmod em28xx *sudo modprobe em28xx card=11 Maybe there's something to fix this! Thanks and congratulations! Alberto. P.D. I attach em28xx dmesg report for card 11 as text file. [ 316.934137] em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) [ 316.934244] em28xx #0: chip ID is em2882/em2883 [ 317.118340] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 [ 317.118353] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [ 317.118364] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 01 00 b8 00 00 00 5b 1e 00 00 [ 317.118376] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 [ 317.118387] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118398] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118409] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [ 317.118420] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [ 317.118431] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [ 317.118442] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118453] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118464] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118475] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118486] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118497] em28xx #0: i2c eeprom e0: 5a 00 55 aa b2 60 58 03 00 17 fc 01 00 00 00 00 [ 317.118508] em28xx #0: i2c eeprom f0: 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 [ 317.118521] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x09910020 [ 317.118523] em28xx #0: EEPROM info: [ 317.118525] em28xx #0: AC97 audio (5 sample rates) [ 317.118527] em28xx #0: USB Remote wakeup capable [ 317.118529] em28xx #0: 500mA max power [ 317.118532] em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x [ 317.119582] em28xx #0: Identified as Terratec Hybrid XS (card=11) [ 317.121532] tvp5150 3-005c: chip found @ 0xb8 (em28xx #0) [ 317.126250] tuner 3-0061: chip found @ 0xc2 (em28xx #0) [ 317.126356] xc2028 3-0061: creating new instance [ 317.126359] xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner [ 317.128316] xc2028 3-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 317.181276] xc2028 3-0061: Loading firmware for type=BASE (1), id . [ 318.090946] xc2028 3-0061: Loading firmware for type=(0), id b700. [ 318.104572] SCODE (2000), id b700: [ 318.104577] xc2028 3-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. [ 318.231522] Registered IR keymap rc-terratec-cinergy-xs [ 318.231627] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-5/rc/rc0/input8 [ 318.231690] rc0: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-5/rc/rc0 [ 318.232208] em28xx #0: Config register raw data: 0x58 [ 318.233011] em28xx #0: AC97 vendor ID = 0x [ 318.233390] em28xx #0: AC97 features = 0x6a90 [ 318.233393] em28xx #0: Empia 202 AC97 audio processor detected [ 318.371715] tvp5150 3-005c: tvp5150am1 detected. [ 318.472132] em28xx #0: v4l2 driver version 0.1.2 [ 318.558532] em28xx #0: V4L2 video device registered as video1 [ 318.558536] em28xx #0: V4L2 VBI device registered as vbi0 [ 318.559173] usbcore: registered new interface driver em28xx [ 318.559176] em28xx driver loaded [ 318.681738] tvp5150 3-005c: tvp5150am1 detected. [ 318.822150] xc2028 3-0061: attaching existing instance [ 318.822154] xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner [ 318.822157] em28xx #0: em28xx #0/2: xc3028 attached [ 318.822160] DVB: registering new adapter (em28xx #0) [ 318.822164] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [ 318.822541] em28xx #0: Successfully loaded em28xx-dvb [ 318.822547] Em28xx: Initialized (Em28xx dvb Extension) extension [ 318.941749] tvp5150 3-005c: tvp5150am1 detected.
Re: Remote that breaks current system
On Mon, 2010-08-16 at 00:04 -0400, Jarod Wilson wrote: > On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus > wrote: > ... > >> So I spent a while beating on things the past few nights for giggles > >> (and for a sanity break from "vacation" with too many kids...). I > >> ended up doing a rather large amount of somewhat invasive work to the > >> streamzap driver itself, but the end result is functional in-kernel > >> decoding, and lirc userspace decode continues to behave correctly. RFC > >> patch here: > >> > >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch > >> > >> Core changes to streamzap.c itself: > >> > >> - had to enable reporting of a long space at the conclusion of each > >> signal (which is what the lirc driver would do w/timeout_enabled set), > >> otherwise I kept having issues with key bounce and/or old data being > >> buffered (i.e., press up, cursor moves up. push down, cursor moves up > >> then down, press left, it moves down, then left, etc.). Still not > >> quite sure what the real problem is there, the lirc userspace decoder > >> has no problems with it either way. > >> > >> - removed streamzap's internal delay buffer, as the ir-core kfifo > >> seems to provide the necessary signal buffering just fine by itself. > >> Can't see any significant difference in decode performance either > >> in-kernel or via lirc with it removed, anyway. (Christoph, can you > >> perhaps expand a bit on why the delay buffer was originally needed/how > >> to reproduce the problem it was intended to solve? Maybe I'm just not > >> triggering it yet.) > > > > Should be fine. Current lircd with timeout support shouldn't have a > > problem with that anymore. I was already thinking of suggesting to remove > > the delay buffer. > > Cool, sounds like a plan then, I'll go ahead with it. > > >> Other fun stuff to note: > >> > >> - currently, loading up an rc5-sz decoder unconditionally, have > >> considered only auto-loading it from the streamzap driver itself. Its > >> a copy of the rc5 decoder with relatively minor tweaks to deal with > >> the extra bit and resulting slightly different bit layout. Might > >> actually be possible to merge back into the rc5 decoder itself, > >> haven't really looked into that yet (should be entirely doable if > >> there's an easy way to figure out early on if we need to grab 14 > >> bits). > > > > There is no way until you see the 14th bit. > > Hm. Was afraid of that. I gave it a shot to see if I could make that > work, pretty shaky results. About 2/3 of the keys get decoded as > 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't > match anything in the keytable (and often duplicate one another). So > it looks like at least for the time being, a separate parallel decoder > is the way to go. I'm thinking that I like the approach of only > explicitly loading it from the streamzap driver though. Just one minor nitpick. You could 'use' the original RC5 decoder, but add a knob to it to make it accept 15 bits instead of 14. However, this will require some interface changes. Best regards, Maxim Levitsky -- 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 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Mon Aug 16 19:00:22 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15067:ab433502e041 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: 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-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-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-rc1-x86_64: WARNINGS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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: CCP2 on OMAP35x
Hi Michael,
On Monday 16 August 2010 17:38:43 Michael Jones wrote:
> Hi Laurent,
>
> I'm working on a sensor driver with a parallel interface to the ISP. In my
> OMAP35x TRM (spruf98h.pdf), I only find 2 occurrences of "CCP2", with no
> discussion or description, whereas in the ISP sources on omap3camera/devel
> I see that it is a building block of the ISP. From the sources, I'm
> guessing that it is involved in interfacing a serial sensor data stream to
> the CCDC, and would be uninvolved in parallel data from a sensor.
That's correct. CCP2 stands for Compact Camera Port 2 and is an interface
standard for serial cameras used in mobile phones (and possibly elsewhere). A
quick search on Google turns up this link
http://www.sunex.com/SIMA/SMIA_CCP2_specification_1.0.pdf. If I'm not
mistaken, CCP2 is a superset of the CSI-1 interface standard defined by the
MIPI alliance.
> Is the CCP2 indeed documented somewhere for the OMAP35x? Or is this
> perhaps only available in the OMAP34x?
The physical CCP2 interface is only available in the OMAP34xx and OMAP36xx
processors. The OMAP35xx family has a parallel receiver only.
However, the CCP2 module can also read back raw data from memory. Even though
the physical CCP2 interface is not present on the OMAP34xx/36xx families (at
least according to the TRM, I don't think anymore has built an OMAP35xx board
to verify this), the CCP2 module itself is available and can be used in memory
input mode.
> In omap34xxcam_video_init(), the media_entity links are activated. In this
> if/else there,
>
> if (vdev->vdev_sensor->entity.links[0].sink->entity ==
> &isp->isp_csi2a.subdev.entity) {...} else {...}
>
> the assumption is made that a sensor is either connected
> A. (sensor->)CSI2A->CCDC or
> B. sensor->CCP2->CCDC
That's correct.
> but if I'm correct that the CCP2 is related to serial data, there is an
> option (C) missing for parallel data: sensor->CCDC. In fact, this is the
> link that is created in omap34xxcam_probe() if 'case
> ISP_INTERFACE_PARALLEL'. Is this correct, that I would need to add an
> 'else if' to get parallel data working?
You shouldn't use the video nodes /dev/video0 and /dev/video1. They're legacy
and will soon be removed. You should instead use the new video nodes
/dev/video[2-8] along with the media controller API. They should support
parallel sensors properly.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] drivers/media/video: Use available error codes
From: Julia Lawall
Error codes are stored in rc, but the return value is always 0. Return rc
instead.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
local idexpression x;
constant C;
@@
if (...) { ...
x = -C
... when != x
(
return <+...x...+>;
|
return NULL;
|
return;
|
* return ...;
)
}
//
Signed-off-by: Julia Lawall
---
This changes the semantics of the function, but currently its return value
is ignored. Alternatively, the function could be converted to return
nothing.
drivers/media/video/zr364xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/zr364xx.c b/drivers/media/video/zr364xx.c
index a82b5bd..616c61f 100644
--- a/drivers/media/video/zr364xx.c
+++ b/drivers/media/video/zr364xx.c
@@ -572,7 +572,7 @@ static int zr364xx_got_frame(struct zr364xx_camera *cam,
int jpgsize)
DBG("wakeup [buf/i] [%p/%d]\n", buf, buf->vb.i);
unlock:
spin_unlock_irqrestore(&cam->slock, flags);
- return 0;
+ return rc;
}
/* this function moves the usb stream read pipe data
--
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/16] drivers/media/video/zoran: Use available error codes
From: Julia Lawall
Error codes are stored in res, but the return value is always 0. Return
res instead.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
local idexpression x;
constant C;
@@
if (...) { ...
x = -C
... when != x
(
return <+...x...+>;
|
return NULL;
|
return;
|
* return ...;
)
}
//
Signed-off-by: Julia Lawall
---
This changes the semantics and has not been tested.
drivers/media/video/zoran/zoran_driver.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/zoran/zoran_driver.c
b/drivers/media/video/zoran/zoran_driver.c
index 6f89d0a..c155ddf 100644
--- a/drivers/media/video/zoran/zoran_driver.c
+++ b/drivers/media/video/zoran/zoran_driver.c
@@ -3322,7 +3322,7 @@ zoran_mmap (struct file *file,
mmap_unlock_and_return:
mutex_unlock(&zr->resource_lock);
- return 0;
+ return res;
}
static const struct v4l2_ioctl_ops zoran_ioctl_ops = {
--
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 6/16] drivers/media: Use available error codes
From: Julia Lawall
In each case, error codes are stored in rc, but the return value is always
0. Return rc instead.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
local idexpression x;
constant C;
@@
if (...) { ...
x = -C
... when != x
(
return <+...x...+>;
|
return NULL;
|
return;
|
* return ...;
)
}
//
Signed-off-by: Julia Lawall
---
The changes change the semantics and are not tested. In the second case,
the function is used in only one place and the return value is igored.
drivers/media/dvb/frontends/drx397xD.c |2 +-
drivers/media/video/s2255drv.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/drx397xD.c
b/drivers/media/dvb/frontends/drx397xD.c
index f74cca6..a05007c 100644
--- a/drivers/media/dvb/frontends/drx397xD.c
+++ b/drivers/media/dvb/frontends/drx397xD.c
@@ -232,7 +232,7 @@ static int write_fw(struct drx397xD_state *s, enum blob_ix
ix)
exit_rc:
read_unlock(&fw[s->chip_rev].lock);
- return 0;
+ return rc;
}
/* Function is not endian safe, use the RD16 wrapper below */
diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index 8ec7c9a..8f74341 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -600,7 +600,7 @@ static int s2255_got_frame(struct s2255_channel *channel,
int jpgsize)
dprintk(2, "%s: [buf/i] [%p/%d]\n", __func__, buf, buf->vb.i);
unlock:
spin_unlock_irqrestore(&dev->slock, flags);
- return 0;
+ return rc;
}
static const struct s2255_fmt *format_by_fourcc(int fourcc)
--
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] IR/streamzap: enable functional in-kernel decoding
This patch makes in-kernel decoding with the stock Streamzap PC Remote
work out of the box. There are quite a few things going on in this
patch, all (mostly) related to getting this working:
1) I had to enable reporting of a long space at the end of each signal,
or I had weird buffering and keybounce issues.
2) The keymap has been reworked slightly to match actual decoded values,
the first edition was missing the pre-data bits present in the lirc
config file for this remote.
3) There's a whole new decoder included, specifically for the
not-quite-RC5 15-bit protocol variant used by the Streamzap PC
Remote. The decoder, while usable with other recievers (tested with
an mceusb receiver), will only be loaded by the streamzap driver, as
its likely not of use in almost all other situations. This can be
revisited if/when all keytable loading (and disabling of unneeded
protocol decoder engines) is moved to userspace, but for now, I think
this makes the most sense.
Note that I did try to enable handling the streamzap RC5-ish protocol in
the current RC5 decoder, but there's no particularly easy way to tell if
its 14-bit RC5 or 15-bit Streamzap until we see bit 14, and even then,
in testing an attempted decoder merge, only 2/3 of the keys were
properly recognized as being the 15-bit variant and decoded correctly,
the rest were close enough to compliant with 14-bit that they were
decoded as such (but they have overlap with one another, and thus we
can't just shrug and use the 14-bit decoded values).
Also of note in this patch is the removal of the streamzap driver's
internal delay buffer. Per discussion w/Christoph, it shouldn't be
needed by lirc any longer anyway, and it doesn't seem to make any
difference to the in-kernel decoder engine. That being the case, I'm
yanking it all out, as it greatly simplifies the driver code (net result
is that streamzap.c is now 252 lines less than lirc_streamzap.c was).
Signed-off-by: Jarod Wilson
---
drivers/media/IR/Kconfig| 12 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/ir-core-priv.h |6 +
drivers/media/IR/ir-rc5-sz-decoder.c| 153
drivers/media/IR/ir-sysfs.c |1 +
drivers/media/IR/keymaps/Makefile |2 +-
drivers/media/IR/keymaps/rc-rc5-streamzap.c | 81 --
drivers/media/IR/keymaps/rc-streamzap.c | 82 ++
drivers/media/IR/streamzap.c| 358 +++
include/media/rc-map.h |5 +-
10 files changed, 352 insertions(+), 349 deletions(-)
create mode 100644 drivers/media/IR/ir-rc5-sz-decoder.c
delete mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c
create mode 100644 drivers/media/IR/keymaps/rc-streamzap.c
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index 490c57c..152000d 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -79,6 +79,18 @@ config IR_SONY_DECODER
Enable this option if you have an infrared remote control which
uses the Sony protocol, and you need software decoding support.
+config IR_RC5_SZ_DECODER
+ tristate "Enable IR raw decoder for the RC-5 (streamzap) protocol"
+ depends on IR_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-5 (streamzap) protocol,
+ and if the IR is decoded in software. (The Streamzap PC Remote
+ uses an IR protocol that is almost standard RC-5, but not quite,
+ as it uses an additional bit).
+
config IR_LIRC_CODEC
tristate "Enable IR to LIRC bridge"
depends on IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 5367683..953c6c4 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
+obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o
obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index a85a8c7..0ad8ea3 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,6 +76,12 @@ struct ir_raw_event_ctrl {
bool first;
bool toggle;
} jvc;
+ struct rc5_sz_dec {
+ int state;
+ u32 bits;
+ unsigned count;
+ unsigned wanted_bits;
+ } rc5_sz;
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
diff --git a/drivers/media/IR/ir-rc5-sz-decoder.c
b/drivers/media/IR/ir-rc5-sz-decoder.c
new file mode 100644
index 000..68f11d6
--- /dev/null
+++ b/dri
CCP2 on OMAP35x
Hi Laurent,
I'm working on a sensor driver with a parallel interface to the ISP. In my
OMAP35x TRM (spruf98h.pdf), I only find 2 occurrences of "CCP2", with no
discussion or description, whereas in the ISP sources on omap3camera/devel I
see that it is a building block of the ISP. From the sources, I'm guessing
that it is involved in interfacing a serial sensor data stream to the CCDC, and
would be uninvolved in parallel data from a sensor.
Is the CCP2 indeed documented somewhere for the OMAP35x? Or is this perhaps
only available in the OMAP34x?
In omap34xxcam_video_init(), the media_entity links are activated. In this
if/else there,
if (vdev->vdev_sensor->entity.links[0].sink->entity ==
&isp->isp_csi2a.subdev.entity) {...} else {...}
the assumption is made that a sensor is either connected
A. (sensor->)CSI2A->CCDC or
B. sensor->CCP2->CCDC
but if I'm correct that the CCP2 is related to serial data, there is an option
(C) missing for parallel data: sensor->CCDC. In fact, this is the link that is
created in omap34xxcam_probe() if 'case ISP_INTERFACE_PARALLEL'. Is this
correct, that I would need to add an 'else if' to get parallel data working?
sincerely,
Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
--
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
saa7146 and tda100123 print debug messages at an inappropriate KERN_WARNING/KERN_ERR level
Hello, I do from time to time manage to hang my system in a way where IO-APIC interrupt processing halts. This is probably not related to V4L/DVB. In this situation, the saa7146 and tda10023 will of course fail (cannot blame them for that), and this failure makes them fill the console with pointless debug messages. Which I do blame them for, and is what I'd like to avoid. A typical example of such log messages: Aug 14 08:04:24 canardo kernel: [33080.584008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.612006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.640005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.656005] DVB: TDA10023(1): tda10023_writereg, writereg error (reg == 0x00, val == 0x32, ret == -5) Aug 14 08:04:24 canardo kernel: [33080.668007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.696008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.724018] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.752013] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.768008] DVB: TDA10023(1): tda10023_writereg, writereg error (reg == 0x00, val == 0x33, ret == -5) Aug 14 08:04:24 canardo kernel: [33080.780007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.808009] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.836005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.864005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.880005] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -5) Aug 14 08:04:24 canardo kernel: [33080.892006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.920008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.948006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.976006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33080.992041] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -5) Aug 14 08:04:24 canardo kernel: [33081.004005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.032009] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.060006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.088006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.104004] tda10023: lock tuner fails Aug 14 08:04:24 canardo kernel: [33081.116007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.144007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.172007] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.26] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.228006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.256008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.284006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.312008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.328004] tda10023: unlock tuner fails Aug 14 08:04:24 canardo kernel: [33081.340006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.368008] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.396006] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.424005] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Aug 14 08:04:24 canardo kernel: [33081.440026] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x03, ret == -5)
[PATCH] cx23885: Use enum for board type definitions.
Signed-off-by: Kusanagi Kouichi
---
drivers/media/video/cx23885/cx23885.h | 62 +
1 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885.h
b/drivers/media/video/cx23885/cx23885.h
index ed94b17..55dc282 100644
--- a/drivers/media/video/cx23885/cx23885.h
+++ b/drivers/media/video/cx23885/cx23885.h
@@ -54,36 +54,38 @@
#define BUFFER_TIMEOUT (HZ) /* 0.5 seconds */
-#define CX23885_BOARD_NOAUTO UNSET
-#define CX23885_BOARD_UNKNOWN 0
-#define CX23885_BOARD_HAUPPAUGE_HVR1800lp 1
-#define CX23885_BOARD_HAUPPAUGE_HVR18002
-#define CX23885_BOARD_HAUPPAUGE_HVR12503
-#define CX23885_BOARD_DVICO_FUSIONHDTV_5_EXP 4
-#define CX23885_BOARD_HAUPPAUGE_HVR1500Q 5
-#define CX23885_BOARD_HAUPPAUGE_HVR15006
-#define CX23885_BOARD_HAUPPAUGE_HVR12007
-#define CX23885_BOARD_HAUPPAUGE_HVR17008
-#define CX23885_BOARD_HAUPPAUGE_HVR14009
-#define CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP 10
-#define CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP 11
-#define CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H 12
-#define CX23885_BOARD_COMPRO_VIDEOMATE_E650F 13
-#define CX23885_BOARD_TBS_6920 14
-#define CX23885_BOARD_TEVII_S470 15
-#define CX23885_BOARD_DVBWORLD_200516
-#define CX23885_BOARD_NETUP_DUAL_DVBS2_CI 17
-#define CX23885_BOARD_HAUPPAUGE_HVR127018
-#define CX23885_BOARD_HAUPPAUGE_HVR127519
-#define CX23885_BOARD_HAUPPAUGE_HVR125520
-#define CX23885_BOARD_HAUPPAUGE_HVR121021
-#define CX23885_BOARD_MYGICA_X8506 22
-#define CX23885_BOARD_MAGICPRO_PROHDTVE2 23
-#define CX23885_BOARD_HAUPPAUGE_HVR185024
-#define CX23885_BOARD_COMPRO_VIDEOMATE_E80025
-#define CX23885_BOARD_HAUPPAUGE_HVR129026
-#define CX23885_BOARD_MYGICA_X8558PRO 27
-#define CX23885_BOARD_LEADTEK_WINFAST_PXTV1200 28
+enum {
+ CX23885_BOARD_NOAUTO = UNSET,
+ CX23885_BOARD_UNKNOWN = 0,
+ CX23885_BOARD_HAUPPAUGE_HVR1800lp,
+ CX23885_BOARD_HAUPPAUGE_HVR1800,
+ CX23885_BOARD_HAUPPAUGE_HVR1250,
+ CX23885_BOARD_DVICO_FUSIONHDTV_5_EXP,
+ CX23885_BOARD_HAUPPAUGE_HVR1500Q,
+ CX23885_BOARD_HAUPPAUGE_HVR1500,
+ CX23885_BOARD_HAUPPAUGE_HVR1200,
+ CX23885_BOARD_HAUPPAUGE_HVR1700,
+ CX23885_BOARD_HAUPPAUGE_HVR1400,
+ CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP,
+ CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP,
+ CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H,
+ CX23885_BOARD_COMPRO_VIDEOMATE_E650F,
+ CX23885_BOARD_TBS_6920,
+ CX23885_BOARD_TEVII_S470,
+ CX23885_BOARD_DVBWORLD_2005,
+ CX23885_BOARD_NETUP_DUAL_DVBS2_CI,
+ CX23885_BOARD_HAUPPAUGE_HVR1270,
+ CX23885_BOARD_HAUPPAUGE_HVR1275,
+ CX23885_BOARD_HAUPPAUGE_HVR1255,
+ CX23885_BOARD_HAUPPAUGE_HVR1210,
+ CX23885_BOARD_MYGICA_X8506,
+ CX23885_BOARD_MAGICPRO_PROHDTVE2,
+ CX23885_BOARD_HAUPPAUGE_HVR1850,
+ CX23885_BOARD_COMPRO_VIDEOMATE_E800,
+ CX23885_BOARD_HAUPPAUGE_HVR1290,
+ CX23885_BOARD_MYGICA_X8558PRO,
+ CX23885_BOARD_LEADTEK_WINFAST_PXTV1200
+};
#define GPIO_0 0x0001
#define GPIO_1 0x0002
--
1.7.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
RE: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
Hi Guennadi,
Just reviving an ancient thread.
While working on porting the camera sensor and the camera bridge
drivers to Media Bus I ran into trouble while trying to translate
V4L2_PIX_FMT_JPEG user fourcc to appropriate v4l2_mbus_pixelcode.
I was going to change V4L2_PIX_FMT_JPEG in the old sensor driver to
some v4l2_mbus_pixelcode, but didn't find anything relevant.
When user requests JPEG format in the camera bridge driver I need
to setup the bridge to DMA transparently data from the MIPI CSI
interface, configure MIPI interface to RAW8 and setup the sensor
driver to output JPEG data.
Would it be reasonable to add something like
V4L2_MBUS_FMT_JPEG_1X8 to the list of Media Bus pixel codes?
Would anybody have some better ideas?
Regards,
Sylwester
--
Sylwester Nawrocki
Linux Platform Group
Samsung Poland R&D Center
> -Original Message-
> From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
> Sent: Friday, July 23, 2010 12:43 PM
> To: Sylwester Nawrocki
> Cc: 'Laurent Pinchart'; 'Linux Media Mailing List'; 'Hans Verkuil'
> Subject: RE: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
>
> Hi Sylwester
>
> On Fri, 23 Jul 2010, Sylwester Nawrocki wrote:
>
> > Hi Laurent,
> >
> > > -Original Message-
> > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
> > > Sent: Friday, July 23, 2010 10:35 AM
> > > To: Guennadi Liakhovetski
> > > Cc: Linux Media Mailing List; Hans Verkuil
> > > Subject: Re: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
> > >
> > > Hi Guennadi,
> > >
> > > On Friday 23 July 2010 10:13:37 Guennadi Liakhovetski wrote:
> > > > Add pixel format codes, defined in the MIPI CSI-2 specification.
> > > >
> > > > Signed-off-by: Guennadi Liakhovetski
> > > > ---
> > > >
> > > > Even though it affects the same enum as my patch from yesterday,
> they
> > > are
> > > > independent, Hans and Laurent CCed just to avoid possible
> conflicts,
> > > when
> > > > further patching this file.
> > > >
> > > > include/media/v4l2-mediabus.h | 26 ++
> > > > 1 files changed, 26 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-
> > > mediabus.h
> > > > index a870965..b0dcace 100644
> > > > --- a/include/media/v4l2-mediabus.h
> > > > +++ b/include/media/v4l2-mediabus.h
> > > > @@ -41,6 +41,32 @@ enum v4l2_mbus_pixelcode {
> > > > V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
> > > > V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
> > > > V4L2_MBUS_FMT_SGRBG8_1X8,
> > > > + /* MIPI CSI-2 codes */
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_L,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_CSPS,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10_CSPS,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV422_8,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_YUV422_10,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RGB888,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RGB666,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RGB565,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RGB555,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RGB444,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RAW6,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RAW7,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RAW8,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RAW10,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RAW12,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_RAW14,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_GEN_NULL,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_GEN_BLANKING,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_GEN_EMBEDDED8,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_USER_1,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_USER_2,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_USER_3,
> > > > + V4L2_MBUS_FMT_MIPI_CSI2_USER_4,
> > >
> > > I don't think I like this. Take the raw formats for instance,
> they're
> > > used for
> > > Bayer RGB. V4L2_MBUS_FMT_MIPI_CSI2_RAW8 could map to any Bayer
> format
> > > (GRBG,
> > > RGGB, ...). Why don't we just use "standard" pixel codes ?
> >
> > As far as I understand on some media buses exact pixel formats are
> not
> > defined,
> > although we still need information to configure the bus.
> > MIPI CSI-2 seem an example of such to me, e.g. we do configure MIPI
> > interface
> > to "*_USER_1" format but over the bus is transferred JPEG data.
> > I guess we could try to use "standard" pixel codes but then we would
> > probably have
> > to map from "any" format to specific MIPI format code to configure
> the
> > hardware.
> > Moreover MIPI formats are quite specific, for instance for RAW12 in
> 32-bit
> > sample
> > (from MSb to LSb) we have dummy 8-bits, then 12-bit of actual data
> and
> > remaining
> > 12 dummy bits.
>
> I think, we have to approach this problem from the other side - from
> the
> user perspective. A "RAW8" format tells nothing to mplayer or
> gstreamer,
> whereas they shal
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Saturday, August 14, 2010 08:33:09 pm Guennadi Liakhovetski wrote: > On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: > > > Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): > > > On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: > > > > On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: > > > > > Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): > > > > > > 1. We've discussed this dynamic switching a bit on IRC today. The > > > > > > first reaction was - you probably should concentrate on getting the > > > > > > contiguous version to work reliably. I.e., to reserve the memory in > > > > > > the board init code similar, how other contig users currently do it. > > > > > > > > > > I already tried before to find out how I could allocate memory at init > > > > > without reinventing a new videobuf-dma-contig implementation. Since in > > > > > the Documentation/video4linux/videobuf I've read that videobuf does > > > > > not > > > > > currently play well with drivers that play tricks by allocating DMA > > > > > space at system boot time, I've implemented the alternate sg path. > > > > > > > > > > If it's not quite true what the documentation says and you can give me > > > > > a hint how this could be done, I might try again. > > > > > > > > For an example look at > > > > arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). > > > > Yes, this is the solution that suffers from the already discussed > > limitation > > of not being able to remap a memory with different attributes, which > > affects > > OMAP1 as well. > > > > > For preallocating dma-coherent memory for device personal use during > > > device > > > probe() time (when the memory is less fragmented compared to open() time) > > > see also dt3155_alloc_coherent/dt3155_free_coherent in > > > drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it > > > works for arm arch) > > > > With this workaround applied, I get much better results, thank you Marin. > > However, it seems not bullet proof, since mmap still happens to fail for a > > reason not quite clear to me: > > What exactly does this mean - happens to fail - you mean starting and > stopping mplayer several times? Can you verify, that you're not leaking > memory? That you're freeing all allocated DMA memory again? Are you using > the same parameters to mplayer, right? > > As for the work-around - can you not do this in your board late-initcall > function? > > Not sure whether and how one can get this in the mainline. This is in > principle the same, as in the above dma_declare_coherent_memory() example, > only open-coded without the ioremap. My believe is that dma_declare_coherent_memory() could be used if your frame grabber has local RAM buffer (like video buffer if the graphic adapters) defined by BAR - that is why you need ioremap(). If this RAM turns out to be coherent you use dma_declare_coherent_memory() and any further invocation of dma_alloc_coherent() will allocate from it (till it is exosted). My use of dt3155_alloc_coherent()/dt3155_free_coherent() is to allocate a block of coherent 4MB memory during driver probe() method and use it latter (via videobuff_dma_contig framework)). > Maybe we can add a suitable function > to the dma-alloc API... Could be of general use, I am thinking about this. This could be done by just renaming dt3155_alloc_coherent()/dt3155_free_coherent() to something acceptable (dma_reserve_coherent_memory()/dma_release_reserved_memory(), I am open for suggestions) and export them. Should be added to drivers/base/dma-coherent.c. Marin Mitov > > Thanks > Guennadi > > > > > [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to > > camera 0 > > [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format > > 32315659 not found > > [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format > > 32315559 not found > > [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 > > [ 6068.50] Backtrace: > > [ 6068.52] [] (dump_backtrace+0x0/0x110) from [] > > (dump_stack+0x18/0x1c) > > [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 > > [ 6068.59] [] (dump_stack+0x0/0x1c) from [] > > (__alloc_pages_nodemask+0x504/0x560) > > [ 6068.62] [] (__alloc_pages_nodemask+0x0/0x560) from > > [] (__dma_alloc+0x108/0x354) > > [ 6068.66] [] (__dma_alloc+0x0/0x354) from [] > > (dma_alloc_coherent+0x58/0x64) > > [ 6068.70] [] (dma_alloc_coherent+0x0/0x64) from [] > > (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) > > [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: > > [ 6068.77] [] (__videobuf_mmap_mapper+0x0/0x374 > > [videobuf_dma_contig]) from [] (videobuf_mmap_mapper+0xc4/0x108) > > [ 6068.81] [] (videobuf_mmap_mapper+0x0/0x108) from > > [] (soc_camera_mmap+0x80/0x140) > > [ 6068.84] r5:c1a3b4e0 r4: > > [ 6068.87] [] (soc_camera_mmap+0x0/0x140) from [
Re: Error building v4l
Ok! Now it works! Thank you very much, Xwang Il 16/08/2010 04:59, Douglas Schilling Landgraf ha scritto: Hello, On Sat, Aug 14, 2010 at 3:34 AM, andrea.amoros...@gmail.com wrote: Building the v4l, I obtain the following error: home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l/mceusb.c: In function 'mceusb_dev_probe': /home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l/mceusb.c:923: error: implicit declaration of function 'usb_alloc_coherent' /home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l/mceusb.c:923: warning: assignment makes pointer from integer without a cast /home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l/mceusb.c:1003: error: implicit declaration of function 'usb_free_coherent' make[3]: *** [/home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l/mceusb.o] Error 1 make[2]: *** [_module_/home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic' make[1]: *** [default] Errore 2 make[1]: uscita dalla directory «/home/andreak/src/v4l-dvb-src/v4l-dvb-main/v4l-dvb/v4l» make: *** [all] Errore 2 My system is a Kubuntu 10.04 amd64 with kernel 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 x86_64 GNU/Linux How can I solve? Please download the new patches available and try again. Cheers Douglas -- 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
