isp or soc-camera for image co-processors
Hi Guennadi and Laurent, We are now evaluating another ST platform that supports a image co-processor between the camera sensor and the camera host (SoC). The simple architecture diagram will be similar to one shown below (for the sake of simplicity I show only a single sensor. At least two sensors can be supported by the co-processor): CSI-2 interface CSI2 interface -- |Camera sensor |<---> |CSI2 CSI2 |<---=--> |SoC (ARM Based)| |0 ||serial serial| | | | ||receiver transmitter | | | | |CCI Interface | | | | ||<---> |CCICCI |CCI/I2C Interface| | | ||master slave |<--> | | | | | | | |SYNC signals | | | ITU |---> | | | CCIR|Pixel CLK | | | Interface|---> | | | |ITU Data | | | |---> | | |Image video| | | |Processorprocessing| | | | logic | | | - --- The co-processor supports a video progressing logic engine capable of performing a variety of operations like image recovery, cropping, scaling, gamma correction etc. Now, evaluating the framework available for supporting for the camera host, sensor and co-processor, I am wondering whether soc-camera(v4l2) can support this complex design or something similar to the ISP driver written for OMAP is the way forward. Any pointers on the same and reference links to some documentation will be highly appreciated. Thanks for your help, Regards, Bhupesh ST Microelectonics -- 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] tm6000: add audio conf for new cards
Hi Add configuration of an audio for our new TV cards. diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index a356ba7..88144a1 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -324,6 +324,8 @@ struct tm6000_board tm6000_boards[] = { .tuner_addr = 0xc2 >> 1, .demod_addr = 0x1e >> 1, .type = TM6010, + .avideo = TM6000_AIP_SIF1, + .aradio = TM6000_AIP_LINE1, .caps = { .has_tuner= 1, .has_dvb = 1, @@ -341,6 +343,8 @@ struct tm6000_board tm6000_boards[] = { .tuner_type = TUNER_XC5000, .tuner_addr = 0xc2 >> 1, .type = TM6010, + .avideo = TM6000_AIP_SIF1, + .aradio = TM6000_AIP_LINE1, .caps = { .has_tuner= 1, .has_dvb = 0, Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov With my best regards, Dmitry. diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index a356ba7..88144a1 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -324,6 +324,8 @@ struct tm6000_board tm6000_boards[] = { .tuner_addr = 0xc2 >> 1, .demod_addr = 0x1e >> 1, .type = TM6010, + .avideo = TM6000_AIP_SIF1, + .aradio = TM6000_AIP_LINE1, .caps = { .has_tuner= 1, .has_dvb = 1, @@ -341,6 +343,8 @@ struct tm6000_board tm6000_boards[] = { .tuner_type = TUNER_XC5000, .tuner_addr = 0xc2 >> 1, .type = TM6010, + .avideo = TM6000_AIP_SIF1, + .aradio = TM6000_AIP_LINE1, .caps = { .has_tuner= 1, .has_dvb = 0, Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
В сообщении от 1 марта 2011 00:24:32 автор Mariusz Bialonczyk написал: > On 02/28/2011 09:37 PM, Igor M. Liplianin wrote: > > Sorry, I have nothing against you personally. > > me too :) > > > I have excuses, but you not intresting, I think. > > Peace, friendship, chewing gum, like we use to say in my childhood :) > > > > Switching to other driver not helps me, so be patient. > > > > I patched stv0900 and send pull request. > > I've tested it - and for the first sight it seems that it indeed > solves the problem. Thank you :) > > And about frontend: I think I found a solution which I hope will > satisfy all of us. I think it would be great if user have > an alternative option to use stv090x frontend anyway. I mean your > frontend as default, but a module parameter which enables using > stv090x instead of stv0900 (enabling what's is inside my patch). > This will be a flexible solution which shouldn't harm anyone, > but instead gives an option. > > Igor, Mauro, do you have objections against this solution? > If you agree, then I'll try to prepare an RFC patch for that. Well, I didn't change my mind. There is not an option, but splitting efforts in two ways. > > regards, -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote: > On Mon, 28 Feb 2011, Hans Verkuil wrote: > > > Does anyone know which drivers stop capture if there are no buffers > > available? > > I'm not aware of any. > > Many soc-camera hosts do that. > > > I think this is certainly a good initial approach. > > > > Can someone make a list of things needed for flash/snapshot? So don't look > > yet > > at the implementation, but just start a list of functionalities that we > > need > > to support. I don't think I have seen that yet. > > These are not the features, that we _have_ to implement, these are just > the ones, that are related to the snapshot mode: > > * flash strobe (provided, we do not want to control its timing from > generic controls, and leave that to "reasonable defaults" or to > private controls) > * trigger pin / command > * external exposure > * exposure mode (ERS, GRR,...) > * use "trigger" or "shutter" for readout > * number of frames to capture Add * multiple videobuffer queues to the list Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MCEUSB: falsly claims mass storage device
On Feb 17, 2011, at 6:46 AM, Lucian Muresan wrote: > On 09.02.2011 06:19, Jarod Wilson wrote: > [...] >> Looks like bInterfaceNumber == 2 on this device. The patch to handle this >> similar to the conexant polaris devices should be pretty trivial. I'll >> try to get something together tomorrow. > > Hi, > > any news on this one? I suck, but I have a patch in my local tree now. Need to build and quickly test it to make sure it doesn't break the devices I've got, then I'll get it posted. -- 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: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
On 02/28/2011 09:37 PM, Igor M. Liplianin wrote: > Sorry, I have nothing against you personally. me too :) > I have excuses, but you not intresting, I think. > Peace, friendship, chewing gum, like we use to say in my childhood :) > > Switching to other driver not helps me, so be patient. > > I patched stv0900 and send pull request. I've tested it - and for the first sight it seems that it indeed solves the problem. Thank you :) And about frontend: I think I found a solution which I hope will satisfy all of us. I think it would be great if user have an alternative option to use stv090x frontend anyway. I mean your frontend as default, but a module parameter which enables using stv090x instead of stv0900 (enabling what's is inside my patch). This will be a flexible solution which shouldn't harm anyone, but instead gives an option. Igor, Mauro, do you have objections against this solution? If you agree, then I'll try to prepare an RFC patch for that. regards, -- Mariusz Bialonczyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net -- 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: WinTV HVR-900 (usb 2040:6500) (model 65008) / no audio but clicking noise
Hi! Since I really need analog TV support, I would like to bring this up again... :-) Now i hacked the em28xx module, so that it would try to get the audio data via the em28xx_alsa module... But that fails in the usb_submit_urb() call in the em28xx_init_audio_isoc() function, because: wMaxPacketSize of endpoint 0x83 is 0... Does someone still know how em28xx_alsa was to be used properly? Is there some specialist, that could help me? Markus R. doesnt like to do open src things anymore, or did I misunderstand that? Btw: I have an em2882/em2883 chip, which needs to be handled by the em28xx_alsa module according to this page: http://www.linuxtv.org/wiki/index.php/Em28xx_devices#em2880.2F2881.2F2883 Here is the em28xx related syslog from my box: https://bugzilla.redhat.com/attachment.cgi?id=481332 Bye Arne -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
В сообщении от 28 февраля 2011 21:45:46 автор Mariusz Bialonczyk написал: > On 02/28/2011 06:01 PM, Igor M. Liplianin wrote: > > For those who ... > > He asked me to get rid of my driver. Why should I? > > Maybe because (now) your frontend has problems with tunning on this card? > I though that references are known for you: > 1. > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24 > 573 2. > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25 > 275 3. http://linuxdvb.org.ru/wbb/index.php?page=Thread&threadID=641 > > And to be more specific: I am not asking to get rid of your driver, > my patch doesn't touch your stv0900 implementation, it only change the > frontend for one particular card. > > > I have 7301, test it myself and see nothing bad with stv0900. > > If it is working for you - lucky you! But keep in mind that it it doesn't > mean that it is working for others. Have you tested it with my patch > applied? Besides it is not using your frontend, maybe it just *work*? > > > Obviously, I better patch stv0900 then convert the driver to stv090x. > > Sure, go ahead... I am only wondering why wasn't you so helpful when I was > trying to contact you and offer debugging help when I discovered the > problem after I started using this card. Your only response was: > "I know this issue. Your card is fine." > So now I resolved the problem myself and sent a working solution (tested > by some people - always with good results) and you disagree now. > > I'm only hoping that a hardware *usability* will win over an ego! > > regards, http://git.linuxtv.org/liplianin/media_tree.git?a=shortlog;h=refs/heads/dual_dvb_t_c_ci_rf -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
В сообщении от 28 февраля 2011 21:45:46 автор Mariusz Bialonczyk написал: > On 02/28/2011 06:01 PM, Igor M. Liplianin wrote: > > For those who ... > > He asked me to get rid of my driver. Why should I? > > Maybe because (now) your frontend has problems with tunning on this card? > I though that references are known for you: > 1. > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24 > 573 2. > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25 > 275 3. http://linuxdvb.org.ru/wbb/index.php?page=Thread&threadID=641 > > And to be more specific: I am not asking to get rid of your driver, > my patch doesn't touch your stv0900 implementation, it only change the > frontend for one particular card. > > > I have 7301, test it myself and see nothing bad with stv0900. > > If it is working for you - lucky you! But keep in mind that it it doesn't > mean that it is working for others. Have you tested it with my patch > applied? Besides it is not using your frontend, maybe it just *work*? > > > Obviously, I better patch stv0900 then convert the driver to stv090x. > > Sure, go ahead... I am only wondering why wasn't you so helpful when I was > trying to contact you and offer debugging help when I discovered the > problem after I started using this card. Your only response was: > "I know this issue. Your card is fine." > So now I resolved the problem myself and sent a working solution (tested > by some people - always with good results) and you disagree now. > > I'm only hoping that a hardware *usability* will win over an ego! > > regards, Sorry, I have nothing against you personally. I have excuses, but you not intresting, I think. Peace, friendship, chewing gum, like we use to say in my childhood :) Switching to other driver not helps me, so be patient. I patched stv0900 and send pull request. Tested on Prof 7301, 7500, NetUP Dual DVB-S2, DVBWorld 2104 cards by myself. With all of that vendors I have good relationships. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.39] cx23885, altera-ci: remove operator return in void procedure
The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317: [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver (2011-02-27 07:50:42 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git dual_dvb_t_c_ci_rf Igor M. Liplianin (2): cx23885, altera-ci: remove operator return in void procedure stv0900: speed up DVB-S searching drivers/media/dvb/frontends/stv0900_core.c |5 - drivers/media/video/cx23885/altera-ci.h|2 -- 2 files changed, 4 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
On 02/28/2011 06:01 PM, Igor M. Liplianin wrote: > For those who ... > He asked me to get rid of my driver. Why should I? Maybe because (now) your frontend has problems with tunning on this card? I though that references are known for you: 1. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24573 2. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25275 3. http://linuxdvb.org.ru/wbb/index.php?page=Thread&threadID=641 And to be more specific: I am not asking to get rid of your driver, my patch doesn't touch your stv0900 implementation, it only change the frontend for one particular card. > I have 7301, test it myself and see nothing bad with stv0900. If it is working for you - lucky you! But keep in mind that it it doesn't mean that it is working for others. Have you tested it with my patch applied? Besides it is not using your frontend, maybe it just *work*? > Obviously, I better patch stv0900 then convert the driver to stv090x. Sure, go ahead... I am only wondering why wasn't you so helpful when I was trying to contact you and offer debugging help when I discovered the problem after I started using this card. Your only response was: "I know this issue. Your card is fine." So now I resolved the problem myself and sent a working solution (tested by some people - always with good results) and you disagree now. I'm only hoping that a hardware *usability* will win over an ego! regards, -- Mariusz Bialonczyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net -- 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: Bulding az6007 module fails
Hello, On Mon, Feb 28, 2011 at 4:49 PM, Malte Gell wrote: > Hello, > > Terratec has released sources for the AzureWave 6007 chipset at > http://linux.terratec.de/files/TERRATEC_H7_Linux.tar.gz > > I have merged these sources into a 2.6.38-rc tree and tried to compile these > modules, but I get an error. I tried that myself a while ago (note: I'm not very familiar with Linux drivers, so I might have done it wrong). Anyway, my effort is documented here: http://sites.google.com/site/tingox/asus_m2a-vm_hdmi_linux Let us know if you a) get any help b) figure out a solution Have a nice day. -- Regards, Torfinn Ingolfsen, Norway -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Feb 28 19:00:27 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/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: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
Em 28-02-2011 12:47, Jiri Slaby escreveu: > On 02/28/2011 03:53 PM, Konrad Rzeszutek Wilk wrote: >> On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote: >>> mem->dma_handle is a dma address obtained by dma_alloc_coherent which >>> needn't be a physical address in presence of IOMMU. So ensure we are >> >> Can you add a comment why you are fixing it? Is there a bug report for this? >> Under what conditions did you expose this fault? > > No, by a just peer review when I was looking for something completely > different. > >> You also might want to mention that "needn't be a physical address as >> a hardware IOMMU can (and most likely) will return a bus address where >> physical != bus address." > > Mauro, do you want me to resend this with such an udpate in the changelog? Having it properly documented is always a good idea, especially since a similar fix might be needed on other drivers that also need contiguous memory. While it currently is used only on devices embedded on hardware with no iommu, there are some x86 hardware that doesn't allow DMA scatter/gather. Btw, it may be worth to take a look at vb2 dma contig module, as it might have similar issues. >> Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk >> ' >> on it. 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: V4L2 'brainstorming' meeting in Warsaw, March 2011
On Monday 28 February 2011 19:03:39 Hans Verkuil wrote: > On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote: [snip] > > 4. Agenda > > > > TBD, everyone is welcomed to put his items here :) > > In no particular order: > > 1) pipeline configuration, cropping and scaling: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html > > 2) HDMI API support > > Some hotplug/CEC code can be found here: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html > > but Cisco will soon post RFCs on this topic as well. > > 3) Snapshot functionality. > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html > http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html > > If we finish quicker than expected, then we can also look at this: > > - use of V4L2 as a frontend for SW/DSP codecs In still no particular order: - Muxed formats (H.264 inside MJPEG) - H.264 - Buffers pool - Entity information ioctl - Userspace drivers (OMX) - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - GL/ES in V4L2 devices -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 'brainstorming' meeting in Warsaw, March 2011
On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote: > Hello everyone! > > The idea of v4l2 'brainstorming' session came out after a few discussions on > #v4l > IRC channel about various RFCs and proposals that have been posted recently. I > would like to announce that Samsung Poland R&D Center (SPRC) agreed to take an > opportunity to organize this meeting. I've got a reservation for a conference > room for 16-18 March 2011 in our office. > > I would like to invite all of You for this V4L2 'brainstorming' session. > > I hope that this initial meeting date I've selected will fit us. We have 2 > only > weeks for the preparation, but I hope we will manage. I'm open for another > date > and if required I will change the reservation. > > The meeting will last 3 days what gives us a lot of possibility to present the > issues and proposals, discuss them further and work out a solution that will > be > accepted by others. > > From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-fimc > author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) > and me > (videobuf2 co-author and kernel lead developer in SPRC). > > A quick summary of the above: > > 1. Type of the meeting: > V4L2 'brainstorming' mini-summit :) > > 2. Place: > Samsung Poland R&D Center > Polna 11 Street > 00-633 Warsaw, Poland > > 3. Date: > 16-18 March 2011 > > 4. Agenda > TBD, everyone is welcomed to put his items here :) In no particular order: 1) pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html 2) HDMI API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html but Cisco will soon post RFCs on this topic as well. 3) Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html If we finish quicker than expected, then we can also look at this: - use of V4L2 as a frontend for SW/DSP codecs Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DVB : add option to dump PDU exchanged with CAM in dvb_core
Dear all, Here is a patch for the dvb_core module, you'll find it attached to this message. It's adding a new module integer parameter called "cam_dump_pdu" that can have the following values: - 0 (by default): don't dump PDU (do nothing) - 1: Dump all PDU written and read on device through the syscall functions. The PDU are dumped in segments of 16 bytes maximum written in hexadecimal. - 2: like value 1 but remove the commonly used PDU for polling (generating a lot of "noise" in the logs) The goal of dumping PDU exchanged with CAM is to help debugging userland applications and libraries. This is my first patch submission, so I may have made some errors regarding the submission rules. Best regards, Sebastien. dvb_ca_en50221.patch Description: Binary data
Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
Hi, despite lots of time spent tinkering around and looking for help on the web, I've had no success in getting to work the remote control of my DVB-C card. It is a Terratec Cinergy C: http://linuxtv.org/wiki/index.php/TerraTec_Cinergy_C_DVB-C and am using the Mantis driver. Since it was merged into the kernel tree in 2.6.33, watching TV works without patches, but the remote control does not, although it is supposed to be supported, according to the link above. Kernel is a vanilla 2.6.37.2 with custom configuration on an old AMD Athlon XP machine, running debian Squeeze. When I modprobe the Mantis driver, the following IR-modules are pulled in automagically: ir_lirc_codec lirc_dev ir_core However, no input device is created during module loading. dmesg output: Mantis :01:0a.0: PCI INT A -> Link[APC1] -> GSI 16 (level, high) -> IRQ 16 DVB: registering new adapter (Mantis DVB adapter) IR LIRC bridge handler initialized DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... Am I missing some additional modules? Are there any dependencies on other kernel config options that are not handled automatically by make menuconf? If additional information is needed, I will be happy to provide it. However, I am not sure what is useful and what is not and did not want to bloat this message. Thanks in advance, Jonas -- 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
V4L2 'brainstorming' meeting in Warsaw, March 2011
Hello everyone! The idea of v4l2 'brainstorming' session came out after a few discussions on #v4l IRC channel about various RFCs and proposals that have been posted recently. I would like to announce that Samsung Poland R&D Center (SPRC) agreed to take an opportunity to organize this meeting. I've got a reservation for a conference room for 16-18 March 2011 in our office. I would like to invite all of You for this V4L2 'brainstorming' session. I hope that this initial meeting date I've selected will fit us. We have 2 only weeks for the preparation, but I hope we will manage. I'm open for another date and if required I will change the reservation. The meeting will last 3 days what gives us a lot of possibility to present the issues and proposals, discuss them further and work out a solution that will be accepted by others. From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-fimc author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) and me (videobuf2 co-author and kernel lead developer in SPRC). A quick summary of the above: 1. Type of the meeting: V4L2 'brainstorming' mini-summit :) 2. Place: Samsung Poland R&D Center Polna 11 Street 00-633 Warsaw, Poland 3. Date: 16-18 March 2011 4. Agenda TBD, everyone is welcomed to put his items here :) I will post some travel information tomorrow. SPRC office is in the center of Warsaw, there are a few hotels nearby. I will check for a free rooms and I will make a recommendation soon. I hope we will meet together soon! Best regards -- Marek Szyprowski Samsung Poland R&D Center The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify sender by email and delete this communication immediately. Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie, dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie usuń powyższą wiadomość ze swojego komputera.
V4L2 'brainstorming' meeting in Warsaw, March 2011
Hello everyone! The idea of v4l2 'brainstorming' session came out after a few discussions on #v4l IRC channel about various RFCs and proposals that have been posted recently. I would like to announce that Samsung Poland R&D Center (SPRC) agreed to take an opportunity to organize this meeting. I've got a reservation for a conference room for 16-18 March 2011 in our office. I would like to invite all of You for this V4L2 'brainstorming' session. I hope that this initial meeting date I've selected will fit us. We have 2 only weeks for the preparation, but I hope we will manage. I'm open for another date and if required I will change the reservation. The meeting will last 3 days what gives us a lot of possibility to present the issues and proposals, discuss them further and work out a solution that will be accepted by others. From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-fimc author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) and me (videobuf2 co-author and kernel lead developer in SPRC). A quick summary of the above: 1. Type of the meeting: V4L2 'brainstorming' mini-summit :) 2. Place: Samsung Poland R&D Center Polna 11 Street 00-633 Warsaw, Poland 3. Date: 16-18 March 2011 4. Agenda TBD, everyone is welcomed to put his items here :) I will post some travel information tomorrow. SPRC office is in the center of Warsaw, there are a few hotels nearby. I will check for a free rooms and I will make a recommendation soon. I hope we will meet together soon! Best regards -- Marek Szyprowski Samsung Poland R&D Center The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify sender by email and delete this communication immediately. Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie, dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie usuń powyższą wiadomość ze swojego komputera.
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
В сообщении от 28 февраля 2011 18:09:56 автор Andreas Oberritter написал: > Hello Igor, > > On 02/28/2011 04:41 PM, Igor M. Liplianin wrote: > > В сообщении от 28 февраля 2011 13:37:01 автор Mariusz Bialonczyk написал: > >> On 2011-01-16 21:44, Mariusz Bialonczyk wrote: > >>> Fixing the very annoying tunning issue. When switching from DVB-S2 to > >>> DVB-S, it often took minutes to have a lock. > >>> > >> > [...] > >>> > >>> The patch is changing the frontend from stv0900 to stv090x. > >>> The card now works much more reliable. There is no problem with > >>> switching from DVB-S2 to DVB-S, tunning works flawless. > >> > >> Igor, can I get your ACK on this patch? > >> > >> regards, > > > > Never. > > Think first what you are asking for. > > for those who aren't involved in the development of these drivers, may I > ask you what's the problem with this patch? For those who ... He asked me to get rid of my driver. Why should I? I have 7301, test it myself and see nothing bad with stv0900. Obviously, I better patch stv0900 then convert the driver to stv090x. And if you ask something then be prepaired to not be given smth. Best Regards Igor > > Regards, > Andreas -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v20 1/3] MFD: Wl1273 FM radio core: Add I2C IO functions.
Hi Matti, On Mon, Feb 28, 2011 at 01:02:29PM +0200, Matti J. Aaltonen wrote: > Add I2C IO functions. > Change the IO operation from read to write in wl1273_fm_set_volume. > Update the year of the copyright statement. > Remove two unnecessary calls to i2c_set_clientdata. Provided that you add a changelog relevant to the patch itself, and not to the v1->v2 diff: Acked-by: Samuel Ortiz Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
Hello Igor, On 02/28/2011 04:41 PM, Igor M. Liplianin wrote: > В сообщении от 28 февраля 2011 13:37:01 автор Mariusz Bialonczyk написал: >> On 2011-01-16 21:44, Mariusz Bialonczyk wrote: >>> Fixing the very annoying tunning issue. When switching from DVB-S2 to >>> DVB-S, it often took minutes to have a lock. >>> >> > [...] >>> >>> The patch is changing the frontend from stv0900 to stv090x. >>> The card now works much more reliable. There is no problem with switching >>> from DVB-S2 to DVB-S, tunning works flawless. >> >> Igor, can I get your ACK on this patch? >> >> regards, > Never. > Think first what you are asking for. for those who aren't involved in the development of these drivers, may I ask you what's the problem with this patch? Regards, Andreas -- 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: Well supported USB DVB-C device?
Antti Palosaari writes: > On 02/28/2011 02:02 AM, Malte Gell wrote: >> is there a DVB-C device with USB that is well supported by a recent kernel >> (2.6.38)? > > Anysee E30 C Plus is supported as far as I know. I can confirm that. The only downside so far is that it seems to need a lot of hand-holding by the CPU, which in turn leads to increased power consumption. > Note that new revision of Anysee E30 Combo Plus is no longer supported > since they changed to new NXP silicon tuner. E30 Combo Plus and E30 C > Plus are different devices. Ouch. I really wish vendors would stop using the same name for different devices. /Benny -- 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
Bulding az6007 module fails
Hello, Terratec has released sources for the AzureWave 6007 chipset at http://linux.terratec.de/files/TERRATEC_H7_Linux.tar.gz I have merged these sources into a 2.6.38-rc tree and tried to compile these modules, but I get an error. Can someone tell me how to fix this in order to build the modules? Maybe these sources could even become part of the official Linux kernel? Below is the output when I try to buld the modules. Thanx in advance Malte CALLscripts/checksyscalls.sh CC [M] drivers/media/dvb/dvb-usb/az6007.o In file included from drivers/media/dvb/dvb-usb/az6007.c:11: drivers/media/dvb/frontends/mt2063_cfg.h: In function ‘tuner_MT2063_Open’: drivers/media/dvb/frontends/mt2063_cfg.h:62: error: ‘DVBFE_TUNER_OPEN’ undeclared (first use in this function) drivers/media/dvb/frontends/mt2063_cfg.h:62: error: (Each undeclared identifier is reported only once drivers/media/dvb/frontends/mt2063_cfg.h:62: error: for each function it appears in.) drivers/media/dvb/frontends/mt2063_cfg.h: In function ‘tuner_MT2063_SoftwareShutdown’: drivers/media/dvb/frontends/mt2063_cfg.h:83: error: ‘DVBFE_TUNER_SOFTWARE_SHUTDOWN’ undeclared (first use in this function) drivers/media/dvb/frontends/mt2063_cfg.h: In function ‘tuner_MT2063_ClearPowerMaskBits’: drivers/media/dvb/frontends/mt2063_cfg.h:104: error: ‘DVBFE_TUNER_CLEAR_POWER_MASKBITS’ undeclared (first use in this function) drivers/media/dvb/dvb-usb/az6007.c: At top level: drivers/media/dvb/dvb-usb/az6007.c:156: error: array type has incomplete element type drivers/media/dvb/dvb-usb/az6007.c:535: error: ‘USB_PID_AZUREWAVE_6007’ undeclared here (not in a function) drivers/media/dvb/dvb-usb/az6007.c:536: error: ‘USB_PID_TERRATEC_H7’ undeclared here (not in a function) drivers/media/dvb/dvb-usb/az6007.c:576: error: unknown field ‘rc_key_map’ specified in initializer drivers/media/dvb/dvb-usb/az6007.c:576: error: initializer element is not constant drivers/media/dvb/dvb-usb/az6007.c:576: error: (near initialization for ‘az6007_properties.identify_state’) drivers/media/dvb/dvb-usb/az6007.c:577: error: unknown field ‘rc_key_map_size’ specified in initializer drivers/media/dvb/dvb-usb/az6007.c:577: error: invalid operands to binary / (have ‘struct usb_device_id *’ and ‘long unsigned int’) drivers/media/dvb/dvb-usb/az6007.c:577: warning: missing braces around initializer drivers/media/dvb/dvb-usb/az6007.c:577: warning: (near initialization for ‘az6007_properties.rc’) drivers/media/dvb/dvb-usb/az6007.c:577: error: initializer element is not constant drivers/media/dvb/dvb-usb/az6007.c:577: error: (near initialization for ‘az6007_properties.rc.mode’) drivers/media/dvb/dvb-usb/az6007.c:578: error: unknown field ‘rc_interval’ specified in initializer drivers/media/dvb/dvb-usb/az6007.c:578: warning: initialization makes pointer from integer without a cast drivers/media/dvb/dvb-usb/az6007.c:579: error: unknown field ‘rc_query’ specified in initializer drivers/media/dvb/dvb-usb/az6007.c:579: warning: initialization makes integer from pointer without a cast drivers/media/dvb/dvb-usb/az6007.c:579: error: initializer element is not computable at load time drivers/media/dvb/dvb-usb/az6007.c:579: error: (near initialization for ‘az6007_properties.generic_bulk_ctrl_endpoint’) make[4]: *** [drivers/media/dvb/dvb-usb/az6007.o] Fehler 1 make[3]: *** [drivers/media/dvb/dvb-usb] Fehler 2 make[2]: *** [drivers/media/dvb] Fehler 2 make[1]: *** [drivers/media] Fehler 2 make: *** [drivers] Fehler 2 ("Fehler"=error) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 02/28/2011 03:53 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote: >> mem->dma_handle is a dma address obtained by dma_alloc_coherent which >> needn't be a physical address in presence of IOMMU. So ensure we are > > Can you add a comment why you are fixing it? Is there a bug report for this? > Under what conditions did you expose this fault? No, by a just peer review when I was looking for something completely different. > You also might want to mention that "needn't be a physical address as > a hardware IOMMU can (and most likely) will return a bus address where > physical != bus address." Mauro, do you want me to resend this with such an udpate in the changelog? > Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk > ' > on it. thanks, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 02/28/2011 04:14 PM, Laurent Pinchart wrote: > Hi Jiri, > > On Monday 28 February 2011 16:07:43 Jiri Slaby wrote: >> On 02/28/2011 11:53 AM, Laurent Pinchart wrote: >>> On Monday 28 February 2011 10:37:02 Jiri Slaby wrote: mem->dma_handle is a dma address obtained by dma_alloc_coherent which needn't be a physical address in presence of IOMMU. So ensure we are remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not mem->dma_handle. >>> >>> Quoting arch/arm/include/asm/memory.h, >>> >>> /* >>> >>> * These are *only* valid on the kernel direct mapped RAM memory. >> >> Which the DMA allocation shall be. >> >>> * Note: Drivers should NOT use these. >> >> This is weird. >> >>> They are the wrong >>> >>> * translation for translating DMA addresses. Use the driver >>> * DMA support - see dma-mapping.h. >> >> Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones. >> >>> */ >>> >>> static inline unsigned long virt_to_phys(const volatile void *x) >>> { >>> >>> return __virt_to_phys((unsigned long)(x)); >>> >>> } >>> >>> Why would you use physically contiguous memory if you have an IOMMU >>> anyway ? >> >> Sorry, what? When IOMMU is used, dma_alloc_* functions may return "tags" >> as a DMA address, not a physical address. So using these DMA "addresses" >> directly (e.g. in remap_pfn_range) is a bug. > > What I mean is that videobuf-dma-contig is meant to be used by drivers that > require physically contiguous memory. If the system has an IOMMU, why would > drivers need that ? Aha. They actually need not but they would need do the mapping themselves which they currently do not. IOW the vbuf-dma-contig allocator is used unconditionally in the few drivers I checked. BUT Even if they need only one page and use vbuf-dma-contig, which I don't see a reason not to, it will cause problems too. regards, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors
Hi Laurent, A few questions from me below. I feel we need to talk about this change a bit more, it introduces some recovery and consistency problems, unless I'm missing something. On Sun, Feb 27, 2011 at 10:12, Laurent Pinchart wrote: > videobuf2 expects drivers to check buffer in the buf_prepare operation > and to return success only if the buffer can queued without any issue. > > For hot-pluggable devices, disconnection events need to be handled at > buf_queue time. Checking the disconnected flag and adding the buffer to > the driver queue need to be performed without releasing the driver > spinlock, otherwise race conditions can occur in which the driver could > still allow a buffer to be queued after the disconnected flag has been > set, resulting in a hang during the next DQBUF operation. > > This problem can be solved either in the videobuf2 core or in the device > drivers. To avoid adding a spinlock to videobuf2, make buf_queue return > an int and handle buf_queue failures in videobuf2. Drivers must not > return an error in buf_queue if the condition leading to the error can > be caught in buf_prepare. > > Signed-off-by: Laurent Pinchart > --- > drivers/media/video/videobuf2-core.c | 32 ++-- > include/media/videobuf2-core.h | 2 +- > 2 files changed, 27 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/video/videobuf2-core.c > b/drivers/media/video/videobuf2-core.c > index cc7ab0a..1d81536 100644 > --- a/drivers/media/video/videobuf2-core.c > +++ b/drivers/media/video/videobuf2-core.c > @@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb, struct > v4l2_buffer *b) > /** > * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing > */ > -static void __enqueue_in_driver(struct vb2_buffer *vb) > +static int __enqueue_in_driver(struct vb2_buffer *vb) > { > struct vb2_queue *q = vb->vb2_queue; > + int ret; > > vb->state = VB2_BUF_STATE_ACTIVE; > atomic_inc(&q->queued_count); > - q->ops->buf_queue(vb); > + ret = q->ops->buf_queue(vb); > + if (ret == 0) > + return 0; > + > + vb->state = VB2_BUF_STATE_ERROR; > + atomic_dec(&q->queued_count); > + wake_up_all(&q->done_wq); > + > + return ret; Unless I am missing something, when this happens for an n-th buffer, we wake up all, but only one buffer will have the ERROR state, all the other will be in QUEUED state. This will mess up return values from dqbuf (if this happens on streamon) for other buffers, they will have their V4L2_BUF_FLAG_QUEUED set after dqbuf. Also, returning 0 from DQBUF and the V4L2_BUF_FLAG_ERROR for the failed buffer suggests that streaming may continue. So how do we recover from this disconnection event? What is the general idea? If buf_queue fails, can we restart from some point (i.e. reuse the buffers later) or do we have to clean up completely (i.e. deallocate, etc.)? Right now we are staying in an undefined state. If we cannot recover, we shouldn't be setting V4L2_BUF_FLAG_ERROR, but returning a stronger error instead and maybe clean up the rest, which is not waited for somehow. If we can recover on the other hand, we shouldn't be probably waking up all sleepers or at least giving them meaningful errors. > } > /** > @@ -890,8 +899,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b) > * If already streaming, give the buffer to driver for processing. > * If not, the buffer will be given to driver on next streamon. > */ > - if (q->streaming) > - __enqueue_in_driver(vb); > + if (q->streaming) { > + ret = __enqueue_in_driver(vb); > + if (ret < 0) { > + dprintk(1, "qbuf: buffer queue failed\n"); > + return ret; > + } > + } > What errors can be allowed to be returned from driver here? EIO? Also, isn't returning an error here to userspace suggesting that qbuf didn't happen? But it actually did happen, we put the buffer onto vb2 list and set it state to QUEUED. From the point of view of vb2, the buffer is on its queue, but the userspace may not think so. > dprintk(1, "qbuf of buffer %d succeeded\n", vb->v4l2_buf.index); > return 0; > @@ -1101,6 +1115,7 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf); > int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type) > { > struct vb2_buffer *vb; > + int ret; > > if (q->fileio) { > dprintk(1, "streamon: file io in progress\n"); > @@ -1139,8 +1154,13 @@ int vb2_streamon(struct vb2_queue *q, enum > v4l2_buf_type type) > * If any buffers were queued before streamon, > * we can now pass them to driver for processing. > */ > - list_for_each_entry(vb, &q->queued_list, queued_entry) > - __enqueue_in_driver(vb); > + list_for_each_entry(vb, &q->queued_list, queued_entry) { > + ret =
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
В сообщении от 28 февраля 2011 13:37:01 автор Mariusz Bialonczyk написал: > On 2011-01-16 21:44, Mariusz Bialonczyk wrote: > > Fixing the very annoying tunning issue. When switching from DVB-S2 to > > DVB-S, it often took minutes to have a lock. > > > > [...] > > > > The patch is changing the frontend from stv0900 to stv090x. > > The card now works much more reliable. There is no problem with switching > > from DVB-S2 to DVB-S, tunning works flawless. > > Igor, can I get your ACK on this patch? > > regards, Never. Think first what you are asking for. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: scan file norway, bergen
-- Forwarded message -- From: Thomas Amland Date: Mon, Feb 28, 2011 at 4:03 PM Subject: scan file norway, bergen To: linux-...@linuxtv.org Created with w_scan, frequencies from http://www.ntv.no/dekningskart, and confirmed with scan. # Norway, Bergen # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 57000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 61800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 65000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 69800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote: > mem->dma_handle is a dma address obtained by dma_alloc_coherent which > needn't be a physical address in presence of IOMMU. So ensure we are Can you add a comment why you are fixing it? Is there a bug report for this? Under what conditions did you expose this fault? You also might want to mention that "needn't be a physical address as a hardware IOMMU can (and most likely) will return a bus address where physical != bus address." Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk ' on it. > remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper > by using virt_to_phys(mem->vaddr) and not mem->dma_handle. > > While at it, use PFN_DOWN instead of explicit shift. > > Signed-off-by: Jiri Slaby > Cc: Mauro Carvalho Chehab > Cc: Konrad Rzeszutek Wilk > --- > drivers/media/video/videobuf-dma-contig.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/videobuf-dma-contig.c > b/drivers/media/video/videobuf-dma-contig.c > index c969111..19d3e4a 100644 > --- a/drivers/media/video/videobuf-dma-contig.c > +++ b/drivers/media/video/videobuf-dma-contig.c > @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue > *q, > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > retval = remap_pfn_range(vma, vma->vm_start, > - mem->dma_handle >> PAGE_SHIFT, > + PFN_DOWN(virt_to_phys(mem->vaddr)) >size, vma->vm_page_prot); > if (retval) { > dev_err(q->dev, "mmap: remap failed with error %d. ", retval); > -- > 1.7.4.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
Hi Jiri, On Monday 28 February 2011 16:07:43 Jiri Slaby wrote: > On 02/28/2011 11:53 AM, Laurent Pinchart wrote: > > On Monday 28 February 2011 10:37:02 Jiri Slaby wrote: > >> mem->dma_handle is a dma address obtained by dma_alloc_coherent which > >> needn't be a physical address in presence of IOMMU. So ensure we are > >> remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper > >> by using virt_to_phys(mem->vaddr) and not mem->dma_handle. > > > > Quoting arch/arm/include/asm/memory.h, > > > > /* > > > > * These are *only* valid on the kernel direct mapped RAM memory. > > Which the DMA allocation shall be. > > > * Note: Drivers should NOT use these. > > This is weird. > > > They are the wrong > > > > * translation for translating DMA addresses. Use the driver > > * DMA support - see dma-mapping.h. > > Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones. > > > */ > > > > static inline unsigned long virt_to_phys(const volatile void *x) > > { > > > > return __virt_to_phys((unsigned long)(x)); > > > > } > > > > Why would you use physically contiguous memory if you have an IOMMU > > anyway ? > > Sorry, what? When IOMMU is used, dma_alloc_* functions may return "tags" > as a DMA address, not a physical address. So using these DMA "addresses" > directly (e.g. in remap_pfn_range) is a bug. What I mean is that videobuf-dma-contig is meant to be used by drivers that require physically contiguous memory. If the system has an IOMMU, why would drivers need that ? > Maybe there is a better way to convert a kernel address of the DMA > mapping into a physical frame, but I'm not aware of any... > > >> While at it, use PFN_DOWN instead of explicit shift. > >> > >> Signed-off-by: Jiri Slaby > >> Cc: Mauro Carvalho Chehab > >> Cc: Konrad Rzeszutek Wilk > >> --- > >> > >> drivers/media/video/videobuf-dma-contig.c |2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/drivers/media/video/videobuf-dma-contig.c > >> b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a > >> 100644 --- a/drivers/media/video/videobuf-dma-contig.c > >> +++ b/drivers/media/video/videobuf-dma-contig.c > >> @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct > >> videobuf_queue *q, > >> > >>vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >>retval = remap_pfn_range(vma, vma->vm_start, > >> > >> - mem->dma_handle >> PAGE_SHIFT, > >> + PFN_DOWN(virt_to_phys(mem->vaddr)) > >> > >> size, vma->vm_page_prot); > >> > >>if (retval) { > >> > >>dev_err(q->dev, "mmap: remap failed with error %d. ", retval); -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 02/28/2011 11:53 AM, Laurent Pinchart wrote: > On Monday 28 February 2011 10:37:02 Jiri Slaby wrote: >> mem->dma_handle is a dma address obtained by dma_alloc_coherent which >> needn't be a physical address in presence of IOMMU. So ensure we are >> remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper >> by using virt_to_phys(mem->vaddr) and not mem->dma_handle. > > Quoting arch/arm/include/asm/memory.h, > > /* > * These are *only* valid on the kernel direct mapped RAM memory. Which the DMA allocation shall be. > * Note: Drivers should NOT use these. This is weird. > They are the wrong > * translation for translating DMA addresses. Use the driver > * DMA support - see dma-mapping.h. Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones. > */ > static inline unsigned long virt_to_phys(const volatile void *x) > { > return __virt_to_phys((unsigned long)(x)); > } > > Why would you use physically contiguous memory if you have an IOMMU anyway ? Sorry, what? When IOMMU is used, dma_alloc_* functions may return "tags" as a DMA address, not a physical address. So using these DMA "addresses" directly (e.g. in remap_pfn_range) is a bug. Maybe there is a better way to convert a kernel address of the DMA mapping into a physical frame, but I'm not aware of any... >> While at it, use PFN_DOWN instead of explicit shift. >> >> Signed-off-by: Jiri Slaby >> Cc: Mauro Carvalho Chehab >> Cc: Konrad Rzeszutek Wilk >> --- >> drivers/media/video/videobuf-dma-contig.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/media/video/videobuf-dma-contig.c >> b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a 100644 >> --- a/drivers/media/video/videobuf-dma-contig.c >> +++ b/drivers/media/video/videobuf-dma-contig.c >> @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue >> *q, >> >> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> retval = remap_pfn_range(vma, vma->vm_start, >> - mem->dma_handle >> PAGE_SHIFT, >> + PFN_DOWN(virt_to_phys(mem->vaddr)) >> size, vma->vm_page_prot); >> if (retval) { >> dev_err(q->dev, "mmap: remap failed with error %d. ", retval); > regards, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, Feb 28, 2011 at 01:44:25PM +0100, Guennadi Liakhovetski wrote: > On Mon, 28 Feb 2011, Sakari Ailus wrote: > > > On Mon, Feb 28, 2011 at 12:37:06PM +0100, Guennadi Liakhovetski wrote: > > > So, you'd also need a separate control for external exposure, there are > > > also sensors, that can be configured to different shutter / exposure / > > > readout sequence controlling... No, we don't have to support all that > > > variety, but we have to be aware of it, while making decisions;) > > > > Hi Guennadi, > > > > Do you mean that there are sensors that can synchronise these parameters at > > frame level, or how? There are use cases for that but it doesn't limit to > > still capture. > > No, sorry, I don't mean exposure value, by "external exposure" I meant the > EXPOSURE pin. But in fact, as I see now, it is just another name for the > TRIGGER pin:( But what we do have on some sensors, e.g., on MT9T031. The partial datasheet of that sensor I was able to find in Aptina website suggests there are separate trigger and strobe pins. Trigger is another name for global reset which can be performed over the I2C as well, also on that sensor. > On mt9t031 they distinguish between the beginning of the shutter sequence, > the exposure and the read sequence, and depending on a parameter they > decide which signals to use to start which action. The global reset and mechanical shutter control is exclusively related to operation with mechanical shutter as far as I know. This is essentially extra hardware to enhance one use case a little. What about newer sensors; do they support this kind of functionality? Regards, -- Sakari Ailus sakari dot ailus at iki dot fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, Feb 28, 2011 at 12:20:52PM +0100, Guennadi Liakhovetski wrote: > > > Sorry, not sure what you mean. Do you mean different APIs when the flash > > > is controlled directly by the sensor and by an external controller? No, of > > > course we need one API, but you either issue those ioctl()s to the sensor > > > (sub)device, or to the dedicated flash (sub)device. If you mean my "minor > > > subset" above, then I was trying to say, that this is a basis, that has to > > > be extended, but not, that we will develop a new API for more complicated > > > cases. > > > > I think I misunderstood you originally, sorry. I should have properly read > > the > > RFC. :-) > > > > Your proposal of the flash mode is good, but what about software strobe (a > > little more on that below)? > > > > Also, what about making this a V4L2 control instead? > > These are two things, I think: first we have to decide which functions we > need, second - how to implement them. Sure, controls are also a > possibility. Agreed. ... > > > > > > This doesn't solve the flash/capture synchronization problem > > > > > > though. I > > > > > > don't > > > > > > think we need a dedicated snapshot capture mode at the V4L2 level. A > > > > > > way to > > > > > > configure the sensor to react on an external trigger provided by the > > > > > > flash > > > > > > controller is needed, and that could be a control on the flash > > > > > > sub-device. > > > > > > > > > > Well... Sensors call this a "snapshot mode." I don't care that much > > > > > how > > > > > we > > > > > _call_ it, but I do think, that we should be able to use it. > > > > > > > > Some sensors and webcams might have that, but newer camera solutions > > > > tend to contain a raw bayer sensor and and ISP. There is no concept of > > > > snapsnot mode in these sensors. > > > > > > Hm, I am not sure I understand, why sensors with DSPs in them should have > > > no notion of a snapshot mode. Do they have no strobe / trigger pins? And > > > no built in possibility to synchronize with a flash? > > > > I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a flash > > strobe pin while some doesn't (such as the N900). > > Of course, if no flash is present, you don't have to support it;) There is flash but no hardware flash strobe. Ok? :-) > > Still, even if the strobe pin is missing it should be possible to allow > > strobing the flash by using software strobe (usually an I2C message). > > > > I agree using a hardware strobe is much much better if it's available. > > Again - don't understand. Above (i2c message) you're referring to the > sensor. But I don't think toggling the flash on per-frame basis from I'm referring to the flash controller, not the sensor. They're often controlled using the I2C bus. > software via the sensor makes much sense. That way you could also just > wire your flash to a GPIO. The main advantage of a sensor-controlled flash > is, that is toggles the flash automatically, synchronised with its image > read-out. You would, however, toggle the flash manually, if you just This is very true but unfortunately not all hardware has separate flash strobe signal. > wanted to turn it on permanently (torch-mode). Not quite. There are use cases for the torch mode (an application called Torch, for example). In case the hardware strobe is absent the flash must be strobed using software. This means that the user has to be better aware of the sensor pixel area exposure timing than otherwise would be necessary. > > > > > Hm, don't think only the "flash subdevice" has to know about this. > > > > > First, > > > > > you have to switch the sensor into that mode. Second, it might be > > > > > either > > > > > external trigger from the flash controller, or a programmed trigger > > > > > and > > > > > a > > > > > flash strobe from the sensor to the flash (controller). Third, well, > > > > > not > > > > > quite sure, but doesn't the host have to know about the snapshot mode? > > > > > > > > I do not favour adding use case type of functionality to interfaces that > > > > do not necessarily need it. Would the concept of a snapshot be > > > > parametrisable on V4L2 level? > > > > > > I am open to this. I don't have a good idea of whether camera hosts have > > > to know about the snapshot mode or not. It's open for discussion. > > > > What functionality would the snapshot mode provide? Flash synchronisation? > > Something else? > > Also pre-defined number of images, enabling of the trigger pin and trigger > i2c command. Just noticed - on mt9t031 and mt9v022 the snapshot mode also > enables externally controlled exposure... Is the externally controlled exposure somehow essentially different from just sending new esposure settings to the sensor via I2C? > > I have to admit I don't know of any hardware which would recognise a concept > > of "snapshot". Do you have a smart sensor which does this, for example? The > > only hardware support for the fl
[patch 1/1] mantis_pci: remove asm/pgtable.h include
mantis_pci.c is including asm/pgtable.h and it's leading to a build failure on arm. It has been noticed here : https://buildd.debian.org/fetch.cgi?pkg=linux-2.6&arch=armel&ver=2.6.38~rc6-1~experimental.1&stamp=1298430952&file=log&as=raw As this header doesn't seem to be used, I'm removing it. I've build tested it with arm and x86. Signed-off-by: Arnaud Patard Index: linux-2.6/drivers/media/dvb/mantis/mantis_pci.c === --- linux-2.6.orig/drivers/media/dvb/mantis/mantis_pci.c2011-02-27 21:21:57.370731954 +0100 +++ linux-2.6/drivers/media/dvb/mantis/mantis_pci.c 2011-02-27 21:22:02.142211398 +0100 @@ -22,7 +22,6 @@ #include #include #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 2011-02-28 at 08:33 -0500, Andy Walls wrote: > On Mon, 2011-02-28 at 12:17 +0100, Hans Verkuil wrote: > > On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote: > > > > > So, do I understand it right, that currently there are drivers, that > > > > overwrite the last buffers while waiting for a new one, and ones, that > > > > stop capture for that time. > > > > Does anyone know which drivers stop capture if there are no buffers > > available? > > I'm not aware of any. > > Not that it is a camera driver, but... > > cx18 will stall the stream, due to the CX23418 engine being starved of > buffers for that stream, if the application doesn't read the buffers. > The reasoning for this behavior is that one large gap is better than a > series of small gaps, if the application has fallen behind. ^ Gah. That didn't make sense. I need more coffee before sending email. -Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 2011-02-28 at 12:17 +0100, Hans Verkuil wrote: > On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote: > > > So, do I understand it right, that currently there are drivers, that > > > overwrite the last buffers while waiting for a new one, and ones, that > > > stop capture for that time. > > Does anyone know which drivers stop capture if there are no buffers > available? > I'm not aware of any. Not that it is a camera driver, but... cx18 will stall the stream, due to the CX23418 engine being starved of buffers for that stream, if the application doesn't read the buffers. The reasoning for this behavior is that one large gap is better than a series of small gaps, if the application has fallen behind. The exceptional case is the cx18 MPEG Index stream, which will steal the oldest buffers back in the call to cx18_stream_rotate_idx_mdls(). The CX23418 engine seems to gracefully handle being starved of buffers for a stream for a period of time. This driver does not use videobuf currently. -Andy -- 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: [DVB] Maintainers of dvb_core and budget_ci modules - Patches proposal
Hello Sébastien, On 02/28/2011 12:26 PM, Sébastien RAILLARD (COEXSI) wrote: > I would like to discuss and submit some patches I have developed for these > modules: > - dvb_core: add an option for logging the PDU exchanged with the CAM for > debugging purposes > - dvb_core: clean all ring buffers associated with CAM when a device is > opened > - budget_ci: print information about CI firmware used > - budget_ci: add module option for disabling the IR receiver and the IRQ > mode please, just send your patches to the mailing list, with a description of what problems they solve and with your sign-off. Regards, Andreas -- 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: [GIT PULL] TI WL 128x FM V4L2 driver
On Sun, Feb 27, 2011 at 4:28 PM, Mauro Carvalho Chehab wrote: > > Em 25-01-2011 03:48, halli manjunatha escreveu: > > Hi Mauro, > > > > Please pull the WL128x FM V4L2 driver from > > http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git fm_v4l2_upstream > > > > This is TI WL128x FM V4L2 driver and it introduces ‘wl128x’ folder > > under the ‘drivers/media/radio’. This driver enables support for FM RX > > and TX for Texas Instrument's WL128x (also compatible with WL127x) > > WiLink chip sets. The V4L2 FM driver can work in either Rx or Tx mode, > > and V4L2 interfaces are provided for both. > > > > Texas Instrument's WL128x chip set packs BT, FM, GPS and WLAN in a > > single die with BT, FM and GPS being interfaced over a single UART. > > This driver works on top of the shared transport line discipline > > driver. This driver can also be made use for the WL127x version of the > > chip which packs BT, FM and WLAN only. > > > > This driver has been reviewed by various folks within TI and also in > > Linux media community. The driver has been tested extensively on TI > > platforms and we believe that it is ready for merge into mainline. > > Applied, thanks. > > From what I understood from your comments, this driver will also cover > wl127x chips. As such, it would be better to double check if all > functionalities > present at drivers/media/radio/radio-wl1273.c (assuming that wl1273 is > covered) > are also on the new driver, and, if not, merge the remaining ones and > deprecate > the wl1273-specific driver. > > Cheers, > Mauro Yes, this driver supports all the functionalities which are supported by radio-wl1273.c [But our driver is on UART while wl1273 is based on i2c..] NOTE: V4L2 FM driver depend upon an underlying TI_ST driver which is the core transport driver [based on UART, it is a ldisc driver] Updates to TI-ST driver happen on linux-next tree on kernel.org and are planned to be released in 2.6.39. Since your tree @[http://git.linuxtv.org/media_tree.git?a=shortlog;h=refs/heads/staging/for_v2.6.39] lags behind the linux-next tree, the recent updates to TI-ST driver are missing on your tree. Unfortunately these would cause a build failure for the V4L2 driver, since the APIs have changed on the TI-ST driver. So, I will provide you one patch to make the present driver to work with latest ST driver once your tree moves to 2.6.38-rc6+ kernel. Regards Manju > > > > The following changes since commit db309d3d54c2f721dd1176ce86c63b0381c0a258: > > Mauro Carvalho Chehab (1): > > [media] add support for Encore FM3 > > > > are available in the git repository at: > > > > http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git fm_v4l2_upstream > > > > Manjunatha Halli (7): > > drivers:media:radio: wl128x: FM Driver common header file > > drivers:media:radio: wl128x: FM Driver V4L2 sources > > drivers:media:radio: wl128x: FM Driver Common sources > > drivers:media:radio: wl128x: FM driver RX sources > > drivers:media:radio: wl128x: FM driver TX sources > > drivers:media:radio: wl128x: Kconfig & Makefile for wl128x driver > > drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver > > > > drivers/media/radio/Kconfig | 3 + > > drivers/media/radio/Makefile | 1 + > > drivers/media/radio/wl128x/Kconfig | 17 + > > drivers/media/radio/wl128x/Makefile | 6 + > > drivers/media/radio/wl128x/fmdrv.h | 244 + > > drivers/media/radio/wl128x/fmdrv_common.c | 1677 > > + > > drivers/media/radio/wl128x/fmdrv_common.h | 402 +++ > > drivers/media/radio/wl128x/fmdrv_rx.c | 847 +++ > > drivers/media/radio/wl128x/fmdrv_rx.h | 59 + > > drivers/media/radio/wl128x/fmdrv_tx.c | 425 > > drivers/media/radio/wl128x/fmdrv_tx.h | 37 + > > drivers/media/radio/wl128x/fmdrv_v4l2.c | 580 ++ > > drivers/media/radio/wl128x/fmdrv_v4l2.h | 33 + > > 13 files changed, 4331 insertions(+), 0 deletions(-) > > create mode 100644 drivers/media/radio/wl128x/Kconfig > > create mode 100644 drivers/media/radio/wl128x/Makefile > > create mode 100644 drivers/media/radio/wl128x/fmdrv.h > > create mode 100644 drivers/media/radio/wl128x/fmdrv_common.c > > create mode 100644 drivers/media/radio/wl128x/fmdrv_common.h > > create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c > > create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h > > create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c > > create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h > > create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c > > create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send th
tuner and PAL decoder - runtime suspend
I'm trying to develop the tda9885 poweron + setting paramteres driver, using the v4l2 structure, that feeds a tvp5151. I can declare a tvp5151 input as V4L2_INPUT_TYPE_TUNER and than create a v4l2 subdev driver for tda9885. I don't know if I need to put code in tvp5151 driver in order to trigger the tda9885 power on + setting parameters (v4l2_device_call_all), or if there is an automatic way (I think so) to do it. Finally I'll add runtime suspend and resume code for tda9885 and tvp5151. Is there any recommendation to do this in the right way? Thx, Raffaele -- 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
please update dvb-t es-Madrid scan file
Hello, es-Madrid has to be updated: * Removing channels: - EsMadrid TV (not functional) - Onda 6 (now "la10") - CNN+ (now "Gran Hermano 24h") - 40 Latino (inexistent) - Telecinco Sport (inexistent) - Telecinco Estrellas (inexistent) - Fly Music (inexistent) *Adding channels: - La Sexta 2 (not correctly tuned) - La Sexta 3 (new channel) - Nitro (new channel) - Boing (new channel) - La Siete (new channel) - La Sexta HD (HD) - TVE HD - pruebas (HD) - Telecinco HD (HD) - Telemadrid HD (HD) THANKS, Alberto. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 28 Feb 2011, Sakari Ailus wrote: > On Mon, Feb 28, 2011 at 12:37:06PM +0100, Guennadi Liakhovetski wrote: > > So, you'd also need a separate control for external exposure, there are > > also sensors, that can be configured to different shutter / exposure / > > readout sequence controlling... No, we don't have to support all that > > variety, but we have to be aware of it, while making decisions;) > > Hi Guennadi, > > Do you mean that there are sensors that can synchronise these parameters at > frame level, or how? There are use cases for that but it doesn't limit to > still capture. No, sorry, I don't mean exposure value, by "external exposure" I meant the EXPOSURE pin. But in fact, as I see now, it is just another name for the TRIGGER pin:( But what we do have on some sensors, e.g., on MT9T031. On mt9t031 they distinguish between the beginning of the shutter sequence, the exposure and the read sequence, and depending on a parameter they decide which signals to use to start which action. > Are there any public datasheets that you know of on these? I think, I just searched for mt9t031 and found a datasheet somewhere in the wild... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, Feb 28, 2011 at 12:37:06PM +0100, Guennadi Liakhovetski wrote: > So, you'd also need a separate control for external exposure, there are > also sensors, that can be configured to different shutter / exposure / > readout sequence controlling... No, we don't have to support all that > variety, but we have to be aware of it, while making decisions;) Hi Guennadi, Do you mean that there are sensors that can synchronise these parameters at frame level, or how? There are use cases for that but it doesn't limit to still capture. Are there any public datasheets that you know of on these? Regards, -- Sakari Ailus sakari dot ailus at iki dot fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Well supported USB DVB-C device?
Antti Palosaari wrote > On 02/28/2011 02:02 AM, Malte Gell wrote: > > is there a DVB-C device with USB that is well supported by a recent > > kernel (2.6.38)? I have found a device from Terratec, the Terratec H7. They have published a driver for this device at http://linux.terratec.de/files/TERRATEC_H7_Linux.tar.gz So I think, I will try this device when I have figured out, how their kernel modules is to be built. Malte -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Fri, 25 Feb 2011, Guennadi Liakhovetski wrote: > On Fri, 25 Feb 2011, Sakari Ailus wrote: > > > On Fri, Feb 25, 2011 at 06:08:07PM +0100, Guennadi Liakhovetski wrote: > > > > > What we could also do, we could add an optional callback to subdev > > > (core?) > > > operations, which, if activated, the host would call on each frame > > > completion. > > > > It's not quite that simple. The exposure of the next frame has started long > > time before that. This requires much more thought probably --- in the case > > of lack of hardware support, when the parameters need to be actually given > > to the sensor depend somewhat on sensors, I suppose. > > Yes, that's right. I seem to remember, there was a case, for which such a > callback would have been useful... Don't remember what that was though. I remember now:) I meant to use it to trigger the next frame from the software per sensor I2C command, if no hardware trigger is available. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 28 Feb 2011, Hans Verkuil wrote: > Does anyone know which drivers stop capture if there are no buffers > available? > I'm not aware of any. Many soc-camera hosts do that. > I think this is certainly a good initial approach. > > Can someone make a list of things needed for flash/snapshot? So don't look > yet > at the implementation, but just start a list of functionalities that we need > to support. I don't think I have seen that yet. These are not the features, that we _have_ to implement, these are just the ones, that are related to the snapshot mode: * flash strobe (provided, we do not want to control its timing from generic controls, and leave that to "reasonable defaults" or to private controls) * trigger pin / command * external exposure * exposure mode (ERS, GRR,...) * use "trigger" or "shutter" for readout * number of frames to capture Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
Tested-by: Michal Wegrzynek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 28 Feb 2011, Laurent Pinchart wrote: > > > > I don't think snapshot capture is *that* special. I don't expect most > > > > embedded SoCs to implement snapshot capture in hardware. What usually > > > > happens is that the hardware provides some support (like two independent > > > > video streams for instance, or the ability to capture a given number of > > > > frames) and the scheduling is performed in userspace. Good quality > > > > snapshot capture requires complex algorithms and involves several > > > > hardware pieces (ISP, flash controller, lens controller, ...), so it > > > > can't be implemented in the kernel. > > > > > > I agree. > > > > Right, but sensors do need it. It is not enough to just tell the sensor - > > a per-frame flash is used and let the driver figure out, that it has to > > switch to snapshot mode. The snapshot mode has other effects too, e.g., on > > some sensors it enables the external trigger pin, which some designs might > > want to use also without a flash. Maybe there are also some other side > > effects of such snapshot modes on some other sensors, that I'm not aware > > of. > > This makes me wonder if we need a snapshot mode at all. Why should we tie > flash, capture trigger (and other such options that you're not aware of yet > :-)) together under a single high-level control (in the general sense, not to > be strictly taken as a V4L2 CID) ? Wouldn't it be better to expose those > features individually instead ? User might want to use the flash in video > capture mode for a stroboscopic effect for instance. So, you'd also need a separate control for external exposure, there are also sensors, that can be configured to different shutter / exposure / readout sequence controlling... No, we don't have to support all that variety, but we have to be aware of it, while making decisions;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
On 2011-01-16 21:44, Mariusz Bialonczyk wrote: Fixing the very annoying tunning issue. When switching from DVB-S2 to DVB-S, it often took minutes to have a lock. > [...] The patch is changing the frontend from stv0900 to stv090x. The card now works much more reliable. There is no problem with switching from DVB-S2 to DVB-S, tunning works flawless. Igor, can I get your ACK on this patch? regards, -- Mariusz Bialonczyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net -- 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
[DVB] Maintainers of dvb_core and budget_ci modules - Patches proposal
Dear all, Are-there some maintainers for the dvb_core module and the budget_ci module on the linux-media mailing list? I would like to discuss and submit some patches I have developed for these modules: - dvb_core: add an option for logging the PDU exchanged with the CAM for debugging purposes - dvb_core: clean all ring buffers associated with CAM when a device is opened - budget_ci: print information about CI firmware used - budget_ci: add module option for disabling the IR receiver and the IRQ mode Best regards, Sebastien. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Sun, 27 Feb 2011, Sakari Ailus wrote: > Hi, > > Guennadi Liakhovetski wrote: > > On Fri, 25 Feb 2011, Sakari Ailus wrote: > > > > > Hi Guennadi, > > > > > > Guennadi Liakhovetski wrote: > > > > In principle - yes, and yes, I do realise, that the couple of controls, > > > > that I've proposed only cover a very minor subset of the whole flash > > > > function palette. The purposes of my RFC were: > > > > > > Why would there be a different interface for controlling the flash in > > > simple cases and more complex cases? > > > > Sorry, not sure what you mean. Do you mean different APIs when the flash > > is controlled directly by the sensor and by an external controller? No, of > > course we need one API, but you either issue those ioctl()s to the sensor > > (sub)device, or to the dedicated flash (sub)device. If you mean my "minor > > subset" above, then I was trying to say, that this is a basis, that has to > > be extended, but not, that we will develop a new API for more complicated > > cases. > > I think I misunderstood you originally, sorry. I should have properly read the > RFC. :-) > > Your proposal of the flash mode is good, but what about software strobe (a > little more on that below)? > > Also, what about making this a V4L2 control instead? These are two things, I think: first we have to decide which functions we need, second - how to implement them. Sure, controls are also a possibility. > The ADP1653 driver that > Laurent referred to implements flash control using V4L2 controls only. > > A version of the driver is here: > > http://gitorious.org/omap3camera/mainline/commit/a41027c857dfcbc268cf8d1c7c7d0ab8b6abac92> > > It's not yet in mainline --- one reason for this is the lack of time to > discuss a proper API for the flash. :-) > > ... > > > > > > This doesn't solve the flash/capture synchronization problem though. I > > > > > don't > > > > > think we need a dedicated snapshot capture mode at the V4L2 level. A > > > > > way to > > > > > configure the sensor to react on an external trigger provided by the > > > > > flash > > > > > controller is needed, and that could be a control on the flash > > > > > sub-device. > > > > > > > > Well... Sensors call this a "snapshot mode." I don't care that much how > > > > we > > > > _call_ it, but I do think, that we should be able to use it. > > > > > > Some sensors and webcams might have that, but newer camera solutions > > > tend to contain a raw bayer sensor and and ISP. There is no concept of > > > snapsnot mode in these sensors. > > > > Hm, I am not sure I understand, why sensors with DSPs in them should have > > no notion of a snapshot mode. Do they have no strobe / trigger pins? And > > no built in possibility to synchronize with a flash? > > I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a flash > strobe pin while some doesn't (such as the N900). Of course, if no flash is present, you don't have to support it;) > Still, even if the strobe pin is missing it should be possible to allow > strobing the flash by using software strobe (usually an I2C message). > > I agree using a hardware strobe is much much better if it's available. Again - don't understand. Above (i2c message) you're referring to the sensor. But I don't think toggling the flash on per-frame basis from software via the sensor makes much sense. That way you could also just wire your flash to a GPIO. The main advantage of a sensor-controlled flash is, that is toggles the flash automatically, synchronised with its image read-out. You would, however, toggle the flash manually, if you just wanted to turn it on permanently (torch-mode). > > > > Hm, don't think only the "flash subdevice" has to know about this. > > > > First, > > > > you have to switch the sensor into that mode. Second, it might be either > > > > external trigger from the flash controller, or a programmed trigger and > > > > a > > > > flash strobe from the sensor to the flash (controller). Third, well, not > > > > quite sure, but doesn't the host have to know about the snapshot mode? > > > > > > I do not favour adding use case type of functionality to interfaces that > > > do not necessarily need it. Would the concept of a snapshot be > > > parametrisable on V4L2 level? > > > > I am open to this. I don't have a good idea of whether camera hosts have > > to know about the snapshot mode or not. It's open for discussion. > > What functionality would the snapshot mode provide? Flash synchronisation? > Something else? Also pre-defined number of images, enabling of the trigger pin and trigger i2c command. Just noticed - on mt9t031 and mt9v022 the snapshot mode also enables externally controlled exposure... > I have to admit I don't know of any hardware which would recognise a concept > of "snapshot". Do you have a smart sensor which does this, for example? The > only hardware support for the flash use I know of is the flash strobe signal. Several Aptina / Micron sensors have
Re: [RFC] snapshot mode, flash capabilities and control
On Monday 28 February 2011 12:17:12 Hans Verkuil wrote: > On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote: > > On Monday 28 February 2011 12:02:41 Guennadi Liakhovetski wrote: > > > On Mon, 28 Feb 2011, Hans Verkuil wrote: [snip] > > > > It was my understanding that the streaming would stop if no capture > > > > buffers are available, requiring a VIDIOC_STREAMON to get it started > > > > again. Of course, there is nothing wrong with stopping the hardware > > > > and restarting it again when a new buffer becomes available if that > > > > can be done efficiently enough. Just as long as userspace doesn't > > > > notice. > > > > > > > > Note that there are some problems with this anyway: often restarting > > > > DMA requires resyncing to the video stream, which may lead to lost > > > > frames. Also, the framecounter in struct v4l2_buffer will probably > > > > have failed to count the lost frames. > > > > > > > > In my opinion trying this might cause more problems than it solves. > > > > > > So, do I understand it right, that currently there are drivers, that > > > overwrite the last buffers while waiting for a new one, and ones, that > > > stop capture for that time. > > Does anyone know which drivers stop capture if there are no buffers > available? I'm not aware of any. Do you mean stop capture in a way that requires an explicit VIDIOC_STREAMON ? None that I'm aware of (and I think that would violate the spec). If you instead mean pause capture and restart it on the next VIDIOC_QBUF, uvcvideo (somehow) does that, and the OMAP3 ISP does as well. > > > None of them violate the spec, but the former will not work with the > > > "snapshot mode," and the latter will. Since we do not want / cannot > > > enforce either way, we do need a way to tell the driver to enter the > > > "snapshot mode" even if only to not overwrite the last buffer, right? [snip] > > > Right, but sensors do need it. It is not enough to just tell the sensor > > > - a per-frame flash is used and let the driver figure out, that it has > > > to switch to snapshot mode. The snapshot mode has other effects too, > > > e.g., on some sensors it enables the external trigger pin, which some > > > designs might want to use also without a flash. Maybe there are also > > > some other side effects of such snapshot modes on some other sensors, > > > that I'm not aware of. > > > > This makes me wonder if we need a snapshot mode at all. Why should we tie > > flash, capture trigger (and other such options that you're not aware of > > yet :-)) together under a single high-level control (in the general sense, > > not to be strictly taken as a V4L2 CID) ? Wouldn't it be better to expose > > those features individually instead ? User might want to use the flash in > > video capture mode for a stroboscopic effect for instance. > > I think this is certainly a good initial approach. > > Can someone make a list of things needed for flash/snapshot? So don't look > yet at the implementation, but just start a list of functionalities that > we need to support. I don't think I have seen that yet. That's the right approach. I'll ping people internally to see if we have such a list already. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Monday, February 28, 2011 12:07:33 Laurent Pinchart wrote: > Hi Guennadi, > > On Monday 28 February 2011 12:02:41 Guennadi Liakhovetski wrote: > > On Mon, 28 Feb 2011, Hans Verkuil wrote: > > > On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote: > > > > On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote: > > > > > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: > > > > > > On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: > > > > > > > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > > > > > >> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski > > > > > > >> wrote: > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > configure the sensor to react on an external trigger provided > > > > > > > by the flash controller is needed, and that could be a > > > > > > > control on the flash sub-device. What we would probably miss > > > > > > > is a way to issue a STREAMON with a number of frames to > > > > > > > capture. A new ioctl is probably needed there. Maybe that > > > > > > > would be an opportunity to create a new stream-control ioctl > > > > > > > that could replace STREAMON and STREAMOFF in the long term > > > > > > > (we could extend the subdev s_stream operation, and easily > > > > > > > map STREAMON and STREAMOFF to the new ioctl in video_ioctl2 > > > > > > > internally). > > > > > > > > > > > > How would this be different from queueing n frames (in total; > > > > > > count dequeueing, too) and issuing streamon? --- Except that > > > > > > when the last frame is processed the pipeline could be stopped > > > > > > already before issuing STREAMOFF. That does indeed have some > > > > > > benefits. Something else? > > > > > > >>> > > > > > > >>> Well, you usually see in your host driver, that the videobuffer > > > > > > >>> queue is empty (no more free buffers are available), so, you > > > > > > >>> stop streaming immediately too. > > > > > > >> > > > > > > >> This probably assumes that the host driver knows that this is a > > > > > > >> special queue? Because in general drivers will simply keep > > > > > > >> capturing in the last buffer and not release it to userspace > > > > > > >> until a new buffer is queued. > > > > > > > > > > > > > > Yes, I know about this spec requirement, but I also know, that > > > > > > > not all drivers do that and not everyone is happy about that > > > > > > > requirement:) > > > > > > > > > > > > Right, similarly a v4l2 output device is not releasing the last > > > > > > buffer to userland and keeps sending its content until a new > > > > > > buffer is queued to the driver. But in case of capture device the > > > > > > requirement is a pain, since it only causes draining the power > > > > > > source, when from a user view the video capture is stopped. Also it > > > > > > limits a minimum number of buffers that could be used in preview > > > > > > pipeline. > > > > > > > > > > No, we can't change this. We can of course add some setting that will > > > > > explicitly request different behavior. > > > > > > > > > > The reason this is done this way comes from the traditional TV/webcam > > > > > viewing apps. If for some reason the app can't keep up with the > > > > > capture rate, then frames should just be dropped silently. All apps > > > > > assume this behavior. In a normal user environment this scenario is > > > > > perfectly normal (e.g. you use a webcam app, then do a CPU intensive > > > > > make run). > > > > > > > > Why couldn't drivers drop frames silently without a capture buffer ? If > > > > the hardware can be paused, the driver could just do that when the > > > > last buffer is given back to userspace, and resume the hardware when the > > > > next buffer is queued. > > > > > > It was my understanding that the streaming would stop if no capture > > > buffers are available, requiring a VIDIOC_STREAMON to get it started > > > again. Of course, there is nothing wrong with stopping the hardware and > > > restarting it again when a new buffer becomes available if that can be > > > done efficiently enough. Just as long as userspace doesn't notice. > > > > > > Note that there are some problems with this anyway: often restarting DMA > > > requires resyncing to the video stream, which may lead to lost frames. > > > Also, the framecounter in struct v4l2_buffer will probably have failed > > > to count the lost frames. > > > > > > In my opinion trying this might cause more problems than it solves. > > > > So, do I understand it right, that currently there are drivers, that > > overwrite the last buffers while waiting for a new one, and ones, that > > stop capture for that time. Does anyone know which drivers stop capture if there are no buffers available? I'm not aware of any. > > None of them violate the spec, but the former > > will not work with the "snapshot mode," and the latter will. Since we do > > not want / cannot enforce eit
Re: ec168-9295d36ab66e compiling error
On 02/28/2011 11:39 AM, Antti Palosaari wrote: On 02/28/2011 12:37 PM, Vinicio Nocciolini wrote: [ 304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware [ 304.742587] dvb-usb: did not find the firmware file. (dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) That error message should be rather clear. Use Google to find correct firmware. Antti root@localhost ~]# w_scan -c IT w_scan version 20110206 (compiled for DVB API 5.2) using settings for SPAIN DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 Info: using DVB adapter auto detection. main:3030: FATAL: * NO USEABLE DVB CARD FOUND. * Please check wether dvb driver is loaded and verify that no dvb application (i.e. vdr) is running. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
Hi Guennadi, On Monday 28 February 2011 12:02:41 Guennadi Liakhovetski wrote: > On Mon, 28 Feb 2011, Hans Verkuil wrote: > > On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote: > > > On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote: > > > > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: > > > > > On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: > > > > > > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > > > > >> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski > > > > > >> wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > > configure the sensor to react on an external trigger provided > > > > > > by the flash controller is needed, and that could be a > > > > > > control on the flash sub-device. What we would probably miss > > > > > > is a way to issue a STREAMON with a number of frames to > > > > > > capture. A new ioctl is probably needed there. Maybe that > > > > > > would be an opportunity to create a new stream-control ioctl > > > > > > that could replace STREAMON and STREAMOFF in the long term > > > > > > (we could extend the subdev s_stream operation, and easily > > > > > > map STREAMON and STREAMOFF to the new ioctl in video_ioctl2 > > > > > > internally). > > > > > > > > > > How would this be different from queueing n frames (in total; > > > > > count dequeueing, too) and issuing streamon? --- Except that > > > > > when the last frame is processed the pipeline could be stopped > > > > > already before issuing STREAMOFF. That does indeed have some > > > > > benefits. Something else? > > > > > >>> > > > > > >>> Well, you usually see in your host driver, that the videobuffer > > > > > >>> queue is empty (no more free buffers are available), so, you > > > > > >>> stop streaming immediately too. > > > > > >> > > > > > >> This probably assumes that the host driver knows that this is a > > > > > >> special queue? Because in general drivers will simply keep > > > > > >> capturing in the last buffer and not release it to userspace > > > > > >> until a new buffer is queued. > > > > > > > > > > > > Yes, I know about this spec requirement, but I also know, that > > > > > > not all drivers do that and not everyone is happy about that > > > > > > requirement:) > > > > > > > > > > Right, similarly a v4l2 output device is not releasing the last > > > > > buffer to userland and keeps sending its content until a new > > > > > buffer is queued to the driver. But in case of capture device the > > > > > requirement is a pain, since it only causes draining the power > > > > > source, when from a user view the video capture is stopped. Also it > > > > > limits a minimum number of buffers that could be used in preview > > > > > pipeline. > > > > > > > > No, we can't change this. We can of course add some setting that will > > > > explicitly request different behavior. > > > > > > > > The reason this is done this way comes from the traditional TV/webcam > > > > viewing apps. If for some reason the app can't keep up with the > > > > capture rate, then frames should just be dropped silently. All apps > > > > assume this behavior. In a normal user environment this scenario is > > > > perfectly normal (e.g. you use a webcam app, then do a CPU intensive > > > > make run). > > > > > > Why couldn't drivers drop frames silently without a capture buffer ? If > > > the hardware can be paused, the driver could just do that when the > > > last buffer is given back to userspace, and resume the hardware when the > > > next buffer is queued. > > > > It was my understanding that the streaming would stop if no capture > > buffers are available, requiring a VIDIOC_STREAMON to get it started > > again. Of course, there is nothing wrong with stopping the hardware and > > restarting it again when a new buffer becomes available if that can be > > done efficiently enough. Just as long as userspace doesn't notice. > > > > Note that there are some problems with this anyway: often restarting DMA > > requires resyncing to the video stream, which may lead to lost frames. > > Also, the framecounter in struct v4l2_buffer will probably have failed > > to count the lost frames. > > > > In my opinion trying this might cause more problems than it solves. > > So, do I understand it right, that currently there are drivers, that > overwrite the last buffers while waiting for a new one, and ones, that > stop capture for that time. None of them violate the spec, but the former > will not work with the "snapshot mode," and the latter will. Since we do > not want / cannot enforce either way, we do need a way to tell the driver > to enter the "snapshot mode" even if only to not overwrite the last > buffer, right? > > > > > I agree that you might want different behavior in an embedded > > > > environment, but that should be requested explicitly. > > > > > > > > > In still capture mode (single shot) we might want to use only
[PATCH v20 0/3] ASoC/MFD/V4L2: WL1273 FM Radio driver
Hello. And thanks for the comments. If we now move quickly enough we can get this thing in before it becomes deprecated... Samuel wrote: > for Mauro to take this one you'd have to provide a > diff against the already existing wl1273-core. I've made these patches against the existing stuff. >> + * Copyright (C) 2010 Nokia Corporation >2011. Changed. >> +} > I'm confused with this one: Isn't WL1273_VOLUME_SET a command ? Also, > how can reading from it set the volume ? It cannot... so I've changed it (back) to write. >> + i2c_set_clientdata(client, NULL) >Not needed. Removed. >> +err: >> + i2c_set_clientdata(client, NULL); >Ditto. Ditto. Cheers, Matti Matti J. Aaltonen (3): MFD: Wl1273 FM radio core: Add I2C IO functions. V4L2: Wl1273 FM Radio: Remove I2C IO functions. ASoC: WL1273 FM radio: Access I2C IO functions through pointers. drivers/media/radio/radio-wl1273.c | 360 +++- drivers/mfd/Kconfig|2 +- drivers/mfd/wl1273-core.c | 149 +++- include/linux/mfd/wl1273-core.h|2 + sound/soc/codecs/Kconfig |2 +- sound/soc/codecs/wl1273.c | 11 +- 6 files changed, 264 insertions(+), 262 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v20 2/3] V4L2: Wl1273 FM Radio: Remove I2C IO functions.
Remove I2C IO functions. After refactoring they currently belong to the Wl1273 MFD driver. And now the IO functions are accessed through pointers. Update the year in the copyright statement. Signed-off-by: Matti J. Aaltonen --- drivers/media/radio/radio-wl1273.c | 360 +++- 1 files changed, 106 insertions(+), 254 deletions(-) diff --git a/drivers/media/radio/radio-wl1273.c b/drivers/media/radio/radio-wl1273.c index 7ecc8e6..9e177dc 100644 --- a/drivers/media/radio/radio-wl1273.c +++ b/drivers/media/radio/radio-wl1273.c @@ -1,7 +1,7 @@ /* * Driver for the Texas Instruments WL1273 FM radio. * - * Copyright (C) 2010 Nokia Corporation + * Copyright (C) 2011 Nokia Corporation * Author: Matti J. Aaltonen * * This program is free software; you can redistribute it and/or @@ -104,58 +104,6 @@ static unsigned int rds_buf = 100; module_param(rds_buf, uint, 0); MODULE_PARM_DESC(rds_buf, "Number of RDS buffer entries. Default = 100"); -static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value) -{ - struct i2c_client *client = core->client; - u8 b[2]; - int r; - - r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b); - if (r != 2) { - dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg); - return -EREMOTEIO; - } - - *value = (u16)b[0] << 8 | b[1]; - - return 0; -} - -static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param) -{ - struct i2c_client *client = core->client; - u8 buf[] = { (param >> 8) & 0xff, param & 0xff }; - int r; - - r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf); - if (r) { - dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd); - return r; - } - - return 0; -} - -static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len) -{ - struct i2c_client *client = core->client; - struct i2c_msg msg; - int r; - - msg.addr = client->addr; - msg.flags = 0; - msg.buf = data; - msg.len = len; - - r = i2c_transfer(client->adapter, &msg, 1); - if (r != 1) { - dev_err(&client->dev, "%s: write error.\n", __func__); - return -EREMOTEIO; - } - - return 0; -} - static int wl1273_fm_write_fw(struct wl1273_core *core, __u8 *fw, int len) { @@ -188,94 +136,6 @@ static int wl1273_fm_write_fw(struct wl1273_core *core, return r; } -/** - * wl1273_fm_set_audio() - Set audio mode. - * @core: A pointer to the device struct. - * @new_mode: The new audio mode. - * - * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG. - */ -static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode) -{ - int r = 0; - - if (core->mode == WL1273_MODE_OFF || - core->mode == WL1273_MODE_SUSPENDED) - return -EPERM; - - if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) { - r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET, - WL1273_PCM_DEF_MODE); - if (r) - goto out; - - r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET, - core->i2s_mode); - if (r) - goto out; - - r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE, - WL1273_AUDIO_ENABLE_I2S); - if (r) - goto out; - - } else if (core->mode == WL1273_MODE_RX && - new_mode == WL1273_AUDIO_ANALOG) { - r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE, - WL1273_AUDIO_ENABLE_ANALOG); - if (r) - goto out; - - } else if (core->mode == WL1273_MODE_TX && - new_mode == WL1273_AUDIO_DIGITAL) { - r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET, - core->i2s_mode); - if (r) - goto out; - - r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET, - WL1273_AUDIO_IO_SET_I2S); - if (r) - goto out; - - } else if (core->mode == WL1273_MODE_TX && - new_mode == WL1273_AUDIO_ANALOG) { - r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET, - WL1273_AUDIO_IO_SET_ANALOG); - if (r) - goto out; - } - - core->audio_mode = new_mode; -out: - return r; -} - -/** - * wl1273_fm_set_volume() -Set volume. - * @core: A pointer to the device struct. - * @volume:
[PATCH v20 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.
These changes are needed to keep up with the changes in the MFD core and V4L2 parts of the wl1273 FM radio driver. Use function pointers instead of exported functions for I2C IO. Also move all preprocessor constants from the wl1273.h to include/linux/mfd/wl1273-core.h. Also update the year in the copyright statement. Signed-off-by: Matti J. Aaltonen --- sound/soc/codecs/Kconfig |2 +- sound/soc/codecs/wl1273.c | 11 --- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index c48b23c..9726d6e 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -44,7 +44,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TWL6040 if TWL4030_CORE select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C - select SND_SOC_WL1273 if RADIO_WL1273 + select SND_SOC_WL1273 if MFD_WL1273_CORE select SND_SOC_WM2000 if I2C select SND_SOC_WM8350 if MFD_WM8350 select SND_SOC_WM8400 if MFD_WM8400 diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c index 861b28f..3c27fed 100644 --- a/sound/soc/codecs/wl1273.c +++ b/sound/soc/codecs/wl1273.c @@ -3,7 +3,7 @@ * * Author: Matti Aaltonen, * - * Copyright: (C) 2010 Nokia Corporation + * Copyright: (C) 2011 Nokia Corporation * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -179,7 +179,12 @@ static int snd_wl1273_get_audio_route(struct snd_kcontrol *kcontrol, return 0; } -static const char *wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" }; +/* + * TODO: Implement the audio routing in the driver. Now this control + * only indicates the setting that has been done elsewhere (in the user + * space). + */ +static const char * const wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" }; static int snd_wl1273_set_audio_route(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -239,7 +244,7 @@ static int snd_wl1273_fm_audio_put(struct snd_kcontrol *kcontrol, return 1; } -static const char *wl1273_audio_strings[] = { "Digital", "Analog" }; +static const char * const wl1273_audio_strings[] = { "Digital", "Analog" }; static const struct soc_enum wl1273_audio_enum = SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(wl1273_audio_strings), -- 1.6.1.3 -- 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 v20 1/3] MFD: Wl1273 FM radio core: Add I2C IO functions.
Add I2C IO functions. Change the IO operation from read to write in wl1273_fm_set_volume. Update the year of the copyright statement. Remove two unnecessary calls to i2c_set_clientdata. Signed-off-by: Matti J. Aaltonen --- drivers/mfd/Kconfig |2 +- drivers/mfd/wl1273-core.c | 149 ++- include/linux/mfd/wl1273-core.h |2 + 3 files changed, 149 insertions(+), 4 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index fd01836..9db079b 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -615,7 +615,7 @@ config MFD_VX855 and/or vx855_gpio drivers for this to do anything useful. config MFD_WL1273_CORE - tristate + tristate "Support for TI WL1273 FM radio." depends on I2C select MFD_CORE default n diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c index d2ecc24..4025a4b 100644 --- a/drivers/mfd/wl1273-core.c +++ b/drivers/mfd/wl1273-core.c @@ -1,7 +1,7 @@ /* * MFD driver for wl1273 FM radio and audio codec submodules. * - * Copyright (C) 2010 Nokia Corporation + * Copyright (C) 2011 Nokia Corporation * Author: Matti Aaltonen * * This program is free software; you can redistribute it and/or modify @@ -31,6 +31,145 @@ static struct i2c_device_id wl1273_driver_id_table[] = { }; MODULE_DEVICE_TABLE(i2c, wl1273_driver_id_table); +static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value) +{ + struct i2c_client *client = core->client; + u8 b[2]; + int r; + + r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b); + if (r != 2) { + dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg); + return -EREMOTEIO; + } + + *value = (u16)b[0] << 8 | b[1]; + + return 0; +} + +static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param) +{ + struct i2c_client *client = core->client; + u8 buf[] = { (param >> 8) & 0xff, param & 0xff }; + int r; + + r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf); + if (r) { + dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd); + return r; + } + + return 0; +} + +static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len) +{ + struct i2c_client *client = core->client; + struct i2c_msg msg; + int r; + + msg.addr = client->addr; + msg.flags = 0; + msg.buf = data; + msg.len = len; + + r = i2c_transfer(client->adapter, &msg, 1); + if (r != 1) { + dev_err(&client->dev, "%s: write error.\n", __func__); + return -EREMOTEIO; + } + + return 0; +} + +/** + * wl1273_fm_set_audio() - Set audio mode. + * @core: A pointer to the device struct. + * @new_mode: The new audio mode. + * + * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG. + */ +static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode) +{ + int r = 0; + + if (core->mode == WL1273_MODE_OFF || + core->mode == WL1273_MODE_SUSPENDED) + return -EPERM; + + if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) { + r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET, + WL1273_PCM_DEF_MODE); + if (r) + goto out; + + r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET, + core->i2s_mode); + if (r) + goto out; + + r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE, + WL1273_AUDIO_ENABLE_I2S); + if (r) + goto out; + + } else if (core->mode == WL1273_MODE_RX && + new_mode == WL1273_AUDIO_ANALOG) { + r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE, + WL1273_AUDIO_ENABLE_ANALOG); + if (r) + goto out; + + } else if (core->mode == WL1273_MODE_TX && + new_mode == WL1273_AUDIO_DIGITAL) { + r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET, + core->i2s_mode); + if (r) + goto out; + + r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET, + WL1273_AUDIO_IO_SET_I2S); + if (r) + goto out; + + } else if (core->mode == WL1273_MODE_TX && + new_mode == WL1273_AUDIO_ANALOG) { + r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET, + WL1273_AUDIO_IO_SET_ANALOG); + if (r) + goto
Re: [RFC] snapshot mode, flash capabilities and control
On Mon, 28 Feb 2011, Hans Verkuil wrote: > On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote: > > Hi Hans, > > > > On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote: > > > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: > > > > On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: > > > > > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > > > >> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: > > > > >> > > > > >> > > > > >> > > > > > configure the sensor to react on an external trigger provided by > > > > > the flash controller is needed, and that could be a control on the > > > > > flash sub-device. What we would probably miss is a way to issue a > > > > > STREAMON with a number of frames to capture. A new ioctl is > > > > > probably needed there. Maybe that would be an opportunity to > > > > > create a new stream-control ioctl that could replace STREAMON and > > > > > STREAMOFF in the long term (we could extend the subdev s_stream > > > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl > > > > > in video_ioctl2 internally). > > > > > > > > How would this be different from queueing n frames (in total; count > > > > dequeueing, too) and issuing streamon? --- Except that when the > last > > > > frame is processed the pipeline could be stopped already before > > > > issuing STREAMOFF. That does indeed have some benefits. Something > > > > else? > > > > >>> > > > > >>> Well, you usually see in your host driver, that the videobuffer > queue > > > > >>> is empty (no more free buffers are available), so, you stop > > > > >>> streaming immediately too. > > > > >> > > > > >> This probably assumes that the host driver knows that this is a > > > > >> special queue? Because in general drivers will simply keep capturing > > > > >> in the last buffer and not release it to userspace until a new buffer > > > > >> is queued. > > > > > > > > > > Yes, I know about this spec requirement, but I also know, that not all > > > > > drivers do that and not everyone is happy about that requirement:) > > > > > > > > Right, similarly a v4l2 output device is not releasing the last buffer > > > > to userland and keeps sending its content until a new buffer is queued > to > > > > the driver. But in case of capture device the requirement is a pain, > > > > since it only causes draining the power source, when from a user view > > > > the video capture is stopped. Also it limits a minimum number of buffers > > > > that could be used in preview pipeline. > > > > > > No, we can't change this. We can of course add some setting that will > > > explicitly request different behavior. > > > > > > The reason this is done this way comes from the traditional TV/webcam > > > viewing apps. If for some reason the app can't keep up with the capture > > > rate, then frames should just be dropped silently. All apps assume this > > > behavior. In a normal user environment this scenario is perfectly normal > > > (e.g. you use a webcam app, then do a CPU intensive make run). > > > > Why couldn't drivers drop frames silently without a capture buffer ? If the > > hardware can be paused, the driver could just do that when the last buffer > is > > given back to userspace, and resume the hardware when the next buffer is > > queued. > > It was my understanding that the streaming would stop if no capture buffers > are available, requiring a VIDIOC_STREAMON to get it started again. Of > course, > there is nothing wrong with stopping the hardware and restarting it again > when > a new buffer becomes available if that can be done efficiently enough. Just > as > long as userspace doesn't notice. > > Note that there are some problems with this anyway: often restarting DMA > requires resyncing to the video stream, which may lead to lost frames. Also, > the framecounter in struct v4l2_buffer will probably have failed to count the > lost frames. > > In my opinion trying this might cause more problems than it solves. So, do I understand it right, that currently there are drivers, that overwrite the last buffers while waiting for a new one, and ones, that stop capture for that time. None of them violate the spec, but the former will not work with the "snapshot mode," and the latter will. Since we do not want / cannot enforce either way, we do need a way to tell the driver to enter the "snapshot mode" even if only to not overwrite the last buffer, right? > > > I agree that you might want different behavior in an embedded environment, > > > but that should be requested explicitly. > > > > > > > In still capture mode (single shot) we might want to use only one buffer > > > > so adhering to the requirement would not allow this, would it? > > > > > > That's one of the problems with still capture mode, yes. > > > > > > I have not yet seen a proposal for this that I really like. Most are too > > > specif
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
Hi Jiri, On Monday 28 February 2011 10:37:02 Jiri Slaby wrote: > mem->dma_handle is a dma address obtained by dma_alloc_coherent which > needn't be a physical address in presence of IOMMU. So ensure we are > remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper > by using virt_to_phys(mem->vaddr) and not mem->dma_handle. Quoting arch/arm/include/asm/memory.h, /* * These are *only* valid on the kernel direct mapped RAM memory. * Note: Drivers should NOT use these. They are the wrong * translation for translating DMA addresses. Use the driver * DMA support - see dma-mapping.h. */ static inline unsigned long virt_to_phys(const volatile void *x) { return __virt_to_phys((unsigned long)(x)); } Why would you use physically contiguous memory if you have an IOMMU anyway ? > While at it, use PFN_DOWN instead of explicit shift. > > Signed-off-by: Jiri Slaby > Cc: Mauro Carvalho Chehab > Cc: Konrad Rzeszutek Wilk > --- > drivers/media/video/videobuf-dma-contig.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/videobuf-dma-contig.c > b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a 100644 > --- a/drivers/media/video/videobuf-dma-contig.c > +++ b/drivers/media/video/videobuf-dma-contig.c > @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue > *q, > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > retval = remap_pfn_range(vma, vma->vm_start, > - mem->dma_handle >> PAGE_SHIFT, > + PFN_DOWN(virt_to_phys(mem->vaddr)) >size, vma->vm_page_prot); > if (retval) { > dev_err(q->dev, "mmap: remap failed with error %d. ", retval); -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Well supported USB DVB-C device?
On 02/28/2011 11:49 AM, Magnus Alm wrote: 2011/2/28 Antti Palosaari On 02/28/2011 02:02 AM, Malte Gell wrote: is there a DVB-C device with USB that is well supported by a recent kernel (2.6.38)? Anysee E30 C Plus is supported as far as I know. It works fine, besides the card reader. Yes it is working as E30 Combo Plus was too. The aim was try to say that you never know when chipset changes and it stops working. Anyhow, I am not currently aware that, I am that driver author. Card reader is not supported in any of the Anysee models. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote: > Hi Hans, > > On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote: > > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: > > > On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: > > > > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > > >> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: > > > >> > > > >> > > > >> > > > > configure the sensor to react on an external trigger provided by > > > > the flash controller is needed, and that could be a control on the > > > > flash sub-device. What we would probably miss is a way to issue a > > > > STREAMON with a number of frames to capture. A new ioctl is > > > > probably needed there. Maybe that would be an opportunity to > > > > create a new stream-control ioctl that could replace STREAMON and > > > > STREAMOFF in the long term (we could extend the subdev s_stream > > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl > > > > in video_ioctl2 internally). > > > > > > How would this be different from queueing n frames (in total; count > > > dequeueing, too) and issuing streamon? --- Except that when the last > > > frame is processed the pipeline could be stopped already before > > > issuing STREAMOFF. That does indeed have some benefits. Something > > > else? > > > >>> > > > >>> Well, you usually see in your host driver, that the videobuffer queue > > > >>> is empty (no more free buffers are available), so, you stop > > > >>> streaming immediately too. > > > >> > > > >> This probably assumes that the host driver knows that this is a > > > >> special queue? Because in general drivers will simply keep capturing > > > >> in the last buffer and not release it to userspace until a new buffer > > > >> is queued. > > > > > > > > Yes, I know about this spec requirement, but I also know, that not all > > > > drivers do that and not everyone is happy about that requirement:) > > > > > > Right, similarly a v4l2 output device is not releasing the last buffer > > > to userland and keeps sending its content until a new buffer is queued to > > > the driver. But in case of capture device the requirement is a pain, > > > since it only causes draining the power source, when from a user view > > > the video capture is stopped. Also it limits a minimum number of buffers > > > that could be used in preview pipeline. > > > > No, we can't change this. We can of course add some setting that will > > explicitly request different behavior. > > > > The reason this is done this way comes from the traditional TV/webcam > > viewing apps. If for some reason the app can't keep up with the capture > > rate, then frames should just be dropped silently. All apps assume this > > behavior. In a normal user environment this scenario is perfectly normal > > (e.g. you use a webcam app, then do a CPU intensive make run). > > Why couldn't drivers drop frames silently without a capture buffer ? If the > hardware can be paused, the driver could just do that when the last buffer is > given back to userspace, and resume the hardware when the next buffer is > queued. It was my understanding that the streaming would stop if no capture buffers are available, requiring a VIDIOC_STREAMON to get it started again. Of course, there is nothing wrong with stopping the hardware and restarting it again when a new buffer becomes available if that can be done efficiently enough. Just as long as userspace doesn't notice. Note that there are some problems with this anyway: often restarting DMA requires resyncing to the video stream, which may lead to lost frames. Also, the framecounter in struct v4l2_buffer will probably have failed to count the lost frames. In my opinion trying this might cause more problems than it solves. > > I agree that you might want different behavior in an embedded environment, > > but that should be requested explicitly. > > > > > In still capture mode (single shot) we might want to use only one buffer > > > so adhering to the requirement would not allow this, would it? > > > > That's one of the problems with still capture mode, yes. > > > > I have not yet seen a proposal for this that I really like. Most are too > > specific to this use-case (snapshot) and I'd like to see something more > > general. > > I don't think snapshot capture is *that* special. I don't expect most embedded > SoCs to implement snapshot capture in hardware. What usually happens is that > the hardware provides some support (like two independent video streams for > instance, or the ability to capture a given number of frames) and the > scheduling is performed in userspace. Good quality snapshot capture requires > complex algorithms and involves several hardware pieces (ISP, flash > controller, lens controller, ...), so it can't be implemented in the kernel. I agree. Regards, Hans > > -- > Re
Re: [RFC] snapshot mode, flash capabilities and control
On Monday 28 February 2011 11:40:31 Hans Verkuil wrote: > On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote: > > On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote: > > > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: > > > > On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: > > > > > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > > > >> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: [snip] > > > > >>> Well, you usually see in your host driver, that the videobuffer > > > > >>> queue is empty (no more free buffers are available), so, you stop > > > > >>> streaming immediately too. > > > > >> > > > > >> This probably assumes that the host driver knows that this is a > > > > >> special queue? Because in general drivers will simply keep > > > > >> capturing in the last buffer and not release it to userspace > > > > >> until a new buffer is queued. > > > > > > > > > > Yes, I know about this spec requirement, but I also know, that not > > > > > all drivers do that and not everyone is happy about that > > > > > requirement:) > > > > > > > > Right, similarly a v4l2 output device is not releasing the last > > > > buffer to userland and keeps sending its content until a new buffer > > > > is queued to the driver. But in case of capture device the requirement > > > > is a pain, since it only causes draining the power source, when from a > > > > user view the video capture is stopped. Also it limits a minimum > > > > number of buffers that could be used in preview pipeline. > > > > > > No, we can't change this. We can of course add some setting that will > > > explicitly request different behavior. > > > > > > The reason this is done this way comes from the traditional TV/webcam > > > viewing apps. If for some reason the app can't keep up with the capture > > > rate, then frames should just be dropped silently. All apps assume this > > > behavior. In a normal user environment this scenario is perfectly > > > normal (e.g. you use a webcam app, then do a CPU intensive make run). > > > > Why couldn't drivers drop frames silently without a capture buffer ? If > > the hardware can be paused, the driver could just do that when the last > > buffer is given back to userspace, and resume the hardware when the next > > buffer is queued. > > It was my understanding that the streaming would stop if no capture buffers > are available, requiring a VIDIOC_STREAMON to get it started again. Of > course, there is nothing wrong with stopping the hardware and restarting > it again when a new buffer becomes available if that can be done > efficiently enough. Just as long as userspace doesn't notice. > > Note that there are some problems with this anyway: often restarting DMA > requires resyncing to the video stream, which may lead to lost frames. You'll loose frames when you get a buffer underrun anyway :-) > Also, the framecounter in struct v4l2_buffer will probably have failed to > count the lost frames. > > In my opinion trying this might cause more problems than it solves. Whether drivers will hold on the last buffer and keep filling it again and again until a new buffer is available, or stop the stream and resume it transparently when a new buffer is queued, should probably be left as a choice to the drivers. I'm in favour of the second option, but I understand that it might be difficult to implement for some hardware. The spec should at least not preclude it when efficient hardware support is available. > > > I agree that you might want different behavior in an embedded > > > environment, but that should be requested explicitly. > > > > > > > In still capture mode (single shot) we might want to use only one > > > > buffer so adhering to the requirement would not allow this, would > > > > it? > > > > > > That's one of the problems with still capture mode, yes. > > > > > > I have not yet seen a proposal for this that I really like. Most are > > > too specific to this use-case (snapshot) and I'd like to see something > > > more general. > > > > I don't think snapshot capture is *that* special. I don't expect most > > embedded SoCs to implement snapshot capture in hardware. What usually > > happens is that the hardware provides some support (like two independent > > video streams for instance, or the ability to capture a given number of > > frames) and the scheduling is performed in userspace. Good quality > > snapshot capture requires complex algorithms and involves several > > hardware pieces (ISP, flash controller, lens controller, ...), so it > > can't be implemented in the kernel. > > I agree. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ec168-9295d36ab66e compiling error
On 02/28/2011 12:37 PM, Vinicio Nocciolini wrote: [ 304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware [ 304.742587] dvb-usb: did not find the firmware file. (dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) That error message should be rather clear. Use Google to find correct firmware. 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: ec168-9295d36ab66e compiling error
On 02/27/2011 07:10 PM, Antti Palosaari wrote: Dont use my, or anyone else, old HG trees. You should follow that http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers Antti On 02/24/2011 04:24 PM, Vinicio Nocciolini wrote: Hi all I have problem compiling the project regards Vinicio --- CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/vc032x.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/zc3xx.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-control.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-core.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-video.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_cards.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_vp3028.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-functions.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.o /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c: In function '__ir_input_register': /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:452:24: warning: assignment from incompatible pointer type /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:453:24: warning: assignment from incompatible pointer type CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c: In function 'ir_register_class': /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: error: 'ir_raw_dev_type' undeclared (first use in this function) /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o] Error 1 make[2]: *** [_module_/home/vinicio/Desktop/ec168-9295d36ab66e/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.35.11-83.fc14.i686' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/vinicio/Desktop/ec168-9295d36ab66e/v4l' make: *** [all] Error 2 [vinicio@localhost ec168-9295d36ab66e]$ cat /etc/issue Fedora release 14 (Laughlin) Kernel \r on an \m (\l) -- 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 Hi I have compiled and installed the driver But I think there is an error regards Vinicio [root@localhost ~]# dmesg -c [ 304.598047] usb 1-4: new high speed USB device using ehci_hcd and address 5 [ 304.712607] usb 1-4: New USB device found, idVendor=18b4, idProduct=1689 [ 304.712614] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 304.715963] input: HID 18b4:1689 as /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0/input/input10 [ 304.716902] generic-usb 0003:18B4:1689.0004: input,hidraw0: USB HID v1.11 Keyboard [HID 18b4:1689] on usb-:00:1d.7-4/input0 [ 304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware [ 304.742587] dvb-usb: did not find the firmware file. (dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) [ 304.742603] dvb_usb_ec168: probe of 1-4:1.1 failed with error -2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [st-ericsson] v4l2 vs omx for camera
On Monday 28 February 2011 11:21:52 Hans Verkuil wrote: > On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote: > > On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote: > > > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote: > > > > 2011/2/24 Edward Hervey : > > > > > What *needs* to be solved is an API for data allocation/passing at > > > > > the kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and > > > > > that userspace (like GStreamer) can pass around, monitor and know > > > > > about. > > > > > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > > > Allocator) has been slightly modified to fit hand-in-glove with > > > > HWMEM, so CMA provides buffers, HWMEM pass them around. > > > > > > > > Johan, when you re-spin the HWMEM patchset, can you include > > > > linaro-dev and linux-media in the CC? > > > > > > Yes, please. This sounds promising and we at linux-media would very > > > much like to take a look at this. I hope that the CMA + HWMEM > > > combination is exactly what we need. > > > > Once again let me restate what I've been telling for some time: CMA must > > be *optional*. Not all hardware need contiguous memory. I'll have a look > > at the next HWMEM version. > > Yes, it is optional when you look at specific hardware. On a kernel level > however it is functionality that is required in order to support all the > hardware. There is little point in solving one issue and not the other. I agree. What I meant is that we need to make sure there's no HWMEM -> CMA dependency. -- 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
Sony CXD2099AR support
Hi, I have read that this CI chip driver is in staging because some questions on how to handle it are still not answered. I volunteer to handle this one. I'm a regular java developer, but I'm willing to put effort in learning linux drivers writing. So Ralph, can you give me some pointers on where the discussion should resume ? Do we put people of Mythtv and VDR in the discussion ? I guess so. I don't see anything related to MTD in the DVB CSA documents. I guess this should be left out of the driver. Thx, -- Issa -- Original Message -- Received: 11:48 AM CET, 02/25/2011 From: "Issa Gorissen" To: Subject: Re: Sony CXD2099AR decryption failing > Follow up on the trouble with Digital Devices DuoFlex S2, CI, SMIT Viaccess > CAM and Bis.tv card. > > The whole combination works under Windows 7 with Media Center. I have been > able to watch and change channels I'm entitled to in the Bis.TV package. Only > condition was to disable CI for tuner no 2. If the CI is activated for tuner 1 > and tuner 2, Media Center will not be able to change the channels. > > Anything I can do to make progress for this issue under linux ? > > > Thx > -- > Issa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
Hi Hans, On Saturday 26 February 2011 14:56:18 Hans Verkuil wrote: > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: > > On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: > > > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > >> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: > > >> > > >> > > >> > > > configure the sensor to react on an external trigger provided by > > > the flash controller is needed, and that could be a control on the > > > flash sub-device. What we would probably miss is a way to issue a > > > STREAMON with a number of frames to capture. A new ioctl is > > > probably needed there. Maybe that would be an opportunity to > > > create a new stream-control ioctl that could replace STREAMON and > > > STREAMOFF in the long term (we could extend the subdev s_stream > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl > > > in video_ioctl2 internally). > > > > How would this be different from queueing n frames (in total; count > > dequeueing, too) and issuing streamon? --- Except that when the last > > frame is processed the pipeline could be stopped already before > > issuing STREAMOFF. That does indeed have some benefits. Something > > else? > > >>> > > >>> Well, you usually see in your host driver, that the videobuffer queue > > >>> is empty (no more free buffers are available), so, you stop > > >>> streaming immediately too. > > >> > > >> This probably assumes that the host driver knows that this is a > > >> special queue? Because in general drivers will simply keep capturing > > >> in the last buffer and not release it to userspace until a new buffer > > >> is queued. > > > > > > Yes, I know about this spec requirement, but I also know, that not all > > > drivers do that and not everyone is happy about that requirement:) > > > > Right, similarly a v4l2 output device is not releasing the last buffer > > to userland and keeps sending its content until a new buffer is queued to > > the driver. But in case of capture device the requirement is a pain, > > since it only causes draining the power source, when from a user view > > the video capture is stopped. Also it limits a minimum number of buffers > > that could be used in preview pipeline. > > No, we can't change this. We can of course add some setting that will > explicitly request different behavior. > > The reason this is done this way comes from the traditional TV/webcam > viewing apps. If for some reason the app can't keep up with the capture > rate, then frames should just be dropped silently. All apps assume this > behavior. In a normal user environment this scenario is perfectly normal > (e.g. you use a webcam app, then do a CPU intensive make run). Why couldn't drivers drop frames silently without a capture buffer ? If the hardware can be paused, the driver could just do that when the last buffer is given back to userspace, and resume the hardware when the next buffer is queued. > I agree that you might want different behavior in an embedded environment, > but that should be requested explicitly. > > > In still capture mode (single shot) we might want to use only one buffer > > so adhering to the requirement would not allow this, would it? > > That's one of the problems with still capture mode, yes. > > I have not yet seen a proposal for this that I really like. Most are too > specific to this use-case (snapshot) and I'd like to see something more > general. I don't think snapshot capture is *that* special. I don't expect most embedded SoCs to implement snapshot capture in hardware. What usually happens is that the hardware provides some support (like two independent video streams for instance, or the ability to capture a given number of frames) and the scheduling is performed in userspace. Good quality snapshot capture requires complex algorithms and involves several hardware pieces (ISP, flash controller, lens controller, ...), so it can't be implemented in the kernel. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors
Hello, On Sunday, February 27, 2011 7:13 PM Laurent Pinchart wrote: > videobuf2 expects drivers to check buffer in the buf_prepare operation > and to return success only if the buffer can queued without any issue. > > For hot-pluggable devices, disconnection events need to be handled at > buf_queue time. Checking the disconnected flag and adding the buffer to > the driver queue need to be performed without releasing the driver > spinlock, otherwise race conditions can occur in which the driver could > still allow a buffer to be queued after the disconnected flag has been > set, resulting in a hang during the next DQBUF operation. > > This problem can be solved either in the videobuf2 core or in the device > drivers. To avoid adding a spinlock to videobuf2, make buf_queue return > an int and handle buf_queue failures in videobuf2. Drivers must not > return an error in buf_queue if the condition leading to the error can > be caught in buf_prepare. > > Signed-off-by: Laurent Pinchart Acked-by: Marek Szyprowski We discussed how to solve the hot-plug issue and this is the solution I prefer. > --- > drivers/media/video/videobuf2-core.c | 32 ++-- > include/media/videobuf2-core.h |2 +- > 2 files changed, 27 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/video/videobuf2-core.c > b/drivers/media/video/videobuf2-core.c > index cc7ab0a..1d81536 100644 > --- a/drivers/media/video/videobuf2-core.c > +++ b/drivers/media/video/videobuf2-core.c > @@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb, struct > v4l2_buffer *b) > /** > * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing > */ > -static void __enqueue_in_driver(struct vb2_buffer *vb) > +static int __enqueue_in_driver(struct vb2_buffer *vb) > { > struct vb2_queue *q = vb->vb2_queue; > + int ret; > > vb->state = VB2_BUF_STATE_ACTIVE; > atomic_inc(&q->queued_count); > - q->ops->buf_queue(vb); > + ret = q->ops->buf_queue(vb); > + if (ret == 0) > + return 0; > + > + vb->state = VB2_BUF_STATE_ERROR; > + atomic_dec(&q->queued_count); > + wake_up_all(&q->done_wq); > + > + return ret; > } > > /** > @@ -890,8 +899,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b) >* If already streaming, give the buffer to driver for processing. >* If not, the buffer will be given to driver on next streamon. >*/ > - if (q->streaming) > - __enqueue_in_driver(vb); > + if (q->streaming) { > + ret = __enqueue_in_driver(vb); > + if (ret < 0) { > + dprintk(1, "qbuf: buffer queue failed\n"); > + return ret; > + } > + } > > dprintk(1, "qbuf of buffer %d succeeded\n", vb->v4l2_buf.index); > return 0; > @@ -1101,6 +1115,7 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf); > int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type) > { > struct vb2_buffer *vb; > + int ret; > > if (q->fileio) { > dprintk(1, "streamon: file io in progress\n"); > @@ -1139,8 +1154,13 @@ int vb2_streamon(struct vb2_queue *q, enum > v4l2_buf_type type) >* If any buffers were queued before streamon, >* we can now pass them to driver for processing. >*/ > - list_for_each_entry(vb, &q->queued_list, queued_entry) > - __enqueue_in_driver(vb); > + list_for_each_entry(vb, &q->queued_list, queued_entry) { > + ret = __enqueue_in_driver(vb); > + if (ret < 0) { > + dprintk(1, "streamon: buffer queue failed\n"); > + return ret; > + } > + } > > dprintk(3, "Streamon successful\n"); > return 0; > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h > index 597efe6..3a92f75 100644 > --- a/include/media/videobuf2-core.h > +++ b/include/media/videobuf2-core.h > @@ -225,7 +225,7 @@ struct vb2_ops { > int (*start_streaming)(struct vb2_queue *q); > int (*stop_streaming)(struct vb2_queue *q); > > - void (*buf_queue)(struct vb2_buffer *vb); > + int (*buf_queue)(struct vb2_buffer *vb); > }; > > /** > -- > 1.7.3.4 Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
On Saturday 26 February 2011 14:03:53 Guennadi Liakhovetski wrote: > On Sat, 26 Feb 2011, Hans Verkuil wrote: > > On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: > > > > > > > > > > > configure the sensor to react on an external trigger provided by > > > > > the flash controller is needed, and that could be a control on the > > > > > flash sub-device. What we would probably miss is a way to issue a > > > > > STREAMON with a number of frames to capture. A new ioctl is > > > > > probably needed there. Maybe that would be an opportunity to > > > > > create a new stream-control ioctl that could replace STREAMON and > > > > > STREAMOFF in the long term (we could extend the subdev s_stream > > > > > operation, and easily map STREAMON and STREAMOFF to the new ioctl > > > > > in video_ioctl2 internally). > > > > > > > > How would this be different from queueing n frames (in total; count > > > > dequeueing, too) and issuing streamon? --- Except that when the last > > > > frame is processed the pipeline could be stopped already before > > > > issuing STREAMOFF. That does indeed have some benefits. Something > > > > else? > > > > > > Well, you usually see in your host driver, that the videobuffer queue > > > is empty (no more free buffers are available), so, you stop streaming > > > immediately too. > > > > This probably assumes that the host driver knows that this is a special > > queue? Because in general drivers will simply keep capturing in the last > > buffer and not release it to userspace until a new buffer is queued. > > Yes, I know about this spec requirement, but I also know, that not all > drivers do that and not everyone is happy about that requirement:) Is it a requirement, or just something some drivers do ? Several drivers just stop capturing when no buffer is available, and resume when a new buffer is queued. > > That said, it wouldn't be hard to add some flag somewhere that puts a > > queue in a 'stop streaming on last buffer capture' mode. > > No, it wouldn't... But TBH this doesn't seem like the most elegant and > complete solution. Maybe we have to think a bit more about it - which > soncequences switching into the snapshot mode has on the host driver, > apart from stopping after N frames. So, this is one of the possibilities, > not sure if the best one. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [st-ericsson] v4l2 vs omx for camera
On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote: > On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote: > > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote: > > > 2011/2/24 Edward Hervey : > > > > What *needs* to be solved is an API for data allocation/passing at the > > > > > > > > kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > > > > userspace (like GStreamer) can pass around, monitor and know about. > > > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > > so CMA provides buffers, HWMEM pass them around. > > > > > > Johan, when you re-spin the HWMEM patchset, can you include > > > linaro-dev and linux-media in the CC? > > > > Yes, please. This sounds promising and we at linux-media would very much > > like to take a look at this. I hope that the CMA + HWMEM combination is > > exactly what we need. > > Once again let me restate what I've been telling for some time: CMA must be > *optional*. Not all hardware need contiguous memory. I'll have a look at the > next HWMEM version. Yes, it is optional when you look at specific hardware. On a kernel level however it is functionality that is required in order to support all the hardware. There is little point in solving one issue and not the other. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [st-ericsson] v4l2 vs omx for camera
On Sunday 27 February 2011 20:49:37 Arnd Bergmann wrote: > On Saturday 26 February 2011, Edward Hervey wrote: > > > Are there any gstreamer/linaro/etc core developers attending the ELC in > > > San Francisco in April? I think it might be useful to get together > > > before, during or after the conference and see if we can turn this > > > discussion in something more concrete. > > > > > > It seems to me that there is an overall agreement of what should be > > > done, but that we are far from anything concrete. > > > > > I will be there and this was definitely a topic I intended to talk about. > > > > See you there. > > I'll also be there. Should we organize an official BOF session for this and > invite more people? Any chance of an IRC backchannel and a live audio/video stream for those of us who won't be there ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [st-ericsson] v4l2 vs omx for camera
On Sunday, February 27, 2011 20:49:37 Arnd Bergmann wrote: > On Saturday 26 February 2011, Edward Hervey wrote: > > > > > > Are there any gstreamer/linaro/etc core developers attending the ELC in San Francisco > > > in April? I think it might be useful to get together before, during or after the > > > conference and see if we can turn this discussion in something more concrete. > > > > > > It seems to me that there is an overall agreement of what should be done, but > > > that we are far from anything concrete. > > > > > > > I will be there and this was definitely a topic I intended to talk > > about. > > See you there. > > I'll also be there. Should we organize an official BOF session for this and > invite more people? I think that is an excellent idea. Do you want to organize that? (Always the penalty for suggesting this first :-) ) Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [st-ericsson] v4l2 vs omx for camera
On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote: > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote: > > 2011/2/24 Edward Hervey : > > > What *needs* to be solved is an API for data allocation/passing at the > > > > > > kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > > > userspace (like GStreamer) can pass around, monitor and know about. > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > so CMA provides buffers, HWMEM pass them around. > > > > Johan, when you re-spin the HWMEM patchset, can you include > > linaro-dev and linux-media in the CC? > > Yes, please. This sounds promising and we at linux-media would very much > like to take a look at this. I hope that the CMA + HWMEM combination is > exactly what we need. Once again let me restate what I've been telling for some time: CMA must be *optional*. Not all hardware need contiguous memory. I'll have a look at the next HWMEM version. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi, On Monday 28 February 2011 06:15:23 Kim, HeungJun wrote: > 2011-02-25 오후 9:58, Laurent Pinchart 쓴 글: > > On Friday 25 February 2011 13:46:01 Kim, HeungJun wrote: > >> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu > >> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO. > >> > >> Signed-off-by: Heungjun Kim > >> Signed-off-by: Kyungmin Park > >> --- > >> > >> drivers/media/video/uvc/uvc_ctrl.c |9 - > >> 1 files changed, 8 insertions(+), 1 deletions(-) > >> > >> diff --git a/drivers/media/video/uvc/uvc_ctrl.c > >> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..b98b9f1 100644 > >> --- a/drivers/media/video/uvc/uvc_ctrl.c > >> +++ b/drivers/media/video/uvc/uvc_ctrl.c > >> @@ -333,6 +333,11 @@ static struct uvc_menu_info > >> exposure_auto_controls[] = { { 8, "Aperture Priority Mode" }, > >> > >> }; > >> > >> +static struct uvc_menu_info focus_auto_controls[] = { > >> + { 1, "Auto Mode" }, > >> + { 0, "Manual Mode" }, > > > > Now that manual focus has value 0 and auto focus value 1, the menu > > entries need to be the other way around. > > I don't really get it. My understanding is that your words are structure > uvc_menu_info should be changed as fitted to focus menu type. right? > But, I thinks they don't need to be changed, and I don't find wrong, > I don't know how to fix what you telling me exactly. > > So, could you explain more details? Some examples helps to me. The menu entries are indexed by the V4L2 menu value. The first field is the UVC menu entry value, and the second field its name. As the V4L2 manual focus control has a value of 0, it must be the first entry. > Sorry to bother if you are busy, but it's good for me your advice. > I'll waiting. No worries. -- 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 v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
mem->dma_handle is a dma address obtained by dma_alloc_coherent which needn't be a physical address in presence of IOMMU. So ensure we are remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not mem->dma_handle. While at it, use PFN_DOWN instead of explicit shift. Signed-off-by: Jiri Slaby Cc: Mauro Carvalho Chehab Cc: Konrad Rzeszutek Wilk --- drivers/media/video/videobuf-dma-contig.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/videobuf-dma-contig.c b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a 100644 --- a/drivers/media/video/videobuf-dma-contig.c +++ b/drivers/media/video/videobuf-dma-contig.c @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q, vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); retval = remap_pfn_range(vma, vma->vm_start, -mem->dma_handle >> PAGE_SHIFT, +PFN_DOWN(virt_to_phys(mem->vaddr)) size, vma->vm_page_prot); if (retval) { dev_err(q->dev, "mmap: remap failed with error %d. ", retval); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [st-ericsson] v4l2 vs omx for camera
Hello, On Saturday, February 26, 2011 8:20 PM Nicolas Pitre wrote: > On Sat, 26 Feb 2011, Kyungmin Park wrote: > > > On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij > > wrote: > > > 2011/2/24 Edward Hervey : > > > > > >> What *needs* to be solved is an API for data allocation/passing at the > > >> kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > > >> userspace (like GStreamer) can pass around, monitor and know about. > > > > > > I think the patches sent out from ST-Ericsson's Johan Mossberg to > > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer > > > passing, pinning of buffers and so on. The CMA (Contigous Memory > > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM, > > > so CMA provides buffers, HWMEM pass them around. > > > > > > Johan, when you re-spin the HWMEM patchset, can you include > > > linaro-dev and linux-media in the CC? I think there is *much* interest > > > in this mechanism, people just don't know from the name what it > > > really does. Maybe it should be called mediamem or something > > > instead... > > > > To Marek, > > > > Can you also update the CMA status and plan? > > > > The important thing is still Russell don't agree the CMA since it's > > not solve the ARM different memory attribute mapping issue. Of course > > there's no way to solve the ARM issue. > > There are at least two ways to solve that issue, and I have suggested > both on the lak mailing list already. > > 1) Make the direct mapped kernel memory usable by CMA mapped through a >page-sized two-level page table mapping which would allow for solving >the attributes conflict on a per page basis. That's the solution I work on now. I've also suggested this in the last CMA discussion, however there was no response if this is the right way > 2) Use highmem more aggressively and allow only highmem pages for CMA. >This is quite easy to make sure the target page(s) for CMA would have >no kernel mappings and therefore no attribute conflict. Furthermore, >highmem pages are always relocatable for making physically contiguous >segments available. I'm not sure that highmem is the right solution. First, this will force systems with rather small amount of memory (like 256M) to use highmem just to support DMA allocable memory. It also doesn't solve the issue with specific memory requirement for our DMA hardware (multimedia codec needs video memory buffers from 2 physical banks). The relocation issue has been already addressed in the last CMA patch series. Michal managed to create a framework that allowed to relocate on demand any pages from the CMA area. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html