[PATCH v3] Add udmabuf misc device

2018-05-25 Thread Gerd Hoffmann
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/s

Re: [RfC PATCH] Add udmabuf misc device

2018-04-10 Thread Gerd Hoffmann
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

Re: [RfC PATCH] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
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

Re: [RfC PATCH] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
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. > >>

Re: [PATCH v2] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
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

Re: [RfC PATCH] Add udmabuf misc device

2018-04-06 Thread Gerd Hoffmann
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

[PATCH v2] Add udmabuf misc device

2018-03-16 Thread Gerd Hoffmann
= MISC_DYNAMIC_MINOR, + .name = "udmabuf", + .fops = _fops, +}; + +static int __init udmabuf_dev_init(void) +{ + return misc_register(_misc); +} + +static void __exit udmabuf_dev_exit(void) +{ + misc_deregister(_misc); +} + +module_init(udmabuf_dev_

Re: [RfC PATCH] Add udmabuf misc device

2018-03-14 Thread Gerd Hoffmann
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...@re

[RfC PATCH] Add udmabuf misc device

2018-03-13 Thread Gerd Hoffmann
irl...@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 ++ driver

[PATCH v3 2/4] break kconfig dependency loop

2015-05-22 Thread Gerd Hoffmann
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

[PATCH v2 1/4] break kconfig dependency loop

2015-04-01 Thread Gerd Hoffmann
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

Re: [PATCH v2 1/4] break kconfig dependency loop

2015-04-01 Thread Gerd Hoffmann
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

saa7134 irq status bits

2013-04-02 Thread Gerd Hoffmann
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

Fwd: bttv kernel patch

2012-07-19 Thread Gerd Hoffmann
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.

Re: USB mini-summit at LinuxCon Vancouver

2011-06-10 Thread Gerd Hoffmann
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

Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

2011-01-26 Thread Gerd Hoffmann
...@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

Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

2011-01-26 Thread Gerd Hoffmann
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

Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

2011-01-26 Thread Gerd Hoffmann
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

Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

2011-01-26 Thread Gerd Hoffmann
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

Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

2011-01-26 Thread Gerd Hoffmann
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

Re: Hauppauge USB Live 2

2010-12-15 Thread Gerd Hoffmann
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

Hauppauge USB Live 2

2010-12-14 Thread Gerd Hoffmann
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.

Re: Hauppauge USB Live 2

2010-12-14 Thread Gerd Hoffmann
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

Re: Hauppauge USB Live 2

2010-12-14 Thread Gerd Hoffmann
$ 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.

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-03 Thread Gerd Hoffmann
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

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Gerd Hoffmann
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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann
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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann
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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann
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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann
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

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Gerd Hoffmann
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

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Gerd Hoffmann
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

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Gerd Hoffmann
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

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-25 Thread Gerd Hoffmann
(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