it's due to this:
>
> commit dfb9f5cabfe31b8e936b725b5de8f787f7c18b0f
> Author: Haneen Mohammed
> Date: Tue Jul 24 19:31:05 2018 +0300
>
> drm/vkms: subclass CRTC state
>
> in 4.20-rc1. We aren't doing INIT_WORK() for the workqueue that is being
> flushed.
>
> Don't we need to do INIT_WORK() in vkms_atomic_crtc_reset() too?
Patch is in linux-next:
commit b30b61ff6b1dc37f276cf56a8328b80086a3ffca
Author: Tetsuo Handa
Date: Sat Jan 19 01:43:43 2019 +0900
drm/vkms: Fix flush_work() without INIT_WORK()
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Polish the kerneldoc a bit with suggestions from Randy.
Cc: Randy Dunlap
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: Ramalingam C
--
Greg, I don't need this in any of the topic branches, best if you
pick this one up into
d - vma->vm_start, vma->vm_page_prot))
> return -EAGAIN;
> vma->vm_page_prot = drm_dma_prot(map->type, vma);
> - /* fall through to _DRM_SHM */
> + /* fall through - to _DRM_SHM */
> case _DRM_SHM:
> vm
Polish the kerneldoc a bit with suggestions from Randy.
v2: Randy found another typo: s/compent/component/
Cc: Randy Dunlap
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: Ramalingam C
---
drivers/base/compone
On Mon, Feb 18, 2019 at 7:02 PM Gustavo A. R. Silva
wrote:
>
> Hi Daniel,
>
> On 2/18/19 2:57 AM, Daniel Vetter wrote:
> > On Fri, Feb 15, 2019 at 11:05:46AM -0600, Gustavo A. R. Silva wrote:
> >> In preparation to enabling -Wimplicit-fallthrough, mark switch
> >
15
and mei_hdcp will need.
--------
Daniel Vetter (3):
component: Add documentation
components: multiple components for a device
i915/snd_hdac: I915 subcomponent for the snd_hdac
Ramalingam C (5):
drm/i915: enum port definition is moved into i915_drm.h
to bring his code Mainline
> Maybe CK Hu can help here because driver is originally from him and he knows
> internals. Or maybe you can help here?
>
> i personally make my first steps as spare-time kernel-developer :)
There's a ton of in-kernel users of that function already,
> - mode->vsync_end, mode->vtotal,
> - mode->type, mode->flags);
> + DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
>
> if (is_dual_dsi && !IS_MASTER_DSI_LINK(id))
> return;
> diff
F config")
> > c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling
> > factor while calculating offsets in the physical address of framebuffer")
> > ce0c57576810 ("drm/fb_cma_helper: Implement fb_mmap callback")
> > cf67cc9a29ac ("drm/exynos: remove struct exynos_drm_display")
> > d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> > d56125afcbdf ("drm/exynos: update exynos_drm_framebuffer_init() for
> > multiple buffers")
> > e9fbdcb45a36 ("drm/exynos: fix possible infinite loop issue")
> >
> >
> > How should we proceed with this patch?
> >
> > --
> > Thanks,
> > Sasha
>
> Hi,
>
> I'm new to kernel development, so: what exactly I'm supposed to do in
> such case? Rebase my patch on top of older versions and then resend
> patches somewhere?
>
> Just checked the v3.18.131. Apparently code in question was not changed
> since then, so manual rebase would be trivial.
If you want to do that work of backporting to older kernels, then:
- grab latest point release of each such kernel you care about.
- cherry-pick the upstream commit with git cherry-pick -x (the -x is
required by stable kernel release rules)
- add a note at the bottom that this is the manual backport for $kernel_release
- submit to stable team
https://www.kernel.org/doc/html/v4.14/process/stable-kernel-rules.html#option-3
Cheers, Daniel
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, Jan 11, 2019 at 11:20:09AM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Thu, 2019-01-10 at 21:02 +0100, Daniel Vetter wrote:
> > On Thu, Jan 10, 2019 at 08:01:37PM +0100, Frank Wunderlich wrote:
> > > Hi Daniel,
> > >
> > > > > Would be good
On Fri, Jan 11, 2019 at 05:49:15PM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Fri, 2019-01-11 at 10:20 +0100, Daniel Vetter wrote:
> > On Fri, Jan 11, 2019 at 11:20:09AM +0800, CK Hu wrote:
> > > Hi, Daniel:
> > >
> > > On Thu, 2019-01-10 at 21:02 +0100, D
On Wed, Jan 09, 2019 at 10:53:54PM +0100, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 08:29:35PM +0100, Sam Ravnborg wrote:
> > drmP.h is an relic from the days when there was a single header file.
> > To enable the removal of drmP.h from all users drop include
>
On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
>
> Signed-off-by: Rob Clark
> ---
> Similar case to the issue that was fixed recently in drm/ast
Reviewed-by: Daniel Vetter
>
On Fri, Jan 11, 2019 at 11:06:20PM +0100, Daniel Vetter wrote:
> On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> > This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
> >
> > Signed-off-by: Rob Clark
> > ---
> > Simila
drm/i915: Skip the ERR_PTR error state
drm/i915: Unwind failure on pinning the gen7 ppgtt
Daniel Vetter (2):
Merge tag 'drm-misc-fixes-2019-01-10-1' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge tag 'drm-intel-fixes-2019-01-11' of
le()")
Cc: # v4.14+
Reviewed-by: Daniel Vetter
I'll let Gerd pick this one up, after some testing. Also adding Laurent.
-Daniel
> "crtc_funcs->disable" call would crash (resulting in suspend failure).
> Fix this by converting the suspend/resume functions to use the
>
On Wed, Aug 22, 2018 at 10:59:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 22, 2018 at 10:54:03AM +0200, Daniel Vetter wrote:
> > It was only used by the panic support in fbcon, which is now gone.
> > Remove this now dead code too.
> >
> > Cc: Greg Kroah-Hartman
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:
> > > >
iff --git a/drivers/gpu/drm/xen/xen_drm_front_drv.h
> b/drivers/gpu/drm/xen/xen_drm_front_drv.h
> new file mode 100644
> index ..aaa476535c13
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/xen_drm_front_drv.h
> @@ -0,0 +1,60 @@
> +/*
> + * Xen para-virtual DRM device
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2016-2018 EPAM Systems Inc.
> + *
> + * Author: Oleksandr Andrushchenko
> + */
> +
> +#ifndef __XEN_DRM_FRONT_DRV_H_
> +#define __XEN_DRM_FRONT_DRV_H_
> +
> +#include
> +
> +#include "xen_drm_front.h"
> +#include "xen_drm_front_cfg.h"
> +
> +struct xen_drm_front_drm_pipeline {
> + struct xen_drm_front_drm_info *drm_info;
> +
> + int index;
> +};
> +
> +struct xen_drm_front_drm_info {
> + struct xen_drm_front_info *front_info;
> + struct xen_drm_front_ops *front_ops;
> + struct drm_device *drm_dev;
> + struct xen_drm_front_cfg *cfg;
> +};
> +
> +static inline uint64_t xen_drm_front_fb_to_cookie(
> + struct drm_framebuffer *fb)
> +{
> + return (uint64_t)fb;
> +}
> +
> +static inline uint64_t xen_drm_front_dbuf_to_cookie(
> + struct drm_gem_object *gem_obj)
> +{
> + return (uint64_t)gem_obj;
> +}
> +
> +int xen_drm_front_drv_probe(struct platform_device *pdev,
> + struct xen_drm_front_ops *front_ops);
> +
> +int xen_drm_front_drv_remove(struct platform_device *pdev);
> +
> +bool xen_drm_front_drv_is_used(struct platform_device *pdev);
> +
> +#endif /* __XEN_DRM_FRONT_DRV_H_ */
> +
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
&display_funcs, formats, format_count,
> + NULL, &pipeline->conn);
> +}
> +
> +int xen_drm_front_kms_init(struct xen_drm_front_drm_info *drm_info)
> +{
> + struct drm_device *dev = drm_info->drm_dev;
> + int i, ret;
> +
> + drm_mode_config_init(dev);
> +
> + dev->mode_config.min_width = 0;
> + dev->mode_config.min_height = 0;
> + dev->mode_config.max_width = 4095;
> + dev->mode_config.max_height = 2047;
> + dev->mode_config.funcs = &mode_config_funcs;
> +
> + for (i = 0; i < drm_info->cfg->num_connectors; i++) {
> + struct xen_drm_front_cfg_connector *cfg =
> + &drm_info->cfg->connectors[i];
> + struct xen_drm_front_drm_pipeline *pipeline =
> + &drm_info->pipeline[i];
> +
> + ret = display_pipe_init(drm_info, i, cfg, pipeline);
> + if (ret) {
> + drm_mode_config_cleanup(dev);
> + return ret;
> + }
> + }
> +
> + drm_mode_config_reset(dev);
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.h
> b/drivers/gpu/drm/xen/xen_drm_front_kms.h
> new file mode 100644
> index ..65a50033bb9b
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.h
> @@ -0,0 +1,30 @@
> +/*
> + * Xen para-virtual DRM device
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2016-2018 EPAM Systems Inc.
> + *
> + * Author: Oleksandr Andrushchenko
> + */
> +
> +#ifndef __XEN_DRM_FRONT_KMS_H_
> +#define __XEN_DRM_FRONT_KMS_H_
> +
> +#include "xen_drm_front_drv.h"
> +
> +int xen_drm_front_kms_init(struct xen_drm_front_drm_info *drm_info);
> +
> +void xen_drm_front_kms_on_frame_done(
> + struct xen_drm_front_drm_pipeline *pipeline,
> + uint64_t fb_cookie);
> +
> +#endif /* __XEN_DRM_FRONT_KMS_H_ */
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drv_deinit(front_info);
> xen_drm_front_evtchnl_free_all(front_info);
> + dbuf_free_all(&front_info->dbuf_list);
> }
>
> static int backend_on_initwait(struct xen_drm_front_info *front_info)
> @@ -310,6 +625,8 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
>
> front_info->xb_dev = xb_dev;
> spin_lock_init(&front_info->io_lock);
> + mutex_init(&front_info->req_io_lock);
> + INIT_LIST_HEAD(&front_info->dbuf_list);
> front_info->drm_pdrv_registered = false;
> dev_set_drvdata(&xb_dev->dev, front_info);
> return xenbus_switch_state(xb_dev, XenbusStateInitialising);
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
> b/drivers/gpu/drm/xen/xen_drm_front.h
> index c6f52c892434..db32d00145d1 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.h
> +++ b/drivers/gpu/drm/xen/xen_drm_front.h
> @@ -137,6 +137,8 @@ struct xen_drm_front_info {
> struct xenbus_device *xb_dev;
> /* to protect data between backend IO code and interrupt handler */
> spinlock_t io_lock;
> + /* serializer for backend IO: request/response */
> + struct mutex req_io_lock;
> bool drm_pdrv_registered;
> /* virtual DRM platform device */
> struct platform_device *drm_pdev;
> @@ -144,6 +146,9 @@ struct xen_drm_front_info {
> int num_evt_pairs;
> struct xen_drm_front_evtchnl_pair *evt_pairs;
> struct xen_drm_front_cfg cfg;
> +
> + /* display buffers */
> + struct list_head dbuf_list;
> };
>
> #endif /* __XEN_DRM_FRONT_H_ */
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2016-2018 EPAM Systems Inc.
> + *
> + * Author: Oleksandr Andrushchenko
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xen_drm_front.h"
> +#include "xen_drm_front_drv.h"
> +#include "xen_drm_front_gem.h"
> +
> +static struct drm_gem_object *gem_import_sg_table(struct drm_device *dev,
> + struct dma_buf_attachment *attach, struct sg_table *sgt)
> +{
> + struct xen_drm_front_drm_info *drm_info = dev->dev_private;
> + struct drm_gem_object *gem_obj;
> + struct drm_gem_cma_object *cma_obj;
> + int ret;
> +
> + gem_obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> + if (IS_ERR_OR_NULL(gem_obj))
> + return gem_obj;
> +
> + cma_obj = to_drm_gem_cma_obj(gem_obj);
> +
> + ret = drm_info->front_ops->dbuf_create_from_sgt(
> + drm_info->front_info,
> + xen_drm_front_dbuf_to_cookie(gem_obj),
> + 0, 0, 0, gem_obj->size,
> + drm_gem_cma_prime_get_sg_table(gem_obj));
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + DRM_DEBUG("Imported CMA buffer of size %zu\n", gem_obj->size);
> +
> + return gem_obj;
> +}
> +
> +static int gem_dumb_create(struct drm_file *filp, struct drm_device *dev,
> + struct drm_mode_create_dumb *args)
> +{
> + struct xen_drm_front_drm_info *drm_info = dev->dev_private;
> +
> + if (drm_info->cfg->be_alloc) {
> + /* This use-case is not yet supported and probably won't be */
> + DRM_ERROR("Backend allocated buffers and CMA helpers are not
> supported at the same time\n");
> + return -EINVAL;
> + }
> +
> + return drm_gem_cma_dumb_create(filp, dev, args);
> +}
> +
> +static struct page **gem_get_pages(struct drm_gem_object *gem_obj)
> +{
> + return NULL;
> +}
> +
> +static const struct xen_drm_front_gem_ops xen_drm_front_gem_cma_ops = {
> + .free_object_unlocked = drm_gem_cma_free_object,
> + .prime_get_sg_table= drm_gem_cma_prime_get_sg_table,
> + .prime_import_sg_table = gem_import_sg_table,
> +
> + .prime_vmap= drm_gem_cma_prime_vmap,
> + .prime_vunmap = drm_gem_cma_prime_vunmap,
> + .prime_mmap= drm_gem_cma_prime_mmap,
> +
> + .dumb_create = gem_dumb_create,
> +
> + .mmap = drm_gem_cma_mmap,
> +
> + .get_pages = gem_get_pages,
> +};
Again quite a midlayer you have here. Please inline this to avoid
confusion for other people (since it looks like you only have 1
implementation).
> +
> +const struct xen_drm_front_gem_ops *xen_drm_front_gem_get_ops(void)
> +{
> + return &xen_drm_front_gem_cma_ops;
> +}
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rivers do).
-Daniel
>
> Balloon driver extension, which is needed for contiguous/DMA
> buffers, will be to provide new *kernel API*, no UAPI is needed.
>
> > Wei.
> Thank you,
> Oleksandr
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
erge with 4.17-rcX soon?
For backmerge requests you need to cc/ping the drm-misc maintainers.
Adding them. I think the hold-up also was that Dave was on vacations
still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Apr 20, 2018 at 04:42:48PM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
> >> This driver will be used to support Mesa on the Broadcom 7268 and 7278
> >> platforms.
> >>
> &g
> > + }
> > }
> >
> > int udl_fbdev_init(struct drm_device *dev)
> > --
> > 2.17.0.484.g0c8726318c-goog
> >
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 23, 2018 at 05:46:08PM -0700, Eric Anholt wrote:
> Some drivers leave these unimplemented, so don't make them have
> unimplemented stubs.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_prime.c | 8 ++--
> 1
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 ;)
> >
> >
On Fri, Mar 16, 2018 at 05:29:02AM -0700, Joe Perches wrote:
> On Fri, 2018-03-16 at 08:41 +0100, Daniel Vetter wrote:
> > On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
> > > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> > > argum
l+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20180319050530.GA25589%40seema-Inspiron-15-3567.
> For more options, visit https://groups.google.com/d/optout.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+
> +#define DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, ...)
> \
> + _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_DRIVER, \
> + fmt, ##__VA_ARGS__)
> +#define DRM_DEBUG_DRIVER_RATELIMITED(fmt, ...)
> \
> + DRM_DEV_DEBUG_DRIVER_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> +
> +#define DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, ...) \
> + _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_KMS, \
> + fmt, ##__VA_ARGS__)
> +#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) \
> + DRM_DEV_DEBUG_KMS_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> +
> +#define DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, ...)
> \
> + _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_PRIME,\
> + fmt, ##__VA_ARGS__)
> +#define DRM_DEBUG_PRIME_RATELIMITED(fmt, ...)
> \
> + DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
>
> #endif /* DRM_PRINT_H_ */
> --
> 2.15.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 bel
drm_bridge_remove(bridge);
> hdmi->drm_connector = NULL;
> return -EINVAL;
> }
> --
> 2.11.0
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, May 03, 2018 at 01:55:03PM +0300, Ville Syrjälä wrote:
> On Thu, May 03, 2018 at 11:24:59AM +0200, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:19:32AM +0530, Satendra Singh Thakur wrote:
> > > In the func drm_atomic_set_crtc_for_plane, with the current code,
&g
Jani spotted this when reviewing my earlier patch to remove the driver
internal usage of this field in
commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
Author: Daniel Vetter
Date: Wed Apr 25 19:42:52 2018 +0200
backlight: Nuke BL_CORE_DRIVER1
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> > We've broken that assumption in i915 years ago. Not struct page backed
> > gpu memory is very real.
> >
> > Of course we'll
> > On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> > > > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
> > > > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
> > > > 3.2 Backend exports dma-buf to xen-front
> &g
t; as it is not a Xen specific driver?
>
> That would be my preference if feasible, simply because it can be
> reused by other use-cases that need to create dma-bufs in user-space.
>
> In any case I just knew about dma-bufs this morning, there might be
> things that I'm missing.
See my other reply, I really don't want a generic userspace memory ->
dma-buf thing, it doesn't work. Having a xen-specific grant references <->
dma-buf conversion thing (and I'm honestly still not sure whether the
dma-buf -> grant renferences is a good idea) seems much more reasonable to
me.
Imo simplest way forward would be to start out with a grant refs ->
dma-buf ioctl, and see how far that gets us.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 17, 2018 at 08:08:27PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:00, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:27PM +0300, Dmitry Osipenko wrote:
> >> Colorkey'ing allows to draw on top of overlapping planes, like for example
> >>
On Tue, Apr 17, 2018 at 08:31:11PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:01, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:28PM +0300, Dmitry Osipenko wrote:
> >> This new property allows userspace to apply custom color conversion
> >> coefficients pe
t. Since the buggy code uses the same expression for page frame and
offset I don't think there's a security bug. You might still want to cc:
stable (since without you defacto can't ever use this feature).
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_io
not quite clear to me how manual update displays work with
> DRM...
>
> As far as I see, we have essentially two cases: 1) single buffering,
> where the userspace must set an area in the fb dirty, which then
> triggers the update, 2) multi buffering, which doesn't need fb dirty,
> but just a page flip which triggers the update.
>
> In the 2) case (which I think is the optimal case which all the modern
> apps should use), there's no need for delayed work or any work, and the
> code flow should be very similar to the auto-update model.
>
> Also, as Daniel mentioned in "drm/omapdrm: Nuke
> omap_framebuffer_get_next_connector()" thread, the dirtying mechanism in
> the series is not valid.
>
> Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
turn 0;
> -}
> -
> static void qxl_conn_destroy(struct drm_connector *connector)
> {
> struct qxl_output *qxl_output =
> @@ -1081,7 +1032,6 @@ static const struct drm_connector_funcs
> qxl_connector_funcs = {
> .dpms = drm_helper_connector_dpms,
> .detect = qx
ly changes the
> GEM behavior, so I've forked off to a new driver.
>
> Signed-off-by: Eric Anholt
Read through the entire thing, ignored the hw details, but dropped a few
comments all over. With those addressed one way or another this has my
Acked-by: Daniel Vetter
Can I
f). But that only has benefits if we
really roll it out everywhere, in all the subsystems and drivers, since if
we don't we've made the struct pages ** <-> sgt conversion fun only worse
by adding a 3 representation of gpu buffer object backing storage.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
piod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> > + gpiod_get_direction(pb->enable_gpio) != 0)
> > gpiod_direction_output(pb->enable_gpio, 1);
> >
> > pb->power_supply = devm_regulator_get(&pdev->dev, "power");
> > --
> > 2.11.0
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:
> On 04/13/2018 06:37 PM, Daniel Vetter wrote:
> > On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/10/2018 08:26 PM, Dongwon Kim wrote:
> > > > On Tue, Ap
gt; + drm_dev_put(drm);
>
> return 0;
> }
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 16, 2018 at 10:22 AM, Oleksandr Andrushchenko
wrote:
> On 04/16/2018 10:43 AM, Daniel Vetter wrote:
>>
>> On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:
>>>
>>> On 04/13/2018 06:37 PM, Daniel Vetter wrote:
>>>>
2018 at 12:14 PM, Oleksandr Andrushchenko
wrote:
> On 04/16/2018 12:32 PM, Daniel Vetter wrote:
>>
>> On Mon, Apr 16, 2018 at 10:22 AM, Oleksandr Andrushchenko
>> wrote:
>>>
>>> On 04/16/2018 10:43 AM, Daniel Vetter wrote:
>>>>
>>>>
On Mon, Apr 16, 2018 at 2:39 PM, Christoph Hellwig wrote:
> On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote:
>> I did not mean you should dma_map_sg/page. I just meant that using
>> dma_map_resource to fill only the dma address part of the sg table seems
>>
t; > >
> > > Documentation/gpu/drivers.rst | 1 +
> > > Documentation/gpu/xen-zcopy.rst | 32 +
> > > drivers/gpu/drm/xen/Kconfig | 25 +
> > > drivers/gpu/drm/xen/Makefile| 5 +
> > > drivers/gpu/drm/xen/xen_drm_zcopy.c | 880
> > >
> > > drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c | 154 +
> > > drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h | 38 ++
> > > include/uapi/drm/xen_zcopy_drm.h| 129
> > > 8 files changed, 1264 insertions(+)
> > > create mode 100644 Documentation/gpu/xen-zcopy.rst
> > > create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy.c
> > > create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c
> > > create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h
> > > create mode 100644 include/uapi/drm/xen_zcopy_drm.h
> > >
> > [1]
> > https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
onst struct drm_plane_funcs tegra_plane_funcs = {
> .atomic_duplicate_state = tegra_plane_atomic_duplicate_state,
> .atomic_destroy_state = tegra_plane_atomic_destroy_state,
> .format_mod_supported = tegra_plane_format_mod_supported,
> + .atomic_set_property = tegra_plane_set_property,
> + .atomic_get_property = tegra_plane_get_property,
> };
>
> int tegra_plane_state_add(struct tegra_plane *plane,
> diff --git a/drivers/gpu/drm/tegra/plane.h b/drivers/gpu/drm/tegra/plane.h
> index 7360ddfafee8..dafecea73b29 100644
> --- a/drivers/gpu/drm/tegra/plane.h
> +++ b/drivers/gpu/drm/tegra/plane.h
> @@ -19,6 +19,11 @@ struct tegra_plane {
> struct tegra_dc *dc;
> unsigned int offset;
> unsigned int index;
> +
> + struct {
> + struct drm_property *color_key0;
> + struct drm_property *color_key1;
> + } props;
> };
>
> struct tegra_cursor {
> @@ -49,10 +54,12 @@ struct tegra_plane_state {
> /* used for legacy blending support only */
> struct tegra_plane_legacy_blending_state blending[2];
> bool opaque;
> + bool ckey0_enabled;
> + bool ckey1_enabled;
> };
>
> static inline struct tegra_plane_state *
> -to_tegra_plane_state(struct drm_plane_state *state)
> +to_tegra_plane_state(const struct drm_plane_state *state)
> {
> if (state)
> return container_of(state, struct tegra_plane_state, base);
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_key0;
> struct drm_property *color_key1;
> + struct drm_property *csc_blob;
> } props;
> +
> + struct drm_property_blob *csc_default;
> };
>
> struct tegra_cursor {
> @@ -51,6 +54,8 @@ struct tegra_plane_state {
> u32 format;
> u32 swap;
>
> + struct drm_property_blob *csc_blob;
> +
> /* used for legacy blending support only */
> struct tegra_plane_legacy_blending_state blending[2];
> bool opaque;
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index a5da44209a68..a3054ea7b222 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -29,6 +29,17 @@
> extern "C" {
> #endif
>
> +struct drm_tegra_plane_csc_blob {
> + __u32 yof;
> + __u32 kyrgb;
> + __u32 kur;
> + __u32 kvr;
> + __u32 kug;
> + __u32 kvg;
> + __u32 kub;
> + __u32 kvb;
> +};
> +
> #define DRM_TEGRA_GEM_CREATE_TILED (1 << 0)
> #define DRM_TEGRA_GEM_CREATE_BOTTOM_UP (1 << 1)
> #define DRM_TEGRA_GEM_CREATE_SCATTERED (1 << 2)
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
to require guest-contig
memory for xen buffer sharing using grants.
With the commit message improved:
Acked-by: Daniel Vetter
>
> Signed-off-by: Oleksandr Andrushchenko
> Suggested-by: Daniel Vetter
> ---
> Documentation/gpu/xen-front.rst | 12
>
d probably change the other comments too.
Also would be good to again point at
drm_plane_create_zpos_immutable_property() and related stuff.
> + uint16_t pixel_blend_mode;
> +
> /* Plane rotation */
> unsigned int rotation;
>
> @@ -459,6 +464,7 @@ enum drm_plane_type {
> * @state: current atomic state for this plane
> * @zpos_property: zpos property for this plane
> * @rotation_property: rotation property for this plane
> + * @blend_mode_property: blend mode property for this plane
> * @helper_private: mid-layer private data
> */
> struct drm_plane {
> @@ -506,6 +512,7 @@ struct drm_plane {
>
> struct drm_property *zpos_property;
> struct drm_property *rotation_property;
> + struct drm_property *blend_mode_property;
> };
>
> #define obj_to_plane(x) container_of(x, struct drm_plane, base)
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
errible
> idea I'm willing to at least give it a go on a trial basis once I'm back
> home.
Since Stephen merges all -fixes branches first, before merging all the
-next branches, he already generates that as part of linux-next. All
he'd need to do is push that intermediate sta
On Wed, Dec 20, 2017 at 2:14 AM, Byungchul Park wrote:
> On 12/19/2017 6:59 PM, Daniel Vetter wrote:
>>
>> On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:
>>>
>>> On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
>>>>
>>
only use
it as a cursor. That way desktops get a good hint for what the cursor
plane should be, everyone else can still use all the planes.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
ot;, fmt, \
> ##args)
> -#define DRM_DEBUG_VBL(fmt, ...) \
> - drm_printk(KERN_DEBUG, DRM_UT_VBL, fmt, ##__VA_ARGS__)
> +#define DRM_DEBUG_VBL(fmt, ...)
> \
> + drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_LEASE(fmt, ...)\
> - drm_printk(KERN_DEBUG, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> + drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__)
>
> #define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, level, fmt, args...) \
> ({ \
> --
> 2.15.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Mar 13, 2018 at 06:21:05PM +0200, 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], capable of running as a We
ds/platforms. External displays would be a different
story. I guess you can count that as an
Acked-by: Daniel Vetter
on the overall thing, but pls get bridge folks to review this too.
-Daniel
> ---
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48
> ++
On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> On 2018-05-03 11:06, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >> The more natural approach would perhaps be to add an drm_bridge_add,
> >> but there are sever
tilcdc/tilcdc_crtc.c| 60 +-
> 15 files changed, 280 insertions(+), 390 deletions(-)
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; > index b656e505d11e..804189c63a4c 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> > * @list: to keep track of all added bridges
> > * @timings: the timing specification for the bridge, if any (may
> > * be NULL)
> > + * @link: drm consumer <-> bridge supplier
> > * @funcs: control functions
> > * @driver_private: pointer to the bridge driver's internal context
> > */
> > @@ -271,6 +272,7 @@ struct drm_bridge {
> > struct drm_bridge *next;
> > struct list_head list;
> > const struct drm_bridge_timings *timings;
> > + struct device_link *link;
> >
> > const struct drm_bridge_funcs *funcs;
> > void *driver_private;
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
> drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> drivers/gpu/drm/sti/sti_hda.c | 1 +
> drivers/gpu/drm/sti/sti_hdmi.c | 1 +
> include/drm/drm_bridge.h | 8 +++
> 30 files changed, 57 insertions(+), 36 deletions(-)
>
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, May 07, 2018 at 03:59:04PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:39, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>> On Wed, May 02, 2018 at 09:40:23AM +0200,
On Mon, May 07, 2018 at 04:24:43PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:59, Peter Rosin wrote:
> > On 2018-05-07 15:39, Daniel Vetter wrote:
> >> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >>> On 2018-05-03 11:06, Daniel Vetter wrote:
>
anwhile ...
-Daniel
>
> > I suggest assigning odev here to NULL or to master drm device itself.
>
> I'd rather not use NULL, since it is nice to be able to rely on the
> .odev being there, and WARN if it isn't.
>
> Cheers,
> Peter
>
> > Best regards,
> > J
break;
>> default:
>> WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", ret);
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>> break;
>> }
>> - return ret;
>> + return retval;
>> }
>>
>> static void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
>> --
>> 1.9.1
>>
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[mailto:nicsta...@gmail.com]
> > > Sent: Monday, December 05, 2016 3:30 PM
> > > To: Daniel Vetter
> > > Cc: Deucher, Alexander; Koenig, Christian; Michel Dänzer; linux-
> > > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; Nicolai Stange
> > > S
> ++
> >> 2 files changed, 34 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> >
> > Applied, thanks.
> Wait, it is RFC, not pass the test.
Well 2 months of silence, it
d
expose, but happy to change if folks object.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Dec 06, 2016 at 08:52:41AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 02:17:52PM +0100, Daniel Vetter wrote:
> > Hi Peter,
> >
> > On Tue, Nov 29, 2016 at 10:23:14AM +0100, Daniel Vetter wrote:
> > > We already had a super-short blurb,
flict since there's some in-flight patches to
document the new B: tag a bit better. Anyway:
Reviewed-by: Daniel Vetter
>
>
> Mauro Carvalho Chehab (2):
> MAINTAINERS: convert first part to ReST markup
> MAINTAINERS: add it to the admin-guide
>
> Documentation/
erting outdated docs is harmful. Motived
by comments Peter did in our discussion.
v3: Make the explanations around fixed-width quoting more concise
(Jani).
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Christoph Hellwig
Cc: Peter Zijlstra
Cc: Jani Nikula
Cc: Mauro Carvalho Chehab
Signed
ke a bug workflow issue between drm/i915 and Mesa to be ironed
> > out.
>
> Indeed. I'd rather have the information provided in a bug report to
> actually solve it. I hope having access to the shader program will
> make many more reports useful.
>
> I am also happy to see that there's now a sunset to the GPU hang message.
The other option is that mesa folks don't want error states that we triage
to mesa. We could definitely update the process in that area.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
phan
> F: Documentation/fb/
> F: drivers/video/
> F: include/video/
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
(when atomic landed) we merge new drivers at
a rate of 2-3 per kernel release, and those new drivers get ever simpler
and smaller thanks to all this work.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter wrote:
> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> >> >
rivers and everything in
a friendly and constructive fashion. I want to be part of a great
community, this wasnt :(
/me out and off for a walk
Thanks, Daniel
On Thu, Dec 08, 2016 at 03:02:10PM +0100, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
&g
xplicit/manual upload", for like
small i2c/spi panels (and conceptually also usb, even though there bw and
panel size are a bit scaled up). We've gained some really nice helpers for
this this year, and there's 3 drivers in-flight to make use of it. But
since that's right now just a hobbyist effort it's moving a bit slower
(and I was mistaken a few weeks back where I assumed that one of them
landed already).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_info.lfb_base + screen_info.lfb_size;
> - dev = &vgadev->pdev->dev;
>
> /* Does firmware framebuffer belong to us? */
> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> --
> 2.9.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
implementations, where memory is
allocated with malloc, and then mapped/moved into vram/gpu address
space through some magic, but still visible on both the cpu and gpu
side in some form. Special device to allocate memory, and not being
able to migrate stuff around sound like misfeatures from that pov.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch
wrote:
>
> On 2016-11-22 03:10 PM, Daniel Vetter wrote:
>>
>> On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch
>>> wrote
On Tue, Nov 22, 2016 at 01:21:03PM -0800, Dan Williams wrote:
> On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote:
> > On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch
> > wrote:
> >>
> >> On 2016-11-22 03:10 PM, Daniel Vetter wrote:
> >>&g
roblem though, that it must be called
> from
> process context.
>
> Daniel, why do we have an API the is clearly related to interrupt handling
> but
> requires the caller to implement a workqueue ?
Because in general you need that workqueue anyway, and up to now there was
no driv
ging/xgifb/XGI_main.h
> delete mode 100644 drivers/staging/xgifb/XGI_main_26.c
> delete mode 100644 drivers/staging/xgifb/XGIfb.h
> delete mode 100644 drivers/staging/xgifb/vb_def.h
> delete mode 100644 drivers/staging/xgifb/vb_init.c
> delete mode 100644 drivers/staging/xgifb/vb_ini
On Wed, Nov 23, 2016 at 9:25 AM, Geert Uytterhoeven
wrote:
> Hi Daniel,
>
> On Wed, Nov 23, 2016 at 9:19 AM, Daniel Vetter wrote:
>> On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
>>> Since the fbdev framework is in maintenance mode and all new display dr
uot;drm: move allocation out of
> > > drm_get_format_name())
> > > Cc: Eric Engestrom
> > > Cc: Rob Clark
> > > Cc: Jani Nikula
> > > Cc: Daniel Vetter
> > >
> > > Signed-off-by: Liviu Dudau
> > > ---
> > > I still t
-by: Nicolai Hähnle
Yeah, when the owning ctx changes we need to wake up all waiters, to make
sure we catch all (new) deadlock scenarios. And I tried poking at your
example, and I think it's solid and can't be minimized any further. I
don't have much clue on mutex.c code itself, b
> > Reviewed-by: Christian König (v1)
> > Signed-off-by: Nicolai Hähnle
>
> Completely and utterly fails to apply; I think this patch is based on
> code prior to the mutex rewrite.
>
> Please rebase on tip/locking/core.
>
> Also, is this a regression, or has this been a 'feature' of the ww_mutex
> code from early on?
Sorry forgot to mention that, but I checked. Seems to have been broken
since day 1, at least looking at the original code the wake-single-waiter
stuff is as old as the mutex code added in 2006.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Nov 23, 2016 at 02:08:48PM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:00:46PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 23, 2016 at 12:25:22PM +0100, Nicolai Hähnle wrote:
> > > From: Nicolai Hähnle
> > >
> > > Fix a race condition inv
ad 1 would get woken, and would be able to take the lock, except when
thread 0 successfully raced it and stole the lock. And anyone else racing
in with later timestamps would also immediately back off, ensuring
fairness.
Without thinking it through in detail this is a PI issue, except that we
replace
/
I guess we could create a small fake acquire_ctx for single-lock
paths. That way callers still don't need to deal with having an
explicit ctx, but we can assume the timestamp (for ensuring fairness)
is available for all cases. Otherwise there's indeed a problem with
correctly (we
On Wed, Jan 04, 2017 at 02:24:51PM -0800, Randy Dunlap wrote:
> On 01/04/17 11:29, Jani Nikula wrote:
> > On Wed, 04 Jan 2017, Daniel Vetter wrote:
> >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> >>> From: Randy Dunlap
> >>>
>
; ___________
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-CEA mode/edid for chamelium, problem solved? We want
to do that anyway for HDMI, where you really have to do the limited range
dance to make stuff display correctly.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
assert_spin_locked(&crc->lock);
> - return CIRC_CNT(crc->head, crc->tail, DRM_CRC_ENTRIES_NR);
> -}
> -
> /*
> * 1 frame field of 10 chars plus a number of CRC fields of 10 chars each,
> space
> * separated, with a newline at the end and null-terminated.
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
2201 - 2300 of 3914 matches
Mail list logo
