Re: gspca-sonixj: ioctl VIDIOC_DQBUF blocks for 3s and retuns EIO
On Thu, 13 May 2010 17:58:49 +0200 Frank Schaefer fschaefer@googlemail.com wrote: I'm not sure if I'm hitting a bug or this is the expected driver behavior: With a Microsoft LifeCam VX-3000 (045e:00f5) and gspca-sonixj, ioctl VIDIOC_DQBUF intermittently blocks for exactly 3 seconds and then returns EIO. I noticed that it strongly depends on the captured scenery: when it's changing much, everything is fine. But when for example capturing the wall under constant (lower) light conditions, I'm getting this error nearly permanently. It's a JPEG-device, so I guess the device stops sending data if the picture doesn't change and that's how it should be. But is the long blocking + EIO the way drivers should handle this situtation ? Hello Frank, You are right, this is a bug. I did not know that a webcam could suspend streaming when the image did not change. I will remove the timeout. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] media/IR: Add missing include file to rc-map.c
On Tue, May 11, 2010 at 08:42:14PM +0200, Peter H?we wrote: Am Mittwoch 05 Mai 2010 17:20:21 schrieb Peter H?we: From: Peter Huewe peterhu...@gmx.de This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe peterhu...@gmx.de --- Any updates on this patch? Issue still exists with today's linux-next tree You might want to send this to the linux-next list at least. If the people who introduced the breakage are unresponsive (as often tends to be the case with -next) it's still worth getting trivial fixes rolled in for the interim. This change doesn't exist outside of -next and whatever tree introduced it, so there's not much else anyone can do about it at present. -- 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] media/IR: Add missing include file to rc-map.c
From: Peter Huewe peterhu...@gmx.de This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe peterhu...@gmx.de --- Forwarded to linux-next mailing list - breakage still exists in linux-next of 20100514 - please apply KernelVersion: linux-next-20100505 References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2571452/ [2] http://kisskb.ellerman.id.au/kisskb/buildresult/2571188/ [3] http://kisskb.ellerman.id.au/kisskb/buildresult/2571479/ [4] http://kisskb.ellerman.id.au/kisskb/buildresult/2571429/ [5] http://kisskb.ellerman.id.au/kisskb/buildresult/2571432/ drivers/media/IR/rc-map.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c index caf6a27..46a8f15 100644 --- a/drivers/media/IR/rc-map.c +++ b/drivers/media/IR/rc-map.c @@ -14,6 +14,7 @@ #include media/ir-core.h #include linux/spinlock.h +#include linux/delay.h /* Used to handle IR raw handler extensions */ static LIST_HEAD(rc_map_list); -- 1.6.4.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
Re: AF9015 suspend problem
On 05/14/2010 03:50 AM, Jose Alberto Reguero wrote: El Jueves, 13 de Mayo de 2010, Antti Palosaari escribió: Terve! On 05/02/2010 06:39 PM, Jose Alberto Reguero wrote: When I have a af9015 DVB-T stick plugged I can not recover from pc suspend. I must unplug the stick to suspend work. Even if I remove the modules I cannot recover from suspend. Any idea why this happen? Did you asked this 7 months ago from me? I did some tests (http://linuxtv.org/hg/~anttip/suspend/) and looks like it is firmware loader problem (fw loader misses something or like that...). No one answered when I asked that from ML, but few weeks ago I saw some discussion. Look ML archives. regards Antti I think that is another problem. If I blacklist the af9015 driver and have the stick plugged in, the suspend don't finish, and the system can't resume. If I unplugg the stick the suspend feature work well. Look these and check if it is same problem: DVB USB resume from suspend crash http://www.mail-archive.com/linux-media@vger.kernel.org/msg09974.html Re: tuner XC5000 race condition?? http://www.mail-archive.com/linux-media@vger.kernel.org/msg18012.html Bug 15294 - Oops due to an apparent race between udev and a timeout in firmware_class.c https://bugzilla.kernel.org/show_bug.cgi?id=15294 I haven't examined those yet, but I think they could be coming from same issue. br, 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
[RFC] Add 12 bit RAW Bayer Pattern pixel format support in V4L2
Hi linux-media,
Current V4l2 only support 8 bit and 10 bit RAW Bayer Patten pixel format and
this is a RFC to add 12 bit RAW Bay pixel format support by 4 more pixel format
definition in videodev2.h.
The 12 bit RAW Bayer Pattern pixel format is not a platform specific and is
available in mainstream digital camera devices. It will be supported by the ISP
on Intel Atom platform.
The current 8 bit/10 bit RAW Bayer Pattern pixel format definitions are listed
as in below,
/* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */
#define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG..
GRGR.. */
#define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB..
RGRG.. */
#define V4L2_PIX_FMT_SGRBG8 v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR..
BGBG.. */
#define V4L2_PIX_FMT_SRGGB8 v4l2_fourcc('R', 'G', 'G', 'B') /* 8 RGRG..
GBGB.. */
#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10 BGBG..
GRGR.. */
#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB..
RGRG.. */
#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR..
BGBG.. */
#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG..
GBGB.. */
I am proposing to add 4 more pixel format definition in similar with existing
ones listed as in below, welcome any comment and suggestion.
#define V4L2_PIX_FMT_SBGGR12 v4l2_fourcc('B', 'G', '1', '2') /* 12 BGBG..
GRGR.. */
#define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB..
RGRG.. */
#define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR..
BGBG.. */
#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG..
GBGB.. */
BRs
BRs
Xiaolin
--
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] media/IR: Add missing include file to rc-map.c
Hi Peter, On Fri, 14 May 2010 13:26:51 +0200 Peter Hüwe peterhu...@gmx.de wrote: From: Peter Huewe peterhu...@gmx.de This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe peterhu...@gmx.de --- Forwarded to linux-next mailing list - breakage still exists in linux-next of 20100514 - please apply This patch was included in the v4l-dvb tree (and thus linux-next) today -see commit 1e19cb4e7d15d724cf2c6ae23f0b871c84a92790. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp3dfEhgaylV.pgp Description: PGP signature
Digitus USB 2.0. High Resolution Video Grabber
Hello, I've got Digitus USB 2.0. High Resolution Video Grabber http://www.digitus.info/en/products/multimedia/?c=1162p=17157 and when I plugged it into my Fedora 12 Linux box I got this messages. Digitus is not listed among known devices. Can you fix it? Regards, Martin E. usb 1-4: new high speed USB device using ehci_hcd and address 4 usb 1-4: New USB device found, idVendor=eb1a, idProduct=2821 usb 1-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-4: Product: USB 2821 Device usb 1-4: configuration #1 chosen from 1 choice Linux video capture interface: v2.00 em28xx: New device USB 2821 Device @ 480 Mbps (eb1a:2821, interface 0, class 0) em28xx #0: chip ID is em2820 (or em2710) em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 21 28 90 00 11 03 6a 22 00 00 em28xx #0: i2c eeprom 10: 00 00 04 57 06 21 01 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 02 00 01 01 f0 10 00 00 00 00 00 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 03 01 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 32 00 31 00 20 00 44 00 em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x37da7b8a em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: 500mA max power em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) em28xx #0: found i2c device @ 0x4a [saa7113h] em28xx #0: found i2c device @ 0xa0 [eeprom] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. em28xx #0: You may try to use card=n insmod option to workaround that. em28xx #0: Please send an email with this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board eeprom hash is 0x37da7b8a em28xx #0: Board i2c devicelist hash is 0x6ba50080 em28xx #0: Here is a list of valid choices for the card=n insmod option: em28xx #0: card=0 - Unknown EM2800 video grabber em28xx #0: card=1 - Unknown EM2750/28xx video grabber em28xx #0: card=2 - Terratec Cinergy 250 USB em28xx #0: card=3 - Pinnacle PCTV USB 2 em28xx #0: card=4 - Hauppauge WinTV USB 2 em28xx #0: card=5 - MSI VOX USB 2.0 em28xx #0: card=6 - Terratec Cinergy 200 USB em28xx #0: card=7 - Leadtek Winfast USB II em28xx #0: card=8 - Kworld USB2800 em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 em28xx #0: card=10 - Hauppauge WinTV HVR 900 em28xx #0: card=11 - Terratec Hybrid XS em28xx #0: card=12 - Kworld PVR TV 2800 RF em28xx #0: card=13 - Terratec Prodigy XS em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 em28xx #0: card=15 - V-Gear PocketTV em28xx #0: card=16 - Hauppauge WinTV HVR 950 em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) em28xx #0: card=19 - EM2860/SAA711X Reference Design em28xx #0: card=20 - AMD ATI TV Wonder HD 600 em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber em28xx #0: card=23 - Huaqi DLCW-130 em28xx #0: card=24 - D-Link DUB-T210 TV Tuner em28xx #0: card=25 - Gadmei UTV310 em28xx #0: card=26 - Hercules Smart TV USB 2.0 em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) em28xx #0: card=28 - Leadtek Winfast USB II Deluxe em28xx #0: card=29 - NULL em28xx #0: card=30 - Videology 20K14XUSB USB2.0 em28xx #0: card=31 - Usbgear VD204v9 em28xx #0: card=32 - Supercomp USB 2.0 TV em28xx #0: card=33 - NULL em28xx #0: card=34 - Terratec Cinergy A Hybrid XS em28xx #0: card=35 - Typhoon DVD Maker em28xx #0: card=36 - NetGMBH Cam em28xx #0: card=37 - Gadmei UTV330 em28xx #0: card=38 - Yakumo MovieMixer em28xx #0: card=39 - KWorld PVRTV 300U em28xx #0: card=40 - Plextor ConvertX PX-TV100U em28xx #0: card=41 - Kworld 350 U DVB-T em28xx #0: card=42 - Kworld 355 U DVB-T em28xx #0: card=43 - Terratec Cinergy T XS em28xx #0: card=44 - Terratec Cinergy T XS (MT2060) em28xx #0: card=45 - Pinnacle PCTV DVB-T em28xx #0:
[PATCH -next] IR: fix ir-nec-decoder build, select BITREVERSE
From: Randy Dunlap randy.dun...@oracle.com Fix ir-nec-decoder build: it uses bitrev library code, so select BITREVERSE in its Kconfig. ir-nec-decoder.c:(.text+0x1a2517): undefined reference to `byte_rev_table' ir-nec-decoder.c:(.text+0x1a2526): undefined reference to `byte_rev_table' ir-nec-decoder.c:(.text+0x1a2530): undefined reference to `byte_rev_table' ir-nec-decoder.c:(.text+0x1a2539): undefined reference to `byte_rev_table' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/IR/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20100514.orig/drivers/media/IR/Kconfig +++ linux-next-20100514/drivers/media/IR/Kconfig @@ -13,6 +13,7 @@ source drivers/media/IR/keymaps/Kconfig config IR_NEC_DECODER tristate Enable IR raw decoder for the NEC protocol depends on IR_CORE + select BITREVERSE default y ---help--- -- 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: Stuck Digittrade DVB-T stick (dvb_usb_af9015)
Terve On 05/14/2010 02:17 PM, marc balta wrote: would be nice because it is happening rather often : Every second or third day. Is there a way to reinit the device with a script wihtout restarting my server and without influencing other usb devices. If yes I could reinit the device say two minutes before every recording starts using a hook. This would solve my problems. I just added support for new firmware 5.1.0.0. Please test if it helps. http://linuxtv.org/hg/~anttip/af9015/ http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stuck Digittrade DVB-T stick (dvb_usb_af9015)
Thx for responding so fast. Ok I have updated: May 14 20:11:57 debian kernel: af9013: firmware version:5.1.0 May 14 20:11:57 debian kernel: DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... May 14 20:11:57 debian kernel: MT2060: successfully identified (IF1 = 1220) Now lets wait 3 days ... Greetings, Marc --- Antti Palosaari cr...@iki.fi schrieb am Fr, 14.5.2010: Von: Antti Palosaari cr...@iki.fi Betreff: Re: Stuck Digittrade DVB-T stick (dvb_usb_af9015) An: marc balta marc_ba...@yahoo.de CC: linux-media@vger.kernel.org Datum: Freitag, 14. Mai, 2010 19:16 Uhr Terve On 05/14/2010 02:17 PM, marc balta wrote: would be nice because it is happening rather often : Every second or third day. Is there a way to reinit the device with a script wihtout restarting my server and without influencing other usb devices. If yes I could reinit the device say two minutes before every recording starts using a hook. This would solve my problems. I just added support for new firmware 5.1.0.0. Please test if it helps. http://linuxtv.org/hg/~anttip/af9015/ http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] 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:Fri May 14 19:00:20 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14851:16ade09022d9 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 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-rc7-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc7-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc7-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc7-armv5-omap2: ERRORS 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: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc7-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc7-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc7-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc7-powerpc64: ERRORS 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: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc7-x86_64: ERRORS 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca-sonixj: ioctl VIDIOC_DQBUF blocks for 3s and retuns EIO
Hans de Goede schrieb: Hi, On 05/14/2010 08:00 AM, Jean-Francois Moine wrote: On Thu, 13 May 2010 17:58:49 +0200 Frank Schaeferfschaefer@googlemail.com wrote: I'm not sure if I'm hitting a bug or this is the expected driver behavior: With a Microsoft LifeCam VX-3000 (045e:00f5) and gspca-sonixj, ioctl VIDIOC_DQBUF intermittently blocks for exactly 3 seconds and then returns EIO. I noticed that it strongly depends on the captured scenery: when it's changing much, everything is fine. But when for example capturing the wall under constant (lower) light conditions, I'm getting this error nearly permanently. It's a JPEG-device, so I guess the device stops sending data if the picture doesn't change and that's how it should be. But is the long blocking + EIO the way drivers should handle this situtation ? Hello Frank, You are right, this is a bug. I did not know that a webcam could suspend streaming when the image did not change. I will remove the timeout. The way jpeg works mandates that for each block some data still needs to be generated even if it is a solid color, moreover as these cams do jpeg not mpeg, there is no delta towards the previous frame. So the cam should not stop streaming if it doe timing out and returning -EIO is appropriate. Thus we should not remove the DQBUF timeout IMHO. Urgh, sorry, of course jpeg is not mpeg ! So the device *should* not stop sending frames, which means that I will have to find out what's exactly going on in the kernel... Will need some time, I don't have permanent access to this device. Thanks so far, Frank -- 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: CEU / Camera Driver Question
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt() option,
I setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function to
do the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width= p-format.width;
mf-height = p-format.height;
mf-code = p-format.code;
mf-colorspace = p-format.colorspace;
mf-field= p-format.field;
return 0;
}
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from the
information I have received from Renesas, I'm not seeing any reason why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the call
is made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional
parameter from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Thank you,
Charles Krebs, Embedded Solutions Developer
The Realtime Group
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Tuesday, May 04, 2010 1:43 AM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org; Magnus Damm
magnus.d...@gmail.com
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Mon, 3 May 2010, Charles D. Krebs wrote:
Guennadi,
As per your recommendation I reviewed the soc_camera_platform driver,
and
have chosen to implement the new camera by simply modifying it.
Sure enough, I can boot up and properly register a device under
/dev/video0.
The camera provides 8-bit Grayscale data corresponding to pixel format
V4L2_PIX_FMT_GREY. I can't seem to find any example of a device driver
that
uses this format, so I've been taking my best guess as how to setup
soc_camera_platform_info. So far I have:
static struct soc_camera_platform_info mycam_camera_info = {
.format_name = GREY,
.format_depth = 8,
.format = {
.code = V4L2_MBUS_FMT_YUYV8_2X8_BE,
No, you should be using V4L2_MBUS_FMT_GREY8_1X8 for grey.
.colorspace = V4L2_COLORSPACE_JPEG,
.field = V4L2_FIELD_NONE,
.width = 320,
.height = 240,
},
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
};
It looks like I'll need to modify soc_camera_platform it in a way to at
least add a fourcc field that can be interpreted by the ceu driver for
the
sh_mobile_ceu_set_bus_param call to setup the hardware correctly.
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
But regardless of how I set this structure up, I don't see any direct
support
for
Re: CEU / Camera Driver Question
Hi Charles
On Fri, 14 May 2010, Charles D. Krebs wrote:
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt() option, I
setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function to do
the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width = p-format.width;
mf-height = p-format.height;
mf-code= p-format.code;
mf-colorspace = p-format.colorspace;
mf-field = p-format.field;
return 0;
}
How is this different from this patch from Morimoto-san:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19191
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from the
information I have received from Renesas, I'm not seeing any reason why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the call is
made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional parameter
from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Have you set up platform data similar to struct soc_camera_link
camera_link in arch/sh/boards/mach-ap325rxa/setup.c. The
soc_camera_platform.c driver should be getting pixel format information
from the static struct soc_camera_platform_info, doesn't this work for
you?
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: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi, Am Donnerstag, den 13.05.2010, 15:45 -0300 schrieb Mauro Carvalho Chehab: Mauro Carvalho Chehab wrote: hermann pitton wrote: My view is that the backport tree is very useful to have a broader number of people testing V4L/DVB code, as it can be applied against legacy kernels. Of course, for this to work, people should quickly fix broken backports (that means that not only Douglas should work on it, but other developers are welcomed to contribute with backport fixes). For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb then to provide relevant debug output and eventually patches. Until Douglas or someone fix the breakages with older kernels, yes. As the fix patch is really trivial, I found a couple of minutes to write a patch for fixing this issue. I haven't test the patch, but, as it uses the same backport logic as found at cx2355-ir, I don't expect much troubles on it. Mauro, fine, it is a start. Compiles down to to 2.6.30, but has some __check_debug warnings for three static bool insmod options there. (build cron job of today) To replace them with some int seems ok, but since no such warnings on higher kernels for bool, likely some compat issue. IR oopses on 2.6.30 with Pinnacle 310i on a first try. Thanks for all explanations of the current sync procedures, Douglas does well and four weeks without in depth backward compat are hard to avoid either way. Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after the merge window. Cheers, Hermann saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 5-004b: chip found @ 0x96 (saa7133[1]) tda829x 5-004b: setting tuner address to 61 tda829x 5-004b: type set to tda8290+75a saa7133[1]: registered device video1 [v4l2] saa7133[1]: registered device vbi1 saa7133[1]: registered device radio1 saa7133[2]: setting pci latency timer to 64 saa7133[2]: found at :02:09.0, rev: 208, irq: 19, latency: 64, mmio: 0xfdefd000 saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[2]: board init: gpio is 600c000 IRQ 19/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 6-004b: chip found @ 0x96 (saa7133[2]) tda829x 6-004b: setting tuner address to 61 tda829x 6-004b: type set to tda8290+75a Registered IR keymap rc-pinnacle-color input: i2c IR (Pinnacle PCTV) as /devices/virtual/input/input8 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core] PGD 3ecbd067 PUD 2006b067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/module/saa7134/initstate CPU 0 Modules linked in: rc_pinnacle_color ir_kbd_i2c(+) tda827x tda8290 tuner saa7134(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core ir_common ir_core tveeprom sit tunnel4 fuse bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer r8169 ppdev snd mii soundcore snd_page_alloc parport_pc shpchp k8temp parport hwmon joydev floppy serio_raw pcspkr i2c_nforce2 ata_generic pata_acpi pata_amd radeon drm i2c_algo_bit i2c_core [last unloaded: v4l1_compat] Pid: 3399, comm: modprobe Not tainted 2.6.30.10-105.2.16.fc11.x86_64 #1 RIP: 0010:[a00e97c7] [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core] RSP: 0018:88003b459cb8 EFLAGS: 00010246 RAX:
Re: CEU / Camera Driver Question
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Friday, May 14, 2010 3:38 PM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Fri, 14 May 2010, Charles D. Krebs wrote:
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about
fourcc
codes, that belongs to the user side of the pixel format handling API.
The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch
welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt()
option, I
setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function
to do
the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width = p-format.width;
mf-height = p-format.height;
mf-code = p-format.code;
mf-colorspace = p-format.colorspace;
mf-field = p-format.field;
return 0;
}
How is this different from this patch from Morimoto-san:
You're right - It's not a whole lot different other than I didn't add the
scaling functions to the sub commands.
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19191
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in
its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from
the
information I have received from Renesas, I'm not seeing any reason
why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there
are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image
data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the
call is
made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional
parameter
from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Have you set up platform data similar to struct soc_camera_link
camera_link in arch/sh/boards/mach-ap325rxa/setup.c. The
soc_camera_platform.c driver should be getting pixel format information
from the static struct soc_camera_platform_info, doesn't this work for
you?
I have that structure setup as follows:
static struct soc_camera_platform_info mycamera_camera_info = {
.format_name = GREY,
.format_depth = 8,
.format = {
.code = V4L2_MBUS_FMT_GREY8_1X8,
.colorspace = V4L2_COLORSPACE_JPEG, //V4L2_COLORSPACE_SMPTE170M,
.field = V4L2_FIELD_NONE,
.width = 320,
.height = 240,
},
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
.set_capture = mycamera_camera_set_capture,
};
I would have thought that the pixel format information would have filtered
back thorough the stack to the host driver, but...
In sh_mobile_ceu_set_fmt we have:
static int sh_mobile_ceu_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
{
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
struct sh_mobile_ceu_dev *pcdev = ici-priv;
struct sh_mobile_ceu_cam *cam = icd-host_priv;
struct v4l2_pix_format *pix = f-fmt.pix;
struct v4l2_mbus_framefmt mf;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct device *dev = icd-dev.parent;
__u32 pixfmt = pix-pixelformat;
const struct soc_camera_format_xlate *xlate;
struct v4l2_crop cam_crop;
struct v4l2_rect
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi, [snip] Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after the merge window. The saa7134 card=2 gpio remote is OK on 2.6.33.4 with current v4l-dvb. Sander, let's know about further questions. 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: CEU / Camera Driver Question
Guennadi,
Thank you for making me aware of the patch that Morimoto-San composed.
Implementing the remaining sub commands fixes the issues I was seeing. It's
rather ironic that he was working on that at the same time I was.
I'm now working through a minor userspace application issue and expect to
have the overall demo application working shortly to stream video with this
new camera. Thanks for all of your help and patience.
If I need to make changes to either soc_camera_platform or the ceu driver,
I'll be sure to submit patch proposals to that effect.
Best regards,
Charles Krebs, Embedded Solutions Developer
The Realtime Group
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Friday, May 14, 2010 3:38 PM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Fri, 14 May 2010, Charles D. Krebs wrote:
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about
fourcc
codes, that belongs to the user side of the pixel format handling API.
The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch
welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt()
option, I
setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function
to do
the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width = p-format.width;
mf-height = p-format.height;
mf-code = p-format.code;
mf-colorspace = p-format.colorspace;
mf-field = p-format.field;
return 0;
}
How is this different from this patch from Morimoto-san:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19191
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in
its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from
the
information I have received from Renesas, I'm not seeing any reason
why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there
are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image
data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the
call is
made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional
parameter
from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Have you set up platform data similar to struct soc_camera_link
camera_link in arch/sh/boards/mach-ap325rxa/setup.c. The
soc_camera_platform.c driver should be getting pixel format information
from the static struct soc_camera_platform_info, doesn't this work for
you?
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
