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
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
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
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.
> >>
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
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
= 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_
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
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
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
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
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
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
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.
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
...@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
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
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
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
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
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
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.
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
$ 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.
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
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
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
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
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
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
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
(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
32 matches
Mail list logo
