Re: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils
Hi, On 09/17/2010 12:58 AM, Andy Walls wrote: Hi Hans and Hans, I'd like to move the source code maintained here: http://ivtvdriver.org/svn/ to someplace where it may be less likely to suffer bit rot. I was hoping the v4l-utils git repo would be an appropriate place. Do either of you have any opinions on this? Moving this to v4l-utils.git is fine with me, assuming it is ok with the owner of the code too (H. Verkuil I think ?). 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
[GIT PATCHES FOR 2.6.36] Two small fixes for Conexant TV chip drivers
Mauro, Please pull the following two small changes for 2.6.36 and later kernels. Thanks go to Igor M. Liplianin for reporting the cx25840 bug and Dan Rosenberg for fixing the possible information leak in the ivtvfb driver. The following changes since commit 67ac062a5138ed446a821051fddd798a01478f85: V4L/DVB: Fix regression for BeholdTV Columbus (2010-08-24 10:39:32 -0300) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git cx-fixes-36 Andy Walls (1): cx25840: Fix typo in volume control initialization: 65335 vs. 65535 Dan Rosenberg (1): ivtvfb: prevent reading uninitialized stack memory drivers/media/video/cx25840/cx25840-core.c |2 +- drivers/media/video/ivtv/ivtvfb.c |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) Regards, 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/PATCH v4 07/11] media: Entities, pads and links enumeration
Hi Sakari,
On Thursday 16 September 2010 17:36:29 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Monday 06 September 2010 18:51:59 Hans Verkuil wrote:
> >> On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote:
> >>> On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote:
> On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
> ...
>
> > +};
>
> Should this be a packed struct?
> >>>
> >>> Why ? :-) Packed struct are most useful when they need to match
> >>> hardware structures or network protocols. Packing a structure can
> >>> generate unaligned fields, which are bad performance-wise.
> >>
> >> I'm thinking about preventing a compat32 mess as we have for v4l.
> >>
> >> It is my understanding that the only way to prevent different struct
> >> sizes between 32 and 64 bit is to use packed.
> >
> > I don't think that's correct. Different struct sizes between 32bit and
> > 64bit are caused by variable-size fields, such as 'long' (32bit on 32bit
> > architectures, 64bit on 64bit architectures). I might be wrong though.
>
> As far as I understand that's another reason for the structures not
> being exactly the same. Alignment of different data types in structures
> depends on ABI. I don't know the exact rules for all the architectures
> Linux supports if there are cases where the alignment would be different
> for 32-bit and 64-bit and smaller than the data type. On ARM there have
> been different alignments depending on ABI (EABI vs. GNU ABI) which is
> now practically history though.
>
> I couldn't find a better reference than this:
>
> http://developers.sun.com/solaris/articles/about_amd64_abi.html>
>
> 64-bit integers are aligned differently on 32-bit and 64-bit x86 but the
> alignment is still smaller or equal to the size of the data type.
Thanks for the link.
> I'd also pack them to be sure. The structures should be constructed so
> that the alignment is sane even if they are packed. In that case there's
> no harm done by packing. It just prevents a failure (32-bit vs. 64-bit)
> if there's a problem with the definition.
Even if the structures were packed we would have a problem with
media_user_links. The pads and links pointers will be 4-bytes long on 32-bit
and 8-bytes long on 64-bit. There's no way around that. I could pad the
structure to a fixed size with
struct media_links_enum {
__u32 entity;
/* Should have enough room for pads elements */
struct media_pad_desc __user *pads;
__u8 __pad1[8 - sizeof(void *)];
/* Should have enough room for links elements */
struct media_link_desc __user *links;
__u8 __pad2[8 - sizeof(void *)];
__u32 reserved[4];
};
or with
struct media_links_enum {
__u32 entity;
union {
struct {
/* Should have enough room for pads elements */
struct media_pad_desc __user *pads;
/* Should have enough room for links elements */
struct media_link_desc __user *links;
};
__u32 __pad[4];
};
__u32 reserved[4];
};
Is there any other way ?
--
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
RFC: Move ivtv utilities and ivtv X video extension to v4l-utils
Hi Hans and Hans, I'd like to move the source code maintained here: http://ivtvdriver.org/svn/ to someplace where it may be less likely to suffer bit rot. I was hoping the v4l-utils git repo would be an appropriate place. Do either of you have any opinions on this? If you think it would be acceptable, do you have a preference on where they would be placed in the v4l-utils directory structure? Thanks. Regards, 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: HVR 1600 Distortion
On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote: > I've recently noticed some distortion coming from my hvr1600 when > viewing analog channels. It happens to all analog channels with some > slightly better than others. I am running Fedora 12 linux with kernel > version 2.6.32.21-166. > I know I need to include more information but I'm not sure what to > include. Any help would be appreciated. 1. Would you say the distortion is something you would possibly encounter on an analog television set, or does it look "uniquely digital"? On systems with a long uptime and lots of usage, MPEG encoder firmware could wind up in a screwed up state giving weird output image. Simple solution in this case is to reboot. 2. Have you ensured your cable plant isn't affecting signal integrity? http://ivtvdriver.org/index.php/Howto:Improve_signal_quality 3. Does this happen with only the RF tuner or only CVBS or only SVideo or more than one of them? If the problem is only with RF, then it could be an incoming signal distortion problem. Do you have cable or an over the air antenna for analog RF? 4. What does v4l2-ctl --log-status show as your analog tuner? 5. Do you have a kernel with the new concurrency managed workqueues? On these kernels 'ps axf' will *not* show kernel threads with names like [cx18-0-in], [cx18-0-out/0], [cx18-0-out/1]. This is a major kernel change which could cause some MPEG buffers to be lost or reordered, if the new workqueue implementation has bugs. 6. Have you recently installed new hardware in the subject computer? Of most interest are adapter cards with cables coming off of them and cards very close to the HVR-1600. EMI can be picked up by the HVR-1600's board traces that are not shielded. 7. Does the distortion look like loss of horizontal line sync and happen only near very bright parts of the image on the left edge? If it does, the baseband video signal level is too high. 8. Care to post a short image in a paste bin or email a small MPEG to me? Regards, 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: [PATCH] uvc: Enable USB autosuspend by default on uvcvideo
Hi Matthew, Thanks for the patch. On Thursday 16 September 2010 20:00:04 Matthew Garrett wrote: > We've been doing this for a while in Fedora without any complaints. I'll trust you on that. If users start complaining I'll tell them who to blame ;-) > Signed-off-by: Matthew Garrett Acked-by: Laurent Pinchart (although, if you need to resubmit the patch for any reason, I'd rather like the usb_enable_autosuspend call to be before the uvc_trace call). > --- > drivers/media/video/uvc/uvc_driver.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/uvc/uvc_driver.c > b/drivers/media/video/uvc/uvc_driver.c index 8bdd940..28ed5b4 100644 > --- a/drivers/media/video/uvc/uvc_driver.c > +++ b/drivers/media/video/uvc/uvc_driver.c > @@ -1814,6 +1814,7 @@ static int uvc_probe(struct usb_interface *intf, > } > > uvc_trace(UVC_TRACE_PROBE, "UVC device initialized.\n"); > + usb_enable_autosuspend(udev); > return 0; > > error: -- 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: Hello and question about firmwares
Hello Mauro, Thanks for your help. Found your patch: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/22814 You're right, a more careful research returned -- - Product: PixelView PlayTV USB Hybrid - Part Number: PV-B308U(FRTN)-F - TDA18271 (NXP Hybrid Tuner), 86A20S (Fujitsu ISDB-T demodulator), CX23102 (CNXT AV Decoder - 10bit), USB Bridge -- - Product: PixelView PlayTV USB SBTVD Full-Seg - Part Number: PV-D231U(RN)-F - Chipset: DIB8076 -- Even if they share the same ID(from lsusb), chipsets are different. This is really troublesome :( But, the driver for CX23102 does exist in kernel.So, I was thinkingIs there a way to force kernel to recognize the device PixelView PlayTV USB Hybrid as anyother who uses the same chipset, like Conexant Hybrid TV - RDE250? http://lxr.free-electrons.com/source/drivers/media/video/cx231xx/cx231xx-cards.c http://www.datasheetarchive.com/Indexer/Datasheet-064/DSA00206835.html Shouldn't it work? At least as a regular tv(analog)this way the money I spent wouldn't be for nothing. I don't know if this helps but I found this too(for fujitsu chipset, his full name seems to be MB86A20S): http://www.fujitsu.com/downloads/MICRO/fme/documentation/M17_MB86A20S_OFDM_Demodulator.pdf Do you think it's possible? Thank you again for your help and patch :) Rafael Vieira 2010/9/16 Mauro Carvalho Chehab : > Hi Rafael, > > Em 16-09-2010 13:56, ✎Ʀafael Vieira♦ escreveu: >> I realize now that I was kind of fast foward :) So nice to meet you all. >> I hope someday, I'm able to help you guys. >> Let me give you some more data from the device, although is not >> directly related to my questions. >> >> The two devices: >> >> http://www.pixelview.com.br/play_tv_usb_sbtvd_fullseg.asp (works already) >> >> http://www.pixelview.com.br/playtv_usb_hybrid.asp (I'm trying to get it to >> work) > > They are completely independent devices. One uses dib0700, while the other > uses cx23102, > plus a Fujitsu frontend. The second one is not supported. I wrote a patch to > fix the > auto-detection issues between them a few days ago on my -git tree. > Eventually, analog > support for s-video/composite will work, but analog or digital TV won't work. > I need > to get one of those in order to fix the analog TV. For digital, it is more > complicated, > as we don't have any info about the Fujitsu chip yet. > > Abraços, > Mauro. > -- Rafael Siqueira Telles Vieira -- "Effective leadership is not about making speeches or being liked; leadership is defined by results not attributes" - Peter F. Drucker -- 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
DVICO Dual Express Has Been Superseded
Hi All I saw this post and made some enquiries: http://www.spinics.net/lists/linux-media/msg23091.html I have confirmation that the card is no longer available and has been replaced with Dvico FusionHDTV DVB-T Dual Express2. Has anyone previously heard of it / done any development on it or have any thoughts on how to get it working? Regards Drappa -- 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: Remaining BKL users, what to do
Hi, On 16 Sep 2010, at 16:04, Jan Kara wrote: > On Thu 16-09-10 16:32:59, Arnd Bergmann wrote: >> The big kernel lock is gone from almost all code in linux-next, this is >> the status of what I think will happen to the remaining users: > ... >> fs/ncpfs: >> Should be fixable if Petr still cares about it. Otherwise suggest >> moving to drivers/staging if there are no users left. > I think some people still use this... Yes, indeed. Netware is still alive (unfortunately!) and ncpfs is used in a lot of Universities here in the UK at least (we use it about a thousand workstations and servers here at Cambridge University!). Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- 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: Hello and question about firmwares
Hi Rafael, Em 16-09-2010 13:56, ✎Ʀafael Vieira♦ escreveu: > I realize now that I was kind of fast foward :) So nice to meet you all. > I hope someday, I'm able to help you guys. > Let me give you some more data from the device, although is not > directly related to my questions. > > The two devices: > > http://www.pixelview.com.br/play_tv_usb_sbtvd_fullseg.asp (works already) > > http://www.pixelview.com.br/playtv_usb_hybrid.asp (I'm trying to get it to > work) They are completely independent devices. One uses dib0700, while the other uses cx23102, plus a Fujitsu frontend. The second one is not supported. I wrote a patch to fix the auto-detection issues between them a few days ago on my -git tree. Eventually, analog support for s-video/composite will work, but analog or digital TV won't work. I need to get one of those in order to fix the analog TV. For digital, it is more complicated, as we don't have any info about the Fujitsu chip yet. Abraços, 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: [linux-media] How to handle independent CA devices
On 09.09.2010 23:52, rjkm wrote: > Hi, > > cards like the Digital Devices DuoFlex S2, cineS2 and upcoming > hardware (octuple, network, etc.) have independent CA devices. > This means that instead of having the stream routed from the frontend > through the CI and only then into memory a stream can be sent from > memory through the CI and back. So, the current device model does not > fit this hardware. > > One could hide this fact inside the driver and send the stream from > the frontend through the CI transparently to the API but this would > prevent people from implementing new features like decoding a stream from > a different DVB card, decoding streams from hard disk or even decoding > several sub-streams from different transponders. > The latter works with the current Windows driver but I have not > implemented it in Linux yet. It also has to be supported by the CI > modules. Some can decode 12 streams (6 times video/audio) at once. > > But decoding single streams already works fine. Currently, I am > registering a different adapter for the CI. > On a CineS2 with CI attached at the IO port I then have > > /dev/dvb/adapter[01] for the two DVB-S2 frontends and > /dev/dvb/adapter2 just for the ca0 device. > > I am abusing the unused sec0 to write/read data to/from the CI module. > For testing I hacked zap from dvb-apps to tune on adapter0 but > use adapter2/ca0 to talk to the CI module. > I then write the encrypted stream from adapter0/dvr0 into > adapter2/sec0 and read the decoded stream back from adapter2/sec0. > The encrypted stream of course has to contain all the PIDs of the > ca_pmt. > > So, I would like to hear your opinions about how to handle such CA devices > regarding device names/types, the DVB API and user libraries. Here's my 2ct as viewed from VDR: VDR already has mechanisms that allow independent handling of CAMs and receiving devices. Out of the box this currently only works for DVB devices that actually have a frontend and where the 'ca' device is under the same 'adapter' as the frontend. I could easily make it skip adapters that have no actual 'frontend' and set up separate cDvbCiAdapter objects for adapters that only have a 'ca' device and no frontend. However, VDR always assumes that the data to be recorded comes out of the 'dvr' device that's under the same adapter as the 'frontend'. So requiring that VDR would read from the frontend's 'dvr' device, write to the ca-adapter's 'sec' (or whatever) device, and finally read from that same 'sec' device again would be something I'd rather avoid. Besides, what if some PIDs are encrypted, while others are not? Should the unencrypted ones be read directly from 'dvr' and only the encrypted ones from 'sec'? That might mess with the proper sequence of the packets. As for decrypting data from several frontends through one CAM: I don't see this happening in VDR. Pay tv channels repeat their stuff often enough to find a slot where everything can be recorded. Others may, of course, welcome this ability, but I'd like to keep things simple in VDR. So I'm not against this, I just won't use it in VDR. As for recording encrypted and decrypting later: that's also something I don't see being used in VDR (again, mainly for KISS reasons). So, the bottom line is: I would appreciate an implementation where, given the configuration you described above, I could, e.g., tune using /dev/dvb/adapter0/frontend0, read the data stream from /dev/dvb/adapter0/dvr0 as usual, communicate with the CAM through /dev/dvb/adapter2/ca0 and (which is the tricky part, I guess) "tell" the driver or some library function to "assign the CAM in /dev/dvb/adapter2/ca0 to the frontend|dvr in /dev/dvb/adapter0/frontend0|dvr0). Please forgive me if this sounds like a crazy request - I'm not a driver developer ;-) Klaus -- 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: Remaining BKL users, what to do
From: Alan Cox Date: Thu, 16 Sep 2010 16:07:59 +0100 >> net/appletalk: >> net/ipx/af_ipx.c: >> net/irda/af_irda.c: >> Can probably be saved from retirement in drivers/staging if the >> maintainers still care. > > IPX and Appletalk both have active users. They also look fairly fixable > as the lock_kernel just maps to a stack private mutex, or in several > cases can simply be dropped - its just a push down legacy. I'll take a stab at IPX and Appletalk. -- 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: Remaining BKL users, what to do
From: Samuel Ortiz Date: Thu, 16 Sep 2010 18:57:56 +0200 > On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: >> net/appletalk: >> net/ipx/af_ipx.c: >> net/irda/af_irda.c: >> Can probably be saved from retirement in drivers/staging if the >> maintainers still care. > I'll take care of the IrDA part. Thanks a lot Sam. -- 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] uvc: Enable USB autosuspend by default on uvcvideo
On Thu, Sep 16, 2010 at 07:53:18PM +0100, Matthew Garrett wrote: > On Thu, Sep 16, 2010 at 11:45:30AM -0700, Greg KH wrote: > > On Thu, Sep 16, 2010 at 02:00:04PM -0400, Matthew Garrett wrote: > > > We've been doing this for a while in Fedora without any complaints. > > > > No complaints probably, but does it actually do anything? Last time I > > measured, it didn't, but that was in the .31 kernel days. > > It's necessary if you want to be able to do runtime PCI power management > on the HCD. Ok, fair enough, no objection from me. thanks, greg k-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
[cron job] v4l-dvb daily build 2.6.26 and up: 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:Thu Sep 16 19:00:07 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15160:60edc4bd92b7 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: 991403c594f666a2ed46297c592c60c3b9f4e1e2 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec 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] uvc: Enable USB autosuspend by default on uvcvideo
On Thu, Sep 16, 2010 at 11:45:30AM -0700, Greg KH wrote: > On Thu, Sep 16, 2010 at 02:00:04PM -0400, Matthew Garrett wrote: > > We've been doing this for a while in Fedora without any complaints. > > No complaints probably, but does it actually do anything? Last time I > measured, it didn't, but that was in the .31 kernel days. It's necessary if you want to be able to do runtime PCI power management on the HCD. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Remaining BKL users, what to do
On 2010-09-16 16:49, Steven Rostedt wrote: > On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: >> The big kernel lock is gone from almost all code in linux-next, this is >> the status of what I think will happen to the remaining users: > >> kernel/trace/blktrace.c: >> Should be easy. Ingo? Steven? >> > > Jens, > > Git blame shows this to be your code (copied from block/blktrace.c from > years past). > > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9) It isn't, it can be removed. -- Jens Axboe Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. -- 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] uvc: Enable USB autosuspend by default on uvcvideo
On Thu, Sep 16, 2010 at 02:00:04PM -0400, Matthew Garrett wrote: > We've been doing this for a while in Fedora without any complaints. No complaints probably, but does it actually do anything? Last time I measured, it didn't, but that was in the .31 kernel days. thanks, greg k-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
[PATCH] uvc: Enable USB autosuspend by default on uvcvideo
We've been doing this for a while in Fedora without any complaints. Signed-off-by: Matthew Garrett --- drivers/media/video/uvc/uvc_driver.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c index 8bdd940..28ed5b4 100644 --- a/drivers/media/video/uvc/uvc_driver.c +++ b/drivers/media/video/uvc/uvc_driver.c @@ -1814,6 +1814,7 @@ static int uvc_probe(struct usb_interface *intf, } uvc_trace(UVC_TRACE_PROBE, "UVC device initialized.\n"); + usb_enable_autosuspend(udev); return 0; error: -- 1.7.2.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
Re: Trouble building v4l-dvb
Douglas; Could you please check your last putback ? the build is broken. see: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log and the mail [cron job] v4l-dvb daily build 2.6.26 and up: ERRORS Yours, Jan Ole W. Saastad wrote: Trouble building v4l-dvb Asus eee netbook, running EasyPeasy. o...@ole-eee:~$ cat /etc/issue Ubuntu 9.04 \n \l o...@ole-eee:~$ uname -a Linux ole-eee 2.6.30.5-ep0 #10 SMP PREEMPT Thu Aug 27 19:45:06 CEST 2009 i686 GNU/Linux Rationale for building from source: I have bought a USB TV with mpg4 support from Sandberg, Mini DVB-T dongle. I also received an archive with driver routines for this from Sandberg. These should be copied into the v4l-dvd three and just rebuild with make. I have installed the kernel headers: apt-get install mercurial linux-headers-$(uname -r) build-essential Then I have downloaded the v4l-dvb source (assuming this is a stable release): hg clone http://linuxtv.org/hg/v4l-dvb I wanted to try to build before applying the patch from Sandberg. Issuing make yield the following : LIRC: Requires at least kernel 2.6.36 IR_LIRC_CODEC: Requires at least kernel 2.6.36 IR_IMON: Requires at least kernel 2.6.36 IR_MCEUSB: Requires at least kernel 2.6.36 VIDEOBUF_DMA_CONTIG: Requires at least kernel 2.6.31 V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33 and a few more lines Ignoring these and just continuing : CC [M] /home/ole/work/v4l-dvb/v4l/firedtv-dvb.o CC [M] /home/ole/work/v4l-dvb/v4l/firedtv-fe.o CC [M] /home/ole/work/v4l-dvb/v4l/firedtv-1394.o /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:22:17: error: dma.h: No such file or directory /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:23:21: error: csr1212.h: No such file or directory /home/ole/work/v4l-dvb/v4l/firedtv-1394.c:24:23: error: highlevel.h: No such file or directory and many many more similar errors. After some time the make bails out. I assume this have some connection with the 9.04 being too old. Hints ? Regards, Ole W. Saastad -- 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 -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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: Remaining BKL users, what to do
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: > net/appletalk: > net/ipx/af_ipx.c: > net/irda/af_irda.c: > Can probably be saved from retirement in drivers/staging if the > maintainers still care. I'll take care of the IrDA part. Cheers, Samuel. -- 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: Hello and question about firmwares
I realize now that I was kind of fast foward :) So nice to meet you all. I hope someday, I'm able to help you guys. Let me give you some more data from the device, although is not directly related to my questions. The two devices: http://www.pixelview.com.br/play_tv_usb_sbtvd_fullseg.asp (works already) http://www.pixelview.com.br/playtv_usb_hybrid.asp (I'm trying to get it to work) The two boards even seems to be the same(lsusb output is the same from the two): (from #lsusb) Bus 001 Device 005: ID 1554:5010 Prolink Microsystems Corp. (from dmesg) [10994.296447] dvb-usb: found a 'Prolink Pixelview SBTVD' in cold state, will try to load a firmware [10994.296461] usb 1-3: firmware: requesting dvb-usb-dib0700-1.20.fw [10994.354616] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [10994.354639] dib0700: firmware download failed at 7 with -22 So, the problem to me seems to be only the firmware. I've upload the file (merlinD.rom) to here. http://www.2shared.com/file/URb2IeUi/merlinD.html If anyone care to take a look. Best wishes and many thanks for any help, Rafael Vieira - programmer and student. -- 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
Hello and question about firmwares
Hy there, My name is Rafael Vieira. Sorry, if I say something stupid, but let me share with you my point of view, and you can correct me at anytime. I have a USB PixelView SBTVD Hybrid device and it seems to me that the only thing that keeps it from working is its firmware. Since there is a younger brother from this board http://dougsland.livejournal.com/103169.html that works already. I found a rom(merlinD.rom that I can send it to the list, if you want), from the CD of the device, that I suspect is its firmware. Yes, I've heard of usbsnoop, but my question is, if I have the firmware(If I'm right), can't I just rename it? Or do some operation directly on the firmware? Do I really need to use usbsnoop? (I didn't wan't to install windows to do this, honestly) Thanks, Rafael Vieira - programmer and student. -- 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: Remaining BKL users, what to do
On 2010-09-16 16:32:59, Arnd Bergmann wrote: > The big kernel lock is gone from almost all code in linux-next, this is > the status of what I think will happen to the remaining users: > fs/qnx4: > Should be easy to fix, there are only a few places in the code that > use the BKL. Anders? Will do. Cheers Anders -- 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 v4 07/11] media: Entities, pads and links enumeration
Hi Laurent and Hans, Laurent Pinchart wrote: > Hi Hans, > > On Monday 06 September 2010 18:51:59 Hans Verkuil wrote: >> On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote: >>> On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote: On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote: ... > +}; Should this be a packed struct? >>> >>> Why ? :-) Packed struct are most useful when they need to match hardware >>> structures or network protocols. Packing a structure can generate >>> unaligned fields, which are bad performance-wise. >> >> I'm thinking about preventing a compat32 mess as we have for v4l. >> >> It is my understanding that the only way to prevent different struct sizes >> between 32 and 64 bit is to use packed. > > I don't think that's correct. Different struct sizes between 32bit and 64bit > are caused by variable-size fields, such as 'long' (32bit on 32bit > architectures, 64bit on 64bit architectures). I might be wrong though. As far as I understand that's another reason for the structures not being exactly the same. Alignment of different data types in structures depends on ABI. I don't know the exact rules for all the architectures Linux supports if there are cases where the alignment would be different for 32-bit and 64-bit and smaller than the data type. On ARM there have been different alignments depending on ABI (EABI vs. GNU ABI) which is now practically history though. I couldn't find a better reference than this: http://developers.sun.com/solaris/articles/about_amd64_abi.html> 64-bit integers are aligned differently on 32-bit and 64-bit x86 but the alignment is still smaller or equal to the size of the data type. I'd also pack them to be sure. The structures should be constructed so that the alignment is sane even if they are packed. In that case there's no harm done by packing. It just prevents a failure (32-bit vs. 64-bit) if there's a problem with the definition. Just my 2 cents worth. :) Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining BKL users, what to do
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote: > The big kernel lock is gone from almost all code in linux-next, this is > the status of what I think will happen to the remaining users: ... > fs/ncpfs: > Should be fixable if Petr still cares about it. Otherwise suggest > moving to drivers/staging if there are no users left. I think some people still use this... > fs/udf: > Not completely trivial, but probably necessary to fix. Project web > site is dead, I hope that Jan Kara can be motivated to fix it though. Yeah, I can have a look at it. Honza -- Jan Kara SUSE Labs, CR -- 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: Hauppauge WinTV-HVR1800 dual tuner help needed
On Thu, Sep 16, 2010 at 10:23 AM, Jack Snodgrass wrote: > I can use 1 input on the card with mythtv > using /dev/dvb/adapter0/frontend0 > but I can't figure out how to use the 2nd tuner I'm not sure if the > 2nd tuner is getting > detected correctly... or if the 2nd tuner is just an analog tuner and > not a digital tuner > or what exactly... The HVR-1800 doesn't have two digital tuners. It has an analog tuner and a digital tuner. If you need dual ClearQAM, you need a card like the HVR-2250. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: Remaining BKL users, what to do
> net/appletalk: > net/ipx/af_ipx.c: > net/irda/af_irda.c: > Can probably be saved from retirement in drivers/staging if the > maintainers still care. IPX and Appletalk both have active users. They also look fairly fixable as the lock_kernel just maps to a stack private mutex, or in several cases can simply be dropped - its just a push down legacy. IRDA may well be a candidate for staging -- 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: Remaining BKL users, what to do
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: > The big kernel lock is gone from almost all code in linux-next, this is > the status of what I think will happen to the remaining users: > kernel/trace/blktrace.c: > Should be easy. Ingo? Steven? > Jens, Git blame shows this to be your code (copied from block/blktrace.c from years past). Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9) -- Steve -- 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
Remaining BKL users, what to do
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if nobody cares.
drivers/media/video (V4L):
Mauro is working on it, some drivers get moved to staging while the
others get fixed. An easy workaround would be possible by adding
per-driver mutexes, but Mauro wants to it properly by locking all
the right places.
fs/adfs:
Probably not hard to fix, but needs someone to test it.
adfs has only seen janitorial fixes for the last 5 years.
Do we know of any users?
fs/autofs:
Pretty much dead, replaced by autofs4. I'd suggest moving this
to drivers/staging in 2.6.37 and letting it die there.
fs/coda:
Coda seems to have an active community, but not all of their
code is actually part of linux (pioctl!), while the last official
release is missing many of the cleanups that were don in Linux.
Not sure what to do, if someone is interested, the best way might
be a fresh start with a merger of the mainline linux and the
coda.cs.cmu.edu codebase in drivers/staging.
Just removing the BKL without the Coda community seems like a heap
of pointless work.
fs/freevxfs:
Uses the BKL in readdir and lookup, should be easy to fix. Christoph?
fs/hpfs:
Looks fixable, if anyone cares. Maybe it's time for retirement in
drivers/staging though. The web page only has a Link to the
linux-2.2 version.
fs/lockd:
Trond writes that he has someone working on BKL removal here.
fs/locks.c:
Patch is under discussion, blocked by work on fs/lockd currently.
fs/ncpfs:
Should be fixable if Petr still cares about it. Otherwise suggest
moving to drivers/staging if there are no users left.
fs/qnx4:
Should be easy to fix, there are only a few places in the code that
use the BKL. Anders?
fs/smbfs:
Last I heard this was considered obsolete. Should be move it to
drivers/staging now?
fs/udf:
Not completely trivial, but probably necessary to fix. Project web
site is dead, I hope that Jan Kara can be motivated to fix it though.
fs/ufs:
Evgeniy Dushistov is maintaining this, I hope he can take care of
getting rid of the BKL in UFS.
kernel/trace/blktrace.c:
Should be easy. Ingo? Steven?
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
net/x25:
Andrew Hendry has started working on it.
This is all that's left now. I still need to submit a few patches for
simple file system changes, but it seems we're getting closer to finally
killing it for good.
Arnd
--
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
Hauppauge WinTV-HVR1800 dual tuner help needed
I bought a Hauppauge WinTV-HVR-1800 HDTV Tuner Capture Card PCI-e off of ebay for $30 and need some help getting the 2nd tuner activated ( if it's even possible ) The card pictured in the auction looks exactly like the one I received, but it doesn't look anything like the one listed on: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1800 The card I have has 2 antenna connectors ( no other connectors at all )... a very basic looking card. I want to get both tuners tuning dvb ( digital ) qcam signals off of my FIOS TV Cable cable. I have have gotten the qcam stuff working on a DViCO FusionHDTV 5 Lite and a Hauppauge WinTV-HVR1200 pcie board so I know that that part is ok. I can get a single tuner working on the WinTV-HVR-1800 card... dmesg, lscpi, etc for the card are below... ( I'm only trying to get the major networks ( abc, cbs, fox, etc ) that are not encrypted... ) I'm running fedora 13, but I have compiled / installed the latest ( as of a few days ago ) v4l-dvv drivers from the v4l-dvb site dmesg reports: Linux video capture interface: v2.00 cx23885 driver version 0.0.2 loaded cx23885 :08:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 CORE cx23885[0]: subsystem: 0070:7809, board: Hauppauge WinTV-HVR1800 [card=2,autodetected] tveeprom 1-0050: Hauppauge model 78631, rev C1E9, serial# 2876620 tveeprom 1-0050: MAC address is 00:0d:fe:2b:e4:cc tveeprom 1-0050: tuner model is Philips 18271_8295 (idx 149, type 54) tveeprom 1-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) tveeprom 1-0050: audio processor is CX23887 (idx 42) tveeprom 1-0050: decoder processor is CX23887 (idx 37) tveeprom 1-0050: has no radio cx23885[0]: hauppauge eeprom: model=78631 cx25840 3-0044: cx23887 A/V decoder found @ 0x88 (cx23885[0]) cx25840 3-0044: firmware: requesting v4l-cx23885-avcore-01.fw cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) tuner 2-0042: chip found @ 0x84 (cx23885[0]) tda829x 2-0042: could not clearly identify tuner address, defaulting to 60 tda18271 2-0060: creating new instance TDA18271HD/C1 detected @ 2-0060 tda829x 2-0042: type set to tda8295+18271 cx23885[0]/0: registered device video0 [v4l2] cx23885[0]: registered device video1 [mpeg] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card MT2131: successfully identified at address 0x61 DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... cx23885_dev_checkrevision() Hardware revision = 0xb1 cx23885[0]/0: found at :08:00.0, rev: 15, irq: 19, latency: 0, mmio: 0xf2e0 cx23885 :08:00.0: setting latency timer to 64 IRQ 19/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs lspci reports: 08:00.0 Multimedia video controller: Conexant Systems, Inc. Hauppauge Inc. HDPVR-1250 model 1196 (rev 0f) find on /dev/dvb reports: /dev/dvb /dev/dvb/adapter0 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend0 I also have /dev/video0 and /dev/video1 devices listed lsmod | egrep "tuner|cx23885|dvb|vl4" cx23885 102191 0 tuner 15518 1 cx2341x 9306 1 cx23885 v4l2_common13545 4 cx23885,tuner,cx25840,cx2341x videodev 34211 4 cx23885,tuner,cx25840,v4l2_common videobuf_dma_sg 7217 1 cx23885 videobuf_dvb4174 1 cx23885 dvb_core 71187 2 cx23885,videobuf_dvb videobuf_core 13426 3 cx23885,videobuf_dma_sg,videobuf_dvb ir_common 4056 1 cx23885 ir_core11377 8 cx23885,rc_hauppauge_new,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,ir_common btcx_risc 2978 1 cx23885 tveeprom9994 1 cx23885 i2c_core 19651 13 cx23885,s5h1411,mt2131,s5h1409,tda18271,tda8290,tuner,cx25840,nvidia,v4l2_common,videodev,i2c_i801,tveeprom I can use 1 input on the card with mythtv using /dev/dvb/adapter0/frontend0 but I can't figure out how to use the 2nd tuner I'm not sure if the 2nd tuner is getting detected correctly... or if the 2nd tuner is just an analog tuner and not a digital tuner or what exactly... There is something in mythtv that says how many things an input can tune at once, but setting it to 2 does not let me record two things using this WinTV-HVR-1800 card. mythtv treats it as one tuner... I think that I need to see /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/frontend1 to get to the 2nd tuner... Is there a modprobe cx23885 option that enables a 2nd tuner? Is one of the dmesg messages telling me that the 2nd tuner is analog only? The can on the card doesn't look like any of the cans on my other analog cards that I've had in the past Thanks - jack -- 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.
Re: [PATCH 2/4] imon: split mouse events to a separate input dev
On Thu, Sep 16, 2010 at 03:43:42PM +0200, David Härdeman wrote: > On Thu, September 16, 2010 15:34, Jarod Wilson wrote: > > On Thu, Sep 16, 2010 at 01:32:07PM +0200, David Härdeman wrote: > >> On Thu, September 16, 2010 07:22, Jarod Wilson wrote: > >> > This is a stab at separating the mouse (and front panel/knob) events > >> > out to a separate input device. This is necessary in preparation for > >> > the next patch which makes the rc-core input dev opaque to rc > >> > drivers. > >> > > >> > I can't verify the correctness of the patch beyond the fact that it > >> > compiles without warnings. The driver has resisted most of my > >> > attempts at understanding it properly...for example, the double calls > >> > to le64_to_cpu() and be64_to_cpu() which are applied in > >> > imon_incoming_packet() and imon_panel_key_lookup() would amount > >> > to a bswab64() call, irregardless of the cpu endianness, and I think > >> > the code wouldn't have worked on a big-endian machine... > >> > > >> > Signed-off-by: David Härdeman > >> > > >> > - Minor alterations to apply with minimal core IR changes > >> > - Use timer for imon keys too, since its entirely possible for the > >> > receiver to miss release codes (either by way of another key being > >> > pressed while the first is held or by the remote pointing away from > >> > the recevier when the key is release. yes, I know, its ugly). > >> > >> Where's the additional timer usage exactly? I can't see any in the > >> patch... > > > > For ktype == IMON_KEY_IMON in your original patch, keys were submitted > > with ir_keydown_notimeout, and in this version, they're submitted with > > plain old ir_keydown, which has a built-in timeout. > > Oh, I see. But since you're not adding any timer to the driver code itself > I do not consider the use of plain ir_keydown to be ugly at all (contrary > to what your comment indicated). Oh, sorry, that rant was about the receiver hardware, not the actual code -- yes, the code gets much much cleaner here. :) > Maybe a keyup hardware event is generated (handled via ir_keyup, good), > maybe it isnt't (handled via ir-core timeout which calls ir_keyup > eventually, good). Yeah, its behaving much better for the specific cases Anssi mentioned in the bug now. We also get the automatic release of a key that wasn't released before pressing a second key, by way of the ir_keyup call in ir_keydown. -- Jarod Wilson ja...@redhat.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 2/4] imon: split mouse events to a separate input dev
On Thu, September 16, 2010 15:34, Jarod Wilson wrote: > On Thu, Sep 16, 2010 at 01:32:07PM +0200, David Härdeman wrote: >> On Thu, September 16, 2010 07:22, Jarod Wilson wrote: >> > This is a stab at separating the mouse (and front panel/knob) events >> > out to a separate input device. This is necessary in preparation for >> > the next patch which makes the rc-core input dev opaque to rc >> > drivers. >> > >> > I can't verify the correctness of the patch beyond the fact that it >> > compiles without warnings. The driver has resisted most of my >> > attempts at understanding it properly...for example, the double calls >> > to le64_to_cpu() and be64_to_cpu() which are applied in >> > imon_incoming_packet() and imon_panel_key_lookup() would amount >> > to a bswab64() call, irregardless of the cpu endianness, and I think >> > the code wouldn't have worked on a big-endian machine... >> > >> > Signed-off-by: David Härdeman >> > >> > - Minor alterations to apply with minimal core IR changes >> > - Use timer for imon keys too, since its entirely possible for the >> > receiver to miss release codes (either by way of another key being >> > pressed while the first is held or by the remote pointing away from >> > the recevier when the key is release. yes, I know, its ugly). >> >> Where's the additional timer usage exactly? I can't see any in the >> patch... > > For ktype == IMON_KEY_IMON in your original patch, keys were submitted > with ir_keydown_notimeout, and in this version, they're submitted with > plain old ir_keydown, which has a built-in timeout. Oh, I see. But since you're not adding any timer to the driver code itself I do not consider the use of plain ir_keydown to be ugly at all (contrary to what your comment indicated). Maybe a keyup hardware event is generated (handled via ir_keyup, good), maybe it isnt't (handled via ir-core timeout which calls ir_keyup eventually, good). -- David Härdeman -- 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 2/4] imon: split mouse events to a separate input dev
On Thu, Sep 16, 2010 at 01:32:07PM +0200, David Härdeman wrote: > On Thu, September 16, 2010 07:22, Jarod Wilson wrote: > > This is a stab at separating the mouse (and front panel/knob) events > > out to a separate input device. This is necessary in preparation for > > the next patch which makes the rc-core input dev opaque to rc > > drivers. > > > > I can't verify the correctness of the patch beyond the fact that it > > compiles without warnings. The driver has resisted most of my > > attempts at understanding it properly...for example, the double calls > > to le64_to_cpu() and be64_to_cpu() which are applied in > > imon_incoming_packet() and imon_panel_key_lookup() would amount > > to a bswab64() call, irregardless of the cpu endianness, and I think > > the code wouldn't have worked on a big-endian machine... > > > > Signed-off-by: David Härdeman > > > > - Minor alterations to apply with minimal core IR changes > > - Use timer for imon keys too, since its entirely possible for the > > receiver to miss release codes (either by way of another key being > > pressed while the first is held or by the remote pointing away from > > the recevier when the key is release. yes, I know, its ugly). > > Where's the additional timer usage exactly? I can't see any in the patch... For ktype == IMON_KEY_IMON in your original patch, keys were submitted with ir_keydown_notimeout, and in this version, they're submitted with plain old ir_keydown, which has a built-in timeout. -- Jarod Wilson ja...@redhat.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: [GIT PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h
Hi Hans,
On Wed, 15 Sep 2010 22:00:26 +0200, Hans Verkuil wrote:
> Mauro, Jean, Janne,
>
> This patch series finally retires the hackish v4l2-i2c-drv.h. It served
> honorably,
> but now that the hg repository no longer supports kernels <2.6.26 it is time
> to
> remove it.
>
> Note that this patch series builds on the vtx-removal patch series.
>
> Several patches at the end remove unused i2c-id.h includes and remove bogus
> uses
> of the I2C_HW_ defines (as found in i2c-id.h).
>
> After applying this patch series I get the following if I grep for
> I2C_HW_ in the kernel sources:
>
>
> drivers/staging/lirc/lirc_i2c.c:if (adap->id ==
> I2C_HW_B_CX2388x)
> drivers/staging/lirc/lirc_i2c.c:if (adap->id ==
> I2C_HW_B_CX2388x) {
> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> drivers/staging/lirc/lirc_zilog.c: if (ir->c_rx.adapter->id ==
> I2C_HW_B_HDPVR) {
> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> drivers/staging/lirc/lirc_zilog.c: if (ir->c_rx.adapter->id ==
> I2C_HW_B_HDPVR)
> drivers/video/riva/rivafb-i2c.c:chan->adapter.id=
> I2C_HW_B_RIVA;
> drivers/media/video/ir-kbd-i2c.c: if (ir->c->adapter->id ==
> I2C_HW_SAA7134 && ir->c->addr == 0x30)
> drivers/media/video/ir-kbd-i2c.c: if (adap->id ==
> I2C_HW_B_CX2388x) {
> drivers/media/video/saa7134/saa7134-i2c.c: .id=
> I2C_HW_SAA7134,
> drivers/media/video/cx88/cx88-i2c.c:core->i2c_adap.id = I2C_HW_B_CX2388x;
> drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c->adap.id =
> I2C_HW_B_CX2388x;
>
> Jean, I guess the one in rivafb-i2c.c can just be removed, right?
Correct. The last user for that one was the tvaudio driver and
apparently you just cleaned it up.
> Janne, the HDPVR checks in lirc no longer work since hdpvr never sets the
> adapter ID (nor should it). This lirc code should be checked. I haven't
> been following the IR changes, but there must be a better way of doing this.
>
> The same is true for the CX2388x and SAA7134 checks. These all relate to the
> IR subsystem.
>
> Once we fixed these remaining users of the i2c-id.h defines, then Jean can
> remove that header together with the adapter's 'id' field.
That would be very great. In all honesty I didn't expect it to happen
so fast, but if that happens, I'll be very happy! :) Thanks!
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] IR/imon: set up mce-only devices w/mce keytable
On Thu, Sep 16, 2010 at 10:11:16AM +0200, Anders Eriksson wrote: > > > > ja...@redhat.com said: > > > + /* iMON LCD, MCE IR */ > > + case 0x9e: > > + dev_info(ictx->dev, "0xffdc iMON VFD, MCE IR"); > > + detected_display_type = IMON_DISPLAY_TYPE_VFD; > > + allowed_protos = IR_TYPE_RC6; + break; > > + /* iMON LCD, MCE IR */ +case 0x9f: > > > > That "LCD" in the comment should be VFD. Ah, dammit, copy-paste fail. Will fix, thanks! -- Jarod Wilson ja...@redhat.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 2/4] imon: split mouse events to a separate input dev
On Thu, September 16, 2010 07:22, Jarod Wilson wrote: > This is a stab at separating the mouse (and front panel/knob) events > out to a separate input device. This is necessary in preparation for > the next patch which makes the rc-core input dev opaque to rc > drivers. > > I can't verify the correctness of the patch beyond the fact that it > compiles without warnings. The driver has resisted most of my > attempts at understanding it properly...for example, the double calls > to le64_to_cpu() and be64_to_cpu() which are applied in > imon_incoming_packet() and imon_panel_key_lookup() would amount > to a bswab64() call, irregardless of the cpu endianness, and I think > the code wouldn't have worked on a big-endian machine... > > Signed-off-by: David Härdeman > > - Minor alterations to apply with minimal core IR changes > - Use timer for imon keys too, since its entirely possible for the > receiver to miss release codes (either by way of another key being > pressed while the first is held or by the remote pointing away from > the recevier when the key is release. yes, I know, its ugly). Where's the additional timer usage exactly? I can't see any in the patch... -- David Härdeman -- 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
Dvico Dual Express 2
Hi, I've recently obtained a Dvico FusionHDTV DVB-T Dual Express2, and found it is not the same card as the Dual Express. There is a chance I've done something particularly silly, but I've tried specifying card types etc, and so far had no luck. I believe this is a new hardware revision and currently unsupported. I've made a quick note on the wiki, but I wasn't sure if I should create a new page separate from the existing info page in the Dual Express. From memory the card looks identical to the pictures at http://www.linuxtv.org/wiki/index.php/DViCO_FusionHDTV_DVB-T_Dual_Express. My dmesg looks like: [ 17.112114] cx23885 driver version 0.0.2 loaded [ 17.140399] cx23885 :02:00.0: PCI INT A -> Link[APC5] -> GSI 16 (level, low) -> IRQ 16 [ 17.140405] cx23885[0]: Your board isn't known (yet) to the driver. [ 17.140406] cx23885[0]: Try to pick one of the existing card configs via [ 17.140408] cx23885[0]: card= insmod option. Updating to the latest [ 17.140409] cx23885[0]: version might help as well. [ 17.140412] cx23885[0]: Here is a list of valid choices for the card= insmod option: [ 17.140414] cx23885[0]:card=0 -> UNKNOWN/GENERIC [ 17.140416] cx23885[0]:card=1 -> Hauppauge WinTV-HVR1800lp [ 17.140419] cx23885[0]:card=2 -> Hauppauge WinTV-HVR1800 [ 17.140421] cx23885[0]:card=3 -> Hauppauge WinTV-HVR1250 [ 17.140423] cx23885[0]:card=4 -> DViCO FusionHDTV5 Express [ 17.140426] cx23885[0]:card=5 -> Hauppauge WinTV-HVR1500Q [ 17.140428] cx23885[0]:card=6 -> Hauppauge WinTV-HVR1500 [ 17.140430] cx23885[0]:card=7 -> Hauppauge WinTV-HVR1200 [ 17.140432] cx23885[0]:card=8 -> Hauppauge WinTV-HVR1700 [ 17.140435] cx23885[0]:card=9 -> Hauppauge WinTV-HVR1400 [ 17.140437] cx23885[0]:card=10 -> DViCO FusionHDTV7 Dual Express [ 17.140439] cx23885[0]:card=11 -> DViCO FusionHDTV DVB-T Dual Express [ 17.140442] cx23885[0]:card=12 -> Leadtek Winfast PxDVR3200 H [ 17.140444] cx23885[0]:card=13 -> Compro VideoMate E650F [ 17.140446] cx23885[0]:card=14 -> TurboSight TBS 6920 [ 17.140448] cx23885[0]:card=15 -> TeVii S470 [ 17.140451] cx23885[0]:card=16 -> DVBWorld DVB-S2 2005 [ 17.140453] cx23885[0]:card=17 -> NetUP Dual DVB-S2 CI [ 17.140455] cx23885[0]:card=18 -> Hauppauge WinTV-HVR1270 [ 17.140457] cx23885[0]:card=19 -> Hauppauge WinTV-HVR1275 [ 17.140460] cx23885[0]:card=20 -> Hauppauge WinTV-HVR1255 [ 17.140462] cx23885[0]:card=21 -> Hauppauge WinTV-HVR1210 [ 17.140464] cx23885[0]:card=22 -> Mygica X8506 DMB-TH [ 17.140466] cx23885[0]:card=23 -> Magic-Pro ProHDTV Extreme 2 [ 17.140469] cx23885[0]:card=24 -> Hauppauge WinTV-HVR1850 [ 17.140471] cx23885[0]:card=25 -> Compro VideoMate E800 [ 17.140473] cx23885[0]:card=26 -> Hauppauge WinTV-HVR1290 [ 17.140476] cx23885[0]:card=27 -> Mygica X8558 PRO DMB-TH [ 17.140478] cx23885[0]:card=28 -> LEADTEK WinFast PxTV1200 [ 17.140553] CORE cx23885[0]: subsystem: 18ac:db98, board: UNKNOWN/GENERIC [card=0,autodetected] [ 17.355341] cx23885_dev_checkrevision() Hardware revision = 0xa5 [ 17.355348] cx23885[0]/0: found at :02:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xf900 [ 17.355354] cx23885 :02:00.0: setting latency timer to 64 [ 17.355359] IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 230.677212] cx23885 :02:00.0: PCI INT A disabled Loading the module with card=11 (looks like the most obvious choice) shows: [113131.257580] cx23885 driver version 0.0.2 loaded [113131.276294] cx23885 :02:00.0: PCI INT A -> Link[APC5] -> GSI 16 (level, low) -> IRQ 16 [113131.276517] CORE cx23885[0]: subsystem: 18ac:db98, board: DViCO FusionHDTV DVB-T Dual Express [card=11,insmod option] [113131.512250] cx23885_dvb_register() allocating 1 frontend(s) [113131.512257] cx23885[0]: cx23885 based dvb card [113131.569079] cx23885[0]: frontend initialization failed [113131.569086] cx23885_dvb_register() dvb_register failed err = -1 [113131.569089] cx23885_dev_setup() Failed to register dvb adapters on VID_B [113131.569091] cx23885_dvb_register() allocating 1 frontend(s) [113131.569096] cx23885[0]: cx23885 based dvb card [113131.569492] cx23885[0]: frontend initialization failed [113131.569494] cx23885_dvb_register() dvb_register failed err = -1 [113131.569497] cx23885_dev_setup() Failed to register dvb on VID_C [113131.569501] cx23885_dev_checkrevision() Hardware revision = 0xa5 [113131.569508] cx23885[0]/0: found at :02:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xf900 [113131.569516] cx23885 :02:00.0: setting latency timer to 64 [113131.569521] IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs I've tried a few different card types to see the results, but nothing much more promising than that. Is anyone familiar with this board? Any chance anyone has been tinkering with it? #lspci -vnn 02:00.0 Multimedia video controller [0400]: Conexant Sy
Re: [RFC/PATCH v4 05/11] media: Reference count and power handling
Hi Mauro, On Thursday 16 September 2010 12:35:45 Mauro Carvalho Chehab wrote: > Em 16-09-2010 05:46, Laurent Pinchart escreveu: > > On Saturday 11 September 2010 22:38:33 Sakari Ailus wrote: > >> Mauro Carvalho Chehab wrote: > >>> Em 20-08-2010 12:29, Laurent Pinchart escreveu: > From: Sakari Ailus > > Basically these are the interface functions: > > media_entity_get() - acquire entity > media_entity_put() - release entity > > If the entity is of node type, the power change is distributed to > all connected entities. For non-nodes it only affects that very > node. A mutex is used to serialise access to the entity graph. > > In the background there's a depth-first search algorithm that > traverses the active links in the graph. All these functions parse > the graph to implement whatever they're to do. > > The module counters are increased/decreased in media_entity_get/put to > prevent module unloading when an entity is referenced. > > Signed-off-by: Sakari Ailus > Signed-off-by: Laurent Pinchart > Signed-off-by: Stanimir Varbanov > --- > > Documentation/media-framework.txt | 37 + > drivers/media/media-device.c |1 + > drivers/media/media-entity.c | 146 > + include/media/media-device.h > > |4 + > > include/media/media-entity.h | 15 > 5 files changed, 203 insertions(+), 0 deletions(-) > > diff --git a/Documentation/media-framework.txt > b/Documentation/media-framework.txt index a599824..59649e9 100644 > --- a/Documentation/media-framework.txt > +++ b/Documentation/media-framework.txt > @@ -278,3 +278,40 @@ When the graph traversal is complete the function > will return NULL. > > Graph traversal can be interrupted at any moment. No cleanup function > call is required and the graph structure can be freed normally. > > + > +Reference counting and power handling > +- > + > +Before accessing type-specific entities operations (such as the V4L2 > +sub-device operations), drivers must acquire a reference to the > entity. This +ensures that the entity will be powered on and ready to > accept requests. +Similarly, after being done with an entity, drivers > must release the +reference. > + > +media_entity_get(struct media_entity *entity) > + > +The function will increase the entity reference count. If the entity > is a node +(MEDIA_ENTITY_TYPE_NODE type), the reference count of all > entities it is +connected to, both directly or indirectly, through > active links is increased. +This ensures that the whole media > pipeline will be ready to process + > +Acquiring a reference to an entity increases the media device module > reference +count to prevent module unloading when an entity is being > used. + > +media_entity_get will return a pointer to the entity if successful, > or NULL +otherwise. > + > +media_entity_put(struct media_entity *entity) > + > +The function will decrease the entity reference count and, for node > entities, +like media_entity_get, the reference count of all connected > entities. Calling +media_entity_put with a NULL argument is valid and > will return immediately. + > +When the first reference to an entity is acquired, or the last > reference +released, the entity's set_power operation is called. > Entity drivers must +implement the operation if they need to perform > any power management task, +such as turning powers or clocks on or > off. If no power management is +required, drivers don't need to > provide a set_power operation. The operation +is allowed to fail when > turning power on, in which case the media_entity_get +function will > return NULL. > >>> > >>> The idea of doing power management via media entity get/put doesn't > >>> seem right. The mediabus interface and its usage should be optional, > >>> and only specialized applications will likely implement it. If a > >>> refcount 0 means power off, it ends that a device implementing the > >>> media bus will not work with V4L2 applications. > >> > >> The Media controller does handle the power through reference count but > >> this does not limit to subdev entities. The reference count is also > >> applied recursively to all entities which are connected through active > >> links. > >> > >> There are two cases: > >> > >> 1. The user application opens a subdev node. The subdev entity use count > >> will be incremented and the subdev will be powered up. > >> > >> 2. The user application opens a video node. The reference count for all > >> entities connected to the video node entity through ac
Re: [Query] Is there a spec to request video sensor information?
Hi Hans, On Thursday 16 September 2010 12:36:34 Hans Verkuil wrote: > > On Monday 13 September 2010 19:06:20 Hans Verkuil wrote: > >> On Monday, September 13, 2010 17:27:52 Sakari Ailus wrote: [snip] > >> > What we currently have is this, not in upstream: > >> > > >> > --- > >> > /* SMIA-type sensor information */ > >> > #define V4L2_CID_MODE_CLASS_BASE (V4L2_CTRL_CLASS_MODE | 0x900) > >> > #define V4L2_CID_MODE_CLASS (V4L2_CTRL_CLASS_MODE | 1) > >> > #define V4L2_CID_MODE_FRAME_WIDTH(V4L2_CID_MODE_CLASS_BASE+1) > >> > #define V4L2_CID_MODE_FRAME_HEIGHT (V4L2_CID_MODE_CLASS_BASE+2) > >> > #define V4L2_CID_MODE_VISIBLE_WIDTH (V4L2_CID_MODE_CLASS_BASE+3) > >> > #define V4L2_CID_MODE_VISIBLE_HEIGHT (V4L2_CID_MODE_CLASS_BASE+4) > >> > #define V4L2_CID_MODE_PIXELCLOCK (V4L2_CID_MODE_CLASS_BASE+5) > >> > #define V4L2_CID_MODE_SENSITIVITY(V4L2_CID_MODE_CLASS_BASE+6) > > > > --- > > > >> > The pixel clock is read-only but some of the others should likely be > >> > changeable. > >> > >> It is very similar to the VIDIOC_G/S_DV_TIMINGS ioctls. I think we should > >> look into adding an e.g. V4L2_DV_SMIA_SENSOR type or something along > >> those lines. > > > > I'm not sure if sensivity would fit in there. The rest probably would. > > > >> I'm no sensor expert, so I don't know what sort of timing information is > >> needed for the various sensor types. But I'm sure there are other people > >> who have this knowledge. It would be useful if someone can list the > >> information that you need from the various sensor types. Based on that > >> we can see if this ioctl is a good fit. > > > > Another possibility could be to report the information using the media > > controller framework and an upcoming MEDIA_IOC_ENTITY_INFO ioctl. > > Are you talking about timing information? That doesn't belong in the media > framework. But I think I didn't quite understood what you meant here. Driver need to report driver-specific entity information (such as extension unit GUIDs for the UVC driver for instance). The idea was to add a media controller ioctl for that. Sensor information could be reported using the same mechanism. -- 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: [GIT PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h
On Wed, Sep 15, 2010 at 10:00:26PM +0200, Hans Verkuil wrote:
> Mauro, Jean, Janne,
>
> This patch series finally retires the hackish v4l2-i2c-drv.h. It served
> honorably,
> but now that the hg repository no longer supports kernels <2.6.26 it is time
> to
> remove it.
>
> Note that this patch series builds on the vtx-removal patch series.
>
> Several patches at the end remove unused i2c-id.h includes and remove bogus
> uses
> of the I2C_HW_ defines (as found in i2c-id.h).
>
> After applying this patch series I get the following if I grep for
> I2C_HW_ in the kernel sources:
>
>
> drivers/staging/lirc/lirc_i2c.c:if (adap->id ==
> I2C_HW_B_CX2388x)
> drivers/staging/lirc/lirc_i2c.c:if (adap->id ==
> I2C_HW_B_CX2388x) {
> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> drivers/staging/lirc/lirc_zilog.c: if (ir->c_rx.adapter->id ==
> I2C_HW_B_HDPVR) {
> drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
> drivers/staging/lirc/lirc_zilog.c: if (ir->c_rx.adapter->id ==
> I2C_HW_B_HDPVR)
> drivers/video/riva/rivafb-i2c.c:chan->adapter.id=
> I2C_HW_B_RIVA;
> drivers/media/video/ir-kbd-i2c.c: if (ir->c->adapter->id ==
> I2C_HW_SAA7134 && ir->c->addr == 0x30)
> drivers/media/video/ir-kbd-i2c.c: if (adap->id ==
> I2C_HW_B_CX2388x) {
> drivers/media/video/saa7134/saa7134-i2c.c: .id=
> I2C_HW_SAA7134,
> drivers/media/video/cx88/cx88-i2c.c:core->i2c_adap.id = I2C_HW_B_CX2388x;
> drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c->adap.id =
> I2C_HW_B_CX2388x;
>
> Jean, I guess the one in rivafb-i2c.c can just be removed, right?
>
> Janne, the HDPVR checks in lirc no longer work since hdpvr never sets the
> adapter ID (nor should it). This lirc code should be checked. I haven't
> been following the IR changes, but there must be a better way of doing this.
The staging/lirc drivers will only be merged after porting them to
ir/rc-core. CC-ed Jarod who will work on lirc_zilog.
>
> The same is true for the CX2388x and SAA7134 checks. These all relate to the
> IR subsystem.
>
> Once we fixed these remaining users of the i2c-id.h defines, then Jean can
> remove that header together with the adapter's 'id' field.
>
> Regards,
>
> Hans
>
> The following changes since commit 991403c594f666a2ed46297c592c60c3b9f4e1e2:
> Mauro Carvalho Chehab (1):
> V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0)
>
> are available in the git repository at:
>
> ssh://linuxtv.org/git/hverkuil/v4l-dvb.git i2c
>
> Hans Verkuil (49):
> saa5246a/saa5249: Remove obsolete teletext drivers
> videotext: remove this obsolete API
> Documentation: update now that the vtx/videotext API has been removed.
> Merge branch 'vtx' into i2c
>
> The patches above are the same as the vtx patch series posted before. This
> patch series requires that vtx is merged first as there is no point to convert
> i2c drivers that are going to be removed anyway!
>
> vp27smpx: remove obsolete v4l2-i2c-drv.h header
> wm8739: remove obsolete v4l2-i2c-drv.h header
> cs5345: remove obsolete v4l2-i2c-drv.h header
> saa717x: remove obsolete v4l2-i2c-drv.h header
> saa7115: remove obsolete v4l2-i2c-drv.h header.
> tda9840: remove obsolete v4l2-i2c-drv.h header
> ov7670: remove obsolete v4l2-i2c-drv.h header
> mt9v011: remove obsolete v4l2-i2c-drv.h header
> upd64031a: remove obsolete v4l2-i2c-drv.h header
> saa6588: remove obsolete v4l2-i2c-drv.h header
> saa6752hs: remove obsolete v4l2-i2c-drv.h header
> bt819: remove obsolete v4l2-i2c-drv.h header
> indycam: remove obsolete v4l2-i2c-drv.h header
> m52790: remove obsolete v4l2-i2c-drv.h header
> saa7185: remove obsolete v4l2-i2c-drv.h header
> msp3400: remove obsolete v4l2-i2c-drv.h header
> bt866: remove obsolete v4l2-i2c-drv.h header
> tea6415c: remove obsolete v4l2-i2c-drv.h header
> tvaudio: remove obsolete v4l2-i2c-drv.h header
> wm8775: remove obsolete v4l2-i2c-drv.h header
> adv7175: remove obsolete v4l2-i2c-drv.h header
> saa7191: remove obsolete v4l2-i2c-drv.h header
> bt856: remove obsolete v4l2-i2c-drv.h header
> tlv320aic23b: remove obsolete v4l2-i2c-drv.h header
> tuner: remove obsolete v4l2-i2c-drv.h header
> tda9875: remove obsolete v4l2-i2c-drv.h header
> saa7110: remove obsolete v4l2-i2c-drv.h header
> tda7432: remove obsolete v4l2-i2c-drv.h header
> tea6420: remove obsolete v4l2-i2c-drv.h header
> cs53l32a: remove obsolete v4l2-i2c-drv.h header
> vpx3220: remove obsolete v4l2-i2c-drv.h header
> tvp5150: remove obsolete v4l2-i2c-drv.h header
> upd64083: remove obsolete v4l2-i2c-drv.h header
> saa7127: remove obsolete v4l2-i2c-drv.h header
> cx25840: remove obsolete v4l2-i2c-drv.h header
> adv7
Re: [Query] Is there a spec to request video sensor information?
> Hi Hans, > > On Monday 13 September 2010 19:06:20 Hans Verkuil wrote: >> On Monday, September 13, 2010 17:27:52 Sakari Ailus wrote: >> > Aguirre, Sergio wrote: >> > > I was wondering if there exists a current standard way to query a >> > > Imaging sensor driver for knowing things like the signal vert/horz >> > > blanking time. >> > > >> > > In an old TI custom driver, we used to have a private IOCTL in the >> > > sensor Driver we interfaced with the omap3 ISP, which was basically >> > > reporting: >> > > >> > > - Active resolution (Actual image size) >> > > - Full resolution (Above size + dummy pixel columns/rows >> representing >> > > blanking times) >> > > >> > > However I resist to keep importing that custom interface, since I >> think >> > > its Something that could be already part of an standard API. >> > >> > The N900 sensor drivers currently use private controls for this >> purpose. >> > That is an issue which should be resolved. I agree there should be a >> > uniform, standard way to access this information. >> > >> > What we currently have is this, not in upstream: >> > >> > --- >> > /* SMIA-type sensor information */ >> > #define V4L2_CID_MODE_CLASS_BASE(V4L2_CTRL_CLASS_MODE | >> 0x900) >> > #define V4L2_CID_MODE_CLASS (V4L2_CTRL_CLASS_MODE | 1) >> > #define V4L2_CID_MODE_FRAME_WIDTH >> (V4L2_CID_MODE_CLASS_BASE+1) >> > #define V4L2_CID_MODE_FRAME_HEIGHT >> (V4L2_CID_MODE_CLASS_BASE+2) >> > #define V4L2_CID_MODE_VISIBLE_WIDTH >> (V4L2_CID_MODE_CLASS_BASE+3) >> > #define V4L2_CID_MODE_VISIBLE_HEIGHT >> (V4L2_CID_MODE_CLASS_BASE+4) >> > #define V4L2_CID_MODE_PIXELCLOCK >> (V4L2_CID_MODE_CLASS_BASE+5) >> > #define V4L2_CID_MODE_SENSITIVITY >> (V4L2_CID_MODE_CLASS_BASE+6) > --- >> > >> > The pixel clock is read-only but some of the others should likely be >> > changeable. >> >> It is very similar to the VIDIOC_G/S_DV_TIMINGS ioctls. I think we >> should >> look into adding an e.g. V4L2_DV_SMIA_SENSOR type or something along >> those >> lines. > > I'm not sure if sensivity would fit in there. The rest probably would. > >> I'm no sensor expert, so I don't know what sort of timing information is >> needed for the various sensor types. But I'm sure there are other people >> who have this knowledge. It would be useful if someone can list the >> information that you need from the various sensor types. Based on that >> we >> can see if this ioctl is a good fit. > > Another possibility could be to report the information using the media > controller framework and an upcoming MEDIA_IOC_ENTITY_INFO ioctl. Are you talking about timing information? That doesn't belong in the media framework. But I think I didn't quite understood what you meant here. Regards, Hans > > -- > 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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of 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
Re: [RFC/PATCH v4 05/11] media: Reference count and power handling
Em 16-09-2010 05:46, Laurent Pinchart escreveu: > Hi, > > On Saturday 11 September 2010 22:38:33 Sakari Ailus wrote: >> Mauro Carvalho Chehab wrote: >>> Em 20-08-2010 12:29, Laurent Pinchart escreveu: From: Sakari Ailus Basically these are the interface functions: media_entity_get() - acquire entity media_entity_put() - release entity If the entity is of node type, the power change is distributed to all connected entities. For non-nodes it only affects that very node. A mutex is used to serialise access to the entity graph. In the background there's a depth-first search algorithm that traverses the active links in the graph. All these functions parse the graph to implement whatever they're to do. The module counters are increased/decreased in media_entity_get/put to prevent module unloading when an entity is referenced. Signed-off-by: Sakari Ailus Signed-off-by: Laurent Pinchart Signed-off-by: Stanimir Varbanov --- Documentation/media-framework.txt | 37 + drivers/media/media-device.c |1 + drivers/media/media-entity.c | 146 + include/media/media-device.h |4 + include/media/media-entity.h | 15 5 files changed, 203 insertions(+), 0 deletions(-) diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index a599824..59649e9 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -278,3 +278,40 @@ When the graph traversal is complete the function will return NULL. Graph traversal can be interrupted at any moment. No cleanup function call is required and the graph structure can be freed normally. + +Reference counting and power handling +- + +Before accessing type-specific entities operations (such as the V4L2 +sub-device operations), drivers must acquire a reference to the entity. This +ensures that the entity will be powered on and ready to accept requests. +Similarly, after being done with an entity, drivers must release the +reference. + + media_entity_get(struct media_entity *entity) + +The function will increase the entity reference count. If the entity is a node +(MEDIA_ENTITY_TYPE_NODE type), the reference count of all entities it is +connected to, both directly or indirectly, through active links is increased. +This ensures that the whole media pipeline will be ready to process + +Acquiring a reference to an entity increases the media device module reference +count to prevent module unloading when an entity is being used. + +media_entity_get will return a pointer to the entity if successful, or NULL +otherwise. + + media_entity_put(struct media_entity *entity) + +The function will decrease the entity reference count and, for node entities, +like media_entity_get, the reference count of all connected entities. Calling +media_entity_put with a NULL argument is valid and will return immediately. + +When the first reference to an entity is acquired, or the last reference +released, the entity's set_power operation is called. Entity drivers must +implement the operation if they need to perform any power management task, +such as turning powers or clocks on or off. If no power management is +required, drivers don't need to provide a set_power operation. The operation +is allowed to fail when turning power on, in which case the media_entity_get +function will return NULL. >>> >>> The idea of doing power management via media entity get/put doesn't seem >>> right. The mediabus interface and its usage should be optional, and only >>> specialized applications will likely implement it. If a refcount 0 means >>> power off, it ends that a device implementing the media bus will not >>> work with V4L2 applications. >> >> The Media controller does handle the power through reference count but >> this does not limit to subdev entities. The reference count is also >> applied recursively to all entities which are connected through active >> links. >> >> There are two cases: >> >> 1. The user application opens a subdev node. The subdev entity use count >> will be incremented and the subdev will be powered up. >> >> 2. The user application opens a video node. The reference count for all >> entities connected to the video node entity through active links will be >> incremented. Subdevs will be powered up as well (if they are not already >> because of (1) above). The same works if the entities connected through >> a video node are connected to another entity and the link to that entity >> is activated. In this case the use_counts of the entity se
Re: [PATCH] Illuminators and status LED controls
Hi Mauro, On Monday 13 September 2010 16:38:03 Mauro Carvalho Chehab wrote: > Em 13-09-2010 10:49, Andy Walls escreveu: > > On Mon, 2010-09-13 at 08:45 -0300, Mauro Carvalho Chehab wrote: > >> Em 13-09-2010 05:06, Hans Verkuil escreveu: > >>> On Monday, September 13, 2010 09:04:18 Laurent Pinchart wrote: > On Thursday 09 September 2010 13:48:58 Hans de Goede wrote: > > On 09/09/2010 03:29 PM, Hans Verkuil wrote: > >>> On 09/09/2010 08:55 AM, Peter Korsgaard wrote: > "Hans" == Hans Verkuil writes: > > I originally was in favor of controlling these through v4l as > well, but people made some good arguments against that. The main > one being: why would you want to show these as a control? What is > the end user supposed to do with them? It makes little sense. > > Status LEDs reflect in glasses, making annoying color dots on webcam > pictures. That's why Logitech allows to turn the status LED off on > its webcams. > >>> > >>> That's a really good argument. I didn't think of that one. > >> > >> There's one difference between illuminators and leds and anything else > >> that we use currently via CTRL interface: all other controls affects > >> just an internal hardware capability that are not visible to the user, > >> nor can cause any kind of damage or annoyance. > >> > >> On the other hand, a LED and an illuminator that an application may > >> forget to turn off could be very annoying, and may eventually reduce > >> the lifecycle or a device (in the case of non-LED illuminators, for > >> example). > > > > Yes, I can appreciate that. On driver unload and suspend that should > > certainly be the case for illuminators. > > > > However, I don't think that's a good idea for final close on a file > > descriptor though. That's a departure from normal V4L2 behavior. > > This doesn't seem to be a good reason. Keeping a LED after its usage is > annoying to the user, can cause damage on devices (reduce lifetime) and > can draw lots of power from the batteries (on battery-powered devices). > > > For a USB connected device, turning off the illuminator after the fact > > is simple, if the user has no other recourse: unplug the device. :) > > Try to unplug the flash led on your cell phone ;) Flash are much more complex than "simple" illuminators. They require pre-flash timing information and flash current for instance. The flash API will need a control to set the flash duration, and the driver (or hardware) should turn the flash off automatically after a security timeout (depending on the current, the hardware, ...). > >> So, a special treatment seems to be required for both cases: if the > >> application that changed the LED or illuminator to ON dies or closes, > >> the LED/illuminator should be turned off by the driver. > > > > That will break cases like these: > > > > $ v4l2-ctl -d /dev/video0 -c illuminator_2=1 > > $ (command to run app that doesn't present all controls, e.g. cheese) > > True, but it may have an alternative syntax for it, like: > > v4l2-ctl -d /dev/video0 -c illuminator_2=1 --run cheese [] > > This way, if cheese or v4l2-ctl abends, the illuminator will be turned off. > > Of course, we'll likely need to have a flag visible on userspace, to say > that such control resets to an "off" state when the application dies, to > avoid someone to use it like: > v4l2-ctl -d /dev/video0 -c illuminator_2=1 -- 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: [Query] Is there a spec to request video sensor information?
Hi Hans, On Monday 13 September 2010 19:06:20 Hans Verkuil wrote: > On Monday, September 13, 2010 17:27:52 Sakari Ailus wrote: > > Aguirre, Sergio wrote: > > > I was wondering if there exists a current standard way to query a > > > Imaging sensor driver for knowing things like the signal vert/horz > > > blanking time. > > > > > > In an old TI custom driver, we used to have a private IOCTL in the > > > sensor Driver we interfaced with the omap3 ISP, which was basically > > > reporting: > > > > > > - Active resolution (Actual image size) > > > - Full resolution (Above size + dummy pixel columns/rows representing > > > blanking times) > > > > > > However I resist to keep importing that custom interface, since I think > > > its Something that could be already part of an standard API. > > > > The N900 sensor drivers currently use private controls for this purpose. > > That is an issue which should be resolved. I agree there should be a > > uniform, standard way to access this information. > > > > What we currently have is this, not in upstream: > > > > --- > > /* SMIA-type sensor information */ > > #define V4L2_CID_MODE_CLASS_BASE(V4L2_CTRL_CLASS_MODE | 0x900) > > #define V4L2_CID_MODE_CLASS (V4L2_CTRL_CLASS_MODE | 1) > > #define V4L2_CID_MODE_FRAME_WIDTH (V4L2_CID_MODE_CLASS_BASE+1) > > #define V4L2_CID_MODE_FRAME_HEIGHT (V4L2_CID_MODE_CLASS_BASE+2) > > #define V4L2_CID_MODE_VISIBLE_WIDTH (V4L2_CID_MODE_CLASS_BASE+3) > > #define V4L2_CID_MODE_VISIBLE_HEIGHT(V4L2_CID_MODE_CLASS_BASE+4) > > #define V4L2_CID_MODE_PIXELCLOCK(V4L2_CID_MODE_CLASS_BASE+5) > > #define V4L2_CID_MODE_SENSITIVITY (V4L2_CID_MODE_CLASS_BASE+6) --- > > > > The pixel clock is read-only but some of the others should likely be > > changeable. > > It is very similar to the VIDIOC_G/S_DV_TIMINGS ioctls. I think we should > look into adding an e.g. V4L2_DV_SMIA_SENSOR type or something along those > lines. I'm not sure if sensivity would fit in there. The rest probably would. > I'm no sensor expert, so I don't know what sort of timing information is > needed for the various sensor types. But I'm sure there are other people > who have this knowledge. It would be useful if someone can list the > information that you need from the various sensor types. Based on that we > can see if this ioctl is a good fit. Another possibility could be to report the information using the media controller framework and an upcoming MEDIA_IOC_ENTITY_INFO ioctl. -- 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 v4 07/11] media: Entities, pads and links enumeration
Hi Hans,
On Monday 06 September 2010 18:51:59 Hans Verkuil wrote:
> On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote:
> > On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote:
> > > On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
> > [snip]
> >
> > > > diff --git a/Documentation/media-framework.txt
> > > > b/Documentation/media-framework.txt index 66f7f6c..74a137d 100644
> > > > --- a/Documentation/media-framework.txt
> > > > +++ b/Documentation/media-framework.txt
> >
> > [snip]
> >
> > > > +The media_entity_desc structure is defined as
> > > > +
> > > > +- struct media_entity_desc
> > > > +
> > > > +__u32 id Entity id, set by the application. When the id
> > > > is
> > > > + or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
> > > > + clears the flag and returns the first entity
> > > > with a
> > > > + larger id.
> > > > +char name[32]Entity name. UTF-8 NULL-terminated string.
> > >
> > > Why UTF-8 instead of ASCII?
> >
> > Because vendor-specific names could include non-ASCII characters (same
> > reason for the model name in the media_device structure, if we decice to
> > make the model name ASCII I'll make the entity name ASCII as well).
> >
> > [snip]
> >
> > > > +struct media_entity_desc {
> > > > + __u32 id;
> > > > + char name[32];
> > > > + __u32 type;
> > > > + __u32 revision;
> > > > + __u32 flags;
> > > > + __u32 group_id;
> > > > + __u16 pads;
> > > > + __u16 links;
> > > > +
> > > > + __u32 reserved[4];
> > > > +
> > > > + union {
> > > > + /* Node specifications */
> > > > + struct {
> > > > + __u32 major;
> > > > + __u32 minor;
> > > > + } v4l;
> > > > + struct {
> > > > + __u32 major;
> > > > + __u32 minor;
> > > > + } fb;
> > > > + int alsa;
> > > > + int dvb;
> > > > +
> > > > + /* Sub-device specifications */
> > > > + /* Nothing needed yet */
> > > > + __u8 raw[64];
> > > > + };
> > > > +};
> > >
> > > Should this be a packed struct?
> >
> > Why ? :-) Packed struct are most useful when they need to match hardware
> > structures or network protocols. Packing a structure can generate
> > unaligned fields, which are bad performance-wise.
>
> I'm thinking about preventing a compat32 mess as we have for v4l.
>
> It is my understanding that the only way to prevent different struct sizes
> between 32 and 64 bit is to use packed.
I don't think that's correct. Different struct sizes between 32bit and 64bit
are caused by variable-size fields, such as 'long' (32bit on 32bit
architectures, 64bit on 64bit architectures). I might be wrong though.
--
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 v4 08/11] media: Links setup
Hi Mauro, On Thursday 09 September 2010 03:14:44 Mauro Carvalho Chehab wrote: > Em 20-08-2010 12:29, Laurent Pinchart escreveu: > > Create the following ioctl and implement it at the media device level to > > setup links. > > > > - MEDIA_IOC_SETUP_LINK: Modify the properties of a given link > > > > The only property that can currently be modified is the ACTIVE link flag > > to activate/deactivate a link. Links marked with the IMMUTABLE link flag > > can not be activated or deactivated. > > > > Activating and deactivating a link has effects on entities' use count. > > Those changes are automatically propagated through the graph. > > You need to address here the release() call: if the userspace application > dies or just exits, the device should be set into a sane state, e. g. > devices powered on should be turned off, That's already handled, as media_entity_put() is called in the vdev and subdev release() functions. > and links activated by the application should be de-activated. I don't think that's required. When an application exits with a video device node open, we don't reset all controls and formats. Power needs to be turned off and resources need to be released on exit, but configuration doesn't need to be reset. -- 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 v4 08/11] media: Links setup
Hi Hans,
On Monday 06 September 2010 19:09:20 Hans Verkuil wrote:
> On Wednesday, September 01, 2010 16:08:29 Laurent Pinchart wrote:
> > On Saturday 28 August 2010 13:14:18 Hans Verkuil wrote:
> > > On Friday, August 20, 2010 17:29:10 Laurent Pinchart wrote:
> > [snip]
> >
> > > > +/**
> > > > + * media_entity_remote_pad - Locate the pad at the remote end of a
> > > > link + * @entity: Local entity
> > > > + * @pad: Pad at the local end of the link
> > > > + *
> > > > + * Search for a remote pad connected to the given pad by iterating
> > > > over all
> > > > + * links originating or terminating at that pad until an active link
> > > > is found.
> > > > + *
> > > > + * Return a pointer to the pad at the remote end of the first found
> > > > active link,
> > > > + * or NULL if no active link has been found.
> > > > + */
> > > > +struct media_pad *media_entity_remote_pad(struct media_pad *pad)
> > > > +{
> > > > + unsigned int i;
> > > > +
> > > > + for (i = 0; i < pad->entity->num_links; i++) {
> > > > + struct media_link *link = &pad->entity->links[i];
> > > > +
> > > > + if (!(link->flags & MEDIA_LINK_FLAG_ACTIVE))
> > > > + continue;
> > > > +
> > > > + if (link->source == pad)
> > > > + return link->sink;
> > > > +
> > > > + if (link->sink == pad)
> > > > + return link->source;
> > > > + }
> > > > +
> > > > + return NULL;
> > > > +
> > > > +}
> > >
> > > Why is this needed? Esp. since there can be multiple active remote pads
> > > if you have multiple active outgoing links. Something this function
> > > doesn't deal with.
> >
> > The function is meant to be used when only one of the links can be
> > active. It's most useful to find the entity connected to a given input
> > pad, as input pads can't be connected by multiple simultaneously active
> > links.
>
> In that case I would rename it media_entity_remote_source to match the use
> case (and only look for remote sources).
OK, I'll rename the function.
> Alternatively you could add an index for the nth active link, then it would
> be truly generic.
>
> Right now the function either does too much or too little :-)
--
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 v4 11/11] v4l: Make v4l2_subdev inherit from media_entity
Hi Mauro,
On Thursday 09 September 2010 03:25:38 Mauro Carvalho Chehab wrote:
> Em 20-08-2010 12:29, Laurent Pinchart escreveu:
> > V4L2 subdevices are media entities. As such they need to inherit from
> > (include) the media_entity structure.
> >
> > When registering/unregistering the subdevice, the media entity is
> > automatically registered/unregistered. The entity is acquired on device
> > open and released on device close.
> >
> > Signed-off-by: Laurent Pinchart
> > Signed-off-by: Sakari Ailus
> > ---
> >
> > Documentation/video4linux/v4l2-framework.txt | 23 ++
> > drivers/media/video/v4l2-device.c| 32
> > +- drivers/media/video/v4l2-subdev.c
> > | 27 +- include/media/v4l2-subdev.h
> > |7 +
> > 4 files changed, 82 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/video4linux/v4l2-framework.txt
> > b/Documentation/video4linux/v4l2-framework.txt index 7ff4016..3416d93
> > 100644
> > --- a/Documentation/video4linux/v4l2-framework.txt
> > +++ b/Documentation/video4linux/v4l2-framework.txt
> >
> > @@ -263,6 +263,26 @@ A sub-device driver initializes the v4l2_subdev
struct using:
> > Afterwards you need to initialize subdev->name with a unique name and
> > set the module owner. This is done for you if you use the i2c helper
> > functions.
> >
> > +If integration with the media framework is needed, you must initialize
> > the +media_entity struct embedded in the v4l2_subdev struct (entity
> > field) by +calling media_entity_init():
> > +
> > + struct media_pad *pads = &my_sd->pads;
> > + int err;
> > +
> > + err = media_entity_init(&sd->entity, npads, pads, 0);
> > +
> > +The pads array must have been previously initialized. There is no need
> > to +manually set the struct media_entity type and name fields, but the
> > revision +field must be initialized if needed.
> > +
> > +A reference to the entity will be automatically acquired/released when
> > the +subdev device node (if any) is opened/closed.
> > +
> > +Don't forget to cleanup the media entity before the sub-device is
> > destroyed: +
> > + media_entity_cleanup(&sd->entity);
> > +
> >
> > A device (bridge) driver needs to register the v4l2_subdev with the
> >
> > v4l2_device:
> > @@ -272,6 +292,9 @@ This can fail if the subdev module disappeared before
> > it could be registered.
> >
> > After this function was called successfully the subdev->dev field points
> > to the v4l2_device.
> >
> > +If the v4l2_device parent device has a non-NULL mdev field, the
> > sub-device +entity will be automatically registered with the media
> > device.
> > +
> >
> > You can unregister a sub-device using:
> > v4l2_device_unregister_subdev(sd);
> >
> > diff --git a/drivers/media/video/v4l2-device.c
> > b/drivers/media/video/v4l2-device.c index 91452cd..4f74d01 100644
> > --- a/drivers/media/video/v4l2-device.c
> > +++ b/drivers/media/video/v4l2-device.c
> > @@ -114,10 +114,11 @@ void v4l2_device_unregister(struct v4l2_device
> > *v4l2_dev)
> >
> > EXPORT_SYMBOL_GPL(v4l2_device_unregister);
> >
> > int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev,
> >
> > - struct v4l2_subdev *sd)
> > + struct v4l2_subdev *sd)
> >
> > {
> >
> > + struct media_entity *entity = &sd->entity;
> >
> > struct video_device *vdev;
> >
> > - int ret = 0;
> > + int ret;
> >
> > /* Check for valid input */
> > if (v4l2_dev == NULL || sd == NULL || !sd->name[0])
> >
> > @@ -129,6 +130,15 @@ int v4l2_device_register_subdev(struct v4l2_device
> > *v4l2_dev,
> >
> > if (!try_module_get(sd->owner))
> >
> > return -ENODEV;
> >
> > + /* Register the entity. */
> > + if (v4l2_dev->mdev) {
> > + ret = media_device_register_entity(v4l2_dev->mdev, entity);
> > + if (ret < 0) {
> > + module_put(sd->owner);
> > + return ret;
> > + }
> > + }
> > +
> >
> > sd->v4l2_dev = v4l2_dev;
> > spin_lock(&v4l2_dev->lock);
> > list_add_tail(&sd->list, &v4l2_dev->subdevs);
> >
> > @@ -143,26 +153,36 @@ int v4l2_device_register_subdev(struct v4l2_device
> > *v4l2_dev,
> >
> > if (sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE) {
> >
> > ret = __video_register_device(vdev, VFL_TYPE_SUBDEV, -1, 1,
> >
> > sd->owner);
> >
> > - if (ret < 0)
> > + if (ret < 0) {
> >
> > v4l2_device_unregister_subdev(sd);
> >
> > + return ret;
> > + }
> >
> > }
> >
> > - return ret;
> > + entity->v4l.major = VIDEO_MAJOR;
> > + entity->v4l.minor = vdev->minor;
>
> Hmm... it needs to check if entity is not null.
Entity is set to
struct media_entity *entity = &sd->entity;
It can't be NULL.
> > + return 0;
> >
Re: [RFC/PATCH v4 05/11] media: Reference count and power handling
Hi, On Saturday 11 September 2010 22:38:33 Sakari Ailus wrote: > Mauro Carvalho Chehab wrote: > > Em 20-08-2010 12:29, Laurent Pinchart escreveu: > >> From: Sakari Ailus > >> > >> Basically these are the interface functions: > >> > >> media_entity_get() - acquire entity > >> media_entity_put() - release entity > >> > >>If the entity is of node type, the power change is distributed to > >>all connected entities. For non-nodes it only affects that very > >>node. A mutex is used to serialise access to the entity graph. > >> > >> In the background there's a depth-first search algorithm that traverses > >> the active links in the graph. All these functions parse the graph to > >> implement whatever they're to do. > >> > >> The module counters are increased/decreased in media_entity_get/put to > >> prevent module unloading when an entity is referenced. > >> > >> Signed-off-by: Sakari Ailus > >> Signed-off-by: Laurent Pinchart > >> Signed-off-by: Stanimir Varbanov > >> --- > >> > >> Documentation/media-framework.txt | 37 + > >> drivers/media/media-device.c |1 + > >> drivers/media/media-entity.c | 146 > >> + include/media/media-device.h > >> |4 + > >> include/media/media-entity.h | 15 > >> 5 files changed, 203 insertions(+), 0 deletions(-) > >> > >> diff --git a/Documentation/media-framework.txt > >> b/Documentation/media-framework.txt index a599824..59649e9 100644 > >> --- a/Documentation/media-framework.txt > >> +++ b/Documentation/media-framework.txt > >> @@ -278,3 +278,40 @@ When the graph traversal is complete the function > >> will return NULL. > >> > >> Graph traversal can be interrupted at any moment. No cleanup function > >> call is required and the graph structure can be freed normally. > >> > >> + > >> +Reference counting and power handling > >> +- > >> + > >> +Before accessing type-specific entities operations (such as the V4L2 > >> +sub-device operations), drivers must acquire a reference to the entity. > >> This +ensures that the entity will be powered on and ready to accept > >> requests. +Similarly, after being done with an entity, drivers must > >> release the +reference. > >> + > >> + media_entity_get(struct media_entity *entity) > >> + > >> +The function will increase the entity reference count. If the entity is > >> a node +(MEDIA_ENTITY_TYPE_NODE type), the reference count of all > >> entities it is +connected to, both directly or indirectly, through > >> active links is increased. +This ensures that the whole media pipeline > >> will be ready to process + > >> +Acquiring a reference to an entity increases the media device module > >> reference +count to prevent module unloading when an entity is being > >> used. + > >> +media_entity_get will return a pointer to the entity if successful, or > >> NULL +otherwise. > >> + > >> + media_entity_put(struct media_entity *entity) > >> + > >> +The function will decrease the entity reference count and, for node > >> entities, +like media_entity_get, the reference count of all connected > >> entities. Calling +media_entity_put with a NULL argument is valid and > >> will return immediately. + > >> +When the first reference to an entity is acquired, or the last > >> reference +released, the entity's set_power operation is called. Entity > >> drivers must +implement the operation if they need to perform any power > >> management task, +such as turning powers or clocks on or off. If no > >> power management is +required, drivers don't need to provide a > >> set_power operation. The operation +is allowed to fail when turning > >> power on, in which case the media_entity_get +function will return > >> NULL. > > > > The idea of doing power management via media entity get/put doesn't seem > > right. The mediabus interface and its usage should be optional, and only > > specialized applications will likely implement it. If a refcount 0 means > > power off, it ends that a device implementing the media bus will not > > work with V4L2 applications. > > The Media controller does handle the power through reference count but > this does not limit to subdev entities. The reference count is also > applied recursively to all entities which are connected through active > links. > > There are two cases: > > 1. The user application opens a subdev node. The subdev entity use count > will be incremented and the subdev will be powered up. > > 2. The user application opens a video node. The reference count for all > entities connected to the video node entity through active links will be > incremented. Subdevs will be powered up as well (if they are not already > because of (1) above). The same works if the entities connected through > a video node are connected to another entity and the link to that entity > is activated. In this case the use_counts of the entity sets are applied > across the both sets. > > The user appl
Re: [PATCH 4/4] IR/imon: set up mce-only devices w/mce keytable
ja...@redhat.com said: > + /* iMON LCD, MCE IR */ > + case 0x9e: > + dev_info(ictx->dev, "0xffdc iMON VFD, MCE IR"); > + detected_display_type = IMON_DISPLAY_TYPE_VFD; > + allowed_protos = IR_TYPE_RC6; + break; > + /* iMON LCD, MCE IR */ +case 0x9f: > That "LCD" in the comment should be VFD. /Anders -- 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 v9 3/4] V4L2: WL1273 FM Radio: Controls for the FM radio.
Hi.
On Wed, 2010-09-08 at 21:09 +0200, ext Mauro Carvalho Chehab wrote:
> > +static int wl1273_fm_vidioc_s_tuner(struct file *file, void *priv,
> > + struct v4l2_tuner *tuner)
> > +{
> > + struct wl1273_device *radio =
video_get_drvdata(video_devdata(file));
> > + struct wl1273_core *core = radio->core;
> > + int r = 0;
> > +
> > + dev_dbg(radio->dev, "%s\n", __func__);
> > + dev_dbg(radio->dev, "tuner->index: %d\n", tuner->index);
> > + dev_dbg(radio->dev, "tuner->name: %s\n", tuner->name);
> > + dev_dbg(radio->dev, "tuner->capability: 0x%04x\n",
tuner->capability);
> > + dev_dbg(radio->dev, "tuner->rxsubchans: 0x%04x\n",
tuner->rxsubchans);
> > + dev_dbg(radio->dev, "tuner->rangelow: %d\n", tuner->rangelow);
> > + dev_dbg(radio->dev, "tuner->rangehigh: %d\n",
tuner->rangehigh);
>
> Ranges should be using tuner->rangelow/rangehigh to change band
limits.
I just want to make sure that I understand you correctly. So the idea is
that with the g_tuner the driver can tell the frequency range that's
supported by the chip in RX mode, which is 76MHz to 108 MHz. The lowest
part is in the Japan band and the highest is in the Europe/USA band, the
middle section can be either...
Then the application can choose any sub-range of the above by calling
s_tuner with any values rangelow > 76MHz and rangehigh < 108MHz? After
that the driver just deals with the given frequencies by changing the
band if necessary?
Cheers,
Matti
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] DSM-CC question
Its a very good idea. I will look at it as soon as possible and may be come back to you for questions. I have already done most of the implementation by storing blocks in memory and I have to finish it as soon as possible. But later on I can use this idea, it to optimize memory utilization and performance of my code Thanks. - Original Message From: Simon Kilvington To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Wed, 15 September, 2010 10:40:05 Subject: Re: [linux-dvb] DSM-CC question -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 also have a look at my rb-download code, http://redbutton.sourceforge.net/ this gets around the problem of having to know the directory structure before you download files by using symlinks - ie you download the files as they arrive on the carousel, then when you get a directory you create the directory but make all the file entries in it symlinks - if the files have already arrived, then the links point to them, if the files haven't arrived yet, you just have some dangling symlinks until they do this means you don't have to worry about trying to cache files in memory before you can write them to disc and so makes the whole thing a lot simpler to implement On 14/09/10 22:06, Marc Murphy wrote: > Have a look at libdsmcc. It will write by default to /tmp/cache I have > modified >my test software to notify of a new file or updated file version. > > > Hope this helps > > Marc > > Sent from my iPhone > > On 14 Sep 2010, at 21:31, "Suchita Gupta" wrote: > >> Hi, >> >> First of all, I am new to this list, so I am not sire if this is right place >>for >> >> this question. >> If not, please forgive me and point me to right list. >> >> I am writing a DSMCC decoding implementation to persist it to local >filesystem. >> I am unable to understand few thiings related to "srg" >> >> I know, it represents the top level directory. But how do I get the name of >>this >> >> directory? >> I can extract the names of subdirs and files using name components but where >> is >> >> the name of top level directory? >> >> Also, as far as I understand it, I can't start writing to the local >> filesystem > >> until I have acquired the whole carousel. >> >> Can, anyone please provide me some guidance. >> >> Thanks in Advance, >> rs >> >> >> >> >> ___ >> linux-dvb users mailing list >> For V4L/DVB development, please use instead linux-media@vger.kernel.org >> linux-...@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >> > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > - -- Simon Kilvington -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyQlHUACgkQmt9ZifioJSwN7QCffyS4wY25IMysdwFcJEUS/Aaw JBEAoIGShJ/kxMvOT73o7vEqfXMNKr/r =Jf4M -END PGP SIGNATURE- ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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
