On Wed, Feb 3, 2021 at 9:29 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote:
> >
> > On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter
> > wrote:
> > >
> > > On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote:
> >
On Wed, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote:
>
> On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote:
> > >
> > > On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
On Wed, Feb 3, 2021 at 6:14 PM Daniel Vetter wrote:
>
> On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
> >
> > On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John
> > > wrote:
> >
On Wed, Feb 3, 2021 at 5:42 PM Alex Deucher wrote:
>
> On Wed, Feb 3, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 3:33 PM Bridgman, John wrote:
> > >
> > > >>Uh, that doesn't work. If you want infinite compute queues you ne
On Tue, Jan 19, 2021 at 5:03 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > > wrot
On Tue, Jan 05, 2021 at 09:46:07PM +0800, Kevin Tang wrote:
> Adds dsi host controller support for the Unisoc's display subsystem.
> Adds dsi phy support for the Unisoc's display subsystem.
> Only MIPI DSI Displays supported, DP/TV/HMDI will be support
> in the feature.
>
> v1:
> - Remove dphy
(but shouldn't
affect other process really, if at all possible), hanging kernels at
large not so much.
-Daniel
> Thanks,
> John
> Original Message
> From: Daniel Vetter
> Sent: Wednesday, February 3, 2021 9:27 AM
> To: Alex Deucher
> Cc: Linux Kernel Mailing List; dri-devel;
On Wed, Feb 03, 2021 at 08:56:17AM -0500, Alex Deucher wrote:
> On Wed, Feb 3, 2021 at 7:30 AM Christian König
> wrote:
> >
> > Am 03.02.21 um 13:24 schrieb Daniel Vetter:
> > > On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> > >> Am
"sprd-dpu-drv",
> + .of_match_table = dpu_match_table,
> + },
> +};
> +
> +MODULE_AUTHOR("Leon He ");
> +MODULE_AUTHOR("Kevin Tang ");
> +MODULE_DESCRIPTION("Unisoc Display Controller Driver");
> +MODULE_LICENSE("
ted is
that you could use the new drmm_ infrastructure we just landed. See
comments below, with that addressed:
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/sprd/Kconfig| 1 +
> drivers/gpu/drm/sprd/Makefile | 4 +-
> drivers/gpu/drm/sprd/sprd_dpu.c | 985
> ++
tor */
> + drm_mode_config_reset(drm);
> +
> + /* init kms poll for handling hpd */
> + drm_kms_helper_poll_init(drm);
> +
> + ret = drm_dev_register(drm, 0);
> + if (ret < 0)
> + goto err_kms_helper_poll_fini;
> +
>
On Wed, Feb 03, 2021 at 01:21:20PM +0100, Christian König wrote:
> Am 03.02.21 um 12:45 schrieb Daniel Gomez:
> > On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
> > > On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
> > > > On Wed, Feb 3, 2021 at 9:51 AM C
se.completion);
> - crtc->state->event = NULL;
> - }
> }
>
> static inline struct zynqmp_disp *crtc_to_disp(struct drm_crtc *crtc)
> @@ -1499,6 +1491,13 @@ zynqmp_disp_crtc_atomic_disable(struct drm_crtc *crtc,
>
> drm_crtc_vblank_
is harmless if the module is already loaded (and not
> other caller has this find_module check either).
>
> Signed-off-by: Christoph Hellwig
Hm I thought I've acked this one already somewhere for merging through
your tree.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_
On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote:
> On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote:
> >
> > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal
> > wrote:
> > >
> > > On Thu, 28 Jan 2021 at 17:23, Christian König
> > &
we probably
> would have noticed this much earlier.
Yeah kernel keeps lots of caches around and just gives you back the
previous buffer if it's still around. Still probably not the smartest
idea.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
int qxl_release_bo_alloc(struct qxl_device *qdev,
> @@ -344,6 +345,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
> unsigned long size,
> *rbo = NULL;
> return idr_ret;
> }
> + atomic_inc(>release_count);
>
> mutex_lock(>release_mutex);
> if (qdev->current_release_bo_offset[cur_idx] + 1 >=
> releases_per_bo[cur_idx]) {
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> >
> > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > > Lockdep complains about an AA deadlock w
On Tue, Feb 02, 2021 at 09:56:14PM -0800, John Stultz wrote:
> On Tue, Feb 2, 2021 at 6:04 AM Daniel Vetter wrote:
> >
> > On Fri, Jan 22, 2021 at 05:28:32PM -0800, John Stultz wrote:
> > > On Mon, Dec 21, 2020 at 2:09 PM Daniel Vetter wrote:
> > > >
> &
On Wed, Feb 3, 2021 at 9:51 AM Christian König wrote:
>
> Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > On Wed, Feb 3, 2021 at 9:36 AM Christian König
> > wrote:
> >> Hi Daniel,
> >>
> >> this is not a deadlock, but rather a hardwar
exactly do we need to make this switch for system heap?
I've recently looked at gup usage by random drivers, and found a lot
of worrying things there. gup on dma-buf is really bad idea in
general.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
0007
> > [ 738.359096] RBP: c02064c3 R08: 0003 R09:
> > 00007f6b82b54bbc
> > [ 738.359101] R10: 0001 R11: 0246 R12:
> > 000165a0bc00
> > [ 738.359106] R13: 0007 R14: 0001 R15:
> >
> > [ 738.359129]
> > Showing all locks held in the system:
> > [ 738.359141] 1 lock held by khungtaskd/54:
> > [ 738.359148] #0: 829f6840 (rcu_read_lock){}-{1:2}, at:
> > debug_show_all_locks+0x15/0x183
> > [ 738.359187] 1 lock held by systemd-journal/174:
> > [ 738.359202] 1 lock held by MatrixMultiplic/653:
> > [ 738.359206] #0: 88810e364fe0
> > (>notifier_lock){+.+.}-{3:3}, at:
> > amdgpu_mn_invalidate_gfx+0x34/0xa0 [amdgpu]
> >
> > Daniel
>
> ___
> 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
]);
> + for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++) {
> + lockdep_register_key(>commit_lock_keys[i]);
> + __mutex_init(>commit_lock[i], ">commit_lock[i]",
> + >commit_lock_keys[i]);
> + }
>
On Tue, Feb 02, 2021 at 10:13:14AM -0500, Phillip Susi wrote:
>
> Daniel Vetter writes:
>
> > Just a quick comment on this: Since most framebuffers are write-combining,
> > and reads from that tend to be ~3 orders of magnitude slower than writes
> > (at least on th
t looks like this function isn't needed at
> all anymore and ->screen_pos() can be removed from struct consw.
>
> Does this make sense or am I talking crazy?
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jan 22, 2021 at 05:28:32PM -0800, John Stultz wrote:
> On Mon, Dec 21, 2020 at 2:09 PM Daniel Vetter wrote:
> >
> > On Fri, Dec 18, 2020 at 05:16:56PM -0800, John Stultz wrote:
> > > On Fri, Dec 18, 2020 at 6:36 AM Daniel Vetter wrote:
> > > > On T
ics can be found at [3](suggested by John
> > >>> Stultz).
> > >>>
> > >>> The patch contains the following improvements over the previous version:
> > >>> 1) Each attachment is represented by its own directory to allow creating
> > >&
them. Setting it
to 0 kinda defeats the warning.
-Daniel
>
> Not calling ttm_bo_unpin() makes ttm_bo_release() throw
> a WARN() because of the pin.
>
> Clearing pin_count (which is how ttm fixes things up
> in the error path) works.
>
> I'm open to better ideas.
>
> take care,
> Gerd
>
> ___
> 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
full use cases on Android's closed stacks. And it is uapi.
Tech debt isn't measured in lines of code, but in how expensive it's going
to be to fix up the mess in the future. uapi is expensive no matter how
few lines are used to implement it.
So yeah this needs to be properly thought out, properly implemented (not
just on the virtual demo stack but something that looks like actual
production stack), with open drivers, proper alignment with other efforts
like tracking memory with cgroups, and the interactions with dma-buf
tracking resolved, and igt testcases (this is meant to be generic after
all), and at least solid proposals for rolling this out across the drm
drivers, and ...
In other words, new uapi needs to be done right.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell wrote:
>
> Hi Daniel,
>
> On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote:
> >
> > Hm that has been in drm-intel-gt-next for a few days, is that tree not
> > in linux-next?
>
> It is not.
Adding -
DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
> !COMPILE_TEST [=y]
> Selected by [m]:
> - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> Maybe introduced by c
On Thu, Jan 21, 2021 at 9:28 AM Christoph Hellwig wrote:
>
> On Thu, Jan 21, 2021 at 09:25:40AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 21, 2021 at 8:55 AM Christoph Hellwig wrote:
> > >
> > > drm_fb_helper_modinit has a lot of boilerplate for what is not v
unnecessary rework for something that is slowly getting
> replaced by bridges.
>
> Since all the users that matter have been converted, let's remove the
> TODO item.
>
> Signed-off-by: Maxime Ripard
Acked-by: Daniel Vetter
>
> ---
>
> Changes from v1:
> - New patc
* there's no reason this is a core function.
> +* This hook is deprecated, drivers should instead use
> +* drm_fbdev_generic_setup() which takes care of any necessary
> +* hotplug event forwarding already without further involvement by
> + * the driver.
>
; >
> > I now get this warning from the drm tree merge.
Drat, I missed that when merging.
> Bhawan sent out the fix today:
> https://patchwork.freedesktop.org/patch/415092/
Applied directly to drm-next, thanks.
-Daniel
>
> Alex
>
> >
> > --
> > Cheers,
> > 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
console symbols. At least
> +* attempt to load fbcon to avoid leaving the system without a usable
> +* console.
> +*/
> + if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) &&
> + IS_MODULE(CONFIG_FRAMEBUFFER_CONSOLE) &&
> + !IS_ENABLED(CONFIG_EXPERT) &&
> + !module_loaded("fbcon"))
> + request_module_nowait("fbcon");
> +
> + return drm_dp_aux_dev_init();
> }
>
> static void __exit drm_kms_helper_exit(void)
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 20, 2021 at 2:21 PM Paul Cercueil wrote:
>
>
>
> Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
> écrit :
> > On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
> > wrote:
> >>
> >> Since the encoders have been devm-allocated, they will be f
On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
>
>
>
> Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a
> écrit :
> > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil
> > wrote:
> >>
> >> If we don't call drm_connector_cleanup() manually
t; Cc: # v5.8+
> Signed-off-by: Paul Cercueil
Does what it says on the tin^Wcommit message.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/
ge =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_connector *connector = _bridge->connector;
> +
> + /* Cleanup the connector if we know it was initialized */
> + if (!!panel_bridge->connector.dev)
> + drm_connector_cleanup(connector);
>
if (ret) {
> - dev_err(dev, "Failed to init encoder: %d\n", ret);
> - return ret;
> - }
> -
> ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> if (ret) {
> dev_err(dev, "Unable to attach bridge\n");
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
stinct mappings of each attachment is exposed in a
> > separate file.
> > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers
> > inorder to make the interface expandable in future.
> >
> > All of the improvements above are based on suggesti
On Wed, Jan 20, 2021 at 10:51 AM Yiwei Zhang wrote:
>
> On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > > >
> &g
t;
> > > And now the drm-intel tree.
> > >
> > > I have used the drm-intel tree from next-20210108 for today.
> >
> > This is still affecting the drm and drm-intel trees.
>
> I think the fix for this is in drm-misc-next, Maarten can you send me
> a -next PR to fix this?
I've pulled drm-misc-next into drm-next now, so as long as all other
drm trees are merged after drm, this should be solved now.
drm-intel-next also has their msm build breakage fixed (I acked the
patch already), so hopefully we should be all clean again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
DAC, NULL);
> +
> + ldev->mode_info[index].encoder = lencoder;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/loongson/loongson_plane.c
> b/drivers/gpu/drm/loongson/loongson_plane.c
> new file mode 100644
> index ..288b6c894222
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/loongson_plane.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "loongson_drv.h"
> +
> +static void loongson_plane_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct loongson_crtc *lcrtc;
> + struct loongson_device *ldev;
> + struct drm_plane_state *state = plane->state;
> + u32 gpu_addr = 0;
> + u32 fb_addr = 0;
> + u32 reg_val = 0;
> + u32 reg_offset;
> + u32 pitch;
> + u8 depth;
> + u32 x, y;
> +
> + if (!state->crtc || !state->fb)
> + return;
> +
> + pitch = state->fb->pitches[0];
> + lcrtc = to_loongson_crtc(state->crtc);
> + ldev = lcrtc->ldev;
> + reg_offset = lcrtc->reg_offset;
> + x = state->crtc->x;
> + y = state->crtc->y;
> + depth = state->fb->format->cpp[0] << 3;
> +
> + gpu_addr = loongson_gpu_offset(state);
> + reg_val = (pitch + 255) & ~255;
> + ls_mm_wreg_locked(ldev, FB_STRI_REG + reg_offset, reg_val);
> +
> + switch (depth) {
> + case 12 ... 16:
> + fb_addr = gpu_addr + y * pitch + ALIGN(x, 64) * 2;
> + break;
> + case 24 ... 32:
> + default:
> + fb_addr = gpu_addr + y * pitch + ALIGN(x, 64) * 4;
> + break;
> + }
> +
> + ls_mm_wreg_locked(ldev, FB_ADDR0_REG + reg_offset, fb_addr);
> + ls_mm_wreg_locked(ldev, FB_ADDR1_REG + reg_offset, fb_addr);
> + reg_val = lcrtc->cfg_reg | CFG_ENABLE;
> + ls_mm_wreg_locked(ldev, FB_CFG_REG + reg_offset, reg_val);
> +}
> +
> +static const uint32_t loongson_formats[] = {
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> +};
> +
> +static const uint64_t loongson_format_modifiers[] = { DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID };
> +
> +static const struct drm_plane_funcs loongson_plane_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .destroy = drm_plane_cleanup,
> + .disable_plane = drm_atomic_helper_disable_plane,
> + .reset = drm_atomic_helper_plane_reset,
> + .update_plane = drm_atomic_helper_update_plane,
> +};
> +
> +static const struct drm_plane_helper_funcs loongson_plane_helper_funcs = {
> + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
> + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
> + .atomic_update = loongson_plane_atomic_update,
> +};
> +
> +int loongson_plane_init(struct loongson_crtc *lcrtc)
> +{
> + struct loongson_device *ldev;
> + int crtc_id;
> + int ret;
> +
> + ldev = lcrtc->ldev;
> + crtc_id = lcrtc->crtc_id;
> +
> + lcrtc->plane = devm_kzalloc(ldev->dev->dev, sizeof(*lcrtc->plane),
> + GFP_KERNEL);
> + if (!lcrtc->plane)
> + return -ENOMEM;
> +
> + ret = drm_universal_plane_init(ldev->dev, lcrtc->plane, BIT(crtc_id),
> +_plane_funcs, loongson_formats,
> +ARRAY_SIZE(loongson_formats),
> +loongson_format_modifiers,
> +DRM_PLANE_TYPE_PRIMARY, NULL);
> + if (ret) {
> + DRM_ERROR("fail to init planed crtc %d\n", crtc_id);
> + return ret;
> + }
> +
> + drm_plane_helper_add(lcrtc->plane, _plane_helper_funcs);
> +
> + return 0;
> +}
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > >
> > > On the success of virtio_gpu_object_create, add size of newly allocated
On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > wrote:
> > >
> > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a d
On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter
goto fail;
>
> ret = drm_atomic_commit(state);
>
> --
> 2.17.1
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter wrote:
>
> Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> the region") /dev/kmem zaps ptes when the kernel requests exclusive
> acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> t
0
> > ---[ end trace 77f55ece72f02708 ]---
> >
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
> >
> > Caused by commit
> >
> > 85482fbab59e ("PCI: Revoke mappings like devmem")
> >
> > Reverting that c
md_unref_resource(vgdev, bo);
> virtio_gpu_notify(vgdev);
> /* completion handler calls virtio_gpu_cleanup_object() */
> @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> virtio_gpu_object_attach(vgdev, bo, ents, nents);
> }
>
> + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> *bo_ptr = bo;
> return 0;
>
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote:
> On Mon, 18 Jan 2021, Daniel Vetter wrote:
>
> > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
> > >
> > > > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> > > >
> >
oller if they're stuck).
Note that we have some build issue on some of the configs sfr uses, so drm
trees are still stuck on old versions in linux-next. Hopefully should get
resolved soon, the bugfix is in some subtree I've heard.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> > niggly little warnings.
> >
> > Penultimate set, promise. :)
>
>
> Thank you for all that work. For all the vmwgfx bits:
> Reviewed-by: Zack Rusin
I pulled all the non-vmxgfx patches to drm-misc-next, I'll leave the vmw
stuff to Zack.
Thanks for your work here!
-Daniel
--
t; return ret;
> > > }
> > >
> > > +ret = devm_add_action_or_reset(dev,
> > > ingenic_drm_encoder_cleanup,
> > > + encoder);
> > > +if (ret)
> > > +return ret;
> > > +
> > > ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> > > if (ret) {
> > > dev_err(dev, "Unable to attach bridge\n");
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
pci_dev *pdev) { return 0; };
> +static inline struct pci_dev *vga_default_device(void) { return NULL; }
> +static inline void vga_set_default_device(struct pci_dev *pdev) { }
> +static inline int vga_remove_vgacon(struct pci_dev *pdev) { return 0; }
> #endif
>
> /*
> -
-misc-next, but some patch
monkey help would be really great :-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sun, Jan 17, 2021 at 03:29:05AM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
> Author: Daniel Vetter
> Date: Fri Oct 9 23:21:56 2020 +
>
> drm/vkms: fbdev emulation support
Not sure
ry
> > + * hotplug event forwarding already without further involvement by
> > + * the driver.
> > */
> > void (*output_poll_changed)(struct drm_device *dev);
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; - *
> - * Except that there's no vtable for device-level helper callbacks
> - * there's no reason this is a core function.
> */
> void (*output_poll_changed)(struct drm_device *dev);
>
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven wrote:
>
> Hi Daniel,
>
> CC linux-fbdev
>
> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote:
> > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> > wrote:
> > > On Fri, Jan 8, 2021 at 11:13 AM Philli
| ("sacn out")
> + *|| ("scan out")
> *| Old frame|
> *||
> * |
sktop.org/mailman/listinfo/amd-gfx
>
> ___
> 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, Jan 14, 2021 at 10:11:01AM +0100, Daniel Vetter wrote:
> On Thu, Jan 14, 2021 at 10:04 AM Jani Nikula
> wrote:
> >
> > On Wed, 13 Jan 2021, Lee Jones wrote:
> > > On Wed, 13 Jan 2021, Sam Ravnborg wrote:
> > >
> > >> Hi Lee,
> > &
ave been very small.
-Daniel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> 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
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter
Cc: Andrew Morton
Cc: linux...@kvack.org
--
v2: git add everything ... oops
---
mm/backing-dev.c | 2 +-
1 file changed, 1
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter
Cc: Andrew Morton
Cc: linux...@kvack.org
--
v2: git add everything ... :-/
---
mm/dmapool.c | 3 ++-
1 file changed, 2
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter
Cc: Andrew Morton
Cc: linux...@kvack.org
---
mm/dmapool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter
Cc: Andrew Morton
Cc: linux...@kvack.org
---
mm/backing-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
d the console is a pure
nightmare.
Altogether this is a few years of full time hacking to get this back
into shape, and until that's happening and clearly getting somewhere
the only reasonable thing to do is to delete features in response to
syzkaller crashes.
Also adding dri-devel since defacto that's the only place where
display people hang out nowadays.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
u please respin with my suggestions taking into account somehow?
Thanks, Daniel
>*
>* FIXME:
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jan 12, 2021 at 2:24 PM Daniel Vetter wrote:
>
> On Fri, Nov 27, 2020 at 05:41:14PM +0100, Daniel Vetter wrote:
> > Hi all
> >
> > Another update of my patch series to clamp down a bunch of races and gaps
> > around follow_pfn and other access to iomem mmaps
On Fri, Nov 27, 2020 at 05:41:14PM +0100, Daniel Vetter wrote:
> Hi all
>
> Another update of my patch series to clamp down a bunch of races and gaps
> around follow_pfn and other access to iomem mmaps. Previous version:
>
> v1:
> https://lore.kernel.org/dri-devel/202
* by linking _framebuffer to _plane, _plane to
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; - * RETURNS:
> - * 0 on success, or error code on failure.
> */
> void drm_file_free(struct drm_file *file)
> {
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; ranges.reader_wm_sets[i].min_fill_clk_mhz = (i
> > > 0) ? (loaded_bb->clock_limits[i - 1].dram_speed_mts / 16) + 1 : 0;
> > ranges.reader_wm_sets[i].max_fill_clk_mhz =
> > loaded_bb->clock_limits[i].dram_speed_mts / 16;
to make it
clear why you'd want to look at module options and set them.
Otherwise lgtm, with that change on the entire series:
Acked-by: Daniel Vetter
> +You can use the `modinfo` command to see module options for vkms::
> +
> + modinfo vkms
> +
> +Module options are helpful when tes
1):
drm/msm: Call msm_init_vram before binding the gpu
Daniel Vetter (4):
Merge tag 'amd-drm-fixes-5.11-2021-01-06' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
Merge tag 'drm-intel-fixes-2021-01-07' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Merge
On Fri, Jan 08, 2021 at 06:41:05PM +0800, Tian Tao wrote:
> Based on the drm_connector_mode_valid, if the hibmc implementation
> of mode_valid only returns MODE_OK, then we can not implement the
s/can not/need not/
> mode_valid function.
>
> Signed-off-by: Tian Tao
Reviewed-by
y: 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
tructure
> * @cmd: Command
> - * @seq...: Optional parameter(s)
> + * @seq: Optional parameter(s)
> *
> * Send MIPI DCS command to the controller. Use mipi_dbi_command_read() for
> * get/read.
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
kernel.org/stable/cakmk7uey-b_npmoh9wya4ncsk8al_jk+-+frzsrk6noqqrv...@mail.gmail.com/
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
here is no need for hibmc to call
> drm_dev_put separately.
>
> Signed-off-by: Tian Tao
lgtm, Reviewed-by: Daniel Vetter
Cheers, Daniel
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff
On Fri, Dec 18, 2020 at 05:16:56PM -0800, John Stultz wrote:
> On Fri, Dec 18, 2020 at 6:36 AM Daniel Vetter wrote:
> > On Thu, Dec 17, 2020 at 11:06:11PM +, John Stultz wrote:
> > > Reuse/abuse the pagepool code from the network code to speed
> > >
ac_init(struct hibmc_drm_private *priv)
> > {
> > - struct drm_device *dev = priv->dev;
> > + struct drm_device *dev = >dev;
> > struct hibmc_connector *hibmc_connector = >connector;
> > struct drm_encoder *encoder = >encoder;
> > struct
us" -> "Heterogeneous"
Daniel Vetter (6):
char/agp: Disable frontend without CONFIG_DRM_LEGACY
Merge tag 'drm-misc-next-2020-11-27-1' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next
dma-buf: Fix kerneldoc formatting
Merge tag '
On Fri, Dec 18, 2020 at 5:10 PM Steven Rostedt wrote:
>
> On Thu, 17 Dec 2020 11:03:20 +0100
> Daniel Vetter wrote:
>
> > I think we're tripping over the might_sleep() all the mutexes have,
> > and that's not as good as yours, but good enough to catch a missing
>
> + pools[i] = page_pool_create();
> +
> + if (IS_ERR(pools[i])) {
> + int j;
> +
> + pr_err("%s: page pool creation failed!\n", __func__);
> + for (j = 0; j < i; j++)
> + page_pool_destroy(pools[j]);
> + return PTR_ERR(pools[i]);
> + }
> + }
>
> exp_info.name = "system";
> exp_info.ops = _heap_ops;
> --
> 2.17.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
On Thu, Dec 17, 2020 at 9:40 AM Jiaying Liang wrote:
>
>
> On 12/15/20 7:23 AM, Alex Deucher wrote:
> > On Mon, Dec 14, 2020 at 7:24 PM Jiaying Liang
> > wrote:
> >> On 12/11/20 11:39 AM, Daniel Vetter wrote:
> >>> Hi all
> >>>
> >&g
On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
>
> On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 2:14 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following is
On Wed, Dec 16, 2020 at 09:59:17AM +0200, Tomi Valkeinen wrote:
> Update the maintainer email addresses for TI display drivers.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Daniel Vetter
> ---
> MAINTAINERS | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(
R09:
> R10: R11: R12:
> R13: R14: R15:
> detected fb_set_par error, error code: -16
>
>
> ---
> This report is generated by a bot. It may cont
On Tue, Dec 15, 2020 at 12:59:53PM +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2020 at 11:01:39AM +0800, Tian Tao wrote:
> > drm_irq_uninstall should be called before pci_disable_msi, if use
> > devm_drm_irq_install to register the interrupt, the system will
> > call
arm64_sys_delete_module+0x1fc/0x2d0
> el0_svc_common.constprop.3+0xa8/0x188
> do_el0_svc+0x80/0xa0
> el0_sync_handler+0x8c/0xb0
> el0_sync+0x15c/0x180
> Code: f940b400 b400 a903e7b8 f90013b5 (d421)
> ---[ end trace 310d94ee8abef44f ]---
> Kernel panic - not syncing: Oop
+++ b/include/drm/drm_irq.h
> @@ -29,4 +29,5 @@ struct drm_device;
> int drm_irq_install(struct drm_device *dev, int irq);
> int drm_irq_uninstall(struct drm_device *dev);
> int devm_drm_irq_install(struct drm_device *dev, int irq);
> +int devm_drm_msi_install(struct drm_device *dev);
> #endif
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ot;Cannot connect bridge: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
> goto err_vblank;
> }
>
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e(dlfb->edid);
> + dlfb_free_urb_list(dlfb);
> usb_put_dev(dlfb->udev);
> kfree(dlfb);
>
> --
> 2.17.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
On Mon, Dec 14, 2020 at 04:24:17PM -0800, Jiaying Liang wrote:
>
> On 12/11/20 11:39 AM, Daniel Vetter wrote:
> > Hi all
> >
> > On Fri, Dec 11, 2020 at 8:03 PM Alex Deucher wrote:
> > > On Mon, Nov 30, 2020 at 3:25 AM Wendy Liang
> > > wrote:
&g
es")
> > >
> > > I am still getting these warnings.
> >
> > I am still getting these warnings.
>
> These warnings are now from Linus' tree.
We had a stuck pull request which should have been included in the
main merge pull. This should be fixed now in drm-next. Well in a few
minutes when the compile testing is done.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
101 - 200 of 6575 matches
Mail list logo
