trigger events for playback control: start/stop/pause/resume
- add "req-" prefix to event-channel and ring-ref to unify naming
of the Xen event channels for requests and events
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Grytsov
Cc: Konrad Rzeszutek Wilk
Cc: Ta
figuration
space.
- Minor documentation cleanup (added missed "reserved" fields)
Oleksandr Andrushchenko (5):
xen/sndif: Introduce protocol version
xen/sndif: Fix missed "reserved" fields in comments
xen/sndif: Make requests and responses 64 octets long
xen/sndi
Protocol version was referenced in the protocol description,
but missed its definition. Fix this by adding a constant
for current protocol version.
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/sndif.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/xen
Extend the size of the requests and responses to 64 octets.
Bump protocol version to 2.
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/sndif.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/xen/interface/io/sndif.h b
Hi, Peng!
On 04/12/2018 05:21 AM, Peng Fan wrote:
Hi Oleksandr,
Just have a question, is this drm/xen-front stuff orthogonal to xen shared
coprocessor framework for gpu, or are they exclusive?
They are orthogonal
Thanks,
Peng.
On 04/10/2018 08:26 PM, Dongwon Kim wrote:
On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
On 04/06/2018 09:57 PM, Dongwon Kim wrote:
On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:
On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
Hi,
I fail
n't tested Linus' master branch yet. For now, this VM runs
v4.16 kernel.
Regards,
Oleksandr
[1] https://natalenko.name/myfiles/usercopy_bfq_woe/
Hi.
10.04.2018 08:35, Oleksandr Natalenko wrote:
- does it reproduce _without_ hardened usercopy? (I would assume yes,
but you'd just not get any warning until the hangs started.) If it
does reproduce without hardened usercopy, then a new bisect run could
narrow the search even more.
On 04/10/2018 01:47 PM, Julien Grall wrote:
Hi,
On 04/10/2018 09:53 AM, Oleksandr Andrushchenko wrote:
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
diff --git a/drivers/dma-buf/hyper_dmabuf/hyper_dmabuf_id.h
[...]
+#ifndef __HYPER_DMABUF_ID_H__
+#define __HYPER_DMABUF_ID_H__
+
+#define
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
Use threaded interrupt intead of regular one because most part of ISR
is time-critical and possibly sleeps
Signed-off-by: Dongwon Kim
---
.../hyper_dmabuf/backends/xen/hyper_dmabuf_xen_comm.c | 19 +++
1 file changed, 11 insertions(+
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
Define a private data (e.g. meta data for the buffer) attached to
each hyper_DMABUF structure. This data is provided by userapace via
export_remote IOCTL and its size can be up to 192 bytes.
Signed-off-by: Dongwon Kim
Signed-off-by: Mateusz Polrola
--
Sorry for top-posting
Can we have all this go into some header file which
will not only describe the structures/commands/responses/etc,
but will also allow drivers to use those directly without
defining the same one more time in the code? For example,
this is how it is done in Xen [1]. This w
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
From: "Matuesz Polrola"
The default backend for XEN hypervisor. This backend contains actual
implementation of individual methods defined in "struct hyper_dmabuf_bknd_ops"
defined as:
struct hyper_dmabuf_bknd_ops {
/* backend initialization r
On 02/14/2018 03:50 AM, Dongwon Kim wrote:
Upload of intial version of core framework in hyper_DMABUF driver
enabling DMA_BUF exchange between two different VMs in virtualized
platform based on Hypervisor such as XEN.
Hyper_DMABUF drv's primary role is to import a DMA_BUF from originator
then re
On 04/06/2018 09:57 PM, Dongwon Kim wrote:
On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:
On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
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
almost immediately. I got no warnings at all, though.
Did your system hang on smartctl hammering too? Have you got some stack
traces to compare with mine ones?
Regards,
Oleksandr
bserve the
issue (so far, at least).
Paolo, Jens? I don't know whom to address, actually :(. Can someone give
me an idea on this please?
The thing I can't figure out is how req->sense is slipping forward in
(and even beyond!) the allocation.
*cough* race condition *cough* ☺
Regards,
Oleksandr
ronment to reproduce
it. I'll try to collect more info.
And I'm also curious why
you think 17cb960f29c2 should change anything for that code path.
Maybe, I've just mis-read that code.
Regards,
Oleksandr
ike this code path was re-written completely with 17cb960f29c2, but
it went merged for the upcoming v4.17 only, and thus I haven't tried it yet.
Kees took a brief look at it already: [1]. This is what smartctl does [2]
(just a usual strace capture when the bug is not triggered).
Christoph, do y
terms of implementing all that page sharing fun in multiple directions,
e.g. Host->Guest, Guest->Host, Guest<->Guest.
But I'll let Matt and Dongwon to comment on that.
cheers,
Gerd
Thank you,
Oleksandr
P.S. Sorry for making your original mail thread to discuss things much
broader than your RFC...
On 04/03/2018 12:47 PM, Daniel Vetter wrote:
On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
+static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj)
+{
+ grant_ref_t priv_gref_head;
+ int ret, j, cur_ref
that this is useful outsize virtualization too.
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?
And what about hyper-dmabuf?
Thank you,
Oleksandr
On 04/03/2018 02:22 PM, Roger Pau Monné wrote:
On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote:
From: Bob Liu
The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
* max_indirect_s
On 04/06/2018 12:07 PM, Gerd Hoffmann wrote:
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 shoul
On 04/06/2018 03:11 AM, Matt Roper wrote:
On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote:
Pulling this out of the shadows again.
We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
from Matt and Dongwong.
At least from the intel side there seems to be the idea
q35", BTW.
Do you think something of what's mentioned above is relevant for the
code path in question?
Thanks.
Regards,
Oleksandr
05.04.2018 16:32, Oleksandr Natalenko wrote:
"-hda sda.img -hdb sda.img"
"-hda sda.img -hdb sdb.img", of course, I don't pass the same disk twice
☺
bus=bus0.0,drive=drive0
Does this match your qemu instance?
Well, not really. I just pass 2 raw disks as "-hda sda.img -hdb sda.img"
(it is a playground VM for me with RAID10, LVM and LUKS inside, but I
hope this doesn't matter). Does passing "-hda" differ from your
approach?
Regards,
Oleksandr
things
behave without smartctl too.
Regards,
Oleksandr
Hopefully, SCSI people are Cc'ed here properly…
Thanks!
Regards,
Oleksandr
rtctl is issuing? I'll try to
reproduce this on my end...
As per [2], strace shows "SG_IO" requests. Is this detailed enough?
Thanks for looking into it.
Regards,
Oleksandr
[1] https://git.archlinux.org/svntogit/packages.git/plain/trunk/config?
h=packages/linux&id
ppy/ready to test any proposed patches.
Thanks.
Regards,
Oleksandr
On 04/03/2018 03:32 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add myself as drivers/gpu/drm/xen maintainer.
Signed-off-by: Oleksandr Andrushchenko
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
From: Oleksandr Andrushchenko
Add myself as drivers/gpu/drm/xen maintainer.
Signed-off-by: Oleksandr Andrushchenko
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 622f3e4c5efa..6cf1bd5593b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
On 04/03/2018 02:23 PM, Oleksandr Andrushchenko wrote:
Resending with even more checkpatch code-style fixes.
Applied,
thank you!
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
From: Oleksandr Andrushchenko
Resending with even more checkpatch code-style fixes.
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
From: Oleksandr Andrushchenko
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io
From: Oleksandr Andrushchenko
Introduce Xen zero-copy helper DRM driver, add user-space API of the driver:
1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
- Frontend
- creates a dumb/display
From: Oleksandr Andrushchenko
Hello!
When using Xen PV DRM frontend driver then on backend side one will need
to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers
On 03/28/2018 06:09 PM, Daniel Vetter wrote:
On Wed, Mar 28, 2018 at 10:38:35AM +0300, Oleksandr Andrushchenko wrote:
From: Noralf Trønnes
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing
On 03/29/2018 12:22 PM, Oleksandr Andrushchenko wrote:
Changes since v4:
For your convenience I am attaching diff between v4..v5
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
index 8188e03c9d23..009d942386c5 100644
--- a/Documentation/gpu/xen-front.rst
+++ b
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
From: Oleksandr Andrushchenko
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io
On 03/29/2018 10:17 AM, Daniel Vetter wrote:
On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:
Hi, Daniel!
I just noticed I have missed one change in the patch:
the below must be static.
On 03/28/2018 10:42 AM, Daniel Vetter wrote:
+enum drm_mode_status
xen_drm_front_drm_pipeline *pipeline =
+ container_of(crtc,
Could you please amend the patch in attachment
when merging, so I don't resend?
Thank you in advance,
Oleksandr
>From 3a82d76bd3d954056b760e5d1d09e2f96a2786ef Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko
Date: Wed, 28
On 03/28/2018 10:42 AM, Daniel Vetter wrote:
kms side looks good now too.
Reviewed-by: Daniel Vetter
Thank you
: Noralf Trønnes
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Oleksandr Andrushchenko
Tested-by: Oleksandr Andrushchenko
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm
From: Oleksandr Andrushchenko
Hello!
Notes.
1. Boris, I put your R-b tag as I almost didn't change Xen part
of the driver (see below). Please let me know if this is not acceptable,
so I remove the tag.
2. With this patch series I am also adding a patch from Noralf Trønnes [12]
to e
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
Tested-by: Oleksandr Andrushchenko
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm/drm_drv.h | 15 +
3
On 03/27/2018 12:50 PM, Daniel Vetter wrote:
On Tue, Mar 27, 2018 at 11:34 AM, Oleksandr Andrushchenko
wrote:
Hi, Daniel!
On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote:
On 03/26/2018 11:18 AM, Daniel Vetter wrote:
On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko
Hi, Daniel!
On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote:
On 03/26/2018 11:18 AM, Daniel Vetter wrote:
On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote:
My apologies, but I found a few more things that look strange and
should
be cleaned up. Sorry for this
On 03/26/2018 11:18 AM, Daniel Vetter wrote:
On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote:
My apologies, but I found a few more things that look strange and should
be cleaned up. Sorry for this iterative review approach, but I think we're
slowly getting there.
NVAL;
As mentioned, this -EINVAL here needs to go. Since you already have a
mode_valid callback you can (should) drop this one here entirely.
Not sure how mode_valid is relevant to this code [1]: This function is
called
in the check phase of an atomic update, specifically when the underlying
plan
that you
> use.
Correct. The hash is d7568c130d0d0ff1fc5b364fc879b91f108a3d54, actually, though.
Yes, we miss this commit in our code base, but also we've already
provided a test kernel
with this commit included to the customer. Unfortunately, we have no answer yet.
--
Best regards,
On 03/22/2018 03:14 AM, Boris Ostrovsky wrote:
On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
From: Oleksandr Andrushchenko
Hello!
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4
On 03/20/2018 03:47 PM, Daniel Vetter wrote:
On Tue, Mar 20, 2018 at 01:58:01PM +0200, Oleksandr Andrushchenko wrote:
On 03/19/2018 05:28 PM, Daniel Vetter wrote:
There should be no difference between immediate removal and delayed
removal of the drm_device from the xenbus pov. The lifetimes of
On 03/19/2018 05:28 PM, Daniel Vetter wrote:
On Mon, Mar 19, 2018 at 3:19 PM, Oleksandr Andrushchenko
wrote:
On 03/19/2018 03:51 PM, Daniel Vetter wrote:
On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
Hi, Daniel!
Sorry, if I strip the patch too much below.
On 03/16
Hi.
On Mon, Mar 19, 2018 at 7:52 PM, Nadav Amit wrote:
>> Oleksandr, if you can confirm that it fixes the bug you encountered, it
>> would be great.
>>
>> Greg, Arnd, on your free time, please let me know if there is any issue
>> with the patch, and whether you can
On 03/20/2018 01:23 AM, Boris Ostrovsky wrote:
On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
Resending with all the patches squashed on Daniel's request.
Which of the two series are we supposed to review? The 8-patch one or
this? (I hope
On 03/19/2018 03:51 PM, Daniel Vetter wrote:
On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
Hi, Daniel!
Sorry, if I strip the patch too much below.
On 03/16/2018 10:23 AM, Daniel Vetter wrote:
S-o-b line went missing here :-)
will restore it back ;)
I've
around.
Well, I tried to keep it all at one place, but as we decided
to implement connector hotplug for error delivery it
became split. Also, I handle frame done event time-outs there.
Thank you very much for review and comments,
Oleksandr
Hello.
On Wed, Mar 14, 2018 at 5:02 AM, Nadav Amit wrote:
> Oleksandr, if you can confirm that it fixes the bug you encountered, it
> would be great.
Sure, I'm checking this possibility with a couple of customers, and
will reply back once I have some inputs on it.
> Greg, Arnd
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
From: Oleksandr Andrushchenko
Hello!
Resending with all the patches squashed on Daniel's request.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implem
From: Oleksandr Andrushchenko
Provide kernel documentation for the Xen para-virtualized
frontend DRM driver.
Signed-off-by: Oleksandr Andrushchenko
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/xen-front.rst | 77 +
2 files changed, 78
From: Oleksandr Andrushchenko
Introduce skeleton of the para-virtualized Xen display
frontend driver. This patch only adds required
essential stubs.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile| 1 +
drivers/gpu
From: Oleksandr Andrushchenko
Implement essential initialization of the display driver:
- introduce required data structures
- handle DRM/KMS driver registration
- register driver on backend connection
- remove driver on backend disconnect
Implement kernel modesetiing/connector handling
From: Oleksandr Andrushchenko
Hello!
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4
From: Oleksandr Andrushchenko
Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
- handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set
From: Oleksandr Andrushchenko
Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
- read connector(s) configuration
- read buffer allocation mode (backend/frontend)
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/Makefile
From: Oleksandr Andrushchenko
Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
requirements dictated by the accompanying DRM/(v)GPU drivers running in both
host and guest environments, number of operating
From: Oleksandr Andrushchenko
Handle Xen event channels:
- create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
- implement event channels interrupt handlers
- create and destroy event channels with
From: Oleksandr Andrushchenko
Provide kernel documentation for the Xen para-virtualized
frontend DRM driver.
Signed-off-by: Oleksandr Andrushchenko
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/xen-front.rst | 77 +
2 files changed, 78
From: Oleksandr Andrushchenko
Initial handling for Xen bus states: implement
Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.
Signed-off-by: Oleksandr Andrushchenko
---
drivers
On 03/06/2018 11:26 AM, Daniel Vetter wrote:
On Mon, Mar 05, 2018 at 11:30:35AM +0200, Oleksandr Andrushchenko wrote:
On 03/05/2018 11:25 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:42AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Handle communication with
On 03/06/2018 09:26 AM, Daniel Vetter wrote:
On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote:
On 03/05/2018 11:32 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Implement GEM handling
On 03/06/2018 09:22 AM, Daniel Vetter wrote:
On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote:
On 03/05/2018 11:23 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Implement kernel
On 03/05/2018 11:32 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
On 03/05/2018 11:23 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:
- implement KMS part of the driver with the help of DRM
On 03/05/2018 11:25 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:42AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to
On 03/05/2018 11:13 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:39AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Implement essential initialization of the display driver:
- introduce required data structures
- handle DRM/KMS driver registration
On 03/05/2018 10:52 AM, Daniel Vetter wrote:
On Tue, Feb 20, 2018 at 03:29:07PM +0200, Oleksandr Andrushchenko wrote:
On 02/20/2018 02:53 PM, Oleksandr Andrushchenko wrote:
On 02/20/2018 02:49 PM, Daniel Vetter wrote:
On Tue, Feb 20, 2018 at 02:36:05PM +0200, Oleksandr Andrushchenko wrote
or inclusion.
cheers,
Gerd
Thank you,
Oleksandr Andrushchenko
[1] https://www.youtube.com/watch?v=FcVDHBQInxA
On 02/28/2018 09:46 PM, Boris Ostrovsky wrote:
On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote:
On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr
ll require QEMU to run.
Although this use case would work on x86 it will require additional changes
to get this running on ARM, which is my target platform.
Thank you,
Oleksandr
On 02/26/2018 10:21 AM, Oleksandr Andrushchenko wrote:
**
*Hi, all!*
*
Last *Friday* some concerns on #dri-devel w
On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size
a backend which supports multi-touch and guest
display(s) and running either as a weston client (which is not supported
by QEMU at the moment?) or KMS/DRM client. This allows us to enable much
more use-cases**without the need to run QEMU.
*
*Thank you,*
**Oleksandr Andrushchenko*
*
*
*
*
On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size)
+{
+ struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+ struct xen_gem_object *xen_
On 02/23/2018 05:12 PM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+
+struct drm_driver xen_drm_driver = {
+ .driver_features = DRIVER_GEM | DRIVER_MODESET |
+DRIVER_PRIME | DRIVER_ATOMIC,
+ .lastclose
On 02/23/2018 04:39 PM, Boris Ostrovsky wrote:
On 02/23/2018 01:37 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 12:23 AM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+static struct xenbus_driver xen_driver = {
+.ids = xen_drv_ids,
+.probe
On 02/23/2018 04:44 PM, Boris Ostrovsky wrote:
On 02/23/2018 02:00 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+
+static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
+{
+struct
On 02/23/2018 04:36 PM, Boris Ostrovsky wrote:
On 02/23/2018 02:53 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 02:25 AM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
static int __init xen_drv_init(void)
{
+/* At the moment we only support case
On 02/23/2018 02:25 AM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
static int __init xen_drv_init(void)
{
+ /* At the moment we only support case with XEN_PAGE_SIZE == PAGE_SIZE */
+ BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
Why
On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+
+static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
+{
+ struct xen_drm_front_evtchnl *evtchnl = dev_id;
+ struct xen_drm_front_info *front_info = evtchnl
On 02/23/2018 01:20 AM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+
+static int cfg_connector(struct xen_drm_front_info *front_info,
+ struct xen_drm_front_cfg_connector *connector,
+ const char *path, int index)
+{
+ char
501 - 600 of 1001 matches
Mail list logo
