Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote: On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus christ...@bartelmus.de wrote: Hi Mauro, on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: [...] But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. [...] I hope it helps for you to better understand how this works. So the plan is to have two ways of using IR in the future which are incompatible to each other, the feature-set of one being a subset of the other? Take advantage of the fact that we don't have a twenty year old legacy API already in the kernel. Design an IR API that uses current kernel systems. Christoph, ignore the code I wrote and make a design proposal that addresses these goals... 1) Unified input in Linux using evdev. IR is on equal footing with mouse and keyboard. I think this a case where automating setup can be over-emphasised (in the remote-as-keyboard case). Apologies in advance if I've misunderstood the idea of utilising the 'input subsystem' for IR. If the plan is to offer dedicated IR events via a yet-to- be-announced input event subsystem and to optionally disallow acting as a keyboard via a module option or similar then please ignore the following. Whilst having remotes come through the input subsystem might be 'the correct thing' from a purely technical standpoint, as an end-user I find the use-case for remotes completely different in one key aspect: Keyboards and mice are generally foreground-app input devices, whereas remotes are often controlling daemons sitting in the background piping media through dedicated devices. As an example I have a VDR instance running in the background on my desktop machine outputting to a TV in another room via a pci mpeg decoder - I certainly don't want the VDR remote control interacting with my X11 desktop in any way unless I go out of my way to set it up to do so, nor do I want it interacting with other applications (such as MPD piping music around the house) that are controlled via other remotes in other rooms unless specified. Setting this up with Lircd was easy, how would a kernel-based proposal handle this? Regards Mike 2) plug and play for basic systems - you only need an external app for scripting 3) No special tools - use mkdir, echo, cat, shell scripts to build maps 4) Use of modern Linux features like sysfs, configfs and udev. 5) Direct multi-app support - no daemon 6) Hide timing data from user as much as possible. What are other goals for this subsystem? Maybe we decide to take the existing LIRC system as is and not integrate it into the input subsystem. But I think there is a window here to update the LIRC design to use the latest kernel features. We don't want to build another /dev/mouse and have to rip it out in five years. When designing the key mapping in the kernel you should be aware that there are remotes out there that send a sequence of scan codes for some buttons, e.g. http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159 This is good input. -- 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] What are the goals for the architecture of an in-kernel IR system?
On Sun, 29 Nov 2009 03:25:49 pm Dmitry Torokhov wrote: On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote: On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote: On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus christ...@bartelmus.de wrote: Hi Mauro, on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: [...] But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. [...] I hope it helps for you to better understand how this works. So the plan is to have two ways of using IR in the future which are incompatible to each other, the feature-set of one being a subset of the other? Take advantage of the fact that we don't have a twenty year old legacy API already in the kernel. Design an IR API that uses current kernel systems. Christoph, ignore the code I wrote and make a design proposal that addresses these goals... 1) Unified input in Linux using evdev. IR is on equal footing with mouse and keyboard. I think this a case where automating setup can be over-emphasised (in the remote-as-keyboard case). Apologies in advance if I've misunderstood the idea of utilising the 'input subsystem' for IR. If the plan is to offer dedicated IR events via a yet-to- be-announced input event subsystem and to optionally disallow acting as a keyboard via a module option or similar then please ignore the following. Whilst having remotes come through the input subsystem might be 'the correct thing' from a purely technical standpoint, as an end-user I find the use-case for remotes completely different in one key aspect: Keyboards and mice are generally foreground-app input devices, whereas remotes are often controlling daemons sitting in the background piping media through dedicated devices. As an example I have a VDR instance running in the background on my desktop machine outputting to a TV in another room via a pci mpeg decoder - I certainly don't want the VDR remote control interacting with my X11 desktop in any way unless I go out of my way to set it up to do so, nor do I want it interacting with other applications (such as MPD piping music around the house) that are controlled via other remotes in other rooms unless specified. Setting this up with Lircd was easy, how would a kernel-based proposal handle this? Why would that be different really? On my keyboard there is a key for e-mail application (and many others) - what HID calls Application Launch keys IIRC. There also application control keys and system control keys, KEY_COFFEE aka KEY_SCREENLOCK. Those are not to be consumed by foreground application but by daemons/session-wide application. In my real-world examples above, both VDR and MPD are started at system start and are not associated with any user-initiated sessions (X login etc) - they are not X11 clients. Their only input is via Lircd. Conversely todays Xserver (if I read my logfiles correctly) consumes all input event devices by default, turning them into keypresses for its client apps. This is exactly the wrong behaviour for my use-case. In order to ensure that my daemons receive their input I must first ensure that X doesn't receive those events - assuming this is possible it still complicates matters further than they are today (I'd need a simple way of automatically differentiating between remote devices and keyboard devices) . Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 2.6.32] V4L/DVB updates
On Tue, 1 Dec 2009, Mauro Carvalho Chehab wrote: Mike Isely wrote: On Mon, 30 Nov 2009, Mauro Carvalho Chehab wrote: Em Sat, 28 Nov 2009 14:33:30 -0600 (CST) Mike Isely is...@isely.net escreveu: Mauro: I had also posted up two high priority pvrusb2 patches that should really be cherry-picked for 2.6.32. You've already pulled them into v4l/dvb and I did mark them as high priority at the time. These patches enable use of FX2 microcontroller firmware that is 16KB in size. Hauppauge is no longer shipping 8KB firmware for HVR-1950 and HVR-1900 and without these changes then those devices won't work AT ALL in kernel 2.6.32. You can find these within the v4l-dvb Mercurial repository here: Changeset 13495:87c3853fe2b3 Subject: pvrusb2: Support 16KB FX2 firmware http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3 Changeset 13500:d4c418d4b25c Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c I do not believe these patches have any ordering dependencies with other patches, though between the two the second one technically should come after the first. There are. Picking just those patches broke compilation. Mauro: Please forward to me the compilation errors. Right now I am just not seeing how a patch this trivial could have any compilation dependencies. And unfortunately I will not be able to reproduce your build setup until at least Tuesday night. I must be blind. Also, it seemed too late for adding support for newer boards/firmware when Linus is about to release a kernel. This is not a new feature. It's a bug fix due to something that Hauppauge recently did. Hauppauge is NO LONGER officially distributing FX2 firmware with their hardware which the driver can use. This simply prevents any new HVR-1950 / HVR-1900 users from working under Linux. This fixes breakage for previously working hardware. The root cause is simple - the firmware blob is just larger now - and the fix is trivial. It absolutely needs to go in. In fact, this should go back to a 2.6.31.x and a 2.6.27.x release as well, though in those cases I have to figure out if driver source code is still close enough for the same patches to still work. I am sorry this is showing up late for you. There are multiple reasons for this. However I did mark these patches as high priority, following your v4l-dvb changeset process. I did comment on the pull request that these were important but I guess I needed to also specifically call these out in the pull request text as well. If these don't get in now as part of the official 2.6.32 release, these absolutely need to be queued for 2.6.32.1. We are very late for 2.6.32. I'm not sure if are there still time for it. I'll seek for some time during this week to add those patches at the upstream tree and removing them from the development tree and see what compilation issues arise. Mauro: Thanks. Guess I also really need to get up to speed on git, finally... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
Scan not getting Channel names after DSO
Hi on one (and only one I think) multiplex after digital switchover I am getting the following [6440]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:101:102:25664 [6480]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:201:202:25728 [64c0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:301:302:25792 [6500]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:25856 [6540]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:501:502:25920 [6b00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:2101:2102:27392 [6b40]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27456 [6b80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27520 [6bc0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27584 [6c00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27648 [6c40]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27712 [6c80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27776 [6cc0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:2311:2312:27840 [6d00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27904 [6d80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:601:602:28032 [6980]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GDone. UARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27008 [6840]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1901:26688 [6800]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1809:26624 [67c0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1701:26560 [66c0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1301:26304 [6680]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1201:26240 [6640]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1101:26176 [6700]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1401:26368 [6a00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:701:702:27136 As you can see instead of the Channel name I am getting what looks to be hex - any idea why, this is on 530167000 frequency (channel 28+) example being this item [6d80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:601:602:28032 should be ITV4:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:601:602:28032 any ideas -- 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: exposing controls in sysfs
Comments below... On Mon, 5 Apr 2010, Hans Verkuil wrote: Hi all, The new control framework makes it very easy to expose controls in sysfs. The way it is implemented now in the framework is that each device node will get a 'controls' subdirectory in sysfs. Below which are all the controls associated with that device node. So different device nodes can have different controls if so desired. The name of each sysfs file is derived from the control name, basically making it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other non- alphanumerical characters. Seems to work well. For numerical controls you can write numbers in decimal, octal or hexadecimal. When you write to a button control it will ignore what you wrote, but still execute the action. It looks like this for ivtv: $ ls /sys/class/video4linux/video1 controls dev device index name power subsystem uevent $ ls /sys/class/video4linux/video1/controls audio_crcchroma_gain spatial_chroma_filter_type video_bitrate_mode audio_emphasis contrast spatial_filter video_encoding audio_encoding hue spatial_filter_mode video_gop_closure audio_layer_ii_bitrate insert_navigation_packets spatial_luma_filter_typevideo_gop_size audio_mute median_chroma_filter_maximum stream_type video_mute audio_sampling_frequency median_chroma_filter_minimum stream_vbi_format video_mute_yuv audio_stereo_modemedian_filter_typetemporal_filter video_peak_bitrate audio_stereo_mode_extension median_luma_filter_maximum temporal_filter_modevideo_temporal_decimation balance median_luma_filter_minimumvideo_aspect volume brightness mute video_b_frames chroma_agc saturationvideo_bitrate The question is, is this sufficient? One of the few drivers that exposes controls in sysfs is pvrusb2. As far as I can tell from the source it will create subdirectories under the device node for each control. Those subdirs have the name ctl_control-name (e.g. ctl_volume), and below that are files exposing all the attributes of that control: name, type, min_val, max_val, def_val, cur_val, custom_val, enum_val and bit_val. Most are clear, but some are a bit more obscure. enum_val is basically a QUERYMENU and returns all menu options. bit_val seems to be used for some non-control values like the TV standard that pvrusb2 also exposes and where bit_val is a bit mask of all the valid bits that can be used. Mike, if you have any additional information, just let us know. My pvrusb2 is in another country at the moment so I can't do any testing. Hans: What you see in the pvrusb2 driver is the result of an idea I had back in 2005. The pvrusb2 driver has an internal control API; my original idea back then was to then reimplement other interfaces on top of that API, in a manner that is as orthogonal as possible. The reality today is still pretty close to that concept (except for DVB unfortunately since that framework's architecture effectively has to take over the RF tuner...); the V4L2 implementation in the driver certainly works this way. The sysfs interface you see here is the result of implementing the same API through sysfs. Right now with the pvrusb2 driver the only thing not exported through sysfs is the actual streaming of video itself. The entire sysfs implementation in the driver can be found in pvrusb2-sysfs.c. Notice that the file is generic; there is not anything in it that is specific to any particular control. Rather, pvrusb2-sysfs.c is able to iterate through the driver's controls, picking up the control's name, its type, and accessors. Based on what it finds, this module then synthesizes the interface that you see in /class/pvrusb2/* - it's actually possible to add new controls to the driver without changing anything in pvrusb2-sysfs.c. Personally I think that it is overkill to basically expose the whole QUERYCTRL information to sysfs. I see it as an easy and quick way to read and modify controls via a command line. Over time, I have ended up using pretty much every control in that interface. Obviously not every control always gets touched, but I have found it extremely valuable to have such direct access to every knob in the driver this way. Also, the original concept was that the interface was to be orthogonal; in theory any kind of control action in one interface should be just as valid in another. Mike, do you know of anyone actively using that additional information? Yes. The VDR project at one time implemented a plugin to directly interface to the pvrusb2 driver in this manner. I do
Re: RFC: exposing controls in sysfs
On Tue, 6 Apr 2010, Hans Verkuil wrote: [...] One thing that might be useful is to prefix the name with the control class name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It would groups them better. Or one could make a controls/user and controls/mpeg directory. That might not be such a bad idea actually. I agree with grouping in concept, and using subdirectories is not a bad thing. Probably however you'd want to ensure that in the end all the controls end up logically at the same depth in the tree. [...] An in between solution would be to add _type files. So you would have 'hue' and 'hue_type'. 'cat hue_type' would give something like: int 0 255 1 128 0x Hue In other words 'type min max step flags name'. There was I thought at some point in the past a kernel policy that sysfs controls were supposed to limit themselves to one value per node. And for menu controls like stream_type (hmm, that would become stream_type_type...) you would get: menu 0 5 1 0 Stream Type MPEG-2 Program Stream MPEG-1 System Stream MPEG-2 DVD-compatible Stream MPEG-1 VCD-compatible Stream MPEG-2 SVCD-compatible Stream Note the empty line to denote the unsupported menu item (transport stream). This would give the same information with just a single extra file. Still not sure whether it is worth it though. Just remember that the more complex / subtle you make the node contents, then the more parsing will be required for any program that tries to use it. I also think it's probably a bad idea for example to define a format where the whitespace conveys additional information. The case where I've seen whitespace as part of the syntax actually work cleanly is in Python. -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: exposing controls in sysfs
On Tue, 6 Apr 2010, Devin Heitmueller wrote: [...] I tend to agree with Hans. We've already got *too many* interfaces that do the same thing. The testing matrix is already a nightmare - V4L1 versus V4L2, mmap() versus read(), legacy controls versus extended controls, and don't get even me started on VBI. We should be working to make drivers and interfaces simpler, with *fewer* ways of doing the same thing. The flexibility of providing yet another interface via sysfs compared to just calling v4l2-ctl just isn't worth the extra testing overhead. We've already got too much stuff that needs to be fixed and not enough good developers to warrant making the code more complicated with little tangible benefit. If another API (e.g. sysfs) is defined and it is specifically NOT permitted to be a complete set, then one can ultimately end up with situations where in order to effectively use a driver then multiple APIs *must* be used by the application. That's even worse. This situation already exists in the pvrusb2 driver and it's not because of sysfs - it's because of V4L and DVB. When the pvrusb2 driver is used to handle a hybrid device (such as the HVR-1950) one has to use both the DVB and V4L APIs in order to effectively operate the device. This is because both APIs provide something not available in the other. And this really sucks if all the user wants to do is stream mpeg, darn it! And I don't care if it is digital or analog. I think that situation is very wrong; given that the HVR-1950 can spit out mpeg in either mode the user shouldn't be forced to make his application choice based on which mode he wants. There's only ONE application out there that allows the user to operate an HVR-1950 without being forced to deal with this: MythTV, and that's because, well, MythTV implements both APIs: V4L and DVB. I really, really dislike situations that arise where multiple APIs are *required* to operate a device, when really there should just be one API. That said, if multiple APIs are to be exported by the driver interface, then such APIs really should be as complete as possible in order to avoid potential problems later where because of previous limiting choices of API design now multiple APIs become required. I agree that testing against multiple APIs can be a pain and a drain on effort. But that has not happened with the pvrusb2 driver. It should be possible to implement the API in a way that minimizes further thrashing due to driver changes. The pvrusb2 sysfs implementation there is programmatically created when the driver comes up. The code which implements that interface really doesn't have any logic specific to particular API functions; it is just a reflection of what is internally in the driver. If new knobs are added to the pvrusb2 driver, then the knob automatically appears in the sysfs interface. If you were to go through the change history of the pvrusb2-sysfs.c module, all you're really going to find are changes caused by the sysfs class environment itself (i.e. when struct class was morphed into struct device), not the driver or its functionality. And nobody I've talked to who writes applications that work with V4L has been screaming OMG, if only V4L had a sysfs interface to manage controls! The experience I've seen with users and the pvrusb2 interface is that once they discover the sysfs API, the response is in fact very positive. Most users of the driver had no concept that such a thing was even possible until they were exposed to it. Now that's not to say that we should all be screaming for this - but if people didn't really understand what was possible, then how could they ask for it? -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: exposing controls in sysfs
On Tue, 6 Apr 2010, Markus Rechberger wrote: [...] how about security permissions? while you can easily change the permission levels for nodes in /dev you can't do this so easily with sysfs entries. I don't really think this is needed at all some applications will start to use ioctl some other apps might go for sysfs.. this makes the API a little bit whacko This is an excellent point. I should have brought this up sooner. The driver has control over the modes of the nodes in sysfs. The driver does NOT have control over the owner / group of those nodes. It is possible to change the owner / group from userspace, and I *think* it's possible to create a udev rule to do this, but honestly I have not investigated this possibility so I don't fully know. This is one serious potential drawback to using sysfs as a driver API. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: exposing controls in sysfs
On Tue, 6 Apr 2010, Laurent Pinchart wrote: Hi Andy, On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: [snip] Again, I still don't know whether we should do this. It is dangerously seductive because it would be so trivial to implement. It's like watching ships run aground on a shallow sandbar that all the locals know about. The waters off of 'Point /sys' are full of usability shipwrecks. I don't know if it's some siren's song, the lack of a light house, or just strange currents that deceive even seasoned navigators Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control metatdata. It's not as easy as typing 'cat', but the user base using sysfs in an interactive shell or shell script should also know how to use v4l2-ctl. In embedded systems, the final system deployment should not need the control metadata available from sysfs in a command shell anyway. I fully agree with this. If we push the idea one step further, why do we need to expose controls in sysfs at all ? I have found it useful to have the sysfs interface within the pvrusb2 driver. If it is going to take a lot of work to specifically craft a sysfs interface that exports the V4L API, then it will probably be a pain to maintain going forward. By a lot of work I mean that each V4L API function would have to be explicitly coded for in this interface, thus as the V4L API evolves over time then extra work must be expended each time to keep the sysfs interface in step. If that is to be the case then it may not be worth it. In the pvrusb2 driver this has not been the case because the code I wrote which implements the sysfs interface for the driver does this programmatically. That is, there is nothing in the pvrusb2-sysfs.c module which is specific to a particular function. Instead, when the module initializes it is able to enumerate the API on its own and generate the appropriate interface for each control it finds. Thus as the pvrusb2 driver's implementation has evolved over time, the sysfs implementation has simply continues to do its job, automatically reflecting internal changes without any extra work in that module's code. I don't know if that same strategy could be done in the V4L core. If it could, then this would probably alleviate a lot of concerns about testing / maintenance going forward. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: exposing controls in sysfs
On Thu, 8 Apr 2010, hermann pitton wrote: Hi, Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch: Am 06.04.2010 16:33, schrieb Mike Isely: [snip] Mike, do you know of anyone actively using that additional information? Yes. The VDR project at one time implemented a plugin to directly interface to the pvrusb2 driver in this manner. I do not know if it is still being used since I don't maintain that plugin. Just FYI: The PVR USB2 device is now handled by the pvrinput-plugin, which uses only ioctls. The old pvrusb2-plugin is obsolete. http://projects.vdr-developer.org/projects/show/plg-pvrinput Lars: Thanks for letting me know about that - until this message I had no idea if VDR was still using that interface. Regards, Lars. [snip] thanks Lars. Mike is really caring and went out for even any most obscure tuner bit to help to improve such stuff in the past, when we have been without any data sheets. Hermann: You might have me confused with Mike Krufky there - he's the one who did so much of the tuner driver overhauling in v4l-dvb in the past. To open second, maybe third and even forth ways for apps to use a device, likely going out of sync soon, does only load maintenance work without real gain. Well it was an experiment at the time to see how well such a concept would work. I had done it in a way to minimize maintenance load going forward. On both counts I feel the interface actually has done very well, nonstandard though it may be. I still get the general impression that the user community really has liked the sysfs interface, but the developers never really got very fond of it :-( We should stay sharp to discover something others don't want to let us know about. All other ideas about markets are illusions. Or? So, debugfs sounds much better than sysfs for my taste. Any app and any driver, going out of sync on the latter, will remind us that backward compat _must always be guaranteed_ ... Or did change anything on that and is sysfs excluded from that rule? Backwards compatibility is very important and thus any kind of new interface deserves a lot of forethought to ensure that choices are made in the present that people will regret in the future. Making an interface self-describing is one way that helps with compatibility: if the app can discover on its own how to use the interface then it can adapt to interface changes in the future. I think a lot of people get their brains so wrapped around the ioctl-way of doing things and then they try to map that concept into a sysfs-like (or debugfs-like) abstraction that they don't see how to naturally take advantage of what is possible there. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: exposing controls in sysfs
On Wed, 7 Apr 2010, Hans Verkuil wrote: [...] Perhaps we should just not do this in sysfs at all but in debugfs? We have a lot more freedom there. No requirement of one-value-per-file, and if we need to we can change things in the future. It would actually be easier to issue ioctl commands to a driver from debugfs since we have a proper struct file there. It could be implemented as a separate module that can be loaded if debugfs is enabled and suddenly you have all this extra debug functionality. I admit, I would really enjoy writing something like this. I just don't want to do this in sysfs as that makes it too 'official' so to speak. In other words, mainline applications should not use sysfs, but home-grown scripts are free to use it as far as I am concerned. How much of a problem would that be for you, Mike? On the one hand users have to mount debugfs, but on the other hand it will be consistent for all drivers that use the control framework. And you should be able to ditch a substantial amount of code :-) Adding a debugfs interface that can be used by all V4L drivers is obviously a concept I would not have any problem with. However that does not necessarily mean that I would agree with eventual removal of the pvrusb2 driver's existing sysfs interface. That would depend on whether or not doing such a thing loses functionality and what the driver's user community would think about it. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
Scan-file for uk-Aberdare
Attached is a working scan file for uk-Aberdare post switchover uk-Aberdare_dso Description: Binary data
Re: [PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
Acked-By: Mike Isely is...@pobox.com
(in the context of the pvrusb2 driver related changes)
-Mike
On Mon, 22 Mar 2010, Wolfram Sang wrote:
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
T {
...
struct device_attribute A;
...
};
@ main extends init @
expression E;
statement S;
identifier err;
T *name;
@@
... when != sysfs_attr_init(name-A.attr);
(
+ sysfs_attr_init(name-A.attr);
if (device_create_file(E, name-A))
S
|
+ sysfs_attr_init(name-A.attr);
err = device_create_file(E, name-A);
)
While reviewing, I put the initialization to apropriate places.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Greg KH gre...@suse.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sujith Thomas sujith.tho...@intel.com
Cc: Matthew Garrett m...@redhat.com
---
The thermal-sys.c-part should fix bugs #15548 and #15584.
drivers/macintosh/windfarm_core.c |1 +
drivers/media/video/pvrusb2/pvrusb2-sysfs.c |8
drivers/platform/x86/intel_menlow.c |1 +
drivers/thermal/thermal_sys.c |1 +
drivers/video/fsl-diu-fb.c |1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/windfarm_core.c
b/drivers/macintosh/windfarm_core.c
index 419795f..f447642 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -209,6 +209,7 @@ int wf_register_control(struct wf_control *new_ct)
kref_init(new_ct-ref);
list_add(new_ct-link, wf_controls);
+ sysfs_attr_init(new_ct-attr.attr);
new_ct-attr.attr.name = new_ct-name;
new_ct-attr.attr.mode = 0644;
new_ct-attr.show = wf_show_control;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 6c23456..71f5056 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -423,10 +423,12 @@ static void pvr2_sysfs_add_debugifc(struct pvr2_sysfs
*sfp)
dip = kzalloc(sizeof(*dip),GFP_KERNEL);
if (!dip) return;
+ sysfs_attr_init(dip-attr_debugcmd.attr);
dip-attr_debugcmd.attr.name = debugcmd;
dip-attr_debugcmd.attr.mode = S_IRUGO|S_IWUSR|S_IWGRP;
dip-attr_debugcmd.show = debugcmd_show;
dip-attr_debugcmd.store = debugcmd_store;
+ sysfs_attr_init(dip-attr_debuginfo.attr);
dip-attr_debuginfo.attr.name = debuginfo;
dip-attr_debuginfo.attr.mode = S_IRUGO;
dip-attr_debuginfo.show = debuginfo_show;
@@ -644,6 +646,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
return;
}
+ sysfs_attr_init(sfp-attr_v4l_minor_number.attr);
sfp-attr_v4l_minor_number.attr.name = v4l_minor_number;
sfp-attr_v4l_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_minor_number.show = v4l_minor_number_show;
@@ -658,6 +661,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_minor_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_v4l_radio_minor_number.attr);
sfp-attr_v4l_radio_minor_number.attr.name = v4l_radio_minor_number;
sfp-attr_v4l_radio_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_radio_minor_number.show = v4l_radio_minor_number_show;
@@ -672,6 +676,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_radio_minor_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_unit_number.attr);
sfp-attr_unit_number.attr.name = unit_number;
sfp-attr_unit_number.attr.mode = S_IRUGO;
sfp-attr_unit_number.show = unit_number_show;
@@ -685,6 +690,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-unit_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_bus_info.attr);
sfp-attr_bus_info.attr.name = bus_info_str;
sfp-attr_bus_info.attr.mode = S_IRUGO;
sfp-attr_bus_info.show = bus_info_show;
@@ -699,6 +705,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-bus_info_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_hdw_name.attr);
sfp-attr_hdw_name.attr.name = device_hardware_type;
sfp-attr_hdw_name.attr.mode = S_IRUGO;
sfp-attr_hdw_name.show = hdw_name_show;
@@ -713,6 +720,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-hdw_name_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_hdw_desc.attr);
sfp-attr_hdw_desc.attr.name = device_hardware_description;
sfp-attr_hdw_desc.attr.mode = S_IRUGO;
sfp-attr_hdw_desc.show = hdw_desc_show
Re: [PATCH 09/11] pvrusb2-v4l2: Rename dev_info to pdi
Acked-By: Mike Isely is...@pobox.com
-Mike
On Mon, 5 Apr 2010, Joe Perches wrote:
There is a macro called dev_info that prints struct device specific
information. Having variables with the same name can be confusing and
prevents conversion of the macro to a function.
Rename the existing dev_info variables to something else in preparation
to converting the dev_info macro to a function.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index cc8ddb2..ba32c91 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -48,7 +48,7 @@ struct pvr2_v4l2_dev {
struct pvr2_v4l2_fh {
struct pvr2_channel channel;
- struct pvr2_v4l2_dev *dev_info;
+ struct pvr2_v4l2_dev *pdi;
enum v4l2_priority prio;
struct pvr2_ioread *rhp;
struct file *file;
@@ -161,7 +161,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_v4l2 *vp = fh-vhead;
- struct pvr2_v4l2_dev *dev_info = fh-dev_info;
+ struct pvr2_v4l2_dev *pdi = fh-pdi;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
long ret = -EINVAL;
@@ -563,14 +563,14 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_STREAMON:
{
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means
that we're not currently allowed to stream from
this node. */
ret = -EPERM;
break;
}
- ret = pvr2_hdw_set_stream_type(hdw,dev_info-config);
+ ret = pvr2_hdw_set_stream_type(hdw,pdi-config);
if (ret 0) return ret;
ret = pvr2_hdw_set_streaming(hdw,!0);
break;
@@ -578,7 +578,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
case VIDIOC_STREAMOFF:
{
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means
that we're not currently allowed to stream from
this node. */
@@ -1031,7 +1031,7 @@ static int pvr2_v4l2_open(struct file *file)
}
init_waitqueue_head(fhp-wait_data);
- fhp-dev_info = dip;
+ fhp-pdi = dip;
pvr2_trace(PVR2_TRACE_STRUCT,Creating pvr_v4l2_fh id=%p,fhp);
pvr2_channel_init(fhp-channel,vp-channel.mc_head);
@@ -1112,7 +1112,7 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
struct pvr2_hdw *hdw;
if (fh-rhp) return 0;
- if (!fh-dev_info-stream) {
+ if (!fh-pdi-stream) {
/* No stream defined for this node. This means that we're
not currently allowed to stream from this node. */
return -EPERM;
@@ -1121,21 +1121,21 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
/* First read() attempt. Try to claim the stream and start
it... */
if ((ret = pvr2_channel_claim_stream(fh-channel,
- fh-dev_info-stream)) != 0) {
+ fh-pdi-stream)) != 0) {
/* Someone else must already have it */
return ret;
}
- fh-rhp = pvr2_channel_create_mpeg_stream(fh-dev_info-stream);
+ fh-rhp = pvr2_channel_create_mpeg_stream(fh-pdi-stream);
if (!fh-rhp) {
pvr2_channel_claim_stream(fh-channel,NULL);
return -ENOMEM;
}
hdw = fh-channel.mc_head-hdw;
- sp = fh-dev_info-stream-stream;
+ sp = fh-pdi-stream-stream;
pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
- pvr2_hdw_set_stream_type(hdw,fh-dev_info-config);
+ pvr2_hdw_set_stream_type(hdw,fh-pdi-config);
if ((ret = pvr2_hdw_set_streaming(hdw,!0)) 0) return ret;
return pvr2_ioread_set_enabled(fh-rhp,!0);
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: Problem with cx25840 and Terratec Grabster AV400
On Sat, 24 Apr 2010, Sven Barth wrote: On 24.04.2010 19:13, Mike Isely wrote: Actually the support in the pvrusb2 driver was never really completed. But since I don't have a sample of the hardware here I went on ahead and merged what was there so that it could get exposure and the remaining problems sorted out. -Mike Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). Unfortunately I can't really say it is supported in the pvrusb2 driver until it actually works well enough that a user doesn't have to hack driver source (pvrusb2 or otherwise). Otherwise I'm just going to get inundated with help requests for this. Not having a sample of the device here I'm handicapped from debugging such issues. I've just made a change to the pvrusb2 driver to allow for the ability to mark a piece of hardware (such as this device) as experimental. Such devices will generate a warning in the kernel log upon initialization. The experimental marker doesn't impact the ability to use the device; it just triggers the warning message. Once we know the device is working acceptably well enough, the marker can be turned off. This should help avoid misleading others about whether or not the pvrusb2 driver fully supports a particular piece of hardware. I wrote the last mail, because I want to sort out why the cx25837 chip in my device is behaving differently than expected by the corresponding driver and to remove the need to patch the v4l sources manually. Once I don't need to fear that the next system update breaks the device again (because cx25840.ko is overwritten), I'm more then willed to help you to complete the support for my device in your driver (feature testing, etc). We definitely need to do this. Regards, Sven PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html Yeah, I saw it back then, and then I probably got distracted away :-( The key issue is that your hardware doesn't seem to work until you make those two changes to the v4l-dvb cx25840 driver. Obviously one can't just make those changes without understanding the implications for other users of the driver. I (or someone expert at the cx25840 module) needs to study that patch and understand what is best to do for the driver. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Problem with cx25840 and Terratec Grabster AV400
On Sat, 24 Apr 2010, Sven Barth wrote: Hi! On 24.04.2010 22:24, Mike Isely wrote: On Sat, 24 Apr 2010, Sven Barth wrote: Hi! Although you never really completed that support for the AV400 it runs pretty well once you've touched the cx25840 source. I'm using it for months now and it runs better than it did with Windows (I sometimes had troubles with audio there which led to an out of sync audio track). Unfortunately I can't really say it is supported in the pvrusb2 driver until it actually works well enough that a user doesn't have to hack driver source (pvrusb2 or otherwise). Otherwise I'm just going to get inundated with help requests for this. Not having a sample of the device here I'm handicapped from debugging such issues. I don't want to have this hacking as much as you do. But currently it's the only way that works for me (I'm really glad that it has come that far ^^)... I'll try to help here as good as I can (and time permits) to solve this issue. I understand. I've just made a change to the pvrusb2 driver to allow for the ability to mark a piece of hardware (such as this device) as experimental. Such devices will generate a warning in the kernel log upon initialization. The experimental marker doesn't impact the ability to use the device; it just triggers the warning message. Once we know the device is working acceptably well enough, the marker can be turned off. This should help avoid misleading others about whether or not the pvrusb2 driver fully supports a particular piece of hardware. No offense intended, but do you really think that people will read that? Normal users (using Ubuntu, etc) don't really care whether their device is marked as experimental or not... they just want it to work and thus can go to great lengths to disturb the developers working on their driver... No offense taken. Not a problem. But I felt it was at least important enough for the driver to document this fact. For those who use the device who are capable of attempting some hacking - those people WILL see the message and hopefully that will encourage such folks to contact the author (me) for assistance in further stabilizing the device. The intent wasn't for the flag to be any excuse not to work on it - I just want to leave a marker indicating that the driver is not expected to be fully working (or supported) at this time. PS: Did you read my mail from last December? http://www.isely.net/pipermail/pvrusb2/2009-December/002716.html Yeah, I saw it back then, and then I probably got distracted away :-( I know that problem pretty well. ^^ I was only curious. Spending a lot of time today catching up on stuff like this. Just smoked out two kernel oopses in the driver today as well. The key issue is that your hardware doesn't seem to work until you make those two changes to the v4l-dvb cx25840 driver. Obviously one can't just make those changes without understanding the implications for other users of the driver. I (or someone expert at the cx25840 module) needs to study that patch and understand what is best to do for the driver. -Mike It would be interesting to know why the v4l devs disabled the audio routing for cx2583x chips and whether it was intended that a cx25837 chip gets the same treatment as a e.g. cx25836. I wish I could provide specific information about that :-( And those implications you're talking about is the reason why I wrote here: I want to check whether there is a better or more correct way than to disable those checks (it works here, because I have only that one device that contains a cx2583x chip...). Just a thought: can it be that my chip's audio routing isn't set to the correct value after initialization and thus it needs to be set at least once, while all other chips default to a working routing after initialization? Could be a design mistake done by Terratec... There is no one correct audio routing. And by audio routing I mean the wiring between the chip and the various audio inputs that feed it. The choice for how to route all this is up to the vendor of the device. In many cases there is a common reference design that the vendor starts from, in which case such routing will be more common across devices. But that's just luck really. The cx25840 driver provides an API to things like the pvrusb2 driver to select the proper routing based on that bridge driver's knowledge of the surrounding hardware. This is one of the areas that have to be worked on when porting to a new device. The PVR2_ROUTING_SCHEME_ enumeration in the pvrusb2 driver is part of this. With that all said I haven't looked closely enough at your patch to the cx25840 module so I'm only assuming that we're talking about the same thing here. I have a funny feeling that you're hitting on something else however. I need to look at this more
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-patches
Please from http://linuxtv.org/hg/~mcisely/pvrusb2-patches for the following pvrusb2 driver fixes / improvements: - pvrusb2: Minor debug code fixup - pvrusb2: Fix Gotview hardware support - pvrusb2: Avoid using stack allocated buffers when performing USB I/O - pvrusb2: New feature to mark specific hardware support as experimental - pvrusb2: Fix kernel oops at device unregistration - pvrusb2: Fix missing header include - pvrusb2: Fix USB parent device reference count - pvrusb2: Fix minor internal array allocation - pvrusb2: Fix kernel oops on device tear-down - pvrusb2: Call sysfs_attr_init() appropriately... pvrusb2-devattr.c |1 pvrusb2-devattr.h |5 pvrusb2-hdw.c | 26 + pvrusb2-main.c|4 +-- pvrusb2-sysfs.c | 64 +++--- pvrusb2-v4l2.c| 16 ++--- 6 files changed, 107 insertions(+), 9 deletions(-) These are primarily a collection of stability fixes. Thanks, -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Bug in AMDs V4L2 driver lxv4l2?
: `vsftpd' uses 32-bit capabilities (legacy support in use) [ 565.626822] BUG: unable to handle kernel paging request at 0519e544 [ 565.627024] IP: [cf4bc988] vip_toggle_video_offsets+0x29/0x106 [cimarron] [ 565.627024] *pde = [ 565.627024] Oops: [#1] PREEMPT [ 565.627024] last sysfs file: /sys/class/i2c-adapter/i2c-1/1-004c/temp1_input [ 565.627024] Modules linked in: lxv4l2 cimarron zd1211rw ftdi_sio usbserial lm90 scx200_acb i2c_serial [ 565.627024] [ 565.627024] Pid: 1557, comm: IRQ-11 Not tainted (2.6.29.6-rt24-aldebaran-rt #1) AMD CM-iGLX Geode LX/CS5536 [ 565.627024] EIP: 0060:[cf4bc988] EFLAGS: 00010246 CPU: 0 [ 565.627024] EIP is at vip_toggle_video_offsets+0x29/0x106 [cimarron] [ 565.627024] EAX: EBX: cdb86e24 ECX: cf428000 EDX: ce382c88 [ 565.627024] ESI: cdb86e2c EDI: cdb86e24 EBP: ce382c88 ESP: ce359f28 [ 565.627024] DS: 007b ES: 007b FS: GS: SS: 0068 preempt:0001 [ 565.627024] Process IRQ-11 (pid: 1557, ti=ce359000 task=ce0617f0 task.ti=ce359000) [ 565.627024] Stack: [ 565.627024] cdb86e1c ce38281c cf43d926 cdb86e04 ce382800 0001 [ 565.627024] cf43ebe0 00075a8d 00040d9a 0001 0001 [ 565.627024] ce38281c cdb86e00 00dc9c86 c0393f64 cda15b20 000b c013e758 [ 565.627024] Call Trace: [ 565.627024] [cf43d926] ? lx_capt_resume2+0x199/0x1bd [lxv4l2] [ 565.627024] [cf43ebe0] ? lx_interrupt+0x67d/0x785 [lxv4l2] [ 565.627024] [c013e758] ? handle_IRQ_event+0x83/0x13f [ 565.627024] [c013e9e8] ? thread_simple_irq+0x3a/0x72 [ 565.627024] [c013eac2] ? do_irqd+0xa2/0x24d [ 565.627024] [c013ea20] ? do_irqd+0x0/0x24d [ 565.627024] [c012c5b9] ? kthread+0x36/0x5a [ 565.627024] [c012c583] ? kthread+0x0/0x5a [ 565.627024] [c0102fb3] ? kernel_thread_helper+0x7/0x10 [ 565.627024] Code: 5f c3 56 53 89 c1 8b 9a e4 00 00 00 85 c0 75 33 f6 02 02 8b 0d 60 13 4d cf 8d 73 08 74 0d 8b 44 9a 04 89 41 1c 8b 54 b2 0c eb 0b 8b 44 b2 0c 89 41 1c 8b 54 9a 04 a1 60 13 4d cf 89 50 18 e9 c0 [ 565.627024] EIP: [cf4bc988] vip_toggle_video_offsets+0x29/0x106 [cimarron] SS:ESP 0068:ce359f28 [ 565.627024] CR2: 0519e544 [ 566.207813] ---[ end trace d33f57cfaa8188ac ]--- [ 566.230208] BUG: unable to handle kernel paging request at 0519e544 [ 566.231021] IP: [cf4bc988] vip_toggle_video_offsets+0x29/0x106 [cimarron] [ 566.231021] *pde = [ 566.231021] Oops: [#2] PREEMPT [ 566.231021] last sysfs file: /sys/class/i2c-adapter/i2c-1/1-004c/temp1_input [ 566.231021] Modules linked in: lxv4l2 cimarron zd1211rw ftdi_sio usbserial lm90 scx200_acb i2c_serial [ 566.231021] [ 566.231021] Pid: 1751, comm: fw_singapore Tainted: G D (2.6.29.6-rt24-aldebaran-rt #1) AMD CM-iGLX Geode LX/CS5536 [ 566.231021] EIP: 0060:[cf4bc988] EFLAGS: 00010246 CPU: 0 [ 566.231021] EIP is at vip_toggle_video_offsets+0x29/0x106 [cimarron] [ 566.231021] EAX: EBX: cdb86e24 ECX: cf428000 EDX: ce382c88 [ 566.231021] ESI: cdb86e2c EDI: cdb86e24 EBP: ce382c88 ESP: ce2dee44 [ 566.231021] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 preempt:0001 [ 566.231021] Process fw_singapore (pid: 1751, ti=ce2de000 task=cd8aa030 task.ti=ce2de000) [ 566.231021] Stack: [ 566.231021] cdb86e1c ce38281c cf43d76a cdb86e58 cdb86e00 cdb86e1c ce38281c [ 566.231021] cf4375be 0001 cdb86e04 cdb86e00 0001 bfeae7b0 c044560f cf43c393 [ 566.231021] 0001 ce2def50 ce2def4c cddef740 ce2deea8 000d c0275b89 [ 566.231021] Call Trace: [ 566.231021] [cf43d76a] ? lx_capt_resume+0x108/0x12b [lxv4l2] [ 566.231021] [cf4375be] ? v4l_qbfr+0x72/0x88 [lxv4l2] [ 566.231021] [cf43c393] ? vid_ioctl+0x35c4/0x3d65 [lxv4l2] [ 566.231021] [c0275b89] ? sys_recvfrom+0xb1/0x113 [ 566.231021] [c0275bd9] ? sys_recvfrom+0x101/0x113 [ 566.231021] [c014b731] ? perf_swcounter_event+0xc4/0xeb [ 566.231021] [cf438dcf] ? vid_ioctl+0x0/0x3d65 [lxv4l2] [ 566.231021] [c021cedb] ? v4l2_ioctl+0x31/0x34 [ 566.231021] [c01709d8] ? vfs_ioctl+0x47/0x5d [ 566.231021] [c0170f01] ? do_vfs_ioctl+0x43f/0x47f [ 566.231021] [c0275c04] ? sys_recv+0x19/0x1d [ 566.231021] [c0276003] ? sys_socketcall+0xf2/0x18c [ 566.231021] [c0170f6d] ? sys_ioctl+0x2c/0x42 [ 566.231021] [c0102851] ? syscall_call+0x7/0xb [ 566.231021] Code: 5f c3 56 53 89 c1 8b 9a e4 00 00 00 85 c0 75 33 f6 02 02 8b 0d 60 13 4d cf 8d 73 08 74 0d 8b 44 9a 04 89 41 1c 8b 54 b2 0c eb 0b 8b 44 b2 0c 89 41 1c 8b 54 9a 04 a1 60 13 4d cf 89 50 18 e9 c0 [ 566.231021] EIP: [cf4bc988] vip_toggle_video_offsets+0x29/0x106 [cimarron] SS:ESP 0068:ce2dee44 [ 566.231021] CR2: 0519e544 [ 566.894334] ---[ end trace d33f57cfaa8188ad ]--- -- Sincerely yours, Mike. -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-patches
Mauro: You are reading too much into that comment. I never said it was valid to do what had been done, only that for the longest time this is what the driver did and it never caused a problem that I was made aware of. What I said there was correct, that this is what the driver had been doing in the past, that it's definitely causing a problem now and thus that is why this patch exists. I'd really rather you not mess with my comment. Probably too late however. -Mike On Fri, 21 May 2010, Mauro Carvalho Chehab wrote: Mike Isely wrote: Please from http://linuxtv.org/hg/~mcisely/pvrusb2-patches for the following pvrusb2 driver fixes / improvements: - pvrusb2: Minor debug code fixup - pvrusb2: Fix Gotview hardware support - pvrusb2: Avoid using stack allocated buffers when performing USB I/O Your comment for this patch is wrong: pvrusb2: The pvrusb2 driver has for the longest time used a (tiny) stack allocated buffer for some of its I/O with the hardware. Apparently later kernels don't like this behavior and trap it at run-time, causing nasty complaints to the kernel log. This trivial change fixes the one case in the driver where this had been happening. It were never valid to use stack for DMA, as kernel provides no warranty that the stack would be on a page that can do DMA. In a matter of fact, as most x86 USB drivers accept DMA at the first 3Gb of RAM space, this bug is generally not noticed on i386/x86_64 archs. Yet, if your machine has more than 3Gb, there are some chances that the stack would be at the HIGHMEM area, where DMA is not supported by the processor. As this is a common error, newer kernels have some instrumentation support to warn about such troubles. I'll be fixing the comment. -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-patches
On Fri, 21 May 2010, Mauro Carvalho Chehab wrote: Mike Isely wrote: On Fri, 21 May 2010, Mauro Carvalho Chehab wrote: Mike Isely wrote: Mauro: You are reading too much into that comment. I never said it was valid to do what had been done, only that for the longest time this is what the driver did and it never caused a problem that I was made aware of. What I said there was correct, that this is what the driver had been doing in the past, that it's definitely causing a problem now and thus that is why this patch exists. As I said, this is not right: Apparently later kernels don't like this behavior Mauro: That statement was in reference to the fact that previously the problem had gone undetected, but now later kernels can notice and complain about this, thus later kernels don't like this behavior. We can debate that perhaps the statement can be worded better, but that doesn't make it *wrong*. Calling 2.6.12 kernel as later kernels doesn't seem right to me (that was about the kernel were em28xx driver were introduced). The point when the em28xx driver appeared has nothing to do with this. The point when the kernel started complaining about the use of a stack based USB I/O buffers is the relevant point, which was not back in 2.6.12. I learned of this behavior (that is, receiving warnings about the usage) as being new in the 2.6.34 timeframe, the point when a user pointed out the complaint message in his kernel log; at that time I had not yet tested against that kernel version. It is not later kernels. DMA over stack were never supported. Your driver had a bug that you didn't noticed for long time, probably because nobody reported you this issue, since it appears only on some non-Intel archs and on i386 with more than 3.12 Gb of RAM, and when the stack happens to be after the first 3.12 Gb (with is a somewhat rare condition). I understand your point perfectly that this was never right or valid. In fact, I also understood that point long before you decided to explain it to me here - after all my realization of this problem in the driver is why I wrote the patch in the first place. Absolutely no argument there about the importance of the change. None of that however justifies putting words into an author's mouth, which is effectively what you did by replacing that commit comment. First of all, it is clearly stated at the patch that the description were changed and by whom: [mche...@redhat.com: fix patch description] Second, it is an usual upstream practice to fix descriptions where needed. The patch description is a precious resource for people that are seeking for similar bugs, and for those that are trying to understand some code. So, it is important to not send broken/incomplete comments to kernel, or comments that may have a dubious interpretation. So, subsystem maintainers frequently need to fix comments. Anyway, to end this discussion, I can simply revert the patch from the staging tree, waiting for a new patch from you with a fixed comment. Also, if you prefer, next time, I won't apply any patch from you if I found a bad comment without your ack, even if it means that you'll probably loose a merge window. Leave it as is. What's done is done. Your replaced comment is of course still correct. I would just appreciate some better sensitivity in the future about replacing authors' comments, especially since in this case your interpretation of my original comment was wrong. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-patches
On Fri, 21 May 2010, Mauro Carvalho Chehab wrote: Mike Isely wrote: [snip] The point when the kernel started complaining about the use of a stack based USB I/O buffers is the relevant point, which was not back in 2.6.12. I learned of this behavior (that is, receiving warnings about the usage) as being new in the 2.6.34 timeframe, the point when a user pointed out the complaint message in his kernel log; at that time I had not yet tested against that kernel version. Older kernels also complain if the stack were actually out of the DMA range and you try to program DMA there. Yet, only now we've seen consumer PC's with lots of RAM. One of my test targets is a PC in 32 bit mode with 4GB of RAM; strange then that I've never seen the kernel complain there. The bad buffer has been in the driver for even longer than that and nobody raised the issue to me until about a month ago (the fix was created back then but for other reasons that you already know it didn't become available in -hg until last week). Leave it as is. What's done is done. Your replaced comment is of course still correct. I would just appreciate some better sensitivity in the future about replacing authors' comments, especially since in this case your interpretation of my original comment was wrong. Ok. Thanks. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Subject: Composite input from OnAir Creator - use as security camera
The pvrusb2 driver does not currently support uncompressed video capture. Rather, the data arrives to the application as mpeg2. There are numerous ways to use this data. You can make it work with mplayer for example, but not when mplayer is in pure V4L mode. Rather than repeating it all here, check out the pvrusb2 web site which has a list of various apps and how to make each one work (or why it won't work). The relevant part for you should be here: http://www.isely.net/pvrusb2/usage.html#V4L -Mike On Tue, 25 May 2010, A. F. Cano wrote: Hello, I would like to be able to capture video from a camera connected to the composite video input of an OnAir Creator. I have tried motion, mplayer, kaffeine, mythtv, xawtv and none have worked so far. Hopefully it's something trivial that I'm doing wrong. I am using an up to date Debian Lenny distribution. Months (or even 1+ years) ago, I gave the OnAir Creator a try and had issues with having to hunt down the firmware file. Since I don't get firmware error messages, I presume this issue is no longer relevant, or is it? My previous experience was with Etch, Lenny was installed from scratch, so if the firmware didn't get installed automatically, it isn't in place. This is the kernel used: Linux version 2.6.26-2-686 (Debian 2.6.26-21lenny4) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Tue Mar 9 17:35:51 UTC 2010 It seems the problem is that an ioctl() call is failing. Is this a case of Lenny being too old or is there a more fundamental problem? Do I need to send something to the Creator to get it to start sending? or is this automatic when the applications start? It would be nice to use the Creator inputs (composite for now, but if I could get it to work the S-video input would be even better) for digitizing old analog video tapes, essentially making a video-capture device. o Motion motion would be the ideal application. I have it properly configured and it works with usb web cams, but the quality of the picture is horrible. I have an old NTSC video conferencing camera that has a much better picture, but motion doesn't seem to be able to deal with the OnAir Creator: [1] cap.driver: pvrusb2 [1] cap.card: OnAir Creator Hybrid USB tuner [1] cap.bus_info: usb 4-3 address 11 [1] cap.capabilities=0x01070011 [1] - VIDEO_CAPTURE [1] - VBI_CAPTURE [1] - TUNER [1] - AUDIO [1] - READWRITE [1] VIDIOC_S_FREQUENCY: Numerical result out of range [1] Supported palettes: [1] 0: [1] Unable to find a compatible palette format. [1] ioctl(VIDIOCGMBUF) - Error device does not support memory map [1] V4L capturing using read is deprecated! [1] Motion only supports mmap. [1] Capture error calling vid_start [1] Thread finishing... Is there anything that can be done about this? or is motion a lost cause? o Mplayer $ mplayer -tv input=1:normid=16 tv:// MPlayer dev-SVN-r26940 CPU: Intel(R) Pentium(R) M processor 1400MHz (Family: 6, Model: 9, Stepping: 5) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: OnAir Creator Hybrid USB tuner Tuner cap: Tuner rxs: Capabilites: video capture VBI capture device tuner audio read/write supported norms: 0 = PAL-B/G; 1 = PAL-D/K; 2 = SECAM-B/G; 3 = SECAM-D/K; 4 = PAL-B; 5 = PAL-B1; 6 = PAL-G; 7 = PAL-H; 8 = PAL-I; 9 = PAL-D; 10 = PAL-D1; 11 = PAL-K; 12 = PAL-M; 13 = PAL-N; 14 = PAL-Nc; 15 = PAL-60; 16 = NTSC-M; 17 = NTSC-Mj; 18 = NTSC-443; 19 = NTSC-Mk; 20 = SECAM-B; 21 = SECAM-D; 22 = SECAM-G; 23 = SECAM-H; 24 = SECAM-K; 25 = SECAM-K1; 26 = SECAM-L; 27 = SECAM-LC; inputs: 0 = television; 1 = composite; 2 = s-video; Current input: 1 Current format: unknown (0x0) v4l2: current audio mode is : MONO v4l2: ioctl request buffers failed: Invalid argument v4l2: 0 frames successfully processed, 0 frames dropped. Exiting... (End of file) So in this case, with the input=1 option, it seems that at least I'm getting to the correct input, but overall it also fails. Can mplayer be given other options to make it work? or is this also a lost cause? I have tried with all the NTSC norms: same result. o Kaffeine and MythTV In those two apps, I can't find where to configure it to use the composite input. Plus, they are way too much for what I need, but if I could use MythTV with zone minder as has been mentioned in the MythTV list, it would do nicely. Unfortunately, zone minder
Re: [PATCH 5/17] drivers/media/video/pvrusb2: Add missing mutex_unlock
I looked through my revision history and that bug has been there in the
driver source since at least May 2005, long before it was ever merged
into the kernel. Wow, what a great catch. Thanks!
Acked-By: Mike Isely is...@pobox.com
-Mike
On Wed, 26 May 2010, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Add a mutex_unlock missing on the error path. In the other functions in
the same file the locks and unlocks of this mutex appear to be balanced,
so it would seem that the same should hold in this case.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression E1;
@@
* mutex_lock(E1,...);
+... when != E1
if (...) {
... when != E1
* return ...;
}
...+
* mutex_unlock(E1,...);
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/media/video/pvrusb2/pvrusb2-ioread.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-ioread.c
b/drivers/media/video/pvrusb2/pvrusb2-ioread.c
index b482478..bba6115 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-ioread.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-ioread.c
@@ -223,7 +223,10 @@ int pvr2_ioread_setup(struct pvr2_ioread *cp,struct
pvr2_stream *sp)
pvr2_ioread_setup (setup) id=%p,cp);
pvr2_stream_kill(sp);
ret = pvr2_stream_set_buffer_count(sp,BUFFER_COUNT);
- if (ret 0) return ret;
+ if (ret 0) {
+ mutex_unlock(cp-mutex);
+ return ret;
+ }
for (idx = 0; idx BUFFER_COUNT; idx++) {
bp = pvr2_stream_get_buffer(sp,idx);
pvr2_buffer_set_buffer(bp,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: What ever happened to standardizing signal level?
On Saturday 29 May 2010 14:45:40 Konstantin Dimitrov wrote: at least in driver for the frontend found on TBS 6980 Dual DVB-S2 card i added options esno and dbm respectively for reporting SNR (actually C/N) in EsNo dB and signal strength in dBm, which is at least real statistics about the signal and not like almost meaningless percents. so, that's one way to go. some DVB-S/S2 demodulators use EsNo dB and other EbNo dB and so maybe step toward some standardization is routines for conversion between those two. also, maybe there will be common agreement how to convert signal strength in dBm to percents and SNR (C/N) in EsNo or EbNo dB to percents. i believe that will guarantee more standard way to give information about the signal, but it's just my opinion. On Sat, May 29, 2010 at 6:09 AM, VDR User user@gmail.com wrote: A lot of people were anticipating this happening but it seems to have stalled out. Does anyone know what the intentions are? Many users were also hoping to _finally_ get a good signal meter for linux as well. If anyone has any info, please share! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send 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 i think someone is too concerned about being precisely accurate. So much so that no-one can see the woods for the trees any more. Its not important to me that accuracy is spot on. I only want to know that when tuning the dish I'm getting \better or worse. A mate has fixed this locally. So will we get a plethora of patches all trying to do the same thing. Mike -- 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:v4l-dvb/other] V4L/DVB: drivers/media/video/pvrusb2: Add missing mutex_unlock
On Sat, 3 Jul 2010, Douglas Schilling Landgraf wrote: Hello Mike, Mike Isely wrote: Mauro: FYI, I posted an Acked-By: Mike Isely is...@pobox.com weeks ago, back on 27-May, immediately after the patch was posted. It's a great catch, and the bug has been there since basically the beginning of the driver. Was I ever supposed to see any kind of reaction to that ack (e.g. having the Acked-By added to the patch)? I had posted it in reply to the original patch, copied back to the patch author, to lkml, to linux-media, kernel-janitors, and Mauro. -Mike It seems my mistake since I have added CC instead of Acked-by, sorry. This happened because usually I add CC to the authors of drivers when I took patches from patchwork and I wanna notify them. In your case, I missed the acked-by. Mauro, if possible, could you please replace CC to the correct Acked-by before submit this patch to Linus? Hmm, going through my old e-mail now I can see that the patch was picked up for -mm on 1-Jun. At that time I was marked as a CC: for the patch - which I'd expect as the driver maintainer. But no Acked-By: was showing. Maybe that's when the ack got missed. Obviously I have no issue with this patch. My only real concern is that nobody thinks I might have been ignoring it. Thanks for following up. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Status of the patches under review at LMML (60 patches)
On Wed, 7 Jul 2010, Sven Barth wrote: Hi! Am 06.07.2010 15:06, schrieb Mauro Carvalho Chehab: == Waiting for Mike Iselyis...@isely.net review == Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400 http://patchwork.kernel.org/patch/94960 Is Mike really the maintainer of the cx25840 module and not only of the pvrusb2 one? If he's not the maintainer you should contact the real one, cause I don't think that Mike can help much regarding patches for the cx25840 in that case. Also I might need to adjust the patch cause of the recent changes that happened there the last few months. (I don't know when I'll find time for this...) Regards, Sven No I am definitely not the maintainer of that module, and my knowledge of its inner workings (though improved a lot lately) is still not very good. All I can do here is verify that it doesn't break the pvrusb2 driver (which is what I was planning on doing). -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Status of the patches under review at LMML (60 patches)
On Tue, 6 Jul 2010, Mauro Carvalho Chehab wrote:
This is the summary of the patches that are currently under review at
Linux Media Mailing List linux-media@vger.kernel.org.
Each patch is represented by its submission date, the subject (up to 70
chars) and the patchwork link (if submitted via email).
P.S.: This email is c/c to the developers where some action is expected.
If you were copied, please review the patches, acking/nacking or
submitting an update.
[...]
== Waiting for Mike Isely is...@isely.net review ==
Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400
http://patchwork.kernel.org/patch/94960
These are cx25840 patches and I'm not the maintainer of that module. I
can't really speak to the correctness of the changes. Best I can do is
to try the patch with a few pvrusb2-driven devices here that use the
cx25840 module. I've done that now (HVR-1950 and PVR-USB2 model 24012)
and everything continues to work fine. Note, this part of the patch:
int hw_fix = state-pvr150_workaround;
-
- if (std == V4L2_STD_NTSC_M_JP) {
+ if (std == V4L2_STD_NTSC_M_JP) {
/* Japan uses EIAJ audio standard */
cx25840_write(client, 0x808, hw_fix ? 0x2f : 0xf7);
} else if (std == V4L2_STD_NTSC_M_KR) {
is a whitespace-only change which introduces a bogus tab and messes up
the indentation of that opening if-statement. It should probably be
removed from the patch. Other than that, you have my ack:
Acked-By: Mike Isely is...@pobox.com
-Mike
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: Fw: [PATCH] v4l/dvb: remove err macro from few usb devices
Why is this change needed? (Please point me at a discussion thread, if
you'd like...)
-Mike
On Thu, 8 Jan 2009, Mauro Carvalho Chehab wrote:
Alexey,
You should get the driver maintainer's ack or at least let them know that
you're touching on their drivers.
Mike, Thierry an Dean,
Could you please review this patch?
Cheers,
Mauro.
Forwarded message:
Date: Thu, 01 Jan 2009 11:06:08 +0300
From: Alexey Klimov klimov.li...@gmail.com
To: Mauro Carvalho Chehab mche...@infradead.org
Cc: video4linux-l...@redhat.com, Greg KH g...@kroah.com
Subject: [PATCH] v4l/dvb: remove err macro from few usb devices
Hello all
I re-send this patch. Previous time i sent i get no response.
Please nack, apply or criticize :)
--
Patch removes err() macros from few usb devices.
It places pr_err in pvrusb2-v4l2.c, dev_err in dabusb and in usbvision
drivers. Beside placing dev_err, patch defines new s2255_dev_err macro
with S2255_DRIVER_NAME in s2255 module.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
diff -r 6a189bc8f115 linux/drivers/media/video/dabusb.c
--- a/linux/drivers/media/video/dabusb.c Wed Dec 31 15:26:57 2008 -0200
+++ b/linux/drivers/media/video/dabusb.c Thu Jan 01 10:59:06 2009 +0300
@@ -199,17 +199,20 @@
dst += len;
}
else
- err(dabusb_iso_complete: invalid len
%d, len);
+ dev_err(purb-dev-dev,
+ dabusb_iso_complete: invalid
len %d\n, len);
}
else
dev_warn(purb-dev-dev, dabusb_iso_complete:
corrupted packet status: %d\n, purb-iso_frame_desc[i].status);
if (dst != purb-actual_length)
- err(dst!=purb-actual_length:%d!=%d, dst,
purb-actual_length);
+ dev_err(purb-dev-dev,
+ dst!=purb-actual_length:%d!=%d\n,
+ dst, purb-actual_length);
}
if (atomic_dec_and_test (s-pending_io) !s-remove_pending
s-state != _stopped) {
s-overruns++;
- err(overrun (%d), s-overruns);
+ dev_err(purb-dev-dev, overrun (%d)\n, s-overruns);
}
wake_up (s-wait);
}
@@ -230,13 +233,14 @@
while (transfer_len (s-total_buffer_size 10)) {
b = kzalloc(sizeof (buff_t), GFP_KERNEL);
if (!b) {
- err(kzalloc(sizeof(buff_t))==NULL);
+ dev_err(s-usbdev-dev,
+ kzalloc(sizeof(buff_t))==NULL\n);
goto err;
}
b-s = s;
b-purb = usb_alloc_urb(packets, GFP_KERNEL);
if (!b-purb) {
- err(usb_alloc_urb == NULL);
+ dev_err(s-usbdev-dev, usb_alloc_urb == NULL\n);
kfree (b);
goto err;
}
@@ -245,7 +249,8 @@
if (!b-purb-transfer_buffer) {
kfree (b-purb);
kfree (b);
- err(kmalloc(%d)==NULL, transfer_buffer_length);
+ dev_err(s-usbdev-dev,
+ kmalloc(%d)==NULL\n, transfer_buffer_length);
goto err;
}
@@ -289,10 +294,11 @@
ret=usb_bulk_msg(s-usbdev, pipe, pb-data, pb-size, actual_length,
100);
if(ret0) {
- err(dabusb: usb_bulk_msg failed(%d),ret);
+ dev_err(s-usbdev-dev,
+ usb_bulk_msg failed(%d)\n, ret);
if (usb_set_interface (s-usbdev, _DABUSB_IF, 1) 0) {
- err(set_interface failed);
+ dev_err(s-usbdev-dev, set_interface failed\n);
return -EINVAL;
}
@@ -301,7 +307,7 @@
if( ret == -EPIPE ) {
dev_warn(s-usbdev-dev, CLEAR_FEATURE request to remove
STALL condition.\n);
if(usb_clear_halt(s-usbdev, usb_pipeendpoint(pipe)))
- err(request failed);
+ dev_err(s-usbdev-dev, request failed\n);
}
pb-size = actual_length;
@@ -319,7 +325,8 @@
unsigned char *transfer_buffer = kmalloc (len, GFP_KERNEL);
if (!transfer_buffer) {
- err(dabusb_writemem: kmalloc(%d) failed., len);
+ dev_err(s-usbdev-dev,
+ dabusb_writemem: kmalloc(%d) failed.\n, len);
return -ENOMEM;
}
@@ -352,7 +359,8 @@
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,27)
ret = request_ihex_firmware(fw, dabusb/firmware.fw, s-usbdev-dev);
if (ret) {
- err(Failed to load \dabusb/firmware.fw\: %d\n, ret);
+ dev_err
Re: USB: change interface to usb_lock_device_for_reset()
On Thu, 8 Jan 2009, Mauro Carvalho Chehab wrote:
Hi Mike,
There were an upstream change usb_lock_device_for_reset() that touched on
pvrusb2 driver. I didn't backport it yet, since I'm not sure if the change is
ok. Could you please check?
Thanks,
Mauro.
Yes, the pvrusb2 part of this change looks fine (just change the
treatment of the return code).
Acked-By: Mike Isely is...@pobox.com
I expect this weekend to be working through a backlog of pvrusb2 issues
so you might hear more from me soon :-)
-Mike
commit 011b15df465745474e3ec85482633685933ed5a7
Author: Alan Stern st...@rowland.harvard.edu
Date: Tue Nov 4 11:29:27 2008 -0500
USB: change interface to usb_lock_device_for_reset()
This patch (as1161) changes the interface to
usb_lock_device_for_reset(). The existing interface is apparently not
very clear, judging from the fact that several of its callers don't
use it correctly. The new interface always returns 0 for success and
it always requires the caller to unlock the device afterward.
The new routine will not return immediately if it is called while the
driver's probe method is running. Instead it will wait until the
probe is over and the device has been unlocked. This shouldn't cause
any problems; I don't know of any cases where drivers call
usb_lock_device_for_reset() during probe.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Cc: Pete Zaitcev zait...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
diff --git a/drivers/block/ub.c b/drivers/block/ub.c
index 048d71d..12fb816 100644
--- a/drivers/block/ub.c
+++ b/drivers/block/ub.c
@@ -1579,7 +1579,7 @@ static void ub_reset_task(struct work_struct *work)
struct ub_dev *sc = container_of(work, struct ub_dev, reset_work);
unsigned long flags;
struct ub_lun *lun;
- int lkr, rc;
+ int rc;
if (!sc-reset) {
printk(KERN_WARNING %s: Running reset unrequested\n,
@@ -1597,10 +1597,11 @@ static void ub_reset_task(struct work_struct *work)
} else if (sc-dev-actconfig-desc.bNumInterfaces != 1) {
;
} else {
- if ((lkr = usb_lock_device_for_reset(sc-dev, sc-intf)) 0) {
+ rc = usb_lock_device_for_reset(sc-dev, sc-intf);
+ if (rc 0) {
printk(KERN_NOTICE
%s: usb_lock_device_for_reset failed (%d)\n,
- sc-name, lkr);
+ sc-name, rc);
} else {
rc = usb_reset_device(sc-dev);
if (rc 0) {
@@ -1608,9 +1609,7 @@ static void ub_reset_task(struct work_struct *work)
usb_lock_device_for_reset failed (%d)\n,
sc-name, rc);
}
-
- if (lkr)
- usb_unlock_device(sc-dev);
+ usb_unlock_device(sc-dev);
}
}
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 03cb494..f0a0f72 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -102,7 +102,7 @@ static void hid_reset(struct work_struct *work)
struct usbhid_device *usbhid =
container_of(work, struct usbhid_device, reset_work);
struct hid_device *hid = usbhid-hid;
- int rc_lock, rc = 0;
+ int rc = 0;
if (test_bit(HID_CLEAR_HALT, usbhid-iofl)) {
dev_dbg(usbhid-intf-dev, clear halt\n);
@@ -113,11 +113,10 @@ static void hid_reset(struct work_struct *work)
else if (test_bit(HID_RESET_PENDING, usbhid-iofl)) {
dev_dbg(usbhid-intf-dev, resetting device\n);
- rc = rc_lock = usb_lock_device_for_reset(hid_to_usb_dev(hid),
usbhid-intf);
- if (rc_lock = 0) {
+ rc = usb_lock_device_for_reset(hid_to_usb_dev(hid),
usbhid-intf);
+ if (rc == 0) {
rc = usb_reset_device(hid_to_usb_dev(hid));
- if (rc_lock)
- usb_unlock_device(hid_to_usb_dev(hid));
+ usb_unlock_device(hid_to_usb_dev(hid));
}
clear_bit(HID_RESET_PENDING, usbhid-iofl);
}
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index 8fb92ac..fa304e5 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -3655,7 +3655,7 @@ void pvr2_hdw_device_reset(struct pvr2_hdw *hdw)
int ret;
pvr2_trace(PVR2_TRACE_INIT,Performing a device reset...);
ret = usb_lock_device_for_reset(hdw-usb_dev,NULL);
- if (ret == 1) {
+ if (ret == 0) {
ret = usb_reset_device(hdw-usb_dev);
usb_unlock_device(hdw-usb_dev
Re: USB: change interface to usb_lock_device_for_reset()
On Fri, 9 Jan 2009, Mauro Carvalho Chehab wrote: On Thu, 8 Jan 2009 22:28:18 -0600 (CST) Mike Isely is...@isely.net wrote: On Thu, 8 Jan 2009, Mike Isely wrote: On Thu, 8 Jan 2009, Mauro Carvalho Chehab wrote: Hi Mike, There were an upstream change usb_lock_device_for_reset() that touched on pvrusb2 driver. I didn't backport it yet, since I'm not sure if the change is ok. Could you please check? Thanks, Mauro. Yes, the pvrusb2 part of this change looks fine (just change the treatment of the return code). Before I cause any confusion, the above sentence has a critical typo. I was just pointing out that the pvrusb2 change in the patch below only adjusts the treatment of the return code, which makes perfect sense given the upstream change. I wasn't asking you to change anything :-) The change is fine. Ok. The backport of this patch would be something interesting... It will be something like this: #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,29) if (ret == 0) #else if (ret == 1) #endif Yeah, I know. It's part of the fun of staying in sync with multiple kernels and their ever-changing internal interfaces. I have to support this in the standalone pvrusb2 driver too. One more task this weekend... -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Wed, 14 Jan 2009, Mike Isely wrote: On Wed, 14 Jan 2009, Mauro Carvalho Chehab wrote: [...] I can see some troubles here: 1) The bus info helps to identify the place where you'll find the device info at sysfs; 2) This is a V4L2 API non-compliance. All drivers should be compliant with the API; 3) If we all agree that bus_info doesn't matter at all and decide to change V4L2 API, we'll still have a big trouble: most devices don't have a serial number. The other patches are ok. I was asked to make this change, because otherwise there's no means via the V4L interface to uniquely REPEATABLY be able to identify the same device each time it is plugged in. I have gotten complaints about this. I actually pointed out that bus_info was about the where not the what of the device, but I was convinced to change this - after being surprised that the V4L spec allowed for this. Look at the online v4l spec; the following description exists about bus_info (as part of the VIDIOC_QUERYCAP description): [...] Mauro: If you still don't like this specific changeset, then OK, but I'd still appreciate it if you could pull the other changes (especially the v4l2_subdev fix). And I'd appreciate some suggestions from anyone about a means via the V4L interface to make available a device-specific identifier, like a serial number. Yes I know such a thing is not always available with all devices, but it is available for Hauppauge devices in general and users want to have access to that information for purposes of mapping behavior in userspace. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
The pvrusb2 stuff you just pulled
Mauro: Do you not find it strange that you show up as the credited source for my recent changesets on the summary page http://linuxtv.org/hg/v4l-dvb? (See 10236 - 10240.) I suspect it's because you cherry picked them, but that doesn't make it right. I could have sworn in the past that I've been able to pull in changes / contributions into hg from other pvrusb2 users and successfully preserved the credit in the change list summary. What's the problem here? -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: OK. Well, the usage he wants is something that is better fitted by using sysfs info. There, you should have all information to uniquely identify a device: driver, bus location (on PCI this can be relevant), MAC (for dvb devices), etc. IMO, the proper way is to add the serial number at sysfs, and let the bus_info point to the proper bus location. Having the bus location, an userspace app can seek the sysfs and look for the udev info. For example, on an em28xx analog device I have here, bus_info returns 1-3. Ok, this is a very bad way to specify the bus. IMO, we should use usb_make_path() to generate the canonical name for USB buses. I will review what the pvrusb2 driver is doing and change it to use usb_make_path() if needed. However given all the other information about the device that querycap returns, a serial number in that batch would be right at home there. Requiring an app to go through everything you described is a pretty complex process for what should be very simple datum. In any case, right now the serial number in the pvrusb2 is not available through that means because I haven't done anything to make it available to udev. I'd like to do something, but so far I have found no information on how to make that happen. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] Cross-posting linux-media, linux-dvb etc
On Fri, 16 Jan 2009, Hans Verkuil wrote: On Friday 16 January 2009 15:48:45 Patrick Boettcher wrote: Hi Mauro, Since the creation of linux-media@vger.kernel.org I'm seeing lots of cross-postings between linux-dvb, linux-media and video4linux. This is a little bit annoying if you are subscribed to all of those lists. Worse is, that some people only send requests to linux-media. Like that linux-dvb-only subscribers can't help... Why not closing linux-dvb (and video4linux) and transferring the currently subscribed users to linux-media automatically? I agree with Patrick. I suggest a daily automatic posting to linux-dvb and video4linux telling people that on February 1st these lists disappear and that they should use linux-media instead. Then they can be closed down at the end of the month. I definitely wouldn't wait any longer since it is rather messy right now. One month transition period seems reasonable to me. Amen to that. I've been telling people to go over to linux-media, but old habits are hard to break. It's time to actually make a clean break from the old lists. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Fri, 16 Jan 2009, Janne Grunau wrote:
On Friday 16 January 2009 15:39:33 Mike Isely wrote:
In any case, right now the serial number in the pvrusb2 is not available
through that means because I haven't done anything to make it available
to udev. I'd like to do something, but so far I have found no
information on how to make that happen.
You shouldn't need to do anything special. The serial number is available
through the parent USB device. It can be used for udev rules through
ATTRS{serial} and in sysfs entry of the video device through device/serial.
Ah yes!
What I said before was right in its own context, but now I see something
else.
The serial number that the pvrusb2 driver itself knows about is parsed
out of Hauppauge private data by the tveeprom module from the device's
internal I2C ROM. This data is formatted in a packetized way that is
specific to Hauppauge. What I was refering to was *that* serial number,
and since it's in the private ROM I saw no means for udev to know about
it.
However I just tested with two 24xxx devices using usbview, and the same
serial number is in fact visible in the USB configuration data.
There's simply no way for the USB core in Linux to be able to directly
know about, get at, or even understand that internal ROM. Yet there it
is. I'm thinking now that perhaps the FX2 microcontroller is either
parsing out the data itself during initialization and then writing out
the USB configuration accordingly, or the serial number is in fact
written in two places within the device! Up until now, I had not seen
any evidence to suggest that the FX2 firmware ever actually read the
nearby ROM on its own. But that could be what is happening here.
Thanks for pointing that out. These devices still surprise me.
For anyone looking at this, the serial number in the USB configuration
data for the device is just a hex-formatted version of the same value
that you can see via the pvrusb2 driver's sysfs interface.
-Mike
--
Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-pull
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-pull for the following: - pvrusb2: Use usb_make_path() to determine device bus location pvrusb2-hdw.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) This is the usb_make_path() change that's been talked about. Hopefully you'll see this as a real live actual pull request in spite of the subject line having been thoroughly spoiled / thrashed over the past week due to all the subsequent discussion from the last pull request :-) Note also that the pull location is slightly different than what I usually use. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: POLL: for/against dropping support for kernels 2.6.22
On Sun, 22 Feb 2009, Hans Verkuil wrote: Hi all, There are lot's of discussions, but it can be hard sometimes to actually determine someone's opinion. So here is a quick poll, please reply either to the list or directly to me with your yes/no answer and (optional but welcome) a short explanation to your standpoint. It doesn't matter if you are a user or developer, I'd like to see your opinion regardless. Please DO NOT reply to the replies, I'll summarize the results in a week's time and then we can discuss it further. Should we drop support for kernels 2.6.22 in our v4l-dvb repository? _: Yes _: No Yes (see below) Optional question: Why: I'm always for backwards compatibility in general. I have an out-of-tree standalone pvrusb2 driver which includes extra stuff that at least compiles correctly all the way back to 2.6.12 (extra - but old - i2c modules are also included with the driver for kernels of that vintage). However, that's just my one driver and I think trying to maintain that sort of (in)sanity over the entire v4l-dvb tree is going to be a major morale-sucking headache. I'm working right now on v4l2-subdev support and it's my intention that I will be ripping out all the old I2C adaptation stuff as part of this effort. (I am actually going to at least try to make the old stuff still work as a compile-time switch in the standalone pvrusb2 driver but I don't realistically expect that to remain practical with the driver as it currently resides in v4l-dvb.) So even if the decision is made to keep v4l-dvb as a whole compatible all the way back to 2.6.16, the pvrusb2 driver will still in the end have to be excluded in v4l-dvb builds for anything older than 2.6.22. I really can't vote no above with a straight face while doing this v4l2-subdev related work in the driver. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sat, 14 Mar 2009, Hans Verkuil wrote: On Saturday 14 March 2009 17:13:27 Mike Isely wrote: On Sat, 14 Mar 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect Any chance this is going to get into 2.6.29? I need to know. No, this won't go to 2.6.29. None of the drivers in 2.6.29 using this framework are USB drivers, so it's not needed there. I was going to configure the standalone version of the pvrusb2 driver to use the new framework for 2.6.29. That's why I needed to know. So I'll either configure the driver to not do this until it is built under 2.6.30 or just continue poking the structure directly for 2.6.29. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: On Tue, 24 Mar 2009 23:07:02 -0500 (CDT) Mike Isely is...@isely.net wrote: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for a large collection of pvrusb2 changesets (see below). You forgot to add pvrusb2-cs53l32a.o on your Makefile. I'll add it and merge with the correspond patch that added this patch, to avoid bisect breakage. Damn. Sorry about that. Usually I *do* catch things like that :-( Thanks for spotting and fixing it. There might be another problem - I did test compile and run all this from within v4l-dvb. With that file missing it should not have loaded correctly, which means I must have missed something else too. I will double check this. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB - attach to an open frontend device
Not too sure if this is possible but what I want to do is this open frontend set frequency add demux filters etc record then while this is running I want to attach to the same process and add further demux filters (without retuning - same frequency) any tips? -- 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
Compusa VC-211A no video
I'm having a tough time getting a Compusa VC-211A USB video grabber working under Fedora 16 on a Dell E521. [root@shellder ~]# uname -a Linux shellder.falciani.com 3.1.9-1.fc16.i686 #1 SMP Fri Jan 13 17:14:41 UTC 2012 i686 i686 i386 GNU/Linux Jan 22 15:15:44 shellder kernel: [59072.105044] usb 1-7: new high speed USB device number 5 using ehci_hcd Jan 22 15:15:44 shellder kernel: [59072.220074] usb 1-7: New USB device found, idVendor=eb1a, idProduct=2820 Jan 22 15:15:44 shellder kernel: [59072.220081] usb 1-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Jan 22 15:15:44 shellder kernel: [59072.220656] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) Jan 22 15:15:44 shellder kernel: [59072.220815] em28xx #0: chip ID is em2820 (or em2710) Jan 22 15:15:44 shellder kernel: [59072.290926] em28xx #0: board has no eeprom Jan 22 15:15:44 shellder kernel: [59072.337170] em28xx #0: found i2c device @ 0x4a [saa7113h] Jan 22 15:15:44 shellder kernel: [59072.370919] em28xx #0: Your board has no unique USB ID. Jan 22 15:15:44 shellder kernel: [59072.370924] em28xx #0: A hint were successfully done, based on i2c devicelist hash. Jan 22 15:15:44 shellder kernel: [59072.370929] em28xx #0: This method is not 100% failproof. Jan 22 15:15:44 shellder kernel: [59072.370934] em28xx #0: If the board were missdetected, please email this log to: Jan 22 15:15:44 shellder kernel: [59072.370938] em28xx #0: V4L Mailing List linux-media@vger.kernel.org Jan 22 15:15:44 shellder kernel: [59072.370943] em28xx #0: Board detected as EM2860/SAA711X Reference Design Jan 22 15:15:44 shellder kernel: [59072.434031] em28xx #0: Identified as EM2860/SAA711X Reference Design (card=19) Jan 22 15:15:44 shellder kernel: [59072.434037] em28xx #0: Registering snapshot button... Jan 22 15:15:44 shellder kernel: [59072.434165] input: em28xx snapshot button as /devices/pci:00/:00:0b.1/usb1/1-7/input/input17 Jan 22 15:15:44 shellder kernel: [59072.701150] saa7115 6-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) Jan 22 15:15:45 shellder kernel: [59073.146869] em28xx #0: Config register raw data: 0x00 Jan 22 15:15:45 shellder kernel: [59073.173739] em28xx #0: v4l2 driver version 0.1.3 Jan 22 15:15:45 shellder kernel: [59073.427419] em28xx #0: V4L2 video device registered as video0 Jan 22 15:15:45 shellder mtp-probe: checking bus 1, device 5: /sys/devices/pci:00/:00:0b.1/usb1/1-7 Jan 22 15:15:45 shellder mtp-probe: bus: 1, device: 5 was not an MTP device UCView and VLC: No video to be captured lsusb (at a later date) Bus 001 Device 005: ID eb1a:2820 eMPIA Technology, Inc. I've tried: modprobe -r em28xx modprobe em28xx card=74 Results: No video UCview modprobe -r em28xx modprobe em28xx card=5 Results: No video UCview modprobe -r em28xx modprobe em28xx card=1 Results: No video UCview Any ideas? I had great hope in the card=74 until I saw that it expected a EM2800 and this seems to be a EM2820. Also, the device looks a lot like this but is marked differently http://www.cooldrives.com/usb-video-vcr-camcorder-analog-video-svideo-adapter.html Any idea on how to select Composite Video input? Thanks -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Falciani http://nj.falciani.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 v2 1/2] omap3isp: Use the common clock framework
Quoting Laurent Pinchart (2013-04-04 04:51:40)
Expose the two ISP external clocks XCLKA and XCLKB as common clocks for
subdev drivers.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Mike Turquette mturque...@linaro.org
Regards,
Mike
---
drivers/media/platform/omap3isp/isp.c | 270
--
drivers/media/platform/omap3isp/isp.h | 22 ++-
include/media/omap3isp.h | 10 +-
3 files changed, 218 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 6e5ad8e..694470d 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -55,6 +55,7 @@
#include asm/cacheflush.h
#include linux/clk.h
+#include linux/clkdev.h
#include linux/delay.h
#include linux/device.h
#include linux/dma-mapping.h
@@ -148,6 +149,194 @@ void omap3isp_flush(struct isp_device *isp)
isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_REVISION);
}
+/*
-
+ * XCLK
+ */
+
+#define to_isp_xclk(_hw) container_of(_hw, struct isp_xclk, hw)
+
+static void isp_xclk_update(struct isp_xclk *xclk, u32 divider)
+{
+ switch (xclk-id) {
+ case ISP_XCLK_A:
+ isp_reg_clr_set(xclk-isp, OMAP3_ISP_IOMEM_MAIN,
ISP_TCTRL_CTRL,
+ ISPTCTRL_CTRL_DIVA_MASK,
+ divider ISPTCTRL_CTRL_DIVA_SHIFT);
+ break;
+ case ISP_XCLK_B:
+ isp_reg_clr_set(xclk-isp, OMAP3_ISP_IOMEM_MAIN,
ISP_TCTRL_CTRL,
+ ISPTCTRL_CTRL_DIVB_MASK,
+ divider ISPTCTRL_CTRL_DIVB_SHIFT);
+ break;
+ }
+}
+
+static int isp_xclk_prepare(struct clk_hw *hw)
+{
+ struct isp_xclk *xclk = to_isp_xclk(hw);
+
+ omap3isp_get(xclk-isp);
+
+ return 0;
+}
+
+static void isp_xclk_unprepare(struct clk_hw *hw)
+{
+ struct isp_xclk *xclk = to_isp_xclk(hw);
+
+ omap3isp_put(xclk-isp);
+}
+
+static int isp_xclk_enable(struct clk_hw *hw)
+{
+ struct isp_xclk *xclk = to_isp_xclk(hw);
+ unsigned long flags;
+
+ spin_lock_irqsave(xclk-lock, flags);
+ isp_xclk_update(xclk, xclk-divider);
+ xclk-enabled = true;
+ spin_unlock_irqrestore(xclk-lock, flags);
+
+ return 0;
+}
+
+static void isp_xclk_disable(struct clk_hw *hw)
+{
+ struct isp_xclk *xclk = to_isp_xclk(hw);
+ unsigned long flags;
+
+ spin_lock_irqsave(xclk-lock, flags);
+ isp_xclk_update(xclk, 0);
+ xclk-enabled = false;
+ spin_unlock_irqrestore(xclk-lock, flags);
+}
+
+static unsigned long isp_xclk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct isp_xclk *xclk = to_isp_xclk(hw);
+
+ return parent_rate / xclk-divider;
+}
+
+static u32 isp_xclk_calc_divider(unsigned long *rate, unsigned long
parent_rate)
+{
+ u32 divider;
+
+ if (*rate = parent_rate) {
+ *rate = parent_rate;
+ return ISPTCTRL_CTRL_DIV_BYPASS;
+ }
+
+ divider = DIV_ROUND_CLOSEST(parent_rate, *rate);
+ if (divider = ISPTCTRL_CTRL_DIV_BYPASS)
+ divider = ISPTCTRL_CTRL_DIV_BYPASS - 1;
+
+ *rate = parent_rate / divider;
+ return divider;
+}
+
+static long isp_xclk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ isp_xclk_calc_divider(rate, *parent_rate);
+ return rate;
+}
+
+static int isp_xclk_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long parent_rate)
+{
+ struct isp_xclk *xclk = to_isp_xclk(hw);
+ unsigned long flags;
+ u32 divider;
+
+ divider = isp_xclk_calc_divider(rate, parent_rate);
+
+ spin_lock_irqsave(xclk-lock, flags);
+
+ xclk-divider = divider;
+ if (xclk-enabled)
+ isp_xclk_update(xclk, divider);
+
+ spin_unlock_irqrestore(xclk-lock, flags);
+
+ dev_dbg(xclk-isp-dev, %s: cam_xclk%c set to %lu Hz (div %u)\n,
+ __func__, xclk-id == ISP_XCLK_A ? 'a' : 'b', rate, divider);
+ return 0;
+}
+
+static const struct clk_ops isp_xclk_ops = {
+ .prepare = isp_xclk_prepare,
+ .unprepare = isp_xclk_unprepare,
+ .enable = isp_xclk_enable,
+ .disable = isp_xclk_disable,
+ .recalc_rate = isp_xclk_recalc_rate,
+ .round_rate = isp_xclk_round_rate,
+ .set_rate = isp_xclk_set_rate,
+};
+
+static const char *isp_xclk_parent_name = cam_mclk;
+
+static int isp_xclk_init(struct isp_device *isp)
+{
+ struct isp_platform_data *pdata = isp-pdata;
+ unsigned int i
Re: [PATCH v8 1/7] media: V4L2: add temporary clock helpers
Quoting Barry Song (2013-04-11 01:59:28) 2013/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Thu, 11 Apr 2013, Barry Song wrote: 2013/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Barry On Thu, 11 Apr 2013, Barry Song wrote: Hi Guennadi, Typical video devices like camera sensors require an external clock source. Many such devices cannot even access their hardware registers without a running clock. These clock sources should be controlled by their consumers. This should be performed, using the generic clock framework. Unfortunately so far only very few systems have been ported to that framework. This patch adds a set of temporary helpers, mimicking the generic clock API, to V4L2. Platforms, adopting the clock API, should switch to using it. Eventually this temporary API should be removed. Signed-off-by: Guennadi Liakhovetski g.liakhovetski@xx --- for your patch 1/8 and 3/8, i think it makes a lot of senses to let the object manages its own clock by itself. is it possible for us to implement v4l2-clk.c directly as an instance of standard clk driver for those systems which don't have generic clock, and remove the V4L2 clock APIs like v4l2_clk_get, v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp and fake clock controller driver. finally, after people have generically clk, remove it. I don't think you can force-enable the CFF on systems, that don't support it, e.g. PXA. yes. we can. clock is only a framework, has it any limitation to implement a driver instance on any platform? So, you enable CFF, it provides its own clk_* implementation like clk_get_rate() etc. Now, PXA already has it defined in arch/arm/mach-pxa/clock.c. Don't think this is going to fly. agree. Hi, I came into this thread late and don't have the actual patches in my inbox for review. That said, I don't understand why V4L2 cares about the clk framework *implementation*? The clk.h api is the same for platforms using the common struct clk and those still using the legacy method of defining their own struct clk. If drivers are only consumers of the clk.h api then the implementation underneath should not matter. Regards, Mike Thanks Guennadi people have tried to move to common clk and generic framework for a long time, now you still try to provide a v4l2 specific clock APIs, it just makes v4l2 unacceptable and much complex. Thanks Guennadi v8: Updated both (C) dates drivers/media/v4l2-core/Makefile |2 +- drivers/media/v4l2-core/v4l2-clk.c | 177 include/media/v4l2-clk.h | 54 +++ 3 files changed, 232 insertions(+), 1 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-clk.c create mode 100644 include/media/v4l2-clk.h diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile index aa50c46..628c630 100644 --- a/drivers/media/v4l2-core/Makefile +++ b/drivers/media/v4l2-core/Makefile @@ -5,7 +5,7 @@ tuner-objs := tuner-core.o videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \ - v4l2-event.o v4l2-ctrls.o v4l2-subdev.o + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o ifeq ($(CONFIG_COMPAT),y) videodev-objs += v4l2-compat-ioctl32.o endif diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c new file mode 100644 index 000..d7cc13e --- /dev/null +++ b/drivers/media/v4l2-core/v4l2-clk.c @@ -0,0 +1,177 @@ -barry -barry ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [REVIEWv2 PATCH 07/12] pvrusb2: use v4l2_dev instead of the deprecated parent field.
Acked-By: Mike Isely is...@pobox.com
-Mike
On Wed, 12 Jun 2013, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c |4
drivers/media/usb/pvrusb2/pvrusb2-hdw.h |4
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c |7 ---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index d329209..c4d51d7 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2704,6 +2704,10 @@ static void pvr2_hdw_remove_usb_stuff(struct pvr2_hdw
*hdw)
pvr2_hdw_render_useless(hdw);
}
+void pvr2_hdw_set_v4l2_dev(struct pvr2_hdw *hdw, struct video_device *vdev)
+{
+ vdev-v4l2_dev = hdw-v4l2_dev;
+}
/* Destroy hardware interaction structure */
void pvr2_hdw_destroy(struct pvr2_hdw *hdw)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
index 1a135cf..4184707 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
@@ -22,6 +22,7 @@
#include linux/usb.h
#include linux/videodev2.h
+#include media/v4l2-dev.h
#include pvrusb2-io.h
#include pvrusb2-ctrl.h
@@ -138,6 +139,9 @@ const char *pvr2_hdw_get_device_identifier(struct
pvr2_hdw *);
/* Called when hardware has been unplugged */
void pvr2_hdw_disconnect(struct pvr2_hdw *);
+/* Sets v4l2_dev of a video_device struct */
+void pvr2_hdw_set_v4l2_dev(struct pvr2_hdw *, struct video_device *);
+
/* Get the number of defined controls */
unsigned int pvr2_hdw_get_ctrl_count(struct pvr2_hdw *);
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index 82f619b..d77069e 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -31,6 +31,7 @@
#include linux/videodev2.h
#include linux/module.h
#include media/v4l2-dev.h
+#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
@@ -870,8 +871,8 @@ static void pvr2_v4l2_dev_destroy(struct pvr2_v4l2_dev
*dip)
static void pvr2_v4l2_dev_disassociate_parent(struct pvr2_v4l2_dev *dip)
{
if (!dip) return;
- if (!dip-devbase.parent) return;
- dip-devbase.parent = NULL;
+ if (!dip-devbase.v4l2_dev-dev) return;
+ dip-devbase.v4l2_dev-dev = NULL;
device_move(dip-devbase.dev, NULL, DPM_ORDER_NONE);
}
@@ -1321,7 +1322,7 @@ static void pvr2_v4l2_dev_init(struct pvr2_v4l2_dev
*dip,
if (nr_ptr (unit_number = 0) (unit_number PVR_NUM)) {
mindevnum = nr_ptr[unit_number];
}
- dip-devbase.parent = usbdev-dev;
+ pvr2_hdw_set_v4l2_dev(hdw, dip-devbase);
if ((video_register_device(dip-devbase,
dip-v4l_type, mindevnum) 0)
(video_register_device(dip-devbase,
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] pvrusb2: Declare MODULE_FIRMWARE usage
Acked-By: Mike Isely is...@pobox.com
-Mike
On Thu, 26 Jul 2012, Tim Gardner wrote:
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/pvrusb2/pvrusb2-devattr.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
index d8c8982..adc501d3 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
@@ -54,8 +54,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_29xxx[] = {
{ .module_id = PVR2_CLIENT_ID_DEMOD },
};
+#define PVR2_FIRMWARE_29xxx v4l-pvrusb2-29xxx-01.fw
static const char *pvr2_fw1_names_29xxx[] = {
- v4l-pvrusb2-29xxx-01.fw,
+ PVR2_FIRMWARE_29xxx,
};
static const struct pvr2_device_desc pvr2_device_29xxx = {
@@ -87,8 +88,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_24xxx[] = {
{ .module_id = PVR2_CLIENT_ID_DEMOD },
};
+#define PVR2_FIRMWARE_24xxx v4l-pvrusb2-24xxx-01.fw
static const char *pvr2_fw1_names_24xxx[] = {
- v4l-pvrusb2-24xxx-01.fw,
+ PVR2_FIRMWARE_24xxx,
};
static const struct pvr2_device_desc pvr2_device_24xxx = {
@@ -369,8 +371,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_73xxx[] = {
.i2c_address_list = \x42},
};
+#define PVR2_FIRMWARE_73xxx v4l-pvrusb2-73xxx-01.fw
static const char *pvr2_fw1_names_73xxx[] = {
- v4l-pvrusb2-73xxx-01.fw,
+ PVR2_FIRMWARE_73xxx,
};
static const struct pvr2_device_desc pvr2_device_73xxx = {
@@ -475,8 +478,9 @@ static const struct pvr2_dvb_props pvr2_751xx_dvb_props =
{
};
#endif
+#define PVR2_FIRMWARE_75xxx v4l-pvrusb2-73xxx-01.fw
static const char *pvr2_fw1_names_75xxx[] = {
- v4l-pvrusb2-73xxx-01.fw,
+ PVR2_FIRMWARE_75xxx,
};
static const struct pvr2_device_desc pvr2_device_750xx = {
@@ -556,7 +560,10 @@ struct usb_device_id pvr2_device_table[] = {
};
MODULE_DEVICE_TABLE(usb, pvr2_device_table);
-
+MODULE_FIRMWARE(PVR2_FIRMWARE_29xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_24xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_73xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_75xxx);
/*
Stuff for Emacs to see, in order to encourage consistent editing style:
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
s5p-fimc capturing interlaced BT656
Hi All, I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 video decoder. I notice that the capture driver ignores the field interlace flags reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also seems each field ends up in it's own frame, using only half the height. What would need to be done to store both fields in a single frame, for example in a V4L2_FIELD_INTERLACE_TB/BT format? Cheers, Mike -- 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: s5p-fimc capturing interlaced BT656
Hi Sylwester, On Fri, 2012-08-03 at 21:17 +0200, Sylwester Nawrocki wrote: Hi Mike, On 08/02/2012 02:48 PM, Mike Dyer wrote: Hi All, I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 video decoder. I notice that the capture driver ignores the field interlace flags reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also seems each field ends up in it's own frame, using only half the height. s5p-fimc driver doesn't support the interlaced video capture, as we had no such use case yet. Patches adding it are welcome. What would need to be done to store both fields in a single frame, for example in a V4L2_FIELD_INTERLACE_TB/BT format? Firstly, it would good to figure out FIMC register settings that would allow storing both fields in a single frame. I _suspect_ it's as simple as setting CAM_INTERLACE bit in CIGCTRL register. Have you perhaps tried it already ? For a quick test a patch as below might be sufficient. diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c index 1fc4ce8..19afa1a 100644 --- a/drivers/media/video/s5p-fimc/fimc-reg.c +++ b/drivers/media/video/s5p-fimc/fimc-reg.c @@ -576,6 +576,8 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc, if (cam-flags V4L2_MBUS_FIELD_EVEN_LOW) cfg |= FIMC_REG_CIGCTRL_INVPOLFIELD; + cfg |= FIMC_REG_CIGCTRL_INTERLACE; + writel(cfg, fimc-regs + FIMC_REG_CIGCTRL); return 0; -- Thanks, Sylwester I have indeed tried setting that, but with no effect. However, checking through the datasheet for the FIMC I discovered a DMA output (CIOCTRL) register bit called 'Weave_Out'. The description is: Even and Odd fields can be weaved together and combined to form a complete progressive frame by hardware. This field is useful for interlace DMA output mode (Interlace_out or CAM_INTERLACE). Even field address (1st frame start address) is used weave address. Odd fields address (2nd frame start address) is ignored. This does produce full sized frames, but I still seem to only be getting one field per frame, with a blank line inserted between each real line. Setting both interlace and weave doesn't seem to help. So, something still missing... I wonder if the irq handler is getting called for each field, maybe we need to wait for two interrupts before dequeing the frame? Cheers, Mike -- 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: Core + Radio profile
On Wed, 22 Aug 2012, Mauro Carvalho Chehab wrote: Em 22-08-2012 07:11, Hans Verkuil escreveu: I've added some more core profile requirements. Streaming I/O is not supported by radio nodes. Hmm... pvrusb2/ivtv? Ok, it makes sense to move it to use the alsa mpeg API there. If we're enforcing it, we should deprecate the current way there, and make it use ALSA. I am unaware of any ALSA MPEG API. It's entirely likely that this is because I haven't been paying attention. Nevertheless, can you please point me at any documentation on this so I can get up to speed? Currently the pvrusb2 driver does not attempt to perform any processing or filtering of the data stream, so radio data is just the same mpeg stream as video (but without any real embedded video data). If I have to get into the business of processing the MPEG data in order to adhere to this proposal, then that will be a very big deal for this driver. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 PULL FOR 3.5] pvrusb2 driver updates
Mauro: Please pull - this includes a long-awaited change courtesy of Hans Verkuil which finally transitions the driver to video_ioctl2. -Mike Isely The following changes since commit a1ac5dc28d2b4ca78e183229f7c595ffd725241c: [media] gspca - sn9c20x: Change the exposure setting of Omnivision sensors (2012-05-03 15:29:56 -0300) are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-20120504.git pvrusb2-merge-20120504 Hans Verkuil (1): pvrusb2: convert to video_ioctl2 Mike Isely (9): pvrusb2: Stop statically initializing reserved struct fields to zero pvrusb2: Clean up pvr2_hdw_get_detected_std() pvrusb2: Implement querystd for videodev_ioctl2 pvrusb2: Transform video standard detection result into read-only control ID pvrusb2: Fix truncated video standard names (trivial) pvrusb2: Base available video standards on what hardware supports pvrusb2: Trivial tweak to get rid of some redundant dereferences pvrusb2: Get rid of obsolete code for video standard enumeration pvrusb2: For querystd, start with list of hardware-supported standards drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h |6 +- drivers/media/video/pvrusb2/pvrusb2-hdw.c | 193 +--- drivers/media/video/pvrusb2/pvrusb2-hdw.h |9 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 1343 ++-- 4 files changed, 735 insertions(+), 816 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
atsc_epg 64-bit bug / fault tolerance
I was looking at using the dvb-apps when I had a hangup with atsc_epg.
This issue had been previously reported from what I found at
http://www.mail-archive.com/linux-media@vger.kernel.org/msg44661.html
but had not been resolved from what I could tell.
Below I'm including a patch to fix the segfault on 64-bit builds and
also to improve tolerance of the fault I found when a segment was read
with a mode of '?' (don't ask me why, but I could try to give more
information if desired).
The first three changes in the patch are about using an appropriately
sized type rather than casting a pointer to a larger type; this fixes
the segfault. The last change involves nulling the title text when it
fails to parse rather than failing altogether.
Thanks,
Mike Slegeir
diff -r 4030c51d6e7b util/atsc_epg/atsc_epg.c
--- a/util/atsc_epg/atsc_epg.cTue Apr 10 16:44:06 2012 +0200
+++ b/util/atsc_epg/atsc_epg.cSat May 12 18:15:04 2012 -0500
@@ -60,8 +60,8 @@
void (*old_handler)(int);
struct atsc_string_buffer {
-int buf_len;
-int buf_pos;
+size_t buf_len;
+size_t buf_pos;
char *string;
};
@@ -507,8 +507,8 @@
event-msg_pos = channel-msg_buf.buf_pos;
if(0 atsc_text_segment_decode(seg,
(uint8_t **)channel-msg_buf.string,
-(size_t *)channel-msg_buf.buf_len,
-(size_t *)channel-msg_buf.buf_pos)) {
+ channel-msg_buf.buf_len,
+ channel-msg_buf.buf_pos)) {
fprintf(stderr, %s(): error calling
atsc_text_segment_decode()\n,
__FUNCTION__);
@@ -653,15 +653,18 @@
e_info-title_pos = curr_info-title_buf.buf_pos;
if(0 atsc_text_segment_decode(seg,
(uint8_t **)curr_info-title_buf.string,
-(size_t *)curr_info-title_buf.buf_len,
-(size_t *)curr_info-title_buf.buf_pos)) {
+ curr_info-title_buf.buf_len,
+ curr_info-title_buf.buf_pos)) {
fprintf(stderr, %s(): error calling
atsc_text_segment_decode()\n,
__FUNCTION__);
-return -1;
+e_info-title_len = 0;
}
-e_info-title_len = curr_info-title_buf.buf_pos -
-e_info-title_pos + 1;
+else
+{
+e_info-title_len = curr_info-title_buf.buf_pos -
+e_info-title_pos + 1;
+}
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] pvrusb2: fix sparse warning
Acked-by: Mike Isely is...@pobox.com
-Mike
On Fri, 4 Oct 2013, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2871:13: warning: symbol
'pvr2_hdw_get_detected_std' was not declared. Should it be static?
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Mike Isely is...@pobox.com
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index c4d51d7..ea05f67 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2868,7 +2868,7 @@ static void pvr2_subdev_set_control(struct pvr2_hdw
*hdw, int id,
pvr2_subdev_set_control(hdw, id, #lab, (hdw)-lab##_val); \
}
-v4l2_std_id pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw)
+static v4l2_std_id pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw)
{
v4l2_std_id std;
std = (v4l2_std_id)hdw-std_mask_avail;
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 v6 0/5] clk: clock deregistration support
Quoting Sylwester Nawrocki (2013-10-15 13:04:17)
Hi,
(adding linux-media mailing list at Cc)
On 09/25/2013 11:47 AM, Laurent Pinchart wrote:
On Tuesday 24 September 2013 23:38:44 Sylwester Nawrocki wrote:
[...]
The only issue I found might be at the omap3isp driver, which provides
clock to its sub-drivers and takes reference on the sub-driver modules.
When sub-driver calls clk_get() all modules would get locked in memory,
due to circular reference. One solution to that could be to pass NULL
struct device pointer, as in the below patch.
Doesn't that introduce race conditions ? If the sub-drivers require the
clock,
they want to be sure that the clock won't disappear beyond their backs. I
agree that the circular dependency needs to be solved somehow, but we
probably
need a more generic solution. The problem will become more widespread in the
future with DT-based device instantiation in both V4L2 and KMS.
I'm wondering whether subsystems and drivers itself should be written so
they deal with such dependencies they are aware of.
There is similar situation in the regulator API, regulator_get() simply
takes a reference on a module providing the regulator object.
Before a more generic solution is available, what do you think about
keeping obtaining a reference on a clock provider module in clk_get() and
doing clk_get(), clk_prepare_enable(), ..., clk_unprepare_disable(),
clk_put() in sub-driver whenever a clock is actively used, to avoid
permanent circular reference ?
Laurent,
Did you have any feedback on this proposal? I would like to merge these
patches so that folks with clock driver modules can use them properly.
We can fix up things in the core code as we figure them out.
Regards,
Mike
--
Thanks,
Sylwester
-8--
From ca5963041aad67e31324cb5d4d5e2cfce1706d4f Mon Sep 17 00:00:00 2001
From: Sylwester Nawrockis.nawro...@samsung.com
Date: Thu, 19 Sep 2013 23:52:04 +0200
Subject: [PATCH] omap3isp: Pass NULL device pointer to clk_register()
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
---
drivers/media/platform/omap3isp/isp.c | 15 ++-
drivers/media/platform/omap3isp/isp.h |1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index df3a0ec..d7f3c98 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -290,9 +290,11 @@ static int isp_xclk_init(struct isp_device *isp)
struct clk_init_data init;
unsigned int i;
+for (i = 0; i ARRAY_SIZE(isp-xclks); ++i)
+isp-xclks[i] = ERR_PTR(-EINVAL);
+
for (i = 0; i ARRAY_SIZE(isp-xclks); ++i) {
struct isp_xclk *xclk =isp-xclks[i];
-struct clk *clk;
xclk-isp = isp;
xclk-id = i == 0 ? ISP_XCLK_A : ISP_XCLK_B;
@@ -306,9 +308,9 @@ static int isp_xclk_init(struct isp_device *isp)
xclk-hw.init =init;
-clk = devm_clk_register(isp-dev,xclk-hw);
-if (IS_ERR(clk))
-return PTR_ERR(clk);
+xclk-clk = clk_register(NULL,xclk-hw);
+if (IS_ERR(xclk-clk))
+return PTR_ERR(xclk-clk);
if (pdata-xclks[i].con_id == NULL
pdata-xclks[i].dev_id == NULL)
@@ -320,7 +322,7 @@ static int isp_xclk_init(struct isp_device *isp)
xclk-lookup-con_id = pdata-xclks[i].con_id;
xclk-lookup-dev_id = pdata-xclks[i].dev_id;
-xclk-lookup-clk = clk;
+xclk-lookup-clk = xclk-clk;
clkdev_add(xclk-lookup);
}
@@ -335,6 +337,9 @@ static void isp_xclk_cleanup(struct isp_device *isp)
for (i = 0; i ARRAY_SIZE(isp-xclks); ++i) {
struct isp_xclk *xclk =isp-xclks[i];
+if (!IS_ERR(xclk-clk))
+clk_unregister(xclk-clk);
+
if (xclk-lookup)
clkdev_drop(xclk-lookup);
}
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index cd3eff4..1498f2b 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -135,6 +135,7 @@ struct isp_xclk {
struct isp_device *isp;
struct clk_hw hw;
struct clk_lookup *lookup;
+struct clk *clk;
enum isp_xclk_id id;
spinlock_t lock;/* Protects enabled and divider */
-8--
--
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] pvr2: fix minor storage
Completely agree! Thanks for spotting that one.
Signed-off-by: Mike Isely is...@pobox.com
-Mike
On Thu, 25 Oct 2012, Alan Cox wrote:
From: Alan Cox a...@linux.intel.com
This should have break statements in it.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index fb828ba..299751a 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -3563,9 +3563,9 @@ void pvr2_hdw_v4l_store_minor_number(struct pvr2_hdw
*hdw,
enum pvr2_v4l_type index,int v)
{
switch (index) {
- case pvr2_v4l_type_video: hdw-v4l_minor_number_video = v;
- case pvr2_v4l_type_vbi: hdw-v4l_minor_number_vbi = v;
- case pvr2_v4l_type_radio: hdw-v4l_minor_number_radio = v;
+ case pvr2_v4l_type_video: hdw-v4l_minor_number_video = v;break;
+ case pvr2_v4l_type_vbi: hdw-v4l_minor_number_vbi = v;break;
+ case pvr2_v4l_type_radio: hdw-v4l_minor_number_radio = v;break;
default: break;
}
}
--
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
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 33/68] [media] pvrusb2: get rid of warning: no previous prototype
Acked-By: Mike Isely is...@pobox.com
On Sat, 27 Oct 2012, Mauro Carvalho Chehab wrote:
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:199:5: warning: no previous
prototype for 'pvr2_s_std' [-Wmissing-prototypes]
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:368:5: warning: no previous
prototype for 'pvr2_s_frequency' [-Wmissing-prototypes]
Cc: Mike Isely is...@pobox.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index db249ca..6930676 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -196,7 +196,7 @@ static int pvr2_g_std(struct file *file, void *priv,
v4l2_std_id *std)
return ret;
}
-int pvr2_s_std(struct file *file, void *priv, v4l2_std_id *std)
+static int pvr2_s_std(struct file *file, void *priv, v4l2_std_id *std)
{
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
@@ -365,7 +365,7 @@ static int pvr2_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *vt)
vt-audmode);
}
-int pvr2_s_frequency(struct file *file, void *priv, struct v4l2_frequency
*vf)
+static int pvr2_s_frequency(struct file *file, void *priv, struct
v4l2_frequency *vf)
{
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
s5p-mfc cyclic refresh and slicing
I'm using the MFC on an S5PV210 to encode H264. I'm interested in enabling cyclic intra refresh and fixed size slices. I've set the controls V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB to 1 V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE to V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES to 20 * 1024 I've checked that these are making it to the driver, but they seem to have no effect on the encode. Are there any limitations, or other controls that need to be set to enable these? Cheers, Mike -- 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 0/2] OMAP3 ISP: Simplify clock usage
Quoting Laurent Pinchart (2013-01-08 05:43:52) Hello, Now that the OMAP3 supports the common clock framework, clock rate back-propagation is available for the ISP clocks. Instead of setting the cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set the cam_mclk rate directly. This simplifies the ISP clocks configuration. I'm pleased to see this feature get used on OMAP. Plus your driver gets a negative diffstat :) Reviewed-by: Mike Turquette mturque...@linaro.org Laurent Pinchart (2): ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5 omap3isp: Set cam_mclk rate directly arch/arm/mach-omap2/cclock3xxx_data.c | 10 +- drivers/media/platform/omap3isp/isp.c | 18 ++ drivers/media/platform/omap3isp/isp.h |8 +++- 3 files changed, 14 insertions(+), 22 deletions(-) -- 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
dvb-usb-it913x dissapeared kernel 3.7.2
After updating the kernel on Fedora 18 module dvb-usb-it913x seems to have dissapeared. This has meant my dvb stick ( ID 1b80:e409 Afatech IT9137FN Dual DVB-T [KWorld UB499-2T]) no longer works Is this a Redhat only thing or is it upstream -- 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: Do any drivers access the cx25840 module in an atomic context?
On Mon, 18 Jan 2010, Andy Walls wrote: On Mon, 2010-01-18 at 14:18 -0600, Mike Isely wrote: On Mon, 18 Jan 2010, Andy Walls wrote: Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. Mike, Great! Thank you for the answers. You're welcome. If you would indulge one more (compound) question: Looking at the I2C master implementation in pvrusb2, it looks like it would be OK for me to combine the i2c_master_write() and i2c_master_read() in cx25840_read() into a single 2 msg i2c_transfer() without the pvrusb2 driver having a problem. a. Is that correct? Yes, that is correct. b. Is there a limit on the combined payload, such that a the cx25840_read4() would not work as a combined i2c_transfer() ? There is an overall limit on the size of the I2C transfer. This is due to the underlying firmware on pvrusb2-support devices. Essentially the entire outgoing transfer plus a few bytes of overhead has to fit inside a single 64 byte URB. This also limits the atomic read size to roughly 64 bytes as well (the URB size on the returned data). You should be able to reliably write up to 48 bytes at a time, perhaps even a little more. This issue caused a problem for the cx25840 module a few years back when it used to do firmware downloads with large (e.g. 1024 byte or larger) single I2C transfers. Hans told me then it was that large because it allowed the ivtv driver to run more efficiently, but we cut it back to 48 bytes since it triggered problems with I2C adapters (e.g. pvrusb2) which could not handle such larger transfers at all. The pvrusb2 driver's I2C adapter is really just a proxy for the I2C implementation in the device at the far end of the USB cable. So it works at a higher level than one might normally expect - it operates at the transfer level, no bit-banging. The communications protocol required by the hardware limits the I2C transfers to be either a write of some size, or an atomic write followed by a read of various sizes. The pvrusb2 implementation looks at the incoming transfers and tries to map them as best it can over what the device protocol allows. Generally this means that if it is possible it will do the right thing. In the specific case you mentioned above, the result should in fact be exactly what you need. (I'm saying that without having looked at that area of code for quite a while, but it's what I remember being in my head when I did that part..) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-patches
Please from http://linuxtv.org/hg/~mcisely/pvrusb2-patches for the following pvrusb2 driver fixes / improvements: - pvrusb2: Enforce a 300msec stabilization interval during stream strart - pvrusb2: Reduce encoder quiet period - pvrusb2: Adjust 300msec digitizer wait to be more selective pvrusb2-hdw-internal.h | 12 - pvrusb2-hdw.c | 61 - pvrusb2-hdw.h |1 3 files changed, 61 insertions(+), 13 deletions(-) These fixes improve mpeg streaming startup stability for any pvrusb2-driven device which contains an saa7115 video digitizer. Thanks, -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: OnAir USB HDTV Creator
On Fri, 26 Feb 2010, Dean wrote: I am trying to use an 'OnAir USB HDTV Creator' (from autumnwave.com). According to http://www.linuxtv.org/wiki/index.php/OnAir_USB_HDTV_Creator This device is supported, however it's not working for me. Following the instructions at above link, I tried this: modprobe pvrusb2 initusbreset=0 The result: FATAL: Error inserting pvrusb2 (/lib/modules/2.6.31.12-desktop586-1mnb/kernel/drivers/media/video/pvrusb2/pvrusb2.ko.gz): Unknown symbol in module, or unknown parameter (see dmesg) Dean: The initusbreset module option no longer exists. That's why your modprobe command is failing. That feature was removed from the driver, due to a change in USB stack behavior that started with the 2.6.27 kernel. (The resolution hinted at in the wiki page was in fact just removal of the feature.) So you need to not use initusbreset=0. The advice in the wiki is over a year out of date. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: offering bounty for GPL'd dual em28xx support
On Wed, 22 Jul 2009, Mauro Carvalho Chehab wrote: Em Wed, 22 Jul 2009 11:06:12 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Wed, Jul 22, 2009 at 11:01 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Funky timing of those mails :D. I saw only after sending my mail that Steve was talking about analog and that this is indeed different. Dual analog tuner support should be possible right? Maybe with some other analog usb chipsets? I don't know what the usb blocksize is or if they are isochronous transfers or bulk or control. I assume the video must be uncompressed transferred over usb because the decoding chip is on the usb device is not capable of doing compression encoding after the analog video decoding? Are there usb devices that do such tricks? There were older devices that did compression, mainly designed to fit the stream inside of 12Mbps USB. However, they required onboard RAM to buffer the frame which added considerable cost (in addition to the overhead of doing the compression), and as a result pretty much all of the USB 2.0 designs I have seen do not do any on-chip compression. The example which comes to mind is the Hauppauge Win-TV USB which uses the usbvision chipset. pvrusb2 also has compression, provided by an external mpeg encoder. Those devices are USB 2.0 I know this is a fairly old thread, but I've been away on vacation and I'm catching up on e-mail right now. So forgive me if this has already been answered... The Hauppauge Win-TV PVR-USB2 is the most well-known device in this category and it's what the pvrusb2 driver originally targeted. This device uses a dedicated mpeg encoder chip within the device, so the video stream coming from the hardware is actually compressed video (mpeg format, mostly DVD-style mpeg2). The question of USB 1.1 vs USB 2.0 is actually due to the device's microcontroller (the bridge chip) not the mpeg encoder. In the pvrusb2 case, that controller is a Cypress FX2 which includes an on-chip USB 2.0 high-speed device interface. But the mpeg encoder actually doesn't REQUIRE USB 2.0 high-speed. The default encoder settings configured by the pvrusb2 driver actually work quite well over USB 1.1, since the resulting video stream requires significantly less bandwidth than the 12Mbps that USB 1.1 can theoretically supply. I've actually successfully tested such a configuration here. The hardware works fine over USB 1.1. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Acked-By: Mike Isely is...@pobox.com -Mike On Fri, 7 Aug 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - pvrusb2: fix compile warning - cx24113: fix mips compiler warning - hdpvr: add missing initialization of current_norm - v4l2-ioctl: fix G_STD and G_PARM default handlers - v4l2-ctl: fix get/set-parm bugs and add get/set-output-parm support Thanks, Hans diffstat: linux/drivers/media/dvb/frontends/cx24113.c |6 + linux/drivers/media/video/hdpvr/hdpvr-video.c |2 linux/drivers/media/video/pvrusb2/pvrusb2-audio.c |5 - linux/drivers/media/video/v4l2-ioctl.c| 15 ++- v4l2-apps/util/v4l2-ctl.cpp | 98 +- 5 files changed, 101 insertions(+), 25 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] Add RGB555X and RGB565X formats to pxa-camera
Hi Guennadi, Guennadi Liakhovetski wrote: On Mon, 3 Aug 2009, Mike Rapoport wrote: 2. Mike, while reviewing this patch I came across code in pxa_camera_setup_cicr(), introduced by your earlier patch: case V4L2_PIX_FMT_RGB555: cicr1 |= CICR1_RGB_BPP_VAL(1) | CICR1_RGBT_CONV_VAL(2) | CICR1_TBIT | CICR1_COLOR_SP_VAL(1); break; Why are you enabling the RGB to RGBT conversion here unconditionally? Generally, what are the advantages of configuring CICR1 for a specific RGB format compared to using just a raw capture? Do I understand it right, that ATM we are not using any of those features? As far as I remember I've tried to overlay the captured imagery using pxa overlay1. Most probably it's left here after those tries. Mike, could you, please, verify that those bits are indeed unneeded and provide patch to remove them? Unfortunately, I don't have the sensor handy at the time :( The one I've used then is now broken (physically) and there's no replacement for it :( Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- 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] bttv: Fix potential out-of-order field processing
Mauro:
You can also directly pull this from:
http://linuxtv.org/hg/~mcisely/bttv-patches/
Sorry about the excessively long commit description, but I felt it
important to fully explain this somewhat subtle problem for what is
otherwise a mature driver. The actual patch is tiny.
-Mike
# HG changeset patch
# User Mike Isely is...@pobox.com
# Date 1253545748 18000
# Node ID 760a8bc4028014493ccbbe85d0c9e8c91873fc23
# Parent 29e4ba1a09bcf9a03a653b2124929f5359fef772
bttv: Fix potential out-of-order field processing
From: Mike Isely is...@pobox.com
There is a subtle interaction in the bttv driver which can result in
fields being repeatedly processed out of order. This is a problem
specifically when running in V4L2_FIELD_ALTERNATE mode (probably the
most common case).
1. The determination of which fields are associated with which buffers
happens in videobuf, before the bttv driver gets a chance to queue the
corresponding DMA. Thus by the point when the DMA is queued for a
given buffer, the algorithm has to do the queuing based on the
buffer's already assigned field type - not based on which field is
next in the video stream.
2. The driver normally tries to queue both the top and bottom fields
at the same time (see bttv_irq_next_video()). It tries to sort out
top vs bottom by looking at the field type for the next 2 available
buffers and assigning them appropriately.
3. However the bttv driver *always* actually processes the top field
first. There's even an interrupt set aside for specifically
recognizing when the top field has been processed so that it can be
marked done even while the bottom field is still being DMAed.
Given all of the above, if one gets into a situation where
bttv_irq_next_video() gets entered when the first available buffer has
been pre-associated as a bottom field, then the function is going to
process the buffers out of order. That first available buffer will be
put into the bottom field slot and the buffer after that will be put
into the top field slot. Problem is, since the top field is always
processed first by the driver, then that second buffer (the one after
the first available buffer) will be the first one to be finished.
Because of the strict fifo handling of all video buffers, then that
top field won't be seen by the app until after the bottom field is
also processed. Worse still, the app will get back the
chronologically later bottom field first, *before* the top field is
received. The buffer's timestamps will even be backwards.
While not fatal to most TV apps, this behavior can subtlely degrade
userspace deinterlacing (probably will cause jitter). That's probably
why it has gone unnoticed. But it will also cause serious problems if
the app in question discards all but the latest received buffer (a
latency minimizing tactic) - causing one field to only ever be
displayed since the other is now always late. Unfortunately once you
get into this state, you're stuck this way - because having consumed
two buffers, now the next time around the first available buffer
will again be a bottom field and the same thing happens.
How can we get into this state? In a perfect world, where there's
always a few free buffers queued to the driver, it should be
impossible. However if something disrupts streaming, e.g. if the
userspace app can't queue free buffers fast enough for a moment due
perhaps to a CPU scheduling glitch, then the driver can get
momentarily starved and some number of fields will be dropped. That's
OK. But if an odd number of fields get dropped, then that first
available buffer might be the bottom field and now we're stuck...
This patch fixes that problem by deliberately only setting up a single
field for one frame if we don't get a top field as the first available
buffer. By purposely skipping the other field, then we only handle a
single buffer thus bringing things back into proper sync (i.e. top
field first) for the next frame. To do this we just drop the few
lines in bttv_irq_next_video() that attempt to set up the second
buffer when that second buffer isn't for the bottom field.
This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In
the other modes this change either has no effect or doesn't harm
things any further anyway.
Priority: high
Signed-off-by: Mike Isely is...@pobox.com
diff -r 29e4ba1a09bc -r 760a8bc40280
linux/drivers/media/video/bt8xx/bttv-driver.c
--- a/linux/drivers/media/video/bt8xx/bttv-driver.c Sat Sep 19 09:45:22
2009 -0300
+++ b/linux/drivers/media/video/bt8xx/bttv-driver.c Mon Sep 21 10:09:08
2009 -0500
@@ -3828,11 +3828,34 @@
if (!V4L2_FIELD_HAS_BOTH(item-vb.field)
(item-vb.queue.next != btv-capture)) {
item = list_entry(item-vb.queue.next, struct
bttv_buffer, vb.queue);
+ /* Mike Isely is...@pobox.com - Only check
+* and set up the bottom field in the logic
[PATCH] bttv: Fix reversed polarity error when switching video standard
Mauro:
You can also directly pull this from:
http://linuxtv.org/hg/~mcisely/bttv-patches/
Again, another longer-than usual commit description here. Same reason
as before. This bug is a little less subtle than the other one - and
the patch is even smaller (one character).
-Mike
# HG changeset patch
# User Mike Isely is...@pobox.com
# Date 1253547742 18000
# Node ID e349075171ddf939381fad432c23c1269abc4899
# Parent 760a8bc4028014493ccbbe85d0c9e8c91873fc23
bttv: Fix reversed polarity error when switching video standard
From: Mike Isely is...@pobox.com
The bttv driver function which handles switching of the video standard
(set_tvnorm() in bttv-driver.c) includes a check which can optionally
also reset the cropping configuration to a default value. It is
optional based on a comparison of the cropcap parameters of the
previous vs the newly requested video standard. The comparison is
being done with a memcmp(), a function which only returns a true value
if the comparison actually fails.
This if-statement appears to have been written to assume wrong
memcmp() semantics. That is, it was re-initializing the cropping
configuration only if the new video standard did NOT have different
cropcap values. That doesn't make any sense. One definitely should
reset things if the cropcap parameters are different - if there's any
comparison to made at all.
The effect of this problem was that a transition from, say, PAL to
NTSC would leave in place old cropping setup that made sense for the
PAL geometry but not for NTSC. If the application doesn't care about
cropping it also won't try to reset the cropping configuration,
resulting in an improperly cropped video frame. In the case I was
testing this actually caused black video frames to be displayed.
Another interesting effect of this bug is that if one does something
which does NOT change the video standard and this function is run,
then the cropping setup gets reset anyway - again because of the
backwards comparison. It turns out that just running anything which
merely opens and closes the video device node (e.g. v4l-info) will
cause this to happen. One can argue that simply opening the device
node and not doing anything to it should not mess with any of its
state - but because of this behavior, any TV app which does such
things (e.g. xawtv) probably therefore doesn't see the problem.
The solution is to fix the sense of the if-statement. It's easy to
see how this mistake could have been made given how memcmp() works.
The patch is therefore removal of a single ! character from the
if-statement in set_tvnorm in bttv-driver.c.
Priority: high
Signed-off-by: Mike Isely is...@pobox.com
diff -r 760a8bc40280 -r e349075171dd
linux/drivers/media/video/bt8xx/bttv-driver.c
--- a/linux/drivers/media/video/bt8xx/bttv-driver.c Mon Sep 21 10:09:08
2009 -0500
+++ b/linux/drivers/media/video/bt8xx/bttv-driver.c Mon Sep 21 10:42:22
2009 -0500
@@ -1322,7 +1322,7 @@
tvnorm = bttv_tvnorms[norm];
- if (!memcmp(bttv_tvnorms[btv-tvnorm].cropcap, tvnorm-cropcap,
+ if (memcmp(bttv_tvnorms[btv-tvnorm].cropcap, tvnorm-cropcap,
sizeof (tvnorm-cropcap))) {
bttv_crop_reset(btv-crop[0], norm);
btv-crop[1] = btv-crop[0]; /* current = default */
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] s2255drv: Don't conditionalize video buffer completion on waiting processes
# HG changeset patch
# User Mike Isely is...@pobox.com
# Date 1253739604 18000
# Node ID 522a74147753ba59c7f45e368439928090a286f2
# Parent e349075171ddf939381fad432c23c1269abc4899
s2255drv: Don't conditionalize video buffer completion on waiting processes
From: Mike Isely is...@pobox.com
The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question. That
simply doesn't work when the application is doing things in an
asynchronous manner. If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere. Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less). Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this is anyone waiting on this? check on the buffer never would
have evalutated true. This patch just deletes that harmful check
against the buffer's wait queue.
Priority: high
Signed-off-by: Mike Isely is...@pobox.com
diff -r e349075171dd -r 522a74147753 linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Mon Sep 21 10:42:22 2009 -0500
+++ b/linux/drivers/media/video/s2255drv.c Wed Sep 23 16:00:04 2009 -0500
@@ -599,11 +599,6 @@
buf = list_entry(dma_q-active.next,
struct s2255_buffer, vb.queue);
- if (!waitqueue_active(buf-vb.done)) {
- /* no one active */
- rc = -1;
- goto unlock;
- }
list_del(buf-vb.queue);
do_gettimeofday(buf-vb.ts);
dprintk(100, [%p/%d] wakeup\n, buf, buf-vb.i);
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] s2255drv: Don't conditionalize video buffer completion on waiting processes
On Wed, 23 Sep 2009, dean wrote:
This seems ok. This portion of code was based on vivi.c, so that might be
checked also.
Yes, after seeing the mention of vivi in this driver I looked at vivi.c
and saw the same construct there. Though I'm willing to bet that it's
just as incorrect there as it was here, I haven't tested or otherwise
used vivi so I wasn't prepared to recommend a patch for it as well.
Probably vivi should be fixed, since it is after all intended as a model
for other v4l driver developers. (And are there any other drivers based
on vivi which have inherited this bug as well?)
-Mike
Mike Isely wrote:
# HG changeset patch
# User Mike Isely is...@pobox.com
# Date 1253739604 18000
# Node ID 522a74147753ba59c7f45e368439928090a286f2
# Parent e349075171ddf939381fad432c23c1269abc4899
s2255drv: Don't conditionalize video buffer completion on waiting processes
From: Mike Isely is...@pobox.com
The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question. That
simply doesn't work when the application is doing things in an
asynchronous manner. If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere. Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less). Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this is anyone waiting on this? check on the buffer never would
have evalutated true. This patch just deletes that harmful check
against the buffer's wait queue.
Priority: high
Signed-off-by: Mike Isely is...@pobox.com
diff -r e349075171dd -r 522a74147753 linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Mon Sep 21 10:42:22 2009 -0500
+++ b/linux/drivers/media/video/s2255drv.c Wed Sep 23 16:00:04 2009 -0500
@@ -599,11 +599,6 @@
buf = list_entry(dma_q-active.next,
struct s2255_buffer, vb.queue);
- if (!waitqueue_active(buf-vb.done)) {
- /* no one active */
- rc = -1;
- goto unlock;
- }
list_del(buf-vb.queue);
do_gettimeofday(buf-vb.ts);
dprintk(100, [%p/%d] wakeup\n, buf, buf-vb.i);
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: How to make my device work with linux?
On Thu, 1 Oct 2009, Wellington Terumi Uemura wrote: I was looking around to find that there is a driver for that Fujitsu MB86A16 inside the Linux Mantis Driver project, Fujitsu MB86A16 DVB-S/DSS DC Receiver driver made by Manu Abraham http://www.verbraak.org/wiki/index.php/Linux_Mantis_driver. I've done a few tests with usbsnoop and other tools but USB sniffer doesn't see any valid command, jut a bunch of bytes that makes no sense: http://www.isely.net/pvrusb2/firmware.html#FX2 What you've pointed at here is a page that describes using a trick with the pvrusb2 driver to suck an image of the FX2 firmware out of the FX2 processor itself. That won't work in your case however since it requires that the pvrusb2 driver already be talking to the chip. The procedure documented at that link is really about firmware extraction not reverse-engineering the data link protocol between the FX2 and the host. I will try my luck compiling that Fujitsu driver, but my best guess is that without a proper I/O from that FX2 it will end up with nothing at all. It's that data link protocol that you need to understand. Please realize that the FX2 is just an 8051 microcontroller which happens to have a fairly interesting USB device interface resident on the same silicon. Beyond that, the chip's behavior is really up to whatever the firmware does. For pvrusb2-driven devices that firmware's behavior is pretty well understood. That driver also benefits from the fact that essentially all USB hosted analog (and some hybrid) capture cards with an mpeg encoder and an FX2 all are derivations from a reference design by a single vendor. That reference design included reference firmware, which each manufacturer of course tweaked a bit. For that reason, all those different devices tend to implement a similar enough data link protocol that the pvrusb2 driver can handle them all with the same implementation. The problem is, we don't know if any of that is true for your device. You are dealing with a digital-only capture device so it can't be based on that same reference design. It is entirely sensible that the FX2 firmware was set up in that case with similar requirements in mind so the result *might* be similar in behavior. But it really isn't known. So when you scan documentation for other drivers (e.g. pvrusb2) you must really look at it all with a rather large helping of scepticism. Mike Krufky mentions a driver for the TDA18271 and he's right. There is one - because the pvrusb2 driver also relies on that when driving an HVR-1950 capture device which happens to use that same part. But that isn't the driver you need. What you need is a bridge driver that can implement the host side of the data link protocol implemented by your device's FX2. That is what the pvrusb2 driver does for the capture devices it handles. With the proper bridge driver set up, then the TDA18271 sub-device driver can ride over that data link to establish communications with its hardware in the device. THEN you'll be on the way to having something working. I know that none of the about is the answer you're looking for. But perhaps it will lead you in the right direction. It is entirely possible that there is another bridge driver out there which can handle this part, but I can't help you there. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: How to make my device work with linux?
On Thu, 1 Oct 2009, Devin Heitmueller wrote: On Thu, Oct 1, 2009 at 6:03 PM, Wellington Terumi Uemura wellingtonuem...@gmail.com wrote: It's not the answer that I was looking for but looks like the thing is much more complex than just compile and run drivers, this gives me another perspective, like a dead end. Thank you Mike. Well, it's certainly possible to get it to work if you're willing to make the investment. It's just one of those situations where you realize quickly that you're going to have to be prepared to do *way* more work than just adding a new board profile. Just because there are drivers for the chips on your device doesn't mean that it is trivial to get working. Cheers, Devin And actually I wasn't intending on totally discouraging you either. But you do need to see the perspective of what you're trying to do otherwise you may just get frustrated. Things aren't hopeless. The cxusb module in DVB might be something you should look at. I guess it depends on how deep you wish to dive here. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Change MFC clock reference w.r.t Common Clock Framework
Quoting Prasanna Kumar (2013-03-25 22:20:51)
From: Prasanna Kumar prasanna...@samsung.com
According to Common Clock framework , modified the method of getting
clock for MFC Block.
Signed-off-by: Prasanna Kumar prasanna...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 6aa38a5..b8ac8f6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -50,7 +50,7 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
goto err_p_ip_clk;
}
- pm-clock = clk_get(dev-plat_dev-dev, dev-variant-mclk_name);
+ pm-clock = clk_get_parent(pm-clock_gate);
Ok, I'll bite. Why make this change? Was there an issue using
clkdev/clk_get to get the clock you needed?
Regards,
Mike
if (IS_ERR(pm-clock)) {
mfc_err(Failed to get MFC clock\n);
ret = PTR_ERR(pm-clock);
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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
MFC Encode on S5PV210 hangs
Hi All, I'm trying to use the MFC encoder to generate an H264 bitstream using the V4L2 interface. I've tried using my own application, and also the example encode application here: git://git.infradead.org/users/kmpark/public-apps Both exhibit the same behavior. Input frames are queued up until the input queue is full, but only one frame is emitted (which I guess is the H264 header). The encoder then just sits there. I'm not sure where to start looking, so any advice is appreciated. Cheers, Mike -- 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] next-20140324 drivers/staging/media/sn9c102/sn9c102_hv7131r.c fix style warnings flagged by checkpatch.pl.
Signed-off-by: Mike Sampson m...@sambodata.com
---
drivers/staging/media/sn9c102/sn9c102_hv7131r.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
b/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
index 26a9111..51b24e0 100644
--- a/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
+++ b/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
@@ -23,7 +23,7 @@
#include sn9c102_devtable.h
-static int hv7131r_init(struct sn9c102_device* cam)
+static int hv7131r_init(struct sn9c102_device *cam)
{
int err = 0;
@@ -137,8 +137,8 @@ static int hv7131r_init(struct sn9c102_device* cam)
}
-static int hv7131r_get_ctrl(struct sn9c102_device* cam,
- struct v4l2_control* ctrl)
+static int hv7131r_get_ctrl(struct sn9c102_device *cam,
+ struct v4l2_control *ctrl)
{
switch (ctrl-id) {
case V4L2_CID_GAIN:
@@ -176,8 +176,8 @@ static int hv7131r_get_ctrl(struct sn9c102_device* cam,
}
-static int hv7131r_set_ctrl(struct sn9c102_device* cam,
- const struct v4l2_control* ctrl)
+static int hv7131r_set_ctrl(struct sn9c102_device *cam,
+ const struct v4l2_control *ctrl)
{
int err = 0;
@@ -197,6 +197,7 @@ static int hv7131r_set_ctrl(struct sn9c102_device* cam,
case V4L2_CID_BLACK_LEVEL:
{
int r = sn9c102_i2c_read(cam, 0x01);
+
if (r 0)
return -EIO;
err += sn9c102_i2c_write(cam, 0x01,
@@ -211,10 +212,10 @@ static int hv7131r_set_ctrl(struct sn9c102_device* cam,
}
-static int hv7131r_set_crop(struct sn9c102_device* cam,
- const struct v4l2_rect* rect)
+static int hv7131r_set_crop(struct sn9c102_device *cam,
+ const struct v4l2_rect *rect)
{
- struct sn9c102_sensor* s = sn9c102_get_sensor(cam);
+ struct sn9c102_sensor *s = sn9c102_get_sensor(cam);
int err = 0;
u8 h_start = (u8)(rect-left - s-cropcap.bounds.left) + 1,
v_start = (u8)(rect-top - s-cropcap.bounds.top) + 1;
@@ -226,8 +227,8 @@ static int hv7131r_set_crop(struct sn9c102_device* cam,
}
-static int hv7131r_set_pix_format(struct sn9c102_device* cam,
- const struct v4l2_pix_format* pix)
+static int hv7131r_set_pix_format(struct sn9c102_device *cam,
+ const struct v4l2_pix_format *pix)
{
int err = 0;
@@ -347,7 +348,7 @@ static const struct sn9c102_sensor hv7131r = {
};
-int sn9c102_probe_hv7131r(struct sn9c102_device* cam)
+int sn9c102_probe_hv7131r(struct sn9c102_device *cam)
{
int devid, err;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] [pvrusb2]: remove dead retry cmd code
Sorry been asleep at the wheel here. I'll take a look.
Please realize that the code path being talked about here HAS worked -
because the encoder does tend to fail and this is how the driver
recovers.
-Mike
On Fri, 16 Jan 2015, Hans Verkuil wrote:
On 01/16/2015 12:29 PM, Haim Daniel wrote:
It looks that if (try_count 20) continue jumps to end of the do ...
while(0) loop and goes out.
Ah, you are right. But that is obviously not what was intended, so just
removing
it is not a proper 'fix'.
Mike, can you take a look at this?
Regards,
Hans
--hd.
On Fri, 2015-01-16 at 11:57 +0100, Hans Verkuil wrote:
On 01/05/2015 11:38 PM, Haim Daniel wrote:
In case a command is timed out, current flow sets the retry_flag
and does nothing.
Really? That's not how I read the code: it retries up to 20 times before
bailing out.
Perhaps you missed the if (try_count 20) continue; line?
Regards,
Hans
Signed-off-by: Haim Daniel haim.dan...@gmail.com
---
drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
index f7702ae..02028aa 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
@@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
u32 *argp)
{
unsigned int poll_count;
- unsigned int try_count = 0;
- int retry_flag;
int ret = 0;
unsigned int idx;
/* These sizes look to be limited by the FX2 firmware implementation */
@@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
break;
}
- retry_flag = 0;
- try_count++;
ret = 0;
wrData[0] = 0;
wrData[1] = cmd;
@@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
}
if (rdData[0] (poll_count 1000)) continue;
if (!rdData[0]) {
- retry_flag = !0;
pvr2_trace(
PVR2_TRACE_ERROR_LEGS,
- Encoder timed out waiting for us
- ; arranging to retry);
+ Encoder timed out waiting for us);
} else {
pvr2_trace(
PVR2_TRACE_ERROR_LEGS,
@@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
ret = -EBUSY;
break;
}
- if (retry_flag) {
- if (try_count 20) continue;
- pvr2_trace(
- PVR2_TRACE_ERROR_LEGS,
- Too many retries...);
- ret = -EBUSY;
- }
if (ret) {
del_timer_sync(hdw-encoder_run_timer);
hdw-state_encoder_ok = 0;
--
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
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: rt-mutex usage in i2c
On Sat, Mar 14, 2015 at 1:32 PM, Wolfram Sang w...@the-dreams.de wrote:
On Sat, Mar 14, 2015 at 12:27:03PM +0100, Wolfram Sang wrote:
Hi Sebastian,
- i2c_transfer() has this piece:
2091 if (in_atomic() || irqs_disabled()) {
2092 ret = i2c_trylock_adapter(adap);
is this irqs_disabled() is what bothers me and should not be there.
pxa does a spin_lock_irq() which would enable interrupts on return /
too early.
mxs has a wait_for_completion() which needs irqs enabled _and_ makes
in_atomic() problematic, too. I have't checked other drivers but the
commit, that introduced it, does not explain why it is required.
That was some time ago, but as far as I remember, PIO in i2c_pxa was
required to enable communication with PMIC in interrupt context.
I haven't really looked into it, but a quick search gave me this thread
explaining the intention of the code in question:
http://lists.lm-sensors.org/pipermail/i2c/2007-November/002268.html
Regards,
Wolfram
And adding a recent mail address from Mike to cc.
--
Sincerely yours,
Mike.
--
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
Disappearing dvb-usb stick IT9137FN (Kworld 499-2T)
Hi I have the above usb stick (dual frontend) which works fine for a while then just vanishes. ie: frontend just goes eg ls /dev/dvb (I have a permanent DVB card as well) /dev/dvb/adapter0 /dev/dvb/adapter1 /dev/dvb/adapter2 goes to ls /dev/dvb (I have a permanent DVB card as well) /dev/dvb/adapter0 To get it back I have plug/unplug several times (rebooting the box seems to make no difference) I am currently on fedora 21, but this seems to be a continual issue , through at least fedora 18 to date I cant see anything obvious in dmesg or the logs Any ideas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] media/usb/pvrusb2: Support for V4L2_CTRL_WHICH_DEF_VAL
The code you've added is carefully checking the return pointer from
pvr2_hdw_get_ctrl_v4l() yet the original code did not operate this way.
The result is that now there's this unbalanced effect where it appears
that the validity of the pvr2_ctrl instance is only checked on one side
of the if-statement. I would recommend instead to elevate the call to
pvr2_hdw_get_ctrl_v4l() out of the if-statement - since in both cases
it's being called the same way both times. Then do the validity check
in that one spot and that simplifies the if-statement all the way down
to choosing between pvr2_ctrl_get_value() vs pvr2_ctrl_get_def().
It's not a correctness comment; what you have should work fine. So I'm
ack'ing this in any case:
Acked-By: Mike Isely is...@pobox.com
But you can do the above pretty easily safely, and simplify it a bit
further.
-Mike
On Fri, 21 Aug 2015, Ricardo Ribalda Delgado wrote:
This driver does not use the control infrastructure.
Add support for the new field which on structure
v4l2_ext_controls
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index 1c5f85bf7ed4..43b2f2214798 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -628,6 +628,7 @@ static int pvr2_g_ext_ctrls(struct file *file, void *priv,
struct pvr2_v4l2_fh *fh = file-private_data;
struct pvr2_hdw *hdw = fh-channel.mc_head-hdw;
struct v4l2_ext_control *ctrl;
+ struct pvr2_ctrl *cptr;
unsigned int idx;
int val;
int ret;
@@ -635,8 +636,18 @@ static int pvr2_g_ext_ctrls(struct file *file, void
*priv,
ret = 0;
for (idx = 0; idx ctls-count; idx++) {
ctrl = ctls-controls + idx;
- ret = pvr2_ctrl_get_value(
+ if (ctls-which == V4L2_CTRL_WHICH_DEF_VAL) {
+ cptr = pvr2_hdw_get_ctrl_v4l(hdw, ctrl-id);
+ if (cptr)
+ pvr2_ctrl_get_def(cptr, val);
+ else
+ ret = -EINVAL;
+
+
+ } else
+ ret = pvr2_ctrl_get_value(
pvr2_hdw_get_ctrl_v4l(hdw, ctrl-id), val);
+
if (ret) {
ctls-error_idx = idx;
return ret;
@@ -658,6 +669,10 @@ static int pvr2_s_ext_ctrls(struct file *file, void
*priv,
unsigned int idx;
int ret;
+ /* Default value cannot be changed */
+ if (ctls-which == V4L2_CTRL_WHICH_DEF_VAL)
+ return -EINVAL;
+
ret = 0;
for (idx = 0; idx ctls-count; idx++) {
ctrl = ctls-controls + idx;
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] i2c/adv7511: Fix license, set to GPL v2
Header claims GPL v2, so make the MODULE_LICENSE reflect that properly. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- drivers/gpu/drm/i2c/adv7511_core.c | 2 +- drivers/media/i2c/adv7511.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/adv7511_core.c b/drivers/gpu/drm/i2c/adv7511_core.c index 2564b5d..12e8134 100644 --- a/drivers/gpu/drm/i2c/adv7511_core.c +++ b/drivers/gpu/drm/i2c/adv7511_core.c @@ -956,4 +956,4 @@ module_exit(adv7511_exit); MODULE_AUTHOR(Lars-Peter Clausen l...@metafoo.de); MODULE_DESCRIPTION(ADV7511 HDMI transmitter driver); -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 02d76c6..1a4275d 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -41,7 +41,7 @@ MODULE_PARM_DESC(debug, debug level (0-2)); MODULE_DESCRIPTION(Analog Devices ADV7511 HDMI Transmitter Device Driver); MODULE_AUTHOR(Hans Verkuil); -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); #define MASK_ADV7511_EDID_RDY_INT 0x04 #define MASK_ADV7511_MSEN_INT 0x40 -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] imageon-bridge: Add module license information
Comment header specifies GPL-2, so add a MODULE_LICENSE(GPL v2).
This fixes the driver failing to load when built as module:
imageon_bridge: module license 'unspecified' taints kernel.
imageon_bridge: Unknown symbol ...
As an extra service, also add a description.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
drivers/media/platform/imageon-bridge.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/imageon-bridge.c
b/drivers/media/platform/imageon-bridge.c
index 9550695..a69b6da 100644
--- a/drivers/media/platform/imageon-bridge.c
+++ b/drivers/media/platform/imageon-bridge.c
@@ -317,3 +317,6 @@ static struct platform_driver imageon_bridge_driver = {
.remove = imageon_bridge_remove,
};
module_platform_driver(imageon_bridge_driver);
+
+MODULE_DESCRIPTION(Imageon video bridge);
+MODULE_LICENSE(GPL v2);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c/adv7511: Fix license, set to GPL v2
Header claims GPL v2, so make the MODULE_LICENSE reflect that properly. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- drivers/media/i2c/adv7511.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 95bcd40..497ee00 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -40,7 +40,7 @@ MODULE_PARM_DESC(debug, debug level (0-2)); MODULE_DESCRIPTION(Analog Devices ADV7511 HDMI Transmitter Device Driver); MODULE_AUTHOR(Hans Verkuil); -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); #define MASK_ADV7511_EDID_RDY_INT 0x04 #define MASK_ADV7511_MSEN_INT 0x40 -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] i2c/adv7511: Fix license, set to GPL v2
Okay, I split it up and sent it to the proper lists. Just noticed I forgot to set the in-reply-to headers though. Hope that won't be a problem. On 11-08-15 13:45, Hans Verkuil wrote: Hi Mike, Please split up this patch: these are two different drivers with different authors and different subsystems. The media/i2c/adv7511.c patch I can handle, but the patch for the drm driver should go to the dri-devel mailinglist. I can't take that change. Easiest is just to post two patches, one for each driver. Regards, Hans On 07/28/15 12:57, Mike Looijmans wrote: Header claims GPL v2, so make the MODULE_LICENSE reflect that properly. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- drivers/gpu/drm/i2c/adv7511_core.c | 2 +- drivers/media/i2c/adv7511.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/adv7511_core.c b/drivers/gpu/drm/i2c/adv7511_core.c index 2564b5d..12e8134 100644 --- a/drivers/gpu/drm/i2c/adv7511_core.c +++ b/drivers/gpu/drm/i2c/adv7511_core.c @@ -956,4 +956,4 @@ module_exit(adv7511_exit); MODULE_AUTHOR(Lars-Peter Clausen l...@metafoo.de); MODULE_DESCRIPTION(ADV7511 HDMI transmitter driver); -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 02d76c6..1a4275d 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -41,7 +41,7 @@ MODULE_PARM_DESC(debug, debug level (0-2)); MODULE_DESCRIPTION(Analog Devices ADV7511 HDMI Transmitter Device Driver); MODULE_AUTHOR(Hans Verkuil); -MODULE_LICENSE(GPL); +MODULE_LICENSE(GPL v2); #define MASK_ADV7511_EDID_RDY_INT 0x04 #define MASK_ADV7511_MSEN_INT 0x40 Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] media/usb/pvrusb2: Support for V4L2_CTRL_WHICH_DEF_VAL
Looks good to me (still), including now the change I had previously
suggested. For the record, the ack still applies. (I guess you can
consider this to be an ack of the ack...)
-Mike
On Thu, 29 Oct 2015, Ricardo Ribalda Delgado wrote:
> This driver does not use the control infrastructure.
> Add support for the new field which on structure
> v4l2_ext_controls
>
> Acked-by: Mike Isely <is...@pobox.com>
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> ---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index 1c5f85bf7ed4..81f788b7b242 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -628,6 +628,7 @@ static int pvr2_g_ext_ctrls(struct file *file, void *priv,
> struct pvr2_v4l2_fh *fh = file->private_data;
> struct pvr2_hdw *hdw = fh->channel.mc_head->hdw;
> struct v4l2_ext_control *ctrl;
> + struct pvr2_ctrl *cptr;
> unsigned int idx;
> int val;
> int ret;
> @@ -635,8 +636,15 @@ static int pvr2_g_ext_ctrls(struct file *file, void
> *priv,
> ret = 0;
> for (idx = 0; idx < ctls->count; idx++) {
> ctrl = ctls->controls + idx;
> - ret = pvr2_ctrl_get_value(
> - pvr2_hdw_get_ctrl_v4l(hdw, ctrl->id), );
> + cptr = pvr2_hdw_get_ctrl_v4l(hdw, ctrl->id);
> + if (cptr) {
> + if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + pvr2_ctrl_get_def(cptr, );
> + else
> + ret = pvr2_ctrl_get_value(cptr, );
> + } else
> + ret = -EINVAL;
> +
> if (ret) {
> ctls->error_idx = idx;
> return ret;
> @@ -658,6 +666,10 @@ static int pvr2_s_ext_ctrls(struct file *file, void
> *priv,
> unsigned int idx;
> int ret;
>
> + /* Default value cannot be changed */
> + if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + return -EINVAL;
> +
> ret = 0;
> for (idx = 0; idx < ctls->count; idx++) {
> ctrl = ctls->controls + idx;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
Geniatech / Mygica T230
Hi, I can't get this dvb-t2 USB device to work despite the linuxtv site claiming it is working since 3.19 kernel. I tried talking to the driver team on IRC a few months ago and they said they would look at it but I have recently pulled the linuxtv git tree and compiled it on my Linux Mint 4.09 kernel system and it has not changed. Below is the output of a typical tuning attempt: mp@Aurorabox ~ $ dvbv5-scan uk-CrystalPalace -I CHANNEL Scanning frequency #1 49000 Lock (0x1f) C/N= 28.25dB ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x11c0 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1200 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1240 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1280 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1600 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1640 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1680 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x16c0 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1700 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1740 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1780 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1804 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1a40 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1a80 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1ac0 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1b00 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1c00 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the NIT table ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the SDT table WARNING: no SDT table - storing channel(s) without their names Storing Service ID 4164: '490.00MHz#4164' Storing Service ID 4287: '490.00MHz#4287' Storing Service ID 4288: '490.00MHz#4288' Storing Service ID 4352: '490.00MHz#4352' Storing Service ID 4416: '490.00MHz#4416' Scanning frequency #2 51400 Lock (0x1f) Signal= -29.00dBm C/N= 21.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #3 545833000 Lock (0x1f) Signal= -30.00dBm C/N= 31.00dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #4 50600 Lock (0x1f) Signal= -30.00dBm C/N= 28.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #5 48200 Lock (0x1f) Signal= -30.00dBm C/N= 21.75dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #6 529833000 Lock (0x1f) Signal= -29.00dBm C/N= 21.75dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #7 53800 Lock (0x1f) Signal= -29.00dBm C/N= 16.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #8 57000 Lock (0x1f) Signal= -46.00dBm C/N= 26.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #9 58600 Lock (0x1f) Signal= -39.00dBm C/N= 26.25dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table mp@Aurorabox ~ $ -- 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: Geniatech / Mygica T230
f you want, you can add the latest media_tree to ~any kernel by following the instruction there ok, noted but I doubt that will help in your case * [crope] (cr...@otitsun.oulu.fi): Antti Palosaari www.palosaari.fi * [crope] #linuxtv * [crope] kornbluth.freenode.net :Frankfurt, Germany * [crope] idle 96:04:21, signon: Mon Jul 27 14:42:22 * [crope] End of WHOIS list. On 6 November 2015 at 06:34, Olli Salonen <olli.salo...@iki.fi> wrote: > Hi Mike, > > Can you also paste the dmesg output here, so we can see if the driver > is starting up correctly? > > Cheers, > -olli > > On 3 November 2015 at 23:35, Mike Parkins <mike.bbcn...@gmail.com> wrote: >> Hi, >> I can't get this dvb-t2 USB device to work despite the linuxtv site >> claiming it is working since 3.19 kernel. I tried talking to the driver >> team on IRC a few months ago and they said they would look at it but I have >> recently pulled the linuxtv git tree and compiled it on my Linux Mint 4.09 >> kernel system and it has not changed. Below is the output of a typical >> tuning attempt: >> >> mp@Aurorabox ~ $ dvbv5-scan uk-CrystalPalace -I CHANNEL >> Scanning frequency #1 49000 >> Lock (0x1f) C/N= 28.25dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x11c0 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1200 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1240 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1280 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1600 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1640 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1680 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x16c0 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1700 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1740 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1780 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1804 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1a40 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1a80 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1ac0 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1b00 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1c00 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the NIT table >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the SDT table >> WARNING: no SDT table - storing channel(s) without their names >> Storing Service ID 4164: '490.00MHz#4164' >> Storing Service ID 4287: '490.00MHz#4287' >> Storing Service ID 4288: '490.00MHz#4288' >> Storing Service ID 4352: '490.00MHz#4352' >> Storing Service ID 4416: '490.00MHz#4416' >> Scanning frequency #2 51400 >> Lock (0x1f) Signal= -29.00dBm C/N= 21.50dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while waiting for PAT table >> Scanning frequency #3 545833000 >> Lock (0x1f) Signal= -30.00dBm C/N= 31.00dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while waiting for PAT table >> Scanning frequency #4 50600 >> Lock (0x1f) Signal= -30.00dBm C/N= 28.50dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while waiting for PAT table >> Scanning frequency #5 48200 >> Lock (0x1f) Signal= -30.00dBm C/N= 21.75dB >> ERRORdvb_read_sections: no dat
Questions about dvbv5-scan (missing fields)
Hi I hope this is the right list to ask. I am looking at using dvbv5 for one of my projects. However there are some fields that I cant seem to get, in particular tsid pmt service_type (TV?Radio etc) net netid example output in VDR format CBS Drama:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14640:0:0:0: Showcase TV:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:15296:0:0:0: Box Nation:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14416:0:0:0: Horror Channel:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6129:6130,6131:0:0:14480:0:0:0: 365 Travel:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14784:0:0:0: Television X:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:15232:0:0:0: 5 USA:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6689:6690,6691:0:0:12992:0:0:0: 5*:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6673:6674,6675:0:0:12928:0:0:0: QUEST:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6929:6930,6931:0:0:14498:0:0:0: A can be seen there is loads of zeros where entries should be thanks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] include sys/sysmacros.h for major() & minor()
Linux C libraries are looking to disentangle sysmacros.h from the sys/types.h header to clean up namespace pollution. Since these macros are provided in glibc/etc... today, switch to pulling in this header directly. Signed-off-by: Mike Frysinger <vap...@gentoo.org> --- contrib/test/mc_nextgen_test.c| 1 + lib/libv4lconvert/control/libv4lcontrol.c | 1 + utils/libmedia_dev/get_media_devices.c| 1 + utils/media-ctl/libmediactl.c | 1 + 4 files changed, 4 insertions(+) diff --git a/contrib/test/mc_nextgen_test.c b/contrib/test/mc_nextgen_test.c index a62fd13..4ba37b0 100644 --- a/contrib/test/mc_nextgen_test.c +++ b/contrib/test/mc_nextgen_test.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include diff --git a/lib/libv4lconvert/control/libv4lcontrol.c b/lib/libv4lconvert/control/libv4lcontrol.c index 3c8335c..59f28b1 100644 --- a/lib/libv4lconvert/control/libv4lcontrol.c +++ b/lib/libv4lconvert/control/libv4lcontrol.c @@ -20,6 +20,7 @@ */ #include +#include #include #include #include diff --git a/utils/libmedia_dev/get_media_devices.c b/utils/libmedia_dev/get_media_devices.c index e3a2200..edfeb41 100644 --- a/utils/libmedia_dev/get_media_devices.c +++ b/utils/libmedia_dev/get_media_devices.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c index 4a82d24..16dddbe 100644 --- a/utils/media-ctl/libmediactl.c +++ b/utils/media-ctl/libmediactl.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: core: urb make use of usb_endpoint_maxp_mult
Since usb_endpoint_maxp now returns only lower 11 bits mult
calculation here isn't correct anymore and that breaks webcam
for me. Patch make use of usb_endpoint_maxp_mult instead of
direct calculation.
Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return
only packet size")
Signed-off-by: Mike Krinkin <krinkin@gmail.com>
---
drivers/usb/core/urb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 0be49a1..d75cb8c 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -412,11 +412,8 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
}
/* "high bandwidth" mode, 1-3 packets/uframe? */
- if (dev->speed == USB_SPEED_HIGH) {
- int mult = 1 + ((max >> 11) & 0x03);
- max &= 0x07ff;
- max *= mult;
- }
+ if (dev->speed == USB_SPEED_HIGH)
+ max *= usb_endpoint_maxp_mult(>desc);
if (urb->number_of_packets <= 0)
return -EINVAL;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb/media/pvrusb2: warning in pvr2_send_request_ex/usb_submit_urb
What you have here is way beyond just feeding random crap in via the syscall interface. To cause this you have to fake the presence of a pvrusb2 compatible *hardware* USB device and then lie about its endpoint configuration. Is that really a concern here? Are we now saying that any kernel driver which talks via USB must now also specifically verify the exact expected USB endpoint configuration? Where does that end? How about the vendor-specific RPC protocol that the hardware actually implements over the bulk endpoint? It's likely that the pvrusb2 driver may be making assumptions about the expected responses over that protocol. Please realize that I'm not dismissing this. I can see some merit in this. But I'm just a bit surprised that now we're going this far. Is this really the intention? You're talking about code (pvrusb2_send_request_ex()) that hasn't changed in about 10 years. With this level of paranoia there's got to be a pretty target-rich environment over the set of kernel-supported USB devices. To take this another step, wouldn't that same level of paranoia be a concern for any externally connected PCI-Express device? Because that's another external way into the computer that involves very non-trivial and very hardware-centric protocols. Thunderbolt devices would be an example of this. -Mike On Wed, 20 Sep 2017, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > There seems to be no check on endpoint type before submitting bulk urb > in pvr2_send_request_ex(). > > usb 1-1: New USB device found, idVendor=2040, idProduct=7500 > usb 1-1: New USB device strings: Mfr=0, Product=255, SerialNumber=0 > usb 1-1: Product: a > gadgetfs: configuration #6 > pvrusb2: Hardware description: WinTV HVR-1950 Model 750xx > usb 1-1: BOGUS urb xfer, pipe 3 != type 1 > [ cut here ] > WARNING: CPU: 1 PID: 2713 at drivers/usb/core/urb.c:449 > usb_submit_urb+0xf8a/0x11d0 > Modules linked in: > CPU: 1 PID: 2713 Comm: pvrusb2-context Not tainted > 4.14.0-rc1-42251-gebb2c2437d80 #210 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: 88006b7a18c0 task.stack: 880069978000 > RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 > RSP: 0018:88006997f990 EFLAGS: 00010286 > RAX: 0029 RBX: 880063661900 RCX: > RDX: 0029 RSI: 86876d60 RDI: ed000d32ff24 > RBP: 88006997fa90 R08: 11000d32fdca R09: > R10: R11: R12: 11000d32ff39 > R13: 0001 R14: 0003 R15: 880068bbed68 > FS: () GS:88006c60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 01032000 CR3: 6a0ff000 CR4: 06f0 > Call Trace: > pvr2_send_request_ex+0xa57/0x1d80 > drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3645 > pvr2_hdw_check_firmware drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1812 > pvr2_hdw_setup_low drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2107 > pvr2_hdw_setup drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2250 > pvr2_hdw_initialize+0x548/0x3c10 drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2327 > pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:118 > pvr2_context_thread_func+0x361/0x8c0 > drivers/media/usb/pvrusb2/pvrusb2-context.c:167 > kthread+0x3a1/0x470 kernel/kthread.c:231 > ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 > Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 ee 82 89 fe 45 89 > e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 40 c0 ea 86 e8 30 1b dc fc <0f> > ff e9 9b f7 ff ff e8 aa 95 25 fd e9 80 f7 ff ff e8 50 74 f3 > ---[ end trace 6919030503719da6 ]--- > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
Re: [PATCH 05/24] media: v4l2-dev: convert VFL_TYPE_* into an enum
Acked-By: Mike Isely <is...@pobox.com>
On Mon, 9 Oct 2017, Mauro Carvalho Chehab wrote:
> Using enums makes easier to document, as it can use kernel-doc
> markups. It also allows cross-referencing, with increases the
> kAPI readability.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> Documentation/media/kapi/v4l2-dev.rst | 17 ++---
> drivers/media/pci/cx88/cx88-blackbird.c | 3 +-
> drivers/media/pci/cx88/cx88-video.c | 10 +++---
> drivers/media/pci/cx88/cx88.h | 4 +--
> drivers/media/pci/saa7134/saa7134-video.c | 2 ++
> drivers/media/usb/cx231xx/cx231xx-video.c | 2 ++
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 2 ++
> drivers/media/usb/tm6000/tm6000-video.c | 2 ++
> drivers/media/v4l2-core/v4l2-dev.c| 10 +++---
> include/media/v4l2-dev.h | 59
> +--
> include/media/v4l2-mediabus.h | 30
> 11 files changed, 98 insertions(+), 43 deletions(-)
>
> diff --git a/Documentation/media/kapi/v4l2-dev.rst
> b/Documentation/media/kapi/v4l2-dev.rst
> index b29aa616c267..7bb0505b60f1 100644
> --- a/Documentation/media/kapi/v4l2-dev.rst
> +++ b/Documentation/media/kapi/v4l2-dev.rst
> @@ -196,11 +196,18 @@ device.
> Which device is registered depends on the type argument. The following
> types exist:
>
> -- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
> -- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed
> captions, teletext)
> -- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
> -- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
> -- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors
> +==
> ==
> +:c:type:`vfl_devnode_type` Device nameUsage
> +==
> ==
> +``VFL_TYPE_GRABBER`` ``/dev/videoX`` for video input/output
> devices
> +``VFL_TYPE_VBI`` ``/dev/vbiX`` for vertical blank data
> (i.e.
> + closed captions, teletext)
> +``VFL_TYPE_RADIO`` ``/dev/radioX`` for radio tuners
> +``VFL_TYPE_SUBDEV````/dev/v4l-subdevX`` for V4L2 subdevices
> +``VFL_TYPE_SDR`` ``/dev/swradioX`` for Software Defined Radio
> + (SDR) tuners
> +``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX`` for touch sensors
> +==
> ==
>
> The last argument gives you a certain amount of control over the device
> device node number used (i.e. the X in ``videoX``). Normally you will pass -1
> diff --git a/drivers/media/pci/cx88/cx88-blackbird.c
> b/drivers/media/pci/cx88/cx88-blackbird.c
> index e3101f04941c..0e0952e60795 100644
> --- a/drivers/media/pci/cx88/cx88-blackbird.c
> +++ b/drivers/media/pci/cx88/cx88-blackbird.c
> @@ -805,8 +805,7 @@ static int vidioc_querycap(struct file *file, void *priv,
>
> strcpy(cap->driver, "cx88_blackbird");
> sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
> }
>
> static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
> diff --git a/drivers/media/pci/cx88/cx88-video.c
> b/drivers/media/pci/cx88/cx88-video.c
> index 7d25ecd4404b..9be682cdb644 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -806,8 +806,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void
> *priv,
> return 0;
> }
>
> -void cx88_querycap(struct file *file, struct cx88_core *core,
> -struct v4l2_capability *cap)
> +int cx88_querycap(struct file *file, struct cx88_core *core,
> + struct v4l2_capability *cap)
> {
> struct video_device *vdev = video_devdata(file);
>
> @@ -825,11 +825,14 @@ void cx88_querycap(struct file *file, struct cx88_core
> *core,
> case VFL_TYPE_VBI:
> cap->device_caps |= V4L2_CAP_VBI_CAPTURE;
> break;
> + default:
> + return -EINVAL;
> }
> cap->capabilities = cap->device_caps | V4L2_CAP_VIDEO_CAPTURE |
> V4L2_CAP_VBI_CAPTURE | V4L2_CAP_DEVICE_CAPS;
> if (core->board.radio.type == CX88_RADIO)
> cap->capabilities |= V4L2_CAP_RADIO;
> + return 0;
> }
> EXPORT_SYMBOL(cx88_querycap);
>
GP fault in cx18 module from v4l-dvb drivers on linuxtv.org (Ubuntu 17.04)
Having a problem with a #GP fault when loading the cx18 driver from v4l-dvb from the linuxtv.org site. Device: Hauppauge HVR-1600 (lspci output at pastebin.com/e7G52kqQ) (ATSC signals) Environment: Ubuntu 17.04, kernel 4.10.0-33-generic, 64-bit Hardware: Motherboard: Gigabyte GA-B150M-D3H (16GB RAM) I've downloaded the v4l-dvb kernel drivers, built them, and installed them. I was unable to use the built-in drivers as I needed the cx18-i2c driver. >From the stack trace included with the pastebin link above it appears the problem is in find_ref_lock() when called from c18_probe() if that helps immediately. Things I've tried: -- Remove kernel drivers/Reboot/Install v4l-dvb drivers/build/install/modprobe -- Do a 'make rminstall' to remove drivers and attempt install/modprobe again I found it interesting that even though the #GP happens and the /dev entries are not created, the cx18 module still loads (as found with lsmod) but no cx18-i2c was loaded.
Re: [PATCH] media: pvrusb2: Convert timers to use timer_setup()
Ack'ed (separate formal reply)
-Mike
On Wed, 25 Oct 2017, Kees Cook wrote:
> Eek, sorry, this uses timer_setup_on_stack() which is only in -next.
> If you can Ack this, I can carry it in the timer tree.
>
> Thanks!
>
> -Kees
>
> On Tue, Oct 24, 2017 at 5:22 PM, Kees Cook <keesc...@chromium.org> wrote:
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to pass the timer pointer explicitly.
> >
> > Cc: Mike Isely <is...@pobox.com>
> > Cc: Mauro Carvalho Chehab <mche...@kernel.org>
> > Cc: linux-media@vger.kernel.org
> > Signed-off-by: Kees Cook <keesc...@chromium.org>
> > ---
> > drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 64
> > ++---
> > 1 file changed, 36 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > index ad5b25b89699..8289ee482f49 100644
> > --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > @@ -330,10 +330,10 @@ static void pvr2_hdw_state_log_state(struct pvr2_hdw
> > *);
> > static int pvr2_hdw_cmd_usbstream(struct pvr2_hdw *hdw,int runFl);
> > static int pvr2_hdw_commit_setup(struct pvr2_hdw *hdw);
> > static int pvr2_hdw_get_eeprom_addr(struct pvr2_hdw *hdw);
> > -static void pvr2_hdw_quiescent_timeout(unsigned long);
> > -static void pvr2_hdw_decoder_stabilization_timeout(unsigned long);
> > -static void pvr2_hdw_encoder_wait_timeout(unsigned long);
> > -static void pvr2_hdw_encoder_run_timeout(unsigned long);
> > +static void pvr2_hdw_quiescent_timeout(struct timer_list *);
> > +static void pvr2_hdw_decoder_stabilization_timeout(struct timer_list *);
> > +static void pvr2_hdw_encoder_wait_timeout(struct timer_list *);
> > +static void pvr2_hdw_encoder_run_timeout(struct timer_list *);
> > static int pvr2_issue_simple_cmd(struct pvr2_hdw *,u32);
> > static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> > unsigned int timeout,int probe_fl,
> > @@ -2373,18 +2373,15 @@ struct pvr2_hdw *pvr2_hdw_create(struct
> > usb_interface *intf,
> > }
> > if (!hdw) goto fail;
> >
> > - setup_timer(>quiescent_timer, pvr2_hdw_quiescent_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(>quiescent_timer, pvr2_hdw_quiescent_timeout, 0);
> >
> > - setup_timer(>decoder_stabilization_timer,
> > - pvr2_hdw_decoder_stabilization_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(>decoder_stabilization_timer,
> > + pvr2_hdw_decoder_stabilization_timeout, 0);
> >
> > - setup_timer(>encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(>encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> > + 0);
> >
> > - setup_timer(>encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(>encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> > 0);
> >
> > hdw->master_state = PVR2_STATE_DEAD;
> >
> > @@ -3539,10 +3536,16 @@ static void pvr2_ctl_read_complete(struct urb *urb)
> > complete(>ctl_done);
> > }
> >
> > +struct hdw_timer {
> > + struct timer_list timer;
> > + struct pvr2_hdw *hdw;
> > +};
> >
> > -static void pvr2_ctl_timeout(unsigned long data)
> > +static void pvr2_ctl_timeout(struct timer_list *t)
> > {
> > - struct pvr2_hdw *hdw = (struct pvr2_hdw *)data;
> > + struct hdw_timer *timer = from_timer(timer, t, timer);
> > + struct pvr2_hdw *hdw = timer->hdw;
> > +
> > if (hdw->ctl_write_pend_flag || hdw->ctl_read_pend_flag) {
> > hdw->ctl_timeout_flag = !0;
> > if (hdw->ctl_write_pend_flag)
> > @@ -3564,7 +3567,10 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> > {
> > unsigned int idx;
> > int status = 0;
> > - struct timer_list timer;
> > + struct hdw_timer timer = {
> > + .hdw = hdw,
> > + };
> > +
> > if (!hdw->ctl_lock_held) {
> > pvr2_trace(PVR2_TRACE_ERROR_LEGS,
> >"Atte
Re: [PATCH] media: pvrusb2: Convert timers to use timer_setup()
Acked-By: Mike Isely <is...@pobox.com>
On Tue, 24 Oct 2017, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Mike Isely <is...@pobox.com>
> Cc: Mauro Carvalho Chehab <mche...@kernel.org>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 64
> ++---
> 1 file changed, 36 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index ad5b25b89699..8289ee482f49 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -330,10 +330,10 @@ static void pvr2_hdw_state_log_state(struct pvr2_hdw *);
> static int pvr2_hdw_cmd_usbstream(struct pvr2_hdw *hdw,int runFl);
> static int pvr2_hdw_commit_setup(struct pvr2_hdw *hdw);
> static int pvr2_hdw_get_eeprom_addr(struct pvr2_hdw *hdw);
> -static void pvr2_hdw_quiescent_timeout(unsigned long);
> -static void pvr2_hdw_decoder_stabilization_timeout(unsigned long);
> -static void pvr2_hdw_encoder_wait_timeout(unsigned long);
> -static void pvr2_hdw_encoder_run_timeout(unsigned long);
> +static void pvr2_hdw_quiescent_timeout(struct timer_list *);
> +static void pvr2_hdw_decoder_stabilization_timeout(struct timer_list *);
> +static void pvr2_hdw_encoder_wait_timeout(struct timer_list *);
> +static void pvr2_hdw_encoder_run_timeout(struct timer_list *);
> static int pvr2_issue_simple_cmd(struct pvr2_hdw *,u32);
> static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> unsigned int timeout,int probe_fl,
> @@ -2373,18 +2373,15 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface
> *intf,
> }
> if (!hdw) goto fail;
>
> - setup_timer(>quiescent_timer, pvr2_hdw_quiescent_timeout,
> - (unsigned long)hdw);
> + timer_setup(>quiescent_timer, pvr2_hdw_quiescent_timeout, 0);
>
> - setup_timer(>decoder_stabilization_timer,
> - pvr2_hdw_decoder_stabilization_timeout,
> - (unsigned long)hdw);
> + timer_setup(>decoder_stabilization_timer,
> + pvr2_hdw_decoder_stabilization_timeout, 0);
>
> - setup_timer(>encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> - (unsigned long)hdw);
> + timer_setup(>encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> + 0);
>
> - setup_timer(>encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> - (unsigned long)hdw);
> + timer_setup(>encoder_run_timer, pvr2_hdw_encoder_run_timeout, 0);
>
> hdw->master_state = PVR2_STATE_DEAD;
>
> @@ -3539,10 +3536,16 @@ static void pvr2_ctl_read_complete(struct urb *urb)
> complete(>ctl_done);
> }
>
> +struct hdw_timer {
> + struct timer_list timer;
> + struct pvr2_hdw *hdw;
> +};
>
> -static void pvr2_ctl_timeout(unsigned long data)
> +static void pvr2_ctl_timeout(struct timer_list *t)
> {
> - struct pvr2_hdw *hdw = (struct pvr2_hdw *)data;
> + struct hdw_timer *timer = from_timer(timer, t, timer);
> + struct pvr2_hdw *hdw = timer->hdw;
> +
> if (hdw->ctl_write_pend_flag || hdw->ctl_read_pend_flag) {
> hdw->ctl_timeout_flag = !0;
> if (hdw->ctl_write_pend_flag)
> @@ -3564,7 +3567,10 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> {
> unsigned int idx;
> int status = 0;
> - struct timer_list timer;
> + struct hdw_timer timer = {
> + .hdw = hdw,
> + };
> +
> if (!hdw->ctl_lock_held) {
> pvr2_trace(PVR2_TRACE_ERROR_LEGS,
> "Attempted to execute control transfer without
> lock!!");
> @@ -3621,8 +3627,8 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> hdw->ctl_timeout_flag = 0;
> hdw->ctl_write_pend_flag = 0;
> hdw->ctl_read_pend_flag = 0;
> - setup_timer(, pvr2_ctl_timeout, (unsigned long)hdw);
> - timer.expires = jiffies + timeout;
> + timer_setup_on_stack(, pvr2_ctl_timeout, 0);
> + timer.timer.expires = jiffies + timeout;
>
> if (write_len && write_data) {
> hdw->cmd_debug_state = 2;
> @@ -3677,7 +3683,7 @@ status);
> }
>
> /* Start timer */
> - add_timer();
> + add_timer();
>
> /* Now wait for all I/O to complete */
Re: dvb usb issues since kernel 4.9
On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote:
>
> I've previously experienced that you can be affected by the scheduler
> granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y):
>
> $ grep -H . /proc/sys/kernel/sched_*_granularity_ns
> /proc/sys/kernel/sched_min_granularity_ns:225
> /proc/sys/kernel/sched_wakeup_granularity_ns:300
>
> The above numbers were confirmed on the RPi2 (see[2]). With commit
> 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that
> softirq processing latency is bounded by the sched_wakeup_granularity_ns,
> which with 3 ms is not good enough for their use-case.
Note of caution wrt twiddling sched_wakeup_granularity_ns: it must
remain < sched_latency_ns/2 else you effectively disable wakeup
preemption completely, turning CFS into a tick granularity scheduler.
-Mike
ITE IT9303FN: af9035_ctrl_msg: command=2b failed fw error=21
Hi guys, I'm not sure if this is the right place to post this. I have this card http://www.gadgetaddict.net/myphone-dtv-dongle/ Is there a chance to get this working on the Raspberry Pi 3 based on below's dmesg output? [ 2412.224084] usb 1-1: new high-speed USB device number 10 using ehci-pci [ 2412.582937] usb 1-1: New USB device found, idVendor=048d, idProduct=9306 [ 2412.582943] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 2412.643448] [1746] usb 1-1: dvb_usbv2_probe: bInterfaceNumber=0 [ 2412.643463] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 0b 00 00 00 03 02 00 00 12 22 db ea [ 2412.648672] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 07 00 00 01 06 93 6b f9 [ 2412.648684] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 0b 00 00 01 01 02 00 00 38 4f ad c6 [ 2412.652713] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 05 01 00 83 7b ff [ 2412.652722] usb 1-1: dvb_usb_af9035: prechip_version=83 chip_version=01 chip_type=9306 [ 2412.652727] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 06 00 22 02 01 fd dc [ 2412.656734] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 08 02 00 00 00 00 00 fd ff [ 2412.656743] [1746] usb 1-1: af9035_identify_state: reply=00 00 00 00 [ 2412.656747] usb 1-1: dvb_usb_v2: found a 'ITE 9303 Generic' in cold state [ 2412.656750] [1746] usb 1-1: dvb_usbv2_download_firmware: [ 2412.656810] usb 1-1: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9303-01.fw' [ 2412.656814] [1746] usb 1-1: af9035_download_firmware: [ 2412.656818] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 0b 00 00 03 01 02 00 00 49 c5 35 b5 [ 2412.661103] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 05 03 00 00 fc ff [ 2412.661116] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 04 03 00 00 03 41 00 03 41 80 06 41 93 1a 02 12 bf 02 41 93 22 00 00 a2 af e4 33 90 7c 00 f0 a2 dd e4 33 a3 f0 7e 4b 7f fc 7c 44 7d ca 7b 04 12 a1 aa 4b [ 2412.666246] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 04 00 fb ff [ 2412.666258] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=48 [ 2412.666285] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 05 03 00 00 01 41 ad 29 5f e4 ff 74 3b 2f f5 82 e4 34 f5 f5 83 74 ff f0 0f ef b4 40 ee c2 dd c2 af 74 89 90 f5 3b f0 74 41 a3 f0 74 4c 90 f5 5b f0 4b 6b [ 2412.670091] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 05 00 fa ff [ 2412.670102] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=96 [ 2412.670108] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 06 03 00 00 01 41 d6 29 74 00 a3 f0 74 2f 90 f5 3d f0 74 f5 a3 f0 74 44 90 f5 5d f0 74 76 a3 f0 74 89 90 f5 3f f0 74 2c a3 f0 74 44 90 f5 5f f0 74 fc 3e [ 2412.673737] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 06 00 f9 ff [ 2412.673747] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=144 [ 2412.673753] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 07 03 00 00 01 41 ff 29 68 a3 f0 74 89 90 f5 41 f0 74 31 a3 f0 74 44 90 f5 61 f0 74 6f a3 f0 74 87 90 f5 43 f0 74 59 a3 f0 74 43 90 f5 63 f0 74 04 9e b5 [ 2412.678121] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 07 00 f8 ff [ 2412.678133] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=192 [ 2412.678138] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 08 03 00 00 01 42 28 29 a3 f0 74 87 90 f5 45 f0 74 e1 a3 f0 74 43 90 f5 65 f0 74 e3 a3 f0 74 88 90 f5 47 f0 74 3a a3 f0 74 42 90 f5 67 f0 74 a2 a3 57 e0 [ 2412.681865] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 08 00 f7 ff [ 2412.681875] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=240 [ 2412.681882] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 09 03 00 00 01 42 51 29 f0 90 f5 3a e0 54 fe 44 01 f0 c2 ae c2 8e 43 8e 10 d2 df 75 c0 50 53 89 0f 43 89 20 75 8b be 75 8d be d2 8e c2 c1 c2 ae d2 8d 0e [ 2412.685887] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 09 00 f6 ff [ 2412.685899] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=288 [ 2412.685906] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 0a 03 00 00 01 42 7a 29 be 12 88 3c e4 90 79 04 f0 90 d9 24 e0 54 fe 44 01 f0 e4 90 49 62 f0 90 7c 01 e0 24 ff 92 dd 90 7c 00 e0 24 ff 92 af 22 90 39 a9 [ 2412.690693] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 0a 00 f5 ff [ 2412.690704] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=336 [ 2412.690710] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 0b 03 00 00 01 42 a3 29 f7 04 e0 70 24 c2 ae c2 8e 43 8e 10 d2 df 75 c0 50 53 89 0f 43 89 20 75 8b be 75 8d be d2 8e c2 c1 c2 ae 90 49 62 f0 80 24 e6 0b [ 2412.695033] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 0b 00 f4 ff [ 2412.695044] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=384 [ 2412.695050] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 0c 03 00 00 01 42 cc 29 c2 ae c2 8e 43 8e 10 d2 df 75 c0 d0 53 89 0f 43 89 20 75 8b be 75 8d be d2 8e c2 c1 d2 ae 90 49 62 74 01 f0 d2 be 12 88 3c 80 ed [ 2412.698733] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 0c 00 f3 ff [ 2412.698742] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=432 [
Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating a new function and use it across
> > > the drivers.
> > >
> > > vm_insert_range is the new API which will be used to map a
> > > range of kernel memory/pages to user vma.
> > >
> > > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > > rk3288, rk3328 and rk3399 with graphics.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Reviewed-by: Matthew Wilcox
> > > Tested-by: Heiko Stuebner
> > > ---
> > > include/linux/mm_types.h | 3 +++
> > > mm/memory.c | 38 ++
> > > mm/nommu.c | 7 +++
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 5ed8f62..15ae24f 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > > struct mm_struct *mm,
> > > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > > unsigned long start, unsigned long end);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count);
> > > +
> >
> > This seem to belong to include/linux/mm.h, near vm_insert_page()
>
> Ok, I will change it. Apart from this change does it looks good ?
With this change you can add
Reviewed-by: Mike Rapoport
> >
> > > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > > {
> > > atomic_set(>tlb_flush_pending, 0);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 15c417e..84ea46c 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > >
> > > /**
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: pointer to array of source kernel pages
> > > + * @page_count: number of pages need to insert into user vma
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma. This is a generic function which drivers can use
> > > + * rather than using their own way of mapping range of kernel pages into
> > > + * user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously-inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully-inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context. Called by mmap handlers.
> > > + * Return: 0 on success and error code otherwise
> > > + */
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> > > +
> > > + for (i = 0; i < page_count; i++) {
> > > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > > + if (ret < 0)
> > > + return ret;
> > > + uaddr += PAGE_SIZE;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > +/**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > * @addr: target user address of this page
> > > diff --git a/mm/nommu.c b/mm/nommu.c
> > > index 749276b..d6ef5c7 100644
> > > --- a/mm/nommu.c
> > > +++ b/mm/nommu.c
> > > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > /*
> > > * sys_brk() for the most part doesn't need the global kernel
> > > * lock, except when an application is doing something nasty
> > > --
> > > 1.9.1
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
