Hi, Daniel!
On 3/25/21 11:16 AM, Daniel Vetter wrote:
> On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko
> wrote:
>> Hi,
>>
>> On 3/25/21 8:19 AM, Wan Jiabing wrote:
>>> struct xen_drm_front_drm_info has been declared.
>>> Remove the duplicate.
&g
iled and still free the drm_info.
> Second sets front_info->drm_info to NULL to avoid uaf.
>
> Signed-off-by: Lv Yunlong
Thank you for the patch,
Reviewed-by: Oleksandr Andrushchenko
Will apply to drm-misc-next-fixes
Thank you,
Oleksandr
> ---
> drivers/gpu/drm/xen/xen_d
Hi,
On 3/25/21 8:19 AM, Wan Jiabing wrote:
> struct xen_drm_front_drm_info has been declared.
> Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
Thank you for the patch,
Reviewed-by: Oleksandr Andrushchenko
Will apply to drm-misc-next-fixes
Thank you,
Oleksandr
> ---
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's
On 8/13/20 6:13 PM, Jürgen Groß wrote:
> On 13.08.20 17:10, Oleksandr Andrushchenko wrote:
>>
>> On 8/13/20 6:02 PM, Jürgen Groß wrote:
>>> On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>
>>&g
On 8/13/20 6:02 PM, Jürgen Groß wrote:
> On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>
> Series pushed to:
>
> xen/tip.git for-linus-5.9
>
The top patch has strange title though:
"Subject: [PATCH v2 5/5] drm/xen-front:
Juergen, Boris,
can we please merge these via Xen Linux tree as I have collected enough Ack/R-b?
The series has DRM patches, but those anyway are Xen related, so I think
this should be fine from DRI point of view.
Thank you,
Oleksandr
On 8/13/20 9:21 AM, Oleksandr Andrushchenko wrote:
> F
On 8/13/20 10:05 AM, Jürgen Groß wrote:
> On 13.08.20 08:32, Oleksandr Andrushchenko wrote:
>> Juergen, Boris,
>>
>> can we please merge these via Xen Linux tree as I have collected enough
>> Ack/R-b?
>>
>> The series has DRM patches, but t
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: bf8dc55b1358 ("xen/gntdev: Implement dm
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On 8/4/20 9:11 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> It is possible that the scatter-gather table during dmabuf import has
>> non-zero offset of the data, but user-space doesn't expect t
On 8/4/20 9:12 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
>> display frontend" from Apr 3, 2018, leads to th
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dm
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to
the masks to 64 bits.
>
> Cc: Robin Murphy
> Cc: Julien Grall
> Cc: Nicolas Saenz Julienne
> Cc: Oleksandr Andrushchenko
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Christoph Hellwig
> Cc: xen-de...@lists.xenproject.org
> Sig
On 10/1/19 9:23 PM, Stefano Stabellini wrote:
> On Thu, 26 Sep 2019, Rob Herring wrote:
>> On Thu, Sep 26, 2019 at 6:16 AM Oleksandr Andrushchenko
>> wrote:
>>> On 9/26/19 1:46 PM, Robin Murphy wrote:
>>>> On 2019-09-26 11:17 am, Oleksandr Andrushchenko wrot
On 9/26/19 1:46 PM, Robin Murphy wrote:
> On 2019-09-26 11:17 am, Oleksandr Andrushchenko wrote:
>>
>> On 9/26/19 12:49 PM, Julien Grall wrote:
>>> Hi Rob,
>>>
>>>
>>> On 9/25/19 10:50 PM, Rob Herring wrote:
>>>> As the comment says,
On 9/26/19 12:49 PM, Julien Grall wrote:
> Hi Rob,
>
>
> On 9/25/19 10:50 PM, Rob Herring wrote:
>> As the comment says, this isn't a DT based device. of_dma_configure()
>> is going to stop allowing a NULL DT node, so this needs to be fixed.
>
> And this can't work on arch not selecting CONFIG_OF
()
drivers/xen/gntdev-common.h | 2 +-
drivers/xen/gntdev-dmabuf.c | 11 +++---
drivers/xen/gntdev.c| 52 ++---
3 files changed, 25 insertions(+), 40 deletions(-)
For the series:
Reviewed-by: Oleksandr Andrushchenko
On 6/28/19 11:46 AM, Takashi Iwai wrote:
On Thu, 27 Jun 2019 18:58:53 +0200,
Colin King wrote:
From: Colin Ian King
Shifting the integer value 1 is evaluated using 32-bit
arithmetic and then used in an expression that expects a 64-bit
value, so there is potentially an integer overflow. Fix
+Xen-devel list
On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/video/fbdev/xen-fbfront.c: In function ‘xenfb_backend_changed’:
On 2/25/19 3:55 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to
introduce one atomic field per event to record the number of event
received. I will explore
On 2/20/19 10:46 PM, Julien Grall wrote:
(+ Andrew and Jan for feedback on the event channel interrupt)
Hi Boris,
Thank you for the your feedback.
On 2/20/19 8:04 PM, Boris Ostrovsky wrote:
On 2/20/19 1:05 PM, Julien Grall wrote:
Hi,
On 20/02/2019 17:07, Boris Ostrovsky wrote:
On 2/20/19
On 2/15/19 5:28 PM, Boris Ostrovsky wrote:
On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote:
On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
/* DMA buffer export support. */
@@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref
On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
/* DMA buffer export support. */
@@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);
list_
From: Oleksandr Andrushchenko
Check if there are any imported dma-bufs left not released by
user-space when grant device's release callback is called and
free those if this is the case. This can happen if user-space
leaks the buffers because of a bug or application has been
terminated for any
From: Oleksandr Andrushchenko
If there are exported DMA buffers which are still in use and
grant device is closed by either normal user-space close or by
a signal this leads to the grant device context to be destroyed,
thus making it not possible to correctly destroy those exported
buffers when
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecom
On 1/26/19 2:05 PM, YueHaibing wrote:
> There is no need to have the 'struct drm_framebuffer *fb' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On 2/1/19 11:14 AM, Juergen Gross wrote:
> On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
>> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>>>> Hello,
>>>>
>>>> I am working on porti
On 1/30/19 11:09 AM, Oleksandr Andrushchenko wrote:
> On 1/29/19 9:07 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> When GEM backing storage is allocated
On 1/28/19 8:36 AM, Oleksandr Andrushchenko wrote:
> On 1/26/19 2:05 PM, YueHaibing wrote:
>> There is no need to have the 'struct drm_framebuffer *fb' variable
>> static since new value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing
> Goo
On 1/31/19 11:44 PM, Stefano Stabellini wrote:
> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>> Hello,
>>
>> I am working on porting an out-of-tree kernel driver to the kernel
>> 5.0 and that driver uses functionality provided by
>> drivers/xen/mem-reservat
On 2/1/19 10:27 AM, Christoph Hellwig wrote:
> On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote:
>> The alternative would be to turn xenmem_reservation_scrub_page into a
>> regular function (not a static inline)?
> All that is a moot point until said currently out of tree module
Hello,
I am working on porting an out-of-tree kernel driver to the kernel
5.0 and that driver uses functionality provided by
drivers/xen/mem-reservation.c
module. Since commit [1] it is not possible to build a kernel module
which uses mem-reservation API as xen_scrub_pages variable, which is
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecom
Dropped in favor of https://lkml.org/lkml/2019/1/29/910
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>&g
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.
Fixes: c575b7eeb89f
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
&g
+Boris and Juergen who can also help getting it in
On 1/28/19 8:34 AM, Souptick Joarder wrote:
On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
wrote:
On 1/7/19 7:37 PM, Souptick Joarder wrote:
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
On 1/26/19 2:05 PM, YueHaibing wrote:
> There is no need to have the 'struct drm_framebuffer *fb' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: YueHaibing
Good catch, thank you!
Reviewed-by: Oleksandr Andrushchenko
> ---
> d
Hello, Julien!
Sorry for the late reply - it took quite some time to collect the data
requested.
On 1/22/19 1:44 PM, Julien Grall wrote:
>
>
> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/21/19 7:09 PM, Julien Gral
Hello, Julien!
On 1/21/19 7:09 PM, Julien Grall wrote:
> Hello,
>
> On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
>> On 1/18/19 1:43 PM, Julien Grall wrote:
>>> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
>>>> On 1/17/19 11:18 AM, Christoph Hellw
On 1/18/19 1:43 PM, Julien Grall wrote:
> (+ Stefano)
>
> Hi,
>
> Sorry for jumping late in the conversation.
>
> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
>> On 1/17/19 11:18 AM, Christoph Hellwig wrote:
>>> On Wed, Jan 16, 2019 at 06:43:29AM +
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 06:43:29AM +0000, Oleksandr Andrushchenko wrote:
>>> This whole issue keeps getting more and more confusing.
>> Well, I don't really do DMA here, but instead the buffers in
>> question are shared w
On 1/16/19 8:36 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
>>Hi,
>>
>>> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>>> + DMA_BIDIRECTIONAL)) {
>>> + ret = -EFAULT;
>>> + goto
On 1/16/19 8:30 AM, Gerd Hoffmann wrote:
>Hi,
>
>> +if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>> +DMA_BIDIRECTIONAL)) {
>> +ret = -EFAULT;
>> +goto fail_free_sgt;
>> +}
> Hmm, so it seems the arm guys could not come up
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent
On 1/7/19 7:37 PM, Souptick Joarder wrote:
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
arch/arm/xen/mm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2
On 1/11/19 5:10 PM, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions
On 1/11/19 7:37 AM, Gerd Hoffmann wrote:
Switch to atomic helpers: drm_mode_config_helper_suspend/resume().
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_drv.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff
On 1/10/19 1:15 PM, Gerd Hoffmann wrote:
Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
userspace.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
On 12/19/18 2:26 PM, Gerd Hoffmann wrote:
If we got an error response code from the host, print it to the log.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions
On 12/20/18 8:38 PM, Christoph Hellwig wrote:
On Thu, Dec 20, 2018 at 07:35:15PM +0100, Daniel Vetter wrote:
Err, with streaming DMA buffer sharing is trivial. The coherent DMA
allocator is what causes all kinds of horrible hacks that can't actually
work on various platforms.
Hm, I thought
On 12/20/18 5:36 PM, Christoph Hellwig wrote:
On Tue, Dec 18, 2018 at 08:20:22PM +0100, Noralf Trønnes wrote:
+ if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
+ DMA_BIDIRECTIONAL)) {
Are you using the DMA streaming API as a way to flush the
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
bochs_fbdev.c is almost empty now. Move the remaining framebuffer bits
over to bochs_kms.c. Pure code motion. No functional change.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 29
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Not needed any more, bochs uses the generic emulation now.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs.h | 9 ---
drivers/gpu/drm/bochs/bochs_drv.c | 6 --
drivers/gpu/drm/bochs
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index a9c7140e3b..f1f65324bb 100644
---
bochs_bo(obj);
+
+ return ttm_fbdev_mmap(vma, >bo);
+}
With the above fixed:
Reviewed-by: Oleksandr Andrushchenko
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
It's always NULL, so just remove it.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs.h | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/bochs/bochs_kms.c | 2
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Remove the old, now unused crtc callbacks.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_kms.c | 81 ---
1 file changed, 81 deletions(-)
diff --git a/drivers
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Conversion to atomic modesetting, final step.
Set the DRIVER_ATOMIC flag.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Conversion to atomic modesetting, step five.
Use atomic page_flip helper for crtc.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_kms.c | 23 +--
1 file changed, 1 insertion
tc->primary->state, fb);
Taking into account that crtc->primary access goes away in the series:
Reviewed-by: Oleksandr Andrushchenko
bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
if (event) {
spin_lock_irqsave(>dev->event_lock, irqflags);
@@ -151
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Conversion to atomic modesetting, step four.
Use atomic set_config helper for crtc.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Conversion to atomic modesetting, step two.
Add mode_set_nofb crtc helper callback.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_kms.c | 9 +
1 file changed, 9 insertions(+)
diff
/bochs: add edid support.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/bochs/bochs_hw.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index
On 12/19/18 6:14 PM, Noralf Trønnes wrote:
Den 19.12.2018 09.18, skrev Oleksandr Andrushchenko:
On 12/18/18 9:20 PM, Noralf Trønnes wrote:
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
On 12/19/18 4:10 PM, Gerd Hoffmann wrote:
Hi,
Sure this actually helps? It's below 4G in guest physical address
space, so it can be backed by pages which are actually above 4G in host
physical address space ...
Yes, you are right here. This is why I wrote about the IOMMU
and other
On 12/19/18 5:21 PM, Gerd Hoffmann wrote:
Hi,
You could probably have a comment here explaining the magic below
(just like in the commit message to ease the task of understanding
while reading the code why 2 of 8 bytes of the EDID header is checked
and why it is all needed). Of course one
Hi, Gerd!
On 12/19/18 1:51 PM, Gerd Hoffmann wrote:
Conversion to atomic modesetting, step one.
Add atomic crtc helper callbacks.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_kms.c | 25 +
1 file changed, 25 insertions(+)
diff --git
if (WARN_ON(crtc->primary->fb == NULL))
return -EINVAL;
- bochs_hw_setmode(bochs, mode, crtc->primary->fb->format);
+ bochs_hw_setmode(bochs, mode);
+ bochs_hw_setformat(bochs, crtc->primary->fb->format);
I was about to suggest that you go away from direct crtc->primary
use, but it seems this code goes away in this series
bochs_crtc_mode_set_base(crtc, x, y, old_fb);
return 0;
}
Reviewed-by: Oleksandr Andrushchenko
)
encoder->possible_crtcs = 0x1;
drm_encoder_init(dev, encoder, _encoder_encoder_funcs,
DRM_MODE_ENCODER_DAC, NULL);
- drm_encoder_helper_add(encoder, _encoder_helper_funcs);
}
Reviewed-by: Oleksandr Andrushchenko
ointer arithmetic here?
+ return -1;
+
kfree(bochs->edid);
bochs->edid = drm_do_get_edid(>connector,
bochs_get_edid_block, bochs);
With the above fixed:
Reviewed-by: Oleksandr Andrushchenko
On 12/19/18 3:14 PM, Gerd Hoffmann wrote:
Hi,
+ mapping = xen_obj->base.filp->f_mapping;
+ mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
Let's see if I understand what you're doing:
Here you say that the pages should be DMA accessible for devices that can
only see 4GB.
On 12/18/18 9:20 PM, Noralf Trønnes wrote:
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content
On 12/18/18 20:31, Boris Ostrovsky wrote:
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove
On 12/17/18 5:26 PM, Boris Ostrovsky wrote:
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it might take quite some time to complete) could we please
merge the patches 1 and 3 now
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it might take quite some time to complete) could we please
merge the patches 1 and 3 now that already have ack/r-b?
Thank you,
Oleksandr
On 12/13/18 12:16 PM, Oleksandr Andrushchenko wrote:
bump
On 12/14/18 10:35 AM, Daniel Vetter wrote:
On Fri, Dec 14, 2018 at 09:09:45AM +0200, Oleksandr Andrushchenko wrote:
On 12/13/18 5:48 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
Daniel, could you please comment?
Cross-revieweing someone
On 12/13/18 5:48 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
Daniel, could you please comment?
Cross-revieweing someone else's stuff would scale better,
fair enough
I don't think
I'll get around to anything before next year.
I put you
Daniel, could you please comment?
Thank you
On 11/27/18 12:32 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content
bump
On 12/5/18 10:20 AM, Oleksandr Andrushchenko wrote:
Hello, Daniel!
Could you please ack/nack the patch, so either we can merge the
series or I can address your comments if any
Thank you,
Oleksandr
On 11/30/18 9:42 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Use
On 11/19/18 12:42 PM, Souptick Joarder wrote:
On Mon, Nov 19, 2018 at 3:22 PM Oleksandr Andrushchenko
wrote:
On 11/15/18 5:49 PM, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
On 11/19/18 12:42 PM, Souptick Joarder wrote:
On Mon, Nov 19, 2018 at 3:22 PM Oleksandr Andrushchenko
wrote:
On 11/15/18 5:49 PM, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
p(struct file *filp, struct vm_area_struct *vma)
With the above fixed,
Reviewed-by: Oleksandr Andrushchenko
p(struct file *filp, struct vm_area_struct *vma)
With the above fixed,
Reviewed-by: Oleksandr Andrushchenko
On 07/20/2018 05:08 PM, Boris Ostrovsky wrote:
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends
On 07/20/2018 05:08 PM, Boris Ostrovsky wrote:
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends
1 - 100 of 834 matches
Mail list logo
