Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
> > I doubt you can handle pci memory bars like regular ram when it comes to > > dma and iommu support. There is a reason we have p2pdma in the first > > place ... > > The thing is that such bars would be actually backed by regular host > RAM. Do we really need the complexity of real PCI bar handling for > that? Well, taking shortcuts because of virtualization-specific assumptions already caused problems in the past. See the messy iommu handling we have in virtio-pci for example. So I don't feel like going the "we know it's just normal pages, so lets simplify things" route. Beside that hostmap isn't important for secure buffers, we wouldn't allow the guest mapping them anyway ;) cheers, Gerd
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
Hi, > That could be still a guest physical address. Like on a bare metal > system with TrustZone, there could be physical memory that is not > accessible to the CPU. Hmm. Yes, maybe. We could use the dma address of the (first page of the) guest buffer. In case of a secure buffer the guest has no access to the guest buffer would be unused, but it would at least make sure that things don't crash in case someone tries to map & access the buffer. The host should be able to figure the corresponding host buffer from the guest buffer address. When running drm-misc-next you should be able to test whenever that'll actually work without any virtio-gpu driver changes. cheers, Gerd
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
Hi, > > Also note that the guest manages the address space, so the host can't > > simply allocate guest page addresses. > > Is this really true? I'm not an expert in this area, but on a bare > metal system it's the hardware or firmware that sets up the various > physical address allocations on a hardware level and most of the time > most of the addresses are already pre-assigned in hardware (like the > DRAM base, various IOMEM spaces, etc.). Yes, the firmware does it. Same in a VM, ovmf or seabios (which runs inside the guest) typically does it. And sometimes the linux kernel too. > I think that means that we could have a reserved region that could be > used by the host for dynamic memory hot-plug-like operation. The > reference to memory hot-plug here is fully intentional, we could even > use this feature of Linux to get struct pages for such memory if we > really wanted. We try to avoid such quirks whenever possible. Negotiating such things between qemu and firmware can be done if really needed (and actually is done for memory hotplug support), but it's an extra interface which needs maintenance. > > Mapping host virtio-gpu resources > > into guest address space is planned, it'll most likely use a pci memory > > bar to reserve some address space. The host can map resources into that > > pci bar, on guest request. > > Sounds like a viable option too. Do you have a pointer to some > description on how this would work on both host and guest side? Some early code: https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-gpu-memory-v2 https://git.kraxel.org/cgit/linux/log/?h=drm-virtio-memory-v2 Branches have other stuff too, look for "hostmem" commits. Not much code yet beyond creating a pci bar on the host and detecting presence in the guest. On the host side qemu would create subregions inside the hostmem memory region for the resources. Oh the guest side we can ioremap stuff, like vram. > > Hmm, well, pci memory bars are *not* backed by pages. Maybe we can use > > Documentation/driver-api/pci/p2pdma.rst though. With that we might be > > able to lookup buffers using device and dma address, without explicitly > > creating some identifier. Not investigated yet in detail. > > Not backed by pages as in "struct page", but those are still regular > pages of the physical address space. Well, maybe not. Host gem object could live in device memory, and if we map them into the guest ... > That said, currently the sg_table interface is only able to describe > physical memory using struct page pointers. It's been a long standing > limitation affecting even bare metal systems, so perhaps it's just the > right time to make them possible to use some other identifiers, like > PFNs? I doubt you can handle pci memory bars like regular ram when it comes to dma and iommu support. There is a reason we have p2pdma in the first place ... cheers, Gerd
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
Hi, > That said, Chrome OS would use a similar model, except that we don't > use ION. We would likely use minigbm backed by virtio-gpu to allocate > appropriate secure buffers for us and then import them to the V4L2 > driver. What exactly is a "secure buffer"? I guess a gem object where read access is not allowed, only scanout to display? Who enforces this? The hardware? Or the kernel driver? It might make sense for virtio-gpu to know that concept, to allow guests ask for secure buffers. And of course we'll need some way to pass around identifiers for these (and maybe other) buffers (from virtio-gpu device via guest drivers to virtio-vdec device). virtio-gpu guest driver could generate a uuid for that, attach it to the dma-buf and also notify the host so qemu can maintain a uuid -> buffer lookup table. cheers, Gerd
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote: > > On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote: > > Hi, > > > > > My take on this (for a decoder) would be to allocate memory for output > > > buffers from a secure ION heap, import in the v4l2 driver, and then to > > > provide those to the device using virtio. The device side then uses the > > > dmabuf framework to make the buffers accessible for the hardware. I'm not > > > sure about that, it's just an idea. > > > > Virtualization aside, how does the complete video decoding workflow > > work? I assume along the lines of ... > > > > (1) allocate buffer for decoded video frames (from ion). > > (2) export those buffers as dma-buf. > > (3) import dma-buf to video decoder. > > (4) import dma-buf to gpu. > > > > ... to establish buffers shared between video decoder and gpu? > > > > Then feed the video stream into the decoder, which decodes into the ion > > buffers? Ask the gpu to scanout the ion buffers to show the video? > > > > cheers, > > Gerd > > Yes, exactly. > > [decoder] > 1) Input buffers are allocated using VIDIOC_*BUFS. Ok. > 2) Output buffers are allocated in a guest specific manner (ION, gbm). Who decides whenever ION or gbm is used? The phrase "secure ION heap" used above sounds like using ION is required for decoding drm-protected content. So, do we have to worry about ION here? Or can we just use gbm? [ Note: don't know much about ion, other than that it is used by android, is in staging right now and patches to move it out of staging are floating around @ dri-devel ] > 3) Both input and output buffers are exported as dma-bufs. > 4) The backing storage of both inputs and outputs is made available to the > device. > 5) Decoder hardware writes to output buffers directly. As expected. > 6) Back to the guest side, the output dma-bufs are used by (virtio-) gpu. Ok. So, virtio-gpu has support for dma-buf exports (in drm-misc-next, should land upstream in kernel 5.5). dma-buf imports are not that simple unfortunately. When using the gbm allocation route dma-buf exports are good enough though. The virtio-gpu resources have both a host buffer and a guest buffer[1] Data can be copied using the DRM_IOCTL_VIRTGPU_TRANSFER_{FROM,TO}_HOST ioctls. The dma-buf export will export the guest buffer (which lives in guest ram). It would make sense for the decoded video to go directly to the host buffer though. First because we want avoid copying the video frames for performance reasons, and second because we might not be able to copy video frames (drm ...). This is where the buffer registry idea comes in. Attach a (host) identifier to (guest) dma-bufs, which then allows host device emulation share buffers, i.e. virtio-vdec device emulation could decode to a dma-buf it got from virtio-gpu device emulation. Alternatively we could use virtual ION (or whatever it becomes after de-staging) for buffer management, with both virtio-vdec and virtio-gpu importing dma-bufs from virtual ION on both guest and host side. cheers, Gerd [1] support for shared buffers is in progress.
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
Hi, > My take on this (for a decoder) would be to allocate memory for output > buffers > from a secure ION heap, import in the v4l2 driver, and then to provide those > to the device using virtio. The device side then uses the dmabuf framework to > make the buffers accessible for the hardware. I'm not sure about that, it's > just an idea. Virtualization aside, how does the complete video decoding workflow work? I assume along the lines of ... (1) allocate buffer for decoded video frames (from ion). (2) export those buffers as dma-buf. (3) import dma-buf to video decoder. (4) import dma-buf to gpu. ... to establish buffers shared between video decoder and gpu? Then feed the video stream into the decoder, which decodes into the ion buffers? Ask the gpu to scanout the ion buffers to show the video? cheers, Gerd
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
> > Well. I think before even discussing the protocol details we need a > > reasonable plan for buffer handling. I think using virtio-gpu buffers > > should be an optional optimization and not a requirement. Also the > > motivation for that should be clear (Let the host decoder write directly > > to virtio-gpu resources, to display video without copying around the > > decoded framebuffers from one device to another). > > Just to make sure we're on the same page, what would the buffers come > from if we don't use this optimization? > > I can imagine a setup like this; > 1) host device allocates host memory appropriate for usage with host > video decoder, > 2) guest driver allocates arbitrary guest pages for storage > accessible to the guest software, > 3) guest userspace writes input for the decoder to guest pages, > 4) guest driver passes the list of pages for the input and output > buffers to the host device > 5) host device copies data from input guest pages to host buffer > 6) host device runs the decoding > 7) host device copies decoded frame to output guest pages > 8) guest userspace can access decoded frame from those pages; back to 3 > > Is that something you have in mind? I don't have any specific workflow in mind. If you want display the decoded video frames you want use dma-bufs shared by video decoder and gpu, right? So the userspace application (video player probably) would create the buffers using one of the drivers, export them as dma-buf, then import them into the other driver. Just like you would do on physical hardware. So, when using virtio-gpu buffers: (1) guest app creates buffers using virtio-gpu. (2) guest app exports virtio-gpu buffers buffers as dma-buf. (3) guest app imports the dma-bufs into virtio-vdec. (4) guest app asks the virtio-vdec driver to write the decoded frames into the dma-bufs. (5) guest app asks the virtio-gpu driver to display the decoded frame. The guest video decoder driver passes the dma-buf pages to the host, and it is the host driver's job to fill the buffer. How this is done exactly might depend on hardware capabilities (whenever a host-allocated bounce buffer is needed or whenever the hardware can decode directly to the dma-buf passed by the guest driver) and is an implementation detail. Now, with cross-device sharing added the virtio-gpu would attach some kind of identifier to the dma-buf, virtio-vdec could fetch the identifier and pass it to the host too, and the host virtio-vdec device can use the identifier to get a host dma-buf handle for the (virtio-gpu) buffer. Ask the host video decoder driver to import the host dma-buf. If it all worked fine it can ask the host hardware to decode directly to the host virtio-gpu resource. > > Referencing virtio-gpu buffers needs a better plan than just re-using > > virtio-gpu resource handles. The handles are device-specific. What if > > there are multiple virtio-gpu devices present in the guest? > > > > I think we need a framework for cross-device buffer sharing. One > > possible option would be to have some kind of buffer registry, where > > buffers can be registered for cross-device sharing and get a unique > > id (a uuid maybe?). Drivers would typically register buffers on > > dma-buf export. > > This approach could possibly let us handle this transparently to > importers, which would work for guest kernel subsystems that rely on > the ability to handle buffers like native memory (e.g. having a > sgtable or DMA address) for them. > > How about allocating guest physical addresses for memory corresponding > to those buffers? On the virtio-gpu example, that could work like > this: > - by default a virtio-gpu buffer has only a resource handle, > - VIRTIO_GPU_RESOURCE_EXPORT command could be called to have the > virtio-gpu device export the buffer to a host framework (inside the > VMM) that would allocate guest page addresses for it, which the > command would return in a response to the guest, Hmm, the cross-device buffer sharing framework I have in mind would basically be a buffer registry. virtio-gpu would create buffers as usual, create a identifier somehow (details to be hashed out), attach the identifier to the dma-buf so it can be used as outlined above. Also note that the guest manages the address space, so the host can't simply allocate guest page addresses. Mapping host virtio-gpu resources into guest address space is planned, it'll most likely use a pci memory bar to reserve some address space. The host can map resources into that pci bar, on guest request. > - virtio-gpu driver could then create a regular DMA-buf object for > such memory, because it's just backed by pages (even though they may > not be accessible to the guest; just like in the case of TrustZone > memory protection on bare metal systems), Hmm, well, pci memory bars are *not* backed by pages. Maybe we can use Documentation/driver-api/pci/p2pdma.rst though. With that we might be
Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
Hi, > Our prototype implementation uses [4], which allows the virtio-vdec > device to use buffers allocated by virtio-gpu device. > [4] https://lkml.org/lkml/2019/9/12/157 Well. I think before even discussing the protocol details we need a reasonable plan for buffer handling. I think using virtio-gpu buffers should be an optional optimization and not a requirement. Also the motivation for that should be clear (Let the host decoder write directly to virtio-gpu resources, to display video without copying around the decoded framebuffers from one device to another). Referencing virtio-gpu buffers needs a better plan than just re-using virtio-gpu resource handles. The handles are device-specific. What if there are multiple virtio-gpu devices present in the guest? I think we need a framework for cross-device buffer sharing. One possible option would be to have some kind of buffer registry, where buffers can be registered for cross-device sharing and get a unique id (a uuid maybe?). Drivers would typically register buffers on dma-buf export. Another option would be to pass around both buffer handle and buffer owner, i.e. instead of "u32 handle" have something like this: struct buffer_reference { enum device_type; /* pci, virtio-mmio, ... */ union device_address { struct pci_address pci_addr; u64 virtio_mmio_addr; [ ... ] }; u64 device_buffer_handle; /* device-specific, virtio-gpu could use resource ids here */ }; cheers, Gerd
Re: [PATCH] udmabuf: set read/write flag when exporting
On Thu, Nov 15, 2018 at 05:46:30PM -0800, Gurchetan Singh wrote: > Reviewed-by: Gurchetan Singh > Tested-by: Gurchetan Singh Thanks. Pushed to drm-misc-fixes. cheers, Gerd
[PATCH] udmabuf: set read/write flag when exporting
Otherwise, mmap fails when done with PROT_WRITE. Suggested-by: Gurchetan Singh Signed-off-by: Gerd Hoffmann --- drivers/dma-buf/udmabuf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index e70328ab7e..d9ff246093 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -189,6 +189,7 @@ static long udmabuf_create(const struct udmabuf_create_list *head, exp_info.ops = &udmabuf_ops; exp_info.size = ubuf->pagecount << PAGE_SHIFT; exp_info.priv = ubuf; + exp_info.flags = O_RDWR; buf = dma_buf_export(&exp_info); if (IS_ERR(buf)) { -- 2.9.3
[PATCH v3] Add udmabuf misc device
A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some day to wayland server for seamless guest window display. Note: Initial revision which supports a single region only so it can't handle virtio-gpu ressources yet. qemu test branch: https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf Cc: David Airlie Cc: Tomeu Vizoso Cc: Daniel Vetter Signed-off-by: Gerd Hoffmann --- include/uapi/linux/udmabuf.h | 19 ++ drivers/dma-buf/udmabuf.c | 240 ++ tools/testing/selftests/drivers/dma-buf/udmabuf.c | 95 + drivers/dma-buf/Kconfig | 7 + drivers/dma-buf/Makefile | 1 + tools/testing/selftests/drivers/dma-buf/Makefile | 5 + 6 files changed, 367 insertions(+) create mode 100644 include/uapi/linux/udmabuf.h create mode 100644 drivers/dma-buf/udmabuf.c create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h new file mode 100644 index 00..2fbe69cf05 --- /dev/null +++ b/include/uapi/linux/udmabuf.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_LINUX_UDMABUF_H +#define _UAPI_LINUX_UDMABUF_H + +#include +#include + +#define UDMABUF_FLAGS_CLOEXEC 0x01 + +struct udmabuf_create { + __u32 memfd; + __u32 flags; + __u64 offset; + __u64 size; +}; + +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create) + +#endif /* _UAPI_LINUX_UDMABUF_H */ diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c new file mode 100644 index 00..f9600dc985 --- /dev/null +++ b/drivers/dma-buf/udmabuf.c @@ -0,0 +1,240 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +struct udmabuf { + struct file *filp; + u32 pagecount; + struct page **pages; +}; + +static int udmabuf_vm_fault(struct vm_fault *vmf) +{ + struct vm_area_struct *vma = vmf->vma; + struct udmabuf *ubuf = vma->vm_private_data; + + if (WARN_ON(vmf->pgoff >= ubuf->pagecount)) + return VM_FAULT_SIGBUS; + + vmf->page = ubuf->pages[vmf->pgoff]; + get_page(vmf->page); + return 0; +} + +static const struct vm_operations_struct udmabuf_vm_ops = { + .fault = udmabuf_vm_fault, +}; + +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) +{ + struct udmabuf *ubuf = buf->priv; + + if ((vma->vm_flags & VM_SHARED) == 0) + return -EINVAL; + + vma->vm_ops = &udmabuf_vm_ops; + vma->vm_private_data = ubuf; + return 0; +} + +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at, + enum dma_data_direction direction) +{ + struct udmabuf *ubuf = at->dmabuf->priv; + struct sg_table *sg; + + sg = kzalloc(sizeof(*sg), GFP_KERNEL); + if (!sg) + goto err1; + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, + 0, ubuf->pagecount << PAGE_SHIFT, + GFP_KERNEL) < 0) + goto err2; + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction)) + goto err3; + + return sg; + +err3: + sg_free_table(sg); +err2: + kfree(sg); +err1: + return ERR_PTR(-ENOMEM); +} + +static void unmap_udmabuf(struct dma_buf_attachment *at, + struct sg_table *sg, + enum dma_data_direction direction) +{ + sg_free_table(sg); + kfree(sg); +} + +static void release_udmabuf(struct dma_buf *buf) +{ + struct udmabuf *ubuf = buf->priv; + pgoff_t pg; + + for (pg = 0; pg < ubuf->pagecount; pg++) + put_page(ubuf->pages[pg]); + fput(ubuf->filp); + kfree(ubuf->pages); + kfree(ubuf); +} + +static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long page_num) +{ + struct udmabuf *ubuf = buf->priv; + struct page *page = ubuf->pages[page_num]; + + return kmap_atomic(page); +} + +static void *kmap_udmabuf(struct dma_buf *buf, unsigned long page_num) +{ + struct udmabuf *ubuf = buf->priv; + struct page *page = ubuf->
Re: [RfC PATCH] Add udmabuf misc device
Hi, > Generally we try to cache mappings as much as possible. And wrt finding a > slot: Create a sufficiently sized BAR on the virgl device, just for that? Well. virtio has no concept of "bars" ... The most common virtio transport layer happens to be pci, which actually has bars. But we also have virtio-mmio (largely unused since arm got pci) and virtio-ccw (used on s390x). In any case it would be a layering violation. Figured meanwhile qemu got memfd support recently, i.e. it can be configured to back guest memory with memfd. Which makes the memfd route quite attractive. Guess I try switch udmabuf to require memfd storage as proof-of-concept. cheers, Gerd
Re: [RfC PATCH] Add udmabuf misc device
Hi, > > I fail to see any common ground for xen-zcopy and udmabuf ... > Does the above mean you can assume that xen-zcopy and udmabuf > can co-exist as two different solutions? Well, udmabuf route isn't fully clear yet, but yes. See also gvt (intel vgpu), where the hypervisor interface is abstracted away into a separate kernel modules even though most of the actual vgpu emulation code is common. > And what about hyper-dmabuf? No idea, didn't look at it in detail. Looks pretty complex from a distant view. Maybe because it tries to build a communication framework using dma-bufs instead of a simple dma-buf passing mechanism. Like xen-zcopy it seems to depend on the idea that the hypervisor manages all memory it is easy for guests to share pages with the help of the hypervisor. Which simply isn't the case on kvm. hyper-dmabuf and xen-zcopy could maybe share code, or hyper-dmabuf build on top of xen-zcopy. cheers, Gerd
Re: [RfC PATCH] Add udmabuf misc device
On Fri, Apr 06, 2018 at 10:52:21AM +0100, Daniel Stone wrote: > Hi Gerd, > > On 14 March 2018 at 08:03, Gerd Hoffmann wrote: > >> Either mlock account (because it's mlocked defacto), and get_user_pages > >> won't do that for you. > >> > >> Or you write the full-blown userptr implementation, including mmu_notifier > >> support (see i915 or amdgpu), but that also requires Christian Königs > >> latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr > >> buffers is a no-go). > > > > I guess I'll look at mlock accounting for starters then. Easier for > > now, and leaves the door open to switch to userptr later as this should > > be transparent to userspace. > > Out of interest, do you have usecases for full userptr support? Maybe > another way would be to allow creation of dmabufs from memfds. I have two things in mind. One is vga emulation. I have virtual pci memory bar for the virtual vga. qemu backs vga memory with anonymous pages right now, switching that to shmem should be easy though if that makes things easier. Guest places the framebuffer somewhere in the pci bar, and I want export the chunk which represents the framebuffer as dma-buf to display it on the host without copying around data. Framebuffer is linear in guest physical memory, so a single block only. That is the simpler case. The more difficuilt one is virtio-gpu ressources. virtio-gpu resources live in host memory (guest has no direct access). The guest can optionally specify guest memory pages as backing storage for the resource. Guest backing storage is allowed to be scattered. Commands exist to copy both ways between host storage and guest backing. With virgl (opengl acceleration) enabled the guest will send rendering commands to fill the framebuffer ressource, so there is no need to copy content to the framebuffer ressource. The guest may fill other resources such as textures used for rendering with copy commands. Without acceleration the guest does software-rendering to the backing storage, then sends a command to copy the framebuffer content from guest backing storage to host ressource. Now it would be useful to allow a shared mapping, so no copying between guest backing storage and host resource is needed, especially for the software rendering case (i.e. dumb gem buffers). Being able to export guest dumb buffers to other host processes would be useful too, for example to display guest windows seamlessly on the host wayland server. So getting a dma-buf for the guest backing storage via udmabuf looked like a useful approach. We can export the guest gem buffers to other host processes that way. qemu itself could map it too, to get a linear representation of the scattered guest backing storage. The other obvious approach would be to do it the other way around and allow the guest map the host resource somehow. On the host side qemu could use vgem to allocate resource memory, so it'll be a gem object already. Mapping that into the guest isn't that straight-forward though. The guest manages its physical address space, so the guest would need to find a free spot and ask the host to place the resource there. Then the guest needs page structs covering the mapped resource, so it can work with it. Didn't investigate how difficuilt that is. Use memory hotplug maybe? Can we easily unmap the resource then? Also I think updating the guests physical memory layout (which we would need to do on every resource map/unmap) isn't an exactly cheap operation ... cheers, Gerd
Re: [PATCH v2] Add udmabuf misc device
Hi, > The pages backing a DMA-buf are not allowed to move (at least not without a > patch set I'm currently working on), but for certain MM operations to work > correctly you must be able to modify the page tables entries and move the > pages backing them around. > > For example try to use fork() with some copy on write pages with this > approach. You will find that you have only two options to correctly handle > this. The fork() issue should go away with shared memory pages (no cow). I guess this is the reason why vgem is internally backed by shmem. Hmm. So I could try to limit the udmabuf driver to shmem too (i.e. have the ioctl take a shmem filehandle and offset instead of a virtual address). But maybe it is better then to just extend vgem, i.e. add support to create gem objects from existing shmem. Comments? cheers, Gerd
Re: [RfC PATCH] Add udmabuf misc device
Hi, > > * The general interface should be able to express sharing from any > > guest:guest, not just guest:host. Arbitrary G:G sharing might be > > something some hypervisors simply aren't able to support, but the > > userspace API itself shouldn't make assumptions or restrict that. I > > think ideally the sharing API would include some kind of > > query_targets interface that would return a list of VM's that your > > current OS is allowed to share with; that list would be depend on the > > policy established by the system integrator, but obviously wouldn't > > include targets that the hypervisor itself wouldn't be capable of > > handling. > Can you give a use-case for this? I mean that the system integrator > is the one who defines which guests/hosts talk to each other, > but querying means that it is possible that VMs have some sort > of discovery mechanism, so they can decide on their own whom > to connect to. Note that vsock (created by vmware, these days also has a virtio transport for kvm) started with support for both guest <=> host and guest <=> guest support. But later on guest <=> guest was dropped. As far I know the reasons where (a) lack of use cases and (b) security. So, I likewise would know more details on the use cases you have in mind here. Unless we have a compelling use case here I'd suggest to drop the guest <=> guest requirement as it makes the whole thing alot more complex. > > * The sharing API could be used to share multiple kinds of content in a > > single system. The sharing sink driver running in the content > > producer's VM should accept some additional metadata that will be > > passed over to the target VM as well. Not sure this should be part of hyper-dmabuf. A dma-buf is nothing but a block of data, period. Therefore protocols with dma-buf support (wayland for example) typically already send over metadata describing the content, so duplicating that in hyper-dmabuf looks pointless. > 1. We are targeting ARM and one of the major requirements for the buffer > sharing is the ability to allocate physically contiguous buffers, which gets > even more complicated for systems not backed with an IOMMU. So, for some > use-cases it is enough to make the buffers contiguous in terms of IPA and > sometimes those need to be contiguous in terms of PA. Which pretty much implies the host must to the allocation. > 2. For Xen we would love to see UAPI to create a dma-buf from grant > references provided, so we can use this generic solution to implement > zero-copying without breaking the existing Xen protocols. This can > probably be extended to other hypervizors as well. I'm not sure we can create something which works on both kvm and xen. The memory management model is quite different ... On xen the hypervisor manages all memory. Guests can allow other guests to access specific pages (using grant tables). In theory any guest <=> guest communication is possible. In practice is mostly guest <=> dom0 because guests access their virtual hardware that way. dom0 is the priviledged guest which owns any hardware not managed by xen itself. Xen guests can ask the hypervisor to update the mapping of guest physical pages. They can ballon down (unmap and free pages). They can ballon up (ask the hypervisor to map fresh pages). They can map pages exported by other guests using grant tables. xen-zcopy makes heavy use of this. It balloons down, to make room in the guest physical address space, then goes map the exported pages there, finally composes a dma-buf. On kvm qemu manages all guest memory. qemu also has all guest memory mapped, so a grant-table like mechanism isn't needed to implement virtual devices. qemu can decide how it backs memory for the guest. qemu propagates the guest memory map to the kvm driver in the linux kernel. kvm guests have some control over the guest memory map, for example they can map pci bars wherever they want in their guest physical address space by programming the base registers accordingly, but unlike xen guests they can't ask the host to remap individual pages. Due to qemu having all guest memory mapped virtual devices are typically designed to have the guest allocate resources, then notify the host where they are located. This is where the udmabuf idea comes from: Guest tells the host (qemu) where the gem object is, and qemu then can create a dmabuf backed by those pages to pass it on to other processes such as the wayland display server. Possibly even without the guest explicitly asking for it, i.e. export the framebuffer placed by the guest in the (virtual) vga pci memory bar as dma-buf. And I can imagine that this is useful outsize virtualization too. I fail to see any common ground for xen-zcopy and udmabuf ... Beside that there is the problem that the udmabuf idea has its own share of issues, for example the fork() issue pointed out by Christian König[1]. So I still need to f
[PATCH v2] Add udmabuf misc device
A driver to let userspace turn iovecs into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some day to wayland server for seamless guest window display. Those dma-bufs are accounted against user's shm mlock bucket as the pages are effectively locked in memory. Cc: David Airlie Cc: Tomeu Vizoso Cc: Daniel Vetter Signed-off-by: Gerd Hoffmann --- include/uapi/linux/udmabuf.h | 23 ++ drivers/dma-buf/udmabuf.c | 261 ++ tools/testing/selftests/drivers/dma-buf/udmabuf.c | 69 ++ drivers/dma-buf/Kconfig | 7 + drivers/dma-buf/Makefile | 1 + tools/testing/selftests/drivers/dma-buf/Makefile | 5 + 6 files changed, 366 insertions(+) create mode 100644 include/uapi/linux/udmabuf.h create mode 100644 drivers/dma-buf/udmabuf.c create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h new file mode 100644 index 00..54ceba203a --- /dev/null +++ b/include/uapi/linux/udmabuf.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_LINUX_UDMABUF_H +#define _UAPI_LINUX_UDMABUF_H + +#include +#include + +struct udmabuf_iovec { + __u64 base; + __u64 len; +}; + +#define UDMABUF_FLAGS_CLOEXEC 0x01 + +struct udmabuf_create { + __u32 flags; + __u32 niov; + struct udmabuf_iovec iovs[]; +}; + +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create) + +#endif /* _UAPI_LINUX_UDMABUF_H */ diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c new file mode 100644 index 00..664ab4ee4e --- /dev/null +++ b/drivers/dma-buf/udmabuf.c @@ -0,0 +1,261 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +struct udmabuf { + u32 pagecount; + struct page **pages; + struct user_struct *owner; +}; + +static int udmabuf_vm_fault(struct vm_fault *vmf) +{ + struct vm_area_struct *vma = vmf->vma; + struct udmabuf *ubuf = vma->vm_private_data; + + if (WARN_ON(vmf->pgoff >= ubuf->pagecount)) + return VM_FAULT_SIGBUS; + + vmf->page = ubuf->pages[vmf->pgoff]; + get_page(vmf->page); + return 0; +} + +static const struct vm_operations_struct udmabuf_vm_ops = { + .fault = udmabuf_vm_fault, +}; + +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) +{ + struct udmabuf *ubuf = buf->priv; + + if ((vma->vm_flags & VM_SHARED) == 0) + return -EINVAL; + + vma->vm_ops = &udmabuf_vm_ops; + vma->vm_private_data = ubuf; + return 0; +} + +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at, + enum dma_data_direction direction) +{ + struct udmabuf *ubuf = at->dmabuf->priv; + struct sg_table *sg; + + sg = kzalloc(sizeof(*sg), GFP_KERNEL); + if (!sg) + goto err1; + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, + 0, ubuf->pagecount << PAGE_SHIFT, + GFP_KERNEL) < 0) + goto err2; + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction)) + goto err3; + + return sg; + +err3: + sg_free_table(sg); +err2: + kfree(sg); +err1: + return ERR_PTR(-ENOMEM); +} + +static void unmap_udmabuf(struct dma_buf_attachment *at, + struct sg_table *sg, + enum dma_data_direction direction) +{ + sg_free_table(sg); + kfree(sg); +} + +static void release_udmabuf(struct dma_buf *buf) +{ + struct udmabuf *ubuf = buf->priv; + pgoff_t pg; + + for (pg = 0; pg < ubuf->pagecount; pg++) + put_page(ubuf->pages[pg]); + user_shm_unlock(ubuf->pagecount << PAGE_SHIFT, ubuf->owner); + free_uid(ubuf->owner); + kfree(ubuf->pages); + kfree(ubuf); +} + +static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long page_num) +{ + struct udmabuf *ubuf = buf->priv; + struct page *page = ubuf->pages[page_num]; + + return kmap_atomic(page); +} + +static void *kmap_udmabuf(struct dma_buf *buf, unsigned long page_num) +{ + struct udmab
Re: [RfC PATCH] Add udmabuf misc device
Hi, > Either mlock account (because it's mlocked defacto), and get_user_pages > won't do that for you. > > Or you write the full-blown userptr implementation, including mmu_notifier > support (see i915 or amdgpu), but that also requires Christian Königs > latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr > buffers is a no-go). I guess I'll look at mlock accounting for starters then. Easier for now, and leaves the door open to switch to userptr later as this should be transparent to userspace. > > Known issue: Driver API isn't complete yet. Need add some flags, for > > example to support read-only buffers. > > dma-buf has no concept of read-only. I don't think we can even enforce > that (not many iommus can enforce this iirc), so pretty much need to > require r/w memory. Ah, ok. Just saw the 'write' arg for get_user_pages_fast and figured we might support that, but if iommus can't handle that anyway it's pointless indeed. > > Cc: David Airlie > > Cc: Tomeu Vizoso > > Signed-off-by: Gerd Hoffmann > > btw there's also the hyperdmabuf stuff from the xen folks, but imo their > solution of forwarding the entire dma-buf api is over the top. This here > looks _much_ better, pls cc all the hyperdmabuf people on your next > version. Fun fact: googling for "hyperdmabuf" found me your mail and nothing else :-o (Trying "hyper dmabuf" instead worked better then). Yes, will cc them on the next version. Not sure it'll help much on xen though due to the memory management being very different. Basically xen owns the memory, not the kernel of the control domain (dom0), so creating dmabufs for guest memory chunks isn't that simple ... Also it's not clear whenever they really need guest -> guest exports or guest -> dom0 exports. > Overall I like the idea, but too lazy to review. Cool. General comments on the idea was all I was looking for for the moment. Spare yor review cycles for the next version ;) > Oh, some kselftests for this stuff would be lovely. I'll look into it. thanks, Gerd
[RfC PATCH] Add udmabuf misc device
A driver to let userspace turn iovecs into dma-bufs. Use case: Allows qemu pass around dmabufs for the guest framebuffer. https://www.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf has an experimental patch. Also allows qemu to export guest virtio-gpu resources as host dmabufs. Should be possible to use it to display guest wayland windows on the host display server. virtio-gpu ressources can be chunked so we will actually need multiple iovec entries. UNTESTED. Want collect some feedback on the general approach with this RfC series. Can this work? If not, better ideas? Question: Must this be hooked into some kind of mlock accounting, to limit the amout of memory userspace is allowed to pin this way? Or will get_user_pages_fast() handle that for me? Known issue: Driver API isn't complete yet. Need add some flags, for example to support read-only buffers. Cc: David Airlie Cc: Tomeu Vizoso Signed-off-by: Gerd Hoffmann --- include/uapi/linux/udmabuf.h | 21 drivers/dma-buf/udmabuf.c| 250 +++ drivers/dma-buf/Kconfig | 7 ++ drivers/dma-buf/Makefile | 1 + 4 files changed, 279 insertions(+) create mode 100644 include/uapi/linux/udmabuf.h create mode 100644 drivers/dma-buf/udmabuf.c diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h new file mode 100644 index 00..fd2fa441fe --- /dev/null +++ b/include/uapi/linux/udmabuf.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_LINUX_UDMABUF_H +#define _UAPI_LINUX_UDMABUF_H + +#include +#include + +struct udmabuf_iovec { + __u64 base; + __u64 len; +}; + +struct udmabuf_create { + __u32 flags; + __u32 niov; + struct udmabuf_iovec iovs[]; +}; + +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create) + +#endif /* _UAPI_LINUX_UDMABUF_H */ diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c new file mode 100644 index 00..ec012d7ac7 --- /dev/null +++ b/drivers/dma-buf/udmabuf.c @@ -0,0 +1,250 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +struct udmabuf { + u32 pagecount; + struct page **pages; +}; + +static int udmabuf_vm_fault(struct vm_fault *vmf) +{ + struct vm_area_struct *vma = vmf->vma; + struct udmabuf *ubuf = vma->vm_private_data; + + if (WARN_ON(vmf->pgoff >= ubuf->pagecount)) + return VM_FAULT_SIGBUS; + + vmf->page = ubuf->pages[vmf->pgoff]; + get_page(vmf->page); + return 0; +} + +static const struct vm_operations_struct udmabuf_vm_ops = { + .fault = udmabuf_vm_fault, +}; + +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) +{ + struct udmabuf *ubuf = buf->priv; + + if ((vma->vm_flags & VM_SHARED) == 0) + return -EINVAL; + + vma->vm_ops = &udmabuf_vm_ops; + vma->vm_private_data = ubuf; + return 0; +} + +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at, + enum dma_data_direction direction) +{ + struct udmabuf *ubuf = at->dmabuf->priv; + struct sg_table *sg; + + sg = kzalloc(sizeof(*sg), GFP_KERNEL); + if (!sg) + goto err1; + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, + 0, ubuf->pagecount << PAGE_SHIFT, + GFP_KERNEL) < 0) + goto err2; + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction)) + goto err3; + + return sg; + +err3: + sg_free_table(sg); +err2: + kfree(sg); +err1: + return ERR_PTR(-ENOMEM); +} + +static void unmap_udmabuf(struct dma_buf_attachment *at, + struct sg_table *sg, + enum dma_data_direction direction) +{ + sg_free_table(sg); + kfree(sg); +} + +static void release_udmabuf(struct dma_buf *buf) +{ + struct udmabuf *ubuf = buf->priv; + pgoff_t pg; + + for (pg = 0; pg < ubuf->pagecount; pg++) + put_page(ubuf->pages[pg]); + kfree(ubuf->pages); + kfree(ubuf); +} + +static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long offset) +{ + struct udmabuf *ubuf = buf->priv; + struct page *page = ubuf->pages[offset >> PAGE_SHIFT]; + + return kmap_atomic(page); +} + +static void *kmap_udmabuf(struct dma_buf *buf, unsigned long offset) +{ + struct udmabuf *ubuf = buf->priv; + struct page *page = ubuf->pages[offset >> PAGE_SHIFT]; + + return
[PATCH v3 2/4] break kconfig dependency loop
After adding virtio-gpu I get this funky kconfig dependency loop. scripts/kconfig/conf --oldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by OMAP_REMOTEPROC drivers/remoteproc/Kconfig:12: symbol OMAP_REMOTEPROC depends on OMAP_IOMMU drivers/iommu/Kconfig:141: symbol OMAP_IOMMU is selected by VIDEO_OMAP3 drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2 drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the loop, which looks like the best way to handle it to me. Updated OMAP_IOMMU help text accordingly. Signed-off-by: Gerd Hoffmann Acked-by: Mauro Carvalho Chehab --- drivers/iommu/Kconfig | 3 +++ drivers/media/platform/Kconfig | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 1ae4e54..a5c8d5e 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -178,6 +178,9 @@ config OMAP_IOMMU depends on ARM && MMU depends on ARCH_OMAP2PLUS || COMPILE_TEST select IOMMU_API + ---help--- + The OMAP3 media platform drivers depend on iommu support, + if you need them say Y here. config OMAP_IOMMU_DEBUG bool "Export OMAP IOMMU internals in DebugFS" diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 421f531..19306f72 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -87,8 +87,8 @@ config VIDEO_OMAP3 tristate "OMAP 3 Camera support" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3 depends on HAS_DMA + depends on OMAP_IOMMU select ARM_DMA_USE_IOMMU - select OMAP_IOMMU select VIDEOBUF2_DMA_CONTIG select MFD_SYSCON ---help--- -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] break kconfig dependency loop
On Mi, 2015-04-01 at 22:55 +0800, John Hunter wrote: > Hi Gerd, > I've read the patches about the virtio-gpu, it's a nice design. > As far as I know, there are two other drivers used by qemu, CIRRUS and > BOCHS. > I have a question about the relationship of these three drivers, is > that the virtio-gpu > designed to replace the other two drivers? I mean are the CIRRUS and > BOCHS > going to be deprecated in the future? qemu has a bunch of different virtual graphics cards, and these are the drivers for them. cirrus used to be the default gfx card until recently (qemu older then version 2.2). stdvga (bochs driver) is the current default. So expect them to be around for a while. virtio-gpu will not replace them. > Actually, this is a problem by Martin Peres who is the GSoC xorg > administor. > My proposal is "Convert the BOCHS and CIRRUS drivers to atomic > mode-setting". Surely makes sense for bochs and you shouldn't find major blockers. Not sure this is a reasonable task size for gsoc given it took me only a few days to convert virtio-gpu to atomic modesetting. But maybe fine if you are new to drm kernel hacking and therefore the task includes learning alot new stuff. I have my doubts it'll work out for cirrus though, due to the small amount of video memory it has (and other limitations, because we mimic hardware from the 90ies here). Current code is already swapping framebuffers in and out of video ram because of that. So atomic modesetting, page flip, running wayland on that beast all is going to be problematic I expect. See also: https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ HTH, 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
[PATCH v2 1/4] break kconfig dependency loop
After adding virtio-gpu I get this funky kconfig dependency loop. scripts/kconfig/conf --oldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by OMAP_REMOTEPROC drivers/remoteproc/Kconfig:12: symbol OMAP_REMOTEPROC depends on OMAP_IOMMU drivers/iommu/Kconfig:141: symbol OMAP_IOMMU is selected by VIDEO_OMAP3 drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2 drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the loop, which looks like the best way to handle it to me. I'm open to better suggestions though. Signed-off-by: Gerd Hoffmann --- drivers/media/platform/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index d9b872b..fc21734 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -87,8 +87,8 @@ config VIDEO_OMAP3 tristate "OMAP 3 Camera support" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3 depends on HAS_DMA + depends on OMAP_IOMMU select ARM_DMA_USE_IOMMU - select OMAP_IOMMU select VIDEOBUF2_DMA_CONTIG ---help--- Driver for an OMAP 3 camera controller. -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
saa7134 irq status bits
Hi, Forwarding to linux-media mailing list, hoping that someone there can help out. I havn't worked in the code for years now, can't remember what the AR irq bit is and can't find my copy of the saa7134 data sheet too ... cheers, Gerd Original Message Subject: hello kraxel Date: Tue, 02 Apr 2013 15:48:42 +0800 From: zhaokai To: kra...@bytesex.org Dear Kraxel: My name is zhaokai, I am a soft developer working in beijing. This is my first mail to The Kernel Developer, I am very excited. Now I have a question about your code for saa7134 driver in linux kernel 2.6.21. We use Loongson CPU,I compile kernel and run the image,when I run my test app for saa7134 camera this message will print: saa7130[0]/irq: looping -- clearing all enable bits I study the saa7134 driver code,find the message come from the follow code: if (10 == loop) { print_irqstatus(dev,loop,report,status); if (report & SAA7134_IRQ_REPORT_PE) { /* disable all parity error */ printk(KERN_WARNING "%s/irq: looping -- " "clearing PE (parity error!) enable bit\n",dev->name); saa_clearl(SAA7134_IRQ2,SAA7134_IRQ2_INTE_PE); } else if (report & SAA7134_IRQ_REPORT_GPIO16) { /* disable gpio16 IRQ */ printk(KERN_WARNING "%s/irq: looping -- " "clearing GPIO16 enable bit\n",dev->name); saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO16); } else if (report & SAA7134_IRQ_REPORT_GPIO18) { /* disable gpio18 IRQs */ printk(KERN_WARNING "%s/irq: looping -- " "clearing GPIO18 enable bit\n",dev->name); saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18); } else { /* disable all irqs */ printk(KERN_WARNING "%s/irq: looping -- " "clearing all enable bits\n",dev->name); saa_writel(SAA7134_IRQ1,0); saa_writel(SAA7134_IRQ2,0); } } this is in the interrupt handle function,I add some print and find the value of SAA7134_IRQ_REPORT register is 0x11 or 0x10, normally it would be 0x1 or 0x0, 0x1x means SAA7134_IRQ_REPORT_AR, So what is the meaning of SAA7134_IRQ_REPORT_AR ? Best regards, ZhaoKai -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: bttv kernel patch
Original Message Subject: bttv kernel patch Date: Thu, 19 Jul 2012 04:57:59 -0600 From: Tony Gentile To: kra...@bytesex.org Hello Gerd, Attached is a patch to add the Aposonic W-DVR card to the bttv driver. This card is a basic 4 composite + 1 audio in. (I have no way to check the audio on the card as that connector has been removed from my board.) This is my first submission. I hope it is helpful. Thank you for your time. Sincerely, Tony Gentile diff -uNr linux-3.4.5/Documentation/video4linux/CARDLIST.bttv linux-3.4.5-modded/Documentation/video4linux/CARDLIST.bttv --- linux-3.4.5/Documentation/video4linux/CARDLIST.bttv 2012-07-16 12:20:09.0 -0600 +++ linux-3.4.5-modded/Documentation/video4linux/CARDLIST.bttv 2012-07-19 05:04:38.0 -0600 @@ -159,3 +159,4 @@ 158 -> Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d] 159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540] 160 -> Tongwei Video Technology TD-3116[f200:3116] +161 -> Aposonic W-DVR [0279:0228] diff -uNr linux-3.4.5/drivers/media/video/bt8xx/bttv-cards.c linux-3.4.5-modded/drivers/media/video/bt8xx/bttv-cards.c --- linux-3.4.5/drivers/media/video/bt8xx/bttv-cards.c 2012-07-16 12:20:09.0 -0600 +++ linux-3.4.5-modded/drivers/media/video/bt8xx/bttv-cards.c 2012-07-19 04:48:52.0 -0600 @@ -345,7 +345,7 @@ { 0x15401836, BTTV_BOARD_PV183, "Provideo PV183-7" }, { 0x15401837, BTTV_BOARD_PV183, "Provideo PV183-8" }, { 0x3116f200, BTTV_BOARD_TVT_TD3116, "Tongwei Video Technology TD-3116" }, - + { 0x02280279, BTTV_BOARD_APOSONIC_WDVR, "Aposonic W-DVR" }, { 0, -1, NULL } }; @@ -2893,6 +2893,14 @@ .pll = PLL_28, .tuner_type = TUNER_ABSENT, }, + [BTTV_BOARD_APOSONIC_WDVR] = { + .name = "Aposonic W-DVR", + .video_inputs = 4, + .svhs = NO_SVHS, + .muxsel = MUXSEL(2, 3, 1, 0), + .tuner_type = TUNER_ABSENT, + }, + }; static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards); diff -uNr linux-3.4.5/drivers/media/video/bt8xx/bttv.h linux-3.4.5-modded/drivers/media/video/bt8xx/bttv.h --- linux-3.4.5/drivers/media/video/bt8xx/bttv.h 2012-07-16 12:20:09.0 -0600 +++ linux-3.4.5-modded/drivers/media/video/bt8xx/bttv.h 2012-07-19 04:48:52.0 -0600 @@ -184,7 +184,7 @@ #define BTTV_BOARD_GEOVISION_GV800S_SL 0x9e #define BTTV_BOARD_PV183 0x9f #define BTTV_BOARD_TVT_TD3116 0xa0 - +#define BTTV_BOARD_APOSONIC_WDVR 0xa1 /* more card-specific defines */ #define PT2254_L_CHANNEL 0x10
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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Hi, It depends. We do not have a clear way to see if new ioctls are supported (and I do not consider "try new ioctl and see if data sticks" being a good way) so that facilitated protocol version rev-up. Yea, EVIOCGKEYCODE_V2 on a old kernel returns EINVAL. Not good. There is another one which should have been used to signal "unknown ioctl", ENOTTY IIRC (a bit silly for historical reasons), so you can figure whenever your input data is invalid or whenever the ioctl isn't supported in the first place (in which case you could just fallback to the old version). So keymap manipulating tools might be forced to check protocol version. Guess that is the best way indeed. 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Hi, Will the major revision ever change? Does it make sense to check the version at all? As already established earlier in this thread, by Linus Torvalds as well as by myself, NO! Check removed. thanks, 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Hi, The check should be against concrete version (0x1 in this case). Stepping back: what does the version mean? 0x1 == 1.0 ? 0x10001 == 1.1 ? Can I expect the interface stay backward compatible if only the minor revision changes, i.e. makes it sense to accept 1.x? Will the major revision ever change? Does it make sense to check the version at all? thanks, 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Hi, Hmm, doesn't apply cleanly ... I suspect that Dmitry did the patch against the Debian package, based on a 2007 version of it, as it seems that Debian is using an older version of the package. Applied, thanks. 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: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Hi, Btw, I took some time to take analyse the input-kbd stuff. As said at the README: This is a small collection of input layer utilities. I wrote them mainly for testing and debugging, but maybe others find them useful too :-) ... Gerd Knorr [SUSE Labs] This is an old testing tool written by Gerd Hoffmann probably used for him to test the V4L early Remote Controller implementations. Indeed. The last "official" version seems to be this one: http://dl.bytesex.org/cvs-snapshots/input-20081014-101501.tar.gz Just moved the bits to git a few days ago. http://bigendian.kraxel.org/cgit/input/ Code is unchanged since 2008 though. Gerd, if you're still maintaining it, it is a good idea to apply Dmitry's patch: http://www.spinics.net/lists/linux-input/msg13728.html Hmm, doesn't apply cleanly ... 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: Hauppauge USB Live 2
On 12/14/10 18:23, Gerd Hoffmann wrote: $ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path Using that commit directly looks better. I still see the UsbInterface::sendCommand failures, but the driver seems to finish the initialization and looks for the firmware. So it seems something between -rc2 and -rc5 in mainline made it regress ... Uhm, no. Looks like the difference is actually the .config No, isn't. Running vanilla 2.6.37-rc5 now, seeing both success and failure with the very same kernel. The driver is compiled statically into the kernel now. Booting with the device plugged works, it seems to initialize the device largely sucessfully, although some errors are sprinkled in. The firmware one is probably just a matter of making sure the firmware is in the initramfs, didn't look at that yet. Trying to fix the firmware issue by just unplugging and re-plugging the device once the system is fully up'n'running (and thus /lib/firmware available) results in a failure which looks pretty much like the original report. Any idea? Initialization order issue? Timing issue? cheers, Gerd PS: attached log was created using "dmesg | egrep '(cx|usb 1-2)'". [1.954715] cx231xx v4l2 driver loaded. [1.954741] usbcore: registered new interface driver cx231xx [2.171811] usb 1-2: new high speed USB device using ehci_hcd and address 2 [2.291875] usb 1-2: New USB device found, idVendor=2040, idProduct=c200 [2.293621] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [2.297065] usb 1-2: Product: Hauppauge Device [2.298805] usb 1-2: Manufacturer: Hauppauge [2.298807] usb 1-2: SerialNumber: 0013566174 [2.305647] cx231xx #0: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 5 interfaces [2.307548] cx231xx #0: registering interface 1 [2.309498] cx231xx #0: can't change interface 3 alt no. to 3: Max. Pkt size = 0 [2.311374] cx231xx #0: can't change interface 4 alt no. to 1: Max. Pkt size = 0 [2.313248] cx231xx #0: Identified as Hauppauge USB Live 2 (card=9) [2.337247] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [2.339250] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [2.342754] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [2.373011] cx231xx #0: cx231xx_dif_set_standard: setStandard to [2.382006] cx231xx #0: Changing the i2c master port to 3 [2.386252] cx25840 15-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0) [2.412085] cx25840 15-0044: Firmware download size changed to 16 bytes max length [2.415597] cx25840 15-0044: unable to open firmware v4l-cx231xx-avcore-01.fw [2.448841] cx231xx #0: cx231xx #0: v4l2 driver version 0.0.1 [2.468502] cx231xx #0: cx231xx_dif_set_standard: setStandard to [2.516996] cx231xx #0: video_mux : 0 [2.518927] cx231xx #0: do_mode_ctrl_overrides : 0xb000 [2.521745] cx231xx #0: do_mode_ctrl_overrides NTSC [2.530728] cx231xx #0: cx231xx #0/0: registered device video0 [v4l2] [2.532972] cx231xx #0: cx231xx #0/0: registered device vbi0 [2.534857] cx231xx #0: V4L2 device registered as video0 and vbi0 [2.537056] cx231xx #0: EndPoint Addr 0x84, Alternate settings: 5 [2.549992] cx231xx #0: Alternate setting 0, max size= 512 [2.552147] cx231xx #0: Alternate setting 1, max size= 184 [2.554244] cx231xx #0: Alternate setting 2, max size= 728 [2.556181] cx231xx #0: Alternate setting 3, max size= 2892 [2.558023] cx231xx #0: Alternate setting 4, max size= 1800 [2.559827] cx231xx #0: EndPoint Addr 0x85, Alternate settings: 2 [2.583025] cx231xx #0: Alternate setting 0, max size= 512 [2.584811] cx231xx #0: Alternate setting 1, max size= 512 [2.586602] cx231xx #0: EndPoint Addr 0x86, Alternate settings: 2 [2.598406] cx231xx #0: Alternate setting 0, max size= 512 [2.600058] cx231xx #0: Alternate setting 1, max size= 576 [ 13.304543] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 13.314640] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) [ 29.289535] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 29.299602] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) [ 180.241409] usb 1-2: USB disconnect, address 2 [ 184.261061] usb 1-2: new high speed USB device using ehci_hcd and address 6 [ 184.377920] usb 1-2: New USB device found, idVendor=2040, idProduct=c200 [ 184.377928] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 184.377934] usb 1-2: Product: Hauppauge Device [ 184.377939] usb 1-2: Manufacturer: Hauppauge [ 184.377944] usb 1-2: SerialNumber: 0013566174 [ 184.381595] cx231xx #1: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 5 interfaces [ 184.381603] cx231xx #1: registering interface 1 [ 184.381784] cx231xx #
Re: Hauppauge USB Live 2
$ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path Using that commit directly looks better. I still see the UsbInterface::sendCommand failures, but the driver seems to finish the initialization and looks for the firmware. So it seems something between -rc2 and -rc5 in mainline made it regress ... Uhm, no. Looks like the difference is actually the .config The stripped-down kernel with the driver compiled in statically for a quick test works fine, whereas the fedora-derived configuration doesn't. /me continues burning cpu cycles with kernel builds ;) 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: Hauppauge USB Live 2
On 12/14/10 15:05, Mauro Carvalho Chehab wrote: Hi Devin, Em 14-12-2010 08:06, Devin Heitmueller escreveu: On Tue, Dec 14, 2010 at 4:57 AM, Gerd Hoffmann wrote: Hi folks, Got a "Hauppauge USB Live 2" after google found me that there is a linux driver for it. Unfortunaly linux doesn't manage to initialize the device. I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel with the linuxtv/staging/for_v2.6.38 branch merged in. Kernel log and lsusb output are attached. Ideas anyone? Looks like a regression got introduced since I submitted the original support for the device. Mauro? No idea what happened. The driver is working here with the devices I have. Unfortunately, I don't have any USB Live 2 here for testing. Based on the logs, maybe the driver is directing the I2C commands to the wrong bus. The better would be to bisect the kernel and see what patch broke it. The support for USB live2 were added on changeset 4270c3ca. There aren't many changes on it (45 changes), so, bisecting it shouldn't be hard: $ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path Using that commit directly looks better. I still see the UsbInterface::sendCommand failures, but the driver seems to finish the initialization and looks for the firmware. So it seems something between -rc2 and -rc5 in mainline made it regress ... 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
Hauppauge USB Live 2
Hi folks, Got a "Hauppauge USB Live 2" after google found me that there is a linux driver for it. Unfortunaly linux doesn't manage to initialize the device. I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel with the linuxtv/staging/for_v2.6.38 branch merged in. Kernel log and lsusb output are attached. Ideas anyone? cheers, Gerd [ 231.994065] usb 1-2: new high speed USB device using ehci_hcd and address 5 [ 232.110991] usb 1-2: New USB device found, idVendor=2040, idProduct=c200 [ 232.110998] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 232.111023] usb 1-2: Product: Hauppauge Device [ 232.111029] usb 1-2: Manufacturer: Hauppauge [ 232.111033] usb 1-2: SerialNumber: 0013566174 [ 232.465523] IR NEC protocol handler initialized [ 232.489573] Linux video capture interface: v2.00 [ 232.499834] IR RC5(x) protocol handler initialized [ 232.518668] IR RC6 protocol handler initialized [ 232.541743] IR JVC protocol handler initialized [ 232.579260] IR Sony protocol handler initialized [ 232.614172] lirc_dev: IR Remote Control driver registered, major 250 [ 232.643778] IR LIRC bridge handler initialized [ 232.656779] cx231xx v4l2 driver loaded. [ 232.656844] cx231xx #0: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 5 interfaces [ 232.656848] cx231xx #0: registering interface 1 [ 232.659017] cx231xx #0: can't change interface 3 alt no. to 3: Max. Pkt size = 0 [ 232.660130] cx231xx #0: can't change interface 4 alt no. to 1: Max. Pkt size = 0 [ 232.661252] cx231xx #0: Identified as Hauppauge USB Live 2 (card=9) [ 232.686363] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.686726] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.687166] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.687479] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.687853] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.688348] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.688727] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.688731] cx231xx #0: cx231xx_dev_init: cx231xx_afe init super block - errCode [-32]! [ 232.688845] cx231xx #0: cx231xx_init_dev: cx231xx_i2c_register - errCode [-32]! [ 232.688859] cx231xx: probe of 1-2:1.1 failed with error -32 [ 232.688915] usbcore: registered new interface driver cx231xx Bus 001 Device 005: ID 2040:c200 Hauppauge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x2040 Hauppauge idProduct 0xc200 bcdDevice 40.01 iManufacturer 1 Hauppauge iProduct2 Hauppauge Device iSerial 3 0013566174 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 248 bNumInterfaces 6 bConfigurationValue 1 iConfiguration 4 Hauppauge Device bmAttributes 0x80 (Bus Powered) MaxPower 340mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 32 Hauppauge Device Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0e EP 14 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 1 bInterfaceCount 5 bFunctionClass255 Vendor Specific Class bFunctionSubClass 255 Vendor Specific Subclass bFunctionProtocol 255 Vendor Specific Protocol iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On 12/03/09 05:29, Jarod Wilson wrote: On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote: Anyway, we shouldn't postpone lirc drivers addition due to that. There are still lots of work to do before we'll be able to split the tables from the kernel drivers. Indeed. The sysfs bits are future work for both lirc and evdev drivers. There is no reason to make the lirc merge wait for it. At this point, my plan is to try to finish cleaning up lirc_dev and lirc_mceusb at least over the weekend while at FUDCon up in Toronto, and resubmit them next week. Good plan IMHO. Having lirc_dev merged quickly allows in-kernel drivers start supporting lirc. One final pass over the lirc interface would be good, taking the chance to fixup anything before the ABI is set in stone with the mainline merge. Things to look at: (1) Make sure ioctl structs are 32/64 bit invariant. (2) Maybe add some reserved fields to allow extending later without breaking the ABI. (3) Someone suggested a 'commit' ioctl which would activate the parameters set in (multiple) previous ioctls. Makes sense? (4) Add a ioctl to enable/disable evdev event submission for evdev/lirc hybrid drivers. I'm still on the fence over what to do about lirc_imon. The driver supports essentially 3 generations of devices. First-gen is very old imon parts that don't do onboard decoding. Second-gen is the devices that all got (insanely stupidly) tagged with the exact same usb device ID (0x15c2:0xffdc), some of which have an attached VFD, some with an attached LCD, some with neither, some that are actually RF parts, but all (I think) of which do onboard decoding. Third-gen is the latest stuff, which is all pretty sane, unique device IDs for unique devices, onboard decoding, etc. Do have second-gen and third-gen devices have a 'raw mode'? If so, then there should be a lirc interface for raw data access. So the lirc_imon I submitted supports all device types, with the onboard decode devices defaulting to operating as pure input devices, but an option to pass hex values out via the lirc interface (which is how they've historically been used -- the pure input stuff I hacked together just a few weeks ago), to prevent functional setups from being broken for those who prefer the lirc way. Hmm. I'd tend to limit the lirc interface to the 'raw samples' case. Historically it has also been used to pass decoded data (i.e. rc5) from devices with onboard decoding, but for that in-kernel mapping + input layer really fits better. What I'm debating is whether this should be split into two drivers, one for the older devices that don't do onboard decoding (which would use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy', and one that is a pure input driver, not unlike the ati_remote{,2} drivers, with no lirc_dev dependency at all, probably called simply 'imon'. i.e. lirc_imon would support first+second gen, and imon third-gen devices, without overlap? > But if I split it out, there may end up being a fair amount of code duplication, You could try to split common code into a third module used by the other two. Or have one module for all devices which is a evdev/lirc hybrid. 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: [RFC v2] Another approach to IR
On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel $ ll /sys/class/input/ | grep usb2 lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 -> ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 -> ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 -> ../../devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ So "/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0" is the device node of the physical device, and the input devices belonging to it are in the "input" subdirectory. If the mouse would be a usb IR receiver the IR attributes should go to /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' subdirectory there. HTH, 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, The big issue here is: how do we document that "EM28xxHVR950-00" is the Hauppauge Grey IR that is shipped with their newer devices. > A third approach would be to identify, instead, the Remote Controller directly. So, we would add a sysfs field like ir_type. I'd pick a more descriptive name like 'bundled_remote'. Maybe an additional attribute could say which protocol the bundled remote speaks (rc5, ...), so userspace could do something sensible by default even if it has no data about the bundled remote. There are two issues here: 1) What's the name for this IR? We'll need to invent names for the existing IR's, as those devices don't have a known brand name; Name them by the hardware they are bundled with should work reasonable well. 2) there are cases where the same device is provided with two or more different IR types. If we identify the board type instead of the IR type, userspace can better handle it, by providing a list of the possibilities. We also could also provide a list of possible remotes directly via sysfs instead of expecting userspace know which remotes can come bundled with which board. No matter how we map, we'll still need to document it somehow to userspace. What would be the better? A header file? A set of keymaps from the default IR's that will be added on some directory at the Linux tree? A Documentation/IR ? I'd suggest tools/ir/ (map loader intended to be called by udev) and the maps being files in the linux source tree (next to the drivers?). The maps probably should be installed on some standard location (pretty much like firmware). Anyway, we shouldn't postpone lirc drivers addition due to that. There are still lots of work to do before we'll be able to split the tables from the kernel drivers. Indeed. The sysfs bits are future work for both lirc and evdev drivers. There is no reason to make the lirc merge wait for it. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On 12/01/09 12:49, Andy Walls wrote: On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote: Once lirc_dev is merged you can easily fix this: You'll have *one* driver which supports *both* evdev and lirc interfaces. If lircd opens the lirc interface raw data will be sent there, keystrokes come in via uinput. Otherwise keystrokes are send directly via evdev. Problem solved. This will be kind of strange for lirc_zilog (aka lirc_pvr150). It supports IR transmit on the PVR-150, HVR-1600, and HD-PVR. I don't know if transmit is raw pulse timings, but I'm sure the unit provides codes on receive. Occasionally blocks of "boot data" need to be programmed into the transmitter side. I suspect lirc_zilog will likely need rework Well, for IR *output* it doesn't make sense to disable evdev. One more reason which indicates it probaably is better to introduce a ioctl to disable evdev reporting. lircd will probably turn it off, especially when sending data to uevent. debug tools might not, likewise apps sending IR. so killing the in-kernel IR limits to make ir-kbd-i2c ^^^ being on par with lirc_i2c might be more useful in this case. I didn't quite understand that. Can you provide a little more info? Such as throwing away the address part of rc5 codes ... 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, A current related problem is that i2c based devices can only be bound to only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time. Currently it is somewhat up to the bridge driver which binding is preferred. Discussion about this for the pvrusb2 module had the biggest email churn IIRC. Once lirc_dev is merged you can easily fix this: You'll have *one* driver which supports *both* evdev and lirc interfaces. If lircd opens the lirc interface raw data will be sent there, keystrokes come in via uinput. Otherwise keystrokes are send directly via evdev. Problem solved. cheers, Gerd PS: Not sure this actually makes sense for the i2c case, as far I know these do decoding in hardware and don't provide access to the raw samples, so killing the in-kernel IR limits to make ir-kbd-i2c being on par with lirc_i2c might be more useful in this case. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, The point is that for simple usage, like an user plugging his new USB stick he just bought, he should be able to use the shipped IR without needing to configure anything or manually calling any daemon. This currently works with the existing drivers and it is a feature that needs to be kept. Admittedly, LIRC is way behind when it comes to plug'n'play. Should not be that hard to fixup. When moving the keytable loading from kernel to userspace the kernel drivers have to inform userspace anyway what kind of hardware the IR device is, so udev can figure what keytable it should load. A sysfs attribute is the way to go here I think. lirc drivers can do the same, and lircd can startup with a reasonable (default) configuration. Of course evdev and lirc subsytems/drivers should agree on which attributes should be defined and how they are filled. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On 11/30/09 13:34, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: Hi Mauro, I just don't want to change a working interface just because it could be also implemented in a different way, but having no other visible advantage than using more recent kernel features. I agree. The main reasons to review the interface is: 1) to avoid any overlaps (if are there any) with the evdev interface; Use lirc for raw samples. Use evdev for decoded data. Hardware/drivers which can handle both can support both interfaces. IMHO it makes no sense at all to squeeze raw samples through the input layer. It looks more like a serial line than a input device. In fact you can homebrew a receiver and connect it to the serial port, which was quite common in pre-usb-ir-receiver times. 2) to have it stable enough to be used, without changes, for a long time. It isn't like lirc is a new interface. It has been used in practice for years. I don't think API stability is a problem here. True, but even if we want to merge lirc drivers "as-is", the drivers will still need changes, due to kernel CodingStyle, due to the usage of some API's that may be deprecated, due to some breakage with non-Intel architectures, due to some bugs that kernel hackers may discover, etc. I assumed this did happen in already in preparation of this submission? 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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/26/09 07:23, Jarod Wilson wrote: Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. lirc predates the input layer IR drivers by years, maybe even the input layer itself. The main reason for the input layer IR drivers appearing was lirc not being mainline. A in-kernel driver (bttv in that case) which depends on a out-of-tree subsystem for IR support was simply a pain in the ass for both maintainer (/me back then) and users. At least for IR hardware which allows access to the raw samples it certainly makes sense to support lirc, additional to the current (or improved) input layer support. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that... lircd can handle the input layer as input as well, so you actually can remap things via lircd even for pure input layer drivers. mythtv handling KEY_VOLUMEUP directly would be more elegant though. 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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/26/09 08:28, Christoph Bartelmus wrote: Hi Gerd, on 26 Nov 09 at 00:22, Gerd Hoffmann wrote: [...] To sum it up: I don't think this information will be useful at all for lircd or anyone else. [...] I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be cases which only lircd will be able to handle (using raw samples). That doesn't make attempts to actually decode the IR samples a useless exercise though ;) Well, in my opinion it is kind of useless. I don't see any use case or any demand for passing this kind of information to userspace, at least in the LIRC context. If there's no demand, why bother? There have been complains about this getting lost somewhere in this thread, so it looks like there are people which do care. 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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
(1) ir code (say rc5) -> keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event->type = EV_IR input_event->code = IR_RC5 input_event->value = In case the 32bit value is too small we might want send two events instead, with ->code being set to IR__1 and IR__2 Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. Unfortunately with most hardware decoders the code that you get is only remotely related to the actual code sent. Most RC-5 decoders strip off start bits. I would include only the actual data bits in the payload anyway. Toggle-bits are thrown away. NEC decoders usually don't pass through the address part. Too bad. But information which isn't provided by the hardware can't be passed up anyway, no matter what kernel/userspace interface is used. Gone is gone. There is no common standard which bit is sent first, LSB or MSB. Input layer would have to define a bit order. And drivers which get it the other way from the hardware have to convert. Or maybe signal the order and the input core then will convert if needed. Checksums are thrown away. Don't include them. To sum it up: I don't think this information will be useful at all for lircd or anyone else. Why not? With RC5 remotes applications can get the device address bits for example, which right now are simply get lost in the ir code -> keycode conversion step. Actually lircd does not even know anything about actual protocols. We only distinguish between certain protocol types, like Manchester encoded, space encoded, pulse encoded etc. Everything else like the actual timing is fully configurable. I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be cases which only lircd will be able to handle (using raw samples). That doesn't make attempts to actually decode the IR samples a useless exercise though ;) 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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On 11/25/09 19:20, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. I think at the end of the day we'll want to have all IR drivers use the same interface. The way the current in-kernel input layer drivers work obviously isn't perfect too, so we *must* consider both worlds to get a good solution for long-term ... This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work "out-of-the-box", regardless of whether lircd is installed. I bet this simply isn't going to change. I have no objection so much as to saying "well, you have to install the lircd service now", but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. *Requiring* lircd for the current in-kernel drivers doesn't make sense at all. Allowing lircd being used so it can do some more advanced stuff makes sense though. This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. Lets have a look at the problems the current input layer bits have compared to lirc: (1) ir code (say rc5) -> keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event->type = EV_IR input_event->code = IR_RC5 input_event->value = In case the 32bit value is too small we might want send two events instead, with ->code being set to IR__1 and IR__2 Advantages: * Applications (including lircd) can get access to the unmodified rc5/rc6/... codes. * All the ir-code -> keycode mapping magic can be handled by the core input layer then. All the driver needs to do is to pass on the information which keymap should be loaded by default (for the bundled remote if any). The configuration can happen in userspace (sysfs attribute + udev + small utility in tools/ir/). * lirc drivers which get ir codes from the hardware can be converted to pure input layer drivers without regressions. lircd is not required any more. (2) input layer doesn't give access to the raw samples. Not sure how to deal with that best. Passing them through the input layer would certainly be possible to hack up. But what would be the point? The input layer wouldn't do any processing on them. It wouldn't buy us much. So we might want to simply stick with todays lirc interface for the raw samples. Drivers which support both ir codes (be it by hardware or by in-kernel decoding) and raw samples would register two devices then, one input device and one lirc device. It would probably a good idea to stop sending events to the input layer as soon as someone (most likely lircd) opens the lirc device to avoid keystrokes showing up twice. By default the in-kernel bits will be at work, but optionally you can have lircd grab the raw samples and do fancy advanced decoding. (3) input layer doesn't allow transmitting IR codes. If we keep the lirc interface for raw samples anyway, then we can keep it for sending too, problem solved ;) How does sending hardware work btw? Do they all accept just raw samples? Or does some hardware also accept ir-codes? 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