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
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
s,
Gerd
Thank you,
Oleksandr Andrushchenko
[1] https://www.youtube.com/watch?v=FcVDHBQInxA
s,
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
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
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 were raised
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 were raised
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
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
ckend 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*
*
*
*
*[1]
ckend 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*
*
*
*
*[1]
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: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 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: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: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 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 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: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
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
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 = xen_drv_probe,
+ .remove = xen_drv_remove,
+ .otherend_changed = backend_on_changed,
What
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 = xen_drv_probe,
+ .remove = xen_drv_remove,
+ .otherend_changed = backend_on_changed,
What
On 02/22/2018 06:11 PM, Daniel Vetter wrote:
On Thu, Feb 22, 2018 at 08:12:48AM +0200, Oleksandr Andrushchenko wrote:
On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
It is possible that drm_simple_kms_plane_atomic
On 02/22/2018 06:11 PM, Daniel Vetter wrote:
On Thu, Feb 22, 2018 at 08:12:48AM +0200, Oleksandr Andrushchenko wrote:
On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when
On 02/22/2018 06:59 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 11:11:23AM +0200, Oleksandr Andrushchenko wrote:
ping
On 02/12/2018 10:52 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
If simple_kms_helper based driver needs t
On 02/22/2018 06:59 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 11:11:23AM +0200, Oleksandr Andrushchenko wrote:
ping
On 02/12/2018 10:52 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide
On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual d
On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this ca
From: Oleksandr Andrushchenko
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this case new CRTC state is NULL and must
On 02/21/2018 12:19 PM, Roger Pau Monné wrote:
On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote:
On 02/21/2018 11:17 AM, Roger Pau Monné wrote:
On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
--- /dev/null
+++ b/drivers/gpu/drm/xen
On 02/21/2018 12:19 PM, Roger Pau Monné wrote:
On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote:
On 02/21/2018 11:17 AM, Roger Pau Monné wrote:
On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
--- /dev/null
+++ b/drivers/gpu/drm/xen
On 02/21/2018 11:17 AM, Roger Pau Monné wrote:
On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Introduce skeleton of the para-virtualized Xen display
frontend driver. This patch only adds re
On 02/21/2018 11:17 AM, Roger Pau Monné wrote:
On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Introduce skeleton of the para-virtualized Xen display
frontend driver. This patch only adds required
essential stubs.
Signed-off
On 02/21/2018 11:09 AM, Juergen Gross wrote:
On 21/02/18 09:47, Oleksandr Andrushchenko wrote:
On 02/21/2018 10:19 AM, Juergen Gross wrote:
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Introduce skeleton of th
On 02/21/2018 11:09 AM, Juergen Gross wrote:
On 21/02/18 09:47, Oleksandr Andrushchenko wrote:
On 02/21/2018 10:19 AM, Juergen Gross wrote:
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Introduce skeleton of the para-virtualized Xen display
frontend driver
On 02/21/2018 10:23 AM, Juergen Gross wrote:
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Initial handling for Xen bus states: implement
Xen bus state machine for the frontend driver according to
the state d
On 02/21/2018 10:23 AM, Juergen Gross wrote:
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
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
On 02/21/2018 10:19 AM, Juergen Gross wrote:
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Introduce skeleton of the para-virtualized Xen display
frontend driver. This patch only adds required
essential stubs.
Sign
On 02/21/2018 10:19 AM, Juergen Gross wrote:
On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
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
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Introduce skeleton of the para-virtualized Xen display
frontend driver. This patch only adds required
essential stubs.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
---
drivers/gpu
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 <oleksandr_andrushche...@epam.com>
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.
Sign
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
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
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 Andrush
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
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 appli
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
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 direc
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
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 <oleksandr_andrushche...@epam.com>
Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to the communication channel
- time-out used for backend communication is set to 3
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
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
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Implement essential initialization of the display driver:
- introduce required data structures
- handle DRM/KMS driver registration
- perform basic DRM driver initialization
- register driver on backend connection
-
From: Oleksandr Andrushchenko
Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to the communication channel
- time-out used for backend communication is set to 3000 ms
- manage display buffers shared
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
Implement essential initialization of the display driver:
- introduce required data structures
- handle DRM/KMS driver registration
- perform basic DRM driver initialization
- register driver on backend connection
- remove driver on backend disconnect
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:
- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtu
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
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
-
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
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
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
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:
On 02/20/2018 01:17 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 04:58:43PM +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:
On 02/20/2018 01:17 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 04:58:43PM +0200, 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:
On 02/20/2018 01:17 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 04:58:43PM +0200, Oleksandr Andrushchenko wrote:
On 02/19/2018 04:30 PM, Daniel Vetter wrote:
On Tue, Feb
On 02/20/2018 02:49 PM, Daniel Vetter wrote:
On Tue, Feb 20, 2018 at 02:36:05PM +0200, Oleksandr Andrushchenko wrote:
On 02/20/2018 01:17 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 04:58:43PM +0200, Oleksandr Andrushchenko wrote:
On 02/19/2018 04:30 PM, Daniel Vetter wrote:
On Tue, Feb
On 02/20/2018 01:17 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 04:58:43PM +0200, Oleksandr Andrushchenko wrote:
On 02/19/2018 04:30 PM, Daniel Vetter wrote:
On Tue, Feb 13, 2018 at 10:44:16AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrush
On 02/20/2018 01:17 PM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 04:58:43PM +0200, Oleksandr Andrushchenko wrote:
On 02/19/2018 04:30 PM, Daniel Vetter wrote:
On Tue, Feb 13, 2018 at 10:44:16AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible
On 02/19/2018 04:30 PM, Daniel Vetter wrote:
On Tue, Feb 13, 2018 at 10:44:16AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space appli
On 02/19/2018 04:30 PM, Daniel Vetter wrote:
On Tue, Feb 13, 2018 at 10:44:16AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before
ping
On 02/12/2018 10:52 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
b
ping
On 02/12/2018 10:52 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
because drm_simple_kms_helper.drm_crtc_funcs does not provide any
On 02/13/2018 03:51 PM, Linus Walleij wrote:
On Mon, Feb 12, 2018 at 9:52 AM, Oleksandr Andrushchenko
<andr2...@gmail.com> wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple
On 02/13/2018 03:51 PM, Linus Walleij wrote:
On Mon, Feb 12, 2018 at 9:52 AM, Oleksandr Andrushchenko
wrote:
From: Oleksandr Andrushchenko
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this ca
From: Oleksandr Andrushchenko
It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this case new CRTC state is NULL and must
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
because drm_simple_kms_helper.drm_crtc_funcs does not provide any.
At the same time drm_
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: Linus Walleij
From: Oleksandr Andrushchenko
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
because drm_simple_kms_helper.drm_crtc_funcs does not provide any.
At the same time drm_driver.{enable|disable}_vblank callbacks
From: Oleksandr Andrushchenko
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr Andrushchenko
Cc: Linus Walleij
---
drivers/gpu/drm/tve200/tve200_display.c | 10 --
drivers/gpu/drm
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
because drm_simple_kms_helper.drm_crtc_funcs does not provide any.
At the same time drm_
From: Oleksandr Andrushchenko
If simple_kms_helper based driver needs to work with vblanks,
then it has to provide drm_driver.{enable|disable}_vblank callbacks,
because drm_simple_kms_helper.drm_crtc_funcs does not provide any.
At the same time drm_driver.{enable|disable}_vblank callbacks
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: Marek Vasut &l
From: Oleksandr Andrushchenko
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr Andrushchenko
Cc: Marek Vasut
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 54
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: Eric Anholt <
From: Oleksandr Andrushchenko
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
but use drm_simple_kms_helpe's pipe callbacks instead.
Signed-off-by: Oleksandr Andrushchenko
Cc: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_display.c | 15 ---
drivers/gpu/drm
On 02/02/2018 10:54 AM, Eduardo Otubo wrote:
On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote:
Hi, Eduardo!
I am working on a frontend driver (PV DRM) and also seeing some strange
things on driver unloading:
xt# rmmod -f drm_xen_front.ko
[ 3236.462497] [drm
On 02/02/2018 10:54 AM, Eduardo Otubo wrote:
On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote:
Hi, Eduardo!
I am working on a frontend driver (PV DRM) and also seeing some strange
things on driver unloading:
xt# rmmod -f drm_xen_front.ko
[ 3236.462497] [drm
On 02/01/2018 11:09 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Current
On 02/01/2018 11:09 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove ca
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible
From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible for the driver to listen to backend's
state changes and synchronize the r
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible for the driver to listen to backend's
state changes and synchronize the removal procedure.
Fix this by removing
501 - 600 of 834 matches
Mail list logo
