* migration.
>*
>* This is always called with the dmabuf->resv object locked when
>* no_sgt_cache is true.
> @@ -442,6 +465,8 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
> struct dma_buf *dma_buf_get(int fd);
> void dma_buf_put(struct dma_buf *d
On Wed, Apr 17, 2019 at 04:30:51PM +0200, Daniel Vetter wrote:
> On Wed, Apr 17, 2019 at 04:20:02PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote:
> > > Add optional explicit pinning callbacks instead of implicitly assume the
&
ion we need to
> rework media/v4l2 for per-slice decoding support ;)
>
> > Another driver you might want to look is Rockchip RGA driver (which is
> > a multi function IP, including blitting).
>
> Yep, I've aware of it as well. There's also vivante which exposes 2D
> cores but I'm really not sure whether any function is actually
> implemented.
>
> OMAP4 and OMAP5 have a 2D engine that seems to be vivante as well from
> what I could find out, but it seems to only have blobs for bltsville
> and no significant docs.
Yeah that's the usual approach for drm 2d drivers: You have a bespoke
driver in userspace. Usually that means an X driver, but there's been talk
to pimp the hwc interface to make that _the_ 2d accel interface. There's
also fbdev ... *shudder*.
All of these options are geared towards ultimately displaying stuff on
screens, not pure m2m 2d accel.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ize = pci_resource_len(pdev, bar);
> + pci_info(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar,
> + (unsigned long)pci_resource_start(pdev, bar),
> + (unsigned long)pci_resource_end(pdev, bar));
> +
On Mon, Feb 4, 2019 at 7:49 PM Sam Ravnborg wrote:
>
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:13AM +0100, Daniel Vetter wrote:
> > The compiler already clears this for us.
> >
> > More important, someone might look what this is actually used for,
> > an
| 13 +-
> > 17 files changed, 894 insertions(+), 789 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
> > delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> > create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> > create mode 100644 drivers/phy/cadence/cdns-dphy.c
> >
> > base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c
> >
> ___
> 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
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> +};
I'd include the lower-res formats too here, without those you limit
userspace that looks at this stuff to only these formats. Not that this is
really important for cirrus ... So 24bits would include 16, and 32 would
in
we could teach ttm to not have it's own vma node
...
Anyway, lgtm.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/boch
and would
> not be a burden for the fbdev maintainers, and I can grarantee that I will
> not add any other new features to this driver.
Awesome, and I think as a gradual plan this makes tons of sense.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 05, 2019 at 11:47:58AM +0100, Rafael J. Wysocki wrote:
> w/compOn Thu, Jan 31, 2019 at 3:46 PM Daniel Vetter
> wrote:
> >
> > Someone owes me a beer ...
> >
> > While typing these I think doing an s/component_master/aggregate/
> > would be useful:
an initial draft of these docs.
v2: Review from Rafael:
- git add Documenation/driver-api/component.rst
- lots of polish to the wording + spelling fixes.
Cc: "C, Ramalingam"
Cc: Greg Kroah-Hartman
Cc: Russell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo
On Tue, Feb 05, 2019 at 04:49:02PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 05, 2019 at 05:21:07PM +0100, Daniel Vetter wrote:
> > Someone owes me a beer ...
>
> I find that deeply offensive - it is clearly directed at me personally
> as author of th
org
> Signed-off-by: Rodrigo Siqueira
> ---
> Changes in V2:
> - Add "Cc: sta...@vger.kernel.org" tag
Since cc: stable please apply this patch to drm-misc-fixes, not
drm-misc-next like usual.
Acked-by: Daniel Vetter
>
> drivers/gpu/drm/vkms/vkms_cr
On Mon, Feb 04, 2019 at 07:54:16PM +0100, Sam Ravnborg wrote:
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
> > Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
> > for.
> Can you improve the gammar a lit
ell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo Vivi
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 17
Documentation/driver-api/device_link.rst | 3 +
Documentation/driver-api/index.rst | 1 +
d
ssues:
> -
> -- plain-flip-fb-recreate
> -- plain-flip-ts-check
> -- flip-vs-blocking-wf-vblank
> -- plain-flip-fb-recreate-interruptible
> -- flip-vs-wf_vblank-interruptible
Patch applied to drm-misc-next, thanks for your patch.
-Daniel
> -
> Runtime Configuration
> -
On Fri, Jan 25, 2019 at 4:02 PM Olof Johansson wrote:
>
> On Thu, Jan 24, 2019 at 11:43 PM Daniel Vetter wrote:
> >
> > On Fri, Jan 25, 2019 at 1:14 AM Olof Johansson wrote:
> > >
> > > On Thu, Jan 24, 2019 at 2:23 AM Dave Airlie wrote:
> > > >
help
> + HW offload accelerators are used for high-bandwidth workloads
> + where a higher-level kernel/userspace interface isn't suitable.
> +
> +if ACCEL
> +
> +comment "HW Accellerator drivers"
> +
> +endif
> diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile
> new file mode 100644
> index 0..343bbb8f45a14
> --- /dev/null
> +++ b/drivers/accel/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Makefile for accel devices
> +#
> +
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi Olof & Greg,
Ok I thought about what this means in practice a bit more over the
w/e, and I think we need to drag this discussion on for a bit more.
On Fri, Jan 25, 2019 at 11:23 PM Daniel Vetter wrote:
>
> On Fri, Jan 25, 2019 at 10:16:12AM -0800, Olof Johansson wrote:
> > W
to see if this really is even a viable thing to do.
> The fd handling seems a bit "odd" here, but maybe I just do not
> understand it.
Frankly looks like a ploy to sidestep review by graphics folks. We'd
ask for the userspace first :-)
Also, exporting dma_addr to userspace is considered a very bad idea.
If you want to do this properly, you need a minimal in-kernel memory
manager, and those tend to be based on top of drm_gem.c and merged
through the gpu tree. The last place where we accidentally leaked a
dma addr for gpu buffers was in the fbdev code, and we plugged that
one with
commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a (tag:
drm-misc-next-fixes-2018-10-03)
Author: Neil Armstrong
Date: Fri Sep 28 14:05:55 2018 +0200
drm/fb_helper: Allow leaking fbdev smem_start
Together with cuse the above patch should be enough to implement a drm
driver entirely in userspace at least.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon wrote:
>
> Hi Daniel,
>
> Thanks for the comment.
>
> On Tue, 2019-02-26 at 04:06:13 -0800, Daniel Vetter wrote:
> > On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Sat, F
On Thu, Feb 11, 2021 at 04:21:51PM +0800, Kevin Tang wrote:
> Daniel Vetter 于2021年2月3日周三 下午10:15写道：
>
> > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote:
> > > Adds DPU(Display Processor Unit) support for the Unisoc's display
> > subsystem.
> &g
On Wed, Feb 10, 2021 at 04:12:58PM +, Lee Jones wrote:
> On Wed, 10 Feb 2021, Daniel Vetter wrote:
>
> > On Wed, Feb 10, 2021 at 08:23:41AM +, Lee Jones wrote:
> > > On Tue, 09 Feb 2021, Julia Lawall wrote:
> > >
> > > > Use getter and setter fun
On Tue, Feb 23, 2021 at 2:42 AM Linus Torvalds
wrote:
>
> On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
> >
> > Cc all the mailing lists ... my usual script crashed and I had to
> > hand-roll the email and screwed it up ofc :-/
>
> Oh, and my reply thus a
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> On 2/9/21 5:37 AM, Daniel Vetter wrote:
> > On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
> > >
> > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > > >
On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> >
> > On Tue, Feb 9, 2021 at 6:46 PM Christian König
> > wrote:
> > >
> > >
> > >
> > > Am 09.02.21 um 18:33 sch
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c
> index 66c7d765b8f7..59a8d99e777d 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -244,7 +244,7 @@ static int panel_lvds_probe(struct platform_device *pdev)
>
> static int panel_lvds_remove(struct platform_device *pdev)
> {
> - struct panel_lvds *lvds = dev_get_drvdata(&pdev->dev);
> + struct panel_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_panel_remove(&lvds->panel);
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-
> > drivers/video/backlight/qcom-wled.c |
> > 2 +-
>
> This patch is fine.
>
> Could you please split it out and submit it separately though please.
Or just apply the entire patch through backlight tree, there's nothing
going
gt;
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Feb 10, 2021 at 5:39 PM Suren Baghdasaryan wrote:
>
> On Wed, Feb 10, 2021 at 5:06 AM Daniel Vetter wrote:
> >
> > On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> > > &
first cut merged sooner than later if
possible. And the other prep work has been in -next since -rc1.
Thanks, Daniel
On Fri, Feb 5, 2021 at 2:36 PM Daniel Vetter wrote:
>
> We are already doing this for all the regular sysfs files on PCI
> devices, but not yet on the legacy io files on
On Wed, Feb 10, 2021 at 10:40 PM Bjorn Helgaas wrote:
>
> On Fri, Feb 05, 2021 at 02:36:32PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > no
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 the p
ms->commit_lock[i]",
> + &kms->commit_lock_keys[i]);
> + }
>
> kms->funcs = funcs;
>
>
> base-commit: 19c329f6808995b142b3966301f217c831e7cf31
> --
> https://chromeos.dev
>
> ___
> 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
SI: c02064c3 RDI:
> > 0007
> > [ 738.359096] RBP: c02064c3 R08: 00000003 R09:
> > 7f6b82b54bbc
> > [ 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
> > (&adev->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
e.
Finally why 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
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 hardware l
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 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
atomic_dec(&qdev->release_count);
> }
>
> static 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(&qdev->release_count);
>
> mutex_lock(&qdev->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
ced. Otherwise 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
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
> > &
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
e->event) {
> - complete_all(crtc->state->event->base.completion);
> - crtc->state->event = NULL;
> - }
> }
>
> static inline struct zynqmp_disp *crtc_to_disp(struct drm_crtc *crtc)
> @@ -1499,6 +1491,13 @@ zynqmp_disp_crtc_at
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
/* reset all the states of crtc/plane/encoder/connector */
> + 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_km
y thing I spotted 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
&
robe = sprd_dpu_probe,
> + .remove = sprd_dpu_remove,
> + .driver = {
> + .name = "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("GPL v2");
> diff --git a/drivers/gpu/drm/sprd/sprd_dpu.h b/drivers/gpu/drm/sprd/sprd_dpu.h
> new file mode 100644
> index 000..a937ba1
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/sprd_dpu.h
> @@ -0,0 +1,120 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#ifndef __SPRD_DPU_H__
> +#define __SPRD_DPU_H__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* DPU Layer registers offset */
> +#define DPU_LAY_REG_OFFSET 0x30
> +
> +enum {
> + SPRD_DPU_IF_DBI = 0,
> + SPRD_DPU_IF_DPI,
> + SPRD_DPU_IF_EDPI,
> + SPRD_DPU_IF_LIMIT
> +};
Above seems unused, so not sure what it is?
> +
> +enum {
> + DPU_LAYER_ROTATION_0,
> + DPU_LAYER_ROTATION_90,
> + DPU_LAYER_ROTATION_180,
> + DPU_LAYER_ROTATION_270,
> + DPU_LAYER_ROTATION_0_M,
> + DPU_LAYER_ROTATION_90_M,
> + DPU_LAYER_ROTATION_180_M,
> + DPU_LAYER_ROTATION_270_M,
> +};
Since this seems to be hw register definitions please use #define
constants and maybe move them to all the other register definitions too?
-Daniel
> +
> +/**
> + * Sprd DPU context structure
> + *
> + * @base: DPU controller base address
> + * @irq: IRQ number to install the handler for
> + * @if_type: The type of DPI interface, default is DPI mode.
> + * @vm: videomode structure to use for DPU and DPI initialization
> + * @stopped: indicates whether DPU are stopped
> + * @wait_queue: wait queue, used to wait for DPU shadow register update done
> and
> + * DPU stop register done interrupt signal.
> + * @evt_update: wait queue condition for DPU shadow register
> + * @evt_stop: wait queue condition for DPU stop register
> + */
> +struct dpu_context {
> + void __iomem *base;
> + int irq;
> + u8 if_type;
> + struct videomode vm;
> + bool stopped;
> + wait_queue_head_t wait_queue;
> + bool evt_update;
> + bool evt_stop;
> +};
> +
> +/**
> + * Sprd DPU device structure
> + *
> + * @crtc: DRM crtc
> + * @ctx: A pointer to the DPU's implementation specific context
> + */
> +struct sprd_dpu {
> + struct drm_crtc crtc;
> + struct drm_device *drm;
> + struct dpu_context ctx;
> +};
> +
> +static inline struct sprd_dpu *to_sprd_crtc(struct drm_crtc *crtc)
> +{
> + return container_of(crtc, struct sprd_dpu, crtc);
> +}
> +
> +static inline void
> +dpu_reg_set(struct dpu_context *ctx, u32 offset, u32 set_bits)
> +{
> + u32 bits = readl_relaxed(ctx->base + offset);
> +
> + writel(bits | set_bits, ctx->base + offset);
> +}
> +
> +static inline void
> +dpu_reg_clr(struct dpu_context *ctx, u32 offset, u32 clr_bits)
> +{
> + u32 bits = readl_relaxed(ctx->base + offset);
> +
> + writel(bits & ~clr_bits, ctx->base + offset);
> +}
> +
> +static inline u32
> +layer_reg_rd(struct dpu_context *ctx, u32 offset, int index)
> +{
> + u32 layer_offset = offset + index * DPU_LAY_REG_OFFSET;
> +
> + return readl(ctx->base + layer_offset);
> +}
> +
> +static inline void
> +layer_reg_wr(struct dpu_context *ctx, u32 offset, u32 cfg_bits, int index)
> +{
> + u32 layer_offset = offset + index * DPU_LAY_REG_OFFSET;
> +
> + writel(cfg_bits, ctx->base + layer_offset);
> +}
> +
> +void sprd_dpu_run(struct sprd_dpu *dpu);
> +void sprd_dpu_stop(struct sprd_dpu *dpu);
> +
> +#endif
> diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
> index ec101de..ca93be2 100644
> --- a/drivers/gpu/drm/sprd/sprd_drm.c
> +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> @@ -196,6 +196,7 @@ static struct platform_driver sprd_drm_driver = {
>
> static struct platform_driver *sprd_drm_drivers[] = {
> &sprd_drm_driver,
> + &sprd_dpu_driver,
> };
>
> static int __init sprd_drm_init(void)
> diff --git a/drivers/gpu/drm/sprd/sprd_drm.h b/drivers/gpu/drm/sprd/sprd_drm.h
> index 9781fd5..85d4a8b 100644
> --- a/drivers/gpu/drm/sprd/sprd_drm.h
> +++ b/drivers/gpu/drm/sprd/sprd_drm.h
> @@ -13,4 +13,6 @@ struct sprd_drm {
> struct drm_device drm;
> };
>
> +extern struct platform_driver sprd_dpu_driver;
> +
> #endif /* _SPRD_DRM_H_ */
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
#x27;s is kinda fine (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
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 a
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 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 y
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 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 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:
> >
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
> > >&
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
emented, vt defaults to using
> vc_visible_origin+offset, so it 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 Thu, Feb 4, 2021 at 9:13 AM Christian König wrote:
>
> Am 03.02.21 um 21:14 schrieb Hridya Valsaraju:
> > On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter wrote:
> >> On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote:
> >>> On Mon, Feb 1, 2021
On Wed, Feb 3, 2021 at 5:14 PM Daniel Vetter wrote:
>
> 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 wrot
On Wed, Feb 03, 2021 at 02:11:09PM -0800, Rob Clark wrote:
> On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd wrote:
> >
> > Quoting Rob Clark (2021-02-03 09:29:09)
> > > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, F
them up.
>
> In general I think we need to make it possible that both the in kernel OOM
> killer as well as userspace processes and handlers have access to that kind
> of data.
>
> The fdinfo approach as suggested in the other thread sounds like the easiest
> solution to me.
Yeah for OOM handling cgroups alone isn't enough as the interface - we
need to make sure that oom killer takes into account the system memory
usage (ideally zone aware, for CMA pools).
But to track that we still need that infrastructure first I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Daniel Vetter (2):
PCI: also set up legacy files only after sysfs init
PCI: Revoke mappings like devmem
drivers/pci/pci-sysfs.c
Acked-by: Bjorn Helgaas
Reviewed-by: Dan Williams
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-ar
nen
Cc: Borislav Petkov
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
arch/x86/kernel/cpu/sgx/encl.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index ee50a5010277..20a2dd5ba2b4 100644
--- a/arch/x86/kernel/c
.
Wire it up exactly like the existing code. Note that
pci_remove_legacy_files() doesn't need a check since the one for
pci_bus->legacy_io is sufficient.
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hub
On Fri, Feb 5, 2021 at 3:26 AM Jarkko Sakkinen wrote:
>
> On Thu, Feb 04, 2021 at 07:45:19PM +0100, Daniel Vetter wrote:
> > References:
> > https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
>
> What is the difference between this an
On Thu, Feb 4, 2021 at 10:50 PM Bjorn Helgaas wrote:
>
> [+cc Oliver, Pali, Krzysztof]
>
> s/also/Also/ in subject
>
> On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices
On Fri, Feb 5, 2021 at 11:04 AM Pali Rohár wrote:
>
> On Friday 05 February 2021 10:59:50 Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
> > >
> > > On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> > > > [+cc Ol
On Mon, Feb 8, 2021 at 9:51 PM John Stultz wrote:
> On Mon, Feb 8, 2021 at 2:08 AM Daniel Vetter wrote:
> > On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote:
> > > By default dma_buf_export() sets the exporter name to be
> > > KBUILD_MODNAME. Unfortunately t
,
> -format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> -format);
> + snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
>
> return buf->str;
> }
> --
> 2.29.2
>
> ___
> 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
| 1 +
> mm/migrate.c | 82 +---
> tools/testing/selftests/vm/hmm-tests.c| 49 +
> 14 files changed, 524 insertions(+), 101 deletions(-)
>
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
>
> On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > >
> > > Recent changes to pin_user_pages() prevent the creation of pinned pages in
> > > ZONE_MOVABLE. This series allows pinned page
On Tue, Feb 9, 2021 at 2:35 PM Jason Gunthorpe wrote:
>
> On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote:
> > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > >
> > > > Recent changes to pin_user_pages() prevent the
accounting needs with cgroups. That should work, and it will
allow Android to handle all the Android-ism in a clean way in upstream
code. Or that's at least the plan.
I think the only thing we identified that Android still needs on top
is the dma-buf sysfs stuff, so that shared buffers (which on An
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..d4a45518639c 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -85,6 +85,7 @@ struct vkms_device;
> struct vkms_config {
> bool writeback;
> bool cursor;
> + bool virtual_hw;
> /* only set when instantiated */
> struct vkms_device *dev;
> };
> @@ -127,6 +128,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *source_name,
> /* Composer Support */
> void vkms_composer_worker(struct work_struct *work);
> void vkms_set_composer(struct vkms_output *out, bool enabled);
> +void vkms_crtc_composer(struct vkms_crtc_state *crtc_state);
>
> /* Writeback */
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote:
> > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini
> > wrote:
> > >
> > > Add a virtual hardware or vblank-less mode as a modul
On Thu, Feb 25, 2021 at 2:27 PM Gerd Hoffmann wrote:
>
> On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote:
> > On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote:
> > > On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote:
> > > >
#ifndef __NVKM_PCI_AGP_H__
> > #define __NVKM_PCI_AGP_H__
> >
> > +/* SPDX-License-Identifier: MIT */
> > +#include "priv.h"
> > +#if IS_ENABLED(CONFIG_AGP)
> > void nvkm_agp_ctor(struct nvkm_pci *);
> > void nvkm_agp_dtor(struct nvkm_pci *);
> > void nvkm_agp_preinit(struct nvkm_pci *);
> > int nvkm_agp_init(struct nvkm_pci *);
> > void nvkm_agp_fini(struct nvkm_pci *);
> > -#endif
> > #else
> > static inline void nvkm_agp_ctor(struct nvkm_pci *pci) {}
> > static inline void nvkm_agp_dtor(struct nvkm_pci *pci) {}
> > @@ -17,3 +16,5 @@ static inline void nvkm_agp_preinit(struct nvkm_pci *pci)
> > {}
> > static inline int nvkm_agp_init(struct nvkm_pci *pci) { return -ENOSYS; }
> > static inline void nvkm_agp_fini(struct nvkm_pci *pci) {}
> > #endif
> > +
> > +#endif
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
noise, set the VM_PFNMAP in the
> system and cma heap's mmap handler.
>
> Cc: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Christian Koenig
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Chris Goldsworthy
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraj
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/dma-fence.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 90edf2b281b0..656e9ac2d028 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fe
t; create mode 100644 drivers/gpu/dxgkrnl/Makefile
> create mode 100644 drivers/gpu/dxgkrnl/d3dkmthk.h
> create mode 100644 drivers/gpu/dxgkrnl/dxgadapter.c
> create mode 100644 drivers/gpu/dxgkrnl/dxgkrnl.h
> create mode 100644 drivers/gpu/dxgkrnl/dxgmodule.c
> create mode 100644
be able to review any of this code anymore until that
> changes, sorry.
So you couldn't review the habanalabs driver either?
Get some consistency into your decision making as maintainer. And don't
tell me or anyone else that this is complicated, gpu and rdma driver folks
very much told you and Olof last year that this is what you're getting
yourself into.
Cheers, Daniel
PS: I guess congrats for figuring out you can't write a totally-not-a-gpu
accel driver without making kernel and userspace parts derivatives works
of each another. We told you that last year.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
on upstream that you provide some
> value.
Well there is some in the form of "more hw/platform support". But
given that gpus evolved rather fast, including the entire integration
ecosystem (it's by far not just the hw drivers that move quickly). So
that value deprecates a lot faster than for other kernel subsystems.
And all that's left is the pain of not breaking anything without
actually being able to evolve the overall stack in any meaningful way.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
wrote:
>
> On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo 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
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:
> > > &
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 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
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
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
On Wed, May 20, 2020 at 08:54:36AM +0200, Christian König wrote:
> Am 19.05.20 um 15:27 schrieb Daniel Vetter:
> > Do it uncontionally, there's a separate peek function with
> > dma_fence_is_signalled() which can be called from atomic context.
> >
> > v2: Cons
On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
> On 5/20/2020 2:34 AM, Daniel Vetter wrote:
> > On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > >
On Mon, May 11, 2020 at 06:12:32PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Daniel Vetter
> >Sent: Monday, May 11, 2020 5:12 AM
> >To: LKML
> >Cc: David Airlie ; Daniel Vetter ;
> >Intel Graphics
On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
> > >
> > > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
> > > >
&g
; aux_dev = drm_dp_aux_dev_get_by_minor(minor);
> if (!aux_dev)
> return -ENODEV;
>
> file->private_data = aux_dev;
> 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
nded for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ite the pid recorded
> > in the trace entry?
> >
> > The following patch does exactly that for the vm_grab_id() trace point, but
> > I'm not 100% sure if that is legal or not.
> >
> > Any ideas? Comments?
> >
> > Thanks,
> > Christian.
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
>
> On Tue, 11 Aug 2020, Daniel Vetter wrote:
>
> > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > > Hi Folks,
> > > I know this thread eventually dropped off due to not identifying
901 - 1000 of 3914 matches
Mail list logo
