7;s tree past
few years ...
Greg, should we maybe add a MAINTAINERS entry that matches on all
things console? With tty/vt you definitely have the other side of that
coin already :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jul 31, 2020 at 6:47 PM Melissa Wen wrote:
>
> On 07/31, Sidong Yang wrote:
> > On Fri, Jul 31, 2020 at 11:08:34AM +0200, dan...@ffwll.ch wrote:
> > > On Thu, Jul 30, 2020 at 07:09:25AM -0300, Melissa Wen wrote:
> > > > On 07/29, Daniel Vetter wrote:
>
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
> > struct drm_encoder *encoder);
> >
> > +#if defined(CONFIG_OF)
> > +struct drm_connector *
> > +of_drm_find_connector(struct drm_device *dev, const struct device_node
> > *np);
> > +#else
> > +static inline struct drm_connector *
> > +of_drm_find_connector(struct drm_device *dev, const struct device_node *np)
> > +{
> > + return ERR_PTR(-ENODEV);
> > +}
> > +#endif
> > +
> > /**
> >* drm_for_each_connector_iter - connector_list iterator macro
> >* @connector: &struct drm_connector pointer used as cursor
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; dma-fence objects.
>
> Signed-off-by: Ofir Bitton
> Cc: Greg Kroah-Hartman
> Cc: Daniel Vetter
> Reviewed-by: Oded Gabbay
> Signed-off-by: Oded Gabbay
Are you sure you need kfree_rcu for hl_fence? That was a requirement
from dma_fence, because we do _tons_ of rcu protect
On Thu, Jul 30, 2020 at 1:27 PM Tetsuo Handa
wrote:
>
> On 2020/07/30 20:16, Daniel Vetter wrote:
> > Patch looks good, except ... does this compile? fbcon_update_vcs is
> > defined in fbcon.h, and that doesn't seem to be included here ...
> > Maybe what we want is a
tes
> old_{rows,row_size} values which were saved before calling resize_screen().
>
> Daniel Vetter explained that resize_screen() should not recurse into
> fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set
> when calling resize_screen().
>
> Instead of masking
On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen wrote:
>
> Melissa Wen
>
> On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote:
> >
> > On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen wrote:
> > >
> > > On 07/25, Daniel Vetter wrote:
> > > &
n-ABI */
> };
>
> +/**
> + * This structure describes an array of drm_syncobj and associated points for
> + * timeline variants of drm_syncobj. It is invalid to append this structure
> to
> + * the execbuf if I915_EXEC_FENCE_ARRAY is set.
> + */
> +struct drm_i915_gem_execbu
1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index a8c47aecd342..0047da06041f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdg
but also from the vc side. To avoid the
above recursion problems the code is using FBINFO_MISC_USEREVENT, and
should only set that from fb_ioctl entry points. That's all fairly
fragile, so I've done a bit of reworking, e.g.
commit de29ae5c092bd9a5360cfabf174b0f783248d278
Author: Daniel
; > > > module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms,
> > > > uint, 0444);
> > > > -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default:
> > > > 4)");
> > > > +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec
> > > > (default: 4)");
> > > >
> > > > /* Link configuration registers */
> > > > #define ZYNQMP_DP_LINK_BW_SET0x0
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
< 4)
> +#define BIT_DPU_LAY_FORMAT_YUV420_3PLANE (0x02 << 4)
> +#define BIT_DPU_LAY_FORMAT_ARGB888
ocess. I think it's a great change.
Same here, I think this is excellent.
I do think the big masses of contributors have fairly different pain
points and issues from what makes maintainer's lifes hard, so for the
imo very unlikely outcome that this will shift the TAB to be one-sided
repr
dsi_ctrl_r1p0_ppi.c
> create mode 100644 drivers/gpu/drm/sprd/dsi/core/dsi_ctrl_r1p0_ppi.h
> create mode 100644 drivers/gpu/drm/sprd/dsi/sprd_dsi_api.c
> create mode 100644 drivers/gpu/drm/sprd/dsi/sprd_dsi_api.h
> create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.c
> create mode
auto").
Hm dim (our scripting) should be checking for this already, I've added
that after the last big round of malformed Fixes lines we've had ...
Dave, overuse of dim -f in your history?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
>
> On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
>
> > On Mon, Jul 27, 2020 at 9:28 PM Christian König
> > wrote:
> > >
> > > Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:
> > >
On Mon, Jul 27, 2020 at 10:29 PM Daniel Vetter wrote:
>
> On Mon, Jul 27, 2020 at 9:28 PM Christian König
> wrote:
> >
> > Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:
> > > On 2020-07-27 9:39 a.m., Christian König wrote:
> > >> Am 27.07.20 um 07
m_private_objs-1;
> >>>
> >>> -new_dm_state->context = old_dm_state->context;
> >>> +dm_atomic_destroy_state(obj,
> >>> +state->private_objs[i].state);
> >>> +
> >>> +/* If i is not at the end of the array then the
> >>> + * last element needs to be moved to where i was
> >>> + * before the array can safely be truncated.
> >>> + */
> >>> +if (i != j)
> >>> +state->private_objs[i] =
> >>> +state->private_objs[j];
> >>>
> >>> -if (old_dm_state->context)
> >>> -dc_retain_state(old_dm_state->context);
> >>> +state->private_objs[j].ptr = NULL;
> >>> +state->private_objs[j].state = NULL;
> >>> +state->private_objs[j].old_state = NULL;
> >>> +state->private_objs[j].new_state = NULL;
> >>> +
> >>> +state->num_private_objs = j;
> >>> +break;
> >>> +}
> >>> }
> >>> }
> >>>
> >>> --
> >>> 2.27.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
state.period = NSEC_PER_SEC/fps;
> > +
> > + state.enabled = true;
> > + state.duty_cycle = state.period/2;
> > +
> > + ret = pwm_apply_state(par->extcomin_pwm, &state);
> > + if (ret)
> > + dev_warn(dev, "failed to apply EXTCOMIN pwm
> > state: %d\n", ret);
> > + }
> > + } else {
> > + par->extcomin_pwm = NULL;
> > + }
> > +
> > + if (par->disp)
> > + gpiod_set_value_cansleep(par->disp, 1);
> > +
> > + /* spi test by clearing the display */
> > + par->spi_buf[0] = SMEMLCD_ALL_CLEAR;
> > + par->spi_buf[1] = SMEMLCD_DUMMY_DATA;
> > + ret = spi_write(spi, &(par->spi_buf[0]), 2);
> > + if (ret < 0){
> > + dev_err(dev, "Couldn't send SPI command\n");
> > + goto disable_hw;
> > + }
> > +
> > + ret = register_framebuffer(info);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to register framebuffer\n");
> > + goto disable_hw;
> > + }
> > +
> > + dev_info(dev, "fb%d: %s framebuffer device registered, using %d bytes
> > of video memory\n", info->node, info->fix.id, vmem_size);
> > +
> > + if (!par->extmode)
> > + schedule_delayed_work(&par->d_work, smemlcd_defio->delay);
> > +
> > + return 0;
> > +
> > +disable_hw:
> > + if (par->disp)
> > + gpiod_set_value_cansleep(par->disp, 0);
> > + if (par->extcomin_pwm) {
> > + pwm_disable(par->extcomin_pwm);
> > + pwm_put(par->extcomin_pwm);
> > + }
> > + fb_deferred_io_cleanup(info);
> > +free_vmem:
> > + kfree(vmem);
> > +free_spi_buf:
> > + kfree(par->spi_buf);
> > +free_fb:
> > + cancel_delayed_work_sync(&par->d_work);
> > + mutex_destroy(&par->update_lock);
> > + framebuffer_release(info);
> > +
> > + return ret;
> > +}
> > +
> > +static int smemlcd_remove(struct spi_device *spi)
> > +{
> > + struct smemlcd_par *par = dev_get_drvdata(&spi->dev);
> > + struct fb_info *info = par->info;
> > +
> > + cancel_delayed_work_sync(&par->d_work);
> > +
> > + fb_deferred_io_cleanup(info);
> > +
> > + unregister_framebuffer(info);
> > +
> > + if (par->disp)
> > + gpiod_set_value_cansleep(par->disp, 0);
> > +
> > + if (par->extcomin_pwm) {
> > + pwm_disable(par->extcomin_pwm);
> > + pwm_put(par->extcomin_pwm);
> > + }
> > +
> > + fb_deferred_io_cleanup(info);
> > + __free_pages(__va(info->fix.smem_start),
> > get_order(info->fix.smem_len));
> > +
> > + kfree(par->spi_buf);
> > +
> > + mutex_destroy(&par->update_lock);
> > +
> > + framebuffer_release(info);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct spi_device_id smemlcd_spi_id[] = {
> > + {"ls027b7dh01", 0},
> > + {"ls044q7dh01", 0},
> > + {"ls013b7dh05", 0},
> > + {"ls013b7dh03", 0},
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(spi, smemlcd_spi_id);
> > +
> > +static struct spi_driver smemlcd_driver = {
> > + .probe = smemlcd_probe,
> > + .remove = smemlcd_remove,
> > + .id_table = smemlcd_spi_id,
> > + .driver = {
> > +.name = "smemlcdfb",
> > +.of_match_table = smemlcd_of_match,
> > +},
> > +};
> > +module_spi_driver(smemlcd_driver);
> > +
> > +MODULE_AUTHOR("Rodrigo Alencar <455.rodrigo.alen...@gmail.com>");
> > +MODULE_DESCRIPTION("Sharp Memory LCD Linux Framebuffer Driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.23.0.rc1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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 Sat, Jul 25, 2020 at 8:48 PM Alex Bee wrote:
>
>
> Am 25.07.20 um 17:54 schrieb Daniel Vetter:
> > On Sat, Jul 25, 2020 at 3:52 PM Alex Bee wrote:
> >>
> >> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> >>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee
t;1 + inmodeset=1]
> > > and then in next vblank_get: -EINVAL (!vblank->enabled + refcount ends 1)
> > > as in the first step.
> > >
> > > Melissa
> > >
> > > > -Daniel
> > > >
> > > > >
> > > > > > >
> > > > > > >
On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen wrote:
>
> On 07/25, Daniel Vetter wrote:
> > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang wrote:
> > >
> > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > > On Wed, Jul 22, 2
On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang wrote:
>
> On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen wrote:
> > >
> > > On 07/22, dan...@ffwll.ch wrote:
> > > > On Wed, Jul 22, 2
On Sat, Jul 25, 2020 at 3:52 PM Alex Bee wrote:
>
>
> Am 22.07.20 um 23:43 schrieb Daniel Vetter:
> > On Wed, Jul 22, 2020 at 8:13 PM Alex Bee wrote:
> >> Hi,
> >>
> >> this series mainly ports existining functionality to older SoCs - most
> >
,
> Stephen Rothwell
> _______
> 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
c tree or acks for merging in the other branch. No
rebasing in the middle of the merge window, that's rather uncool.
-Daniel
>
> BR,
> -R
>
> > But its fine now.
> >
> > --
> > viresh
> ___
> 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
f it is not used
> drm: rockchip: use overlay windows as such
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++---
> drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 +
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
arted. Moreover, a series of vkms_vblank_simulate flow out until
> > > disabling vblanks.
> > > Also watching the steps of vkms_crtc_atomic_flush, when the very first
> > > drm_crtc_vblank_get returned an error, the subtest crashed. On the other
> > > hand, when vbla
On Tue, Jul 21, 2020 at 6:08 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Jul 16, 2020 at 08:27:21PM +0900, Tetsuo Handa wrote:
> > On 2020/07/16 19:00, Daniel Vetter wrote:
> > > On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
> > >> On 202
h the
commit message explaining the entire debug story (i.e. all the
evidence that lead you to this) and we should be good to go.
I'm still not really clear on why this breaks stuff when re-enabling
the crtc ...
-Daniel
> Melissa
>
> On 07/21, Daniel Vetter wrote:
> > On Tue, Ju
On Mon, Jul 20, 2020 at 03:07:35PM -0400, Lyude Paul wrote:
> This one's easy - we're already calling kzalloc() in this function, so
Nit: "kzalloc(GFP_KERNEL)", since kzalloc(GFP_ATOMIC) is perfectly fine in
interrupt context. With that clarified for the entire series:
Rev
ning off the CRTC means the next test wont have to turn it back on
again. And the vblank bug seems to be in the code which turns the crtc
back on. At least inserting a vblank wait in there is enough to paper over
all the issues, per Melissa's testing.
So at least we're now fairly confi
ncorporated -
> http://www.ti.com/
> + * Copyright (C) 2010-2011 Texas Instruments Incorporated -
> https://www.ti.com/
> */
>
> #ifndef _HDMI4_CORE_H_
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_co
t;,
> + drm_get_format_name(fb->format->format,
> &format_name));
> return -EINVAL;
> }
>
> @@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> width * height * 2);
> err_msg:
> if (ret)
> - dev_err_once(fb->dev->dev, "Failed to update display %d\n",
> ret);
> + drm_err_once(fb->dev, "Failed to update display %d\n", ret);
>
> drm_dev_exit(idx);
> }
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; > > unsigned long flags)
> > > }
> > >
> > > ret = drm_simple_display_pipe_init(drm, &mxsfb->pipe, &mxsfb_funcs,
> > > - mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL,
> > > - mxsfb->connector);
> > > + mxsfb_formats, ARRAY_SIZE(mxsfb_formats),
> > > + mxsfb_modifiers, mxsfb->connector);
> > > if (ret < 0) {
> > > dev_err(drm->dev, "Cannot setup simple display pipe\n");
> > > goto err_vblank;
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
&dev->pdev->dev, PAGE_SIZE,
> + dev_priv->hw_status_page,
> + dev_priv->dma_status_page);
> }
> kfree(dev->dev_private);
> dev->dev_private = NULL;
> @@ -398,8 +398,8 @@ static int i810_dma_initialize(struct drm_device *dev,
>
> /* Program Hardware Status Page */
> dev_priv->hw_status_page =
> - pci_zalloc_consistent(dev->pdev, PAGE_SIZE,
> - &dev_priv->dma_status_page);
> + dma_alloc_coherent(&dev->pdev->dev, PAGE_SIZE,
> +&dev_priv->dma_status_page, GFP_KERNEL);
> if (!dev_priv->hw_status_page) {
> dev->dev_private = (void *)dev_priv;
> i810_dma_cleanup(dev);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jul 17, 2020 at 12:51 PM Lucas Stach wrote:
>
> Am Freitag, den 17.07.2020, 12:45 +0300 schrieb Laurentiu Palcu:
> > Hi Lukas and Daniel,
> >
> > On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote:
> > > On Fri, Jul 17, 2020 at 11:12:39AM +02
On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter:
> > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote:
> > > Hi Laurentiu,
> > >
> > > Am Donnerstag, den 09.07.2020, 19:47 +0300 s
On Fri, Jul 17, 2020 at 04:00:36PM +0800, miaoqinglang wrote:
>
>
> 在 2020/7/17 15:06, Daniel Vetter 写道:
> > On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> > wrote:
> > >
> > > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qingla
xld.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> >
>
> ___
> 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
r tree would it be for?
Some people put -next in their patch tag to differentiate from -fixes,
so maintainers know what to do with the patch. It's also not part of a
series, hence I think this is on you to apply it.
Cheers, Daniel
>
> Thanks
> James
>
> > #ifdef CONFIG_DEBU
On Thu, Jul 16, 2020 at 09:59:38AM +0800, Jing Xiangfeng wrote:
>
>
> On 2020/7/15 20:05, Daniel Vetter wrote:
> > On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
> > > The variable ret has been assigned the value '-EINVAL'. The assignment
>
kely means adding tons of over/underflow checks at entry points,
since you're never going to catch the driver bugs, there's too many and
not enough people who care) they need to fix this themselves.
Just to avoid confusion here.
> Anyway, my two patches are small and low cost; can we
On Wed, Jul 15, 2020 at 5:57 PM Melissa Wen wrote:
>
> On 07/15, Sidong Yang wrote:
> > On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> > > >
> > > > On 07/14, Daniel Vetter w
v->master->lessee_id);
> - ret = -EINVAL;
> goto out_unlock;
> }
>
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 14, 2020 at 10:23:43PM -0700, Randy Dunlap wrote:
> Drop doubled word "than" in a comment.
>
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
Entire series pushed to drm-misc-next, thanks for you
On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
>
> On 07/14, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen wrote:
> > > >
> > > > On 07/13, Daniel Vetter w
On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen wrote:
> >
> > On 07/13, Daniel Vetter wrote:
> > > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > > On 07/02, Daniel Vetter wrote:
On Mon, Jul 13, 2020 at 9:03 PM Jason Gunthorpe wrote:
>
> On Mon, Jul 13, 2020 at 08:34:12PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 13, 2020 at 5:57 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Mon, Jul 13, 2020 at 06:54:22PM +0300, Oded Gab
--- /dev/null
> > +++ b/drivers/misc/habanalabs/hl_dma_fence.h
> > @@ -0,0 +1,148 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Fence mechanism for dma-buf to allow for asynchronous dma access
> > + *
> > + * Copyright (C) 2012 Canonical Ltd
> > + * Copyright (C) 2012 Texas Instruments
> > + *
> > + * Authors:
> > + * Rob Clark
> > + * Maarten Lankhorst
> > + *
> > + * The dma_fence module is a copy of dma-fence at drivers/dma-buf.
>
> Same comments here for the .h file.
>
> thanks,
>
> greg k-h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> On 07/02, Daniel Vetter wrote:
> > On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> > > there is an error when igt test is run continuously.
> > > vkms_atomic_commi
On Thu, Jul 09, 2020 at 08:29:21AM +0100, Daniel Stone wrote:
> Hi,
> Jumping in after a couple of weeks where I've paged most everything
> out of my brain ...
>
> On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote:
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris
27;o
> Signed-off-by: Shuah Khan
> Signed-off-by: Dan Carpenter
> Signed-off-by: Kees Cook
> Signed-off-by: Olof Johansson
> Signed-off-by: Jonathan Corbet
> Signed-off-by: Chris Mason
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Dan Williams
Replied to the
on-inclusive terminology.
>
> Cc: Jonathan Corbet
> Cc: Kees Cook
> Signed-off-by: Chris Mason
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Dan Williams
Acked-by: Daniel Vetter
> ---
> Documentation/process/coding-style.rst | 12
> Document
//dri.freedesktop.org/docs/drm/gpu/todo.html#convert-logging-to-drm-functions-with-drm-device-paramater
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
urrent Mesa nouveau code, when asked what modifier it used for the
> above allocation, returns one of the "legacy" modifiers nouveau DRM-KMS
> knows nothing about.
>
> -When the modeset driver tries to create an FB for that BO with the
> returned modifier, the nouveau kernel
On Thu, Jul 02, 2020 at 05:11:25PM +0200, Neil Armstrong wrote:
> Hi,
>
> On 02/07/2020 16:15, Daniel Vetter wrote:
> > On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong
> > wrote:
> >>
> >> On 02/07/2020 15:18, Daniel Vetter wrote:
> >>> On Thu
t; b/drivers/gpu/drm/drm_mode_config.c
> index 5761f838a057..f1affc1bb679 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -538,6 +538,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> WARN_ON(!list_empty(&dev->mode_config.fb_list));
> list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) {
> struct drm_printer p = drm_debug_printer("[leaked fb]");
> +
> drm_printf(&p, "framebuffer[%u]:\n", fb->base.id);
> drm_framebuffer_print_info(&p, 1, fb);
> drm_framebuffer_free(&fb->base.refcount);
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 75e2b7053f35..c250fb5a88ca 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -298,6 +298,7 @@ EXPORT_SYMBOL(drm_legacy_pci_init);
> void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver
> *pdriver)
> {
> struct drm_device *dev, *tmp;
> +
> DRM_DEBUG("\n");
>
> if (!(driver->driver_features & DRIVER_LEGACY)) {
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 4af173ced327..b7b90b3a2e38 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -216,6 +216,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
>
> if (format_modifiers) {
> const uint64_t *temp_modifiers = format_modifiers;
> +
> while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> format_modifier_count++;
> }
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 282774e469ac..d66edc53f1ac 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -1014,6 +1014,7 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj,
> struct sg_table *sg)
> {
> struct dma_buf_attachment *attach;
> struct dma_buf *dma_buf;
> +
> attach = obj->import_attach;
> if (sg)
> dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 42d46414f767..3bf73971daf3 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -1188,6 +1188,7 @@ static void drm_syncobj_array_free(struct drm_syncobj
> **syncobjs,
> uint32_t count)
> {
> uint32_t i;
> +
> for (i = 0; i < count; i++)
> drm_syncobj_put(syncobjs[i]);
> kfree(syncobjs);
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 2d5ce690d214..aef3fcb0f12c 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1614,6 +1614,7 @@ static int drm_queue_vblank_event(struct drm_device
> *dev, unsigned int pipe,
> e->event.vbl.crtc_id = 0;
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> +
> if (crtc)
> e->event.vbl.crtc_id = crtc->base.id;
> }
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong wrote:
>
> On 02/07/2020 15:18, Daniel Vetter wrote:
> > On Thu, Jul 02, 2020 at 09:23:11AM +, Simon Ser wrote:
> >> On Thursday, July 2, 2020 9:47 AM, Neil Armstrong
> >> wrote:
> >>
> >>> Fina
re.
That would make sure that userspace cannot look at them.
Also I'm kinda suspecting that there's not unlimited amounts of this magic
invisible storage available anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
27;t really brining you closer to that, pretty much all
the lifetime bugs around hotunload are still there.
-Daniel
> if (!priv) {
> DRM_ERROR("no memory to allocate for hibmc_drm_private\n");
> return -ENOMEM;
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
is papering over some issue,
then I think more debugging is needed.
What exactly is going wrong here for you?
-Daniel
> +
> drm_atomic_helper_cleanup_planes(dev, old_state);
> }
>
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ng the forcibly-disabled atomic path in the modesetting driver in
> this build, so I didn't look too closely at things beyond that.
Yeah, so modifier support in -modesetting is totally broken. It should
be disabled by default because the stuff just doesn't really work.
If that doesn&
> >>> framebuffer
> >>> [ 29.997145] [drm:drm_ioctl] pid=3393, ret = -22
> >>>
> >>> Any suggestions?
> >>>
> >> ___
> >> dri-devel mailing list
> >> dri-de...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >
> > ___
> > 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 Wed, Jul 1, 2020 at 1:26 PM Christian König
wrote:
>
> As discussed on the list.
>
> Signed-off-by: Christian König
Acked-by: Daniel Vetter
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 404
he panel-orientation property.
> * @panel_orientation: drm_panel_orientation value to set
> *
> @@ -2131,7 +2131,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
>
> /**
> * drm_connector_set_panel_orientation_with_quirk -
> - * set the connecter's panel_orientation after checking for quirks
> + * set the connector's panel_orientation after checking for quirks
> * @connector: connector for which to init the panel-orientation property.
> * @panel_orientation: drm_panel_orientation value to set
> * @width: width in pixels of the panel, used for panel quirk detection
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
pass the struct drm_vblank_work to work item callbacks anyway
> Changes since v3:
> * Use our own spinlocks, don't integrate so tightly with kthread_works
> Changes since v2:
> * Use kthread_workers instead of reinventing the wheel.
>
> Cc: Daniel Vetter
> Cc: Tejun Heo
tting callbacks
>
> All of these will be guaranteed to have IRQs enabled, which means it's
> perfectly safe to block here. Just to make things a little less
> confusing to others in the future, let's switch over to
> spin_lock_irq()/spin_unlock_irq() to make that fact a little m
; drm_dp_port_set_pdt+0x90/0x2c0 [drm_kms_helper]
> drm_dp_delayed_destroy_work+0x2be/0x340 [drm_kms_helper]
> process_one_work+0x1ae/0x370
> worker_thread+0x50/0x3a0
> ? process_one_work+0x370/0x370
> kthread+0x11b/0x140
> ? kthread_associate_blkcg+0x90/0x90
> ret_from_fork+0x22/0x30
> ---[ end trace 16486ad3c2627482 ]---
> [ cut here ]
>
> Cheers,
> --
> Luis
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; index 024acad..582635d 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > @@ -27,7 +27,6 @@
> > #include
> > #include
> > #include
> > -#include
> >
> > #define HWVER_131 0x31333100 /* IP version 1.31 */
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jun 24, 2020 at 12:31 AM Dave Chinner wrote:
>
> On Sun, Jun 21, 2020 at 01:42:05PM -0400, Qian Cai wrote:
> > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > alloca
On Tue, Jun 23, 2020 at 6:18 PM Qian Cai wrote:
>
> On Sun, Jun 21, 2020 at 10:01:03PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
> > > >
> > >
On Tue, Jun 23, 2020 at 02:44:24PM -0400, Felix Kuehling wrote:
> Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter:
> > On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling
> > wrote:
> >> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> >>> On Thu, Jun
ernel, it seems a bit unnecessary anyway.
> * Get rid of to_drm_vblank_work() since we now are also able to just
> pass the struct drm_vblank_work to work item callbacks anyway
> Changes since v3:
> * Use our own spinlocks, don't integrate so tightly with kthread_works
> C
_init_release() action for each drm_vblank_crtc so they're
> still cleaned up if we fail to initialize one of them.
>
> Changes since v3:
> * Use drmm_add_action_or_reset() - Daniel Vetter
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: dri-de...@lists.freedesktop.o
I'm happy to help out with analyzing
any lockdep splats. For actual fixes Thomas is better since I don't
understand a lot of how drm/vmwgfx works internally.
Cheers, Daniel
On Thu, Jun 4, 2020 at 10:12 AM Daniel Vetter wrote:
>
> I need a canary in a ttm-based atomic dri
On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote:
>
> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> >>> I still have my doubts about allowing fence waiting from within shrinkers.
> >&g
On Fri, Jun 19, 2020 at 3:12 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-06-19 10:43:09)
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > > On Fri, Jun 19, 2020 at 10:2
On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
> >
> > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > all
On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
>
> On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > fs_reclaim_acquire/release nicely catch recursion issues when
> > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > to use to k
On Sun, Jun 21, 2020 at 7:01 PM Qian Cai wrote:
>
> On Thu, Jun 04, 2020 at 10:12:07AM +0200, Daniel Vetter wrote:
> > fs_reclaim_acquire/release nicely catch recursion issues when
> > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > to use to k
; > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> > > >
> > > > > The madness is only that device B's mmu notifier might need to wait
> > > > > for fence_B so that the dma operation finishes. Which in turn has to
> > > >
On Fri, Jun 19, 2020 at 5:15 PM Jason Gunthorpe wrote:
>
> On Fri, Jun 19, 2020 at 05:06:04PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
> > >
> > > On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> &g
On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
>
> On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > As I've understood GPU that means you need to show that the commands
> > > associated with the buffer have completed. This is all local
On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-06-19 09:51:59)
> > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > wrote:
> > > Forcing a generic primitive to always be part of the same global map is
> > > horrible.
ell encode the wrong contract, that's
all up for discussion. But fundamentally questioning that we need one
is missing what upstream is all about.
> This is a bunch of ad hoc tracking for a very narrow purpose applied
> globally, with loss of information.
It doesn't solve every problem indeed. I'm happy to review patches to
check acyclic-ness of dma-fence at the global level from you, I
haven't figured out yet how to make that happen. I know i915-gem has
that, but this is about the cross-driver contract here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jun 19, 2020 at 8:58 AM Jason Gunthorpe wrote:
>
> On Thu, Jun 18, 2020 at 05:00:51PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 17, 2020 at 12:28:35PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 17, 2020 at 08:48:50AM +0200, Daniel Vetter wrote:
> > >
On Wed, Jun 17, 2020 at 12:28:35PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 17, 2020 at 08:48:50AM +0200, Daniel Vetter wrote:
>
> > Now my understanding for rdma is that if you don't have hw page fault
> > support,
>
> The RDMA ODP feature is restartable HW pa
On Wed, Jun 17, 2020 at 12:29:40PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 17, 2020 at 09:57:54AM +0200, Daniel Vetter wrote:
>
> > > At the very least I think there should be some big warning that
> > > dma_fence in notifiers should be avoided.
> >
> > Ye
On Wed, Jun 17, 2020 at 9:27 AM Jason Gunthorpe wrote:
>
> On Tue, Jun 16, 2020 at 02:07:19PM +0200, Daniel Vetter wrote:
> > > > I've pinged a bunch of armsoc gpu driver people and ask them how much
> > > > this
> > > > hurts, so that we have a
On Tue, Jun 16, 2020 at 2:07 PM Daniel Vetter wrote:
>
> Hi Jason,
>
> Somehow this got stuck somewhere in the mail queues, only popped up just
> now ...
>
> On Thu, Jun 11, 2020 at 11:15:15AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 11, 2020 at 10:34:30AM
quot;Testing DRM range manager (struct drm_mm), with
> random_seed=0x%x max_iterations=%u max_prime=%u\n",
> random_seed, max_iterations, max_prime);
> err = run_selftests(selftests, ARRAY_SIZE(selftests), NULL);
>
> --
> 2.27.0.83.g0313f36c6ebe
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
is okay for everyone to collect them like this and push them via I2C for
> 5.8-rc2.
for the drm side of things:
Acked-by: Daniel Vetter
>
> One minor exception is the media documentation patch which I simply have
> missed so far, but it is trivial.
>
> And then, finally, there is
t;lanes;
> > @@ -1028,8 +1030,10 @@ static ssize_t cdns_dsi_transfer(struct
> > mipi_dsi_host *host,
> > int ret, i, tx_len, rx_len;
> >
> > ret = pm_runtime_get_sync(host->dev);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + pm_runtime_put(host->dev);
> > return ret;
> > + }
> >
> > cdns_dsi_init_link(dsi);
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi Jason,
Somehow this got stuck somewhere in the mail queues, only popped up just
now ...
On Thu, Jun 11, 2020 at 11:15:15AM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> > > I still have my doubts about allowing fence waiting
On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote:
>
> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> >>> I still have my doubts about allowing fence waiting from within shrinkers.
> >&g
On Thu, Jun 11, 2020 at 4:29 PM Tvrtko Ursulin
wrote:
>
>
> On 11/06/2020 12:29, Daniel Vetter wrote:
> > On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin
> > wrote:
> >> On 10/06/2020 16:17, Daniel Vetter wrote:
> >>> On Wed, Jun 10, 2
On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin
wrote:
>
>
> On 10/06/2020 16:17, Daniel Vetter wrote:
> > On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 04/06/2020 09:12, Daniel Vetter wrote:
> >>> Design
On Thu, Jun 11, 2020 at 09:30:12AM +0200, Thomas Hellström (Intel) wrote:
>
> On 6/4/20 10:12 AM, Daniel Vetter wrote:
> > Two in one go:
> > - it is allowed to call dma_fence_wait() while holding a
> >dma_resv_lock(). This is fundamental to how eviction works with
g for !CONFIG_MMU_NOTIFIER
Cc: Thomas Hellström (Intel)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
This is part of a gpu lockdep annotation series simply because i
701 - 800 of 2795 matches
Mail list logo
