[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 <airl...@linux.ie>
Cc: Tomeu Vizoso <tomeu.viz...@collabora.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
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 = _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
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 <kra...@redhat.com> 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
[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 <airl...@linux.ie>
Cc: Tomeu Vizoso <tomeu.viz...@collabora.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
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 = _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
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 <airl...@linux.ie> > > Cc: Tomeu Vizoso <tomeu.viz...@collabora.com> > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > 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 <airl...@linux.ie>
Cc: Tomeu Vizoso <tomeu.viz...@collabora.com>
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
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 = _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;
+ str
[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 kra...@redhat.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com --- 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
[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 kra...@redhat.com --- 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
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
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 zhao...@loongson.cn
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 t...@squid-vision.com
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, 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 Knorrkra...@bytesex.org [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: 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, 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, 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: 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 #1: can't change interface 3 alt no. to 3: Max. Pkt size = 0
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: 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 Hoffmannkra...@redhat.com 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
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: [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 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?
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 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] 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
On 11/25/09 19:20, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com 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 = rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_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
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 =rc5 value In case the 32bit value is too small we might want send two events instead, with -code being set to IR_code_1 and IR_code_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
