RE: videobuf2 and VMAs
Hello, On Friday, June 10, 2011 1:21 AM Jonathan Corbet wrote: I'm finally getting around to trying to really understand videobuf2. In the process I've run into something which has thrown me for a bit of a loop... /** * vb2_get_vma() - acquire and lock the virtual memory area * @vma: given virtual memory area * * This function attempts to acquire an area mapped in the userspace for * the duration of a hardware operation. The area is locked by performing * the same set of operation that are done when process calls fork() and * memory areas are duplicated. * * Returns a copy of a virtual memory region on success or NULL. */ This function makes a copy of the VMA which is completely outside of the knowledge of the mm subsystem. For the life of me, I cannot figure out why that is a wise or necessary thing to do. You are not locking the real VMA in any way. If you're worried about the underlying pages going away somehow, this will not save you. User space can still munmap() the space whenever it feels like it. This vb2_get_vma() function mimics the fork() situation, where the vma structures are cloned and transferred to the new process. All these operations are performed to ensure that the memory that is behind this vma will not go away. This means that the following operations are performed: if there exists a backing file behind the vma, its ref count is increased (simulates open() call), the vma is copied (in case of fork the vma structures are also copied) and vm_open() method is called. This way even if the user will munmap() the original area and close the fd in his process, the vma (the copied fake vma structure) will still exist and can be used by vb2 for calling vm_close() method once the client of that memory finished his access. This ensures that the memory (underlying pages or pfns) that have been grabbed by vb2_get_vma() are still available until the vb2_put_vma() call. This of course requires the driver to operate correctly - use vm_area ref counting and/or free resources on release method, but we cannot do anything more in vb2. This kind of operation, it seems, should really be done with get_user_pages(). Except that it seems that you're not really expecting user pages here - it looks like this is an attempt to support memory belonging to a different device which has been mapped into the process's address space? That might be a nice thing to try to document here. Right, get_user_page() is just one special case and it doesn't work with memory coming from mmaped device. You are definitely right that we should better document it. If you're worried about the file being closed, it might be better to save a reference directly. But having fake VMAs floating around worries me. I see, without additional comment this might be confusing, we will try to document it better. Moving on: /** * vb2_get_contig_userptr() - lock physically contiguous userspace mapped memory * @vaddr:starting virtual address of the area to be verified * @size: size of the area * @res_paddr:will return physical address for the given vaddr * @res_vma: will return locked copy of struct vm_area for the given area * * This function will go through memory area of size @size mapped at @vaddr and * verify that the underlying physical pages are contiguous. If they are * contiguous the virtual memory area is locked and a @res_vma is filled with * the copy and @res_pa set to the physical address of the buffer. [...] Since we've determined that you're expecting this buffer to be in somebody's device memory, the loop through the whole thing seems like a bit much. Testing the VMA flags for VM_IO and !VM_NONLINEAR seems like it should suffice? Or am I missing something? This is the first time I see VM_NONLINEAR, I will need to check how it is used. The loop was to ensure that memory is really contiguous, because nothing prevents other (unknown!) drivers to mmap the io memory in non-linear way. (FWIW, user space could conceivably create a contiguous buffer in anonymous memory by using hugepages. The current videobuf2 code won't support that - follow_pfn() will fail. Probably not going to be an issue anytime in the near future, but one never knows...) Right, this should be put into TODO list. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
Hi, The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. Do people really want to virtualize the whole xHCI controller, or just specific ports or devices to the guest operating system? SR/IOV support is an optional xHCI feature. As I understand it you can create a VF which looks like a real xHCI controller. This is partly done in hardware and partly by software. Then you can assign it some ressources (specific ports) and pass it to the guest. If just specific ports, would something like usbip be better for virtual machines, with the USB traffic going over the network connection between the guest/host? There are several ways depending on the use case. Usually the guest sees a (fully software emulated) host adapter with usb devices connected, where the usb devices can be (a) emulated too or (b) real usb devices passed through to the guest. The later is done by passing the guests requests to the real device via usbfs. One problem with emulating usb fully in software is the polling design of the hardware which makes the emulation quite cpu intensive. Using a xHCI VF should help here alot, but works for the pass through use case only of course. cheers, Gerd -- 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 mini-summit at LinuxCon Vancouver
Hi, On 06/10/2011 02:21 AM, Sarah Sharp wrote: I'm pleased to announce a USB mini-summit at LinuxCon Vancouver. What: USB mini-summit When: Tuesday, August 16th, all day Where: At the conference venue, room TBD pending confirmation from Angela Brown. Proposed topics include USB virtualization, and improved bandwidth APIs between the USB core and drivers (especially webcam drivers). See the detailed topic list below. Anyone is also welcome to propose or show up with a USB related topic. MUSB? USB 3.0 gadget drivers? USB-IP? I would like to give a short presentation on / demo off the usb redirection over the network (USB-IP replacement with a less dumb protocol) I've been working on, followed by a questions and answers session. For those who want to give this a try now, see: http://hansdegoede.livejournal.com/9682.html Sheets from the presentation I gave on this at FOSDEM: http://people.fedoraproject.org/~jwrdegoede/usb-redir.pdf The USB mini-summit does overlap with the virtualization mini-summit by a day, but I'm hoping we can schedule talks so some of the virtualization folks can make it to the USB mini-summit. The other option was on Friday during the conference which was not ideal. Proposed topics: Topic 1 --- The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. I'm not really happy with how the management / hand over of userspace to kernel space drivers and vice versa works. This is a problem when doing usb-redirection to a virtual machine. I think this is best discussed in a separate thread, and then if needed further discussed during the mini summit. I'll send a mail on this shortly. I'll use the same address list as this mail, except that I'm going to cut linux-kernel from the CC list. Topic 2 --- I'd also like to get the V4L and audio developers who work with USB devices together with the core USB folks to talk about bandwidth management under xHCI. One of the issues is that since the xHCI hardware does bandwidth management, not the xHCI driver, a schedule that will take too much bandwidth will get rejected much sooner than any USB driver currently expects (during a call to usb_set_interface). This poses issues, since most USB video drivers negotiate the video size and frame rate after they call usb_set_interface, so they don't know whether they can fall back to a less bandwidth-intensive setting. Currently, they just submit URBs with less and less bandwidth until one interval setting gets accepted that won't work under xHCI. A second issue is that that some drivers need less bandwidth than the device advertises, and the xHCI driver currently uses whatever periodic interval the device advertises in its descriptors. This is not what the video/audio driver wants, especially in the case of buggy high speed devices that advertise the interval in frames, not microframes. There needs to be some way for the drivers to communicate their bandwidth needs to the USB core. We've known about this issue for a while, and I think it's time to get everyone in the same room and hash out an API. Interesting, being able to tell the core how much bandwidth a device will actually use (versus what it claims as maxpacketsize in its descriptors) is something which we really need. I know of at least 2 usb1 webcam chipsets (and drivers) which have only 1 altsetting which claim 1023 bytes maxpacketsize. But they also have a register which allows the driver to configure how large the largest (iso) packet it sends will actually be. Currently these drivers have this beauty to be able to tell the linux usb core that they won't be using 1023 as maxpacketsize but something else, and thus function without needing full usb1 bandwidth: struct usb_host_interface *alt; alt = gspca_dev-dev-config-intf_cache[0]-altsetting[1]; alt-endpoint[0].desc.wMaxPacketSize = cpu_to_le16(packet_size); ret = usb_set_interface(gspca_dev-dev, gspca_dev-iface, 1); Yes they are overwriting the kernels cached descriptors ... ### Something which I would also like to bring to everyone's attention is that we really need to fix the ehci schedule code wrt scheduling usb1 transfers over usb2 hubs. The current code is very broken when it comes to periodic transfers, it basically disallows using the last microframe (let alone the crossing of the frame boundary and using the first microframe of the next frame). This means that trying to submit isoc transfers with a size of 1023 will just plain fail, even if this is the only device on the entire bus. This is one of the reasons I ended up
Improving kernel - userspace (usbfs) usb device hand off
Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. First of all an example use case scenarios where the current API falls short. 1) Redirection of USB devices to a virtual machine, qemu, vbox, etc. all have the ability to redirect a USB device to the virtual machine, and they all use usbfs for this. The first thing which will happen here when the user selects a device to redirect is a IOCTL_USBFS_DISCONNECT. This causes the kernel driver to see a device unplug, with no chances for the kernel driver to do anything against this. Now lets say the user does the following: -write a file to a usb flash disk -redirect the flash disk to a vm Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. Again not good. ### So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem b) It will allow for example a v4l2 driver to keep its /dev/video node around Note that b) means that the normal disconnect handler should still be called after a soft reconnect on a real disconnect. 2) A usb_driver soft_reconnect callback to match the soft_disconnect 3) A mechanism for a usb_driver to signal a usbfs fd owner of the device it would like the device back. So for example the gvfs mount can be automatically unmounted (if not busy). 4) A IOCTL_USBFS_SOFT_DISCONNECT ioctl which will call the drivers soft_disconnect if it has one, and otherwise fall back to the regular disconnect. 5) A method for a usbfs fd owning app to know the device driver would like the device back. I suggest using poll with POLLIN to signal this. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] adp1653: Add driver for LED flash controller
Laurent Pinchart wrote: Hi Sakari, On Monday 16 May 2011 15:00:39 Sakari Ailus wrote: This patch adds the driver for the adp1653 LED flash controller. This controller supports a high power led in flash and torch modes and an indicator light, sometimes also called privacy light. The adp1653 is used on the Nokia N900. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Signed-off-by: Tuukka Toivonen tuukka...@gmail.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: David Cohen daco...@gmail.com [snip] +v4l2_ctrl_new_std(flash-ctrls, adp1653_ctrl_ops, + V4L2_CID_FLASH_FAULT, 0, V4L2_FLASH_FAULT_OVER_VOLTAGE + | V4L2_FLASH_FAULT_OVER_TEMPERATURE + | V4L2_FLASH_FAULT_SHORT_CIRCUIT, 0, 0); You need to mark the fault control as volatile. Thanks for catching this! I'll fix it for the pull req. Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. that sounds quite weird. Should only happen if still image and video functions are on different configurations or different alt-settings of the same interface. But if they are on same configurations and separate interfaces, you should be able to bind gphoto to the still image interface and v4l2 to the camera interface. How's the device setup ? So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? -- balbi signature.asc Description: Digital signature
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On 06/10/2011 10:22 AM, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. that sounds quite weird. Should only happen if still image and video functions are on different configurations or different alt-settings of the same interface. But if they are on same configurations and separate interfaces, you should be able to bind gphoto to the still image interface and v4l2 to the camera interface. How's the device setup ? These are very cheap devices, and as such poorly designed. There still and webcam functionality is on the same interface. This is likely done this way because the devices cannot handle both functions at the same time. So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot be reliably done from userspace. Where as it is trivial to do this from kernel space. One could advocate to make the existing disconnect ioctl use the new soft_disconnect usb_driver callback instead of adding a new usbfs ioctl for this, but that means that a driver can block any and all userspace triggered disconnects. Where as having a new ioctl, means that apps which want to play nice can play nice, while keeping the possibility of a hard userspace initiated disconnect. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 10:36:47AM +0200, Hans de Goede wrote: On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. that sounds quite weird. Should only happen if still image and video functions are on different configurations or different alt-settings of the same interface. But if they are on same configurations and separate interfaces, you should be able to bind gphoto to the still image interface and v4l2 to the camera interface. How's the device setup ? These are very cheap devices, and as such poorly designed. There still and webcam functionality is on the same interface. This is likely done this way because the devices cannot handle both functions at the same time. ok got it. So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot in that case, why don't you just flush all data and continue ? Also, desktop manager knows that a particular device mounted, so it could also ask the user if s/he wants to continue. I'm not sure preventing a disconnect is a good thing. be reliably done from userspace. Where as it is trivial to do this from kernel space. One could advocate to make the existing disconnect ioctl use the new soft_disconnect usb_driver callback instead of adding a new usbfs ioctl for this, but that means that a driver can block any and all userspace triggered disconnects. Where as having a new ioctl, means that apps which want to play nice can play nice, while keeping the possibility of a hard userspace initiated disconnect. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. OTOH, if the user really wants to move the usb device to the guest OS, he has just requested for that, so should we prevent it ? what we need is for the applications to be notified to exit cleanly and release the device because the user has requested to do so. No ? -- balbi signature.asc Description: Digital signature
Re: TechniSat SkyStar S2 / CX24120-13Z again
Jannis Achstetter jannis_achstetter at web.de wrote: [...] I can't test functionality right now since I'm not at home where the device is but I will test first thing when I get home. The card works absolutely fine. So it's not more than applying a single patch against 2.6.39.1 to get the card supported (+ a firmware file from userspace). I modified the patch a little to get rid of two compilation warnings and will modify it further to comply with kernel coding-style rules and post it to this list then. Jannis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l2_ctrl_new_std_volatile()?
Hi Hans, The v4l2_ctrl_new_std() doesn't allow setting the is_volatile bit in the bit field. The adp1653 driver needs that for the faults control. Would you prefer just setting the bit in the driver, or, as Laurent suggested, a new v4l2_ctrl_new_std_volatile() function which would mark the control as volatile by itself? Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Fri, Jun 10, 2011 at 6:47 AM, Jonathan Corbet cor...@lwn.net wrote: Hi, Kassey, I've been looking at the driver some to understand how you're using the hardware. One quick question: The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. Since you're limited to contiguous DMA (does the PXA910 even support scatter/gather mode?), PXA910 supports scatter/gather mode, but we did not use that. USERPTR is going to be very limiting. Is the application mapping I/O memory elsewhere in the system with the expectation of having the video frames go directly there? Could you tell me how that works? I'd like to understand the use case here. USERPTR is popular on Android Camera HAL implementation.. we alloc memory in user space by PMEM, and QBUF to driver, once DMA finished the buffer, we DQBUF and send the buffer address to display DMA directly. or doing encode. MMAP can not offer big size memory, for 720P resolution, when running Android. FWIW, I believe that videobuf2 would support the MMAP mode with no additional effort on your part; any reason why you haven't enabled that? you are right. I just enabled it on videobuf, and I will try to enable it on videobuf2, too. thanks. Thanks, jon -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2_ctrl_new_std_volatile()?
On Friday, June 10, 2011 10:47:09 Sakari Ailus wrote: Hi Hans, The v4l2_ctrl_new_std() doesn't allow setting the is_volatile bit in the bit field. The adp1653 driver needs that for the faults control. Would you prefer just setting the bit in the driver, or, as Laurent suggested, a new v4l2_ctrl_new_std_volatile() function which would mark the control as volatile by itself? Just set the bit in the driver. If this will start happening a lot, then we can consider adding a special function for this, but volatile controls are still pretty rare and I do not think it warrants a special function just for that. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: soc_camera_set_fmt in soc_camera_open
On Fri, 10 Jun 2011, Kassey Lee wrote: hi, Guennadi: in drivers/media/video/soc_camera.c static int soc_camera_open(struct file *file) it will call soc_camera_set_fmt to configure the sensor and host controller. for sensor, this means it will trigger download setting, this may take quite time through i2c or SPI. I complain about this, because after we open, request, s_param, S_FMT, DQBUF, in S_FMT, we will download the setting again. how do you think ? If it's a concern for you, you might consider moving most of your sensor set up from .s_(mbus_)fmt() to .s_stream(). Would that solve your problem? Thanks Guennadi /* * Try to configure with default parameters. Notice: this is the * very first open, so, we cannot race against other calls, * apart from someone else calling open() simultaneously, but * .video_lock is protecting us against it. */ ret = soc_camera_set_fmt(icd, f); if (ret 0) goto esfmt; -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. --- 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
[GIT PATCHES FOR 3.1] Add autofoo/foo and control event support
Hi Mauro, This patch series adds support for handling autofoo/foo type controls (e.g. autogain/gain, autoexposure/exposure, etc) and adds a new event for control changes, either a value or a status change. The changes against the RFCv3 patch series are minor: one small bug was fixed in the autofoo/foo support (a cluster_walk started one element too far) and I removed the v4l2_ctrl_handler_cnt that I added earlier. I'm working on a much better solution for this. See this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg32552.html So I decided not to add something that I'm going to remove soon anyway. Test code is available in qv4l2 from here: http://git.linuxtv.org/hverkuil/v4l-utils.git?a=shortlog;h=refs/heads/core It's been tested with vivi and ivtv. We (Cisco) have also been using an older version of this patch series at work for the past 2-3 months. I have added some additional notes to the various patches below. Regards, Hans The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git core8 Hans Verkuil (18): v4l2-ctrls: introduce call_op define v4l2-ctrls: simplify error_idx handling. v4l2-ctrls: drivers should be able to ignore the READ_ONLY flag v4l2-ioctl: add ctrl_handler to v4l2_fh v4l2-subdev: implement per-filehandle control handlers. v4l2-ctrls: fix and improve volatile control handling. v4l2-controls.txt: update to latest v4l2-ctrl.c changes. v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios DocBook: Improve cluster documentation and document the new autoclusters. vivi: add autogain/gain support to test the autocluster functionality. These patches above all deal with autocluster support. I'm hoping that this set of patches can at least be merged since once this is in I can work on converting soc-camera to the control framework. That work depends on the autocluster support. v4l2-ctrls: add v4l2_fh pointer to the set control functions. vb2_poll: don't start DMA, leave that to the first read(). v4l2-ctrls: add control events. v4l2-ctrls: simplify event subscription. V4L2 spec: document control events. vivi: support control events. ivtv: add control event support. This set adds support for the new control events. v4l2-compat-ioctl32: add VIDIOC_DQEVENT support. This adds a missing compat32 conversion. It didn't matter much in the past that this was missing, but control events are something that are much more likely to be used in a 32-bit app running in a 64-bit OS, so it is now more important to do this right. Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 17 +- .../DocBook/media/v4l/vidioc-subscribe-event.xml | 142 +- Documentation/video4linux/v4l2-controls.txt| 69 - drivers/media/radio/radio-wl1273.c |2 +- drivers/media/radio/wl128x/fmdrv_v4l2.c|2 +- drivers/media/video/ivtv/ivtv-fileops.c| 34 +-- drivers/media/video/ivtv/ivtv-ioctl.c |2 + drivers/media/video/saa7115.c |4 +- drivers/media/video/v4l2-compat-ioctl32.c | 37 +++ drivers/media/video/v4l2-ctrls.c | 332 drivers/media/video/v4l2-device.c |1 + drivers/media/video/v4l2-event.c | 130 ++-- drivers/media/video/v4l2-fh.c |6 +- drivers/media/video/v4l2-ioctl.c | 40 ++- drivers/media/video/v4l2-subdev.c | 14 +- drivers/media/video/videobuf2-core.c | 17 +- drivers/media/video/vivi.c | 53 +++- include/linux/videodev2.h | 29 ++- include/media/v4l2-ctrls.h | 92 +- include/media/v4l2-event.h |2 + include/media/v4l2-fh.h|2 + kernel/compat.c|1 + 22 files changed, 851 insertions(+), 177 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. Sakari Ailus (3): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 283 Documentation/DocBook/media/v4l/v4l2.xml |9 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 485 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 62 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1058 insertions(+), 5 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] mm: alloc_contig_freed_pages() added
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This commit introduces alloc_contig_freed_pages() function
which allocates (ie. removes from buddy system) free pages
in range. Caller has to guarantee that all pages in range
are in buddy system.
Along with this function, a free_contig_pages() function is
provided which frees all (or a subset of) pages allocated
with alloc_contig_free_pages().
Michal Nazarewicz has modified the function to make it easier
to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
return pfn of one-past-the-last allocated page.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h |3 ++
mm/page_alloc.c| 44
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 58cdbac..f1417ed 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -32,6 +32,9 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
*/
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+extern unsigned long alloc_contig_freed_pages(unsigned long start,
+ unsigned long end, gfp_t flag);
+extern void free_contig_pages(struct page *page, int nr_pages);
/*
* For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4e8985a..00e9b24 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5600,6 +5600,50 @@ out:
spin_unlock_irqrestore(zone-lock, flags);
}
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
+ gfp_t flag)
+{
+ unsigned long pfn = start, count;
+ struct page *page;
+ struct zone *zone;
+ int order;
+
+ VM_BUG_ON(!pfn_valid(start));
+ zone = page_zone(pfn_to_page(start));
+
+ spin_lock_irq(zone-lock);
+
+ page = pfn_to_page(pfn);
+ for (;;) {
+ VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ list_del(page-lru);
+ order = page_order(page);
+ zone-free_area[order].nr_free--;
+ rmv_page_order(page);
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
+ pfn += 1 order;
+ if (pfn = end)
+ break;
+ VM_BUG_ON(!pfn_valid(pfn));
+ page += 1 order;
+ }
+
+ spin_unlock_irq(zone-lock);
+
+ /* After this, pages in the range can be freed one be one */
+ page = pfn_to_page(start);
+ for (count = pfn - start; count; --count, ++page)
+ prep_new_page(page, 0, flag);
+
+ return pfn;
+}
+
+void free_contig_pages(struct page *page, int nr_pages)
+{
+ for (; nr_pages; --nr_pages, ++page)
+ __free_page(page);
+}
+
#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
--
1.7.1.569.g6f426
--
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 02/10] lib: genalloc: Generic allocator improvements
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit adds a gen_pool_alloc_aligned() function to the
generic allocator API. It allows specifying alignment for the
allocated block. This feature uses
the bitmap_find_next_zero_area_off() function.
It also fixes possible issue with bitmap's last element being
not fully allocated (ie. space allocated for chunk-bits is
not a multiple of sizeof(long)).
It also makes some other smaller changes:
- moves structure definitions out of the header file,
- adds __must_check to functions returning value,
- makes gen_pool_add() return -ENOMEM rater than -1 on error,
- changes list_for_each to list_for_each_entry, and
- makes use of bitmap_clear().
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: rebased and updated to Linux v3.0-rc1]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/genalloc.h | 50 ++--
lib/genalloc.c | 190 +++---
2 files changed, 138 insertions(+), 102 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 5bbebda..af44e88 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -11,28 +11,11 @@
#ifndef __GENALLOC_H__
#define __GENALLOC_H__
-/*
- * General purpose special memory pool descriptor.
- */
-struct gen_pool {
- rwlock_t lock;
- struct list_head chunks;/* list of chunks in this pool */
- int min_alloc_order;/* minimum allocation order */
-};
-/*
- * General purpose special memory pool chunk descriptor.
- */
-struct gen_pool_chunk {
- spinlock_t lock;
- struct list_head next_chunk;/* next chunk in pool */
- phys_addr_t phys_addr; /* physical starting address of memory
chunk */
- unsigned long start_addr; /* starting address of memory chunk */
- unsigned long end_addr; /* ending address of memory chunk */
- unsigned long bits[0]; /* bitmap for allocating memory chunk */
-};
-
-extern struct gen_pool *gen_pool_create(int, int);
+struct gen_pool;
+
+struct gen_pool *__must_check gen_pool_create(unsigned order, int nid);
+
extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
size_t, int);
@@ -53,7 +36,26 @@ static inline int gen_pool_add(struct gen_pool *pool,
unsigned long addr,
{
return gen_pool_add_virt(pool, addr, -1, size, nid);
}
-extern void gen_pool_destroy(struct gen_pool *);
-extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
-extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+void gen_pool_destroy(struct gen_pool *pool);
+
+unsigned long __must_check
+gen_pool_alloc_aligned(struct gen_pool *pool, size_t size,
+ unsigned alignment_order);
+
+/**
+ * gen_pool_alloc() - allocate special memory from the pool
+ * @pool: Pool to allocate from.
+ * @size: Number of bytes to allocate from the pool.
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses a first-fit algorithm.
+ */
+static inline unsigned long __must_check
+gen_pool_alloc(struct gen_pool *pool, size_t size)
+{
+ return gen_pool_alloc_aligned(pool, size, 0);
+}
+
+void gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size);
#endif /* __GENALLOC_H__ */
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 577ddf8..b41dd90 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -16,23 +16,46 @@
#include linux/genalloc.h
+/* General purpose special memory pool descriptor. */
+struct gen_pool {
+ rwlock_t lock; /* protects chunks list */
+ struct list_head chunks;/* list of chunks in this pool */
+ unsigned order; /* minimum allocation order */
+};
+
+/* General purpose special memory pool chunk descriptor. */
+struct gen_pool_chunk {
+ spinlock_t lock;/* protects bits */
+ struct list_head next_chunk;/* next chunk in pool */
+ phys_addr_t phys_addr; /* physical starting address of memory
chunk */
+ unsigned long start;/* start of memory chunk */
+ unsigned long size; /* number of bits */
+ unsigned long bits[0]; /* bitmap for allocating memory chunk */
+};
+
+
/**
- * gen_pool_create - create a new special memory pool
- * @min_alloc_order: log base 2 of number of bytes each bitmap bit represents
- * @nid: node id of the node the pool structure should be allocated on, or -1
+ * gen_pool_create() - create a new special memory pool
+ * @order: Log base 2 of number of bytes each bitmap bit
+ * represents.
+ * @nid: Node id of the node the pool structure should be allocated
+ *
[PATCH 06/10] mm: MIGRATE_CMA migration type added
From: Michal Nazarewicz m.nazarew...@samsung.com
The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.
This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).
It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory. Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.
To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: cleaned up Kconfig]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/mmzone.h | 43 ++
mm/Kconfig |8 -
mm/compaction.c| 10 +
mm/internal.h |3 ++
mm/page_alloc.c| 93 ++--
5 files changed, 130 insertions(+), 27 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c928dac..a2eeacf 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,37 @@
*/
#define PAGE_ALLOC_COSTLY_ORDER 3
-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE 1
-#define MIGRATE_MOVABLE 2
-#define MIGRATE_PCPTYPES 3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE 3
-#define MIGRATE_ISOLATE 4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+ MIGRATE_UNMOVABLE,
+ MIGRATE_RECLAIMABLE,
+ MIGRATE_MOVABLE,
+ MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
+ MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+ /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works. Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function. What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+ MIGRATE_CMA,
+#endif
+ MIGRATE_ISOLATE,/* can't allocate from here */
+ MIGRATE_TYPES
+};
+
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+# define is_migrate_cma(migratetype) false
+#endif
#define for_each_migratetype_order(order, type) \
for (order = 0; order MAX_ORDER; order++) \
@@ -54,6 +78,11 @@ static inline int get_pageblock_migratetype(struct page
*page)
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
}
+static inline bool is_pageblock_cma(struct page *page)
+{
+ return is_migrate_cma(get_pageblock_migratetype(page));
+}
+
struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long nr_free;
diff --git a/mm/Kconfig b/mm/Kconfig
index 8ca47a5..6ffedd8 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -189,7 +189,7 @@ config COMPACTION
config MIGRATION
bool Page migration
def_bool y
- depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
+ depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION ||
CMA_MIGRATE_TYPE
help
Allows the migration of the physical location of pages of processes
while the virtual addresses are not changed. This is useful in
@@ -198,6 +198,12 @@ config MIGRATION
pages as migration can relocate pages to satisfy a huge page
allocation instead of reclaiming.
+config CMA_MIGRATE_TYPE
+ bool
+ help
+ This enables the use the MIGRATE_CMA migrate type, which lets lets CMA
+ work on almost arbitrary memory range and not only inside
ZONE_MOVABLE.
+
config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
diff --git a/mm/compaction.c b/mm/compaction.c
index 021a296..6d013c3 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -119,6 +119,16 @@ static bool suitable_migration_target(struct page *page)
if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
return false;
+ /* Keep MIGRATE_CMA alone as well. */
+ /*
+* XXX Revisit. We currently cannot let compaction touch CMA
+* pages since
[PATCH 10/10] ARM: S5PV210: add CMA support for FIMC devices on Aquila board
This patch is an example how CMA can be activated for particular devices
in the system. It creates one CMA region and assigns it to all s5p-fimc
devices on Samsung Aquila S5PC110 board.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig |1 +
arch/arm/mach-s5pv210/mach-aquila.c | 26 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 37b5a97..c09a92c 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -64,6 +64,7 @@ menu S5PC110 Machines
config MACH_AQUILA
bool Aquila
select CPU_S5PV210
+ select CMA
select S3C_DEV_FB
select S5P_DEV_FIMC0
select S5P_DEV_FIMC1
diff --git a/arch/arm/mach-s5pv210/mach-aquila.c
b/arch/arm/mach-s5pv210/mach-aquila.c
index 4e1d8ff..8c404e5 100644
--- a/arch/arm/mach-s5pv210/mach-aquila.c
+++ b/arch/arm/mach-s5pv210/mach-aquila.c
@@ -21,6 +21,8 @@
#include linux/gpio_keys.h
#include linux/input.h
#include linux/gpio.h
+#include linux/cma.h
+#include linux/dma-mapping.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -650,6 +652,19 @@ static void __init aquila_map_io(void)
s5p_set_timer_source(S5P_PWM3, S5P_PWM4);
}
+unsigned long cma_area_start;
+unsigned long cma_area_size = 32 20;
+
+static void __init aquila_reserve(void)
+{
+ unsigned long ret = cma_reserve(cma_area_start, cma_area_size);
+
+ if (!IS_ERR_VALUE(ret)) {
+ cma_area_start = ret;
+ printk(KERN_INFO cma: reserved %ld bytes at %lx\n,
cma_area_size, cma_area_start);
+ }
+}
+
static void __init aquila_machine_init(void)
{
/* PMIC */
@@ -672,6 +687,16 @@ static void __init aquila_machine_init(void)
s3c_fb_set_platdata(aquila_lcd_pdata);
platform_add_devices(aquila_devices, ARRAY_SIZE(aquila_devices));
+
+ if (cma_area_start) {
+ struct cma *cma;
+ cma = cma_create(cma_area_start, cma_area_size);
+ if (cma) {
+ set_dev_cma_area(s5p_device_fimc0.dev, cma);
+ set_dev_cma_area(s5p_device_fimc1.dev, cma);
+ set_dev_cma_area(s5p_device_fimc2.dev, cma);
+ }
+ }
}
MACHINE_START(AQUILA, Aquila)
@@ -683,4 +708,5 @@ MACHINE_START(AQUILA, Aquila)
.map_io = aquila_map_io,
.init_machine = aquila_machine_init,
.timer = s5p_timer,
+ .reserve= aquila_reserve,
MACHINE_END
--
1.7.1.569.g6f426
--
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 01/10] lib: bitmap: Added alignment offset for bitmap_find_next_zero_area()
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit adds a bitmap_find_next_zero_area_off() function which
works like bitmap_find_next_zero_area() function expect it allows an
offset to be specified when alignment is checked. This lets caller
request a bit such that its number plus the offset is aligned
according to the mask.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/bitmap.h | 24 +++-
lib/bitmap.c | 22 --
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index dcafe0b..50e2c16 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -45,6 +45,7 @@
* bitmap_set(dst, pos, nbits) Set specified bit area
* bitmap_clear(dst, pos, nbits) Clear specified bit area
* bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area
+ * bitmap_find_next_zero_area_off(buf, len, pos, n, mask) as above
* bitmap_shift_right(dst, src, n, nbits) *dst = *src n
* bitmap_shift_left(dst, src, n, nbits) *dst = *src n
* bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src)
@@ -114,11 +115,24 @@ extern int __bitmap_weight(const unsigned long *bitmap,
int bits);
extern void bitmap_set(unsigned long *map, int i, int len);
extern void bitmap_clear(unsigned long *map, int start, int nr);
-extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
-unsigned long size,
-unsigned long start,
-unsigned int nr,
-unsigned long align_mask);
+
+extern unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask,
+ unsigned long align_offset);
+
+static inline unsigned long
+bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+ return bitmap_find_next_zero_area_off(map, size, start, nr,
+ align_mask, 0);
+}
extern int bitmap_scnprintf(char *buf, unsigned int len,
const unsigned long *src, int nbits);
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 41baf02..bad4f20 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -315,30 +315,32 @@ void bitmap_clear(unsigned long *map, int start, int nr)
}
EXPORT_SYMBOL(bitmap_clear);
-/*
+/**
* bitmap_find_next_zero_area - find a contiguous aligned zero area
* @map: The address to base the search on
* @size: The bitmap size in bits
* @start: The bitnumber to start searching at
* @nr: The number of zeroed bits we're looking for
* @align_mask: Alignment mask for zero area
+ * @align_offset: Alignment offset for zero area.
*
* The @align_mask should be one less than a power of 2; the effect is that
- * the bit offset of all zero areas this function finds is multiples of that
- * power of 2. A @align_mask of 0 means no alignment is required.
+ * the bit offset of all zero areas this function finds plus @align_offset
+ * is multiple of that power of 2.
*/
-unsigned long bitmap_find_next_zero_area(unsigned long *map,
-unsigned long size,
-unsigned long start,
-unsigned int nr,
-unsigned long align_mask)
+unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask,
+unsigned long align_offset)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
/* Align allocation */
- index = __ALIGN_MASK(index, align_mask);
+ index = __ALIGN_MASK(index + align_offset, align_mask) - align_offset;
end = index + nr;
if (end size)
@@ -350,7 +352,7 @@ again:
}
return index;
}
-EXPORT_SYMBOL(bitmap_find_next_zero_area);
+EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
/*
[PATCH 07/10] mm: MIGRATE_CMA isolation functions added
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit changes various functions that change pages and
pageblocks migrate type between MIGRATE_ISOLATE and
MIGRATE_MOVABLE in such a way as to allow to work with
MIGRATE_CMA migrate type.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h | 40 +++-
mm/page_alloc.c| 19 ---
mm/page_isolation.c| 15 ---
3 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index c5d1a7c..177b307 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -3,39 +3,53 @@
/*
* Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE,
+ * If specified range includes migrate types other than MOVABLE or CMA,
* this will fail with -EBUSY.
*
* For isolating all pages in the range finally, the caller have to
* free all pages in the range. test_page_isolated() can be used for
* test it.
*/
-extern int
-start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+int __start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
+
+static inline int
+start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
+
+int __undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
/*
* Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
* target range is [start_pfn, end_pfn)
*/
-extern int
-undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+static inline int
+undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
/*
- * test all pages in [start_pfn, end_pfn)are isolated or not.
+ * Test all pages in [start_pfn, end_pfn) are isolated or not.
*/
-extern int
-test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
+int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
/*
- * Internal funcs.Changes pageblock's migrate type.
- * Please use make_pagetype_isolated()/make_pagetype_movable().
+ * Internal functions. Changes pageblock's migrate type.
*/
-extern int set_migratetype_isolate(struct page *page);
-extern void unset_migratetype_isolate(struct page *page);
+int set_migratetype_isolate(struct page *page);
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype);
+static inline void unset_migratetype_isolate(struct page *page)
+{
+ __unset_migratetype_isolate(page, MIGRATE_MOVABLE);
+}
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
extern int alloc_contig_range(unsigned long start, unsigned long end,
- gfp_t flags);
+ gfp_t flags, unsigned migratetype);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c13c0dc..c5b78ad 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5641,7 +5641,7 @@ out:
return ret;
}
-void unset_migratetype_isolate(struct page *page)
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype)
{
struct zone *zone;
unsigned long flags;
@@ -5649,8 +5649,8 @@ void unset_migratetype_isolate(struct page *page)
spin_lock_irqsave(zone-lock, flags);
if (get_pageblock_migratetype(page) != MIGRATE_ISOLATE)
goto out;
- set_pageblock_migratetype(page, MIGRATE_MOVABLE);
- move_freepages_block(zone, page, MIGRATE_MOVABLE);
+ set_pageblock_migratetype(page, migratetype);
+ move_freepages_block(zone, page, migratetype);
out:
spin_unlock_irqrestore(zone-lock, flags);
}
@@ -5755,6 +5755,10 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
* @start: start PFN to allocate
* @end: one-past-the-last PFN to allocate
* @flags: flags passed to alloc_contig_freed_pages().
+ * @migratetype: migratetype of the underlaying pageblocks (either
+ * #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks
+ * in range must have the same migratetype and it must
+ * be either of the two.
*
* The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
* aligned, hovewer it's callers responsibility to guarantee that we
@@ -5766,7 +5770,7
[PATCH 09/10] ARM: integrate CMA with dma-mapping subsystem
This patch adds support for CMA to dma-mapping subsystem for ARM
architecture. CMA area can be defined individually for each device in
the system. This is up to the board startup code to create CMA area and
assign it to the devices.
Buffer alignment is derived from the buffer size, but for only for
buffers up to 1MiB. Larger buffers are aligned to 1MiB always.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/include/asm/device.h |3 ++
arch/arm/include/asm/dma-mapping.h | 19 +++
arch/arm/mm/dma-mapping.c | 60 +++-
3 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..942913e 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -10,6 +10,9 @@ struct dev_archdata {
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
+#ifdef CONFIG_CMA
+ struct cma *cma_area;
+#endif
};
struct pdev_archdata {
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 4fff837..e387ea7 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -14,6 +14,25 @@
#error Please update to __arch_pfn_to_dma
#endif
+struct cma;
+
+#ifdef CONFIG_CMA
+static inline struct cma *get_dev_cma_area(struct device *dev)
+{
+ return dev-archdata.cma_area;
+}
+
+static inline void set_dev_cma_area(struct device *dev, struct cma *cma)
+{
+ dev-archdata.cma_area = cma;
+}
+#else
+static inline struct cma *get_dev_cma_area(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
/*
* dma_to_pfn/pfn_to_dma/dma_to_virt/virt_to_dma are architecture private
* functions used internally by the DMA-mapping API to provide DMA
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82a093c..233e34a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -18,6 +18,7 @@
#include linux/device.h
#include linux/dma-mapping.h
#include linux/highmem.h
+#include linux/cma.h
#include asm/memory.h
#include asm/highmem.h
@@ -52,16 +53,36 @@ static u64 get_coherent_dma_mask(struct device *dev)
return mask;
}
+
+static struct page *__alloc_system_pages(size_t count, unsigned int order,
gfp_t gfp)
+{
+ struct page *page, *p, *e;
+
+ page = alloc_pages(gfp, order);
+ if (!page)
+ return NULL;
+
+ /*
+* Now split the huge page and free the excess pages
+*/
+ split_page(page, order);
+ for (p = page + count, e = page + (1 order); p e; p++)
+ __free_page(p);
+ return page;
+}
+
/*
* Allocate a DMA buffer for 'dev' of size 'size' using the
* specified gfp mask. Note that 'size' must be page aligned.
*/
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
- unsigned long order = get_order(size);
- struct page *page, *p, *e;
+ struct cma *cma = get_dev_cma_area(dev);
+ struct page *page;
+ size_t count = size PAGE_SHIFT;
void *ptr;
u64 mask = get_coherent_dma_mask(dev);
+ unsigned long order = get_order(count PAGE_SHIFT);
#ifdef CONFIG_DMA_API_DEBUG
u64 limit = (mask + 1) ~mask;
@@ -78,16 +99,19 @@ static struct page *__dma_alloc_buffer(struct device *dev,
size_t size, gfp_t gf
if (mask 0xULL)
gfp |= GFP_DMA;
- page = alloc_pages(gfp, order);
- if (!page)
- return NULL;
+ /*
+* First, try to allocate memory from contiguous area aligned up to 1MiB
+*/
+ page = cm_alloc(cma, count, order 8 ? 8 : order);
/*
-* Now split the huge page and free the excess pages
+* Fallback if contiguous alloc fails or is not available
*/
- split_page(page, order);
- for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
- __free_page(p);
+ if (!page)
+ page = __alloc_system_pages(count, order, gfp);
+
+ if (!page)
+ return NULL;
/*
* Ensure that the allocated pages are zeroed, and that any data
@@ -104,13 +128,19 @@ static struct page *__dma_alloc_buffer(struct device
*dev, size_t size, gfp_t gf
/*
* Free a DMA buffer. 'size' must be page aligned.
*/
-static void __dma_free_buffer(struct page *page, size_t size)
+static void __dma_free_buffer(struct device *dev, struct page *page, size_t
size)
{
- struct page *e = page + (size PAGE_SHIFT);
+ struct cma *cma = get_dev_cma_area(dev);
+ size_t count = size PAGE_SHIFT;
+ struct page *e = page + count;
- while (page e) {
- __free_page(page);
- page++;
+ if (cma) {
+ cm_free(cma, page, count);
+ } else {
+
[PATCH 05/10] mm: alloc_contig_range() added
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit adds the alloc_contig_range() function which tries
to allecate given range of pages. It tries to migrate all
already allocated pages that fall in the range thus freeing them.
Once all pages in the range are freed they are removed from the
buddy system thus allocated for the caller to use.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: renamed some variables for easier code reading]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h |2 +
mm/page_alloc.c| 144
2 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index f1417ed..c5d1a7c 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -34,6 +34,8 @@ extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
+extern int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 00e9b24..2cea044 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5638,6 +5638,150 @@ unsigned long alloc_contig_freed_pages(unsigned long
start, unsigned long end,
return pfn;
}
+static unsigned long pfn_to_maxpage(unsigned long pfn)
+{
+ return pfn ~(MAX_ORDER_NR_PAGES - 1);
+}
+
+static unsigned long pfn_to_maxpage_up(unsigned long pfn)
+{
+ return ALIGN(pfn, MAX_ORDER_NR_PAGES);
+}
+
+#define MIGRATION_RETRY5
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
+{
+ int migration_failed = 0, ret;
+ unsigned long pfn = start;
+
+ /*
+* Some code borrowed from KAMEZAWA Hiroyuki's
+* __alloc_contig_pages().
+*/
+
+ for (;;) {
+ pfn = scan_lru_pages(pfn, end);
+ if (!pfn || pfn = end)
+ break;
+
+ ret = do_migrate_range(pfn, end);
+ if (!ret) {
+ migration_failed = 0;
+ } else if (ret != -EBUSY
+ || ++migration_failed = MIGRATION_RETRY) {
+ return ret;
+ } else {
+ /* There are unstable pages.on pagevec. */
+ lru_add_drain_all();
+ /*
+* there may be pages on pcplist before
+* we mark the range as ISOLATED.
+*/
+ drain_all_pages();
+ }
+ cond_resched();
+ }
+
+ if (!migration_failed) {
+ /* drop all pages in pagevec and pcp list */
+ lru_add_drain_all();
+ drain_all_pages();
+ }
+
+ /* Make sure all pages are isolated */
+ if (WARN_ON(test_pages_isolated(start, end)))
+ return -EBUSY;
+
+ return 0;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end: one-past-the-last PFN to allocate
+ * @flags: flags passed to alloc_contig_freed_pages().
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, hovewer it's callers responsibility to guarantee that we
+ * are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * Returns zero on success or negative error code. On success all
+ * pages which PFN is in (start, end) are allocated for the caller and
+ * need to be freed with free_contig_pages().
+ */
+int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags)
+{
+ unsigned long outer_start, outer_end;
+ int ret;
+
+ /*
+* What we do here is we mark all pageblocks in range as
+* MIGRATE_ISOLATE. Because of the way page allocator work, we
+* align the range to MAX_ORDER pages so that page allocator
+* won't try to merge buddies from different pageblocks and
+* change MIGRATE_ISOLATE to some other migration type.
+*
+* Once the pageblocks are marked as MIGRATE_ISOLATE, we
+* migrate the pages from an unaligned range (ie. pages that
+* we are interested in). This will put all the pages in
+* range back to page allocator as MIGRATE_ISOLATE.
+*
+* When this is done, we take the pages in range from page
+* allocator removing them from the buddy system. This way
+* page
[PATCH 08/10] mm: cma: Contiguous Memory Allocator added
The Contiguous Memory Allocator is a set of functions that lets one initialise a region of memory which then can be used to perform allocations of contiguous memory chunks from. CMA allows for creation of separate contexts. Kernel is allowed to allocate movable pages within CMA's managed memory so that it can be used for page cache when CMA devices do not use it. On cm_alloc() request such pages are migrated out of CMA area to free required contiguous block. This code is heavily based on earlier works by Michal Nazarewicz. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Michal Nazarewicz min...@mina86.com --- include/linux/cma.h | 189 +++ mm/Kconfig | 21 +++ mm/Makefile |1 + mm/cma.c| 358 +++ 4 files changed, 569 insertions(+), 0 deletions(-) create mode 100644 include/linux/cma.h create mode 100644 mm/cma.c diff --git a/include/linux/cma.h b/include/linux/cma.h new file mode 100644 index 000..70a993c --- /dev/null +++ b/include/linux/cma.h @@ -0,0 +1,189 @@ +#ifndef __LINUX_CMA_H +#define __LINUX_CMA_H + +/* + * Contiguous Memory Allocator + * Copyright (c) 2010-2011 by Samsung Electronics. + * Written by: + * Michal Nazarewicz min...@mina86.com + * Marek Szyprowski m.szyprow...@samsung.com + */ + +/* + * Contiguous Memory Allocator + * + * The Contiguous Memory Allocator (CMA) makes it possible for + * device drivers to allocate big contiguous chunks of memory after + * the system has booted. + * + * It requires some machine- and/or platform-specific initialisation + * code which prepares memory ranges to be used with CMA and later, + * device drivers can allocate memory from those ranges. + * + * Why is it needed? + * + * Various devices on embedded systems have no scatter-getter and/or + * IO map support and require contiguous blocks of memory to + * operate. They include devices such as cameras, hardware video + * coders, etc. + * + * Such devices often require big memory buffers (a full HD frame + * is, for instance, more then 2 mega pixels large, i.e. more than 6 + * MB of memory), which makes mechanisms such as kmalloc() or + * alloc_page() ineffective. + * + * At the same time, a solution where a big memory region is + * reserved for a device is suboptimal since often more memory is + * reserved then strictly required and, moreover, the memory is + * inaccessible to page system even if device drivers don't use it. + * + * CMA tries to solve this issue by operating on memory regions + * where only movable pages can be allocated from. This way, kernel + * can use the memory for pagecache and when device driver requests + * it, allocated pages can be migrated. + * + * Driver usage + * + * CMA should not be used directly by the device drivers. It should + * be considered as helper framework for dma-mapping subsystm and + * respective (platform)bus drivers. + * + * The CMA client needs to have a pointer to a CMA context + * represented by a struct cma (which is an opaque data type). + * + * Once such pointer is obtained, a caller may allocate contiguous + * memory chunk using the following function: + * + * cm_alloc() + * + * This function returns a pointer to the first struct page which + * represent a contiguous memory chunk. This pointer + * may be used with the following function: + * + * cm_free()-- frees allocated contiguous memory + * + * Platform/machine integration + * + * CMA context must be created on platform or machine initialisation + * and passed to respective subsystem that will be a client for CMA. + * The latter may be done by a global variable or some filed in + * struct device. For the former CMA provides the following functions: + * + * cma_init_migratetype() + * cma_reserve() + * cma_create() + * + * The first one initialises a portion of reserved memory so that it + * can be used with CMA. The second first tries to reserve memory + * (using memblock) and then initialise it. + * + * The cma_reserve() function must be called when memblock is still + * operational and reserving memory with it is still possible. On + * ARM platform the reserve machine callback is a perfect place to + * call it. + * + * The last function creates a CMA context on a range of previously + * initialised memory addresses. Because it uses kmalloc() it needs + * to be called after SLAB is initialised. + */ + +/* Kernel level API */ + +#ifdef __KERNEL__ + +struct cma; +struct page; + +#ifdef CONFIG_CMA + +/** + * cma_init_migratetype() - initialises range of physical memory to be used + * with CMA context. + * @start: start address of the memory range in bytes. + * @size: size of the memory range in bytes. + * + *
[PATCHv10 0/10] Contiguous Memory Allocator
Hello everyone, Like I've promised during the Memory Management summit at Linaro Meeting in Budapest I continued the development of the CMA. The goal is to integrate it as tight as possible with other kernel subsystems (like memory management and dma-mapping) and finally merge to mainline. This version introduces integration with DMA-mapping subsystem for ARM architecture, but I believe that similar integration can be done for other archs too. I've also rebased all the code onto latest v3.0-rc2 kernel. A few words for these who see CMA for the first time: The Contiguous Memory Allocator (CMA) makes it possible for device drivers to allocate big contiguous chunks of memory after the system has booted. The main difference from the similar frameworks is the fact that CMA allows to transparently reuse memory region reserved for the big chunk allocation as a system memory, so no memory is wasted when no big chunk is allocated. Once the alloc request is issued, the framework will migrate system pages to create a required big chunk of physically contiguous memory. For more information see the changelog and links to previous versions of CMA framework. The current version of CMA is just an allocator that handles allocation of contiguous memory blocks. The difference between this patchset and Kamezawa's alloc_contig_pages() are: 1. alloc_contig_pages() requires MAX_ORDER alignment of allocations which may be unsuitable for embeded systems where a few MiBs are required. Lack of the requirement on the alignment means that several threads might try to access the same pageblock/page. To prevent this from happening CMA uses a mutex so that only one cm_alloc()/cm_free() function may run at one point. 2. CMA may use its own migratetype (MIGRATE_CMA) which behaves similarly to ZONE_MOVABLE but can be put in arbitrary places. This is required for us since we need to define two disjoint memory ranges inside system RAM. (ie. in two memory banks (do not confuse with nodes)). 3. alloc_contig_pages() scans memory in search for range that could be migrated. CMA on the other hand maintains its own allocator to decide where to allocate memory for device drivers and then tries to migrate pages from that part if needed. This is not strictly required but I somehow feel it might be faster. The integration with ARM DMA-mapping subsystem is quite straightforward. Once cma context is available alloc_pages() can be replaced by cm_alloc() call. Current version have been tested on Samsung S5PC110 based Aquila machine and s5p-fimc V4L2 driver. The driver itself uses videobuf2 dma-contig memory allocator, which in turn relies on dma_alloc_coherent() from DMA-mapping subsystem. By integrating CMA with DMA-mapping we manage to get this driver working with CMA without any single change required in the driver or videobuf2-dma-contig allocator. TODO: 1. use struct page * or pfn internally instead of physicall address 2. use some simple bitmap based allocator instead of genaloc 3. provide a function similar to dma_declare_coherent_memory(), which will created and register cma area for particular device 4. code cleanup and simplification 5. discussion 6. double-mapping issues with ARMv6+ and coherent memory Best regards -- Marek Szyprowski Samsung Poland RD Center Links to previous versions of the patchset: v9: http://article.gmane.org/gmane.linux.kernel.mm/60787 v8: http://article.gmane.org/gmane.linux.kernel.mm/56855 v7: http://article.gmane.org/gmane.linux.kernel.mm/55626 v6: http://article.gmane.org/gmane.linux.kernel.mm/55626 v5: (intentionally left out as CMA v5 was identical to CMA v4) lv4: http://article.gmane.org/gmane.linux.kernel.mm/52010 v3: http://article.gmane.org/gmane.linux.kernel.mm/51573 v2: http://article.gmane.org/gmane.linux.kernel.mm/50986 v1: http://article.gmane.org/gmane.linux.kernel.mm/50669 Changelog: v10: 1. Rebased onto 3.0-rc2 and resolved all conflicts 2. Simplified CMA to be just a pure memory allocator, for use with platfrom/bus specific subsystems, like dma-mapping. Removed all device specific functions are calls. 3. Integrated with ARM DMA-mapping subsystem. 4. Code cleanup here and there. 5. Removed private context support. v9: 1. Rebased onto 2.6.39-rc1 and resolved all conflicts 2. Fixed a bunch of nasty bugs that happened when the allocation failed (mainly kernel oops due to NULL ptr dereference). 3. Introduced testing code: cma-regions compatibility layer and videobuf2-cma memory allocator module. v8: 1. The alloc_contig_range() function has now been separated from CMA and put in page_allocator.c. This function tries to migrate all LRU pages in specified range and then allocate the range using alloc_contig_freed_pages(). 2. Support for MIGRATE_CMA has been separated from the CMA code. I have not tested if CMA
[PATCH 03/10] mm: move some functions from memory_hotplug.c to page_isolation.c
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Memory hotplug is a logic for making pages unused in the specified
range of pfn. So, some of core logics can be used for other purpose
as allocating a very large contigous memory block.
This patch moves some functions from mm/memory_hotplug.c to
mm/page_isolation.c. This helps adding a function for large-alloc in
page_isolation.c with memory-unplug technique.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
[m.nazarewicz: reworded commit message]
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: rebased and updated to Linux v3.0-rc1]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h |7 +++
mm/memory_hotplug.c| 111 --
mm/page_isolation.c| 115
3 files changed, 122 insertions(+), 111 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 051c1b1..58cdbac 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -33,5 +33,12 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+/*
+ * For migration.
+ */
+
+int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn);
+unsigned long scan_lru_pages(unsigned long start, unsigned long end);
+int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
#endif
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 9f64637..aee6dc0 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -637,117 +637,6 @@ int is_mem_section_removable(unsigned long start_pfn,
unsigned long nr_pages)
}
/*
- * Confirm all pages in a range [start, end) is belongs to the same zone.
- */
-static int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn)
-{
- unsigned long pfn;
- struct zone *zone = NULL;
- struct page *page;
- int i;
- for (pfn = start_pfn;
-pfn end_pfn;
-pfn += MAX_ORDER_NR_PAGES) {
- i = 0;
- /* This is just a CONFIG_HOLES_IN_ZONE check.*/
- while ((i MAX_ORDER_NR_PAGES) !pfn_valid_within(pfn + i))
- i++;
- if (i == MAX_ORDER_NR_PAGES)
- continue;
- page = pfn_to_page(pfn + i);
- if (zone page_zone(page) != zone)
- return 0;
- zone = page_zone(page);
- }
- return 1;
-}
-
-/*
- * Scanning pfn is much easier than scanning lru list.
- * Scan pfn from start to end and Find LRU page.
- */
-static unsigned long scan_lru_pages(unsigned long start, unsigned long end)
-{
- unsigned long pfn;
- struct page *page;
- for (pfn = start; pfn end; pfn++) {
- if (pfn_valid(pfn)) {
- page = pfn_to_page(pfn);
- if (PageLRU(page))
- return pfn;
- }
- }
- return 0;
-}
-
-static struct page *
-hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
-{
- /* This should be improved!! */
- return alloc_page(GFP_HIGHUSER_MOVABLE);
-}
-
-#define NR_OFFLINE_AT_ONCE_PAGES (256)
-static int
-do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
-{
- unsigned long pfn;
- struct page *page;
- int move_pages = NR_OFFLINE_AT_ONCE_PAGES;
- int not_managed = 0;
- int ret = 0;
- LIST_HEAD(source);
-
- for (pfn = start_pfn; pfn end_pfn move_pages 0; pfn++) {
- if (!pfn_valid(pfn))
- continue;
- page = pfn_to_page(pfn);
- if (!get_page_unless_zero(page))
- continue;
- /*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
-*/
- ret = isolate_lru_page(page);
- if (!ret) { /* Success */
- put_page(page);
- list_add_tail(page-lru, source);
- move_pages--;
- inc_zone_page_state(page, NR_ISOLATED_ANON +
- page_is_file_cache(page));
-
- } else {
-#ifdef CONFIG_DEBUG_VM
- printk(KERN_ALERT removing pfn %lx from LRU failed\n,
- pfn);
- dump_page(page);
-#endif
- put_page(page);
- /* Because we don't have big zone-lock. we should
- check this again here. */
- if
[PATCH] media: DVB_NET must depend on DVB_CORE
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/media/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index dc61895..c2ee0aa 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -87,7 +87,7 @@ config DVB_CORE config DVB_NET bool DVB Network Support default (NET INET) - depends on NET INET + depends on NET INET DVB_CORE help The DVB network support in the DVB core can optionally be disabled if this -- 1.7.2.5 -- 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/10] lib: genalloc: Generic allocator improvements
I am curious about one thing Why do we need this allocator. Why not use allocate_resource and friends. The kernel generic resource handler already handles object alignment and subranges. It just seems to be a surplus allocator that could perhaps be mostly removed by using the kernel resource allocator we already have ? Alan -- 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
Media_build does not compile due to errors in cx18-driver.h, cx18-driver.c and dvbdev.c /rc-main.c
Hans, Mauro:
I have tried to compile the sources at git://linuxtv.org/media_build.git,
using build.sh
At
cx18-driver.h:659:
struct workqueue_struct *out_work_queue;
char out_workq_name[12]; /* cx18-NN-out */
struct workqueue_struct *out_work_queue;
char out_workq_name[12]; /* cx18-NN-out */
cx18-driver.c:718
a similar problem occurs: the following code block is repeated:
static int __devinit cx18_create_out_workq(struct cx18 *cx)
{
snprintf(cx-out_workq_name, sizeof(cx-out_workq_name), %s-out,
cx-v4l2_dev.name);
cx-out_work_queue = create_workqueue(cx-out_workq_name);
if (cx-out_work_queue == NULL) {
CX18_ERR(Unable to create outgoing mailbox handler threads\n);
return -ENOMEM;
}
return 0;
}
static int __devinit cx18_create_out_workq(struct cx18 *cx)
{
snprintf(cx-out_workq_name, sizeof(cx-out_workq_name), %s-out,
cx-v4l2_dev.name);
cx-out_work_queue = create_workqueue(cx-out_workq_name);
if (cx-out_work_queue == NULL) {
CX18_ERR(Unable to create outgoing mailbox handler threads\n);
return -ENOMEM;
}
return 0;
}
Furthermore, there is an error that is present in three sources:
At
./v4l/dvbdev.c:466: twice:
the escape sequence \\ sould be replaced with \
./rc-main.c:1131: twice:
the escape sequence \\ sould be replaced with \
./v4l/v4l2-dev.c:782: twice:
the escape sequence \\ sould be replaced with \
--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: vb2: about vb2_queue-queued_count
Hello, On Wednesday, June 08, 2011 10:48 PM Uwe Kleine-König wrote: I'm still debugging my new video overlay device driver. The current problem is again when playing back a second video. After streamoff is called at the end of the first video, I disable the overlay and call vb2_buffer_done on the last buffer. This is exited early because vb-state == VB2_BUF_STATE_DEQUEUED. This results in vb-vb2_queue-queued_count being 1. Now if the new video starts I call vb2_queue_init in the .vidioc_reqbufs callback on my queue (that still has queued_count == 1). After vb2_queue_init returns queued_count is still 1 though q-queued_list is reset to be empty. __vb2_queue_cancel has a similar problem, q-queued_list is reset, but queued_count is not. Thanks again for finding the bug. You are right, __vb2_queue_cancel should reset queued_count too. I will post a patch soon. OTOH queued_count seems to be read only by vb2_wait_for_all_buffers which currently has no users. :-) Right, no mainline drive use it right now, but this function might be convenient for some standard drivers. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: vb2: reset queued_count value during queue reinitialization
queued_count variable was left untouched during the queue reinitialization in __vb2_queue_cancel, what might lead to mismatch between the real number of queued buffers and queued_count variable. Reported-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Pawel Osciak pa...@osciak.com --- drivers/media/video/videobuf2-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 6ba1461..6be2f79 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -1196,6 +1196,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q) * has not already dequeued before initiating cancel. */ INIT_LIST_HEAD(q-done_list); + atomic_set(q-queued_count, 0); wake_up_all(q-done_wq); /* -- 1.7.1.569.g6f426 -- 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: Improving kernel - userspace (usbfs) usb device hand off
Hi, On 06/10/2011 10:42 AM, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 10:36:47AM +0200, Hans de Goede wrote: On Fri, Jun 10, 2011 at 09:55:13AM +0200, Hans de Goede wrote: snip So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot in that case, why don't you just flush all data and continue ? Also, desktop manager knows that a particular device mounted, so it could also ask the user if s/he wants to continue. I'm not sure preventing a disconnect is a good thing. I assume you are sure preventing data loss is a good thing? Because in this example the 2 are the same. Also note I'm not suggestion at always preventing the disconnect, I'm suggesting to add a new try_disconnect ioctl, which apps which want to behave nicely can use instead of the regular disconnect ioctl, and then drivers can prevent the disconnect. Apps using the old ioctl will still get an unconditional disconnect as before. be reliably done from userspace. Where as it is trivial to do this from kernel space. One could advocate to make the existing disconnect ioctl use the new soft_disconnect usb_driver callback instead of adding a new usbfs ioctl for this, but that means that a driver can block any and all userspace triggered disconnects. Where as having a new ioctl, means that apps which want to play nice can play nice, while keeping the possibility of a hard userspace initiated disconnect. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. OTOH, if the user really wants to move the usb device to the guest OS, he has just requested for that, so should we prevent it ? what we need is for the applications to be notified to exit cleanly and release the device because the user has requested to do so. No ? We are talking about a device with a mounted file system on it here, any process could be holding files open on there, and there currently exists no mechanism to notify all apps to exit cleanly and release the files. Even if there were some method for a desktop environment like gnome to ask apps to release those files, and all gnome apps where to be modified to support that mechanism, then there are still 1000-s of non gnome (or kde, xfce, whatever) apps which will not support that. We already have a mechanism to cleanly close down a filesystem, it is called unmount. And it will fail if apps have files open. All I'm suggesting is forwarding this ebusy failure to the application trying to disconnect the driver from the usb mass storage interface. Simply removing the filesystem from under apps holding files open will lead to io errors, and very unhappy apps. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.40] Fixes
Hello. On Mon, 2011-05-23 at 13:06 +0200, ext Hans Verkuil wrote: Hi Mauro, Here are a few fixes: the first fixes a bug in the wl12xx drivers (I hope Matti's email is still correct). The second fixes a few DocBook validation errors, and I'm still here... And it's a nice surprise that the wl1273 radio driver hasn't been deprecated or has it... I actually could add some features to it. Cheers, Matti the last fixes READ_ONLY and GRABBED handling in the control framework. Regards, Hans The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f: [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (3): wl12xx: g_volatile_ctrl fix: wrong field set. Media DocBook: fix validation errors. v4l2-ctrls: drivers should be able to ignore READ_ONLY and GRABBED flags Documentation/DocBook/dvb/dvbproperty.xml|5 ++- Documentation/DocBook/v4l/subdev-formats.xml | 10 ++-- drivers/media/radio/radio-wl1273.c |2 +- drivers/media/radio/wl128x/fmdrv_v4l2.c |2 +- drivers/media/video/v4l2-ctrls.c | 59 +- 5 files changed, 50 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 02:19:20PM +0200, Hans de Goede wrote: So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem I'm not sure you even need a driver callback for that. Should we leave that to Desktop manager ? Not sure what you mean here, but we need for a way for drivers to say no to a software caused disconnection. See my usb mass storage device which is still mounted getting redirected to a vm example. This cannot in that case, why don't you just flush all data and continue ? Also, desktop manager knows that a particular device mounted, so it could also ask the user if s/he wants to continue. I'm not sure preventing a disconnect is a good thing. I assume you are sure preventing data loss is a good thing? Because in this example the 2 are the same. Also note I'm not suggestion at always preventing the disconnect, I'm suggesting to add a new try_disconnect ioctl, which apps which want to behave nicely can use instead of the regular disconnect ioctl, and then drivers can prevent the disconnect. Apps using the old ioctl will still get an unconditional disconnect as before. I'm just not sure if this should sit in the kernel. You can easily have some sort of device manager (much like udisks for storage) to track this down for ya. So instead of calling usbfs straight, you need to go via the device manager. This device manager should know that before calling 'disconnect' it must be sure there's nothing pending. One could also argue that making the existing disconnect ioctl return -EBUSY in some cases now is an ABI change. OTOH, if the user really wants to move the usb device to the guest OS, he has just requested for that, so should we prevent it ? what we need is for the applications to be notified to exit cleanly and release the device because the user has requested to do so. No ? We are talking about a device with a mounted file system on it here, any process could be holding files open on there, and there currently exists no mechanism to notify all apps to exit cleanly and release the files. Even if there were some method for a desktop environment like gnome to ask apps to release those files, and all gnome apps where to be modified to support that mechanism, then there are still 1000-s of non gnome (or kde, xfce, whatever) apps which will not support that. Still, I'm not sure this is argument good enough to add another sort of conflicting ioctl to the kernel. It won't prevent apps from calling the other disconnect anyway. And besides, if an app can be modified to use the try_disconnect ioctl, they can be modified for the system notification (on userland) too, can't they ? We already have a mechanism to cleanly close down a filesystem, it is called unmount. And it will fail if apps have files open. All I'm suggesting is forwarding this ebusy failure to the application trying to disconnect the driver from the usb mass storage interface. Simply removing the filesystem from under apps holding files open will lead to io errors, and very unhappy apps. Correct, but does the solution _have_ to sit in kernel ? I'm not sure. If you add the try_disconnect ioctl and all applications one your desktop, except one, are playing nice, you will still have problems. To me, it sounds much nicer to add such things on userland alone, in a way such that it doesn't matter if it's a usb storage, mmc card, or eSATA drive. That should be hidden from apps IMHO. -- balbi signature.asc Description: Digital signature
Re: Media_build does not compile due to errors in cx18-driver.h, cx18-driver.c and dvbdev.c /rc-main.c
Jan Hoogenraad jan-conceptro...@hoogenraad.net wrote:
Hans, Mauro:
I have tried to compile the sources at
git://linuxtv.org/media_build.git,
using build.sh
At
cx18-driver.h:659:
struct workqueue_struct *out_work_queue;
char out_workq_name[12]; /* cx18-NN-out */
struct workqueue_struct *out_work_queue;
char out_workq_name[12]; /* cx18-NN-out */
cx18-driver.c:718
a similar problem occurs: the following code block is repeated:
static int __devinit cx18_create_out_workq(struct cx18 *cx)
{
snprintf(cx-out_workq_name, sizeof(cx-out_workq_name), %s-out,
cx-v4l2_dev.name);
cx-out_work_queue = create_workqueue(cx-out_workq_name);
if (cx-out_work_queue == NULL) {
CX18_ERR(Unable to create outgoing mailbox handler threads\n);
return -ENOMEM;
}
return 0;
}
static int __devinit cx18_create_out_workq(struct cx18 *cx)
{
snprintf(cx-out_workq_name, sizeof(cx-out_workq_name), %s-out,
cx-v4l2_dev.name);
cx-out_work_queue = create_workqueue(cx-out_workq_name);
if (cx-out_work_queue == NULL) {
CX18_ERR(Unable to create outgoing mailbox handler threads\n);
return -ENOMEM;
}
return 0;
}
Furthermore, there is an error that is present in three sources:
At
./v4l/dvbdev.c:466: twice:
the escape sequence \\ sould be replaced with \
./rc-main.c:1131: twice:
the escape sequence \\ sould be replaced with \
./v4l/v4l2-dev.c:782: twice:
the escape sequence \\ sould be replaced with \
--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What are the error messages?
Tejun Heo made quite a number of workqueue changes, and the cx18 driver got
dragged forward with them. So did ivtv for that matter.
Just disable the cx18 driver if you don't need it for an older kernel.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for June 8 (docbook/media)
Hi Randy, Em 09-06-2011 20:37, Randy Dunlap escreveu: Big hint: I see these errors not during make htmldocs but during a kernel code build when CONFIG_BUILD_DOCSRC=y. Sorry, I should have mentioned this earlier. I couldn't reach any troubles there. Documentation build is stopping earlier. I'm using the -next tree for 20110610: $ make defconfig $ make CONFIG_BUILD_DOCSRC=y -j 16 Documentation/ Documentation/networking/timestamping/timestamping.c:45:30: error: linux/net_tstamp.h: No such file or directory Documentation/networking/timestamping/timestamping.c: In function ‘main’: Documentation/networking/timestamping/timestamping.c:331: error: storage size of ‘hwconfig’ isn’t known Documentation/networking/timestamping/timestamping.c:331: error: storage size of ‘hwconfig_requested’ isn’t known Documentation/networking/timestamping/timestamping.c:355: error: ‘SOF_TIMESTAMPING_TX_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:355: error: (Each undeclared identifier is reported only once Documentation/networking/timestamping/timestamping.c:355: error: for each function it appears in.) Documentation/networking/timestamping/timestamping.c:357: error: ‘SOF_TIMESTAMPING_TX_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:359: error: ‘SOF_TIMESTAMPING_RX_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:361: error: ‘SOF_TIMESTAMPING_RX_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:363: error: ‘SOF_TIMESTAMPING_SOFTWARE’ undeclared (first use in this function) Documentation/accounting/getdelays.c: In function ‘main’: Documentation/networking/timestamping/timestamping.c:365: error: ‘SOF_TIMESTAMPING_SYS_HARDWARE’ undeclared (first use in this function)Documentation/accounting/getdelays.c:525: error: ‘TASKSTATS_TYPE_NULL’ undeclared (first use in this function) Documentation/accounting/getdelays.c:525: error: (Each undeclared identifier is reported only once Documentation/accounting/getdelays.c:525: error: for each function it appears in.) Documentation/networking/timestamping/timestamping.c:367: error: ‘SOF_TIMESTAMPING_RAW_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:387: error: ‘HWTSTAMP_TX_ON’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:387: error: ‘HWTSTAMP_TX_OFF’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:390: error: ‘HWTSTAMP_FILTER_PTP_V1_L4_SYNC’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:390: error: ‘HWTSTAMP_FILTER_NONE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:331: warning: unused variable ‘hwconfig_requested’ Documentation/networking/timestamping/timestamping.c:331: warning: unused variable ‘hwconfig’ make[2]: *** [Documentation/accounting/getdelays] Error 1 make[3]: *** [Documentation/networking/timestamping/timestamping] Error 1 make[1]: *** [Documentation/accounting] Error 2 make[1]: *** Waiting for unfinished jobs make[2]: *** [Documentation/networking/timestamping] Error 2 make[2]: *** Waiting for unfinished jobs make[1]: *** [Documentation/networking] Error 2 make: *** [Documentation/] Error 2 Could you please send me your .config? Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] lib: genalloc: Generic allocator improvements
I plan to replace it with lib/bitmap.c bitmap_* based allocator (similar like it it is used by dma_declare_coherent_memory() and friends in drivers/base/dma-coherent.c). We need something really simple for CMA area management. IMHO allocate_resource and friends a bit too heavy here, but good to know that such allocator also exists. Not sure I'd class allocate_resource as heavyweight but providing it's using something that already exists rather than inventing yet another allocator. This wants dealing with before it goes upstream though so the chaneges in lib/*c etc never have to reach mainline and then get changed back. Alan -- 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 05/13] [media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
On Thu, Jun 9, 2011 at 9:07 AM, Andreas Oberritter o...@linuxtv.org wrote: ... implemented in *kernel* drivers for several generations of the dreambox. Well, let's see the source code to the drivers in question, and from there we can make some decisions on how to best proceed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media_build does not compile due to errors in cx18-driver.h, cx18-driver.c and dvbdev.c /rc-main.c
Andy: Something along the line of id already defined. I just corrected the code by removing the duplicate lines that are in the sources of the tar. The other 3 files have a bad escape sequence in a line saying that this is the backports. One backslash not removed in a script, I guess. Devin: The version does not matter for the cx18 problem: any compiler complains on duplicate lines. Anyway: 2.6.32-32-generic-pae #62-Ubuntu SMP Wed Apr 20 22:10:33 UTC 2011 i686 GNU/Linux Devin Heitmueller wrote: On Fri, Jun 10, 2011 at 8:34 AM, Andy Wallsawa...@md.metrocast.net wrote: What are the error messages? Tejun Heo made quite a number of workqueue changes, and the cx18 driver got dragged forward with them. So did ivtv for that matter. Just disable the cx18 driver if you don't need it for an older kernel. Regards, Andy Another highly relevant piece of information to know is what kernel Jan is running on. It is probably from before the workqueue changes. Devin -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [PATCH 05/13] [media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
On 10.06.2011 15:18, Devin Heitmueller wrote: On Thu, Jun 9, 2011 at 9:07 AM, Andreas Oberrittero...@linuxtv.org wrote: ... implemented in *kernel* drivers for several generations of the dreambox. Well, let's see the source code to the drivers in question, and from there we can make some decisions on how to best proceed. Just a side note: VDR uses this (and others) in its full featured output devices. I'm not sure whether this discussion is aiming at completely doing away with these definitions, or if there will be a replacement. Just wanted to make you folks aware of this. Klaus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media_build does not compile due to errors in cx18-driver.h, cx18-driver.c and dvbdev.c /rc-main.c
Sorry; too fast a reaction; I did not realize that the build script creates a version per kernel, and that my messages thus become hard to trace. The cx18 doubles were clear. The one in the code file may be caused by v2.6.37_dont_use_alloc_ordered_workqueue.patch but I don't see the problem in the header file in that patch. Below the 3 non cx18 offending lines: line in v4l2-dev.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); line in rc-main.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); line in dvbdeb.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); Jan Hoogenraad wrote: Andy: Something along the line of id already defined. I just corrected the code by removing the duplicate lines that are in the sources of the tar. The other 3 files have a bad escape sequence in a line saying that this is the backports. One backslash not removed in a script, I guess. Devin: The version does not matter for the cx18 problem: any compiler complains on duplicate lines. Anyway: 2.6.32-32-generic-pae #62-Ubuntu SMP Wed Apr 20 22:10:33 UTC 2011 i686 GNU/Linux Devin Heitmueller wrote: On Fri, Jun 10, 2011 at 8:34 AM, Andy Wallsawa...@md.metrocast.net wrote: What are the error messages? Tejun Heo made quite a number of workqueue changes, and the cx18 driver got dragged forward with them. So did ivtv for that matter. Just disable the cx18 driver if you don't need it for an older kernel. Regards, Andy Another highly relevant piece of information to know is what kernel Jan is running on. It is probably from before the workqueue changes. Devin attachment: jan-verisign.vcf
[PATCH 0/2] radio-timb: Simplified platform data and open function added
To follow are two patches for the timberdale radio driver. The first just simplifies the platform data. The second uses the platform data to find a tuner and DSP on a provided I2C bus. --Richard -- 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: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Hans de Goede wrote: Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. First of all an example use case scenarios where the current API falls short. 1) Redirection of USB devices to a virtual machine, qemu, vbox, etc. all have the ability to redirect a USB device to the virtual machine, and they all use usbfs for this. The first thing which will happen here when the user selects a device to redirect is a IOCTL_USBFS_DISCONNECT. This causes the kernel driver to see a device unplug, with no chances for the kernel driver to do anything against this. Now lets say the user does the following: -write a file to a usb flash disk -redirect the flash disk to a vm Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. You haven't given a proper description of the problem. See below. 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. Again not good. As Felipe has mentioned, this sounds like the sort of problem that can better be solved in userspace. A dual-mode device like the one you describe really is either a still-cam or a webcam, never both at the same time. Hence what users need is a utility program to switch modes (by loading/unloading the appropriate programs or drivers). Or maybe a desktop daemon that could accomplish the same result automatically, based on requests from user programs. ### So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem Not feasible. usb-storage has no idea whether or not a device it controls has a mounted filesystem. (All it does is send SCSI commands to a device and get back the results.) Since that's the main use case you're interested in, this part of the proposal seems destined to fail. But userspace _does_ know where the mounted filesystems are. Therefore userspace should be responsible for avoiding programs that want to take control of devices holding these filesystems. That's the reason why usbfs device nodes are owned by root and have 0644 mode; there're can be written to only by programs with superuser privileges -- and such programs are supposed to be careful about what they do. b) It will allow for example a v4l2 driver to keep its /dev/video node around Note that b) means that the normal disconnect handler should still be called after a soft reconnect on a real disconnect. In some sense the disconnect callback for usb-storage already _is_ soft. Although the driver cannot refuse the disconnect, it _can_ continue to communicate with the device until the callback returns. (As it happens, usb-storage _doesn't_ do any further communication with the device. This is mostly for historical reasons, to compensate for shortcomings in the SCSI stack in earlier kernel versions. On the other hand, there really isn't much that you would want to send to a mass-storage device during a soft disconnect. Perhaps tell it to flush its cache out to the storage medium -- but if there are no open file handles for the device and no mounted filesystems then the cache will already be flushed.) 2) A usb_driver soft_reconnect callback to match the soft_disconnect 3) A mechanism for a usb_driver to signal a usbfs fd owner of the device it would like the device back. So for example the gvfs mount can be automatically unmounted (if not busy). This also should be handled in userspace. USB drivers never want back a device they are no longer bound to -- in fact, the device model used throughout the kernel makes this whole idea meaningless. Device drivers don't want devices back. Rather, _users_
[PATCH 2/2] radio-timb: Add open function which finds tuner and DSP via I2C
This patch uses the platform data and finds a tuner and DSP. This is
done when the user calls open. Not during probe, to allow shorter bootup
time of the system.
This piece of code was actually missing earlier, many of the functions
were not useful without DSP and tuner.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
index a185610..64a5e19 100644
--- a/drivers/media/radio/radio-timb.c
+++ b/drivers/media/radio/radio-timb.c
@@ -141,9 +141,42 @@ static const struct v4l2_ioctl_ops timbradio_ioctl_ops = {
.vidioc_s_ctrl = timbradio_vidioc_s_ctrl
};
+static int timbradio_fops_open(struct file *file)
+{
+ struct timbradio *tr = video_drvdata(file);
+ struct i2c_adapter *adapt;
+
+ /* find the I2C bus */
+ adapt = i2c_get_adapter(tr-pdata.i2c_adapter);
+ if (!adapt) {
+ printk(KERN_ERR DRIVER_NAME: No I2C bus\n);
+ return -ENODEV;
+ }
+
+ /* now find the tuner and dsp */
+ if (!tr-sd_dsp)
+ tr-sd_dsp = v4l2_i2c_new_subdev_board(tr-v4l2_dev, adapt,
+ tr-pdata.dsp, NULL);
+
+ if (!tr-sd_tuner)
+ tr-sd_tuner = v4l2_i2c_new_subdev_board(tr-v4l2_dev, adapt,
+ tr-pdata.tuner, NULL);
+
+ i2c_put_adapter(adapt);
+
+ if (!tr-sd_tuner || !tr-sd_dsp) {
+ printk(KERN_ERR DRIVER_NAME
+ : Failed to get tuner or DSP\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
static const struct v4l2_file_operations timbradio_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = video_ioctl2,
+ .open = timbradio_fops_open,
};
static int __devinit timbradio_probe(struct platform_device *pdev)
--
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 1/2] radio-timb: Simplified platform data
This patch simplifies the platform data slightly, by removing
unused elements.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 69272e4..696879e 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -287,12 +287,8 @@ static __devinitdata struct i2c_board_info
timberdale_saa7706_i2c_board_info = {
static __devinitdata struct timb_radio_platform_data
timberdale_radio_platform_data = {
.i2c_adapter = 0,
- .tuner = {
- .info = timberdale_tef6868_i2c_board_info
- },
- .dsp = {
- .info = timberdale_saa7706_i2c_board_info
- }
+ .tuner = timberdale_tef6868_i2c_board_info,
+ .dsp = timberdale_saa7706_i2c_board_info
};
static const __devinitconst struct resource timberdale_video_resources[] = {
diff --git a/include/media/timb_radio.h b/include/media/timb_radio.h
index a59a848..a40a6a3 100644
--- a/include/media/timb_radio.h
+++ b/include/media/timb_radio.h
@@ -23,13 +23,8 @@
struct timb_radio_platform_data {
int i2c_adapter; /* I2C adapter where the tuner and dsp are attached */
- struct {
- struct i2c_board_info *info;
- } tuner;
- struct {
- const char *module_name;
- struct i2c_board_info *info;
- } dsp;
+ struct i2c_board_info *tuner;
+ struct i2c_board_info *dsp;
};
#endif
--
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: Improving kernel - userspace (usbfs) usb device hand off
Em 10-06-2011 11:48, Alan Stern escreveu: On Fri, 10 Jun 2011, Hans de Goede wrote: As Felipe has mentioned, this sounds like the sort of problem that can better be solved in userspace. A dual-mode device like the one you describe really is either a still-cam or a webcam, never both at the same time. Hence what users need is a utility program to switch modes (by loading/unloading the appropriate programs or drivers). Unloading a driver in order to access the hardware via userspace? This sounds a very bad idea do me. What happens if another hardware is using the same driver? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for June 8 (docbook/media)
Em 10-06-2011 12:04, Randy Dunlap escreveu: On 06/10/11 05:47, Mauro Carvalho Chehab wrote: Hi Randy, Em 09-06-2011 20:37, Randy Dunlap escreveu: Big hint: I see these errors not during make htmldocs but during a kernel code build when CONFIG_BUILD_DOCSRC=y. Sorry, I should have mentioned this earlier. I couldn't reach any troubles there. Documentation build is stopping earlier. I'm using the -next tree for 20110610: $ make defconfig $ make CONFIG_BUILD_DOCSRC=y -j 16 Documentation/ Maybe that incantation does not set CONFIG_HEADERS_CHECK, which CONFIG_BUILD_DOCSRC depends on. [build errors snipped] Could you please send me your .config? yes, attached. Hmm... didn't work either. With your config: [mchehab@buidmachine linux-next]$ make -j 16 Documentation/ CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh HOSTCC Documentation/networking/timestamping/timestamping Documentation/networking/timestamping/timestamping.c:45:30: error: linux/net_tstamp.h: No such file or directory Documentation/networking/timestamping/timestamping.c: In function ‘main’: Documentation/networking/timestamping/timestamping.c:331: error: storage size of ‘hwconfig’ isn’t known Documentation/networking/timestamping/timestamping.c:331: error: storage size of ‘hwconfig_requested’ isn’t known Documentation/networking/timestamping/timestamping.c:355: error: ‘SOF_TIMESTAMPING_TX_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:355: error: (Each undeclared identifier is reported only once Documentation/networking/timestamping/timestamping.c:355: error: for each function it appears in.) Documentation/networking/timestamping/timestamping.c:357: error: ‘SOF_TIMESTAMPING_TX_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:359: error: ‘SOF_TIMESTAMPING_RX_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:361: error: ‘SOF_TIMESTAMPING_RX_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:363: error: ‘SOF_TIMESTAMPING_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:365: error: ‘SOF_TIMESTAMPING_SYS_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:367: error: ‘SOF_TIMESTAMPING_RAW_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:387: error: ‘HWTSTAMP_TX_ON’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:387: error: ‘HWTSTAMP_TX_OFF’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:390: error: ‘HWTSTAMP_FILTER_PTP_V1_L4_SYNC’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:390: error: ‘HWTSTAMP_FILTER_NONE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:331: warning: unused variable ‘hwconfig_requested’ Documentation/networking/timestamping/timestamping.c:331: warning: unused variable ‘hwconfig’ make[3]: *** [Documentation/networking/timestamping/timestamping] Error 1 make[2]: *** [Documentation/networking/timestamping] Error 2 make[1]: *** [Documentation/networking] Error 2 make: *** [Documentation/] Error 2 PS.: A full build against next is broken: $ make -j 27 CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/x86/lib/memmove_64.o gcc: arch/x86/lib/memmove_64.c: No such file or directory gcc: no input files make[1]: *** [arch/x86/lib/memmove_64.o] Error 1 make: *** [arch/x86/lib] Error 2 make: *** Waiting for unfinished jobs My tree is on this commit: commit c4c5f633751496147f2d846844aa084a1dbca0f4 Author: Stephen Rothwell s...@canb.auug.org.au Date: Fri Jun 10 16:17:26 2011 +1000 Add linux-next specific files for 20110610 -- 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: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Mauro Carvalho Chehab wrote: Em 10-06-2011 11:48, Alan Stern escreveu: On Fri, 10 Jun 2011, Hans de Goede wrote: As Felipe has mentioned, this sounds like the sort of problem that can better be solved in userspace. A dual-mode device like the one you describe really is either a still-cam or a webcam, never both at the same time. Hence what users need is a utility program to switch modes (by loading/unloading the appropriate programs or drivers). Unloading a driver in order to access the hardware via userspace? This sounds a very bad idea do me. What happens if another hardware is using the same driver? A kernel driver wouldn't have to be unloaded. It could simply be unbound from the device via sysfs or usbfs. Alan STern -- 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: Media_build does not compile due to errors in cx18-driver.h, cx18-driver.c and dvbdev.c /rc-main.c
Em 10-06-2011 11:14, Jan Hoogenraad escreveu: Sorry; too fast a reaction; I did not realize that the build script creates a version per kernel, and that my messages thus become hard to trace. The cx18 doubles were clear. The one in the code file may be caused by v2.6.37_dont_use_alloc_ordered_workqueue.patch but I don't see the problem in the header file in that patch. Below the 3 non cx18 offending lines: line in v4l2-dev.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); line in rc-main.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); line in dvbdeb.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); It seems to be caused by a bad escape sequence for the latest patch. I'll fix the Makefile script. Thanks for reporting it. -- 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-next: Tree for June 8 (docbook/media)
On 06/10/11 08:19, Mauro Carvalho Chehab wrote: Em 10-06-2011 12:04, Randy Dunlap escreveu: On 06/10/11 05:47, Mauro Carvalho Chehab wrote: Hi Randy, Em 09-06-2011 20:37, Randy Dunlap escreveu: Big hint: I see these errors not during make htmldocs but during a kernel code build when CONFIG_BUILD_DOCSRC=y. Sorry, I should have mentioned this earlier. I couldn't reach any troubles there. Documentation build is stopping earlier. I'm using the -next tree for 20110610: $ make defconfig $ make CONFIG_BUILD_DOCSRC=y -j 16 Documentation/ Maybe that incantation does not set CONFIG_HEADERS_CHECK, which CONFIG_BUILD_DOCSRC depends on. [build errors snipped] Could you please send me your .config? yes, attached. Hmm... didn't work either. With your config: [mchehab@buidmachine linux-next]$ make -j 16 Documentation/ CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh HOSTCC Documentation/networking/timestamping/timestamping Documentation/networking/timestamping/timestamping.c:45:30: error: linux/net_tstamp.h: No such file or directory Documentation/networking/timestamping/timestamping.c: In function ‘main’: Documentation/networking/timestamping/timestamping.c:331: error: storage size of ‘hwconfig’ isn’t known Documentation/networking/timestamping/timestamping.c:331: error: storage size of ‘hwconfig_requested’ isn’t known Documentation/networking/timestamping/timestamping.c:355: error: ‘SOF_TIMESTAMPING_TX_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:355: error: (Each undeclared identifier is reported only once Documentation/networking/timestamping/timestamping.c:355: error: for each function it appears in.) Documentation/networking/timestamping/timestamping.c:357: error: ‘SOF_TIMESTAMPING_TX_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:359: error: ‘SOF_TIMESTAMPING_RX_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:361: error: ‘SOF_TIMESTAMPING_RX_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:363: error: ‘SOF_TIMESTAMPING_SOFTWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:365: error: ‘SOF_TIMESTAMPING_SYS_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:367: error: ‘SOF_TIMESTAMPING_RAW_HARDWARE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:387: error: ‘HWTSTAMP_TX_ON’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:387: error: ‘HWTSTAMP_TX_OFF’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:390: error: ‘HWTSTAMP_FILTER_PTP_V1_L4_SYNC’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:390: error: ‘HWTSTAMP_FILTER_NONE’ undeclared (first use in this function) Documentation/networking/timestamping/timestamping.c:331: warning: unused variable ‘hwconfig_requested’ Documentation/networking/timestamping/timestamping.c:331: warning: unused variable ‘hwconfig’ make[3]: *** [Documentation/networking/timestamping/timestamping] Error 1 make[2]: *** [Documentation/networking/timestamping] Error 2 make[1]: *** [Documentation/networking] Error 2 make: *** [Documentation/] Error 2 PS.: A full build against next is broken: $ make -j 27 CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/x86/lib/memmove_64.o gcc: arch/x86/lib/memmove_64.c: No such file or directory gcc: no input files make[1]: *** [arch/x86/lib/memmove_64.o] Error 1 make: *** [arch/x86/lib] Error 2 make: *** Waiting for unfinished jobs My tree is on this commit: commit c4c5f633751496147f2d846844aa084a1dbca0f4 Author: Stephen Rothwell s...@canb.auug.org.au Date: Fri Jun 10 16:17:26 2011 +1000 Add linux-next specific files for 20110610 Still fails on linux-next-20110610 for me. Please try a full, clean build, not using only $ make -j 16 Documentation/ $ mkdir doc64 $ cp -a config-r7970 doc64/.config $ make O=doc64 oldconfig $ make O=doc64 -j9 all ... ls: cannot access /lnx/src/NEXT/linux-next-20110610/Documentation/DocBook/media/*/*.gif: No such file or directory ls: cannot access /lnx/src/NEXT/linux-next-20110610/Documentation/DocBook/media/*/*.png: No such file or directory -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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: Media_build does not compile due to errors in cx18-driver.h, cx18-driver.c and dvbdev.c /rc-main.c
Em 10-06-2011 12:34, Mauro Carvalho Chehab escreveu: Em 10-06-2011 11:14, Jan Hoogenraad escreveu: Sorry; too fast a reaction; I did not realize that the build script creates a version per kernel, and that my messages thus become hard to trace. The cx18 doubles were clear. The one in the code file may be caused by v2.6.37_dont_use_alloc_ordered_workqueue.patch but I don't see the problem in the header file in that patch. Below the 3 non cx18 offending lines: line in v4l2-dev.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); line in rc-main.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); line in dvbdeb.c: printk(KERN_ERR WARNING: You are using an experimental version of the media stack.\n\tAs the driver is backported to an older kernel, it doesn't offer\n\tenough quality for its usage in production.\n\tUse it with care.\nLatest git patches (needed if you report a bug to linux-media@vger.kernel.org):\n\t75125b9d44456e0cf2d1fbb72ae33c13415299d1 [media] DocBook: Don't be noisy at make cleanmediadocs\n\t0fba2f7ff0c4d9f48a5c334826a22db32f816a76 Revert \\[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS\\\n\t4f75ad768da3c5952d1e7080045a5b5ce7b0d85d [media] DocBook/video.xml: Document the remaining data structures\n); It seems to be caused by a bad escape sequence for the latest patch. I'll fix the Makefile script. Thanks for reporting it. Fixed. It is building fine right now, against RHEL 6.1 kernel (2.6.32-131). Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Friday 10 June 2011, Marek Szyprowski wrote: The Contiguous Memory Allocator is a set of functions that lets one initialise a region of memory which then can be used to perform allocations of contiguous memory chunks from. CMA allows for creation of separate contexts. Kernel is allowed to allocate movable pages within CMA's managed memory so that it can be used for page cache when CMA devices do not use it. On cm_alloc() request such pages are migrated out of CMA area to free required contiguous block. Hi Marek, I'm generally happy with the patches 1 through 7, i.e the heavy lifting to make contiguous allocations work. Thank you very much for keeping up the work and submitting these in a good shape. I do think that we need to discuss the driver-visible API a bit more. My feeling is that this is rather un-Linux-like and it needs to be simplified some more. Of course, I don't mind being overruled by the memory management experts here, or if you can argue that it's really the right way to do it. + * Driver usage + * + * CMA should not be used directly by the device drivers. It should + * be considered as helper framework for dma-mapping subsystm and + * respective (platform)bus drivers. + * + * The CMA client needs to have a pointer to a CMA context + * represented by a struct cma (which is an opaque data type). + * + * Once such pointer is obtained, a caller may allocate contiguous + * memory chunk using the following function: + * + * cm_alloc() + * + * This function returns a pointer to the first struct page which + * represent a contiguous memory chunk. This pointer + * may be used with the following function: + * + * cm_free()-- frees allocated contiguous memory Please explain why you want a new top-level API here. I think it would be much nicer if a device driver could simply call alloc_pages(..., GFP_CMA) or similar, where all the complexity in here gets hidden behind a conditional deep inside of the page allocator. Evidently, the two functions you describe here have an extra argument for the context. Can you elaborate why that is really needed? What is the specific requirement to have multiple such contexts in one system and what is the worst-case effect that you would get when the interface is simplified to have only one for all devices? Alternatively, would it be possible to provide the cm_alloc/cm_free functions only as backing to the dma mapping API and not export them as a generic device driver interface? + * Platform/machine integration + * + * CMA context must be created on platform or machine initialisation + * and passed to respective subsystem that will be a client for CMA. + * The latter may be done by a global variable or some filed in + * struct device. For the former CMA provides the following functions: + * + * cma_init_migratetype() + * cma_reserve() + * cma_create() + * + * The first one initialises a portion of reserved memory so that it + * can be used with CMA. The second first tries to reserve memory + * (using memblock) and then initialise it. + * + * The cma_reserve() function must be called when memblock is still + * operational and reserving memory with it is still possible. On + * ARM platform the reserve machine callback is a perfect place to + * call it. + * + * The last function creates a CMA context on a range of previously + * initialised memory addresses. Because it uses kmalloc() it needs + * to be called after SLAB is initialised. + */ This interface looks flawed to me for multiple reasons: * It requires you to call three distinct functions in order to do one thing, and they all take the same arguments (more or less). Why not have one function call at the latest possible point where you can still change the memory attributes, and have everything else happen automatically? * It requires you to pass the exact location of the area. I can see why you want that on certain machines that require DMA areas to be spread across multiple memory buses, but IMHO it's not appropriate for a generic API. * It requires you to hardcode the size in a machine specific source file. This probably seems to be a natural thing to do when you have worked a lot on the ARM architecture, but it's really not. We really want to get rid of board files and replace them with generic probing based on the device tree, and the size of the area is more policy than a property of the hardware that can be accurately described in the device tree or a board file. I'm sure that we can find a solution for all of these problems, it just takes a few good ideas. Especially for the last point, I don't have a better suggestion yet, but hopefully someone else can come up with one. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: vb2: about vb2_queue-queued_count
On Fri, Jun 10, 2011 at 01:50:37PM +0200, Marek Szyprowski wrote: Hello, On Wednesday, June 08, 2011 10:48 PM Uwe Kleine-König wrote: I'm still debugging my new video overlay device driver. The current problem is again when playing back a second video. After streamoff is called at the end of the first video, I disable the overlay and call vb2_buffer_done on the last buffer. This is exited early because vb-state == VB2_BUF_STATE_DEQUEUED. This results in vb-vb2_queue-queued_count being 1. Now if the new video starts I call vb2_queue_init in the .vidioc_reqbufs callback on my queue (that still has queued_count == 1). After vb2_queue_init returns queued_count is still 1 though q-queued_list is reset to be empty. __vb2_queue_cancel has a similar problem, q-queued_list is reset, but queued_count is not. Thanks again for finding the bug. You are right, __vb2_queue_cancel should reset queued_count too. I will post a patch soon. IMHO vb2_queue_init should reset queued_count, too. Not sure if you just skipped to mention it here Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2: reset queued_count value during queue reinitialization
On Fri, Jun 10, 2011 at 02:04:38PM +0200, Marek Szyprowski wrote: queued_count variable was left untouched during the queue reinitialization in __vb2_queue_cancel, what might lead to mismatch between the real number of queued buffers and queued_count variable. Reported-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Pawel Osciak pa...@osciak.com Half-acked-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de As mentioned in the original report, the setup routine should initialize queued_count, too, so only a half ack. Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] lib: genalloc: Generic allocator improvements
On Fri, 10 Jun 2011 14:52:17 +0200, Alan Cox a...@lxorguk.ukuu.org.uk wrote: I plan to replace it with lib/bitmap.c bitmap_* based allocator (similar like it it is used by dma_declare_coherent_memory() and friends in drivers/base/dma-coherent.c). We need something really simple for CMA area management. IMHO allocate_resource and friends a bit too heavy here, but good to know that such allocator also exists. Not sure I'd class allocate_resource as heavyweight but providing it's using something that already exists rather than inventing yet another allocator. genalloc is already in the kernel and is used in a few places, so we either let everyone use it as they see fit or we deprecate the library. If we don't deprecate it I see no reason why CMA should not use it. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal mina86 Nazarewicz(o o) ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo-- -- 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: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote: As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. It's still wrong. This should be just another USB_REQ_SET_CONFIGURATION(). If this is was just one single driver, you could easily do that. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have thought before coding, as the result is not user-friendly in the least. I agree here 6. The question has been asked whether the cameras are always using the same interface. Typically, yes. The same altsetting? That depends on the camera. Some of them use isochronous transport for streaming, and some of them rely exclusively upon bulk transport. Those which use bulk transport only are confined to altsetting 0. the transfer type or the way the configurations are setup shouldn't matter much for the end functionality. Some possible solutions? Well, first of all it needs to be understood that the problem originates as a bad feature of something good, namely the rigid separation of kernelspace and userspace functionality which is an integral part of the Linux security model. Some other operating systems are not so careful, and thus they do not have a problem about supporting dual-mode hardware. You'd need to describe this fully. What's the problem in having one driver handle all modes of operation of that particular camera ? Sounds like a decision from V4L2 folks not to take still image cameras in kernel. Am I wrong ? Second, it appears to me that the problem is most appropriately addressed from the userspace side and perhaps also from the kernelspace side. In userspace, it would be a really good idea if those who are attempting to write user-friendly apps and to create user-friendly distros would actually learn some of the basics of Linux, such as the rudiments of the security model. Since dual-mode cameras are known to exist, it would have been appropriate, when one is detected, to pop up a dialog window which asks the user to choose a webcam app or a stillcam app. Even this minor innovation would stop a lot of
[PATCH 0/19] S5P FIMC driver conversion to control framework and Media Controller API
Hello,
The following change set is a S5P/EXYNOS4 FIMC (camera host interface
and video post-processor) driver conversion to the control framework
and Media Controller API. The first and last patch add Runtime PM support
in the mem-to-mem and capture driver respectively.
The s5p-fimc driver supports S5PC110, S5PV210 and EXYNOS4210 (S5PV310) SoCs.
As far as camera support is concerned the most recent Exynos4210 SoC has
2 parallel and 2 MIPI-CSI2 inputs, 2 MIPI-CSI2 receivers and 4 FIMC subsystems.
FIMC instances can be attached to any parallel input or the MIPI-CSI receiver
output. The MIPI-CSI receivers have fixed connections to the MIPI CSI physical
interfaces (MIPI-CSIS PHY). Using media controller API allows to easily
discover the H/W structure and choose optimal configuration in particular
use case.
The media device introduced with patch: s5p-fimc: Add the media device
driver acts as a top level entity to which sensor, the mipi-csi receiver
and FIMC subdevs are registered. It also assures proper use of 2 SoC output
clocks for external sensors, which are shared among all FIMC entities.
Patch s5p-fimc: Add a subdev for the FIMC processing block adds a v4l2
sub-device for each FIMC camera capture processing unit.
Video pipeline configuration procedure for subdevs has not yet been fully
discussed and settled. Nevertheless I have adopted following configuration
flow for the FIMC.{n} (capture) subdevs:
1) set format at sink pad (this will reset sink crop rectangle)
2) set crop rectangle at sink pad (optional)
3) set rotate control
4) set crop (composition) at source pad (optional). Here scaling constraints
are checked according to whether sink pad crop has been set or not and
whether 90/270 deg rotation is set.
Rotation can also be changed while streaming, in this case when 90/270 deg
rotation is attempted to be set and scaling bounds are exceeded
(max. 64x downscaling) s_ctrl returns EINVAL.
The following pipeline configurations are possible:
1) sensor subdev - FIMC.? subdev - video node (/dev/video*)
2) sensor subdev - s5p-mipi-csis.? subdev - FIMC.? subdev -
video node (/dev/video*)
3) sensor1 subdev - s5p-mipi-csis.? -+- FIMC.{n} subdev ...
|
+- FIMC.{n+1} subdev ..
4) LCD capture subdev - FIMC.? - video node (dev/video)
4) is not yet implemented.
I have tested this driver with media-ctl tool (thanks go to Laurent Pinchart
for sharing it) which can be found at:
http://git.ideasonboard.org/?p=media-ctl.git
This patch set depends on my previous s5p-fimc bugfixes, available at:
http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/s5p-fimc
as well as the control framework updates from Hans Verkuil:
http://www.spinics.net/lists/linux-media/msg33552.html
(patch 1...6, 8, 11).
The corresponding platform support patches illustrating the media device
and mipi-csis platform data setup are being prepared and will follow shortly.
There are a few open issues that are not really fully resolved yet:
- V4L2 device node only and media controller API coexistence;
For now the driver is checking if image sensor subdev exposes a device
node to user space, if it doesn't then formats are configured by the
V4L2 node driver in VIDIOC_S_FMT ioctl. If sensor exposes a video node
then only the output DMA is configured in S_FMT.
It seems more reasonable to permanently enable sensor and mipi-csi subdevs
and choose proper actions in the host driver at runtime on some different
precondition basis.
- Accessing controls' value in interrupt context; it would be useful to use
struct v4l2_ctrl::val directly in the driver rather than caching it
additonally.
Any comments and suggestions on this initial version are appreciated.
drivers/media/video/Kconfig |2 +-
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 1280 +++
drivers/media/video/s5p-fimc/fimc-core.c| 917 ++--
drivers/media/video/s5p-fimc/fimc-core.h| 192 +++--
drivers/media/video/s5p-fimc/fimc-mdevice.c | 738 +++
drivers/media/video/s5p-fimc/fimc-mdevice.h | 126 +++
drivers/media/video/s5p-fimc/fimc-reg.c | 76 +-
drivers/media/video/s5p-fimc/regs-fimc.h|8 +-
include/media/s5p_fimc.h| 11 +
10 files changed, 2416 insertions(+), 936 deletions(-)
--
Thanks,
Sylwester Nawrocki
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 01/19] s5p-fimc: Add support for runtime PM in the mem-to-mem driver
Only the FIMC entity memory-to-memory operation is fully covered,
for the camera capture suspend/resume only stubs are provided.
It's all what is needed to enable the driver on EXYNOS4 series with
power domain driver enabled. Camera capture pipeline suspend/resume
is covered by a separate patch.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 20 +++
drivers/media/video/s5p-fimc/fimc-core.c| 237 +++
drivers/media/video/s5p-fimc/fimc-core.h| 16 ++-
drivers/media/video/s5p-fimc/fimc-reg.c |2 +-
4 files changed, 197 insertions(+), 78 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 81b4a82..9432ea8 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/list.h
#include linux/slab.h
#include linux/clk.h
@@ -197,6 +198,18 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
return 0;
}
+int fimc_capture_suspend(struct fimc_dev *fimc)
+{
+ /* TODO: */
+ return -EBUSY;
+}
+
+int fimc_capture_resume(struct fimc_dev *fimc)
+{
+ /* TODO: */
+ return 0;
+}
+
static int start_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q-drv_priv;
@@ -382,9 +395,14 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
+ ret = pm_runtime_get_sync(fimc-pdev-dev);
+ if (ret)
+ return ret;
+
if (++fimc-vid_cap.refcnt == 1) {
ret = fimc_isp_subdev_init(fimc, 0);
if (ret) {
+ pm_runtime_put_sync(fimc-pdev-dev);
fimc-vid_cap.refcnt--;
return -EIO;
}
@@ -412,6 +430,8 @@ static int fimc_capture_close(struct file *file)
fimc_subdev_unregister(fimc);
}
+ pm_runtime_put_sync(fimc-pdev-dev);
+
return 0;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index bdf19ad..4540280 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/list.h
#include linux/io.h
#include linux/slab.h
@@ -302,7 +303,6 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
static void fimc_m2m_job_finish(struct fimc_ctx *ctx, int vb_state)
{
struct vb2_buffer *src_vb, *dst_vb;
- struct fimc_dev *fimc = ctx-fimc_dev;
if (!ctx || !ctx-m2m_ctx)
return;
@@ -313,43 +313,41 @@ static void fimc_m2m_job_finish(struct fimc_ctx *ctx, int
vb_state)
if (src_vb dst_vb) {
v4l2_m2m_buf_done(src_vb, vb_state);
v4l2_m2m_buf_done(dst_vb, vb_state);
- v4l2_m2m_job_finish(fimc-m2m.m2m_dev, ctx-m2m_ctx);
+ v4l2_m2m_job_finish(ctx-fimc_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
}
}
/* Complete the transaction which has been scheduled for execution. */
-static void fimc_m2m_shutdown(struct fimc_ctx *ctx)
+static int fimc_m2m_shutdown(struct fimc_ctx *ctx)
{
struct fimc_dev *fimc = ctx-fimc_dev;
int ret;
if (!fimc_m2m_pending(fimc))
- return;
+ return 0;
fimc_ctx_state_lock_set(FIMC_CTX_SHUT, ctx);
ret = wait_event_timeout(fimc-irq_queue,
!fimc_ctx_state_is_set(FIMC_CTX_SHUT, ctx),
FIMC_SHUTDOWN_TIMEOUT);
- /*
-* In case of a timeout the buffers are not released in the interrupt
-* handler so return them here with the error flag set, if there are
-* any on the queue.
-*/
- if (ret == 0)
- fimc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
}
static int stop_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q-drv_priv;
+ int ret;
- fimc_m2m_shutdown(ctx);
-
+ ret = fimc_m2m_shutdown(ctx);
+ if (ret == -ETIMEDOUT)
+ fimc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
return 0;
}
-static void fimc_capture_irq_handler(struct fimc_dev *fimc)
+void fimc_capture_irq_handler(struct fimc_dev *fimc)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *v_buf;
@@ -404,7 +402,7 @@ static void fimc_capture_irq_handler(struct fimc_dev *fimc)
fimc_hw_get_frame_index(fimc), cap-active_buf_cnt);
}
-static irqreturn_t fimc_isr(int irq, void *priv)
[PATCH/RFC 05/19] s5p-fimc: Limit number of available inputs to one
Camera sensors at FIMC input are no longer selected with S_INPUT ioctl.
They will be attached to required FIMC entity through pipeline
re-configuration at the media device level.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 43 ---
1 files changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 2748cca..19f27d4 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -566,57 +566,26 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
}
static int fimc_cap_enum_input(struct file *file, void *priv,
-struct v4l2_input *i)
+ struct v4l2_input *i)
{
struct fimc_ctx *ctx = priv;
- struct s5p_platform_fimc *pldata = ctx-fimc_dev-pdata;
- struct s5p_fimc_isp_info *isp_info;
- if (i-index = pldata-num_clients)
+ if (i-index != 0)
return -EINVAL;
- isp_info = pldata-isp_info[i-index];
i-type = V4L2_INPUT_TYPE_CAMERA;
- strncpy(i-name, isp_info-board_info-type, 32);
return 0;
}
-static int fimc_cap_s_input(struct file *file, void *priv,
- unsigned int i)
+static int fimc_cap_s_input(struct file *file, void *priv, unsigned int i)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_dev *fimc = ctx-fimc_dev;
- struct s5p_platform_fimc *pdata = fimc-pdata;
-
- if (fimc_capture_active(ctx-fimc_dev))
- return -EBUSY;
-
- if (i = pdata-num_clients)
- return -EINVAL;
-
-
- if (fimc-vid_cap.sd) {
- int ret = v4l2_subdev_call(fimc-vid_cap.sd, core, s_power, 0);
- if (ret)
- err(s_power failed: %d, ret);
-
- clk_disable(fimc-clock[CLK_CAM]);
- }
-
- /* Release the attached sensor subdevice. */
- fimc_subdev_unregister(fimc);
-
- return fimc_isp_subdev_init(fimc, i);
+ return i == 0 ? i : -EINVAL;
}
-static int fimc_cap_g_input(struct file *file, void *priv,
- unsigned int *i)
+static int fimc_cap_g_input(struct file *file, void *priv, unsigned int *i)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_vid_cap *cap = ctx-fimc_dev-vid_cap;
-
- *i = cap-input_index;
+ *i = 0;
return 0;
}
--
1.7.5.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
[PATCH/RFC 02/19] s5p-fimc: Add media entity initialization
Add intialization of the media entities for video capture
and mem-to-mem video nodes.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 28 --
drivers/media/video/s5p-fimc/fimc-core.c| 27 +++--
drivers/media/video/s5p-fimc/fimc-core.h|4 +++
3 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 9432ea8..2748cca 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -842,9 +842,8 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
fr-width = fr-f_width = fr-o_width = 640;
fr-height = fr-f_height = fr-o_height = 480;
- if (!v4l2_dev-name[0])
- snprintf(v4l2_dev-name, sizeof(v4l2_dev-name),
-%s.capture, dev_name(fimc-pdev-dev));
+ snprintf(v4l2_dev-name, sizeof(v4l2_dev-name),
+%s.capture, dev_name(fimc-pdev-dev));
ret = v4l2_device_register(NULL, v4l2_dev);
if (ret)
@@ -856,11 +855,11 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
goto err_v4l2_reg;
}
- snprintf(vfd-name, sizeof(vfd-name), %s:cap,
-dev_name(fimc-pdev-dev));
+ strlcpy(vfd-name, v4l2_dev-name, sizeof(vfd-name));
vfd-fops = fimc_capture_fops;
vfd-ioctl_ops = fimc_capture_ioctl_ops;
+ vfd-v4l2_dev = v4l2_dev;
vfd-minor = -1;
vfd-release= video_device_release;
vfd-lock = fimc-lock;
@@ -890,6 +889,11 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
vb2_queue_init(q);
+ fimc-vid_cap.vd_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_init(vfd-entity, 1, fimc-vid_cap.vd_pad, 0);
+ if (ret)
+ goto err_ent;
+
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(v4l2_dev, Failed to register video device\n);
@@ -899,10 +903,11 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
v4l2_info(v4l2_dev,
FIMC capture driver registered as /dev/video%d\n,
vfd-num);
-
return 0;
err_vd_reg:
+ media_entity_cleanup(vfd-entity);
+err_ent:
video_device_release(vfd);
err_v4l2_reg:
v4l2_device_unregister(v4l2_dev);
@@ -914,10 +919,11 @@ err_info:
void fimc_unregister_capture_device(struct fimc_dev *fimc)
{
- struct fimc_vid_cap *capture = fimc-vid_cap;
+ struct video_device *vfd = fimc-vid_cap.vfd;
- if (capture-vfd)
- video_unregister_device(capture-vfd);
-
- kfree(capture-ctx);
+ if (vfd) {
+ media_entity_cleanup(vfd-entity);
+ video_unregister_device(vfd);
+ }
+ kfree(fimc-vid_cap.ctx);
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 4540280..ad15d46 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1504,10 +1504,8 @@ static int fimc_register_m2m_device(struct fimc_dev
*fimc)
pdev = fimc-pdev;
v4l2_dev = fimc-m2m.v4l2_dev;
- /* set name if it is empty */
- if (!v4l2_dev-name[0])
- snprintf(v4l2_dev-name, sizeof(v4l2_dev-name),
-%s.m2m, dev_name(pdev-dev));
+ snprintf(v4l2_dev-name, sizeof(v4l2_dev-name),
+%s.m2m, dev_name(pdev-dev));
ret = v4l2_device_register(pdev-dev, v4l2_dev);
if (ret)
@@ -1521,6 +1519,7 @@ static int fimc_register_m2m_device(struct fimc_dev *fimc)
vfd-fops = fimc_m2m_fops;
vfd-ioctl_ops = fimc_m2m_ioctl_ops;
+ vfd-v4l2_dev = v4l2_dev;
vfd-minor = -1;
vfd-release= video_device_release;
vfd-lock = fimc-lock;
@@ -1538,17 +1537,22 @@ static int fimc_register_m2m_device(struct fimc_dev
*fimc)
goto err_m2m_r2;
}
+ ret = media_entity_init(vfd-entity, 0, NULL, 0);
+ if (ret)
+ goto err_m2m_r3;
+
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(v4l2_dev,
%s(): failed to register video device\n, __func__);
- goto err_m2m_r3;
+ goto err_m2m_r4;
}
v4l2_info(v4l2_dev,
FIMC m2m driver registered as /dev/video%d\n, vfd-num);
return 0;
-
+err_m2m_r4:
+ media_entity_cleanup(vfd-entity);
err_m2m_r3:
v4l2_m2m_release(fimc-m2m.m2m_dev);
err_m2m_r2:
@@ -1561,12 +1565,13 @@ err_m2m_r1:
void fimc_unregister_m2m_device(struct fimc_dev *fimc)
{
- if (fimc) {
-
[PATCH/RFC 03/19] s5p-fimc: Remove registration of video nodes from probe()
Do not register video nodes during FIMC device probe. Also make
fimc_register_m2m_device() public for use by the media device driver.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 18 +-
drivers/media/video/s5p-fimc/fimc-core.h |1 +
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index ad15d46..b464da5 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1491,7 +1491,7 @@ static struct v4l2_m2m_ops m2m_ops = {
.job_abort = fimc_job_abort,
};
-static int fimc_register_m2m_device(struct fimc_dev *fimc)
+int fimc_register_m2m_device(struct fimc_dev *fimc)
{
struct video_device *vfd;
struct platform_device *pdev;
@@ -1700,25 +1700,12 @@ static int fimc_probe(struct platform_device *pdev)
goto err_irq;
}
- ret = fimc_register_m2m_device(fimc);
- if (ret)
- goto err_irq;
-
- /* At least one camera sensor is required to register capture node */
- if (cap_input_index = 0) {
- ret = fimc_register_capture_device(fimc);
- if (ret)
- goto err_m2m;
- }
-
dev_dbg(pdev-dev, %s(): fimc-%d registered successfully\n,
__func__, fimc-id);
pm_runtime_put_sync(fimc-pdev-dev);
return 0;
-err_m2m:
- fimc_unregister_m2m_device(fimc);
err_irq:
free_irq(fimc-irq, fimc);
err_clk:
@@ -1805,9 +1792,6 @@ static int __devexit fimc_remove(struct platform_device
*pdev)
fimc_suspend(pdev-dev);
pm_runtime_set_suspended(pdev-dev);
- fimc_unregister_m2m_device(fimc);
- fimc_unregister_capture_device(fimc);
-
vb2_dma_contig_cleanup_ctx(fimc-alloc_ctx);
clk_disable(fimc-clock[CLK_BUS]);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 55c1410..c088dac 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -644,6 +644,7 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx);
int fimc_prepare_config(struct fimc_ctx *ctx, u32 flags);
int fimc_prepare_addr(struct fimc_ctx *ctx, struct vb2_buffer *vb,
struct fimc_frame *frame, struct fimc_addr *paddr);
+int fimc_register_m2m_device(struct fimc_dev *fimc);
/* -*/
/* fimc-capture.c */
--
1.7.5.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
[PATCH/RFC 12/19] s5p-fimc: Add PM helper function for streaming control
Create a helper function for (re)starting streaming PM resume calls.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 78 ---
drivers/media/video/s5p-fimc/fimc-core.c|4 +-
drivers/media/video/s5p-fimc/fimc-core.h|3 +
3 files changed, 52 insertions(+), 33 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index cfc2c98..615ca4b 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -31,6 +31,48 @@
#include fimc-mdevice.h
#include fimc-core.h
+/**
+ * fimc_start_capture - initialize the H/W for camera capture operation
+ *
+ * Initialize the camera capture datapath so when this function successfuly
+ * completes all what is needed to start the capture pipeline is asserting
+ * the global capture bit ImgCptEn.
+ */
+static int fimc_start_capture(struct fimc_dev *fimc)
+{
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
+ struct fimc_sensor_info *sensor;
+ unsigned long flags;
+ int ret = 0;
+
+ if (fimc-pipeline.sensor == NULL || ctx == NULL)
+ return -EIO;
+ sensor = v4l2_get_subdev_hostdata(fimc-pipeline.sensor);
+
+ spin_lock_irqsave(fimc-slock, flags);
+ fimc_prepare_dma_offset(ctx, ctx-d_frame);
+ fimc_set_yuv_order(ctx);
+
+ fimc_hw_set_camera_polarity(fimc, sensor-pdata);
+ fimc_hw_set_camera_type(fimc, sensor-pdata);
+ fimc_hw_set_camera_source(fimc, sensor-pdata);
+ fimc_hw_set_camera_offset(fimc, ctx-s_frame);
+
+ ret = fimc_set_scaler_info(ctx);
+ if (!ret) {
+ fimc_hw_set_input_path(ctx);
+ fimc_hw_set_prescaler(ctx);
+ fimc_hw_set_mainscaler(ctx);
+ fimc_hw_set_target_format(ctx);
+ fimc_hw_set_rotation(ctx);
+ fimc_hw_set_effect(ctx);
+ fimc_hw_set_output_path(ctx);
+ fimc_hw_set_out_dma(ctx);
+ }
+ spin_unlock_irqrestore(fimc-slock, flags);
+ return ret;
+}
+
static int fimc_stop_capture(struct fimc_dev *fimc)
{
unsigned long flags;
@@ -92,47 +134,21 @@ static int start_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q-drv_priv;
struct fimc_dev *fimc = ctx-fimc_dev;
- struct s5p_fimc_isp_info *isp_info;
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
int ret;
fimc_hw_reset(fimc);
- ret = v4l2_subdev_call(fimc-vid_cap.sd, video, s_stream, 1);
- if (ret ret != -ENOIOCTLCMD)
- return ret;
-
- ret = fimc_prepare_config(ctx, ctx-state);
- if (ret)
- return ret;
-
- isp_info = fimc-pdata-isp_info[fimc-vid_cap.input_index];
- fimc_hw_set_camera_type(fimc, isp_info);
- fimc_hw_set_camera_source(fimc, isp_info);
- fimc_hw_set_camera_offset(fimc, ctx-s_frame);
-
- if (ctx-state FIMC_PARAMS) {
- ret = fimc_set_scaler_info(ctx);
- if (ret) {
- err(Scaler setup error);
- return ret;
- }
- fimc_hw_set_input_path(ctx);
- fimc_hw_set_prescaler(ctx);
- fimc_hw_set_mainscaler(ctx);
- fimc_hw_set_target_format(ctx);
- fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx);
- }
-
- fimc_hw_set_output_path(ctx);
- fimc_hw_set_out_dma(ctx);
-
INIT_LIST_HEAD(fimc-vid_cap.pending_buf_q);
INIT_LIST_HEAD(fimc-vid_cap.active_buf_q);
fimc-vid_cap.active_buf_cnt = 0;
fimc-vid_cap.frame_count = 0;
fimc-vid_cap.buf_index = 0;
+ ret = fimc_start_capture(fimc);
+ if (ret)
+ return ret;
+
set_bit(ST_CAPT_PEND, fimc-state);
return 0;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index a0703e8..da52d4f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -468,7 +468,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
/* Set order for 1 and 2 plane YCBCR 4:2:2 formats. */
-static void fimc_set_yuv_order(struct fimc_ctx *ctx)
+void fimc_set_yuv_order(struct fimc_ctx *ctx)
{
/* The one only mode supported in SoC. */
ctx-in_order_2p = S5P_FIMC_LSB_CRCB;
@@ -510,7 +510,7 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
dbg(ctx-out_order_1p= %d, ctx-out_order_1p);
}
-static void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
+void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
{
struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
u32 i, depth = 0;
diff --git
[PATCH/RFC 11/19] s5p-fimc: Add media operations in the capture entity driver
Add the link_setup handler for the camera capture video node.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 32 +++
drivers/media/video/s5p-fimc/fimc-core.h|2 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index a14f857..cfc2c98 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -654,6 +654,37 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_g_input = fimc_cap_g_input,
};
+/* Media operations */
+static int fimc_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct video_device *vd = media_entity_to_video_device(entity);
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(remote-entity);
+ struct fimc_dev *fimc = video_get_drvdata(vd);
+
+ if (WARN_ON(fimc == NULL))
+ return 0;
+
+ dbg(%s -- %s, flags: 0x%x. input: 0x%x,
+ local-entity-name, remote-entity-name, flags,
+ fimc-vid_cap.input);
+
+ if (flags MEDIA_LNK_FL_ENABLED) {
+ if (fimc-vid_cap.input != 0)
+ return -EBUSY;
+ fimc-vid_cap.input = sd-grp_id;
+ return 0;
+ }
+
+ fimc-vid_cap.input = 0;
+ return 0;
+}
+
+static const struct media_entity_operations fimc_media_ops = {
+ .link_setup = fimc_link_setup,
+};
+
/* fimc-lock must be already initialized */
int fimc_register_capture_device(struct fimc_dev *fimc,
struct v4l2_device *v4l2_dev)
@@ -728,6 +759,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
if (ret)
goto err_ent;
+ vfd-entity.ops = fimc_media_ops;
vfd-ctrl_handler = ctx-ctrl_handler;
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index eb5fa47..793575b 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -305,6 +305,7 @@ struct fimc_m2m_device {
* @reqbufs_count: the number of buffers requested in REQBUFS ioctl
* @input_index: input (camera sensor) index
* @refcnt: driver's private reference counter
+ * @input: capture input type, grp_id of attached subdev
*/
struct fimc_vid_cap {
struct fimc_ctx *ctx;
@@ -322,6 +323,7 @@ struct fimc_vid_cap {
unsigned intreqbufs_count;
int input_index;
int refcnt;
+ u32 input;
};
/**
--
1.7.5.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
[PATCH/RFC 04/19] s5p-fimc: Remove sclk_cam clock handling
The external sclk_cam clocks will be handled at the media device
driver level.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 12 ++--
drivers/media/video/s5p-fimc/fimc-core.h |3 +--
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index b464da5..d8949c0 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -31,7 +31,7 @@
#include fimc-core.h
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
- sclk_fimc, fimc, sclk_cam
+ sclk_fimc, fimc
};
static struct fimc_fmt fimc_formats[] = {
@@ -1605,7 +1605,6 @@ static int fimc_probe(struct platform_device *pdev)
struct samsung_fimc_driverdata *drv_data;
struct s5p_platform_fimc *pdata;
int ret = 0;
- int cap_input_index = -1;
dev_dbg(pdev-dev, %s():\n, __func__);
@@ -1658,14 +1657,6 @@ static int fimc_probe(struct platform_device *pdev)
goto err_req_region;
}
- fimc-num_clocks = MAX_FIMC_CLOCKS - 1;
-
- /* Check if a video capture node needs to be registered. */
- if (pdata pdata-num_clients 0) {
- cap_input_index = 0;
- fimc-num_clocks++;
- }
-
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(pdev-dev, failed to get IRQ resource\n);
@@ -1674,6 +1665,7 @@ static int fimc_probe(struct platform_device *pdev)
}
fimc-irq = res-start;
+ fimc-num_clocks = MAX_FIMC_CLOCKS;
ret = fimc_clk_get(fimc);
if (ret)
goto err_regs_unmap;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index c088dac..f059216 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -34,7 +34,7 @@
/* Time to wait for next frame VSYNC interrupt while stopping operation. */
#define FIMC_SHUTDOWN_TIMEOUT ((100*HZ)/1000)
-#define MAX_FIMC_CLOCKS3
+#define MAX_FIMC_CLOCKS2
#define MODULE_NAMEs5p-fimc
#define FIMC_MAX_DEVS 4
#define FIMC_MAX_OUT_BUFS 4
@@ -46,7 +46,6 @@
enum {
CLK_BUS,
CLK_GATE,
- CLK_CAM,
};
enum fimc_dev_flags {
--
1.7.5.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
[PATCH/RFC 07/19] s5p-fimc: Remove v4l2_device from video capture and m2m driver
Currently there is a v4l2_device instance being registered per each
(capture and memory-to-memory) video node created per FIMC H/W instance.
This patch is a prerequisite for using the top level v4l2_device
instantiated by the media device driver.
To retain current debug trace semantic (so it's possible to distinguish
between the capture and m2m FIMC) the video_device is used in place
of v4l2_device where appropriate.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 43 -
drivers/media/video/s5p-fimc/fimc-core.c| 54 ++-
drivers/media/video/s5p-fimc/fimc-core.h| 15 ---
drivers/media/video/s5p-fimc/fimc-reg.c |7 ++-
4 files changed, 48 insertions(+), 71 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 0ddeacc..d4a4c86 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -133,7 +133,6 @@ static int start_streaming(struct vb2_queue *q)
fimc-vid_cap.buf_index = 0;
set_bit(ST_CAPT_PEND, fimc-state);
-
return 0;
}
@@ -180,7 +179,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
{
struct vb2_queue *vq = vb-vb2_queue;
struct fimc_ctx *ctx = vq-drv_priv;
- struct v4l2_device *v4l2_dev = ctx-fimc_dev-m2m.v4l2_dev;
int i;
if (!ctx-d_frame.fmt || vq-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
@@ -190,7 +188,8 @@ static int buffer_prepare(struct vb2_buffer *vb)
unsigned long size = get_plane_size(ctx-d_frame, i);
if (vb2_plane_size(vb, i) size) {
- v4l2_err(v4l2_dev, User buffer too small (%ld
%ld)\n,
+ v4l2_err(ctx-fimc_dev-vid_cap.vfd,
+User buffer too small (%ld %ld)\n,
vb2_plane_size(vb, i), size);
return -EINVAL;
}
@@ -402,7 +401,8 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
pix = f-fmt.pix_mp;
frame-fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
if (!frame-fmt) {
- err(fimc target format not found\n);
+ v4l2_err(fimc-vid_cap.vfd,
+Not supported capture (FIMC target) color format\n);
return -EINVAL;
}
@@ -462,7 +462,7 @@ static int fimc_cap_streamon(struct file *file, void *priv,
return -EBUSY;
if (!(ctx-state FIMC_DST_FMT)) {
- v4l2_err(fimc-vid_cap.v4l2_dev, Format is not set\n);
+ v4l2_err(fimc-vid_cap.vfd, Format is not set\n);
return -EINVAL;
}
@@ -592,9 +592,8 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
return ret;
if (!(ctx-state FIMC_DST_FMT)) {
- v4l2_err(fimc-vid_cap.v4l2_dev,
-Capture color format not set\n);
- return -EINVAL; /* TODO: make sure this is the right value */
+ v4l2_err(fimc-vid_cap.vfd, Capture format is not set\n);
+ return -EINVAL;
}
f = ctx-s_frame;
@@ -603,7 +602,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
ctx-d_frame.width, ctx-d_frame.height,
ctx-rotation);
if (ret) {
- v4l2_err(fimc-vid_cap.v4l2_dev, Out of the scaler range\n);
+ v4l2_err(fimc-vid_cap.vfd, Out of the scaler range\n);
return ret;
}
@@ -647,16 +646,16 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
};
/* fimc-lock must be already initialized */
-int fimc_register_capture_device(struct fimc_dev *fimc)
+int fimc_register_capture_device(struct fimc_dev *fimc,
+struct v4l2_device *v4l2_dev)
{
- struct v4l2_device *v4l2_dev = fimc-vid_cap.v4l2_dev;
struct video_device *vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
struct v4l2_format f;
struct fimc_frame *fr;
struct vb2_queue *q;
- int ret;
+ int ret = -ENOMEM;
ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
if (!ctx)
@@ -674,20 +673,14 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
fr-width = fr-f_width = fr-o_width = 640;
fr-height = fr-f_height = fr-o_height = 480;
- snprintf(v4l2_dev-name, sizeof(v4l2_dev-name),
-%s.capture, dev_name(fimc-pdev-dev));
-
- ret = v4l2_device_register(NULL, v4l2_dev);
- if (ret)
- goto err_info;
-
vfd = video_device_alloc();
if (!vfd) {
v4l2_err(v4l2_dev, Failed to allocate video device\n);
- goto err_v4l2_reg;
+
[PATCH/RFC 13/19] s5p-fimc: Correct color format enumeration
Create separate VIDIOC_ENUM_FMT ioctl handlers for video capture
and mem-to-mem video node. This is needed as some formats are
valid only for the video capture and some only for the mem-to-mem
video node. Create single function for pixel format lookup out of
find_mbus_format() and find_format().
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 32 ++
drivers/media/video/s5p-fimc/fimc-core.c| 61 +--
drivers/media/video/s5p-fimc/fimc-core.h|6 +-
drivers/media/video/s5p-fimc/fimc-mdevice.c |2 +-
4 files changed, 56 insertions(+), 45 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 615ca4b..896b3b9 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -382,6 +382,22 @@ static int fimc_vidioc_querycap_capture(struct file *file,
void *priv,
return 0;
}
+static int fimc_cap_enum_fmt_mplane(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ struct fimc_fmt *fmt;
+
+ fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM | FMT_FLAGS_M2M,
+ f-index);
+ if (!fmt)
+ return -EINVAL;
+ strncpy(f-description, fmt-name, sizeof(f-description) - 1);
+ f-pixelformat = fmt-fourcc;
+ if (fmt-fourcc == V4L2_MBUS_FMT_JPEG_1X8)
+ f-flags |= V4L2_FMT_FLAG_COMPRESSED;
+ return 0;
+}
+
/* Synchronize formats of the camera interface input and attached sensor. */
static int sync_capture_fmt(struct fimc_ctx *ctx)
{
@@ -400,7 +416,7 @@ static int sync_capture_fmt(struct fimc_ctx *ctx)
}
dbg(w: %d, h: %d, code= %d, fmt-width, fmt-height, fmt-code);
- frame-fmt = find_mbus_format(fmt, FMT_FLAGS_CAM);
+ frame-fmt = fimc_find_format(NULL, fmt, FMT_FLAGS_CAM, -1);
if (!frame-fmt) {
err(fimc source format not found\n);
return -EINVAL;
@@ -462,12 +478,10 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
frame = ctx-d_frame;
pix = f-fmt.pix_mp;
- frame-fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
- if (!frame-fmt) {
- v4l2_err(fimc-vid_cap.vfd,
-Not supported capture (FIMC target) color format\n);
+ frame-fmt = fimc_find_format(f, NULL,
+ FMT_FLAGS_M2M | FMT_FLAGS_CAM, 0);
+ if (WARN(frame-fmt == NULL, Pixel format lookup failed\n))
return -EINVAL;
- }
for (i = 0; i frame-fmt-colplanes; i++) {
frame-payload[i] =
@@ -647,7 +661,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
struct v4l2_crop *cr)
static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops = {
.vidioc_querycap= fimc_vidioc_querycap_capture,
- .vidioc_enum_fmt_vid_cap_mplane = fimc_vidioc_enum_fmt_mplane,
+ .vidioc_enum_fmt_vid_cap_mplane = fimc_cap_enum_fmt_mplane,
.vidioc_try_fmt_vid_cap_mplane = fimc_cap_try_fmt_mplane,
.vidioc_s_fmt_vid_cap_mplane= fimc_cap_s_fmt_mplane,
.vidioc_g_fmt_vid_cap_mplane= fimc_cap_g_fmt_mplane,
@@ -708,7 +722,6 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
struct video_device *vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
- struct v4l2_format f;
struct fimc_frame *fr;
struct vb2_queue *q;
int ret = -ENOMEM;
@@ -723,9 +736,8 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
ctx-state = FIMC_CTX_CAP;
/* Default format of the output frames */
- f.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB32;
fr = ctx-d_frame;
- fr-fmt = find_format(f, FMT_FLAGS_M2M);
+ fr-fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
fr-width = fr-f_width = fr-o_width = 640;
fr-height = fr-f_height = fr-o_height = 480;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index da52d4f..49ada07 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -860,18 +860,17 @@ static int fimc_m2m_querycap(struct file *file, void *fh,
return 0;
}
-int fimc_vidioc_enum_fmt_mplane(struct file *file, void *priv,
- struct v4l2_fmtdesc *f)
+static int fimc_m2m_enum_fmt_mplane(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
{
struct fimc_fmt *fmt;
- if (f-index = ARRAY_SIZE(fimc_formats))
+ fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_M2M, f-index);
+ if (!fmt)
return -EINVAL;
- fmt = fimc_formats[f-index];
[PATCH/RFC 09/19] s5p-fimc: Conversion to use struct v4l2_fh
This is a prerequisite for the patch converting the driver to use
the control framework. As the capture driver does not use per file
handle contexts, two separate ioctl handlers are created for it
(vidioc_try_fmt_mplane, and vidioc_g_fmt_mplane) so there is no
handlers shared between the memory-to-memory and capture video node.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 114 ++
drivers/media/video/s5p-fimc/fimc-core.c| 174 +++
drivers/media/video/s5p-fimc/fimc-core.h| 10 +-
3 files changed, 164 insertions(+), 134 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index d4a4c86..05e95da 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -263,7 +263,10 @@ static struct vb2_ops fimc_capture_qops = {
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
- int ret = 0;
+ int ret = v4l2_fh_open(file);
+
+ if (ret)
+ return ret;
dbg(pid: %d, state: 0x%lx, task_pid_nr(current), fimc-state);
@@ -272,11 +275,12 @@ static int fimc_capture_open(struct file *file)
return -EBUSY;
ret = pm_runtime_get_sync(fimc-pdev-dev);
- if (ret)
+ if (ret 0) {
+ v4l2_fh_release(file);
return ret;
+ }
++fimc-vid_cap.refcnt;
- file-private_data = fimc-vid_cap.ctx;
return 0;
}
@@ -294,22 +298,20 @@ static int fimc_capture_close(struct file *file)
pm_runtime_put_sync(fimc-pdev-dev);
- return 0;
+ return v4l2_fh_release(file);
}
static unsigned int fimc_capture_poll(struct file *file,
struct poll_table_struct *wait)
{
- struct fimc_ctx *ctx = file-private_data;
- struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
return vb2_poll(fimc-vid_cap.vbq, file, wait);
}
static int fimc_capture_mmap(struct file *file, struct vm_area_struct *vma)
{
- struct fimc_ctx *ctx = file-private_data;
- struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
return vb2_mmap(fimc-vid_cap.vbq, vma);
}
@@ -327,8 +329,7 @@ static const struct v4l2_file_operations fimc_capture_fops
= {
static int fimc_vidioc_querycap_capture(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct fimc_ctx *ctx = file-private_data;
- struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
strncpy(cap-driver, fimc-pdev-name, sizeof(cap-driver) - 1);
strncpy(cap-card, fimc-pdev-name, sizeof(cap-card) - 1);
@@ -376,20 +377,41 @@ static int sync_capture_fmt(struct fimc_ctx *ctx)
return 0;
}
+static int fimc_cap_g_fmt_mplane(struct file *file, void *fh,
+struct v4l2_format *f)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
+
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ return -EINVAL;
+
+ return fimc_fill_format(ctx-d_frame, f);
+}
+
+static int fimc_cap_try_fmt_mplane(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
+
+ return fimc_try_fmt_mplane(ctx, f);
+}
+
static int fimc_cap_s_fmt_mplane(struct file *file, void *priv,
struct v4l2_format *f)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_dev *fimc = ctx-fimc_dev;
- struct fimc_frame *frame;
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
struct v4l2_pix_format_mplane *pix;
+ struct fimc_frame *frame;
int ret;
int i;
if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
return -EINVAL;
- ret = fimc_vidioc_try_fmt_mplane(file, priv, f);
+ ret = fimc_try_fmt_mplane(ctx, f);
if (ret)
return ret;
@@ -431,7 +453,7 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
static int fimc_cap_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
- struct fimc_ctx *ctx = priv;
+ struct fimc_dev *fimc = video_drvdata(file);
if (i-index != 0)
return -EINVAL;
@@ -455,8 +477,8 @@ static int fimc_cap_g_input(struct file *file, void *priv,
unsigned int *i)
static int fimc_cap_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
{
-
[PATCH/RFC 08/19] s5p-fimc: Add the media device driver
The fimc media device driver is hooked onto s5p-fimc-md platform device.
Such a platform device need to be adde in a board initialization code
and then camera sensors need to be specified as it's platform data.
The s5p-fimc_md device is a top level entity for all FIMC, mipi-csis
and sensor devices.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-core.c| 12 +-
drivers/media/video/s5p-fimc/fimc-core.h| 10 +-
drivers/media/video/s5p-fimc/fimc-mdevice.c | 710 +++
drivers/media/video/s5p-fimc/fimc-mdevice.h | 126 +
include/media/s5p_fimc.h|2 +
7 files changed, 857 insertions(+), 7 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6b2b0dc..8ec1346 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -961,7 +961,7 @@ config VIDEO_MX2
config VIDEO_SAMSUNG_S5P_FIMC
tristate Samsung S5P and EXYNOS4 camera host interface driver
- depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P
+ depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P MEDIA_CONTROLLER
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index df6954a..33dec7f 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,4 +1,4 @@
-s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o
+s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o fimc-mdevice.o
s5p-csis-objs := mipi-csis.o
obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += s5p-csis.o
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 00e92a0..b4387d7 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -29,6 +29,7 @@
#include media/videobuf2-dma-contig.h
#include fimc-core.h
+#include fimc-mdevice.h
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
sclk_fimc, fimc
@@ -1972,7 +1973,7 @@ static struct platform_driver fimc_driver = {
.remove = __devexit_p(fimc_remove),
.id_table = fimc_driver_ids,
.driver = {
- .name = MODULE_NAME,
+ .name = FIMC_MODULE_NAME,
.owner = THIS_MODULE,
.pm = fimc_pm_ops,
}
@@ -1980,15 +1981,18 @@ static struct platform_driver fimc_driver = {
static int __init fimc_init(void)
{
- int ret = platform_driver_register(fimc_driver);
+ int ret;
+
+ ret = platform_driver_register(fimc_driver);
if (ret)
- err(platform_driver_register failed: %d\n, ret);
- return ret;
+ return ret;
+ return fimc_md_register_driver();
}
static void __exit fimc_exit(void)
{
platform_driver_unregister(fimc_driver);
+ fimc_md_unregister_driver();
}
module_init(fimc_init);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index fe82bf7..23aaa8c 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -36,7 +36,7 @@
/* Time to wait for next frame VSYNC interrupt while stopping operation. */
#define FIMC_SHUTDOWN_TIMEOUT ((100*HZ)/1000)
#define MAX_FIMC_CLOCKS2
-#define MODULE_NAMEs5p-fimc
+#define FIMC_MODULE_NAME s5p-fimc
#define FIMC_MAX_DEVS 4
#define FIMC_MAX_OUT_BUFS 4
#define SCALER_MAX_HRATIO 64
@@ -387,6 +387,12 @@ struct samsung_fimc_driverdata {
int num_entities;
};
+struct fimc_pipeline {
+ struct media_pipeline *pipe;
+ struct v4l2_subdev *sensor;
+ struct v4l2_subdev *csis;
+};
+
struct fimc_ctx;
/**
@@ -408,6 +414,7 @@ struct fimc_ctx;
* @vid_cap: camera capture device information
* @state: flags used to synchronize m2m and capture mode operation
* @alloc_ctx: videobuf2 memory allocator context
+ * @pipeline: fimc pipeline information
*/
struct fimc_dev {
spinlock_t slock;
@@ -427,6 +434,7 @@ struct fimc_dev {
struct fimc_vid_cap vid_cap;
unsigned long state;
struct vb2_alloc_ctx*alloc_ctx;
+ struct fimc_pipelinepipeline;
};
/**
diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c
b/drivers/media/video/s5p-fimc/fimc-mdevice.c
new file mode 100644
index 000..ae70a42
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c
@@ -0,0 +1,710 @@
+/*
+ * S5P/EXYNOS4 SoC series camera host interface media
[PATCH/RFC 17/19] s5p-fimc: Add v4l2_device notification support for single frame capture
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 47 +++
drivers/media/video/s5p-fimc/fimc-core.h|2 +
drivers/media/video/s5p-fimc/fimc-mdevice.c |1 +
include/media/s5p_fimc.h|9 +
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index d9f5829..6e932b2 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -871,6 +871,53 @@ static const struct media_entity_operations fimc_media_ops
= {
.link_setup = fimc_link_setup,
};
+/**
+ * fimc_sensor_notify - v4l2_device notification from a sensor subdev
+ * @sd: pointer to a subdev generating the notification
+ * @notification: the notification type, must be S5P_FIMC_TX_END_NOTIFY
+ * @arg: pointer to an u32 type integer that stores the frame payload value
+ *
+ * The End Of Frame notification sent by sensor subdev in its still capture
+ * mode. If there is only a single VSYNC generated by the sensor at the
+ * beginning of a frame transmission, FIMC does not issue the LastIrq
+ * (end of frame) interrupt. And this notification is used to complete the
+ * frame capture and returning a buffer to user-space. Subdev drivers should
+ * call this notification from their last 'End of frame capture' interrupt.
+ */
+void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
+ void *arg)
+{
+ struct fimc_sensor_info *sensor;
+ struct fimc_vid_buffer *buf;
+ struct fimc_md *fmd;
+ struct fimc_dev *fimc;
+ unsigned long flags;
+
+ if (sd == NULL)
+ return;
+
+ sensor = v4l2_get_subdev_hostdata(sd);
+ fmd = entity_to_fimc_mdev(sd-entity);
+
+ spin_lock_irqsave(fmd-slock, flags);
+ fimc = sensor ? sensor-parent : NULL;
+
+ if (fimc arg notification == S5P_FIMC_TX_END_NOTIFY
+ test_bit(ST_CAPT_PEND, fimc-state)) {
+ unsigned long irq_flags;
+ spin_lock_irqsave(fimc-slock, irq_flags);
+ if (!list_empty(fimc-vid_cap.active_buf_q)) {
+ buf = list_entry(fimc-vid_cap.active_buf_q.next,
+struct fimc_vid_buffer, list);
+ vb2_set_plane_payload(buf-vb, 0, *((u32 *)arg));
+ }
+ fimc_capture_irq_handler(fimc, true);
+ fimc_deactivate_capture(fimc);
+ spin_unlock_irqrestore(fimc-slock, irq_flags);
+ }
+ spin_unlock_irqrestore(fmd-slock, flags);
+}
+
static int fimc_subdev_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_fh *fh,
struct v4l2_subdev_mbus_code_enum *code)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index ca8d357..28f0e30 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -700,6 +700,8 @@ void fimc_unregister_capture_device(struct fimc_dev *fimc);
int fimc_capture_ctrls_create(struct fimc_dev *fimc);
int fimc_vid_cap_buf_queue(struct fimc_dev *fimc,
struct fimc_vid_buffer *fimc_vb);
+void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
+ void *arg);
int fimc_capture_suspend(struct fimc_dev *fimc);
int fimc_capture_resume(struct fimc_dev *fimc);
int fimc_capture_config_update(struct fimc_ctx *ctx);
diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c
b/drivers/media/video/s5p-fimc/fimc-mdevice.c
index 38ed74c..2622447 100644
--- a/drivers/media/video/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c
@@ -665,6 +665,7 @@ static int __devinit fimc_md_probe(struct platform_device
*pdev)
v4l2_dev = fmd-v4l2_dev;
v4l2_dev-mdev = fmd-media_dev;
+ v4l2_dev-notify = fimc_sensor_notify;
snprintf(v4l2_dev-name, sizeof(v4l2_dev-name), %s,
dev_name(pdev-dev));
diff --git a/include/media/s5p_fimc.h b/include/media/s5p_fimc.h
index 086a7aa..2b58904 100644
--- a/include/media/s5p_fimc.h
+++ b/include/media/s5p_fimc.h
@@ -60,4 +60,13 @@ struct s5p_platform_fimc {
struct s5p_fimc_isp_info *isp_info;
int num_clients;
};
+
+/*
+ * v4l2_device notification id. This is only for internal use in the kernel.
+ * Sensor subdevs should issue S5P_FIMC_TX_END_NOTIFY notification in single
+ * frame capture mode when there is only one VSYNC pulse issued by the sensor
+ * at begining of the frame transmission.
+ */
+#define S5P_FIMC_TX_END_NOTIFY _IO('e', 0)
+
#endif /* S5P_FIMC_H_ */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body
[PATCH/RFC 16/19] s5p-fimc: Add support for camera capture in JPEG format
Add support for transparent DMA transfer of JPEG data with MIPI-CSI2
USER1 format. In JPEG mode the color effect, scaling and cropping
is not supported. Same applies to image rotation and flip thus those
controls are marked as inactive when V4L2_PIX_FMT_JPEG pixelformat
is selected.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 22 +++-
drivers/media/video/s5p-fimc/fimc-core.c| 73 ++
drivers/media/video/s5p-fimc/fimc-core.h|7 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 31
drivers/media/video/s5p-fimc/regs-fimc.h|8 +--
5 files changed, 87 insertions(+), 54 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index f3efdbf..d9f5829 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -65,7 +65,7 @@ static int fimc_start_capture(struct fimc_dev *fimc)
fimc_hw_set_mainscaler(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx);
+ fimc_hw_set_effect(ctx, false);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
clear_bit(ST_CAPT_APPLY_CFG, fimc-state);
@@ -519,6 +519,17 @@ static int fimc_cap_try_fmt_mplane(struct file *file, void
*fh,
return fimc_try_fmt_mplane(ctx, f);
}
+static void fimc_capture_mark_jpeg_xfer(struct fimc_ctx *ctx, bool jpeg)
+{
+ ctx-scaler.enabled = !jpeg;
+ fimc_ctrls_activate(ctx, !jpeg);
+
+ if (jpeg)
+ set_bit(ST_CAPT_JPEG, ctx-fimc_dev-state);
+ else
+ clear_bit(ST_CAPT_JPEG, ctx-fimc_dev-state);
+}
+
static int fimc_cap_s_fmt_mplane(struct file *file, void *priv,
struct v4l2_format *f)
{
@@ -553,6 +564,9 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
(pix-width * pix-height * frame-fmt-depth[i]) 3;
}
+ /* Switch to the transparent DMA transfer mode if required */
+ fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(frame-fmt-color));
+
fimc_fill_frame(frame, f);
ctx-state |= FIMC_DST_FMT;
@@ -781,7 +795,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
struct v4l2_crop *cr)
f = ctx-s_frame;
/* Check for the pixel scaling ratio when cropping input image. */
- ret = fimc_check_scaler_ratio(cr-c.width, cr-c.height,
+ ret = fimc_check_scaler_ratio(ctx, cr-c.width, cr-c.height,
ctx-d_frame.width, ctx-d_frame.height,
ctx-rotation);
if (ret) {
@@ -981,6 +995,8 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
*mf = fmt-format;
return 0;
}
+ fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(ffmt-color));
+
ff = fmt-pad == FIMC_SD_PAD_SINK ?
ctx-s_frame : ctx-d_frame;
@@ -1046,7 +1062,7 @@ static int fimc_capture_try_crop(struct fimc_ctx *ctx,
struct v4l2_rect *r,
u32 min_sz;
/* In JPEG transparent transfer mode cropping is not supported */
- if (fimc_fmt_is_jpeg(sink-fmt-color)) {
+ if (fimc_fmt_is_jpeg(ctx-d_frame.fmt-color)) {
r-width = sink-f_width;
r-height = sink-f_height;
r-left = r-top = 0;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6d5d3e1..4261822 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -160,22 +160,28 @@ static struct fimc_fmt fimc_formats[] = {
.memplanes = 2,
.colplanes = 2,
.flags = FMT_FLAGS_M2M,
+ }, {
+ .name = JPEG encoded data,
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .color = S5P_FIMC_JPEG,
+ .depth = { 8 },
+ .memplanes = 1,
+ .colplanes = 1,
+ .mbus_code = V4L2_MBUS_FMT_JPEG_1X8,
+ .flags = FMT_FLAGS_CAM,
},
};
-int fimc_check_scaler_ratio(int sw, int sh, int dw, int dh, int rot)
+int fimc_check_scaler_ratio(struct fimc_ctx *ctx, int sw, int sh,
+ int dw, int dh, int rotation)
{
- int tx, ty;
+ if (rotation == 90 || rotation == 270)
+ swap(dw, dh);
- if (rot == 90 || rot == 270) {
- ty = dw;
- tx = dh;
- } else {
- tx = dw;
- ty = dh;
- }
+ if (!ctx-scaler.enabled)
+ return (sw == dw sh == dh) ? 0 : -EINVAL;
-
[PATCH/RFC 06/19] s5p-fimc: Remove sensor management code from FIMC capture driver
The sensor subdevs need to be shared between all available FIMC instances.
Remove their registration from FIMC capture driver so they can then be
registered to the media device driver.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 139 +--
drivers/media/video/s5p-fimc/fimc-core.h|2 +-
2 files changed, 2 insertions(+), 139 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 19f27d4..0ddeacc 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -17,12 +17,9 @@
#include linux/bug.h
#include linux/interrupt.h
#include linux/device.h
-#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/list.h
#include linux/slab.h
-#include linux/clk.h
-#include linux/i2c.h
#include linux/videodev2.h
#include media/v4l2-device.h
@@ -33,126 +30,6 @@
#include fimc-core.h
-static struct v4l2_subdev *fimc_subdev_register(struct fimc_dev *fimc,
- struct s5p_fimc_isp_info *isp_info)
-{
- struct i2c_adapter *i2c_adap;
- struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct v4l2_subdev *sd = NULL;
-
- i2c_adap = i2c_get_adapter(isp_info-i2c_bus_num);
- if (!i2c_adap)
- return ERR_PTR(-ENOMEM);
-
- sd = v4l2_i2c_new_subdev_board(vid_cap-v4l2_dev, i2c_adap,
- isp_info-board_info, NULL);
- if (!sd) {
- v4l2_err(vid_cap-v4l2_dev, failed to acquire subdev\n);
- return NULL;
- }
-
- v4l2_info(vid_cap-v4l2_dev, subdevice %s registered successfuly\n,
- isp_info-board_info-type);
-
- return sd;
-}
-
-static void fimc_subdev_unregister(struct fimc_dev *fimc)
-{
- struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct i2c_client *client;
-
- if (vid_cap-input_index 0)
- return; /* Subdevice already released or not registered. */
-
- if (vid_cap-sd) {
- v4l2_device_unregister_subdev(vid_cap-sd);
- client = v4l2_get_subdevdata(vid_cap-sd);
- i2c_unregister_device(client);
- i2c_put_adapter(client-adapter);
- vid_cap-sd = NULL;
- }
-
- vid_cap-input_index = -1;
-}
-
-/**
- * fimc_subdev_attach - attach v4l2_subdev to camera host interface
- *
- * @fimc: FIMC device information
- * @index: index to the array of available subdevices,
- *-1 for full array search or non negative value
- *to select specific subdevice
- */
-static int fimc_subdev_attach(struct fimc_dev *fimc, int index)
-{
- struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct s5p_platform_fimc *pdata = fimc-pdata;
- struct s5p_fimc_isp_info *isp_info;
- struct v4l2_subdev *sd;
- int i;
-
- for (i = 0; i pdata-num_clients; ++i) {
- isp_info = pdata-isp_info[i];
-
- if (index = 0 i != index)
- continue;
-
- sd = fimc_subdev_register(fimc, isp_info);
- if (!IS_ERR_OR_NULL(sd)) {
- vid_cap-sd = sd;
- vid_cap-input_index = i;
-
- return 0;
- }
- }
-
- vid_cap-input_index = -1;
- vid_cap-sd = NULL;
- v4l2_err(vid_cap-v4l2_dev, fimc%d: sensor attach failed\n,
-fimc-id);
- return -ENODEV;
-}
-
-static int fimc_isp_subdev_init(struct fimc_dev *fimc, unsigned int index)
-{
- struct s5p_fimc_isp_info *isp_info;
- struct s5p_platform_fimc *pdata = fimc-pdata;
- int ret;
-
- if (index = pdata-num_clients)
- return -EINVAL;
-
- isp_info = pdata-isp_info[index];
-
- if (isp_info-clk_frequency)
- clk_set_rate(fimc-clock[CLK_CAM], isp_info-clk_frequency);
-
- ret = clk_enable(fimc-clock[CLK_CAM]);
- if (ret)
- return ret;
-
- ret = fimc_subdev_attach(fimc, index);
- if (ret)
- return ret;
-
- ret = fimc_hw_set_camera_polarity(fimc, isp_info);
- if (ret)
- return ret;
-
- ret = v4l2_subdev_call(fimc-vid_cap.sd, core, s_power, 1);
- if (!ret)
- return ret;
-
- /* enabling power failed so unregister subdev */
- fimc_subdev_unregister(fimc);
-
- v4l2_err(fimc-vid_cap.v4l2_dev, ISP initialization failed: %d\n,
-ret);
-
- return ret;
-}
-
static int fimc_stop_capture(struct fimc_dev *fimc)
{
unsigned long flags;
@@ -399,15 +276,7 @@ static int fimc_capture_open(struct file *file)
if (ret)
return ret;
- if (++fimc-vid_cap.refcnt == 1) {
- ret = fimc_isp_subdev_init(fimc, 0);
[PATCH/RFC 18/19] s5p-fimc: Use consistent names for the buffer list functions
Also correct and improve *_queue_add/pop functions description.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |6 ++--
drivers/media/video/s5p-fimc/fimc-core.c|6 ++--
drivers/media/video/s5p-fimc/fimc-core.h| 38 +-
3 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 6e932b2..4f57fbb 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -101,12 +101,12 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
/* Release buffers that were enqueued in the driver by videobuf2. */
while (!list_empty(cap-pending_buf_q)) {
- buf = pending_queue_pop(cap);
+ buf = fimc_pending_queue_pop(cap);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
while (!list_empty(cap-active_buf_q)) {
- buf = active_queue_pop(cap);
+ buf = fimc_active_queue_pop(cap);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
@@ -263,7 +263,7 @@ static void buffer_queue(struct vb2_buffer *vb)
fimc_hw_set_output_addr(fimc, buf-paddr, buf_id);
buf-index = vid_cap-buf_index;
- active_queue_add(vid_cap, buf);
+ fimc_active_queue_add(vid_cap, buf);
if (++vid_cap-buf_index = FIMC_MAX_OUT_BUFS)
vid_cap-buf_index = 0;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 4261822..d573657 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -328,7 +328,7 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, bool
rel_buf)
test_bit(ST_CAPT_RUN, fimc-state) rel_buf) {
ktime_get_real_ts(ts);
- v_buf = active_queue_pop(cap);
+ v_buf = fimc_active_queue_pop(cap);
tv = v_buf-vb.v4l2_buf.timestamp;
tv-tv_sec = ts.tv_sec;
@@ -345,12 +345,12 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, bool
rel_buf)
if (!list_empty(cap-pending_buf_q)) {
- v_buf = pending_queue_pop(cap);
+ v_buf = fimc_pending_queue_pop(cap);
fimc_hw_set_output_addr(fimc, v_buf-paddr, cap-buf_index);
v_buf-index = cap-buf_index;
/* Move the buffer to the capture active queue */
- active_queue_add(cap, v_buf);
+ fimc_active_queue_add(cap, v_buf);
dbg(next frame: %d, done frame: %d,
fimc_hw_get_frame_index(fimc), v_buf-index);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 28f0e30..015d216 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -722,22 +722,27 @@ static inline void fimc_deactivate_capture(struct
fimc_dev *fimc)
}
/*
- * Add buf to the capture active buffers queue.
- * Locking: Need to be called with fimc_dev::slock held.
+ * Buffer list manipulation functions. Must be called with fimc.slock held.
*/
-static inline void active_queue_add(struct fimc_vid_cap *vid_cap,
- struct fimc_vid_buffer *buf)
+
+/**
+ * fimc_active_queue_add - add buffer to the capture active buffers queue
+ * @buf: buffer to add to the active buffers list
+ */
+static inline void fimc_active_queue_add(struct fimc_vid_cap *vid_cap,
+struct fimc_vid_buffer *buf)
{
list_add_tail(buf-list, vid_cap-active_buf_q);
vid_cap-active_buf_cnt++;
}
-/*
- * Pop a video buffer from the capture active buffers queue
- * Locking: Need to be called with fimc_dev::slock held.
+/**
+ * fimc_active_queue_pop - pop buffer from the capture active buffers queue
+ *
+ * The caller must assure the active_buf_q list is not empty.
*/
-static inline struct fimc_vid_buffer *
-active_queue_pop(struct fimc_vid_cap *vid_cap)
+static inline struct fimc_vid_buffer *fimc_active_queue_pop(
+ struct fimc_vid_cap *vid_cap)
{
struct fimc_vid_buffer *buf;
buf = list_entry(vid_cap-active_buf_q.next,
@@ -747,16 +752,23 @@ active_queue_pop(struct fimc_vid_cap *vid_cap)
return buf;
}
-/* Add video buffer to the capture pending buffers queue */
+/**
+ * fimc_pending_queue_add - add buffer to the capture pending buffers queue
+ * @buf: buffer to add to the pending buffers list
+ */
static inline void fimc_pending_queue_add(struct fimc_vid_cap *vid_cap,
struct fimc_vid_buffer *buf)
{
list_add_tail(buf-list, vid_cap-pending_buf_q);
}
-/*
[PATCH/RFC 14/19] s5p-fimc: Convert to use video pipeline operations
Add format negotiation routine for sensor subdevs not exposing
a device node.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 180 +--
drivers/media/video/s5p-fimc/fimc-core.c| 26 +++--
drivers/media/video/s5p-fimc/fimc-core.h|7 +-
drivers/media/video/s5p-fimc/fimc-reg.c |8 +-
4 files changed, 137 insertions(+), 84 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 896b3b9..e1b1d12 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -75,11 +75,9 @@ static int fimc_start_capture(struct fimc_dev *fimc)
static int fimc_stop_capture(struct fimc_dev *fimc)
{
- unsigned long flags;
- struct fimc_vid_cap *cap;
+ struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *buf;
-
- cap = fimc-vid_cap;
+ unsigned long flags;
if (!fimc_capture_active(fimc))
return 0;
@@ -93,11 +91,10 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
!test_bit(ST_CAPT_SHUT, fimc-state),
FIMC_SHUTDOWN_TIMEOUT);
- v4l2_subdev_call(cap-sd, video, s_stream, 0);
-
spin_lock_irqsave(fimc-slock, flags);
fimc-state = ~(1 ST_CAPT_RUN | 1 ST_CAPT_PEND |
-1 ST_CAPT_SHUT | 1 ST_CAPT_STREAM);
+1 ST_CAPT_SHUT | 1 ST_CAPT_STREAM |
+1 ST_CAPT_ISP_STREAM);
fimc-vid_cap.active_buf_cnt = 0;
@@ -113,9 +110,9 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
}
spin_unlock_irqrestore(fimc-slock, flags);
-
dbg(state: 0x%lx, fimc-state);
- return 0;
+
+ return fimc_pipeline_s_stream(fimc, 0);
}
int fimc_capture_suspend(struct fimc_dev *fimc)
@@ -219,10 +216,10 @@ static int buffer_prepare(struct vb2_buffer *vb)
static void buffer_queue(struct vb2_buffer *vb)
{
- struct fimc_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
- struct fimc_dev *fimc = ctx-fimc_dev;
struct fimc_vid_buffer *buf
= container_of(vb, struct fimc_vid_buffer, vb);
+ struct fimc_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
+ struct fimc_dev *fimc = ctx-fimc_dev;
struct fimc_vid_cap *vid_cap = fimc-vid_cap;
unsigned long flags;
int min_bufs;
@@ -249,9 +246,14 @@ static void buffer_queue(struct vb2_buffer *vb)
min_bufs = vid_cap-reqbufs_count 1 ? 2 : 1;
if (vid_cap-active_buf_cnt = min_bufs
- !test_and_set_bit(ST_CAPT_STREAM, fimc-state))
+ !test_and_set_bit(ST_CAPT_STREAM, fimc-state)) {
fimc_activate_capture(ctx);
+ spin_unlock_irqrestore(fimc-slock, flags);
+ if (!test_and_set_bit(ST_CAPT_ISP_STREAM, fimc-state))
+ fimc_pipeline_s_stream(fimc, 1);
+ return;
+ }
spin_unlock_irqrestore(fimc-slock, flags);
}
@@ -314,15 +316,19 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
- ret = pm_runtime_get_sync(fimc-pdev-dev);
- if (ret 0) {
- v4l2_fh_release(file);
- return ret;
- }
+ pm_runtime_get_sync(fimc-pdev-dev);
- if (++fimc-vid_cap.refcnt == 1)
+ if (++fimc-vid_cap.refcnt == 1) {
+ ret = fimc_pipeline_initialize(fimc,
+ fimc-vid_cap.vfd-entity, true);
+ if (ret 0) {
+ pm_runtime_put_sync(fimc-pdev-dev);
+ fimc-vid_cap.refcnt--;
+ v4l2_fh_release(file);
+ return ret;
+ }
ret = fimc_capture_ctrls_create(fimc);
-
+ }
return ret;
}
@@ -334,10 +340,10 @@ static int fimc_capture_close(struct file *file)
if (--fimc-vid_cap.refcnt == 0) {
fimc_stop_capture(fimc);
+ fimc_pipeline_shutdown(fimc);
fimc_ctrls_delete(fimc-vid_cap.ctx);
vb2_queue_release(fimc-vid_cap.vbq);
}
-
pm_runtime_put_sync(fimc-pdev-dev);
return v4l2_fh_release(file);
}
@@ -398,39 +404,69 @@ static int fimc_cap_enum_fmt_mplane(struct file *file,
void *priv,
return 0;
}
-/* Synchronize formats of the camera interface input and attached sensor. */
-static int sync_capture_fmt(struct fimc_ctx *ctx)
+/**
+ * fimc_pipeline_try_or_set_fmt - negotiate and/or set formats at pipeline
+ *elements
+ * @ctx: FIMC capture context
+ * @ff: pixel format to verify (width/height/fmt)
+ * @mfmt: if NULL format is only tried on subdevs, if not NULL format
+ *will be set on subdevs and returned
[PATCH/RFC 15/19] s5p-fimc: Add a subdev for the FIMC processing block
This subdev interface exposes the internal scaler and color converter
functionality to user space. Resolution and media bus format can now
be configured explicitly by applications. Camera frame composition
onto the output buffer can be confgured through set/get_crop at FIMC.{n}
source pad. Additionally crop, controls and composition may be
reconfigured while streaming.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 463 ++-
drivers/media/video/s5p-fimc/fimc-core.c|4 +
drivers/media/video/s5p-fimc/fimc-core.h| 33 ++-
drivers/media/video/s5p-fimc/fimc-mdevice.c | 32 ++-
4 files changed, 512 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index e1b1d12..f3efdbf 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -68,6 +68,7 @@ static int fimc_start_capture(struct fimc_dev *fimc)
fimc_hw_set_effect(ctx);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
+ clear_bit(ST_CAPT_APPLY_CFG, fimc-state);
}
spin_unlock_irqrestore(fimc-slock, flags);
return ret;
@@ -127,6 +128,33 @@ int fimc_capture_resume(struct fimc_dev *fimc)
return 0;
}
+/**
+ * fimc_capture_config_update - apply the camera interface configuration
+ *
+ * To be called from within the interrupt handler with fimc.slock
+ * spinlock held. Camera pixel crop, rotation and image flip state will
+ * be updated in the H/W.
+ */
+int fimc_capture_config_update(struct fimc_ctx *ctx)
+{
+ struct fimc_dev *fimc = ctx-fimc_dev;
+ int ret;
+
+ spin_lock(ctx-slock);
+ fimc_hw_set_camera_offset(fimc, ctx-s_frame);
+ ret = fimc_set_scaler_info(ctx);
+ if (ret == 0) {
+ fimc_hw_set_prescaler(ctx);
+ fimc_hw_set_mainscaler(ctx);
+ fimc_hw_set_target_format(ctx);
+ fimc_hw_set_rotation(ctx);
+ fimc_prepare_dma_offset(ctx, ctx-d_frame);
+ fimc_hw_set_out_dma(ctx);
+ }
+ spin_unlock(ctx-slock);
+ return ret;
+}
+
static int start_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q-drv_priv;
@@ -443,7 +471,7 @@ static int fimc_pipeline_try_or_set_fmt(struct fimc_ctx
*ctx,
while (ff-fmt-mbus_code != mf-code) {
if (mf-code != -1) {
ffmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, i++);
- if(!ffmt)
+ if (!ffmt)
return -EINVAL;
} else {
ffmt = ff-fmt;
@@ -532,7 +560,7 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
ret = fimc_pipeline_try_or_set_fmt(ctx, frame, mf);
fimc_md_graph_unlock(fimc);
if (!ret) {
- frame = ctx-s_frame;
+ frame = ctx-s_frame;
frame-f_width = mf-width;
frame-f_height = mf-height;
frame-o_width = mf-width;
@@ -571,12 +599,69 @@ static int fimc_cap_g_input(struct file *file, void
*priv, unsigned int *i)
return 0;
}
+/**
+ * fimc_pipeline_validate - check for formats inconsistencies on all links ends
+ *
+ * Return 0 if all formats match or -EPIPE otherwise.
+ */
+static int fimc_pipeline_validate(struct fimc_dev *fimc)
+{
+ struct v4l2_subdev_format sink_fmt, src_fmt;
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
+ struct v4l2_subdev *sd;
+ struct media_pad *pad;
+ int ret;
+
+ /* Start with the video capture node pad */
+ pad = media_entity_remote_source(vid_cap-vd_pad);
+ if (pad == NULL)
+ return -EPIPE;
+ /* FIMC.{N} subdevice */
+ sd = media_entity_to_v4l2_subdev(pad-entity);
+
+ while (1) {
+ /* Retrieve format at the sink pad */
+ pad = sd-entity.pads[0];
+ if (!(pad-flags MEDIA_PAD_FL_SINK))
+ break;
+ /* Don't call FIMC subdev operation to avoid a deadlock */
+ if (sd == fimc-vid_cap.subdev) {
+ sink_fmt.format.width = vid_cap-ctx-s_frame.f_width;
+ sink_fmt.format.height = vid_cap-ctx-s_frame.f_height;
+ } else {
+ sink_fmt.pad = pad-index;
+ sink_fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(sd, pad, get_fmt, NULL,
sink_fmt);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return -EPIPE;
+ }
+ /* Retrieve format at the source pad */
+ pad = media_entity_remote_source(pad);
+
[PATCH/RFC 19/19] s5p-fimc: Add runtime PM support in the camera capture driver
Add support for whole pipeline suspend/resume. Sensors must support
suspend/resume through s_power subdev operation.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 87 +++
drivers/media/video/s5p-fimc/fimc-core.c| 10 ++--
drivers/media/video/s5p-fimc/fimc-core.h|1 +
3 files changed, 67 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 4f57fbb..0d64d17 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -74,7 +74,7 @@ static int fimc_start_capture(struct fimc_dev *fimc)
return ret;
}
-static int fimc_stop_capture(struct fimc_dev *fimc)
+static int fimc_stop_capture(struct fimc_dev *fimc, bool suspend)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *buf;
@@ -90,26 +90,28 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
wait_event_timeout(fimc-irq_queue,
!test_bit(ST_CAPT_SHUT, fimc-state),
- FIMC_SHUTDOWN_TIMEOUT);
+ (2*HZ/10)); /* 200 ms */
spin_lock_irqsave(fimc-slock, flags);
- fimc-state = ~(1 ST_CAPT_RUN | 1 ST_CAPT_PEND |
-1 ST_CAPT_SHUT | 1 ST_CAPT_STREAM |
-1 ST_CAPT_ISP_STREAM);
+ fimc-state = ~(1 ST_CAPT_RUN | 1 ST_CAPT_SHUT |
+1 ST_CAPT_STREAM | 1 ST_CAPT_ISP_STREAM);
+ if (!suspend)
+ fimc-state = ~(1 ST_CAPT_PEND | 1 ST_CAPT_SUSPENDED);
- fimc-vid_cap.active_buf_cnt = 0;
-
- /* Release buffers that were enqueued in the driver by videobuf2. */
- while (!list_empty(cap-pending_buf_q)) {
+ /* Release unused buffers */
+ while (!suspend !list_empty(cap-pending_buf_q)) {
buf = fimc_pending_queue_pop(cap);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
-
+ /* If suspending put unused buffers onto pending queue */
while (!list_empty(cap-active_buf_q)) {
buf = fimc_active_queue_pop(cap);
- vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ if (suspend)
+ fimc_pending_queue_add(cap, buf);
+ else
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
-
+ set_bit(ST_CAPT_SUSPENDED, fimc-state);
spin_unlock_irqrestore(fimc-slock, flags);
dbg(state: 0x%lx, fimc-state);
@@ -118,13 +120,39 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
int fimc_capture_suspend(struct fimc_dev *fimc)
{
- /* TODO: */
- return -EBUSY;
+ bool suspend = fimc_capture_in_use(fimc);
+
+ int ret = fimc_stop_capture(fimc, suspend);
+ if (ret)
+ return ret;
+ return fimc_pipeline_shutdown(fimc);
}
+static void buffer_queue(struct vb2_buffer *vb);
+
int fimc_capture_resume(struct fimc_dev *fimc)
{
- /* TODO: */
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
+ struct fimc_vid_buffer *buf;
+ int i;
+
+ if (!test_and_clear_bit(ST_CAPT_SUSPENDED, fimc-state))
+ return 0;
+
+ INIT_LIST_HEAD(fimc-vid_cap.active_buf_q);
+ vid_cap-buf_index = 0;
+ fimc_pipeline_initialize(fimc, fimc-vid_cap.vfd-entity,
+false);
+ fimc_start_capture(fimc);
+
+ clear_bit(ST_CAPT_SUSPENDED, fimc-state);
+
+ for (i = 0; i vid_cap-reqbufs_count; i++) {
+ if (list_empty(vid_cap-pending_buf_q))
+ break;
+ buf = fimc_pending_queue_pop(vid_cap);
+ buffer_queue(buf-vb);
+ }
return 0;
}
@@ -164,11 +192,9 @@ static int start_streaming(struct vb2_queue *q)
fimc_hw_reset(fimc);
- INIT_LIST_HEAD(fimc-vid_cap.pending_buf_q);
- INIT_LIST_HEAD(fimc-vid_cap.active_buf_q);
- fimc-vid_cap.active_buf_cnt = 0;
- fimc-vid_cap.frame_count = 0;
- fimc-vid_cap.buf_index = 0;
+ vid_cap-active_buf_cnt = 0;
+ vid_cap-frame_count = 0;
+ vid_cap-buf_index = 0;
ret = fimc_start_capture(fimc);
if (ret)
@@ -186,7 +212,7 @@ static int stop_streaming(struct vb2_queue *q)
if (!fimc_capture_active(fimc))
return -EINVAL;
- return fimc_stop_capture(fimc);
+ return fimc_stop_capture(fimc, false);
}
static unsigned int get_plane_size(struct fimc_frame *fr, unsigned int plane)
@@ -255,8 +281,9 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_lock_irqsave(fimc-slock, flags);
fimc_prepare_addr(ctx, buf-vb, ctx-d_frame, buf-paddr);
- if (!test_bit(ST_CAPT_STREAM, fimc-state)
- vid_cap-active_buf_cnt FIMC_MAX_OUT_BUFS)
[PATCH/RFC 10/19] s5p-fimc: Conversion to the control framework
The FIMC entity supports rotation, horizontal and vertical flip
in camera capture and memory-to-memory operation mode.
Due to atomic contexts used in mem-to-mem driver the control
values need to be cached in drivers internal data structure.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 60 +++---
drivers/media/video/s5p-fimc/fimc-core.c| 288 +++
drivers/media/video/s5p-fimc/fimc-core.h| 34 ++--
drivers/media/video/s5p-fimc/fimc-mdevice.c | 11 +-
drivers/media/video/s5p-fimc/fimc-reg.c | 32 +---
5 files changed, 183 insertions(+), 242 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 05e95da..a14f857 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -28,6 +28,7 @@
#include media/videobuf2-core.h
#include media/videobuf2-dma-contig.h
+#include fimc-mdevice.h
#include fimc-core.h
static int fimc_stop_capture(struct fimc_dev *fimc)
@@ -260,6 +261,29 @@ static struct vb2_ops fimc_capture_qops = {
.stop_streaming = stop_streaming,
};
+/**
+ * fimc_capture_ctrls_create - initialize the control handler
+ *
+ * Initialize the capture video node control handler and populate it
+ * with FIMC specific controls. If the linked sensor subdevice does
+ * not expose a video node add its controls to the FIMC control
+ * handler. This function must be called with the graph mutex held.
+ */
+int fimc_capture_ctrls_create(struct fimc_dev *fimc)
+{
+ int ret;
+
+ if (WARN_ON(fimc-vid_cap.ctx == NULL))
+ return -ENXIO;
+ if (fimc-vid_cap.ctx-ctrls_rdy)
+ return 0;
+ ret = fimc_ctrls_create(fimc-vid_cap.ctx);
+ if (ret || subdev_has_devnode(fimc-pipeline.sensor))
+ return ret;
+ return v4l2_ctrl_add_handler(fimc-vid_cap.ctx-ctrl_handler,
+ fimc-pipeline.sensor-ctrl_handler);
+}
+
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
@@ -280,9 +304,10 @@ static int fimc_capture_open(struct file *file)
return ret;
}
- ++fimc-vid_cap.refcnt;
+ if (++fimc-vid_cap.refcnt == 1)
+ ret = fimc_capture_ctrls_create(fimc);
- return 0;
+ return ret;
}
static int fimc_capture_close(struct file *file)
@@ -293,11 +318,11 @@ static int fimc_capture_close(struct file *file)
if (--fimc-vid_cap.refcnt == 0) {
fimc_stop_capture(fimc);
+ fimc_ctrls_delete(fimc-vid_cap.ctx);
vb2_queue_release(fimc-vid_cap.vbq);
}
pm_runtime_put_sync(fimc-pdev-dev);
-
return v4l2_fh_release(file);
}
@@ -534,30 +559,6 @@ static int fimc_cap_dqbuf(struct file *file, void *priv,
return vb2_dqbuf(fimc-vid_cap.vbq, buf, file-f_flags O_NONBLOCK);
}
-static int fimc_cap_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct fimc_dev *fimc = video_drvdata(file);
- struct fimc_ctx *ctx = fimc-vid_cap.ctx;
- int ret = -EINVAL;
-
- /* Allow any controls but 90/270 rotation while streaming */
- if (!fimc_capture_active(ctx-fimc_dev) ||
- ctrl-id != V4L2_CID_ROTATE ||
- (ctrl-value != 90 ctrl-value != 270)) {
- ret = check_ctrl_val(ctx, ctrl);
- if (!ret) {
- ret = fimc_s_ctrl(ctx, ctrl);
- if (!ret)
- ctx-state |= FIMC_PARAMS;
- }
- }
- if (ret == -EINVAL)
- ret = v4l2_subdev_call(ctx-fimc_dev-vid_cap.sd,
- core, s_ctrl, ctrl);
- return ret;
-}
-
static int fimc_cap_cropcap(struct file *file, void *fh,
struct v4l2_cropcap *cr)
{
@@ -644,10 +645,6 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_streamon= fimc_cap_streamon,
.vidioc_streamoff = fimc_cap_streamoff,
- .vidioc_queryctrl = fimc_vidioc_queryctrl,
- .vidioc_g_ctrl = fimc_vidioc_g_ctrl,
- .vidioc_s_ctrl = fimc_cap_s_ctrl,
-
.vidioc_g_crop = fimc_cap_g_crop,
.vidioc_s_crop = fimc_cap_s_crop,
.vidioc_cropcap = fimc_cap_cropcap,
@@ -731,6 +728,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
if (ret)
goto err_ent;
+ vfd-ctrl_handler = ctx-ctrl_handler;
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(v4l2_dev, Failed to register video device\n);
diff --git
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jun 10 19:00:40 CEST 2011 git hash:75125b9d44456e0cf2d1fbb72ae33c13415299d1 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Hans de Goede wrote: Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. [...] 2) So called dual mode cameras are (cheap) stillcams often even without an lcdscreen viewfinder, and battery backed sram instead of flash, which double as a webcam. We have drivers for both the stillcam function of these (in libgphoto2, so using usbfs) as well as for the webcam function (v4l2 kernel drivers). These drivers work well, and are mature. Yet the user experience is rather poor. Under gnome the still-cam contents will be automatically be made available as a drive using a gvfs-gphoto2 fuse mount. This however involves sending a disconnect to the v4l2 kernel driver, and thus the /dev/video# node disappearing. So if a user wants to use the device as a webcam he/she needs to first go to nautilus and unmount the gvfs mount. Until that is done the user will simply get a message from an app like cheese that he has no webcam, not even an ebusy error, just that he has no such device. Again not good. [...] As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have thought before coding, as the result is not user-friendly in the least. 6. The question has been asked whether the cameras are always using the same interface. Typically, yes. The same altsetting? That depends on the camera. Some of them use isochronous transport for streaming, and some of them rely exclusively upon bulk transport. Those which use bulk transport only are confined to altsetting 0. Some possible solutions? Well, first of all it needs to be understood that the problem originates as a bad feature of something good, namely the rigid separation of kernelspace and userspace functionality which is an integral part of the Linux security model. Some other operating systems are not so careful, and thus they do not have a problem about supporting dual-mode hardware. Second, it appears to me that the problem is most appropriately addressed from the userspace side and perhaps also from the kernelspace side. In userspace, it would be a really good idea if those who are attempting to write user-friendly apps and to create user-friendly distros would actually learn some of the basics of Linux, such as the rudiments of the security model. Since dual-mode cameras are known to exist, it would have been appropriate, when one is detected, to pop up a dialog window which asks the user to choose a webcam app or a stillcam app. Even this minor innovation would stop a lot of user grief. Frankly, I am mystified that this was not done. This still leaves the problem (see item 3, above) that a dual-mode camera needs to be re-plugged in order to re-enable the access to /dev/video* if it has been used in stillcam mode. If it is possible to do a re-plug in software, this would help a lot. It does not matter if the re-plug
Re: USB mini-summit at LinuxCon Vancouver
On Thu, Jun 09, 2011 at 08:18:05PM -0700, Greg KH wrote: On Thu, Jun 09, 2011 at 05:21:03PM -0700, Sarah Sharp wrote: Topic 1 --- The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. Do people really want to virtualize the whole xHCI controller, or just specific ports or devices to the guest operating system? A host OS could chose to virtualize the whole xHCI controller if it wanted to. That's part of the reason why xHCI does all the bandwidth checking in hardware, not in software. If just specific ports, would something like usbip be better for virtual machines, with the USB traffic going over the network connection between the guest/host? It could be done that way too. But that doesn't help if you're trying to run Windows under Linux, right? Only if all the guest OSes use the same USB IP protocol then it would work. Hope to see you there! Thanks for putting this together. Do we need to sign up somewhere to give the organizers a sense of how many people will be attending? I private ack by email would be great. Or you can ack by facebook: https://www.facebook.com/event.php?eid=229532200405657 I could add the event in upcoming.yahoo.com if anyone uses that. Sarah Sharp -- 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 mini-summit at LinuxCon Vancouver
On Fri, Jun 10, 2011 at 12:48:15PM -0700, Sarah Sharp wrote: On Thu, Jun 09, 2011 at 08:18:05PM -0700, Greg KH wrote: On Thu, Jun 09, 2011 at 05:21:03PM -0700, Sarah Sharp wrote: Topic 1 --- The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. Do people really want to virtualize the whole xHCI controller, or just specific ports or devices to the guest operating system? A host OS could chose to virtualize the whole xHCI controller if it wanted to. That's part of the reason why xHCI does all the bandwidth checking in hardware, not in software. And here I thought it did that so it would be correct :) If just specific ports, would something like usbip be better for virtual machines, with the USB traffic going over the network connection between the guest/host? It could be done that way too. But that doesn't help if you're trying to run Windows under Linux, right? Only if all the guest OSes use the same USB IP protocol then it would work. usbip works on Windows as well as Linux. But how could you run Windows with a xHCI controller in a guest, as Windows has no xHCI driver? What would it expect to see? Hope to see you there! Thanks for putting this together. Do we need to sign up somewhere to give the organizers a sense of how many people will be attending? I private ack by email would be great. Or you can ack by facebook: https://www.facebook.com/event.php?eid=229532200405657 I could add the event in upcoming.yahoo.com if anyone uses that. Nice try, but I'm still not going to join facebook... -- 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: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Felipe Balbi wrote: I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. And the problem is how to coordinate the two of them. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? No. Something else is needed. Alan Stern -- 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: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 05:18:39PM -0400, Alan Stern wrote: 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. ach true.. Had forgotten that detail. Needs more thinking. -- balbi signature.asc Description: Digital signature
ov519 unknown sensor
Hello, I just wanted to let you know the Orion StarShoot Solar System Color Imaging Camera works with the latest v4l git tree (http://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git). It needs the case 0xb1: for the OV9600 that's not in Linus's tree yet. I didn't know what sensor was in the camera or weather it would work when I got it, so maybe this will help someone else who is googling that camera. thanks, Paul -- 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: ov519 unknown sensor
It's not an unknown sensor, please ignore that subject line. That was before I tested it with the latest v4l tree. 2011/6/10 Paul Thomas pthomas8...@gmail.com: Hello, I just wanted to let you know the Orion StarShoot Solar System Color Imaging Camera works with the latest v4l git tree (http://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git). It needs the case 0xb1: for the OV9600 that's not in Linus's tree yet. I didn't know what sensor was in the camera or weather it would work when I got it, so maybe this will help someone else who is googling that camera. thanks, Paul -- 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: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote: As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. Yes. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. As I understand, the basic reason why webcam functionality needs to be in the kernel is speed. Quick reaction time, and faster data transmission. Most but not all webcams use isochronous data transport. The ones which do not, cannot get as high a rate of frames per second. Isochronous data transport has historically seemed to need kernel support in order to work properly. Related to this, libusb has not supported isochronous data transport. But still cameras use bulk transport. This is natural because one needs to move data which is stored on the camera to a place on the computer where it can be processed (if needed) and stored. There is no impediment to userspace talking to a USB device, so why not go ahead and do the job that way if the kernel is not needed? The second thing to mention is that libgphoto2 at this point is supporting well over 1,000 cameras. True, there are not 1,000 driver libraries, but there are quite a few. My impression is that nobody wants to put stuff like that in the kernel unless it is absolutely necessary, just because some of those cameras are dual-mode cameras. Don't people complain on a fairly regular basis about kernel code bloat? 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) See above. 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. It's still wrong. This should be just another USB_REQ_SET_CONFIGURATION(). If this is was just one single driver, you could easily do that. Well, I think it ought to be possible anyway. Up to that point, I agree. Though I confess I do not exactly know how. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. I would only add to this, that it is not pleasant to have to deal with frustrated users. At this point, my usual advice is that this is a distro problem. Ask your distro for help. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? See above. 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Alan Stern wrote: On Fri, 10 Jun 2011, Felipe Balbi wrote: I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. And the problem is how to coordinate the two of them. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? No. Something else is needed. Alan Stern Agreed. Something else is needed. But what? Also, very good point about PTP. Theodore Kilgore -- 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 support for PCTV452E.
I think you've missed this line at the end of ttpci-eeprom.c : EXPORT_SYMBOL(ttpci_eeprom_decode_mac); -- 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: Improving kernel - userspace (usbfs) usb device hand off
On Sat, Jun 11, 2011 at 6:43 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: I do not believe that we have found the optimal solution, yet. The ideal thing would be some kind of hack which allows the kernel to be used when it is needed, and when it is not needed it does not interfere. Just wondering if you can use libusb-1.0 for the user space still image functionality. libusb-1.0 offers the following functions to do that for you under Linux. int libusb_kernel_driver_active (libusb_device_handle *dev, int interface) Determine if a kernel driver is active on an interface. int libusb_detach_kernel_driver (libusb_device_handle *dev, int interface) Detach a kernel driver from an interface. int libusb_attach_kernel_driver (libusb_device_handle *dev, int interface) Re-attach an interface's kernel driver, which was previously detached using libusb_detach_kernel_driver(). So you can detach the kernel v4l2 driver at the beginning and later re-attach it when you finish. -- Xiaofan -- 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-next: Tree for June 8 (docbook/media)
Hi Mauro, On Fri, 10 Jun 2011 12:19:12 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: PS.: A full build against next is broken: $ make -j 27 CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/x86/lib/memmove_64.o gcc: arch/x86/lib/memmove_64.c: No such file or directory gcc: no input files Was that a build starting from a clean (object) tree? -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpEBFD9EycMa.pgp Description: PGP signature
