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
e check.
>
> Cc: Oleksandr Andrushchenko
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/xen/xen_drm_front.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
> b/drivers/gpu/drm/xen/xen_drm_
On 2/3/19 5:42 PM, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleks
re's open fd(s)
> - The driver holds a ref on drm_device as long as it's bound to the
>struct device
>
> When both sides are done with drm_device, it is released.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/dr
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 6/14/19 11:35 PM, Daniel Vetter wrote:
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu
the if ladder and first check if the buffer is imported.
Fixes: b9068cde51ee ("drm/cma-helper: Add DRM_GEM_CMA_VMAP_DRIVER_OPS")
Cc: sta...@vger.kernel.org
Reported-by: "Li, Tingqian"
Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
--
On 6/30/19 9:18 AM, Sam Ravnborg wrote:
The drmP.h header is deprecated. Drop all uses.
Added includes/forwards to the header files and
then fixed fallout in the .c files.
Signed-off-by: Sam Ravnborg
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xenproject.org
---
The list of cc: was too
modified. Therefore make fb_funcs
constant to protect it from further modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 8/14/19 8:26 PM, Daniel Vetter wrote:
On Tue, Aug 13, 2019 at 10:32:00AM +0300, Oleksandr Andrushchenko wrote:
On 8/13/19 9:27 AM, Nishka Dasgupta wrote:
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
eference for us.
>
> Might as well take the real pointer ins't of complicated games that
> baffle.
>
> Signed-off-by: Daniel Vetter
> Cc: Oleksandr Andrushchenko
> Cc: xen-de...@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_fr
On 11/18/19 12:35 PM, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: Juergen
On 10/21/19 10:12 PM, Jason Gunthorpe wrote:
On Wed, Oct 16, 2019 at 06:35:15AM +, Oleksandr Andrushchenko wrote:
On 10/16/19 8:11 AM, Jürgen Groß wrote:
On 15.10.19 20:12, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents
uch
>> symbols so they are turned on implicitly when the user enables a kconfig
>> that needs them.
>>
>> Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
>>
>> Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UA
blank events explicitly.
>
> v5:
> * update comment
> v4:
> * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
Thank you for your work,
Reviewed-by: Oleksandr Andrushchenko
> ---
&
On 1/27/20 1:59 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 27.01.20 um 10:53 schrieb Oleksandr Andrushchenko:
>> Sorry for jumping in late
>>
>> On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
>>> The atomic helpers automatically send out fake VBLANK events if n
> disable automatic vblank events explictly.
>
> v4:
> * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 13 +++
patch here fixes that leak.
>
> Same for virtio, started leaking with
>
> commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a
> Author: Gerd Hoffmann
> Date: Tue Feb 11 14:58:04 2020 +0100
>
> drm/virtio: add drm_driver.release callback.
>
> Cc: Gerd Hoffmann
>
On 3/30/20 12:59, Ding Xiang wrote:
Fix a static code checker warning:
drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
warn: passing zero to 'PTR_ERR'
Signed-off-by: Ding Xiang
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 2
On 4/21/20 14:51, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if (IS_ERR_OR_NULL(xen_obj))
On 4/21/20 13:45, Dan Carpenter wrote:
> Hi Kernel Janitors,
Hi
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the
On 4/21/20 2:51 PM, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if
fix. It makes the API cleaner.
>
> Done via the following script:
>
> __from=drm_gem_object_put_unlocked
> __to=drm_gem_object_put
> for __file in $(git grep --name-only $__from); do
>sed -i "s/$__from/$__to/g" $__file;
> done
>
> Cc: Oleksandr Andrush
Hi,
On 8/20/20 2:56 AM, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
> frontend").
>
> The bot has tested the following trees: v5.8.1,
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 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
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:
_free_object_unlocked or any other name if this seems to be
too long,
but starting with xen_drm_front_ as the rest of exported functions?
With this,
Acked-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
> {
> struct xen_drm_front_drm_info *drm_info = obj->dev->dev_priv
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
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
---
drivers/gpu/drm/xen/xen_drm_front.c
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
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
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
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
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
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
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
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/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
On 5/21/21 12:09 PM, Daniel Vetter wrote:
> Goes through all the drivers and deletes the default hook since it's
> the default now.
>
> Signed-off-by: Daniel Vetter
Acked-by: Oleksandr Andrushchenko
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
> ---
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, 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
On 2/24/21 6:17 PM, Daniel Vetter wrote:
> On Wed, Feb 24, 2021 at 8:55 AM Oleksandr Andrushchenko
> wrote:
>> Hello, Jan!
>>
>> On 2/23/21 6:41 PM, Jan Beulich wrote:
>>> By having selected DRM_XEN, I was assuming I would build the frontend
>>> driv
the "depends on" to the other, real option, and "select"ing
> the dummy one.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Oleksandr Andrushchenko
> --- a/drivers/gpu/drm/xen/Kconfig
> +++ b/drivers/gpu/drm/xen/Kconfig
> @@ -1,15 +1,11 @@
> # SPDX-License-Ide
Hi, Juergen!
On 22.10.21 09:47, Juergen Gross wrote:
> Similar to the virtual frame buffer (vfb) the pv display driver is not
> essential for booting the system. Set the respective flag.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
> ---
> d
Hi, Bernard!
On 15.11.21 05:45, Bernard Zhao wrote:
> In function xen_drm_front_gem_import_sg_table, if in error branch,
> there maybe potential memleak if not call gem_free_pages_array.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 8 ++--
> 1 file
w being created by the helper macro
> DEFINE_DRM_GEM_FOPS().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front.c | 16 +---
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 108 +---
> drivers/g
return -ENODEV;
> +
> DRM_INFO("Creating %s\n", xen_drm_driver.desc);
>
> drm_info = kzalloc(sizeof(*drm_info), GFP_KERNEL);
With the commit message fixed:
Reviewed-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
hich triggers the WARNING.
>
> Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Oleksandr Andrushchenko
> ---
> This patch eliminates a WARNING which occurs during running any user space
> application over drm (weston, modetest, etc) using PV Display frontend
> in Xen guest (i
401 - 458 of 458 matches
Mail list logo
