Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote: > On Wed, 31 Jan 2024 at 11:11, Daniel Vetter wrote: > > > > On Wed, Jan 31, 2024 at 05:17:08AM +, Jason-JH Lin (林睿祥) wrote: > > > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > > > > > External email : Please do not click links or open attachments until > > > > you have verified the sender or the content. > > > > On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote: > > > > > Hi Maxime, Daniel, > > > > > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > > > disabling > > > > > the cursor plane, the old_state->legacy_cursor_update in > > > > > drm_atomic_wait_for_vblank() is set to true. > > > > > As the result, we are not actually waiting for a vlbank to wait for > > > > our > > > > > hardware to close the cursor plane. Subsequently, the execution > > > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > > > > > Could you please apply this patch to fix our problem? > > > > > Or are there any considerations for not applying this patch? > > > > > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > > > land > > > > it. > > > > > > > > > > Got it. I would add tested-by tag for mediatek SoC. > > > > > > > I'd be _very_ happy if someone else can take care of that ... > > > > > > > > There's also the potential issue that it might slow down some of the > > > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > > > think > > > > all the drivers where this matters have switched over to the async > > > > plane > > > > update stuff meanwhile. So hopefully that's good. > > > > > > > > > > I think all the drivers should have switched to async plane update. > > > > > > Can we add the checking condition to see if atomic_async_update/check > > > function are implemented? > > > > Pretty sure not all have done that, so really it boils down to whether we > > break a real user's use-case. Which pretty much can only be checked by > > merging the patch (hence the requirement to get as many acks as possible > > from display drivers) and then being willing to handle any fallout that's > > reported as regressions for a specific driver. > > > > It's a pile of work, at least when it goes south, that's why I'm looking > > for volunteers. > > I can check this on all sensible msm generations, including mdp4, but > it will be next week, after the FOSDEM. > > BTW, for technical reasons one of the msm platforms still has the > legacy cursor implementation might it be related? Yeah, msm is one of the drivers I had to change with some hacks to avoid really bad fallout. It should still work like before, but that's one that definitely needs testing. -Sima > > > > > Note that handling the fallout doesn't mean you have to fix that specific > > driver, the only realistic option might be to reinstate the legacy cursor > > behaviour, but as an explicit opt-in that only that specific driver > > enables. > > > > So maybe for next round of that patch it might be good to have a 2nd patch > > which implements this fallback plan in the shared atomic modeset code? > > > > Cheers, Sima > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, Jan 31, 2024 at 05:17:08AM +, Jason-JH Lin (林睿祥) wrote: > On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote: > > > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote: > > > Hi Maxime, Daniel, > > > > > > We encountered similar issue with mediatek SoCs. > > > > > > We have found that in drm_atomic_helper_commit_rpm(), when > > disabling > > > the cursor plane, the old_state->legacy_cursor_update in > > > drm_atomic_wait_for_vblank() is set to true. > > > As the result, we are not actually waiting for a vlbank to wait for > > our > > > hardware to close the cursor plane. Subsequently, the execution > > > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > > > buffer. This can lead to use-after-free issues with our hardware. > > > > > > Could you please apply this patch to fix our problem? > > > Or are there any considerations for not applying this patch? > > > > Mostly it needs someone to collect a pile of acks/tested-by and then > > land > > it. > > > > Got it. I would add tested-by tag for mediatek SoC. > > > I'd be _very_ happy if someone else can take care of that ... > > > > There's also the potential issue that it might slow down some of the > > legacy X11 use-cases that really needed a non-blocking cursor, but I > > think > > all the drivers where this matters have switched over to the async > > plane > > update stuff meanwhile. So hopefully that's good. > > > > I think all the drivers should have switched to async plane update. > > Can we add the checking condition to see if atomic_async_update/check > function are implemented? Pretty sure not all have done that, so really it boils down to whether we break a real user's use-case. Which pretty much can only be checked by merging the patch (hence the requirement to get as many acks as possible from display drivers) and then being willing to handle any fallout that's reported as regressions for a specific driver. It's a pile of work, at least when it goes south, that's why I'm looking for volunteers. Note that handling the fallout doesn't mean you have to fix that specific driver, the only realistic option might be to reinstate the legacy cursor behaviour, but as an explicit opt-in that only that specific driver enables. So maybe for next round of that patch it might be good to have a 2nd patch which implements this fallback plan in the shared atomic modeset code? Cheers, Sima > > Regards, > Jason-JH.Lin > > > Cheers, Sima > > > > > > Regards, > > > Jason-JH.Lin > > > > > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > > > The stuff never really worked, and leads to lots of fun because > > it > > > > > out-of-order frees atomic states. Which upsets KASAN, among > > other > > > > > things. > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support > > for > > > > > that > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > routines, doing something similar. > > > > > > > > > > For everyone else it's probably better to remove the use-after- > > free > > > > > bug, and encourage folks to use the async support instead. The > > > > > affected drivers which register a legacy cursor plane and don't > > > > > either > > > > > use the new async stuff or their own commit routine are: > > amdgpu, > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > vmwgfx. > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > Thanks for submitting that patch. It's been in the downstream RPi > > > > tree > > > > for a while, so I'd really like it to be merged eventually :) > > > > > > > > Acked-by: Maxime Ripard > > > > > > > > Maxime > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, Daniel, > > We encountered similar issue with mediatek SoCs. > > We have found that in drm_atomic_helper_commit_rpm(), when disabling > the cursor plane, the old_state->legacy_cursor_update in > drm_atomic_wait_for_vblank() is set to true. > As the result, we are not actually waiting for a vlbank to wait for our > hardware to close the cursor plane. Subsequently, the execution > proceeds to drm_atomic_helper_cleanup_planes() to free the cursor > buffer. This can lead to use-after-free issues with our hardware. > > Could you please apply this patch to fix our problem? > Or are there any considerations for not applying this patch? Mostly it needs someone to collect a pile of acks/tested-by and then land it. I'd be _very_ happy if someone else can take care of that ... There's also the potential issue that it might slow down some of the legacy X11 use-cases that really needed a non-blocking cursor, but I think all the drivers where this matters have switched over to the async plane update stuff meanwhile. So hopefully that's good. Cheers, Sima > > Regards, > Jason-JH.Lin > > On Tue, 2023-03-07 at 15:56 +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote: > > > The stuff never really worked, and leads to lots of fun because it > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > things. > > > > > > For async updates we now have a more solid solution with the > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > that > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > routines, doing something similar. > > > > > > For everyone else it's probably better to remove the use-after-free > > > bug, and encourage folks to use the async support instead. The > > > affected drivers which register a legacy cursor plane and don't > > > either > > > use the new async stuff or their own commit routine are: amdgpu, > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > vmwgfx. > > > > > > Inspired by an amdgpu bug report. > > > > Thanks for submitting that patch. It's been in the downstream RPi > > tree > > for a while, so I'd really like it to be merged eventually :) > > > > Acked-by: Maxime Ripard > > > > Maxime -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] Revert "drm/msm/gpu: Push gpu lock down past runpm"
On Wed, Jan 10, 2024 at 06:54:53AM -0800, Rob Clark wrote:
> On Wed, Jan 10, 2024 at 2:50 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 09, 2024 at 10:22:17AM -0800, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > This reverts commit abe2023b4cea192ab266b351fd38dc9dbd846df0.
> > >
> > > Changing the locking order means that scheduler/msm_job_run() can race
> > > with the recovery kthread worker, with the result that the GPU gets an
> > > extra runpm get when we are trying to power it off. Leaving the GPU in
> > > an unrecovered state.
> >
> > The recovery kthread is supposed to stop all the relevant schedulers,
> > which should remove any possible race conditions. So unless there's more
> > going on, or you have your own recovery kthread (don't, reuse the one from
> > the scheduler with your own work items, that's why you can provide that)
> > this looks like an incomplete/incorrect explanation ... ?
> >
> > Slightly confused
>
> msm still uses it's own recovery, which pre-dates the scheduler
> conversion. At one point (a yr or two back?) I started looking at
> integrating recovery w/ scheduler.. at the time I think you talked me
> out of it, but I don't remember the reason
hm ... most scheduler discussions I remember was around the "allocate your
own workqueue and hand that to scheduler to avoid races/deadlocks". Which
iirc Boris implemented a while ago. Once you have that workqueue you can
then also process any other error condition on there with the exact same
locking design (like hw error or page faults or whatever), not just
drm/sched tdr.
I don't remember anything else that ever came up at least at a fundamental
level ...
So if that discussion was older than 78efe21b6f8e ("drm/sched: Allow using
a dedicated workqueue for the timeout/fault tdr") you should be covered.
Fingers crossed :-)
Meanwhile if you do not use drm/sched tdr at all then doing the exact same
design but just on your own workqueue should also work. The critical thing
is really only:
- have one single-thread workqueue for all gpu recover
- bracket each handler in there with drm_sched_stop/start for all affected
engines
No more races!
Cheers, Sima
>
> BR,
> -R
>
> > -Sima
> >
> > >
> > > I'll need to come up with a different scheme for appeasing lockdep.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_gpu.c| 11 +--
> > > drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +--
> > > 2 files changed, 10 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > > index 095390774f22..655002b21b0d 100644
> > > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > > @@ -751,12 +751,14 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> > > msm_gem_submit *submit)
> > > struct msm_ringbuffer *ring = submit->ring;
> > > unsigned long flags;
> > >
> > > - pm_runtime_get_sync(>pdev->dev);
> > > + WARN_ON(!mutex_is_locked(>lock));
> > >
> > > - mutex_lock(>lock);
> > > + pm_runtime_get_sync(>pdev->dev);
> > >
> > > msm_gpu_hw_init(gpu);
> > >
> > > + submit->seqno = submit->hw_fence->seqno;
> > > +
> > > update_sw_cntrs(gpu);
> > >
> > > /*
> > > @@ -781,11 +783,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> > > msm_gem_submit *submit)
> > > gpu->funcs->submit(gpu, submit);
> > > gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
> > >
> > > - hangcheck_timer_reset(gpu);
> > > -
> > > - mutex_unlock(>lock);
> > > -
> > > pm_runtime_put(>pdev->dev);
> > > + hangcheck_timer_reset(gpu);
> > > }
> > >
> > > /*
> > > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > b/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > index e0ed27739449..548f5266a7d3 100644
> > > --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > @@ -21,8 +21,6 @@ static struct dma_fence *msm_job_run(struct
> > > drm_sched_job *job)
> > >
> > > msm_fence_init(submit->hw_fence, fctx);
> > >
> > > - submit->seqno = submit->hw_fence->seqno;
> > > -
> > > mutex_lock(>lru.lock);
> > >
> > > for (i = 0; i < submit->nr_bos; i++) {
> > > @@ -35,8 +33,13 @@ static struct dma_fence *msm_job_run(struct
> > > drm_sched_job *job)
> > >
> > > mutex_unlock(>lru.lock);
> > >
> > > + /* TODO move submit path over to using a per-ring lock.. */
> > > + mutex_lock(>lock);
> > > +
> > > msm_gpu_submit(gpu, submit);
> > >
> > > + mutex_unlock(>lock);
> > > +
> > > return dma_fence_get(submit->hw_fence);
> > > }
> > >
> > > --
> > > 2.43.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] Revert "drm/msm/gpu: Push gpu lock down past runpm"
On Tue, Jan 09, 2024 at 10:22:17AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> This reverts commit abe2023b4cea192ab266b351fd38dc9dbd846df0.
>
> Changing the locking order means that scheduler/msm_job_run() can race
> with the recovery kthread worker, with the result that the GPU gets an
> extra runpm get when we are trying to power it off. Leaving the GPU in
> an unrecovered state.
The recovery kthread is supposed to stop all the relevant schedulers,
which should remove any possible race conditions. So unless there's more
going on, or you have your own recovery kthread (don't, reuse the one from
the scheduler with your own work items, that's why you can provide that)
this looks like an incomplete/incorrect explanation ... ?
Slightly confused
-Sima
>
> I'll need to come up with a different scheme for appeasing lockdep.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c| 11 +--
> drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +--
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 095390774f22..655002b21b0d 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -751,12 +751,14 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit)
> struct msm_ringbuffer *ring = submit->ring;
> unsigned long flags;
>
> - pm_runtime_get_sync(>pdev->dev);
> + WARN_ON(!mutex_is_locked(>lock));
>
> - mutex_lock(>lock);
> + pm_runtime_get_sync(>pdev->dev);
>
> msm_gpu_hw_init(gpu);
>
> + submit->seqno = submit->hw_fence->seqno;
> +
> update_sw_cntrs(gpu);
>
> /*
> @@ -781,11 +783,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit)
> gpu->funcs->submit(gpu, submit);
> gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
>
> - hangcheck_timer_reset(gpu);
> -
> - mutex_unlock(>lock);
> -
> pm_runtime_put(>pdev->dev);
> + hangcheck_timer_reset(gpu);
> }
>
> /*
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuffer.c
> index e0ed27739449..548f5266a7d3 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> @@ -21,8 +21,6 @@ static struct dma_fence *msm_job_run(struct drm_sched_job
> *job)
>
> msm_fence_init(submit->hw_fence, fctx);
>
> - submit->seqno = submit->hw_fence->seqno;
> -
> mutex_lock(>lru.lock);
>
> for (i = 0; i < submit->nr_bos; i++) {
> @@ -35,8 +33,13 @@ static struct dma_fence *msm_job_run(struct drm_sched_job
> *job)
>
> mutex_unlock(>lru.lock);
>
> + /* TODO move submit path over to using a per-ring lock.. */
> + mutex_lock(>lock);
> +
> msm_gpu_submit(gpu, submit);
>
> + mutex_unlock(>lock);
> +
> return dma_fence_get(submit->hw_fence);
> }
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v4 1/3] drm/bridge: add transparent bridge helper
+ struct drm_aux_bridge_data *data;
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> + return -EINVAL;
> +
> + data = container_of(bridge, struct drm_aux_bridge_data, bridge);
> +
> + return drm_bridge_attach(bridge->encoder, data->next_bridge, bridge,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +}
> +
> +static const struct drm_bridge_funcs drm_aux_bridge_funcs = {
> + .attach = drm_aux_bridge_attach,
> +};
> +
> +static int drm_aux_bridge_probe(struct auxiliary_device *auxdev,
> +const struct auxiliary_device_id *id)
> +{
> + struct drm_aux_bridge_data *data;
> +
> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->dev = >dev;
> + data->next_bridge = devm_drm_of_get_bridge(>dev,
> auxdev->dev.of_node, 0, 0);
> + if (IS_ERR(data->next_bridge))
> + return dev_err_probe(>dev, PTR_ERR(data->next_bridge),
> + "failed to acquire drm_bridge\n");
> +
> + data->bridge.funcs = _aux_bridge_funcs;
> + data->bridge.of_node = data->dev->of_node;
> +
> + return devm_drm_bridge_add(data->dev, >bridge);
> +}
> +
> +static const struct auxiliary_device_id drm_aux_bridge_table[] = {
> + { .name = KBUILD_MODNAME ".aux_bridge" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(auxiliary, drm_aux_bridge_table);
> +
> +static struct auxiliary_driver drm_aux_bridge_drv = {
> + .name = "aux_bridge",
> + .id_table = drm_aux_bridge_table,
> + .probe = drm_aux_bridge_probe,
> +};
> +module_auxiliary_driver(drm_aux_bridge_drv);
> +
> +MODULE_AUTHOR("Dmitry Baryshkov ");
> +MODULE_DESCRIPTION("DRM transparent bridge");
> +MODULE_LICENSE("GPL");
> diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
> new file mode 100644
> index ..441ab3f0e920
> --- /dev/null
> +++ b/include/drm/bridge/aux-bridge.h
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + *
> + * Author: Dmitry Baryshkov
> + */
> +#ifndef DRM_AUX_BRIDGE_H
> +#define DRM_AUX_BRIDGE_H
> +
> +#if IS_ENABLED(CONFIG_DRM_AUX_BRIDGE)
> +int drm_aux_bridge_register(struct device *parent);
> +#else
> +static inline int drm_aux_bridge_register(struct device *parent)
> +{
> + return 0;
> +}
> +#endif
> +
> +#endif
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Freedreno] [PATCH] drm/msm/mdp5: Don't leak some plane state
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcount a few years ago
in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
early by tracking commits, v3.")
Fix it by using the right helpers.
Fixes: 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early
by tracking commits, v3.")
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reported-and-tested-by: do...@noisolation.com
Cc: do...@noisolation.com
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index bd2c4ac45601..0d5ff03cb091 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -130,8 +130,7 @@ static void mdp5_plane_destroy_state(struct drm_plane
*plane,
{
struct mdp5_plane_state *pstate = to_mdp5_plane_state(state);
- if (state->fb)
- drm_framebuffer_put(state->fb);
+ __drm_atomic_helper_plane_destroy_state(state);
kfree(pstate);
}
--
2.40.1
Re: [Freedreno] [PATCH 4/4] drm/msm: Remove vma use tracking
On Wed, Aug 02, 2023 at 03:21:52PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This was not strictly necessary, as page unpinning (ie. shrinker) only
> cares about the resv. It did give us some extra sanity checking for
> userspace controlled iova, and was useful to catch issues on kernel and
> userspace side when enabling userspace iova. But if userspace screws
> this up, it just corrupts it's own gpu buffers and/or gets iova faults.
> So we can just let userspace shoot it's own foot and drop the extra per-
> buffer SUBMIT overhead.
>
> Signed-off-by: Rob Clark
I did check a few things (like that the gem lru helpers have all the
needed lockdep_assert_held) and I think aside from the optimization this
is a nice semantic cleanup. Since iirc we've had a locking inversion
discussion and the vma tracking here came up as a culprit. On the series:
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/msm/msm_gem.c| 9 +---
> drivers/gpu/drm/msm/msm_gem.h| 12 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 14 ++
> drivers/gpu/drm/msm/msm_gem_vma.c| 67 +---
> drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +-
> 5 files changed, 9 insertions(+), 96 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 1c81ff6115ac..ce1ed0f9ad2d 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -607,9 +607,6 @@ static int clear_iova(struct drm_gem_object *obj,
> if (!vma)
> return 0;
>
> - if (msm_gem_vma_inuse(vma))
> - return -EBUSY;
> -
> msm_gem_vma_purge(vma);
> msm_gem_vma_close(vma);
> del_vma(vma);
> @@ -660,7 +657,6 @@ void msm_gem_unpin_iova(struct drm_gem_object *obj,
> msm_gem_lock(obj);
> vma = lookup_vma(obj, aspace);
> if (!GEM_WARN_ON(!vma)) {
> - msm_gem_vma_unpin(vma);
> msm_gem_unpin_locked(obj);
> }
> msm_gem_unlock(obj);
> @@ -991,11 +987,10 @@ void msm_gem_describe(struct drm_gem_object *obj,
> struct seq_file *m,
> } else {
> name = comm = NULL;
> }
> - seq_printf(m, " [%s%s%s: aspace=%p,
> %08llx,%s,inuse=%d]",
> + seq_printf(m, " [%s%s%s: aspace=%p, %08llx,%s]",
> name, comm ? ":" : "", comm ? comm : "",
> vma->aspace, vma->iova,
> - vma->mapped ? "mapped" : "unmapped",
> - msm_gem_vma_inuse(vma));
> + vma->mapped ? "mapped" : "unmapped");
> kfree(comm);
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 2ddd896aac68..8ddef5443140 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -59,24 +59,16 @@ struct msm_fence_context;
>
> struct msm_gem_vma {
> struct drm_mm_node node;
> - spinlock_t lock;
> uint64_t iova;
> struct msm_gem_address_space *aspace;
> struct list_head list;/* node in msm_gem_object::vmas */
> bool mapped;
> - int inuse;
> - uint32_t fence_mask;
> - uint32_t fence[MSM_GPU_MAX_RINGS];
> - struct msm_fence_context *fctx[MSM_GPU_MAX_RINGS];
> };
>
> struct msm_gem_vma *msm_gem_vma_new(struct msm_gem_address_space *aspace);
> int msm_gem_vma_init(struct msm_gem_vma *vma, int size,
> u64 range_start, u64 range_end);
> -bool msm_gem_vma_inuse(struct msm_gem_vma *vma);
> void msm_gem_vma_purge(struct msm_gem_vma *vma);
> -void msm_gem_vma_unpin(struct msm_gem_vma *vma);
> -void msm_gem_vma_unpin_fenced(struct msm_gem_vma *vma, struct
> msm_fence_context *fctx);
> int msm_gem_vma_map(struct msm_gem_vma *vma, int prot, struct sg_table *sgt,
> int size);
> void msm_gem_vma_close(struct msm_gem_vma *vma);
>
> @@ -298,15 +290,13 @@ struct msm_gem_submit {
> /* make sure these don't conflict w/ MSM_SUBMIT_BO_x */
> #define BO_VALID 0x8000 /* is current addr in cmdstream correct/valid?
> */
> #define BO_LOCKED0x4000 /* obj lock is held */
> -#define BO_OBJ_PINNED0x2000 /* obj (pages) is pinned and on active
> list */
> -#define BO_VMA_PINNED0x1000 /* vma (virtual address) is pinned */
> +#define BO_PINNED0x2000 /* obj (pages) is pinned and on active list */
> uint32_t flags;
> union {
> struct drm_gem_object *obj;
>
Re: [Freedreno] [RFC] drm/msm: Disallow relocs on a6xx+
On Wed, Aug 02, 2023 at 03:10:44PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Mesa stopped using these pretty early in a6xx bringup. Take advantage
> of this to disallow some legacy UABI.
>
> Signed-off-by: Rob Clark
> ---
> So, it was late 2018 when mesa stopped using relocs. At that point a6xx
> support was still in a pretty early state. I guess you _could_ use such
> an old version of mesa with a6xx hw.. but you really shouldn't.
Acked-by: Daniel Vetter
Might be good to cite the mesa commit that removed the a6xx reloc code in
the commit message.
-Sima
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 ++
> drivers/gpu/drm/msm/msm_gem_submit.c| 10 ++
> drivers/gpu/drm/msm/msm_gpu.h | 9 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index ba35c2a87021..695cce82d914 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -1078,6 +1078,8 @@ int adreno_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> adreno_gpu->info = config->info;
> adreno_gpu->chip_id = config->chip_id;
>
> + gpu->allow_relocs = config->info->family < ADRENO_6XX_GEN1;
> +
> /* Only handle the core clock when GMU is not in use (or is absent). */
> if (adreno_has_gmu_wrapper(adreno_gpu) ||
> adreno_gpu->info->family < ADRENO_6XX_GEN1) {
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 63c96416e183..3b908f9f5493 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -882,6 +882,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (submit->valid)
> continue;
>
> + if (!gpu->allow_relocs) {
> + if (submit->cmd[i].nr_relocs) {
> + DRM_ERROR("relocs not allowed\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + continue;
> + }
> +
> ret = submit_reloc(submit, msm_obj, submit->cmd[i].offset * 4,
> submit->cmd[i].nr_relocs,
> submit->cmd[i].relocs);
> if (ret)
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 7a4fa1b8655b..4252e3839fbc 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -285,6 +285,15 @@ struct msm_gpu {
> /* True if the hardware supports expanded apriv (a650 and newer) */
> bool hw_apriv;
>
> + /**
> + * @allow_relocs: allow relocs in SUBMIT ioctl
> + *
> + * Mesa won't use relocs for driver version 1.4.0 and later. This
> + * switch-over happened early enough in mesa a6xx bringup that we
> + * can disallow relocs for a6xx and newer.
> + */
> + bool allow_relocs;
> +
> struct thermal_cooling_device *cooling;
> };
>
> --
> 2.41.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 1/3] drm: Create support for Write-Only property blob
On Fri, Apr 21, 2023 at 12:27:47PM -0400, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> User space might need to inject data into the kernel without allowing it
> to be read again by any user space.
> An example of where this is particularly useful is secret keys fetched
> by user space and injected into the kernel to enable content protection.
>
> [How]
> Create a DRM_MODE_CREATE_BLOB_WRITE_ONLY flag used by user space to
> create a blob and mark the blob as write only.
> On reading back the blob, data will be not be copied if it's a write
> only blob
This makes no sense at all, why would you want to disallow reading?
Userspace already knows the key, there's not much point in hiding it from
userspace?
Also for new uapi we need the igt patches and userspace, please link
those.
-Daniel
>
> Signed-off-by: Mark Yacoub
> ---
> drivers/gpu/drm/drm_property.c | 3 ++-
> include/drm/drm_property.h | 2 ++
> include/uapi/drm/drm_mode.h| 6 ++
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index dfec479830e49..afedf7109d002 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -765,7 +765,7 @@ int drm_mode_getblob_ioctl(struct drm_device *dev,
> if (!blob)
> return -ENOENT;
>
> - if (out_resp->length == blob->length) {
> + if (out_resp->length == blob->length && !blob->is_write_only) {
> if (copy_to_user(u64_to_user_ptr(out_resp->data),
>blob->data,
>blob->length)) {
> @@ -800,6 +800,7 @@ int drm_mode_createblob_ioctl(struct drm_device *dev,
> ret = -EFAULT;
> goto out_blob;
> }
> + blob->is_write_only = out_resp->flags & DRM_MODE_CREATE_BLOB_WRITE_ONLY;
>
> /* Dropping the lock between create_blob and our access here is safe
>* as only the same file_priv can remove the blob; at this point, it is
> diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> index 65bc9710a4702..700782f021b99 100644
> --- a/include/drm/drm_property.h
> +++ b/include/drm/drm_property.h
> @@ -205,6 +205,7 @@ struct drm_property {
> * _mode_config.property_blob_list.
> * @head_file: entry on the per-file blob list in _file.blobs list.
> * @length: size of the blob in bytes, invariant over the lifetime of the
> object
> + * @is_write_only: user space can't read the blob data.
> * @data: actual data, embedded at the end of this structure
> *
> * Blobs are used to store bigger values than what fits directly into the 64
> @@ -219,6 +220,7 @@ struct drm_property_blob {
> struct list_head head_global;
> struct list_head head_file;
> size_t length;
> + bool is_write_only;
> void *data;
> };
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 46becedf5b2fc..10403c9a73082 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1168,6 +1168,9 @@ struct drm_format_modifier {
> __u64 modifier;
> };
>
> +#define DRM_MODE_CREATE_BLOB_WRITE_ONLY
> \
> + (1 << 0) /* data of the blob can't be read by user space */
> +
> /**
> * struct drm_mode_create_blob - Create New blob property
> *
> @@ -1181,6 +1184,9 @@ struct drm_mode_create_blob {
> __u32 length;
> /** @blob_id: Return: new property ID. */
> __u32 blob_id;
> + /** Flags for special handling. */
> + __u32 flags;
> + __u32 pad;
> };
>
> /**
> --
> 2.40.0.634.g4ca3ef3211-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [RFC 2/3] drm/msm: Rework get_comm_cmdline() helper
On Fri, Apr 21, 2023 at 07:47:26AM -0700, Rob Clark wrote:
> On Fri, Apr 21, 2023 at 2:33 AM Emil Velikov wrote:
> >
> > Greeting all,
> >
> > Sorry for the delay - Easter Holidays, food coma and all that :-)
> >
> > On Tue, 18 Apr 2023 at 15:31, Rob Clark wrote:
> > >
> > > On Tue, Apr 18, 2023 at 1:34 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Apr 18, 2023 at 09:27:49AM +0100, Tvrtko Ursulin wrote:
> > > > >
> > > > > On 17/04/2023 21:12, Rob Clark wrote:
> > > > > > From: Rob Clark
> > > > > >
> > > > > > Make it work in terms of ctx so that it can be re-used for fdinfo.
> > > > > >
> > > > > > Signed-off-by: Rob Clark
> > > > > > ---
> > > > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++--
> > > > > > drivers/gpu/drm/msm/msm_drv.c | 2 ++
> > > > > > drivers/gpu/drm/msm/msm_gpu.c | 13 ++---
> > > > > > drivers/gpu/drm/msm/msm_gpu.h | 12 ++--
> > > > > > drivers/gpu/drm/msm/msm_submitqueue.c | 1 +
> > > > > > 5 files changed, 21 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > index bb38e728864d..43c4e1fea83f 100644
> > > > > > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > > @@ -412,7 +412,7 @@ int adreno_set_param(struct msm_gpu *gpu,
> > > > > > struct msm_file_private *ctx,
> > > > > > /* Ensure string is null terminated: */
> > > > > > str[len] = '\0';
> > > > > > - mutex_lock(>lock);
> > > > > > + mutex_lock(>lock);
> > > > > > if (param == MSM_PARAM_COMM) {
> > > > > > paramp = >comm;
> > > > > > @@ -423,7 +423,7 @@ int adreno_set_param(struct msm_gpu *gpu,
> > > > > > struct msm_file_private *ctx,
> > > > > > kfree(*paramp);
> > > > > > *paramp = str;
> > > > > > - mutex_unlock(>lock);
> > > > > > + mutex_unlock(>lock);
> > > > > > return 0;
> > > > > > }
> > > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> > > > > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > > > index 3d73b98d6a9c..ca0e89e46e13 100644
> > > > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > > > @@ -581,6 +581,8 @@ static int context_init(struct drm_device *dev,
> > > > > > struct drm_file *file)
> > > > > > rwlock_init(>queuelock);
> > > > > > kref_init(>ref);
> > > > > > + ctx->pid = get_pid(task_pid(current));
> > > > >
> > > > > Would it simplify things for msm if DRM core had an up to date
> > > > > file->pid as
> > > > > proposed in
> > > > > https://patchwork.freedesktop.org/patch/526752/?series=109902=4 ?
> > > > > It
> > > > > gets updated if ioctl issuer is different than fd opener and this
> > > > > being
> > > > > context_init here reminded me of it. Maybe you wouldn't have to track
> > > > > the
> > > > > pid in msm?
> > >
> > > The problem is that we also need this for gpu devcore dumps, which
> > > could happen after the drm_file is closed. The ctx can outlive the
> > > file.
> > >
> > I think we all kept forgetting about that. MSM had support for ages,
> > while AMDGPU is the second driver to land support - just a release
> > ago.
> >
> > > But the ctx->pid has the same problem as the existing file->pid when
> > > it comes to Xorg.. hopefully over time that problem just goes away.
> >
> > Out of curiosity: what do you mean with "when it comes to Xorg" - the
> > "was_master" handling or something else?
>
> The problem is that Xorg is the one to open the drm fd, and then
> passes the fd to the client.. so the pid of drm_file is the Xorg p
Re: [Freedreno] [RFC 2/3] drm/msm: Rework get_comm_cmdline() helper
->ctx, , );
> > /*
> > * When we get GPU iova faults, we can get 1000s of them,
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> > index 7a4fa1b8655b..b2023a42116b 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.h
> > +++ b/drivers/gpu/drm/msm/msm_gpu.h
> > @@ -377,17 +377,25 @@ struct msm_file_private {
> > */
> > int sysprof;
> > + /** @pid: Process that opened this file. */
> > + struct pid *pid;
> > +
> > + /**
> > +* lock: Protects comm and cmdline
> > +*/
> > + struct mutex lock;
> > +
> > /**
> > * comm: Overridden task comm, see MSM_PARAM_COMM
> > *
> > -* Accessed under msm_gpu::lock
> > + * Accessed under msm_file_private::lock
> > */
> > char *comm;
> > /**
> > * cmdline: Overridden task cmdline, see MSM_PARAM_CMDLINE
> > *
> > -* Accessed under msm_gpu::lock
> > +* Accessed under msm_file_private::lock
> > */
> > char *cmdline;
> > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > index 0e803125a325..0444ba04fa06 100644
> > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > @@ -61,6 +61,7 @@ void __msm_file_private_destroy(struct kref *kref)
> > }
> > msm_gem_address_space_put(ctx->aspace);
> > + put_pid(ctx->pid);
> > kfree(ctx->comm);
> > kfree(ctx->cmdline);
> > kfree(ctx);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
On Fri, Apr 14, 2023 at 06:40:27AM -0700, Rob Clark wrote: > On Fri, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin > wrote: > > > > > > On 13/04/2023 21:05, Daniel Vetter wrote: > > > On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote: > > >> > > >> On 13/04/2023 14:27, Daniel Vetter wrote: > > >>> On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote: > > >>>> > > >>>> On 12/04/2023 20:18, Daniel Vetter wrote: > > >>>>> On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote: > > >>>>>> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter > > >>>>>> wrote: > > >>>>>>> > > >>>>>>> On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote: > > >>>>>>>> On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On 11/04/2023 23:56, Rob Clark wrote: > > >>>>>>>>>> From: Rob Clark > > >>>>>>>>>> > > >>>>>>>>>> Add support to dump GEM stats to fdinfo. > > >>>>>>>>>> > > >>>>>>>>>> v2: Fix typos, change size units to match docs, use div_u64 > > >>>>>>>>>> v3: Do it in core > > >>>>>>>>>> > > >>>>>>>>>> Signed-off-by: Rob Clark > > >>>>>>>>>> Reviewed-by: Emil Velikov > > >>>>>>>>>> --- > > >>>>>>>>>> Documentation/gpu/drm-usage-stats.rst | 21 > > >>>>>>>>>> drivers/gpu/drm/drm_file.c| 76 > > >>>>>>>>>> +++ > > >>>>>>>>>> include/drm/drm_file.h| 1 + > > >>>>>>>>>> include/drm/drm_gem.h | 19 +++ > > >>>>>>>>>> 4 files changed, 117 insertions(+) > > >>>>>>>>>> > > >>>>>>>>>> diff --git a/Documentation/gpu/drm-usage-stats.rst > > >>>>>>>>>> b/Documentation/gpu/drm-usage-stats.rst > > >>>>>>>>>> index b46327356e80..b5e7802532ed 100644 > > >>>>>>>>>> --- a/Documentation/gpu/drm-usage-stats.rst > > >>>>>>>>>> +++ b/Documentation/gpu/drm-usage-stats.rst > > >>>>>>>>>> @@ -105,6 +105,27 @@ object belong to this client, in the > > >>>>>>>>>> respective memory region. > > >>>>>>>>>> Default unit shall be bytes with optional unit specifiers > > >>>>>>>>>> of 'KiB' or 'MiB' > > >>>>>>>>>> indicating kibi- or mebi-bytes. > > >>>>>>>>>> > > >>>>>>>>>> +- drm-shared-memory: [KiB|MiB] > > >>>>>>>>>> + > > >>>>>>>>>> +The total size of buffers that are shared with another file > > >>>>>>>>>> (ie. have more > > >>>>>>>>>> +than a single handle). > > >>>>>>>>>> + > > >>>>>>>>>> +- drm-private-memory: [KiB|MiB] > > >>>>>>>>>> + > > >>>>>>>>>> +The total size of buffers that are not shared with another file. > > >>>>>>>>>> + > > >>>>>>>>>> +- drm-resident-memory: [KiB|MiB] > > >>>>>>>>>> + > > >>>>>>>>>> +The total size of buffers that are resident in system memory. > > >>>>>>>>> > > >>>>>>>>> I think this naming maybe does not work best with the existing > > >>>>>>>>> drm-memory- keys. > > >>>>>>>> > > >>>>>>>> Actually, it was very deliberate not to conflict with the existing > > >>>>>>>> drm-memory- keys ;-) &g
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
On Fri, 14 Apr 2023 at 10:57, Tvrtko Ursulin
wrote:
> On 13/04/2023 21:05, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 13/04/2023 14:27, Daniel Vetter wrote:
> >>> On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
> >>>>
> >>>> On 12/04/2023 20:18, Daniel Vetter wrote:
> >>>>> On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> >>>>>> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> >>>>>>>
> >>>>>>> On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> >>>>>>>> On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 11/04/2023 23:56, Rob Clark wrote:
> >>>>>>>>>> From: Rob Clark
> >>>>>>>>>>
> >>>>>>>>>> Add support to dump GEM stats to fdinfo.
> >>>>>>>>>>
> >>>>>>>>>> v2: Fix typos, change size units to match docs, use div_u64
> >>>>>>>>>> v3: Do it in core
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Rob Clark
> >>>>>>>>>> Reviewed-by: Emil Velikov
> >>>>>>>>>> ---
> >>>>>>>>>> Documentation/gpu/drm-usage-stats.rst | 21
> >>>>>>>>>> drivers/gpu/drm/drm_file.c| 76
> >>>>>>>>>> +++
> >>>>>>>>>> include/drm/drm_file.h| 1 +
> >>>>>>>>>> include/drm/drm_gem.h | 19 +++
> >>>>>>>>>> 4 files changed, 117 insertions(+)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >>>>>>>>>> b/Documentation/gpu/drm-usage-stats.rst
> >>>>>>>>>> index b46327356e80..b5e7802532ed 100644
> >>>>>>>>>> --- a/Documentation/gpu/drm-usage-stats.rst
> >>>>>>>>>> +++ b/Documentation/gpu/drm-usage-stats.rst
> >>>>>>>>>> @@ -105,6 +105,27 @@ object belong to this client, in the
> >>>>>>>>>> respective memory region.
> >>>>>>>>>> Default unit shall be bytes with optional unit specifiers of
> >>>>>>>>>> 'KiB' or 'MiB'
> >>>>>>>>>> indicating kibi- or mebi-bytes.
> >>>>>>>>>>
> >>>>>>>>>> +- drm-shared-memory: [KiB|MiB]
> >>>>>>>>>> +
> >>>>>>>>>> +The total size of buffers that are shared with another file (ie.
> >>>>>>>>>> have more
> >>>>>>>>>> +than a single handle).
> >>>>>>>>>> +
> >>>>>>>>>> +- drm-private-memory: [KiB|MiB]
> >>>>>>>>>> +
> >>>>>>>>>> +The total size of buffers that are not shared with another file.
> >>>>>>>>>> +
> >>>>>>>>>> +- drm-resident-memory: [KiB|MiB]
> >>>>>>>>>> +
> >>>>>>>>>> +The total size of buffers that are resident in system memory.
> >>>>>>>>>
> >>>>>>>>> I think this naming maybe does not work best with the existing
> >>>>>>>>> drm-memory- keys.
> >>>>>>>>
> >>>>>>>> Actually, it was very deliberate not to conflict with the existing
> >>>>>>>> drm-memory- keys ;-)
> >>>>>>>>
> >>>>>>>> I wouldn't have preferred drm-memory-{active,resident,...} but it
> >>>>>>>> could be mis-parsed by existing userspace so my hands were a bit
> >>>>>>>> tied.
> >>>>>>>>
> >>>>>>>>> How about introduce the concept of a memory region from the start
> >>>>&
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
>
> On 13/04/2023 14:27, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 12/04/2023 20:18, Daniel Vetter wrote:
> > > > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> > > > > On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > > > > > > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > > > > > > From: Rob Clark
> > > > > > > > >
> > > > > > > > > Add support to dump GEM stats to fdinfo.
> > > > > > > > >
> > > > > > > > > v2: Fix typos, change size units to match docs, use div_u64
> > > > > > > > > v3: Do it in core
> > > > > > > > >
> > > > > > > > > Signed-off-by: Rob Clark
> > > > > > > > > Reviewed-by: Emil Velikov
> > > > > > > > > ---
> > > > > > > > > Documentation/gpu/drm-usage-stats.rst | 21
> > > > > > > > > drivers/gpu/drm/drm_file.c| 76
> > > > > > > > > +++
> > > > > > > > > include/drm/drm_file.h| 1 +
> > > > > > > > > include/drm/drm_gem.h | 19 +++
> > > > > > > > > 4 files changed, 117 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > index b46327356e80..b5e7802532ed 100644
> > > > > > > > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > > > @@ -105,6 +105,27 @@ object belong to this client, in the
> > > > > > > > > respective memory region.
> > > > > > > > > Default unit shall be bytes with optional unit specifiers
> > > > > > > > > of 'KiB' or 'MiB'
> > > > > > > > > indicating kibi- or mebi-bytes.
> > > > > > > > >
> > > > > > > > > +- drm-shared-memory: [KiB|MiB]
> > > > > > > > > +
> > > > > > > > > +The total size of buffers that are shared with another file
> > > > > > > > > (ie. have more
> > > > > > > > > +than a single handle).
> > > > > > > > > +
> > > > > > > > > +- drm-private-memory: [KiB|MiB]
> > > > > > > > > +
> > > > > > > > > +The total size of buffers that are not shared with another
> > > > > > > > > file.
> > > > > > > > > +
> > > > > > > > > +- drm-resident-memory: [KiB|MiB]
> > > > > > > > > +
> > > > > > > > > +The total size of buffers that are resident in system memory.
> > > > > > > >
> > > > > > > > I think this naming maybe does not work best with the existing
> > > > > > > > drm-memory- keys.
> > > > > > >
> > > > > > > Actually, it was very deliberate not to conflict with the existing
> > > > > > > drm-memory- keys ;-)
> > > > > > >
> > > > > > > I wouldn't have preferred drm-memory-{active,resident,...} but it
> > > > > > > could be mis-parsed by existing userspace so my hands were a bit
> > > > > > > tied.
> > > > > > >
> > > > > > > > How about introduce the concept of a memory region from the
> > > > > > > > start and
> > > > > > > > use naming similar like we do for engines?
> > > > > > > >
> >
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/2023 20:18, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> > > On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> > > >
> > > > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > > > > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > > > > From: Rob Clark
> > > > > > >
> > > > > > > Add support to dump GEM stats to fdinfo.
> > > > > > >
> > > > > > > v2: Fix typos, change size units to match docs, use div_u64
> > > > > > > v3: Do it in core
> > > > > > >
> > > > > > > Signed-off-by: Rob Clark
> > > > > > > Reviewed-by: Emil Velikov
> > > > > > > ---
> > > > > > >Documentation/gpu/drm-usage-stats.rst | 21
> > > > > > >drivers/gpu/drm/drm_file.c| 76
> > > > > > > +++
> > > > > > >include/drm/drm_file.h| 1 +
> > > > > > >include/drm/drm_gem.h | 19 +++
> > > > > > >4 files changed, 117 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > index b46327356e80..b5e7802532ed 100644
> > > > > > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > > > > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > > > > > @@ -105,6 +105,27 @@ object belong to this client, in the
> > > > > > > respective memory region.
> > > > > > >Default unit shall be bytes with optional unit specifiers of
> > > > > > > 'KiB' or 'MiB'
> > > > > > >indicating kibi- or mebi-bytes.
> > > > > > >
> > > > > > > +- drm-shared-memory: [KiB|MiB]
> > > > > > > +
> > > > > > > +The total size of buffers that are shared with another file (ie.
> > > > > > > have more
> > > > > > > +than a single handle).
> > > > > > > +
> > > > > > > +- drm-private-memory: [KiB|MiB]
> > > > > > > +
> > > > > > > +The total size of buffers that are not shared with another file.
> > > > > > > +
> > > > > > > +- drm-resident-memory: [KiB|MiB]
> > > > > > > +
> > > > > > > +The total size of buffers that are resident in system memory.
> > > > > >
> > > > > > I think this naming maybe does not work best with the existing
> > > > > > drm-memory- keys.
> > > > >
> > > > > Actually, it was very deliberate not to conflict with the existing
> > > > > drm-memory- keys ;-)
> > > > >
> > > > > I wouldn't have preferred drm-memory-{active,resident,...} but it
> > > > > could be mis-parsed by existing userspace so my hands were a bit tied.
> > > > >
> > > > > > How about introduce the concept of a memory region from the start
> > > > > > and
> > > > > > use naming similar like we do for engines?
> > > > > >
> > > > > > drm-memory-$CATEGORY-$REGION: ...
> > > > > >
> > > > > > Then we document a bunch of categories and their semantics, for
> > > > > > instance:
> > > > > >
> > > > > > 'size' - All reachable objects
> > > > > > 'shared' - Subset of 'size' with handle_count > 1
> > > > > > 'resident' - Objects with backing store
> > > > > > 'active' - Objects in use, subset of resident
> > > > > > 'purgeable' - Or inactive? Subset of resident.
> > > > > >
> > > > > > We keep the same semantics as with process memory accounting (if I
> > > > > > got
> > > > > > it right) which could be desirable for a simplified mental model.
> > > > > >
> >
Re: [Freedreno] [PATCH v4 1/6] drm: Add common fdinfo helper
On Thu, Apr 13, 2023 at 10:07:11AM +0200, Christian König wrote:
> Am 13.04.23 um 00:42 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Handle a bit of the boiler-plate in a single case, and make it easier to
> > add some core tracked stats.
> >
> > v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
> >
> > Reviewed-by: Daniel Vetter
> > Signed-off-by: Rob Clark
> > ---
> > Documentation/gpu/drm-usage-stats.rst | 10 +++-
> > drivers/gpu/drm/drm_file.c| 35 +++
> > include/drm/drm_drv.h | 7 ++
> > include/drm/drm_file.h| 4 +++
> > 4 files changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > b/Documentation/gpu/drm-usage-stats.rst
> > index b46327356e80..2ab32c40e93c 100644
> > --- a/Documentation/gpu/drm-usage-stats.rst
> > +++ b/Documentation/gpu/drm-usage-stats.rst
> > @@ -126,7 +126,15 @@ percentage utilization of the engine, whereas
> > drm-engine- only reflects
> > time active without considering what frequency the engine is operating as
> > a
> > percentage of it's maximum frequency.
> > +Implementation Details
> > +==
> > +
> > +Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
> > +implement _driver.show_fdinfo if they wish to provide any stats which
> > +are not provided by drm_show_fdinfo(). But even driver specific stats
> > should
> > +be documented above and where possible, aligned with other drivers.
>
> I'm really wondering if it wouldn't be less mid-layering if we let the
> drivers call the drm function to print the common values instead of the
> other way around?
The idea is that we plug this into DRM_GEM_FOPS and then everyone gets it
by default. So it's a bit a tradeoff between midlayering and having
inconsistent uapi between drivers. And there's generic tools that parse
this, so consistency across drivers is good.
My gut feeling was that after a bit of experimenting with lots of
different drivers for fdinfo stuff it's time to push for a bit more
standardization and less fragmentation.
We can of course later on course-correct and shuffle things around again,
e.g. by pushing more things into the gem_bo_fops->status hook (ttm and
other memory manager libs could implement a decent one by default), or
moving more into the drm_driver->show_fdinfo callback again.
If you look at kms we also shuffle things back between core (for
more consistency) and drivers (for more flexibility where needed).
The important part here imo is that we start with some scaffolding to be
able to do this. Like another thing that I think we want is some
drm_fdinfo_print functions that make sure the formatting is guaranteed
consistents and we don't trip up parsers (like some drivers use " \t" as
separator instead of just "\t", I guess by accident).
> Apart from thatquestion the patch looks good to me.
Ack? Or want the above recorded in the commit message, I think it'd make
sense to put it there.
-Daniel
>
> Christian.
>
> > +
> > Driver specific implementations
> > -===
> > +---
> > :ref:`i915-usage-stats`
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index a51ff8cee049..6d5bdd684ae2 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
> >*/
> > struct drm_file *drm_file_alloc(struct drm_minor *minor)
> > {
> > + static atomic64_t ident = ATOMIC_INIT(0);
> > struct drm_device *dev = minor->dev;
> > struct drm_file *file;
> > int ret;
> > @@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
> > if (!file)
> > return ERR_PTR(-ENOMEM);
> > + /* Get a unique identifier for fdinfo: */
> > + file->client_id = atomic64_inc_return();
> > file->pid = get_pid(task_pid(current));
> > file->minor = minor;
> > @@ -868,6 +871,38 @@ void drm_send_event(struct drm_device *dev, struct
> > drm_pending_event *e)
> > }
> > EXPORT_SYMBOL(drm_send_event);
> > +/**
> > + * drm_show_fdinfo - helper for drm file fops
> > + * @seq_file: output stream
> > + * @f: the device file instance
> > + *
> > + * Helper to implement fdinfo, for userspace to query usage stats, etc, of
> > a
> > + * process using the GPU. See also _driver.show_fdinfo.
> > + *
> >
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> > > wrote:
> > > >
> > > >
> > > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > > From: Rob Clark
> > > > >
> > > > > Add support to dump GEM stats to fdinfo.
> > > > >
> > > > > v2: Fix typos, change size units to match docs, use div_u64
> > > > > v3: Do it in core
> > > > >
> > > > > Signed-off-by: Rob Clark
> > > > > Reviewed-by: Emil Velikov
> > > > > ---
> > > > > Documentation/gpu/drm-usage-stats.rst | 21
> > > > > drivers/gpu/drm/drm_file.c| 76
> > > > > +++
> > > > > include/drm/drm_file.h| 1 +
> > > > > include/drm/drm_gem.h | 19 +++
> > > > > 4 files changed, 117 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > > > b/Documentation/gpu/drm-usage-stats.rst
> > > > > index b46327356e80..b5e7802532ed 100644
> > > > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > > > @@ -105,6 +105,27 @@ object belong to this client, in the respective
> > > > > memory region.
> > > > > Default unit shall be bytes with optional unit specifiers of 'KiB'
> > > > > or 'MiB'
> > > > > indicating kibi- or mebi-bytes.
> > > > >
> > > > > +- drm-shared-memory: [KiB|MiB]
> > > > > +
> > > > > +The total size of buffers that are shared with another file (ie.
> > > > > have more
> > > > > +than a single handle).
> > > > > +
> > > > > +- drm-private-memory: [KiB|MiB]
> > > > > +
> > > > > +The total size of buffers that are not shared with another file.
> > > > > +
> > > > > +- drm-resident-memory: [KiB|MiB]
> > > > > +
> > > > > +The total size of buffers that are resident in system memory.
> > > >
> > > > I think this naming maybe does not work best with the existing
> > > > drm-memory- keys.
> > >
> > > Actually, it was very deliberate not to conflict with the existing
> > > drm-memory- keys ;-)
> > >
> > > I wouldn't have preferred drm-memory-{active,resident,...} but it
> > > could be mis-parsed by existing userspace so my hands were a bit tied.
> > >
> > > > How about introduce the concept of a memory region from the start and
> > > > use naming similar like we do for engines?
> > > >
> > > > drm-memory-$CATEGORY-$REGION: ...
> > > >
> > > > Then we document a bunch of categories and their semantics, for
> > > > instance:
> > > >
> > > > 'size' - All reachable objects
> > > > 'shared' - Subset of 'size' with handle_count > 1
> > > > 'resident' - Objects with backing store
> > > > 'active' - Objects in use, subset of resident
> > > > 'purgeable' - Or inactive? Subset of resident.
> > > >
> > > > We keep the same semantics as with process memory accounting (if I got
> > > > it right) which could be desirable for a simplified mental model.
> > > >
> > > > (AMD needs to remind me of their 'drm-memory-...' keys semantics. If we
> > > > correctly captured this in the first round it should be equivalent to
> > > > 'resident' above. In any case we can document no category is equal to
> > > > which category, and at most one of the two must be output.)
> > > >
> > > > Region names we at most partially standardize. Like we could say
> > > > 'system' is to be used where backing store is system RAM and others are
> > > > driver defined.
> > > >
> > > > Then discrete GPUs could emit N sets of key-values, one for each memory
> > > > region they support.
> > > >
> > > > I think this all also works for objects which can be migrated between
> > > > memory regions. 'Size' accounts them against all regions while for
> > > > 'resident' they only appear in
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
objects then on discrete GPUs it
> > seems we get an 'aggregate' value here which is not what I think we
> > want. We rather want to have the ability for drivers to list stats per
> > individual memory region.
> >
> > > + spin_unlock(>table_lock);
> > > +
> > > + print_size(p, "drm-shared-memory", size.shared);
> > > + print_size(p, "drm-private-memory", size.private);
> > > + print_size(p, "drm-active-memory", size.active);
> > > +
> > > + if (has_status) {
> > > + print_size(p, "drm-resident-memory", size.resident);
> > > + print_size(p, "drm-purgeable-memory", size.purgeable);
> > > + }
> > > +}
> > > +
> > > /**
> > >* drm_fop_show_fdinfo - helper for drm file fops
> > >* @seq_file: output stream
> > > @@ -904,6 +978,8 @@ void drm_fop_show_fdinfo(struct seq_file *m, struct
> > > file *f)
> > >
> > > if (dev->driver->show_fdinfo)
> > > dev->driver->show_fdinfo(, file);
> > > +
> > > + print_memory_stats(, file);
> > > }
> > > EXPORT_SYMBOL(drm_fop_show_fdinfo);
> > >
> > > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> > > index dfa995b787e1..e5b40084538f 100644
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > > @@ -41,6 +41,7 @@
> > > struct dma_fence;
> > > struct drm_file;
> > > struct drm_device;
> > > +struct drm_printer;
> > > struct device;
> > > struct file;
> > >
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 189fd618ca65..213917bb6b11 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -42,6 +42,14 @@
> > > struct iosys_map;
> > > struct drm_gem_object;
> > >
> > > +/**
> > > + * enum drm_gem_object_status - bitmask of object state for fdinfo
> > > reporting
> > > + */
> > > +enum drm_gem_object_status {
> > > + DRM_GEM_OBJECT_RESIDENT = BIT(0),
> > > + DRM_GEM_OBJECT_PURGEABLE = BIT(1),
> > > +};
> > > +
> > > /**
> > >* struct drm_gem_object_funcs - GEM object functions
> > >*/
> > > @@ -174,6 +182,17 @@ struct drm_gem_object_funcs {
> > >*/
> > > int (*evict)(struct drm_gem_object *obj);
> > >
> > > + /**
> > > + * @status:
> > > + *
> > > + * The optional status callback can return additional object state
> > > + * which determines which stats the object is counted against. The
> > > + * callback is called under table_lock. Racing against object
> > > status
> > > + * change is "harmless", and the callback can expect to not race
> > > + * against object destruction.
> > > + */
> > > + enum drm_gem_object_status (*status)(struct drm_gem_object *obj);
> >
> > Does this needs to be in object funcs and couldn't be consolidated to
> > driver level?
> >
> > Regards,
> >
> > Tvrtko
> >
> > > +
> > > /**
> > >* @vm_ops:
> > >*
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 4/7] drm/i915: Switch to fdinfo helper
On Wed, Apr 12, 2023 at 04:12:41PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/2023 14:51, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 01:32:43PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > >drivers/gpu/drm/i915/i915_driver.c | 3 ++-
> > > >drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
> > > >drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> > > >3 files changed, 8 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index db7a86def7e2..37eacaa3064b 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -1696,7 +1696,7 @@ static const struct file_operations
> > > > i915_driver_fops = {
> > > > .compat_ioctl = i915_ioc32_compat_ioctl,
> > > > .llseek = noop_llseek,
> > > >#ifdef CONFIG_PROC_FS
> > > > - .show_fdinfo = i915_drm_client_fdinfo,
> > > > + .show_fdinfo = drm_fop_show_fdinfo,
> > > >#endif
> > > >};
> > > > @@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
> > > > .open = i915_driver_open,
> > > > .lastclose = i915_driver_lastclose,
> > > > .postclose = i915_driver_postclose,
> > > > + .show_fdinfo = i915_drm_client_fdinfo,
> > > > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > > > .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > > > diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> > > > b/drivers/gpu/drm/i915/i915_drm_client.c
> > > > index b09d1d386574..4a77e5e47f79 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drm_client.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> > > > @@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx,
> > > > unsigned int class)
> > > >}
> > > >static void
> > > > -show_client_class(struct seq_file *m,
> > > > +show_client_class(struct drm_printer *p,
> > > > struct i915_drm_client *client,
> > > > unsigned int class)
> > > >{
> > > > @@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
> > > > rcu_read_unlock();
> > > > if (capacity)
> > > > - seq_printf(m, "drm-engine-%s:\t%llu ns\n",
> > > > + drm_printf(p, "drm-engine-%s:\t%llu ns\n",
> > > >uabi_class_names[class], total);
> > > > if (capacity > 1)
> > > > - seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
> > > > + drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
> > > >uabi_class_names[class],
> > > >capacity);
> > > >}
> > > > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
> > > > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file
> > > > *file)
> > > >{
> > > > - struct drm_file *file = f->private_data;
> > > > struct drm_i915_file_private *file_priv = file->driver_priv;
> > > > struct drm_i915_private *i915 = file_priv->dev_priv;
> > > > struct i915_drm_client *client = file_priv->client;
> > > > - struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > > unsigned int i;
> > > > /*
> > > > @@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m,
> > > > struct file *f)
> > > > *
> > > > **
> > > > */
> > > > - seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
> > > > - seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
> > > > - pci_domain_nr(pdev->bus), pdev->bus->number,
> > > > - PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> > > > - seq_
Re: [Freedreno] [PATCH v3 4/7] drm/i915: Switch to fdinfo helper
on't want the i915_drm_client design to spread, it conceptually makes no sense. drm_file is the uapi object, once that's gone userspace will never be able to look at anything, having a separate free-standing object that's essentially always dead is backwards. I went a bit more in-depth in a different thread on scheduler fd_info stats, but essentially fd_info needs to pull stats, you should never push stats towards the drm_file (or i915_drm_client). That avoids all the refcounting issues and rcu needs and everything else like that. Maybe you want to jump into that thread: https://lore.kernel.org/dri-devel/CAKMK7uE=m3sstqrlcedg0vg8viodoecusydk1oc++f5pqi0...@mail.gmail.com/ So retiring i915_drm_client infrastructure is the right direction I think. -Daniel > Regards, > > Tvrtko > > > - > > /* > > * Temporarily skip showing client engine information with GuC > > submission till > > * fetching engine busyness is implemented in the GuC submission backend > > @@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct > > file *f) > > return; > > for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) > > - show_client_class(m, client, i); > > + show_client_class(p, client, i); > > } > > #endif > > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h > > b/drivers/gpu/drm/i915/i915_drm_client.h > > index 69496af996d9..ef85fef45de5 100644 > > --- a/drivers/gpu/drm/i915/i915_drm_client.h > > +++ b/drivers/gpu/drm/i915/i915_drm_client.h > > @@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct > > i915_drm_client *client) > > struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients > > *clients); > > #ifdef CONFIG_PROC_FS > > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f); > > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file); > > #endif > > void i915_drm_clients_fini(struct i915_drm_clients *clients); -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats
On Wed, Apr 12, 2023 at 01:36:52AM +0300, Dmitry Baryshkov wrote: > On 11/04/2023 21:28, Rob Clark wrote: > > On Tue, Apr 11, 2023 at 10:36 AM Dmitry Baryshkov > > wrote: > > > > > > On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote: > > > > > > > > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote: > > > > > > > > > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote: > > > > > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > Similar motivation to other similar recent attempt[1]. But with > > > > > > > an > > > > > > > attempt to have some shared code for this. As well as > > > > > > > documentation. > > > > > > > > > > > > > > It is probably a bit UMA-centric, I guess devices with VRAM might > > > > > > > want > > > > > > > some placement stats as well. But this seems like a reasonable > > > > > > > start. > > > > > > > > > > > > > > Basic gputop support: > > > > > > > https://patchwork.freedesktop.org/series/116236/ > > > > > > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204 > > > > > > > > > > > > On a related topic, I'm wondering if it would make sense to report > > > > > > some more global things (temp, freq, etc) via fdinfo? Some of this, > > > > > > tools like nvtop could get by trawling sysfs or other driver > > > > > > specific > > > > > > ways. But maybe it makes sense to have these sort of things > > > > > > reported > > > > > > in a standardized way (even though they aren't really per-drm_file) > > > > > > > > > > I think that's a bit much layering violation, we'd essentially have to > > > > > reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want > > > > > to > > > > > be in :-) > > > > > > > > I guess this is true for temp (where there are thermal zones with > > > > potentially multiple temp sensors.. but I'm still digging my way thru > > > > the thermal_cooling_device stuff) > > > > > > It is slightly ugly. All thermal zones and cooling devices are virtual > > > devices (so, even no connection to the particular tsens device). One > > > can either enumerate them by checking > > > /sys/class/thermal/thermal_zoneN/type or enumerate them through > > > /sys/class/hwmon. For cooling devices again the only enumeration is > > > through /sys/class/thermal/cooling_deviceN/type. > > > > > > Probably it should be possible to push cooling devices and thermal > > > zones under corresponding providers. However I do not know if there is > > > a good way to correlate cooling device (ideally a part of GPU) to the > > > thermal_zone (which in our case is provided by tsens / temp_alarm > > > rather than GPU itself). > > > > > > > > > > > But what about freq? I think, esp for cases where some "fw thing" is > > > > controlling the freq we end up needing to use gpu counters to measure > > > > the freq. > > > > > > For the freq it is slightly easier: /sys/class/devfreq/*, devices are > > > registered under proper parent (IOW, GPU). So one can read > > > /sys/class/devfreq/3d0.gpu/cur_freq or > > > /sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq. > > > > > > However because of the components usage, there is no link from > > > /sys/class/drm/card0 > > > (/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0) > > > to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit. > > > > > > Getting all these items together in a platform-independent way would > > > be definitely an important but complex topic. > > > > But I don't believe any of the pci gpu's use devfreq ;-) > > > > And also, you can't expect the CPU to actually know the freq when fw > > is the one controlling freq. We can, currently, have a reasonable > > approximation from devfreq but that stops if IFPC is implemented. And > > other GPUs have even less direct control. So fre
Re: [Freedreno] [PATCH v3 6/7] drm: Add fdinfo memory stats
On Tue, Apr 11, 2023 at 03:56:11PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Add support to dump GEM stats to fdinfo.
>
> v2: Fix typos, change size units to match docs, use div_u64
> v3: Do it in core
>
> Signed-off-by: Rob Clark
> Reviewed-by: Emil Velikov
> ---
> Documentation/gpu/drm-usage-stats.rst | 21
> drivers/gpu/drm/drm_file.c| 76 +++
> include/drm/drm_file.h| 1 +
> include/drm/drm_gem.h | 19 +++
> 4 files changed, 117 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index b46327356e80..b5e7802532ed 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -105,6 +105,27 @@ object belong to this client, in the respective memory
> region.
> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-shared-memory: [KiB|MiB]
> +
> +The total size of buffers that are shared with another file (ie. have more
> +than a single handle).
> +
> +- drm-private-memory: [KiB|MiB]
> +
> +The total size of buffers that are not shared with another file.
> +
> +- drm-resident-memory: [KiB|MiB]
> +
> +The total size of buffers that are resident in system memory.
> +
> +- drm-purgeable-memory: [KiB|MiB]
> +
> +The total size of buffers that are purgeable.
> +
> +- drm-active-memory: [KiB|MiB]
> +
> +The total size of buffers that are active on one or more rings.
> +
> - drm-cycles-
>
> Engine identifier string must be the same as the one specified in the
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 37dfaa6be560..46fdd843bb3a 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -871,6 +872,79 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void print_size(struct drm_printer *p, const char *stat, size_t sz)
> +{
> + const char *units[] = {"", " KiB", " MiB"};
> + unsigned u;
> +
> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> + if (sz < SZ_1K)
> + break;
> + sz = div_u64(sz, SZ_1K);
> + }
> +
> + drm_printf(p, "%s:\t%zu%s\n", stat, sz, units[u]);
> +}
> +
> +static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_gem_object *obj;
> + struct {
> + size_t shared;
> + size_t private;
> + size_t resident;
> + size_t purgeable;
> + size_t active;
> + } size = {0};
> + bool has_status = false;
> + int id;
> +
> + spin_lock(>table_lock);
> + idr_for_each_entry (>object_idr, obj, id) {
> + enum drm_gem_object_status s = 0;
> +
> + if (obj->funcs && obj->funcs->status) {
> + s = obj->funcs->status(obj);
> + has_status = true;
> + }
> +
> + if (obj->handle_count > 1) {
> + size.shared += obj->size;
> + } else {
> + size.private += obj->size;
> + }
> +
> + if (s & DRM_GEM_OBJECT_RESIDENT) {
> + size.resident += obj->size;
> + } else {
> + /* If already purged or not yet backed by pages, don't
> + * count it as purgeable:
> + */
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (!dma_resv_test_signaled(obj->resv,
> dma_resv_usage_rw(true))) {
> + size.active += obj->size;
> +
> + /* If still active, don't count as purgeable: */
Maybe mention this in the kerneldoc for DRM_GEM_OBJECT_PURGEABLE?
Otherwise looks tidy:
Reviewed-by: Daniel Vetter
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_PURGEABLE)
> + size.purgeable += obj->size;
> + }
> + spin_unlock(>table_lock);
> +
> + print_size(p, "drm-shared-memory", size.shared);
> + print_size(p, "drm-private-memory", size.private);
> + print_size(p, &quo
Re: [Freedreno] [PATCH v3 5/7] drm/etnaviv: Switch to fdinfo helper
On Tue, Apr 11, 2023 at 03:56:10PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
You're on an old tree, this got reverted. But I'm kinda wondering whether
another patch on top shouldn't just includ the drm_show_fdinfo in
DRM_GEM_FOPS macro ... There's really no good reasons for drivers to not
have this I think?
-Daniel
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 44ca803237a5..17d6af94 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -476,9 +476,8 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
> ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
> };
>
> -static void etnaviv_fop_show_fdinfo(struct seq_file *m, struct file *f)
> +static void etnaviv_fop_show_fdinfo(struct drm_printer *p, struct drm_file
> *file)
> {
> - struct drm_file *file = f->private_data;
> struct drm_device *dev = file->minor->dev;
> struct etnaviv_drm_private *priv = dev->dev_private;
> struct etnaviv_file_private *ctx = file->driver_priv;
> @@ -487,8 +486,6 @@ static void etnaviv_fop_show_fdinfo(struct seq_file *m,
> struct file *f)
>* For a description of the text output format used here, see
>* Documentation/gpu/drm-usage-stats.rst.
>*/
> - seq_printf(m, "drm-driver:\t%s\n", dev->driver->name);
> - seq_printf(m, "drm-client-id:\t%u\n", ctx->id);
>
> for (int i = 0; i < ETNA_MAX_PIPES; i++) {
> struct etnaviv_gpu *gpu = priv->gpu[i];
> @@ -507,7 +504,7 @@ static void etnaviv_fop_show_fdinfo(struct seq_file *m,
> struct file *f)
> cur = snprintf(engine + cur, sizeof(engine) - cur,
> "%sNN", cur ? "/" : "");
>
> - seq_printf(m, "drm-engine-%s:\t%llu ns\n", engine,
> + drm_printf(p, "drm-engine-%s:\t%llu ns\n", engine,
> ctx->sched_entity[i].elapsed_ns);
> }
> }
> @@ -515,7 +512,7 @@ static void etnaviv_fop_show_fdinfo(struct seq_file *m,
> struct file *f)
> static const struct file_operations fops = {
> .owner = THIS_MODULE,
> DRM_GEM_FOPS,
> - .show_fdinfo = etnaviv_fop_show_fdinfo,
> + .show_fdinfo = drm_fop_show_fdinfo,
> };
>
> static const struct drm_driver etnaviv_drm_driver = {
> @@ -529,6 +526,7 @@ static const struct drm_driver etnaviv_drm_driver = {
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = etnaviv_debugfs_init,
> #endif
> + .show_fdinfo= etnaviv_fop_show_fdinfo,
> .ioctls = etnaviv_ioctls,
> .num_ioctls = DRM_ETNAVIV_NUM_IOCTLS,
> .fops = ,
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 3/7] drm/amdgpu: Switch to fdinfo helper
On Tue, Apr 11, 2023 at 03:56:08PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
> 3 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index f5ffca24def4..3611cfd5f076 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2752,7 +2752,7 @@ static const struct file_operations
> amdgpu_driver_kms_fops = {
> .compat_ioctl = amdgpu_kms_compat_ioctl,
> #endif
> #ifdef CONFIG_PROC_FS
> - .show_fdinfo = amdgpu_show_fdinfo
> + .show_fdinfo = drm_fop_show_fdinfo,
> #endif
> };
>
> @@ -2807,6 +2807,7 @@ static const struct drm_driver amdgpu_kms_driver = {
> .dumb_map_offset = amdgpu_mode_dumb_mmap,
> .fops = _driver_kms_fops,
> .release = _driver_release_kms,
> + .show_fdinfo = amdgpu_show_fdinfo,
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> index 99a7855ab1bc..c2fdd5e448d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> @@ -53,9 +53,8 @@ static const char *amdgpu_ip_name[AMDGPU_HW_IP_NUM] = {
> [AMDGPU_HW_IP_VCN_JPEG] = "jpeg",
> };
>
> -void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
> +void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file)
> {
> - struct drm_file *file = f->private_data;
> struct amdgpu_device *adev = drm_to_adev(file->minor->dev);
> struct amdgpu_fpriv *fpriv = file->driver_priv;
> struct amdgpu_vm *vm = >vm;
> @@ -86,18 +85,15 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file
> *f)
>* **
>*/
>
> - seq_printf(m, "pasid:\t%u\n", fpriv->vm.pasid);
> - seq_printf(m, "drm-driver:\t%s\n", file->minor->dev->driver->name);
> - seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", domain, bus, dev, fn);
> - seq_printf(m, "drm-client-id:\t%Lu\n", vm->immediate.fence_context);
> - seq_printf(m, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
> - seq_printf(m, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
> - seq_printf(m, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
> + drm_printf(p, "pasid:\t%u\n", fpriv->vm.pasid);
> + drm_printf(p, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
> + drm_printf(p, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
> + drm_printf(p, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
random aside, but we're not super consistent here, some of these have an
additional ' ' space.
I guess a next step would be a drm_fdinfo_printf(drm_printer *p, const
char *name, const char *printf, ...) and maybe some specialized ones that
dtrt for specific parameters, like drm_fdinfo_llu().
But that's for next one I guess :-)
-Daniel
> for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
> if (!usage[hw_ip])
> continue;
>
> - seq_printf(m, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
> + drm_printf(p, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
> ktime_to_ns(usage[hw_ip]));
> }
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> index e86834bfea1d..0398f5a159ef 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> @@ -37,6 +37,6 @@
> #include "amdgpu_ids.h"
>
> uint32_t amdgpu_get_ip_count(struct amdgpu_device *adev, int id);
> -void amdgpu_show_fdinfo(struct seq_file *m, struct file *f);
> +void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file);
>
> #endif
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 1/7] drm: Add common fdinfo helper
On Tue, Apr 11, 2023 at 03:56:06PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Handle a bit of the boiler-plate in a single case, and make it easier to
> add some core tracked stats.
>
> Signed-off-by: Rob Clark
Thanks a lot for kicking this off. A few polish comments below, with those
addressed:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_file.c | 39 ++
> include/drm/drm_drv.h | 7 +++
> include/drm/drm_file.h | 4
> 3 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index a51ff8cee049..37dfaa6be560 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
> */
> struct drm_file *drm_file_alloc(struct drm_minor *minor)
> {
> + static atomic_t ident = ATOMIC_INIT(0);
Maybe make this atomic64_t just to be sure?
> struct drm_device *dev = minor->dev;
> struct drm_file *file;
> int ret;
> @@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
> if (!file)
> return ERR_PTR(-ENOMEM);
>
> + /* Get a unique identifier for fdinfo: */
> + file->client_id = atomic_inc_return() - 1;
> file->pid = get_pid(task_pid(current));
> file->minor = minor;
>
> @@ -868,6 +871,42 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +/**
> + * drm_fop_show_fdinfo - helper for drm file fops
> + * @seq_file: output stream
> + * @f: the device file instance
> + *
> + * Helper to implement fdinfo, for userspace to query usage stats, etc, of a
> + * process using the GPU.
Please mention drm_driver.show_fd_info here too.
> + */
> +void drm_fop_show_fdinfo(struct seq_file *m, struct file *f)
> +{
> + struct drm_file *file = f->private_data;
> + struct drm_device *dev = file->minor->dev;
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + /*
> + * **
> + * For text output format description please see drm-usage-stats.rst!
> + * **
Maybe move this into the kerneldoc comment above (perhaps with an
IMPORTANT: tag or something, and make it an actual link)?
Also in the drm-usage-stats.rst please put a link to this function and
that is must be used for implementing fd_info.
> + */
> +
> + drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
> + drm_printf(, "drm-client-id:\t%u\n", file->client_id);
> +
> + if (dev_is_pci(dev->dev)) {
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +
> + drm_printf(, "drm-pdev:\t%04x:%02x:%02x.%d\n",
> +pci_domain_nr(pdev->bus), pdev->bus->number,
> +PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> + }
> +
> + if (dev->driver->show_fdinfo)
> + dev->driver->show_fdinfo(, file);
> +}
> +EXPORT_SYMBOL(drm_fop_show_fdinfo);
Bit a bikeshed, but for consistency drop the _fop_? We don't have it for
any of the other drm fops and git grep doesn't show a naming conflict.
> +
> /**
> * mock_drm_getfile - Create a new struct file for the drm device
> * @minor: drm minor to wrap (e.g. #drm_device.primary)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 5b86bb7603e7..a883c6d3bcdf 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -401,6 +401,13 @@ struct drm_driver {
> struct drm_device *dev, uint32_t handle,
> uint64_t *offset);
>
> + /**
> + * @fdinfo:
> + *
> + * Print device specific fdinfo. See drm-usage-stats.rst.
Please make this a link. I like links in kerneldoc :-)
> + */
> + void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
> +
> /** @major: driver major number */
> int major;
> /** @minor: driver minor number */
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 0d1f853092ab..dfa995b787e1 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -258,6 +258,9 @@ struct drm_file {
> /** @pid: Process that opened this file. */
> struct pid *pid;
>
> + /** @client_id: A unique id for fdinfo */
> + u32 client_id;
> +
> /** @magic: Authentication magic, see @authenticated. */
> drm_magic_t magic
Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats
On Tue, Apr 11, 2023 at 08:35:48PM +0300, Dmitry Baryshkov wrote: > On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote: > > > > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote: > > > > > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote: > > > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark wrote: > > > > > > > > > > From: Rob Clark > > > > > > > > > > Similar motivation to other similar recent attempt[1]. But with an > > > > > attempt to have some shared code for this. As well as documentation. > > > > > > > > > > It is probably a bit UMA-centric, I guess devices with VRAM might want > > > > > some placement stats as well. But this seems like a reasonable start. > > > > > > > > > > Basic gputop support: https://patchwork.freedesktop.org/series/116236/ > > > > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204 > > > > > > > > On a related topic, I'm wondering if it would make sense to report > > > > some more global things (temp, freq, etc) via fdinfo? Some of this, > > > > tools like nvtop could get by trawling sysfs or other driver specific > > > > ways. But maybe it makes sense to have these sort of things reported > > > > in a standardized way (even though they aren't really per-drm_file) > > > > > > I think that's a bit much layering violation, we'd essentially have to > > > reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to > > > be in :-) > > > > I guess this is true for temp (where there are thermal zones with > > potentially multiple temp sensors.. but I'm still digging my way thru > > the thermal_cooling_device stuff) > > It is slightly ugly. All thermal zones and cooling devices are virtual > devices (so, even no connection to the particular tsens device). One > can either enumerate them by checking > /sys/class/thermal/thermal_zoneN/type or enumerate them through > /sys/class/hwmon. For cooling devices again the only enumeration is > through /sys/class/thermal/cooling_deviceN/type. > > Probably it should be possible to push cooling devices and thermal > zones under corresponding providers. However I do not know if there is > a good way to correlate cooling device (ideally a part of GPU) to the > thermal_zone (which in our case is provided by tsens / temp_alarm > rather than GPU itself). There's not even sysfs links to connect the pieces in both ways? > > But what about freq? I think, esp for cases where some "fw thing" is > > controlling the freq we end up needing to use gpu counters to measure > > the freq. > > For the freq it is slightly easier: /sys/class/devfreq/*, devices are > registered under proper parent (IOW, GPU). So one can read > /sys/class/devfreq/3d0.gpu/cur_freq or > /sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq. > > However because of the components usage, there is no link from > /sys/class/drm/card0 > (/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0) > to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit. Hm ... do we need to make component more visible in sysfs, with _lots_ of links? Atm it's just not even there. > Getting all these items together in a platform-independent way would > be definitely an important but complex topic. Yeah this sounds like some work. But also sounds like it's all generic issues (thermal zones above and component here) that really should be fixed at that level? Cheers, Daniel > > > What might be needed is better glue to go from the fd or fdinfo to the > > > right hw device and then crawl around the hwmon in sysfs automatically. I > > > would not be surprised at all if we really suck on this, probably more > > > likely on SoC than pci gpus where at least everything should be under the > > > main pci sysfs device. > > > > yeah, I *think* userspace would have to look at /proc/device-tree to > > find the cooling device(s) associated with the gpu.. at least I don't > > see a straightforward way to figure it out just for sysfs > > > > BR, > > -R > > > > > -Daniel > > > > > > > > > > > BR, > > > > -R > > > > > > > > > > > > > [1] https://patchwork.freedesktop.org/series/112397/ > > > > > > > > > > Rob Clark (2): > > > > > drm: Add fdinfo memory stats > > > > > drm/msm: Add memory stats to fdinfo > > > > > > > > > > Documentation/gpu/drm-usage-stats.rst | 21 +++ > > > > > drivers/gpu/drm/drm_file.c| 79 > > > > > +++ > > > > > drivers/gpu/drm/msm/msm_drv.c | 25 - > > > > > drivers/gpu/drm/msm/msm_gpu.c | 2 - > > > > > include/drm/drm_file.h| 10 > > > > > 5 files changed, 134 insertions(+), 3 deletions(-) > > > > > > > > > > -- > > > > > 2.39.2 > > > > > > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > -- > With best wishes > Dmitry -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats
On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote: > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark wrote: > > > > From: Rob Clark > > > > Similar motivation to other similar recent attempt[1]. But with an > > attempt to have some shared code for this. As well as documentation. > > > > It is probably a bit UMA-centric, I guess devices with VRAM might want > > some placement stats as well. But this seems like a reasonable start. > > > > Basic gputop support: https://patchwork.freedesktop.org/series/116236/ > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204 > > On a related topic, I'm wondering if it would make sense to report > some more global things (temp, freq, etc) via fdinfo? Some of this, > tools like nvtop could get by trawling sysfs or other driver specific > ways. But maybe it makes sense to have these sort of things reported > in a standardized way (even though they aren't really per-drm_file) I think that's a bit much layering violation, we'd essentially have to reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to be in :-) What might be needed is better glue to go from the fd or fdinfo to the right hw device and then crawl around the hwmon in sysfs automatically. I would not be surprised at all if we really suck on this, probably more likely on SoC than pci gpus where at least everything should be under the main pci sysfs device. -Daniel > > BR, > -R > > > > [1] https://patchwork.freedesktop.org/series/112397/ > > > > Rob Clark (2): > > drm: Add fdinfo memory stats > > drm/msm: Add memory stats to fdinfo > > > > Documentation/gpu/drm-usage-stats.rst | 21 +++ > > drivers/gpu/drm/drm_file.c| 79 +++ > > drivers/gpu/drm/msm/msm_drv.c | 25 - > > drivers/gpu/drm/msm/msm_gpu.c | 2 - > > include/drm/drm_file.h| 10 > > 5 files changed, 134 insertions(+), 3 deletions(-) > > > > -- > > 2.39.2 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 1/2] drm: Add fdinfo memory stats
On Tue, Apr 11, 2023 at 08:02:09AM -0700, Rob Clark wrote: > On Tue, Apr 11, 2023 at 3:43 AM Daniel Vetter wrote: > > > > On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > Add a helper to dump memory stats to fdinfo. For the things the drm > > > core isn't aware of, use a callback. > > > > > > v2: Fix typos, change size units to match docs, use div_u64 > > > > > > Signed-off-by: Rob Clark > > > Reviewed-by: Emil Velikov > > > > Uh can't we wire this up by default? Having this as a per-driver opt-in > > sounds like we'll get maximally fragmented drm fd_info, and since that's > > uapi I don't think that's any good at all. > > That is the reason for the centralized documentation of the props (and > why for this one I added a helper, rather than continuing the current > pattern of everyone rolling their own).. Yeah, but we all know how consistent specs are without either a common implementation or a test suite (or better, both) :-) It's imo good to kick of new things, but anything that multiple drivers could/should implement or once we have multiple drivers implementing something should be common code. I'm doing the same pushing for the fd_info around ctx, at least all drivers using drm/sched should mostly just get this stuff instead of tons of driver glue that then blows up in interesting ways because people discover new ways to get lifetime rules wrong ... > We _could_ (and I had contemplated) doing this all in core if (a) we > move madv to drm_gem_object, and (b) track > drm_gem_get_pages()/drm_gem_put_pages(). I guess neither is totally > unreasonable, pretty much all the non-ttm/non-cma GEM drivers have > some form of madvise ioctl and use > drm_gem_get_pages()/drm_gem_put_pages().. The active part shouldn't need anything new, you should be able to compute that by looking at dma_resv (which is still ok under the spinlock, we still have the lockless stuff to check status afaik). The other bits are a bit more work, and I guess you could sort that out for now by making the status callback optional. Long term pushing purgeable as a concept one level up might make sense, but that's maybe a bit too much refactoring for this. I think just the minimal to get at least infra in place and the fully driver-agnostic stuff computed for every gem driver would be great already. And it makes it much easier for the next fd_info thing to become fully generic, which hopefully motivates people to do that. -Daniel > > BR, > -R > > > I think it's time we have > > - drm_fd_info > > - rolled out to all drivers in their fops > > - with feature checks as appropriate > > - push the driver-specific things into a drm_driver callback > > > > And I guess start peopling giving a hard time for making things needless > > driver-specifict ... there's really no reason at all this is not > > consistent across drivers. > > -Daniel > > > > > --- > > > Documentation/gpu/drm-usage-stats.rst | 21 +++ > > > drivers/gpu/drm/drm_file.c| 79 +++ > > > include/drm/drm_file.h| 10 > > > 3 files changed, 110 insertions(+) > > > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst > > > b/Documentation/gpu/drm-usage-stats.rst > > > index b46327356e80..b5e7802532ed 100644 > > > --- a/Documentation/gpu/drm-usage-stats.rst > > > +++ b/Documentation/gpu/drm-usage-stats.rst > > > @@ -105,6 +105,27 @@ object belong to this client, in the respective > > > memory region. > > > Default unit shall be bytes with optional unit specifiers of 'KiB' or > > > 'MiB' > > > indicating kibi- or mebi-bytes. > > > > > > +- drm-shared-memory: [KiB|MiB] > > > + > > > +The total size of buffers that are shared with another file (ie. have > > > more > > > +than a single handle). > > > + > > > +- drm-private-memory: [KiB|MiB] > > > + > > > +The total size of buffers that are not shared with another file. > > > + > > > +- drm-resident-memory: [KiB|MiB] > > > + > > > +The total size of buffers that are resident in system memory. > > > + > > > +- drm-purgeable-memory: [KiB|MiB] > > > + > > > +The total size of buffers that are purgeable. > > > + > > > +- drm-active-memory: [KiB|MiB] > > > + > > > +The total size of buffers that are active on one or more rings. > > > + > > > - drm-cycles- > > > > > > Engine identifier string must be the same as
Re: [Freedreno] [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4
On Tue, Apr 11, 2023 at 07:55:33AM -0700, Rob Clark wrote: > On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter wrote: > > > Konrad Dybcio (18): > > > drm/msm/adreno: Use OPP for every GPU generation > > > > This had a minor conflict with refactoring from drm-misc-next, I went > > what's in your pr. Please double check I didn't screw up, but at least it > > compiles :-) > > Hmm, am I looking at the wrong thing.. the conflict I'm seeing is with > drm_gem_lru (and looks to be correctly resolved) Yeah that one was trivial. Unfortunately git does not report anything if you only keep one or the other branch entirely in your resolution, so the only way for you to see the conflict is to re-create the merge :-) Or at least my git foo isn't good enough for a better way ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 1/2] drm: Add fdinfo memory stats
if (s & DRM_GEM_OBJECT_RESIDENT) {
> + size.resident += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_ACTIVE) {
> + size.active += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_PURGEABLE)
> + size.purgeable += obj->size;
> + }
> + spin_unlock(>table_lock);
> +
> + print_size(p, "drm-shared-memory", size.shared);
> + print_size(p, "drm-private-memory", size.private);
> +
> + if (status) {
> + print_size(p, "drm-resident-memory", size.resident);
> + print_size(p, "drm-purgeable-memory", size.purgeable);
> + print_size(p, "drm-active-memory", size.active);
> + }
> +}
> +EXPORT_SYMBOL(drm_print_memory_stats);
> +
> /**
> * mock_drm_getfile - Create a new struct file for the drm device
> * @minor: drm minor to wrap (e.g. #drm_device.primary)
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 0d1f853092ab..7bd8a1374f39 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -41,6 +41,7 @@
> struct dma_fence;
> struct drm_file;
> struct drm_device;
> +struct drm_printer;
> struct device;
> struct file;
>
> @@ -438,6 +439,15 @@ void drm_send_event_timestamp_locked(struct drm_device
> *dev,
>struct drm_pending_event *e,
>ktime_t timestamp);
>
> +enum drm_gem_object_status {
> + DRM_GEM_OBJECT_RESIDENT = BIT(0),
> + DRM_GEM_OBJECT_PURGEABLE = BIT(1),
> + DRM_GEM_OBJECT_ACTIVE= BIT(2),
> +};
> +
> +void drm_print_memory_stats(struct drm_file *file, struct drm_printer *p,
> + enum drm_gem_object_status (*status)(struct
> drm_gem_object *));
> +
> struct file *mock_drm_getfile(struct drm_minor *minor, unsigned int flags);
>
> #endif /* _DRM_FILE_H_ */
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4
/drm/msm/dsi/dsi_phy_28nm_8960.xml.h| 40 +- > drivers/gpu/drm/msm/dsi/dsi_phy_7nm.xml.h | 36 +- > drivers/gpu/drm/msm/dsi/mmss_cc.xml.h | 40 +- > drivers/gpu/drm/msm/dsi/sfpb.xml.h | 38 +- > drivers/gpu/drm/msm/hdmi/hdmi.xml.h| 62 +- > drivers/gpu/drm/msm/hdmi/qfprom.xml.h | 40 +- > drivers/gpu/drm/msm/msm_atomic.c | 29 +- > drivers/gpu/drm/msm/msm_debugfs.c |6 +- > drivers/gpu/drm/msm/msm_drv.c | 109 +- > drivers/gpu/drm/msm/msm_drv.h | 15 +- > drivers/gpu/drm/msm/msm_fbdev.c| 173 +- > drivers/gpu/drm/msm/msm_fence.c| 86 +- > drivers/gpu/drm/msm/msm_fence.h| 23 +- > drivers/gpu/drm/msm/msm_gem.c | 150 +- > drivers/gpu/drm/msm/msm_gem.h | 29 +- > drivers/gpu/drm/msm/msm_gem_submit.c | 37 +- > drivers/gpu/drm/msm/msm_gem_vma.c | 91 +- > drivers/gpu/drm/msm/msm_gpu.c |8 +- > drivers/gpu/drm/msm/msm_gpu.h | 12 +- > drivers/gpu/drm/msm/msm_gpu_devfreq.c |2 +- > drivers/gpu/drm/msm/msm_io_utils.c |1 + > drivers/gpu/drm/msm/msm_iommu.c| 38 +- > drivers/gpu/drm/msm/msm_kms.h |8 - > drivers/gpu/drm/msm/msm_mdss.c | 198 +- > drivers/gpu/drm/msm/msm_mmu.h |1 + > drivers/gpu/drm/msm/msm_ringbuffer.c |8 +- > drivers/gpu/drm/msm/msm_submitqueue.c |2 +- > drivers/gpu/drm/scheduler/sched_fence.c| 46 + > drivers/gpu/drm/scheduler/sched_main.c |2 +- > include/drm/drm_gem.h |1 + > include/drm/drm_vblank.h |1 + > include/drm/gpu_scheduler.h| 17 + > include/linux/dma-fence.h | 22 + > include/linux/dma-resv.h |2 + > include/uapi/drm/msm_drm.h | 18 +- > include/uapi/linux/sync_file.h | 37 +- > 125 files changed, 6659 insertions(+), 4519 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h > create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
On Wed, Apr 05, 2023 at 12:53:29AM +0300, Dmitry Baryshkov wrote:
> On 04/04/2023 22:16, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> > > On 08/03/2023 17:53, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > For an atomic commit updating a single CRTC (ie. a pageflip) calculate
> > > > the next vblank time, and inform the fence(s) of that deadline.
> > > >
> > > > v2: Comment typo fix (danvet)
> > > > v3: If there are multiple CRTCs, consider the time of the soonest vblank
> > > >
> > > > Signed-off-by: Rob Clark
> > > > Reviewed-by: Daniel Vetter
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > >drivers/gpu/drm/drm_atomic_helper.c | 37
> > > > +
> > > >1 file changed, 37 insertions(+)
> > >
> > > As I started playing with hotplug on RB5 (sm8250, DSI-HDMI bridge), I
> > > found
> > > that this patch introduces the following backtrace on HDMI hotplug. Is
> > > there
> > > anything that I can do to debug/fix the issue? The warning seems harmless,
> > > but it would be probably be good to still fix it. With addresses decoded:
> >
> > Bit a shot in the dark, but does the below help?
>
> This indeed seems to fix the issue. I'm not sure about the possible side
> effects, but, if you were to send the patch:
>
> Tested-by: Dmitry Baryshkov
Thanks for the quick feedback, I already discussed this with Rob on irc
yesterday (and landed his more throughrough version of the drm_vblank.c
fix to drm-misc-next). I'll polish the drm_atomic_helper.c part asap and
will send it out. Would be great if you can then retest to make sure all
the pieces still work together for your case.
-Daniel
>
> >
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index f21b5a74176c..6640d80d84f3 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1528,6 +1528,9 @@ static void set_fence_deadline(struct drm_device *dev,
> > for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> > ktime_t v;
> > + if (drm_atomic_crtc_needs_modeset(new_crtc_state))
> > + continue;
> > +
> > if (drm_crtc_next_vblank_start(crtc, ))
> > continue;
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 78a8c51a4abf..7ae38e8e27e8 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -1001,6 +1001,9 @@ int drm_crtc_next_vblank_start(struct drm_crtc *crtc,
> > ktime_t *vblanktime)
> > struct drm_display_mode *mode = >hwmode;
> > u64 vblank_start;
> > + if (!drm_dev_has_vblank(crtc->dev))
> > + return -EINVAL;
> > +
> > if (!vblank->framedur_ns || !vblank->linedur_ns)
> > return -EINVAL;
> >
> > >
> > > [ 31.151348] [ cut here ]
> > > [ 31.157043] msm_dpu ae01000.display-controller:
> > > drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
> > > [ 31.157177] WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/drm_vblank.c:728
> > > drm_crtc_vblank_helper_get_vblank_timestamp_internal
> > > (drivers/gpu/drm/drm_vblank.c:728)
> > > [ 31.180629] Modules linked in:
> > > [ 31.184106] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted
> > > 6.3.0-rc2-8-gd39e48ca80c0 #542
> > > [ 31.193358] Hardware name: Qualcomm Technologies, Inc. Robotics RB5
> > > (DT)
> > > [ 31.200796] Workqueue: events lt9611uxc_hpd_work
> > > [ 31.205990] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> > > BTYPE=--)
> > > [ 31.213722] pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal
> > > (drivers/gpu/drm/drm_vblank.c:728)
> > > [ 31.222032] lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal
> > > (drivers/gpu/drm/drm_vblank.c:728)
> > > [ 31.230341] sp : 880bb8d0
> > > [ 31.234061] x29: 880bb900 x28: 0038 x27:
> > > 61a7956b8d60
> > > [ 31.242051] x26: x25: x24:
> > > 880bb9c4
> > > [ 31.250038] x23: 0001 x22: bf0033b94ef0 x21:
> > > 61a7957901d0
> > > [ 31.258029] x20: 61a79571 x19: 61a78128b000 x18:
> &g
Re: [Freedreno] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> On 08/03/2023 17:53, Rob Clark wrote:
> > From: Rob Clark
> >
> > For an atomic commit updating a single CRTC (ie. a pageflip) calculate
> > the next vblank time, and inform the fence(s) of that deadline.
> >
> > v2: Comment typo fix (danvet)
> > v3: If there are multiple CRTCs, consider the time of the soonest vblank
> >
> > Signed-off-by: Rob Clark
> > Reviewed-by: Daniel Vetter
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 37 +
> > 1 file changed, 37 insertions(+)
>
> As I started playing with hotplug on RB5 (sm8250, DSI-HDMI bridge), I found
> that this patch introduces the following backtrace on HDMI hotplug. Is there
> anything that I can do to debug/fix the issue? The warning seems harmless,
> but it would be probably be good to still fix it. With addresses decoded:
Bit a shot in the dark, but does the below help?
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f21b5a74176c..6640d80d84f3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1528,6 +1528,9 @@ static void set_fence_deadline(struct drm_device *dev,
for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
ktime_t v;
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state))
+ continue;
+
if (drm_crtc_next_vblank_start(crtc, ))
continue;
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 78a8c51a4abf..7ae38e8e27e8 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1001,6 +1001,9 @@ int drm_crtc_next_vblank_start(struct drm_crtc *crtc,
ktime_t *vblanktime)
struct drm_display_mode *mode = >hwmode;
u64 vblank_start;
+ if (!drm_dev_has_vblank(crtc->dev))
+ return -EINVAL;
+
if (!vblank->framedur_ns || !vblank->linedur_ns)
return -EINVAL;
>
> [ 31.151348] [ cut here ]
> [ 31.157043] msm_dpu ae01000.display-controller:
> drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
> [ 31.157177] WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/drm_vblank.c:728
> drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.180629] Modules linked in:
> [ 31.184106] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted
> 6.3.0-rc2-8-gd39e48ca80c0 #542
> [ 31.193358] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
> [ 31.200796] Workqueue: events lt9611uxc_hpd_work
> [ 31.205990] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [ 31.213722] pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.222032] lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.230341] sp : 880bb8d0
> [ 31.234061] x29: 880bb900 x28: 0038 x27:
> 61a7956b8d60
> [ 31.242051] x26: x25: x24:
> 880bb9c4
> [ 31.250038] x23: 0001 x22: bf0033b94ef0 x21:
> 61a7957901d0
> [ 31.258029] x20: 61a79571 x19: 61a78128b000 x18:
> fffec278
> [ 31.266014] x17: 00400465 x16: 0020 x15:
> 0060
> [ 31.274001] x14: 0001 x13: bf00354550e0 x12:
> 0825
> [ 31.281989] x11: 02b7 x10: bf00354b1208 x9 :
> bf00354550e0
> [ 31.289976] x8 : efff x7 : bf00354ad0e0 x6 :
> 02b7
> [ 31.297963] x5 : 61a8feebbe48 x4 : 4000f2b7 x3 :
> a2a8c9f64000
> [ 31.305947] x2 : x1 : x0 :
> 61a780283100
> [ 31.313934] Call trace:
> [ 31.316719] drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.324646] drm_crtc_vblank_helper_get_vblank_timestamp
> (drivers/gpu/drm/drm_vblank.c:843)
> [ 31.331528] drm_crtc_get_last_vbltimestamp
> (drivers/gpu/drm/drm_vblank.c:884)
> [ 31.337170] drm_crtc_next_vblank_start
> (drivers/gpu/drm/drm_vblank.c:1006)
> [ 31.342430] drm_atomic_helper_wait_for_fences
> (drivers/gpu/drm/drm_atomic_helper.c:1531
> drivers/gpu/drm/drm_atomic_helper.c:1578)
> [ 31.348561] drm_atomic_helper_commit
> (drivers/gpu/drm/drm_atomic_helper.c:2007)
> [ 31.353724] drm_atomic_commit (drivers/gpu/drm/drm_atomic.c:1444)
> [ 31.358127] drm_client_modeset_commit_atomic
> (drivers/gpu/drm/drm_client_modeset.c:1045)
> [ 31.364146] drm_client_m
Re: [Freedreno] [PATCH] drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini()
On Fri, Feb 17, 2023 at 09:18:54AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 16.02.23 um 21:11 schrieb Daniel Vetter:
> > On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> > > Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> > > calling fbdev implementation. Avoids a possible stale mutex with
> > > generic fbdev code.
> > >
> > > As indicated by its name, drm_fb_helper_prepare() prepares struct
> > > drm_fb_helper before setting up the fbdev support with a call to
> > > drm_fb_helper_init(). In legacy fbdev emulation, this happens next
> > > to each other. If successful, drm_fb_helper_fini() later tear down
> > > the fbdev device and also unprepare via drm_fb_helper_unprepare().
> > >
> > > Generic fbdev emulation prepares struct drm_fb_helper immediately
> > > after allocating the instance. It only calls drm_fb_helper_init()
> > > as part of processing a hotplug event. If the hotplug-handling fails,
> > > it runs drm_fb_helper_fini(). This unprepares the fb-helper instance
> > > and the next hotplug event runs on stale data.
> > >
> > > Solve this by moving drm_fb_helper_unprepare() from drm_fb_helper_fini()
> > > into the fbdev implementations. Call it right before freeing the
> > > fb-helper instance.
> > >
> > > Fixes: 4825797c36da ("drm/fb-helper: Introduce drm_fb_helper_unprepare()")
> > > Cc: Thomas Zimmermann
> > > Cc: Javier Martinez Canillas
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Cc: dri-de...@lists.freedesktop.org
> > >
> > > Signed-off-by: Thomas Zimmermann
> >
> > This reminds me of an old patch I just recently stumbled over again:
> >
> > https://lore.kernel.org/dri-devel/Y3St2VHJ7jEmcNFw@phenom.ffwll.local/
> >
> > Should I resurrect that one maybe and send it out? I think that also ties
> > a bit into your story here.
>
> I don't think it will be necessary. I began to convert the existing fbdev
> emulation to make use of drm_client, which should resove a number of
> problems. I expect to post this after the various trees have merged the
> recent changes to fbdev helpers.
The only version the patch is fixing is the client one, the old one is
unfixable (I think at least, hence just the comments). Note that the link
is pre-splitting, I do have a rebased version here.
I'll just send that out and head into vacations :-)
-Daniel
>
> Best regards
> Thomas
>
> >
> > > ---
> > > drivers/gpu/drm/armada/armada_fbdev.c | 3 +++
> > > drivers/gpu/drm/drm_fb_helper.c| 2 --
> > > drivers/gpu/drm/drm_fbdev_generic.c| 2 ++
> > > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ++-
> > > drivers/gpu/drm/gma500/framebuffer.c | 2 ++
> > > drivers/gpu/drm/i915/display/intel_fbdev.c | 1 +
> > > drivers/gpu/drm/msm/msm_fbdev.c| 2 ++
> > > drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 ++
> > > drivers/gpu/drm/radeon/radeon_fb.c | 2 ++
> > > drivers/gpu/drm/tegra/fb.c | 1 +
> > > 10 files changed, 17 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
> > > b/drivers/gpu/drm/armada/armada_fbdev.c
> > > index 07e410c62b7a..0e44f53e9fa4 100644
> > > --- a/drivers/gpu/drm/armada/armada_fbdev.c
> > > +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> > > @@ -147,6 +147,7 @@ int armada_fbdev_init(struct drm_device *dev)
> > >err_fb_setup:
> > > drm_fb_helper_fini(fbh);
> > >err_fb_helper:
> > > + drm_fb_helper_unprepare(fbh);
> > > priv->fbdev = NULL;
> > > return ret;
> > > }
> > > @@ -164,6 +165,8 @@ void armada_fbdev_fini(struct drm_device *dev)
> > > if (fbh->fb)
> > > fbh->fb->funcs->destroy(fbh->fb);
> > > + drm_fb_helper_unprepare(fbh);
> > > +
> > > priv->fbdev = NULL;
> > > }
> > > }
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 28c428e9c530..a39998047f8a 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -590,8 +590,6 @@ void drm_fb_helper_fini(struct drm_fb_helper
> > > *fb
Re: [Freedreno] [PATCH] drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini()
On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> calling fbdev implementation. Avoids a possible stale mutex with
> generic fbdev code.
>
> As indicated by its name, drm_fb_helper_prepare() prepares struct
> drm_fb_helper before setting up the fbdev support with a call to
> drm_fb_helper_init(). In legacy fbdev emulation, this happens next
> to each other. If successful, drm_fb_helper_fini() later tear down
> the fbdev device and also unprepare via drm_fb_helper_unprepare().
>
> Generic fbdev emulation prepares struct drm_fb_helper immediately
> after allocating the instance. It only calls drm_fb_helper_init()
> as part of processing a hotplug event. If the hotplug-handling fails,
> it runs drm_fb_helper_fini(). This unprepares the fb-helper instance
> and the next hotplug event runs on stale data.
>
> Solve this by moving drm_fb_helper_unprepare() from drm_fb_helper_fini()
> into the fbdev implementations. Call it right before freeing the
> fb-helper instance.
>
> Fixes: 4825797c36da ("drm/fb-helper: Introduce drm_fb_helper_unprepare()")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
>
> Signed-off-by: Thomas Zimmermann
This reminds me of an old patch I just recently stumbled over again:
https://lore.kernel.org/dri-devel/Y3St2VHJ7jEmcNFw@phenom.ffwll.local/
Should I resurrect that one maybe and send it out? I think that also ties
a bit into your story here.
> ---
> drivers/gpu/drm/armada/armada_fbdev.c | 3 +++
> drivers/gpu/drm/drm_fb_helper.c| 2 --
> drivers/gpu/drm/drm_fbdev_generic.c| 2 ++
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ++-
> drivers/gpu/drm/gma500/framebuffer.c | 2 ++
> drivers/gpu/drm/i915/display/intel_fbdev.c | 1 +
> drivers/gpu/drm/msm/msm_fbdev.c| 2 ++
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 ++
> drivers/gpu/drm/radeon/radeon_fb.c | 2 ++
> drivers/gpu/drm/tegra/fb.c | 1 +
> 10 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 07e410c62b7a..0e44f53e9fa4 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -147,6 +147,7 @@ int armada_fbdev_init(struct drm_device *dev)
> err_fb_setup:
> drm_fb_helper_fini(fbh);
> err_fb_helper:
> + drm_fb_helper_unprepare(fbh);
> priv->fbdev = NULL;
> return ret;
> }
> @@ -164,6 +165,8 @@ void armada_fbdev_fini(struct drm_device *dev)
> if (fbh->fb)
> fbh->fb->funcs->destroy(fbh->fb);
>
> + drm_fb_helper_unprepare(fbh);
> +
> priv->fbdev = NULL;
> }
> }
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 28c428e9c530..a39998047f8a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -590,8 +590,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
I think it would be good to update the kerneldoc of _init() and _fini()
here to mention each another like we usually do with these pairs. Same
with prepare/unprepare() although the latter rerfences _prepare() already.
> }
> mutex_unlock(_fb_helper_lock);
>
> - drm_fb_helper_unprepare(fb_helper);
> -
> if (!fb_helper->client.funcs)
> drm_client_release(_helper->client);
> }
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 365f80717fa1..4d6325e91565 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -65,6 +65,8 @@ static void drm_fbdev_fb_destroy(struct fb_info *info)
>
> drm_client_framebuffer_delete(fb_helper->buffer);
> drm_client_release(_helper->client);
> +
> + drm_fb_helper_unprepare(fb_helper);
> kfree(fb_helper);
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index b89e33af8da8..4929ffe5a09a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -183,8 +183,8 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
>
> err_setup:
> drm_fb_helper_fini(helper);
> -
> err_init:
> + drm_fb_helper_unprepare(helper);
> private->fb_helper = NULL;
> kfree(fbdev);
>
> @@ -219,6 +
[Freedreno] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in
commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas
Date: Wed Dec 5 14:59:07 2018 -0500
drm/amd/display: Add fast path for cursor plane updates
we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.
v3: Paper over msm and i915 regression. The complete_all is the only
thing missing afaict.
v4: Fixup i915 fixup ...
v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in
dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to
untangle this all. Thanks to Abhinav Kumar for the debug help.
Cc: Abhinav Kumar
Cc: Thomas Zimmermann
Cc: Maxime Ripard
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
References:
https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: Maxime Ripard
Tested-by: Maxime Ripard
Cc: mikita.lip...@amd.com
Cc: Michel Dänzer
Cc: harry.wentl...@amd.com
Cc: Rob Clark
Cc: "Kazlauskas, Nicholas"
Cc: Dmitry Osipenko
Cc: Maarten Lankhorst
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: Matthias Brugger
Cc: AngeloGioacchino Del Regno
Cc: "Ville Syrjälä"
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Imre Deak
Cc: Manasi Navare
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 13 -
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/msm/msm_atomic.c | 15 +++
3 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..f6b4c3a00684 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1587,13 +1587,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
int i, ret;
unsigned int crtc_mask = 0;
-/*
- * Legacy cursor ioctls are completely unsynced, and userspace
- * relies on that (by doing tons of cursor updates).
- */
- if (old_state->legacy_cursor_update)
- return;
-
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!new_crtc_state->active)
continue;
@@ -2244,12 +2237,6 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
continue;
}
- /* Legacy cursor updates are fully unsynced. */
- if (state->legacy_cursor_update) {
- complete_all(>flip_done);
- continue;
- }
-
if (!new_crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3479125fbda6..2454451fcf95 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7651,6 +7651,20 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
return ret;
}
+
+ /*
+* FIXME: Cut over to (async) commit helpers instead of hand-rolling
+* everything.
+*/
+ if (state->base.legacy_cursor_update) {
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc *crtc;
+ int i;
+
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
+ complete_all(_crtc_state->uapi.commit->flip_done);
+ }
+
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
di
Re: [Freedreno] [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Fri, Jan 06, 2023 at 04:33:04PM -0800, Abhinav Kumar wrote: > Hi Daniel > > Thanks for looking into this series. > > On 1/6/2023 1:49 PM, Dmitry Baryshkov wrote: > > On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote: > > > > > > On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote: > > > > On Fri, 6 Jan 2023 at 02:38, Jessica Zhang > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 1/5/2023 3:33 AM, Daniel Vetter wrote: > > > > > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote: > > > > > > > Introduce and add support for a solid_fill property. When the > > > > > > > solid_fill > > > > > > > property is set, and the framebuffer is set to NULL, memory fetch > > > > > > > will be > > > > > > > disabled. > > > > > > > > > > > > > > In addition, loosen the NULL FB checks within the atomic commit > > > > > > > callstack > > > > > > > to allow a NULL FB when the solid_fill property is set and add FB > > > > > > > checks > > > > > > > in methods where the FB was previously assumed to be non-NULL. > > > > > > > > > > > > > > Finally, have the DPU driver use drm_plane_state.solid_fill and > > > > > > > instead of > > > > > > > dpu_plane_state.color_fill, and add extra checks in the DPU > > > > > > > atomic commit > > > > > > > callstack to account for a NULL FB in cases where solid_fill is > > > > > > > set. > > > > > > > > > > > > > > Some drivers support hardware that have optimizations for solid > > > > > > > fill > > > > > > > planes. This series aims to expose these capabilities to > > > > > > > userspace as > > > > > > > some compositors have a solid fill flag (ex. SOLID_COLOR in the > > > > > > > Android > > > > > > > hardware composer HAL) that can be set by apps like the Android > > > > > > > Gears > > > > > > > app. > > > > > > > > > > > > > > Userspace can set the solid_fill property to a blob containing the > > > > > > > appropriate version number and solid fill color (in RGB323232 > > > > > > > format) and > > > > > > > setting the framebuffer to NULL. > > > > > > > > > > > > > > Note: Currently, there's only one version of the solid_fill blob > > > > > > > property. > > > > > > > However if other drivers want to support a similar feature, but > > > > > > > require > > > > > > > more than just the solid fill color, they can extend this feature > > > > > > > by > > > > > > > creating additional versions of the drm_solid_fill struct. > > > > > > > > > > > > > > Changes in V2: > > > > > > > - Dropped SOLID_FILL_FORMAT property (Simon) > > > > > > > - Switched to implementing solid_fill property as a blob (Simon, > > > > > > > Dmitry) > > > > > > > - Changed to checks for if solid_fill_blob is set (Dmitry) > > > > > > > - Abstracted (plane_state && !solid_fill_blob) checks to helper > > > > > > > method > > > > > > > (Dmitry) > > > > > > > - Removed DPU_PLANE_COLOR_FILL_FLAG > > > > > > > - Fixed whitespace and indentation issues (Dmitry) > > > > > > > > > > > > Now that this is a blob, I do wonder again whether it's not cleaner > > > > > > to set > > > > > > the blob as the FB pointer. Or create some kind other kind of > > > > > > special data > > > > > > source objects (because solid fill is by far not the only such > > > > > > thing). > > > > > > > > > > > > We'd still end up in special cases like when userspace that doesn't > > > > > > understand solid fill tries to read out such a framebuffer, but > > > > > > these > > > > > > cases already exist anyway for lack of priviledges. > > >
Re: [Freedreno] [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote: > On Fri, 6 Jan 2023 at 02:38, Jessica Zhang wrote: > > > > > > > > On 1/5/2023 3:33 AM, Daniel Vetter wrote: > > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote: > > >> Introduce and add support for a solid_fill property. When the solid_fill > > >> property is set, and the framebuffer is set to NULL, memory fetch will be > > >> disabled. > > >> > > >> In addition, loosen the NULL FB checks within the atomic commit callstack > > >> to allow a NULL FB when the solid_fill property is set and add FB checks > > >> in methods where the FB was previously assumed to be non-NULL. > > >> > > >> Finally, have the DPU driver use drm_plane_state.solid_fill and instead > > >> of > > >> dpu_plane_state.color_fill, and add extra checks in the DPU atomic commit > > >> callstack to account for a NULL FB in cases where solid_fill is set. > > >> > > >> Some drivers support hardware that have optimizations for solid fill > > >> planes. This series aims to expose these capabilities to userspace as > > >> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android > > >> hardware composer HAL) that can be set by apps like the Android Gears > > >> app. > > >> > > >> Userspace can set the solid_fill property to a blob containing the > > >> appropriate version number and solid fill color (in RGB323232 format) and > > >> setting the framebuffer to NULL. > > >> > > >> Note: Currently, there's only one version of the solid_fill blob > > >> property. > > >> However if other drivers want to support a similar feature, but require > > >> more than just the solid fill color, they can extend this feature by > > >> creating additional versions of the drm_solid_fill struct. > > >> > > >> Changes in V2: > > >> - Dropped SOLID_FILL_FORMAT property (Simon) > > >> - Switched to implementing solid_fill property as a blob (Simon, Dmitry) > > >> - Changed to checks for if solid_fill_blob is set (Dmitry) > > >> - Abstracted (plane_state && !solid_fill_blob) checks to helper method > > >>(Dmitry) > > >> - Removed DPU_PLANE_COLOR_FILL_FLAG > > >> - Fixed whitespace and indentation issues (Dmitry) > > > > > > Now that this is a blob, I do wonder again whether it's not cleaner to set > > > the blob as the FB pointer. Or create some kind other kind of special data > > > source objects (because solid fill is by far not the only such thing). > > > > > > We'd still end up in special cases like when userspace that doesn't > > > understand solid fill tries to read out such a framebuffer, but these > > > cases already exist anyway for lack of priviledges. > > > > > > So I still think that feels like the more consistent way to integrate this > > > feature. Which doesn't mean it has to happen like that, but the > > > patches/cover letter should at least explain why we don't do it like this. > > > > Hi Daniel, > > > > IIRC we were facing some issues with this check [1] when trying to set > > FB to a PROP_BLOB instead. Which is why we went with making it a > > separate property instead. Will mention this in the cover letter. > > What kind of issues? Could you please describe them? We switched from bitmask to enum style for prop types, which means it's not possible to express with the current uapi a property which accepts both an object or a blob. Which yeah sucks a bit ... But! blob properties are kms objects (like framebuffers), so it should be possible to stuff a blob into an object property as-is. Of course you need to update the validation code to make sure we accept either an fb or a blob for the internal representation. But that kind of split internally is required no matter what I think. -Daniel > > > > > [1] > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71 > > > > Thanks, > > > > Jessica Zhang > > > > > -Daniel > > > > > >> > > >> Changes in V3: > > >> - Fixed some logic errors in atomic checks (Dmitry) > > >> - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() > > >> helper > > >>methods (Dmitry) > > >> > > >> Jessica Zhang (3): > > >>drm: Introduce solid fill propert
Re: [Freedreno] [PATCH] drm/msm: Set preferred depth.
On Fri, Jan 06, 2023 at 09:18:21AM +0200, Dmitry Baryshkov wrote:
> On 06/01/2023 09:16, Steev Klimaszewski wrote:
> > As of commit 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format
> > selection"), if no supported color formats are found, it tries to use the
> > driver provided default, which msm didn't have set and leads to the
> > following output:
> >
> > msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not
> > supported
> > msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not
> > supported
> > msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not
> > supported
> > msm_dpu ae01000.display-controller: [drm] No compatible format found
> > [ cut here ]
> > WARNING: CPU: 0 PID: 73 at drivers/gpu/drm/drm_atomic.c:1604
> > __drm_atomic_helper_set_config+0x240/0x33c
> > Modules linked in: ext4 mbcache jbd2 msm mdt_loader ocmem gpu_sched
> > llcc_qcom gpio_keys qrtr
> > CPU: 0 PID: 73 Comm: kworker/u16:2 Not tainted 6.2.0-rc2-next-20230106 #53
> > Hardware name: LENOVO 21BX0015US/21BX0015US, BIOS N3HET74W (1.46 )
> > 10/12/2022
> > Workqueue: events_unbound deferred_probe_work_func
> > pstate: 8045 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : __drm_atomic_helper_set_config+0x240/0x33c
> > lr : __drm_atomic_helper_set_config+0x68/0x33c
> > sp : 88a7b790
> > x29: 88a7b790 x28: 73ee3e130a00 x27:
> > x26: 73ee3d256e00 x25: 0038 x24: 73e6c0d65e00
> > x23: 73e6c17a7800 x22: 73e6c0d64e00 x21: 73e79c025e00
> > x20: c0d64e00 x19: 73ee3e130a00 x18:
> > x17: 662074616d726f66 x16: 20656c6269746170 x15:
> > x14: x13: x12:
> > x11: x10: x9 : a829144ff8bc
> > x8 : x7 : x6 :
> > x5 : 73e6c0d65f50 x4 : 73ee3d254950 x3 : 73e6c0d65ec0
> > x2 : 73ee3c953a00 x1 : 73e79c025580 x0 :
> > Call trace:
> > __drm_atomic_helper_set_config+0x240/0x33c
> > drm_client_modeset_commit_atomic+0x160/0x280
> > drm_client_modeset_commit_locked+0x64/0x194
> > drm_client_modeset_commit+0x38/0x60
> > __drm_fb_helper_initial_config_and_unlock+0x528/0x63c
> > drm_fb_helper_initial_config+0x54/0x64
> > msm_fbdev_init+0x94/0xfc [msm]
> > msm_drm_bind+0x548/0x614 [msm]
> > try_to_bring_up_aggregate_device+0x1e4/0x2d0
> > __component_add+0xc4/0x1c0
> > component_add+0x1c/0x2c
> > dp_display_probe+0x2a4/0x460 [msm]
> > platform_probe+0x70/0xcc
> > really_probe+0xc8/0x3e0
> > __driver_probe_device+0x84/0x190
> > driver_probe_device+0x44/0x120
> > __device_attach_driver+0xc4/0x160
> > bus_for_each_drv+0x84/0xe0
> > __device_attach+0xa4/0x1cc
> > device_initial_probe+0x1c/0x2c
> > bus_probe_device+0xa4/0xb0
> > deferred_probe_work_func+0xc0/0x114
> > process_one_work+0x1ec/0x470
> > worker_thread+0x74/0x410
> > kthread+0xfc/0x110
> > ret_from_fork+0x10/0x20
> > ---[ end trace 00000000 ]---
> >
> > Signed-off-by: Steev Klimaszewski
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> Suggested-by: Dmitry Baryshkov
> Reviewed-by: Dmitry Baryshkov
I think a documentation patch that preferred_depth = 0 actually means
xrgb would be good, since we seem to have a serious confusion going on
here?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/msm: Set preferred depth.
On Fri, Jan 06, 2023 at 09:31:31AM +0100, Thomas Zimmermann wrote:
> Am 06.01.23 um 08:16 schrieb Steev Klimaszewski:
> > As of commit 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format
> > selection"), if no supported color formats are found, it tries to use the
> > driver provided default, which msm didn't have set and leads to the
> > following output:
> >
> > msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not
> > supported
> > msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not
> > supported
> > msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not
> > supported
> > msm_dpu ae01000.display-controller: [drm] No compatible format found
> > [ cut here ]
> > WARNING: CPU: 0 PID: 73 at drivers/gpu/drm/drm_atomic.c:1604
> > __drm_atomic_helper_set_config+0x240/0x33c
> > Modules linked in: ext4 mbcache jbd2 msm mdt_loader ocmem gpu_sched
> > llcc_qcom gpio_keys qrtr
> > CPU: 0 PID: 73 Comm: kworker/u16:2 Not tainted 6.2.0-rc2-next-20230106 #53
> > Hardware name: LENOVO 21BX0015US/21BX0015US, BIOS N3HET74W (1.46 )
> > 10/12/2022
> > Workqueue: events_unbound deferred_probe_work_func
> > pstate: 8045 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : __drm_atomic_helper_set_config+0x240/0x33c
> > lr : __drm_atomic_helper_set_config+0x68/0x33c
> > sp : 88a7b790
> > x29: 88a7b790 x28: 73ee3e130a00 x27:
> > x26: 73ee3d256e00 x25: 0038 x24: 73e6c0d65e00
> > x23: 73e6c17a7800 x22: 73e6c0d64e00 x21: 73e79c025e00
> > x20: c0d64e00 x19: 73ee3e130a00 x18:
> > x17: 662074616d726f66 x16: 20656c6269746170 x15:
> > x14: x13: x12:
> > x11: x10: x9 : a829144ff8bc
> > x8 : x7 : x6 :
> > x5 : 73e6c0d65f50 x4 : 73ee3d254950 x3 : 73e6c0d65ec0
> > x2 : 73ee3c953a00 x1 : 73e79c025580 x0 :
> > Call trace:
> > __drm_atomic_helper_set_config+0x240/0x33c
> > drm_client_modeset_commit_atomic+0x160/0x280
> > drm_client_modeset_commit_locked+0x64/0x194
> > drm_client_modeset_commit+0x38/0x60
> > __drm_fb_helper_initial_config_and_unlock+0x528/0x63c
> > drm_fb_helper_initial_config+0x54/0x64
> > msm_fbdev_init+0x94/0xfc [msm]
> > msm_drm_bind+0x548/0x614 [msm]
> > try_to_bring_up_aggregate_device+0x1e4/0x2d0
> > __component_add+0xc4/0x1c0
> > component_add+0x1c/0x2c
> > dp_display_probe+0x2a4/0x460 [msm]
> > platform_probe+0x70/0xcc
> > really_probe+0xc8/0x3e0
> > __driver_probe_device+0x84/0x190
> > driver_probe_device+0x44/0x120
> > __device_attach_driver+0xc4/0x160
> > bus_for_each_drv+0x84/0xe0
> > __device_attach+0xa4/0x1cc
> > device_initial_probe+0x1c/0x2c
> > bus_probe_device+0xa4/0xb0
> > deferred_probe_work_func+0xc0/0x114
> > process_one_work+0x1ec/0x470
> > worker_thread+0x74/0x410
> > kthread+0xfc/0x110
> > ret_from_fork+0x10/0x20
> > ---[ end trace ]---
> >
> > Signed-off-by: Steev Klimaszewski
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index 8b0b0ac74a6f..65c4c93c311e 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -479,6 +479,7 @@ static int msm_drm_init(struct device *dev, const
> > struct drm_driver *drv)
> > drm_helper_move_panel_connectors_to_head(ddev);
> > + ddev->mode_config.preferred_depth = 24;
>
> Reviewed-by: Thomas Zimmermann
preferred_depth is not a mandatory thing, we need to fix the fbdev patch,
not work around that in all the drivers. xrgb is the assumed default.
-Daniel
>
> Best regards
> Thomas
>
> > ddev->mode_config.funcs = _config_funcs;
> > ddev->mode_config.helper_private = _config_helper_funcs;
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/msm: Add MSM_SUBMIT_BO_NO_IMPLICIT
On Thu, 5 Jan 2023 at 15:51, Rob Clark wrote:
>
> On Thu, Jan 5, 2023 at 4:49 AM Daniel Vetter wrote:
> >
> > On Tue, Dec 06, 2022 at 11:21:23AM -0800, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > In cases where implicit sync is used, it is still useful (for things
> > > like sub-allocation, etc) to allow userspace to opt-out of implicit
> > > sync on per-BO basis.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_drv.c| 3 ++-
> > > drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
> > > include/uapi/drm/msm_drm.h | 4 +++-
> > > 3 files changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > > index 017a512982a2..e0e1199a822f 100644
> > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > @@ -45,9 +45,10 @@
> > > * - 1.7.0 - Add MSM_PARAM_SUSPENDS to access suspend count
> > > * - 1.8.0 - Add MSM_BO_CACHED_COHERENT for supported GPUs (a6xx)
> > > * - 1.9.0 - Add MSM_SUBMIT_FENCE_SN_IN
> > > + * - 1.10.0 - Add MSM_SUBMIT_BO_NO_IMPLICIT
> > > */
> > > #define MSM_VERSION_MAJOR1
> > > -#define MSM_VERSION_MINOR9
> > > +#define MSM_VERSION_MINOR10
> > > #define MSM_VERSION_PATCHLEVEL 0
> > >
> > > static const struct drm_mode_config_funcs mode_config_funcs = {
> > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > index eb3536e3d66a..8bad07a04f85 100644
> > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > @@ -334,9 +334,20 @@ static int submit_fence_sync(struct msm_gem_submit
> > > *submit, bool no_implicit)
> > > if (ret)
> > > return ret;
> > >
> > > + /* If userspace has determined that explicit fencing is
> > > + * used, it can disable implicit sync on the entire
> > > + * submit:
> > > + */
> > > if (no_implicit)
> > > continue;
> > >
> > > + /* Otherwise userspace can ask for implicit sync to be
> > > + * disabled on specific buffers. This is useful for
> > > internal
> > > + * usermode driver managed buffers, suballocation, etc.
> > > + */
> > > + if (submit->bos[i].flags & MSM_SUBMIT_BO_NO_IMPLICIT)
> > > + continue;
> > > +
> > > ret = drm_sched_job_add_implicit_dependencies(>base,
> >
> > Won't this break shrinkers and fun stuff like that? It's why we added the
> > new USAGE_OTHER fence slot at least, and also why I wonder whether we
>
> Only if the entire explicit sync path was busted.. My daily driver for
> email/docs/meet/chat/corpstuff is a 4G device and CrOS is all explicit
> sync.. I would have found out rapidly and dramatically if it was
> busted :-P
>
> But seriously, this doesn't change what fences we attach to buffers,
> only what the sched job waits on
Oh I'm a silly one :-)
> > shouldn't push this into the helper to make the right call. Every driver
> > kinda needs the same wheel.
>
> We kinda already have moved everything we can (with the current
> driver-specific-uabi model) to helpers, what is left is driver
> specific ioctl parsing. We absolutely should take a step back and
> re-evaluate this before anyone else adds a new submit/execbuf ioctl.
> For example, the driver specific ioctl could just have a pointer to a
> drm_gem_submit_bo_table type structure, and then we could move the
> whole thing to a helper. Short of breaking the submit ioctl up (which
> a uring type uabi would let us do), I think the next best thing is to
> split out common cross-driver structs for common parts of
> submit/execbuf.
Yeah I thought this was the "attach fence to dma_resv" side of things.
This here is I think fine as a pattern, unless we build some kind of
outright submit ioctl helpers that take care of everything.
-Daniel
>
> BR,
> -R
>
> > -Daniel
> >
> > > obj,
> > > write);
> > > diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_d
Re: [Freedreno] [PATCH v2 0/8] drm/msm: DSC Electric Boogaloo for sm8[12]50
On Thu, Dec 22, 2022 at 12:19:35AM +0100, Marijn Suijten wrote: > This preliminary Display Stream Compression support package for > (initially tested on) sm8[12]50 is based on comparing DSC behaviour > between downstream and mainline. Some new callbacks are added (for > binding blocks on active CTLs), logic bugs are corrected, zeroed struct > members are now assigned proper values, and RM allocation and hw block > retrieval now hand out (or not) DSC blocks without causing null-pointer > dereferences. > > Unfortunately it is not yet enough to get rid of completely corrupted > display output on the boards I tested here: > - Sony Xperia 1 (sm8150), 1644x3840 or 1096x2560 pixels; > - Sony Xperia 5II (sm8250), 1080x2520, at 60 or 120Hz; > - (can include more Xperia boards if desired) > > Both devices use the DUALPIPE_DSCMERGE topology downstream: dual LM, PP > and DSC, but only a single INTF/encoder/DSI-link. > > Hopefully this spawns some community/upstream interest to help rootcause > our corruption issues (after we open a drm/msm report on GitLab for more > appropriate tracking). > > The Sony Xperia XZ3 (sdm845) was fully tested and validated with this > series to not cause any regressions (and one of the math fixes now > allows us to change slice_count in the panel driver, which would corrupt > previously). > > Changes since v1: > > - Split patch 6 into two separately backportable Fixes: patches; > - Additionally remove num_enc from msm_display_topology in favour of > num_dsc; > - Reorder patches to have all Fixes: at the beginning for easier > picking; > - Fix existing multiline comment while editing it anyway; > - Add missing Signed-off-by to patch 5. Please note that Electric Boogaloo/Boogaloo Boys has been appropriated by US alt-right groups, and so is really not a great thing to put into the cover letter for your patch series. For the next round, please use a meme that isn't tarnished like this. Thanks, Daniel > > v1: > https://lore.kernel.org/linux-arm-msm/20221213232207.113607-1-marijn.suij...@somainline.org/T/#u > > Marijn Suijten (8): > drm/msm/dpu: Wire up DSC mask for active CTL configuration > drm/msm/dsi: Use DSC slice(s) packet size to compute word count > drm/msm/dsi: Flip greater-than check for slice_count and > slice_per_intf > drm/msm/dpu: Disallow unallocated resources to be returned > drm/msm/dpu: Reject topologies for which no DSC blocks are available > drm/msm/dpu: Remove num_enc from topology struct in favour of num_dsc > drm/msm/dpu: Implement DSC binding to PP block for CTL V1 > drm/msm/dpu: Add DSC configuration for SM8150 and SM8250 > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 + > .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 1 + > .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 + > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 23 +++- > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 9 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 27 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 4 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 14 -- > drivers/gpu/drm/msm/dsi/dsi_host.c| 7 ++--- > drivers/gpu/drm/msm/msm_drv.h | 2 -- > 10 files changed, 82 insertions(+), 18 deletions(-) > > -- > 2.39.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v9 08/15] drm/bridge: add psr support for panel bridge callbacks
On Wed, Dec 14, 2022 at 03:35:45PM +0530, Vinod Polimera wrote:
> This change will handle the psr entry exit cases in the panel
> bridge atomic callback functions. For example, the panel power
> should not turn off if the panel is entering psr.
>
> Signed-off-by: Sankeerth Billakanti
> Signed-off-by: Vinod Polimera
I think this is all a nice integration of the sr helpers and bridge stuff
and makes sense to me. For the 2 bridge patches and the drm core atomic
patch:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/bridge/panel.c | 48
> ++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 3558cbf..5e77e38 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -113,6 +113,18 @@ static void panel_bridge_atomic_pre_enable(struct
> drm_bridge *bridge,
> struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *old_crtc_state;
> +
> + crtc = drm_atomic_get_new_crtc_for_encoder(atomic_state, encoder);
> + if (!crtc)
> + return;
> +
> + old_crtc_state = drm_atomic_get_old_crtc_state(atomic_state, crtc);
> + if (old_crtc_state && old_crtc_state->self_refresh_active)
> + return;
>
> drm_panel_prepare(panel_bridge->panel);
> }
> @@ -121,6 +133,18 @@ static void panel_bridge_atomic_enable(struct drm_bridge
> *bridge,
> struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *old_crtc_state;
> +
> + crtc = drm_atomic_get_new_crtc_for_encoder(atomic_state, encoder);
> + if (!crtc)
> + return;
> +
> + old_crtc_state = drm_atomic_get_old_crtc_state(atomic_state, crtc);
> + if (old_crtc_state && old_crtc_state->self_refresh_active)
> + return;
>
> drm_panel_enable(panel_bridge->panel);
> }
> @@ -129,6 +153,18 @@ static void panel_bridge_atomic_disable(struct
> drm_bridge *bridge,
> struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *new_crtc_state;
> +
> + crtc = drm_atomic_get_old_crtc_for_encoder(atomic_state, encoder);
> + if (!crtc)
> + return;
> +
> + new_crtc_state = drm_atomic_get_new_crtc_state(atomic_state, crtc);
> + if (new_crtc_state && new_crtc_state->self_refresh_active)
> + return;
>
> drm_panel_disable(panel_bridge->panel);
> }
> @@ -137,6 +173,18 @@ static void panel_bridge_atomic_post_disable(struct
> drm_bridge *bridge,
> struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *new_crtc_state;
> +
> + crtc = drm_atomic_get_old_crtc_for_encoder(atomic_state, encoder);
> + if (!crtc)
> + return;
> +
> + new_crtc_state = drm_atomic_get_new_crtc_state(atomic_state, crtc);
> + if (new_crtc_state && new_crtc_state->self_refresh_active)
> + return;
>
> drm_panel_unprepare(panel_bridge->panel);
> }
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/msm: Add MSM_SUBMIT_BO_NO_IMPLICIT
On Tue, Dec 06, 2022 at 11:21:23AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> In cases where implicit sync is used, it is still useful (for things
> like sub-allocation, etc) to allow userspace to opt-out of implicit
> sync on per-BO basis.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c| 3 ++-
> drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
> include/uapi/drm/msm_drm.h | 4 +++-
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 017a512982a2..e0e1199a822f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -45,9 +45,10 @@
> * - 1.7.0 - Add MSM_PARAM_SUSPENDS to access suspend count
> * - 1.8.0 - Add MSM_BO_CACHED_COHERENT for supported GPUs (a6xx)
> * - 1.9.0 - Add MSM_SUBMIT_FENCE_SN_IN
> + * - 1.10.0 - Add MSM_SUBMIT_BO_NO_IMPLICIT
> */
> #define MSM_VERSION_MAJOR1
> -#define MSM_VERSION_MINOR9
> +#define MSM_VERSION_MINOR10
> #define MSM_VERSION_PATCHLEVEL 0
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index eb3536e3d66a..8bad07a04f85 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -334,9 +334,20 @@ static int submit_fence_sync(struct msm_gem_submit
> *submit, bool no_implicit)
> if (ret)
> return ret;
>
> + /* If userspace has determined that explicit fencing is
> + * used, it can disable implicit sync on the entire
> + * submit:
> + */
> if (no_implicit)
> continue;
>
> + /* Otherwise userspace can ask for implicit sync to be
> + * disabled on specific buffers. This is useful for internal
> + * usermode driver managed buffers, suballocation, etc.
> + */
> + if (submit->bos[i].flags & MSM_SUBMIT_BO_NO_IMPLICIT)
> + continue;
> +
> ret = drm_sched_job_add_implicit_dependencies(>base,
Won't this break shrinkers and fun stuff like that? It's why we added the
new USAGE_OTHER fence slot at least, and also why I wonder whether we
shouldn't push this into the helper to make the right call. Every driver
kinda needs the same wheel.
-Daniel
> obj,
> write);
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index f54b48ef6a2d..329100016e7c 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -222,10 +222,12 @@ struct drm_msm_gem_submit_cmd {
> #define MSM_SUBMIT_BO_READ 0x0001
> #define MSM_SUBMIT_BO_WRITE0x0002
> #define MSM_SUBMIT_BO_DUMP 0x0004
> +#define MSM_SUBMIT_BO_NO_IMPLICIT 0x0008
>
> #define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | \
> MSM_SUBMIT_BO_WRITE | \
> - MSM_SUBMIT_BO_DUMP)
> + MSM_SUBMIT_BO_DUMP | \
> + MSM_SUBMIT_BO_NO_IMPLICIT)
>
> struct drm_msm_gem_submit_bo {
> __u32 flags; /* in, mask of MSM_SUBMIT_BO_x */
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote: > Introduce and add support for a solid_fill property. When the solid_fill > property is set, and the framebuffer is set to NULL, memory fetch will be > disabled. > > In addition, loosen the NULL FB checks within the atomic commit callstack > to allow a NULL FB when the solid_fill property is set and add FB checks > in methods where the FB was previously assumed to be non-NULL. > > Finally, have the DPU driver use drm_plane_state.solid_fill and instead of > dpu_plane_state.color_fill, and add extra checks in the DPU atomic commit > callstack to account for a NULL FB in cases where solid_fill is set. > > Some drivers support hardware that have optimizations for solid fill > planes. This series aims to expose these capabilities to userspace as > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android > hardware composer HAL) that can be set by apps like the Android Gears > app. > > Userspace can set the solid_fill property to a blob containing the > appropriate version number and solid fill color (in RGB323232 format) and > setting the framebuffer to NULL. > > Note: Currently, there's only one version of the solid_fill blob property. > However if other drivers want to support a similar feature, but require > more than just the solid fill color, they can extend this feature by > creating additional versions of the drm_solid_fill struct. > > Changes in V2: > - Dropped SOLID_FILL_FORMAT property (Simon) > - Switched to implementing solid_fill property as a blob (Simon, Dmitry) > - Changed to checks for if solid_fill_blob is set (Dmitry) > - Abstracted (plane_state && !solid_fill_blob) checks to helper method > (Dmitry) > - Removed DPU_PLANE_COLOR_FILL_FLAG > - Fixed whitespace and indentation issues (Dmitry) Now that this is a blob, I do wonder again whether it's not cleaner to set the blob as the FB pointer. Or create some kind other kind of special data source objects (because solid fill is by far not the only such thing). We'd still end up in special cases like when userspace that doesn't understand solid fill tries to read out such a framebuffer, but these cases already exist anyway for lack of priviledges. So I still think that feels like the more consistent way to integrate this feature. Which doesn't mean it has to happen like that, but the patches/cover letter should at least explain why we don't do it like this. -Daniel > > Changes in V3: > - Fixed some logic errors in atomic checks (Dmitry) > - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper > methods (Dmitry) > > Jessica Zhang (3): > drm: Introduce solid fill property for drm plane > drm: Adjust atomic checks for solid fill color > drm/msm/dpu: Use color_fill property for DPU planes > > drivers/gpu/drm/drm_atomic.c | 136 +- > drivers/gpu/drm/drm_atomic_helper.c | 34 +++--- > drivers/gpu/drm/drm_atomic_state_helper.c | 9 ++ > drivers/gpu/drm/drm_atomic_uapi.c | 59 ++ > drivers/gpu/drm/drm_blend.c | 17 +++ > drivers/gpu/drm/drm_plane.c | 8 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 65 +++ > include/drm/drm_atomic_helper.h | 5 +- > include/drm/drm_blend.h | 1 + > include/drm/drm_plane.h | 62 ++ > 11 files changed, 302 insertions(+), 103 deletions(-) > > -- > 2.38.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On Wed, Nov 09, 2022 at 05:44:37PM -0800, Jessica Zhang wrote: > > > On 11/9/2022 5:59 AM, Daniel Vetter wrote: > > On Wed, Nov 09, 2022 at 04:53:45PM +0300, Dmitry Baryshkov wrote: > > > On 09/11/2022 16:52, Daniel Vetter wrote: > > > > On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: > > > > > On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov > > > > > wrote: > > > > > > > > > > > On 29/10/2022 01:59, Jessica Zhang wrote: > > > > > > > > > > > > > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for > > > > > > > drm_plane. In addition, add support for setting and getting the > > > > > > > values > > > > > > > of these properties. > > > > > > > > > > > > > > COLOR_FILL represents the color fill of a plane while > > > > > > > COLOR_FILL_FORMAT > > > > > > > represents the format of the color fill. Userspace can set enable > > > > > > > solid > > > > > > > fill on a plane by assigning COLOR_FILL to a uint64_t value, > > > > > > > assigning > > > > > > > the COLOR_FILL_FORMAT property to a uint32_t value, and setting > > > > > > > the > > > > > > > framebuffer to NULL. > > > > > > > > > > > > I suppose that COLOR_FILL should override framebuffer rather than > > > > > > requiring that FB is set to NULL. In other words, if > > > > > > color_filL_format > > > > > > is non-zero, it would make sense to ignore the FB. Then one can use > > > > > > the > > > > > > color_fill_format property to quickly switch between filled plane > > > > > > and > > > > > > FB-backed one. > > > > > > > > > > That would be inconsistent with the rest of the KMS uAPI. For > > > > > instance, > > > > > the kernel will error out if CRTC has active=0 but a connector is > > > > > still > > > > > linked to the CRTC. IOW, the current uAPI errors out if the KMS state > > > > > is inconsistent. > > > > > > > > So if the use-case here really is to solid-fill a plane (and not just > > > > provide a background color for the crtc overall), then I guess we could > > > > also extend addfb to make that happen. We've talked in the past about > > > > propertery-fying framebuffer objects, and that would sort out this uapi > > > > wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at > > > > least. > > > > > > > > But if the use-cases are all background color then just doing the crtc > > > > background color would be tons simpler (and likely also easier to > > > > support > > > > for more hardware). > > > > > > No. The hardware supports multiple color-filled planes, which do not have > > > to > > > cover the whole CRTC. > > > > The use case here means the userspace use-case. What the hw can do on any > > given chip kinda doesnt matter, which is why I'm asking. KMD uapi is not > > meant to reflect 100% exactly what a specific chip can do, but instead: > > - provide features userspace actually needs. If you want per-plane fill, > >you need userspace that makes use of per-plane fill, and if all you have > >is crtc background, then that's it. > > Hey Daniel, > > The userspace use case we're trying to support is the Android HWC SOLID_FILL > hint here [1], which is specifying per-plane fill. Does surfaceflinger actually use this for more than background fills? Yes I'm annoying, but if we can simplify the kernel driver implementation burden by asking compositors to do the math and simplify things, then I think we should. We also need an open source implementation for this that works and is tested end-to-end. There's the drm_hwc project, but last time I've checked there's really not much happpening there unfortunately. -Daniel > > Thanks, > > Jessica Zhang > > [1] > https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/master/graphics/composer/aidl/android/hardware/graphics/composer3/Composition.aidl#52 > > > - we should create uapi with an eye towards what's actually possible on a > >reasonable set of drivers and hw. Sometimes that means a slightly more > >restricted set so that it's possible to implement in more places, > >especially if that restricted feature set still gets the job done for > >userspace. > > > > Cheers, Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On Wed, Nov 09, 2022 at 04:53:45PM +0300, Dmitry Baryshkov wrote: > On 09/11/2022 16:52, Daniel Vetter wrote: > > On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: > > > On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov > > > wrote: > > > > > > > On 29/10/2022 01:59, Jessica Zhang wrote: > > > > > > > > > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for > > > > > drm_plane. In addition, add support for setting and getting the values > > > > > of these properties. > > > > > > > > > > COLOR_FILL represents the color fill of a plane while > > > > > COLOR_FILL_FORMAT > > > > > represents the format of the color fill. Userspace can set enable > > > > > solid > > > > > fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning > > > > > the COLOR_FILL_FORMAT property to a uint32_t value, and setting the > > > > > framebuffer to NULL. > > > > > > > > I suppose that COLOR_FILL should override framebuffer rather than > > > > requiring that FB is set to NULL. In other words, if color_filL_format > > > > is non-zero, it would make sense to ignore the FB. Then one can use the > > > > color_fill_format property to quickly switch between filled plane and > > > > FB-backed one. > > > > > > That would be inconsistent with the rest of the KMS uAPI. For instance, > > > the kernel will error out if CRTC has active=0 but a connector is still > > > linked to the CRTC. IOW, the current uAPI errors out if the KMS state > > > is inconsistent. > > > > So if the use-case here really is to solid-fill a plane (and not just > > provide a background color for the crtc overall), then I guess we could > > also extend addfb to make that happen. We've talked in the past about > > propertery-fying framebuffer objects, and that would sort out this uapi > > wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least. > > > > But if the use-cases are all background color then just doing the crtc > > background color would be tons simpler (and likely also easier to support > > for more hardware). > > No. The hardware supports multiple color-filled planes, which do not have to > cover the whole CRTC. The use case here means the userspace use-case. What the hw can do on any given chip kinda doesnt matter, which is why I'm asking. KMD uapi is not meant to reflect 100% exactly what a specific chip can do, but instead: - provide features userspace actually needs. If you want per-plane fill, you need userspace that makes use of per-plane fill, and if all you have is crtc background, then that's it. - we should create uapi with an eye towards what's actually possible on a reasonable set of drivers and hw. Sometimes that means a slightly more restricted set so that it's possible to implement in more places, especially if that restricted feature set still gets the job done for userspace. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: > On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov > wrote: > > > On 29/10/2022 01:59, Jessica Zhang wrote: > > > > > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for > > > drm_plane. In addition, add support for setting and getting the values > > > of these properties. > > > > > > COLOR_FILL represents the color fill of a plane while COLOR_FILL_FORMAT > > > represents the format of the color fill. Userspace can set enable solid > > > fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning > > > the COLOR_FILL_FORMAT property to a uint32_t value, and setting the > > > framebuffer to NULL. > > > > I suppose that COLOR_FILL should override framebuffer rather than > > requiring that FB is set to NULL. In other words, if color_filL_format > > is non-zero, it would make sense to ignore the FB. Then one can use the > > color_fill_format property to quickly switch between filled plane and > > FB-backed one. > > That would be inconsistent with the rest of the KMS uAPI. For instance, > the kernel will error out if CRTC has active=0 but a connector is still > linked to the CRTC. IOW, the current uAPI errors out if the KMS state > is inconsistent. So if the use-case here really is to solid-fill a plane (and not just provide a background color for the crtc overall), then I guess we could also extend addfb to make that happen. We've talked in the past about propertery-fying framebuffer objects, and that would sort out this uapi wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least. But if the use-cases are all background color then just doing the crtc background color would be tons simpler (and likely also easier to support for more hardware). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
return -EFAULT;
> > >>>>>>>>> +
> > >>>>>>>>> + return 0;
> > >>>>>>>>> +}
> > >>>>>>>>> +
> > >>>>>>>>> static long dma_buf_ioctl(struct file *file,
> > >>>>>>>>> unsigned int cmd, unsigned long arg)
> > >>>>>>>>> {
> > >>>>>>>>> @@ -369,6 +412,9 @@ static long dma_buf_ioctl(struct file *file,
> > >>>>>>>>> case DMA_BUF_SET_NAME_B:
> > >>>>>>>>> return dma_buf_set_name(dmabuf, (const char
> > >>>>>>>>> __user *)arg);
> > >>>>>>>>>
> > >>>>>>>>> + case DMA_BUF_IOCTL_INFO:
> > >>>>>>>>> + return dma_buf_info(dmabuf, (void __user *)arg);
> > >>>>>>>>> +
> > >>>>>>>>> default:
> > >>>>>>>>> return -ENOTTY;
> > >>>>>>>>> }
> > >>>>>>>>> @@ -530,6 +576,7 @@ struct dma_buf *dma_buf_export(const struct
> > >>>>>>>>> dma_buf_export_info *exp_info)
> > >>>>>>>>> dmabuf->priv = exp_info->priv;
> > >>>>>>>>> dmabuf->ops = exp_info->ops;
> > >>>>>>>>> dmabuf->size = exp_info->size;
> > >>>>>>>>> + dmabuf->map_info = exp_info->map_info;
> > >>>>>>>>> dmabuf->exp_name = exp_info->exp_name;
> > >>>>>>>>> dmabuf->owner = exp_info->owner;
> > >>>>>>>>> spin_lock_init(>name_lock);
> > >>>>>>>>> @@ -1245,10 +1292,6 @@ int dma_buf_mmap(struct dma_buf *dmabuf,
> > >>>>>>>>> struct vm_area_struct *vma,
> > >>>>>>>>> if (WARN_ON(!dmabuf || !vma))
> > >>>>>>>>> return -EINVAL;
> > >>>>>>>>>
> > >>>>>>>>> - /* check if buffer supports mmap */
> > >>>>>>>>> - if (!dmabuf->ops->mmap)
> > >>>>>>>>> - return -EINVAL;
> > >>>>>>>>> -
> > >>>>>>>>> /* check for offset overflow */
> > >>>>>>>>> if (pgoff + vma_pages(vma) < pgoff)
> > >>>>>>>>> return -EOVERFLOW;
> > >>>>>>>>> @@ -1262,7 +1305,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf,
> > >>>>>>>>> struct vm_area_struct *vma,
> > >>>>>>>>> vma_set_file(vma, dmabuf->file);
> > >>>>>>>>> vma->vm_pgoff = pgoff;
> > >>>>>>>>>
> > >>>>>>>>> - return dmabuf->ops->mmap(dmabuf, vma);
> > >>>>>>>>> + return __dma_buf_mmap(dmabuf, vma);
> > >>>>>>>>> }
> > >>>>>>>>> EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
> > >>>>>>>>>
> > >>>>>>>>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > >>>>>>>>> index 71731796c8c3..37923c8d5c24 100644
> > >>>>>>>>> --- a/include/linux/dma-buf.h
> > >>>>>>>>> +++ b/include/linux/dma-buf.h
> > >>>>>>>>> @@ -23,6 +23,8 @@
> > >>>>>>>>> #include
> > >>>>>>>>> #include
> > >>>>>>>>>
> > >>>>>>>>> +#include
> > >>>>>>>>> +
> > >>>>>>>>> struct device;
> > >>>>>>>>> struct dma_buf;
> > >>>>>>>>> struct dma_buf_attachment;
> > >>>>>>>>> @@ -307,6 +309,13 @@ struct dma_buf {
> > >>>>>>>>>*/
> > >>>>>>>>> size_t size;
> > >>>>>>>>>
> > >>>>>>>>> + /**
> > >>>>>>>>> + * @map_info:
> > >>>>>>>>> + *
> > >>>>>>>>> + * CPU mapping/coherency information for the buffer.
> > >>>>>>>>> + */
> > >>>>>>>>> + enum dma_buf_map_info map_info;
> > >>>>>>>>> +
> > >>>>>>>>> /**
> > >>>>>>>>>* @file:
> > >>>>>>>>>*
> > >>>>>>>>> @@ -533,6 +542,7 @@ struct dma_buf_attachment {
> > >>>>>>>>>* @ops:Attach allocator-defined dma buf ops to the new
> > >>>>>>>>> buffer
> > >>>>>>>>>* @size: Size of the buffer - invariant over the
> > >>>>>>>>> lifetime of the buffer
> > >>>>>>>>>* @flags: mode flags for the file
> > >>>>>>>>> + * @map_info:CPU mapping/coherency information for the
> > >>>>>>>>> buffer
> > >>>>>>>>>* @resv: reservation-object, NULL to allocate default one
> > >>>>>>>>>* @priv: Attach private data of allocator to this buffer
> > >>>>>>>>>*
> > >>>>>>>>> @@ -545,6 +555,7 @@ struct dma_buf_export_info {
> > >>>>>>>>> const struct dma_buf_ops *ops;
> > >>>>>>>>> size_t size;
> > >>>>>>>>> int flags;
> > >>>>>>>>> + enum dma_buf_map_info map_info;
> > >>>>>>>>> struct dma_resv *resv;
> > >>>>>>>>> void *priv;
> > >>>>>>>>> };
> > >>>>>>>>> diff --git a/include/uapi/linux/dma-buf.h
> > >>>>>>>>> b/include/uapi/linux/dma-buf.h
> > >>>>>>>>> index b1523cb8ab30..07b403ffdb43 100644
> > >>>>>>>>> --- a/include/uapi/linux/dma-buf.h
> > >>>>>>>>> +++ b/include/uapi/linux/dma-buf.h
> > >>>>>>>>> @@ -85,6 +85,72 @@ struct dma_buf_sync {
> > >>>>>>>>>
> > >>>>>>>>> #define DMA_BUF_NAME_LEN32
> > >>>>>>>>>
> > >>>>>>>>> +/**
> > >>>>>>>>> + * enum dma_buf_map_info - CPU mapping info
> > >>>>>>>>> + *
> > >>>>>>>>> + * This enum describes coherency of a userspace mapping of the
> > >>>>>>>>> dmabuf.
> > >>>>>>>>> + *
> > >>>>>>>>> + * Importing devices should check dma_buf::map_info flag and
> > >>>>>>>>> reject an
> > >>>>>>>>> + * import if unsupported. For example, if the exporting device
> > >>>>>>>>> uses
> > >>>>>>>>> + * @DMA_BUF_COHERENT_CACHED but the importing device does not
> > >>>>>>>>> support
> > >>>>>>>>> + * CPU cache coherency, the dma-buf import should fail.
> > >>>>>>>>> + */
> > >>>>>>>>> +enum dma_buf_map_info {
> > >>>>>>>>> + /**
> > >>>>>>>>> + * @DMA_BUF_MAP_INCOHERENT: CPU mapping is incoherent.
> > >>>>>>>>> + *
> > >>>>>>>>> + * Use of DMA_BUF_IOCTL_SYNC is required for CPU managed
> > >>>>>>>>> coherenency.
> > >>>>>>>>> + */
> > >>>>>>>>> + DMA_BUF_MAP_INCOHERENT,
> > >>>>>>>>> +
> > >>>>>>>>> + /**
> > >>>>>>>>> + * @DMA_BUF_COHERENT_WC: CPU mapping is coherent but not
> > >>>>>>>>> cached.
> > >>>>>>>>> + *
> > >>>>>>>>> + * A cpu mmap'ing is coherent, and DMA_BUF_IOCTL_SYNC is
> > >>>>>>>>> not required.
> > >>>>>>>>> + * However fences may be still required for synchronizing
> > >>>>>>>>> access. Ie.
> > >>>>>>>>> + * coherency can only be relied upon by an explicit-fencing
> > >>>>>>>>> userspace.
> > >>>>>>>>> + * An implicit-sync userspace must still use
> > >>>>>>>>> DMA_BUF_IOCTL_SYNC.
> > >>>>>>>>> + *
> > >>>>>>>>> + * The cpu mapping is writecombine.
> > >>>>>>>>> + */
> > >>>>>>>>> + DMA_BUF_COHERENT_WC,
> > >>>>>>>>> +
> > >>>>>>>>> + /**
> > >>>>>>>>> + * @DMA_BUF_COHERENT_CACHED: CPU mapping is coherent and
> > >>>>>>>>> CPU cached.
> > >>>>>>>>> + *
> > >>>>>>>>> + * A cpu mmap'ing is coherent, and DMA_BUF_IOCTL_SYNC is
> > >>>>>>>>> not required.
> > >>>>>>>>> + * However fences may be still required for synchronizing
> > >>>>>>>>> access. Ie.
> > >>>>>>>>> + * coherency can only be relied upon by an explicit-fencing
> > >>>>>>>>> userspace.
> > >>>>>>>>> + * An implicit-sync userspace must still use
> > >>>>>>>>> DMA_BUF_IOCTL_SYNC.
> > >>>>>>>>> + *
> > >>>>>>>>> + * The cpu mapping is cached.
> > >>>>>>>>> + */
> > >>>>>>>>> + DMA_BUF_COHERENT_CACHED,
> > >>>>>>>>> +};
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + * struct dma_buf_info - Query info about the buffer.
> > >>>>>>>>> + */
> > >>>>>>>>> +struct dma_buf_info {
> > >>>>>>>>> +
> > >>>>>>>>> +#define DMA_BUF_INFO_MAP_INFO1
> > >>>>>>>>> +
> > >>>>>>>>> + /**
> > >>>>>>>>> + * @param: Which param to query
> > >>>>>>>>> + *
> > >>>>>>>>> + * DMA_BUF_INFO_MAP_INFO:
> > >>>>>>>>> + * Returns enum dma_buf_map_info, describing the
> > >>>>>>>>> coherency and
> > >>>>>>>>> + * caching of a CPU mapping of the buffer.
> > >>>>>>>>> + */
> > >>>>>>>>> + __u32 param;
> > >>>>>>>>> + __u32 pad;
> > >>>>>>>>> +
> > >>>>>>>>> + /**
> > >>>>>>>>> + * @value: Return value of the query.
> > >>>>>>>>> + */
> > >>>>>>>>> + __u64 value;
> > >>>>>>>>> +};
> > >>>>>>>>> +
> > >>>>>>>>> #define DMA_BUF_BASE'b'
> > >>>>>>>>> #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct
> > >>>>>>>>> dma_buf_sync)
> > >>>>>>>>>
> > >>>>>>>>> @@ -95,4 +161,6 @@ struct dma_buf_sync {
> > >>>>>>>>> #define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, __u32)
> > >>>>>>>>> #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64)
> > >>>>>>>>>
> > >>>>>>>>> +#define DMA_BUF_IOCTL_INFO _IOWR(DMA_BUF_BASE, 2, struct
> > >>>>>>>>> dma_buf_info)
> > >>>>>>>>> +
> > >>>>>>>>> #endif
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
-1245,10 +1292,6 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
> > > > vm_area_struct *vma,
> > > >if (WARN_ON(!dmabuf || !vma))
> > > >return -EINVAL;
> > > >
> > > > - /* check if buffer supports mmap */
> > > > - if (!dmabuf->ops->mmap)
> > > > - return -EINVAL;
> > > > -
> > > >/* check for offset overflow */
> > > >if (pgoff + vma_pages(vma) < pgoff)
> > > >return -EOVERFLOW;
> > > > @@ -1262,7 +1305,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
> > > > vm_area_struct *vma,
> > > >vma_set_file(vma, dmabuf->file);
> > > >vma->vm_pgoff = pgoff;
> > > >
> > > > - return dmabuf->ops->mmap(dmabuf, vma);
> > > > + return __dma_buf_mmap(dmabuf, vma);
> > > >}
> > > >EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
> > > >
> > > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > > index 71731796c8c3..37923c8d5c24 100644
> > > > --- a/include/linux/dma-buf.h
> > > > +++ b/include/linux/dma-buf.h
> > > > @@ -23,6 +23,8 @@
> > > >#include
> > > >#include
> > > >
> > > > +#include
> > > > +
> > > >struct device;
> > > >struct dma_buf;
> > > >struct dma_buf_attachment;
> > > > @@ -307,6 +309,13 @@ struct dma_buf {
> > > > */
> > > >size_t size;
> > > >
> > > > + /**
> > > > + * @map_info:
> > > > + *
> > > > + * CPU mapping/coherency information for the buffer.
> > > > + */
> > > > + enum dma_buf_map_info map_info;
> > > > +
> > > >/**
> > > > * @file:
> > > > *
> > > > @@ -533,6 +542,7 @@ struct dma_buf_attachment {
> > > > * @ops:Attach allocator-defined dma buf ops to the new buffer
> > > > * @size: Size of the buffer - invariant over the lifetime of the
> > > > buffer
> > > > * @flags: mode flags for the file
> > > > + * @map_info:CPU mapping/coherency information for the buffer
> > > > * @resv: reservation-object, NULL to allocate default one
> > > > * @priv: Attach private data of allocator to this buffer
> > > > *
> > > > @@ -545,6 +555,7 @@ struct dma_buf_export_info {
> > > >const struct dma_buf_ops *ops;
> > > >size_t size;
> > > >int flags;
> > > > + enum dma_buf_map_info map_info;
> > > >struct dma_resv *resv;
> > > >void *priv;
> > > >};
> > > > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> > > > index b1523cb8ab30..07b403ffdb43 100644
> > > > --- a/include/uapi/linux/dma-buf.h
> > > > +++ b/include/uapi/linux/dma-buf.h
> > > > @@ -85,6 +85,72 @@ struct dma_buf_sync {
> > > >
> > > >#define DMA_BUF_NAME_LEN32
> > > >
> > > > +/**
> > > > + * enum dma_buf_map_info - CPU mapping info
> > > > + *
> > > > + * This enum describes coherency of a userspace mapping of the dmabuf.
> > > > + *
> > > > + * Importing devices should check dma_buf::map_info flag and reject an
> > > > + * import if unsupported. For example, if the exporting device uses
> > > > + * @DMA_BUF_COHERENT_CACHED but the importing device does not support
> > > > + * CPU cache coherency, the dma-buf import should fail.
> > > > + */
> > > > +enum dma_buf_map_info {
> > > > + /**
> > > > + * @DMA_BUF_MAP_INCOHERENT: CPU mapping is incoherent.
> > > > + *
> > > > + * Use of DMA_BUF_IOCTL_SYNC is required for CPU managed
> > > > coherenency.
> > > > + */
> > > > + DMA_BUF_MAP_INCOHERENT,
> > > > +
> > > > + /**
> > > > + * @DMA_BUF_COHERENT_WC: CPU mapping is coherent but not cached.
> > > > + *
> > > > + * A cpu mmap'ing is coherent, and DMA_BUF_IOCTL_SYNC is not
> > > > required.
> > > > + * However fences may be still required for synchronizing access.
> > > > Ie.
> > > > + * coherency can only be relied upon by an explicit-fencing
> > > > userspace.
> > > > + * An implicit-sync userspace must still use DMA_BUF_IOCTL_SYNC.
> > > > + *
> > > > + * The cpu mapping is writecombine.
> > > > + */
> > > > + DMA_BUF_COHERENT_WC,
> > > > +
> > > > + /**
> > > > + * @DMA_BUF_COHERENT_CACHED: CPU mapping is coherent and CPU
> > > > cached.
> > > > + *
> > > > + * A cpu mmap'ing is coherent, and DMA_BUF_IOCTL_SYNC is not
> > > > required.
> > > > + * However fences may be still required for synchronizing access.
> > > > Ie.
> > > > + * coherency can only be relied upon by an explicit-fencing
> > > > userspace.
> > > > + * An implicit-sync userspace must still use DMA_BUF_IOCTL_SYNC.
> > > > + *
> > > > + * The cpu mapping is cached.
> > > > + */
> > > > + DMA_BUF_COHERENT_CACHED,
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct dma_buf_info - Query info about the buffer.
> > > > + */
> > > > +struct dma_buf_info {
> > > > +
> > > > +#define DMA_BUF_INFO_MAP_INFO1
> > > > +
> > > > + /**
> > > > + * @param: Which param to query
> > > > + *
> > > > + * DMA_BUF_INFO_MAP_INFO:
> > > > + * Returns enum dma_buf_map_info, describing the coherency and
> > > > + * caching of a CPU mapping of the buffer.
> > > > + */
> > > > + __u32 param;
> > > > + __u32 pad;
> > > > +
> > > > + /**
> > > > + * @value: Return value of the query.
> > > > + */
> > > > + __u64 value;
> > > > +};
> > > > +
> > > >#define DMA_BUF_BASE'b'
> > > >#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct
> > > > dma_buf_sync)
> > > >
> > > > @@ -95,4 +161,6 @@ struct dma_buf_sync {
> > > >#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, __u32)
> > > >#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64)
> > > >
> > > > +#define DMA_BUF_IOCTL_INFO _IOWR(DMA_BUF_BASE, 2, struct
> > > > dma_buf_info)
> > > > +
> > > >#endif
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [Linaro-mm-sig] [PATCH v2 1/3] dma-buf: Add ioctl to query mmap info
MA_BUF_VM_PROT_x
> + */
> + __u32 param;
> + __u32 pad;
> +
> + /**
> + * @value: Return value of the query.
> + */
> + __u64 value;
> +};
> +
> #define DMA_BUF_BASE 'b'
> #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
>
> @@ -95,4 +121,6 @@ struct dma_buf_sync {
> #define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, __u32)
> #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64)
>
> +#define DMA_BUF_IOCTL_INFO _IOWR(DMA_BUF_BASE, 2, struct dma_buf_info)
> +
> #endif
> --
> 2.36.1
>
> ___
> Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/msm/gem: Drop obj lock in msm_gem_free_object()
On Fri, Jun 24, 2022 at 02:28:25PM -0700, Rob Clark wrote:
> On Fri, Jun 24, 2022 at 1:58 PM Daniel Vetter wrote:
> >
> > On Thu, Jun 16, 2022 at 06:59:46AM -0700, Rob Clark wrote:
> > > On Thu, Jun 16, 2022 at 1:28 AM Stephen Boyd wrote:
> > > >
> > > > Quoting Rob Clark (2022-06-13 13:50:32)
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gem.h
> > > > > b/drivers/gpu/drm/msm/msm_gem.h
> > > > > index d608339c1643..432032ad4aed 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gem.h
> > > > > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > > > > @@ -229,7 +229,19 @@ msm_gem_unlock(struct drm_gem_object *obj)
> > > > > static inline bool
> > > > > msm_gem_is_locked(struct drm_gem_object *obj)
> > > > > {
> > > > > - return dma_resv_is_locked(obj->resv);
> > > > > + /*
> > > > > +* Destroying the object is a special case..
> > > > > msm_gem_free_object()
> > > > > +* calls many things that WARN_ON if the obj lock is not
> > > > > held. But
> > > > > +* acquiring the obj lock in msm_gem_free_object() can cause a
> > > > > +* locking order inversion between reservation_ww_class_mutex
> > > > > and
> > > > > +* fs_reclaim.
> > > > > +*
> > > > > +* This deadlock is not actually possible, because no one
> > > > > should
> > > > > +* be already holding the lock when msm_gem_free_object() is
> > > > > called.
> > > > > +* Unfortunately lockdep is not aware of this detail. So
> > > > > when the
> > > > > +* refcount drops to zero, we pretend it is already locked.
> > > > > +*/
> > > > > + return dma_resv_is_locked(obj->resv) ||
> > > > > (kref_read(>refcount) == 0);
> > > >
> > > > Instead of modifying this function can we push down the fact that this
> > > > function is being called from the free path and skip checking this
> > > > condition in that case? Or add some "_locked/free_path" wrappers that
> > > > skip the lock assertion? That would make it clearer to understand while
> > > > reading the code that it is locked when it is asserted to be locked, and
> > > > that we don't care when we're freeing because all references to the
> > > > object are gone.
> > >
> > > that was my earlier attempt, and I wasn't too happy with the result.
> > > And then I realized if refcount==0 then by definition we aren't racing
> > > with anyone else ;-)
> >
> > I think that's not entirely correct, at least not for fairly reasonable
> > shrinker designs:
> >
> > If the shrinker trylocks for throwing stuff out it might race with a
> > concurrent finalization. Depends a bit upon your design, but usually
> > that's possible.
>
> Kinda but in fact no. At least not if your shrinker is designed properly.
>
> The shrinker does kref_get_unless_zero() and bails in the case that
> we've already started finalizing. See:
>
> https://patchwork.freedesktop.org/patch/490160/
Oh you have the order differently than what I'd have typed. If you do
dma_resv_trylock under the lru lock then the kref_get_unless_zero isn't
needed.
Ofc if you do it like you do then you need your locking check trickery.
> > There won't be a problem since you'll serialize on a lock eventually. But
> > if you drop all your locking debug checks like this then it's very hard to
> > figure this out :-)
> >
> > Ofc you can adjust your refcounting scheme to make this impossible, but
> > then there's also not really any need to call any functions which might
> > need some locking, since by that time all that stuff must have been
> > cleaned up already (or the refcount could not have dropped to zero). Like
> > if any iova mapping holds a reference you never have these problems.
> >
> > Long story short, this kind of design freaks me out big time. Especially
> > when it involves both a cross-driver refcount like the gem_bo one and a
> > cross driver lock ...
> >
> > The standard way to fix this is to trylock dma_resv on cleanup and push to
> > a worker if you can't get it. This is what ttm and i915 does. Might be
> > good to lift that into drm_gem.c helpers and just use it.
>
> We used to do that (but unconditionally).. and got rid of it because
>
Re: [Freedreno] Please add another drm/msm tree to the linux-next
On Wed, Jun 15, 2022 at 05:19:42PM +0300, Dmitry Baryshkov wrote: > Hi Stephen, > > I would appreciate if you could add > > https://gitlab.freedesktop.org/lumag/msm.git msm-next-lumag > > to the linux-next tree. > > This tree is a part of drm/msm maintenance structure. As a co-maintainer I > collect and test display patches, while Rob concenctrates on GPU part of the > driver. Later during the release cycle these patchesare pulled by Rob Clark > directly into msm-next. > > During last cycle Rob suggested adding this tree to the linux-next effort, > so that the patches receive better integration testing during the Linux > development cycle. Have you guys thought of group maintainering? Single point of failure trees freak me out a bit, it tends to build silos pretty hard. Simplest path is to just toss it all into drm-misc, but at least have one tree for your driver. Building new single maintainer silos after I've run around for years collecting them all is rather meh. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/msm/gem: Drop obj lock in msm_gem_free_object()
RN_ON(!msm_gem_is_locked(obj));
> > + put_iova_spaces_locked(obj, close);
> > +}
>
> they are both _locked paths ;-)
>
> But in general I think the parallel code paths make things more
> confusing about what is the right thing to call. And I would like to
> put more WARN_ON(!locked()) in the gem_vma code, to make it clear that
> the obj lock is protecting things there as well.. which, with this
> approach would turn into parallel code paths multiple levels deep
>
> BR,
> -R
>
> > +
> > +/* Called with msm_obj locked or on the free path */
> > static void
> > -put_iova_vmas(struct drm_gem_object *obj)
> > +put_iova_vmas_locked(struct drm_gem_object *obj)
> > {
> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> > struct msm_gem_vma *vma, *tmp;
> >
> > - GEM_WARN_ON(!msm_gem_is_locked(obj));
> > -
> > - list_for_each_entry_safe(vma, tmp, _obj->vmas, list) {
> > + list_for_each_entry_safe(vma, tmp, _obj->vmas, list)
> > del_vma(vma);
> > - }
> > +}
> > +
> > +static void
> > +put_iova_vmas(struct drm_gem_object *obj)
> > +{
> > + GEM_WARN_ON(!msm_gem_is_locked(obj));
> > + put_iova_vmas_locked(obj);
> > }
> >
> > static struct msm_gem_vma *get_vma_locked(struct drm_gem_object *obj,
> > @@ -795,12 +803,10 @@ void msm_gem_evict(struct drm_gem_object *obj)
> > update_inactive(msm_obj);
> > }
> >
> > -void msm_gem_vunmap(struct drm_gem_object *obj)
> > +static void msm_gem_vunmap_locked(struct drm_gem_object *obj)
> > {
> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> >
> > - GEM_WARN_ON(!msm_gem_is_locked(obj));
> > -
> > if (!msm_obj->vaddr || GEM_WARN_ON(!is_vunmapable(msm_obj)))
> > return;
> >
> > @@ -808,6 +814,12 @@ void msm_gem_vunmap(struct drm_gem_object *obj)
> > msm_obj->vaddr = NULL;
> > }
> >
> > +void msm_gem_vunmap(struct drm_gem_object *obj)
> > +{
> > + GEM_WARN_ON(!msm_gem_is_locked(obj));
> > + msm_gem_vunmap_locked(obj);
> > +}
> > +
> > void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu)
> > {
> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> > @@ -1021,12 +1033,11 @@ void msm_gem_free_object(struct drm_gem_object *obj)
> > list_del(_obj->mm_list);
> > mutex_unlock(>mm_lock);
> >
> > - msm_gem_lock(obj);
> > -
> > /* object should not be on active list: */
> > GEM_WARN_ON(is_active(msm_obj));
> >
> > - put_iova_spaces(obj, true);
> > + put_iova_spaces_locked(obj, true);
> > +
> >
> > if (obj->import_attach) {
> > GEM_WARN_ON(msm_obj->vaddr);
> > @@ -1036,19 +1047,13 @@ void msm_gem_free_object(struct drm_gem_object *obj)
> > */
> > kvfree(msm_obj->pages);
> >
> > - put_iova_vmas(obj);
> > -
> > - /* dma_buf_detach() grabs resv lock, so we need to unlock
> > -* prior to drm_prime_gem_destroy
> > -*/
> > - msm_gem_unlock(obj);
> > + put_iova_vmas_locked(obj);
> >
> > drm_prime_gem_destroy(obj, msm_obj->sgt);
> > } else {
> > - msm_gem_vunmap(obj);
> > + msm_gem_vunmap_locked(obj);
> > put_pages(obj);
> > - put_iova_vmas(obj);
> > - msm_gem_unlock(obj);
> > + put_iova_vmas_locked(obj);
> > }
> >
> > drm_gem_object_release(obj);
> > diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> > index c75d3b879a53..b2998a074de7 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.h
> > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > @@ -253,7 +253,6 @@ static inline bool is_purgeable(struct
> > msm_gem_object *msm_obj)
> >
> > static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
> > {
> > - GEM_WARN_ON(!msm_gem_is_locked(_obj->base));
> > return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
> > }
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > index 086dacf2f26a..afff3a79e925 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > @@ -175,6 +175,7 @@ static const int vmap_shrink_limit = 15;
> > static bool
> > vmap_shrink(struct msm_gem_object *msm_obj)
> > {
> > + GEM_WARN_ON(!msm_gem_is_locked(_obj->base));
> > if (!is_vunmapable(msm_obj))
> > return false;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 1/2] drm: Add DRM_GEM_FOPS
On Thu, Jun 09, 2022 at 10:42:11AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> The DEFINE_DRM_GEM_FOPS() helper is a bit limiting if a driver wants to
> provide additional file ops, like show_fdinfo().
>
> v2: Split out DRM_GEM_FOPS instead of making DEFINE_DRM_GEM_FOPS
> varardic
> v3: nits
>
> Signed-off-by: Rob Clark
> Acked-by: Thomas Zimmermann
We're at three drivers, maybe it'd be better if this is more standardized?
I feel like we're opening a bit a can of worms here where everyone just
has some good odl fashioned fun. It's at least much better documented than
the old property proliferation :-)
-Daniel
> ---
> include/drm/drm_gem.h | 26 ++
> 1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 9d7c61a122dc..87cffc9efa85 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -314,6 +314,23 @@ struct drm_gem_object {
> const struct drm_gem_object_funcs *funcs;
> };
>
> +/**
> + * DRM_GEM_FOPS - Default drm GEM file operations
> + *
> + * This macro provides a shorthand for setting the GEM file ops in the
> + * _operations structure. If all you need are the default ops, use
> + * DEFINE_DRM_GEM_FOPS instead.
> + */
> +#define DRM_GEM_FOPS \
> + .open = drm_open,\
> + .release= drm_release,\
> + .unlocked_ioctl = drm_ioctl,\
> + .compat_ioctl = drm_compat_ioctl,\
> + .poll = drm_poll,\
> + .read = drm_read,\
> + .llseek = noop_llseek,\
> + .mmap = drm_gem_mmap
> +
> /**
> * DEFINE_DRM_GEM_FOPS() - macro to generate file operations for GEM drivers
> * @name: name for the generated structure
> @@ -330,14 +347,7 @@ struct drm_gem_object {
> #define DEFINE_DRM_GEM_FOPS(name) \
> static const struct file_operations name = {\
> .owner = THIS_MODULE,\
> - .open = drm_open,\
> - .release= drm_release,\
> - .unlocked_ioctl = drm_ioctl,\
> - .compat_ioctl = drm_compat_ioctl,\
> - .poll = drm_poll,\
> - .read = drm_read,\
> - .llseek = noop_llseek,\
> - .mmap = drm_gem_mmap,\
> + DRM_GEM_FOPS,\
> }
>
> void drm_gem_object_release(struct drm_gem_object *obj);
> --
> 2.36.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 3/4] drm/bridge: Add devm_drm_bridge_add()
On Sat, May 21, 2022 at 11:17:51AM +0200, Maxime Ripard wrote: > Hi, > > On Tue, May 10, 2022 at 12:29:43PM -0700, Douglas Anderson wrote: > > This adds a devm managed version of drm_bridge_add(). Like other > > "devm" function listed in drm_bridge.h, this function takes an > > explicit "dev" to use for the lifetime management. A few notes: > > * In general we have a "struct device" for bridges that makes a good > > candidate for where the lifetime matches exactly what we want. > > * The "bridge->dev->dev" device appears to be the encoder > > device. That's not the right device to use for lifetime management. > > > > Suggested-by: Dmitry Baryshkov > > Signed-off-by: Douglas Anderson > > If we are to introduce more managed helpers, I think it'd be wiser to > introduce them as DRM-managed, and not device managed. > > Otherwise, you'll end up in a weird state when a device has been removed > but the DRM device is still around. Top-level post since I didn't see any good place to reply in the thread below: - devm is for device stuff, which drm_bridge is (it's not uapi visible in any way or fasion) - drmm is for uapi visible stuff (like drm_encoder) Yes the uapi-visible stuff can outlive the device-related pieces. The way to handle this is: - drm_dev_unplug() when the device disappears underneath you (or just a part, I guess the infra for that doesn't exist yet and maybe we should add it). - drm_dev_enter/exit wrapped around the device related parts. Iow, this patch here I think is the right direction, and gets my Reviewed-by: Daniel Vetter But also, it's definitely not a complete solution as the discussion in the thread here points out. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3] drm/probe-helper: Make 640x480 first if no EDID
On Thu, May 26, 2022 at 09:01:03AM -0700, Doug Anderson wrote: > Hi, > > On Thu, May 26, 2022 at 8:42 AM Daniel Vetter wrote: > > > > On Thu, 26 May 2022 at 03:28, Sean Paul wrote: > > > > > > On Wed, May 25, 2022 at 9:26 AM Daniel Vetter wrote: > > > > > > > > On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote: > > > > > Hi, > > > > > > > > > > On Fri, May 20, 2022 at 5:01 PM Doug Anderson > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann > > > > > > wrote: > > > > > > > > > > > > > > Hi Douglas, > > > > > > > > > > > > > > I understand that you're trying to tell userspace that the > > > > > > > modelist has > > > > > > > been made up, but it's not something that should be done via > > > > > > > fragile > > > > > > > heuristics IMHO. > > > > > > > > > > > > > > I looked at the Chromium source code that you linked, but I > > > > > > > cannot say > > > > > > > whether it's doing the correct thing. It all depends on what your > > > > > > > program needs. > > > > > > > > > > > > > > In that function, you could also search for > > > > > > > 'DRM_MODE_TYPE_USERDEF'. > > > > > > > It's the mode that the user specified on the kernel command line. > > > > > > > If > > > > > > > Chromium's automatic mode selection fails, you'd give your users > > > > > > > direct > > > > > > > control over it. > > > > > > > > > > > > That doesn't really work for Chrome OS. Certainly a kernel hacker > > > > > > could do this, but it's not something I could imagine us exposing to > > > > > > an average user of a Chromebook. > > > > > > > > > > > > > > > > > > > When there's no flagged mode or if > > > > > > > /sys/class/drm/card<...>/status contains "unconnected", you can > > > > > > > assume > > > > > > > that the modelist is artificial and try the modes in an > > > > > > > appropriate order. > > > > > > > > > > > > So "no flagged" means that nothing is marked as preferred, correct? > > > > > > > > > > > > ...so I guess what you're suggesting is that the order that the > > > > > > kernel > > > > > > is presenting the modes to userspace is not ABI. If there are no > > > > > > preferred modes then userspace shouldn't necessarily assume that the > > > > > > first mode returned is the best mode. Instead it should assume that > > > > > > if > > > > > > there is no preferred mode then the mode list is made up and it > > > > > > should > > > > > > make its own decisions about the best mode to start with. If this is > > > > > > the ABI from the kernel then plausibly I could convince people to > > > > > > change userspace to pick 640x480 first in this case. > > > > > > > > > > > > > If we really want the kernel to give additional guarantees, we > > > > > > > should > > > > > > > have a broader discussion about this topic IMHO. > > > > > > > > > > > > Sure. I've added Stéphane Marchesin to this thread in case he wants > > > > > > to > > > > > > chime in about anything. > > > > > > > > > > > > Overall, my take on the matter: > > > > > > > > > > > > * Mostly I got involved because, apparently, a DP compliance test > > > > > > was > > > > > > failing. The compliance test was upset that when it presented us > > > > > > with > > > > > > no EDID that we didn't default to 640x480. There was a push to make > > > > > > a > > > > > > fix for this in the Qualcomm specific driver but that didn't sit > > > > > > right > > > > > > with me. > > > > > >
Re: [Freedreno] [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, 30 May 2022 at 17:41, Rob Clark wrote:
>
> On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
> >
> > On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> > >
> > > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > Am 29.05.22 um 18:29 schrieb Rob Clark:
> > > > > From: Rob Clark
> > > > >
> > > > > If a GEM object is allocated, and then exported as a dma-buf fd which
> > > > > is
> > > > > mmap'd before or without the GEM buffer being directly mmap'd, the
> > > > > vma_node could be unitialized. This leads to a situation where the
> > > > > CPU
> > > > > mapping is not correctly torn down in drm_vma_node_unmap().
> > > >
> > > > Which drivers are affected by this problem?
> > > >
> > > > I checked several drivers and most appear to be initializing the offset
> > > > during object construction, such as GEM SHMEM. [1] TTM-based drivers
> > > > also seem unaffected. [2]
> > > >
> > > > From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> > > > They only seem to run drm_gem_create_mmap_offset() from their
> > > > ioctl-handling code.
> > > >
> > > > If so, I'd say it's preferable to fix these drivers and put a
> > > > drm_WARN_ONCE() into drm_gem_prime_mmap().
> > >
> > > That is good if fewer drivers are affected, however I disagree with
> > > your proposal. At least for freedreno userspace, a lot of bo's never
> > > get mmap'd (either directly of via dmabuf), so we should not be
> > > allocating a mmap offset unnecessarily.
> >
> > Does this actually matter in the grand scheme of things? We originally
> > allocated mmap offset only on demand because userspace only had 32bit
> > loff_t support and so simply couldn't mmap anything if the offset
> > ended up above 32bit (even if there was still va space available).
> >
> > But those days are long gone (about 10 years or so) and the allocation
> > overhead for an mmap offset is tiny. So I think unless you can
> > benchmark an impact allocating it at bo alloc seems like the simplest
> > design overall, and hence what we should be doing. And if the vma
> > offset allocation every gets too slow due to fragmentation we can lift
> > the hole tree from i915 into drm_mm and the job should be done. At
> > that point we could also allocate the offset unconditionally in the
> > gem_init function and be done with it.
> >
> > Iow I concur with Thomas here, unless there's hard data contrary
> > simplicity imo trumps here.
>
> 32b userspace is still alive and well, at least on arm chromebooks ;-)
There's lots of different 32b userspace. The old thing was about
userspace which didn't use mmap64, but only mmap. Which could only
mmap the lower 4GB of a file, and so if you ended up with mmap_offset
above 4G then you'd blow up.
But mmap64 is a thing since forever, and if you compile with the right
glibc switch (loff_t is the magic thing iirc) it all works even with
default mmap. So I really don't think you should have this problem
anymore (except when cros is doing something really, really silly).
-Daniel
>
> BR,
> -R
>
> > -Daniel
> >
> > >
> > > BR,
> > > -R
> > >
> > > > Best regards
> > > > Thomas
> > > >
> > > > [1]
> > > > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> > > > [2]
> > > > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
> > > >
> > > > >
> > > > > Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake
> > > > > offset")
> > > > > Signed-off-by: Rob Clark
> > > > > ---
> > > > > Note, it's possible the issue existed in some related form prior to
> > > > > the
> > > > > commit tagged with Fixes.
> > > > >
> > > > > drivers/gpu/drm/drm_prime.c | 5 +
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > > > index e3f09f18110c..849eea154dfc 100644
> > > > > --- a/drivers/gpu/drm/drm_prime.c
> > > > > +++ b/drivers/gpu/drm/drm_prime.c
> > > > > @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object
> > > > > *obj, struct vm_area_struct *vma)
> > > > > struct file *fil;
> > > > > int ret;
> > > > >
> > > > > + /* Ensure that the vma_node is initialized: */
> > > > > + ret = drm_gem_create_mmap_offset(obj);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > /* Add the fake offset */
> > > > > vma->vm_pgoff += drm_vma_node_start(>vma_node);
> > > > >
> > > >
> > > > --
> > > > Thomas Zimmermann
> > > > Graphics Driver Developer
> > > > SUSE Software Solutions Germany GmbH
> > > > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > > > (HRB 36809, AG Nürnberg)
> > > > Geschäftsführer: Ivo Totev
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
>
> On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 29.05.22 um 18:29 schrieb Rob Clark:
> > > From: Rob Clark
> > >
> > > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > > mmap'd before or without the GEM buffer being directly mmap'd, the
> > > vma_node could be unitialized. This leads to a situation where the CPU
> > > mapping is not correctly torn down in drm_vma_node_unmap().
> >
> > Which drivers are affected by this problem?
> >
> > I checked several drivers and most appear to be initializing the offset
> > during object construction, such as GEM SHMEM. [1] TTM-based drivers
> > also seem unaffected. [2]
> >
> > From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> > They only seem to run drm_gem_create_mmap_offset() from their
> > ioctl-handling code.
> >
> > If so, I'd say it's preferable to fix these drivers and put a
> > drm_WARN_ONCE() into drm_gem_prime_mmap().
>
> That is good if fewer drivers are affected, however I disagree with
> your proposal. At least for freedreno userspace, a lot of bo's never
> get mmap'd (either directly of via dmabuf), so we should not be
> allocating a mmap offset unnecessarily.
Does this actually matter in the grand scheme of things? We originally
allocated mmap offset only on demand because userspace only had 32bit
loff_t support and so simply couldn't mmap anything if the offset
ended up above 32bit (even if there was still va space available).
But those days are long gone (about 10 years or so) and the allocation
overhead for an mmap offset is tiny. So I think unless you can
benchmark an impact allocating it at bo alloc seems like the simplest
design overall, and hence what we should be doing. And if the vma
offset allocation every gets too slow due to fragmentation we can lift
the hole tree from i915 into drm_mm and the job should be done. At
that point we could also allocate the offset unconditionally in the
gem_init function and be done with it.
Iow I concur with Thomas here, unless there's hard data contrary
simplicity imo trumps here.
-Daniel
>
> BR,
> -R
>
> > Best regards
> > Thomas
> >
> > [1]
> > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> > [2]
> > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
> >
> > >
> > > Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake
> > > offset")
> > > Signed-off-by: Rob Clark
> > > ---
> > > Note, it's possible the issue existed in some related form prior to the
> > > commit tagged with Fixes.
> > >
> > > drivers/gpu/drm/drm_prime.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > index e3f09f18110c..849eea154dfc 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj,
> > > struct vm_area_struct *vma)
> > > struct file *fil;
> > > int ret;
> > >
> > > + /* Ensure that the vma_node is initialized: */
> > > + ret = drm_gem_create_mmap_offset(obj);
> > > + if (ret)
> > > + return ret;
> > > +
> > > /* Add the fake offset */
> > > vma->vm_pgoff += drm_vma_node_start(>vma_node);
> > >
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3] drm/probe-helper: Make 640x480 first if no EDID
On Thu, 26 May 2022 at 03:28, Sean Paul wrote: > > On Wed, May 25, 2022 at 9:26 AM Daniel Vetter wrote: > > > > On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Fri, May 20, 2022 at 5:01 PM Doug Anderson > > > wrote: > > > > > > > > Hi, > > > > > > > > On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann > > > > wrote: > > > > > > > > > > Hi Douglas, > > > > > > > > > > I understand that you're trying to tell userspace that the modelist > > > > > has > > > > > been made up, but it's not something that should be done via fragile > > > > > heuristics IMHO. > > > > > > > > > > I looked at the Chromium source code that you linked, but I cannot say > > > > > whether it's doing the correct thing. It all depends on what your > > > > > program needs. > > > > > > > > > > In that function, you could also search for 'DRM_MODE_TYPE_USERDEF'. > > > > > It's the mode that the user specified on the kernel command line. If > > > > > Chromium's automatic mode selection fails, you'd give your users > > > > > direct > > > > > control over it. > > > > > > > > That doesn't really work for Chrome OS. Certainly a kernel hacker > > > > could do this, but it's not something I could imagine us exposing to > > > > an average user of a Chromebook. > > > > > > > > > > > > > When there's no flagged mode or if > > > > > /sys/class/drm/card<...>/status contains "unconnected", you can assume > > > > > that the modelist is artificial and try the modes in an appropriate > > > > > order. > > > > > > > > So "no flagged" means that nothing is marked as preferred, correct? > > > > > > > > ...so I guess what you're suggesting is that the order that the kernel > > > > is presenting the modes to userspace is not ABI. If there are no > > > > preferred modes then userspace shouldn't necessarily assume that the > > > > first mode returned is the best mode. Instead it should assume that if > > > > there is no preferred mode then the mode list is made up and it should > > > > make its own decisions about the best mode to start with. If this is > > > > the ABI from the kernel then plausibly I could convince people to > > > > change userspace to pick 640x480 first in this case. > > > > > > > > > If we really want the kernel to give additional guarantees, we should > > > > > have a broader discussion about this topic IMHO. > > > > > > > > Sure. I've added Stéphane Marchesin to this thread in case he wants to > > > > chime in about anything. > > > > > > > > Overall, my take on the matter: > > > > > > > > * Mostly I got involved because, apparently, a DP compliance test was > > > > failing. The compliance test was upset that when it presented us with > > > > no EDID that we didn't default to 640x480. There was a push to make a > > > > fix for this in the Qualcomm specific driver but that didn't sit right > > > > with me. > > > > > > > > * On all devices I'm currently working with (laptops), the DP is a > > > > secondary display. If a user was trying to plug in a display with a > > > > bad EDID and the max mode (1024x768) didn't work, they could just use > > > > the primary display to choose a different resolution. It seems > > > > unlikely a user would truly be upset and would probably be happy they > > > > could get their broken display to work at all. Even if this is a > > > > primary display, I believe there are documented key combos to change > > > > the resolution of the primary display even if you can't see anything. > > > > > > > > * That all being said, defaulting to 640x480 when there's no EDID made > > > > sense to me, especially since it's actually defined in the DP spec. So > > > > I'm trying to do the right thing and solve this corner case. That > > > > being said, if it's truly controversial I can just drop it. > > > > > > > > > > > > So I guess my plan will be to give Stéphane a little while in case he > > > > wants to chime in. If not then I guess I'll try a Chrom
Re: [Freedreno] [PATCH v3] drm/probe-helper: Make 640x480 first if no EDID
On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote: > Hi, > > On Fri, May 20, 2022 at 5:01 PM Doug Anderson wrote: > > > > Hi, > > > > On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann > > wrote: > > > > > > Hi Douglas, > > > > > > I understand that you're trying to tell userspace that the modelist has > > > been made up, but it's not something that should be done via fragile > > > heuristics IMHO. > > > > > > I looked at the Chromium source code that you linked, but I cannot say > > > whether it's doing the correct thing. It all depends on what your > > > program needs. > > > > > > In that function, you could also search for 'DRM_MODE_TYPE_USERDEF'. > > > It's the mode that the user specified on the kernel command line. If > > > Chromium's automatic mode selection fails, you'd give your users direct > > > control over it. > > > > That doesn't really work for Chrome OS. Certainly a kernel hacker > > could do this, but it's not something I could imagine us exposing to > > an average user of a Chromebook. > > > > > > > When there's no flagged mode or if > > > /sys/class/drm/card<...>/status contains "unconnected", you can assume > > > that the modelist is artificial and try the modes in an appropriate order. > > > > So "no flagged" means that nothing is marked as preferred, correct? > > > > ...so I guess what you're suggesting is that the order that the kernel > > is presenting the modes to userspace is not ABI. If there are no > > preferred modes then userspace shouldn't necessarily assume that the > > first mode returned is the best mode. Instead it should assume that if > > there is no preferred mode then the mode list is made up and it should > > make its own decisions about the best mode to start with. If this is > > the ABI from the kernel then plausibly I could convince people to > > change userspace to pick 640x480 first in this case. > > > > > If we really want the kernel to give additional guarantees, we should > > > have a broader discussion about this topic IMHO. > > > > Sure. I've added Stéphane Marchesin to this thread in case he wants to > > chime in about anything. > > > > Overall, my take on the matter: > > > > * Mostly I got involved because, apparently, a DP compliance test was > > failing. The compliance test was upset that when it presented us with > > no EDID that we didn't default to 640x480. There was a push to make a > > fix for this in the Qualcomm specific driver but that didn't sit right > > with me. > > > > * On all devices I'm currently working with (laptops), the DP is a > > secondary display. If a user was trying to plug in a display with a > > bad EDID and the max mode (1024x768) didn't work, they could just use > > the primary display to choose a different resolution. It seems > > unlikely a user would truly be upset and would probably be happy they > > could get their broken display to work at all. Even if this is a > > primary display, I believe there are documented key combos to change > > the resolution of the primary display even if you can't see anything. > > > > * That all being said, defaulting to 640x480 when there's no EDID made > > sense to me, especially since it's actually defined in the DP spec. So > > I'm trying to do the right thing and solve this corner case. That > > being said, if it's truly controversial I can just drop it. > > > > > > So I guess my plan will be to give Stéphane a little while in case he > > wants to chime in. If not then I guess I'll try a Chrome patch... > > ...and if that doesn't work, I'll just drop it. > > OK, this userspace code seems to work: > > https://crrev.com/c/3662501 - ozone/drm: Try 640x480 before picking > the first mode if no EDID > > ...so we'll see how review of that goes. :-) Yeah it sucks a bit but I'm mildly afraid that if we muck around with the absolute fallback mode list in upstream we get whacked by a regression report :-/ There's the additional fun that on modern displays probably 720p (or maybe 720i) is a lot more likely to work than anything else really, so best we can do here maybe is to make it an uapi guarantee that if there's no preferred mode, then most likely the kernel invent random noise out of thin air, and userspace has to be careful and do its own magic heuristics. Or maybe we should add a flag for "this stuff is invented, buyer beware". I think clarifying that would be good. Changing defaults feels a bit too risky, we had some really hilarious regression reports in the past along the lines of the infamous xkcd. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [RFC v2] drm/msm: Add initial ci/ subdirectory
On Thu, May 12, 2022 at 03:28:16PM +0200, Tomeu Vizoso wrote: > On 5/11/22 7:46 PM, Rob Clark wrote: > > On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote: > > > > > > On Tue, 10 May 2022 at 22:26, Rob Clark wrote: > > > > > > > > On Tue, May 10, 2022 at 12:39 PM Jessica Zhang > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 5/10/2022 7:13 AM, Tomeu Vizoso wrote: > > > > > > And use it to store expectations about what the drm/msm driver is > > > > > > supposed to pass in the IGT test suite. > > > > > > > > > > > > Also include a configuration file that points to the out-of-tree CI > > > > > > scripts. > > > > > > > > > > > > By storing the test expectations along the code we can make sure > > > > > > both > > > > > > stay in sync with each other, and so we can know when a code change > > > > > > breaks those expectations. > > > > > > > > > > > > This will allow all contributors to drm/msm to reuse the > > > > > > infrastructure > > > > > > already in gitlab.freedesktop.org to test the driver on several > > > > > > generations of the hardware. > > > > > > > > > > > > v2: > > > > > > - Fix names of result expectation files to match SoC > > > > > > - Don't execute tests that are going to skip on all boards > > > > > > > > > > > > Signed-off-by: Tomeu Vizoso > > > > > > --- > > > > > >Documentation/gpu/msm_automated_testing.rst | 70 + > > > > > >drivers/gpu/drm/msm/ci/gitlab-ci.yml | 11 ++ > > > > > >drivers/gpu/drm/msm/ci/msm.testlist | 148 > > > > > > ++ > > > > > >.../gpu/drm/msm/ci/msm_apq8016_results.txt| 140 > > > > > > + > > > > > >.../gpu/drm/msm/ci/msm_apq8096_results.txt| 140 > > > > > > + > > > > > >drivers/gpu/drm/msm/ci/msm_sc7180_results.txt | 141 > > > > > > + > > > > > >drivers/gpu/drm/msm/ci/msm_sdm845_results.txt | 141 > > > > > > + > > > > > >7 files changed, 791 insertions(+) > > > > > >create mode 100644 Documentation/gpu/msm_automated_testing.rst > > > > > >create mode 100644 drivers/gpu/drm/msm/ci/gitlab-ci.yml > > > > > >create mode 100644 drivers/gpu/drm/msm/ci/msm.testlist > > > > > >create mode 100644 drivers/gpu/drm/msm/ci/msm_apq8016_results.txt > > > > > >create mode 100644 drivers/gpu/drm/msm/ci/msm_apq8096_results.txt > > > > > >create mode 100644 drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > >create mode 100644 drivers/gpu/drm/msm/ci/msm_sdm845_results.txt > > > > > > > > > > [snip] > > > > > > > > diff --git a/drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > b/drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > new file mode 100644 > > > > > > index ..01f7b4b399b5 > > > > > > --- /dev/null > > > > > > +++ b/drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > @@ -0,0 +1,141 @@ > > > > > > +igt@core_auth@getclient-simple,dmesg-warn > > > > > > +igt@core_auth@getclient-master-drop,pass > > > > > > +igt@core_auth@basic-auth,pass > > > > > > +igt@core_auth@many-magics,pass > > > > > > +igt@core_getclient,pass > > > > > > +igt@core_getstats,pass > > > > > > +igt@core_getversion,pass > > > > > > +igt@core_setmaster_vs_auth,pass > > > > > > +igt@drm_read@invalid-buffer,pass > > > > > > +igt@drm_read@fault-buffer,pass > > > > > > +igt@drm_read@empty-block,pass > > > > > > +igt@drm_read@empty-nonblock,pass > > > > > > +igt@drm_read@short-buffer-block,pass > > > > > > +igt@drm_read@short-buffer-nonblock,pass > > > > > > +igt@drm_read@short-buffer-wakeup,pass > > > > > > +igt@kms_addfb_basic@unused-handle,pass > >
Re: [Freedreno] [RFC v2] drm/msm: Add initial ci/ subdirectory
On Wed, 11 May 2022 at 22:32, Rob Clark wrote: > > On Wed, May 11, 2022 at 12:14 PM Daniel Vetter wrote: > > > > On Wed, 11 May 2022 at 19:46, Rob Clark wrote: > > > > > > On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote: > > > > > > > > On Tue, 10 May 2022 at 22:26, Rob Clark wrote: > > > > > > > > > > On Tue, May 10, 2022 at 12:39 PM Jessica Zhang > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 5/10/2022 7:13 AM, Tomeu Vizoso wrote: > > > > > > > And use it to store expectations about what the drm/msm driver is > > > > > > > supposed to pass in the IGT test suite. > > > > > > > > > > > > > > Also include a configuration file that points to the out-of-tree > > > > > > > CI > > > > > > > scripts. > > > > > > > > > > > > > > By storing the test expectations along the code we can make sure > > > > > > > both > > > > > > > stay in sync with each other, and so we can know when a code > > > > > > > change > > > > > > > breaks those expectations. > > > > > > > > > > > > > > This will allow all contributors to drm/msm to reuse the > > > > > > > infrastructure > > > > > > > already in gitlab.freedesktop.org to test the driver on several > > > > > > > generations of the hardware. > > > > > > > > > > > > > > v2: > > > > > > >- Fix names of result expectation files to match SoC > > > > > > >- Don't execute tests that are going to skip on all boards > > > > > > > > > > > > > > Signed-off-by: Tomeu Vizoso > > > > > > > --- > > > > > > > Documentation/gpu/msm_automated_testing.rst | 70 + > > > > > > > drivers/gpu/drm/msm/ci/gitlab-ci.yml | 11 ++ > > > > > > > drivers/gpu/drm/msm/ci/msm.testlist | 148 > > > > > > > ++ > > > > > > > .../gpu/drm/msm/ci/msm_apq8016_results.txt| 140 > > > > > > > + > > > > > > > .../gpu/drm/msm/ci/msm_apq8096_results.txt| 140 > > > > > > > + > > > > > > > drivers/gpu/drm/msm/ci/msm_sc7180_results.txt | 141 > > > > > > > + > > > > > > > drivers/gpu/drm/msm/ci/msm_sdm845_results.txt | 141 > > > > > > > + > > > > > > > 7 files changed, 791 insertions(+) > > > > > > > create mode 100644 Documentation/gpu/msm_automated_testing.rst > > > > > > > create mode 100644 drivers/gpu/drm/msm/ci/gitlab-ci.yml > > > > > > > create mode 100644 drivers/gpu/drm/msm/ci/msm.testlist > > > > > > > create mode 100644 > > > > > > > drivers/gpu/drm/msm/ci/msm_apq8016_results.txt > > > > > > > create mode 100644 > > > > > > > drivers/gpu/drm/msm/ci/msm_apq8096_results.txt > > > > > > > create mode 100644 drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > > create mode 100644 drivers/gpu/drm/msm/ci/msm_sdm845_results.txt > > > > > > > > > > > > > [snip] > > > > > > > > > > diff --git a/drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > > b/drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > > new file mode 100644 > > > > > > > index ..01f7b4b399b5 > > > > > > > --- /dev/null > > > > > > > +++ b/drivers/gpu/drm/msm/ci/msm_sc7180_results.txt > > > > > > > @@ -0,0 +1,141 @@ > > > > > > > +igt@core_auth@getclient-simple,dmesg-warn > > > > > > > +igt@core_auth@getclient-master-drop,pass > > > > > > > +igt@core_auth@basic-auth,pass > > > > > > > +igt@core_auth@many-magics,pass > > > > > > > +igt@core_getclient,pass > > > > > > > +igt@core_getstats,pass > > > > > > > +igt@core_getversion,pass > > > > > > > +igt@core_
Re: [Freedreno] Adding CI results to the kernel tree was Re: [RFC v2] drm/msm: Add initial ci/ subdirectory
/ or tools/testing/ appropriately. In general I think any mess this causes is a pretty good indicator that something is amiss, like if this causes messy history due to tests flipping too much and causing issues then that also indicates an issue with the kernel or testcase quality itself. And it might be good to shine more light on that stuff. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [RFC v2] drm/msm: Add initial ci/ subdirectory
0..3df1e5ef6d80 > > > --- /dev/null > > > +++ b/drivers/gpu/drm
Re: [Freedreno] Adding CI results to the kernel tree was Re: [RFC v2] drm/msm: Add initial ci/ subdirectory
d > in the kernel tree (such as expectations), and then link out to an > external drm-ci tree[1] which has all the necessary scripts and yml > for building and running tests, to avoid having to put a whole lot > more in the kernel tree. (We should be specifying exact commit-sha for > that tree, IMO, as it controls the version of i-g-t which gets used, > and we need to be able to update expectations in sync with an i-g-t > uprev, for example when new tests are added or if a test fix caused a > fail->pass transition.) Yeah I think longer-term we should carry a lot more in upstream, at least anything that's shared across drivers wrt the ci integration (or build testing and running tests which are hw agnostic). Maybe even igt, not sure (otoh xfs-tests isn't moving into the kernel either, and there's lots more like that). Personally I think long-term the only thing outside should be other repos with tests or stuff you need to run them, and not really the glue to make it all work in ci. But that's maybe a bit too much wishful thinking if CI systems stay largely subsystem specific (which they currently are in many ways, with some overlap). But maybe there is enough random pieces to share here for a lot more in-tree to make sense, and imo the fewer extra steps and indirection CI testing and test updating has, the better. But like Rob says, eventually there's a limit and when you put the entire GL/vulkan stack + it's conformance testsuite (which is maintained by khronos somewhere completely different than both kernel.org and freedesktop.org) then it's definitely too much and wont work. And eventually we do want to run these things too (e.g. intel-gfx-ci does run mesa + piglit on every run). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On Thu, Mar 17, 2022 at 05:44:57PM +0100, Christian König wrote: > Am 17.03.22 um 17:18 schrieb Rob Clark: > > On Thu, Mar 17, 2022 at 9:04 AM Christian König > > wrote: > > > Am 17.03.22 um 16:10 schrieb Rob Clark: > > > > [SNIP] > > > > userspace frozen != kthread frozen .. that is what this patch is > > > > trying to address, so we aren't racing between shutting down the hw > > > > and the scheduler shoveling more jobs at us. > > > Well exactly that's the problem. The scheduler is supposed to shoveling > > > more jobs at us until it is empty. > > > > > > Thinking more about it we will then keep some dma_fence instance > > > unsignaled and that is and extremely bad idea since it can lead to > > > deadlocks during suspend. > > Hmm, perhaps that is true if you need to migrate things out of vram? > > It is at least not a problem when vram is not involved. > > No, it's much wider than that. > > See what can happen is that the memory management shrinkers want to wait for > a dma_fence during suspend. > > And if you stop the scheduler they will just wait forever. > > What you need to do instead is to drain the scheduler, e.g. call > drm_sched_entity_flush() with a proper timeout for each entity you have > created. Yeah I think properly flushing the scheduler and stopping it and cutting all drivers over to that sounds like the right approach. Generally suspend shouldn't be such a critical path that this will hurt us, all the other io queues get flushed too afaik. Resume is the thing that needs to go real fast. So a patch set to move all drivers that open code the kthread_park to the right scheduler function sounds like the right idea here to me. -Daniel > > Regards, > Christian. > > > > > > So this patch here is an absolute clear NAK from my side. If amdgpu is > > > doing something similar that is a severe bug and needs to be addressed > > > somehow. > > I think amdgpu's use of kthread_park is not related to suspend, but > > didn't look too closely. > > > > And perhaps the solution for this problem is more complex in the case > > of amdgpu, I'm not super familiar with the constraints there. But I > > think it is a fine solution for integrated GPUs. > > > > BR, > > -R > > > > > Regards, > > > Christian. > > > > > > > BR, > > > > -R > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector
On Fri, Mar 11, 2022 at 10:05:53AM +0200, Laurent Pinchart wrote:
> On Fri, Mar 11, 2022 at 10:46:13AM +0300, Dmitry Baryshkov wrote:
> > On Fri, 11 Mar 2022 at 04:50, Abhinav Kumar
> > wrote:
> > >
> > > For some vendor driver implementations, display hardware can
> > > be shared between the encoder used for writeback and the physical
> > > display.
> > >
> > > In addition resources such as clocks and interrupts can
> > > also be shared between writeback and the real encoder.
> > >
> > > To accommodate such vendor drivers and hardware, allow
> > > real encoder to be passed for drm_writeback_connector.
> > >
> > > Co-developed-by: Kandpal Suraj
> > > Signed-off-by: Abhinav Kumar
> > > ---
> > > drivers/gpu/drm/drm_writeback.c | 8
> > > include/drm/drm_writeback.h | 13 +++--
> > > 2 files changed, 15 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_writeback.c
> > > b/drivers/gpu/drm/drm_writeback.c
> > > index dccf4504..4dad687 100644
> > > --- a/drivers/gpu/drm/drm_writeback.c
> > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > @@ -189,8 +189,8 @@ int drm_writeback_connector_init(struct drm_device
> > > *dev,
> > > if (IS_ERR(blob))
> > > return PTR_ERR(blob);
> > >
> > > - drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
> > > - ret = drm_encoder_init(dev, _connector->encoder,
> > > + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> > > + ret = drm_encoder_init(dev, wb_connector->encoder,
> > >_writeback_encoder_funcs,
> > >DRM_MODE_ENCODER_VIRTUAL, NULL);
> >
> > If the encoder is provided by a separate driver, it might use a
> > different set of encoder funcs.
>
> More than that, if the encoder is provided externally but doesn't have
> custom operations, I don't really see the point of having an external
> encoder in the first place.
>
> Has this series been tested with a driver that needs to provide an
> encoder, to make sure it fits the purpose ?
Also, can we not force all drivers to do this setup that don't need it? We
have a ton of kms drivers, forcing unnecessary busiwork on drivers is
really not good.
-Daniel
>
> > I'd suggest checking whether the wb_connector->encoder is NULL here.
> > If it is, allocate one using drmm_kzalloc and init it.
> > If it is not NULL, assume that it has been initialized already, so
> > skip the drm_encoder_init() and just call the drm_encoder_helper_add()
> >
> > > if (ret)
> > > @@ -204,7 +204,7 @@ int drm_writeback_connector_init(struct drm_device
> > > *dev,
> > > goto connector_fail;
> > >
> > > ret = drm_connector_attach_encoder(connector,
> > > - _connector->encoder);
> > > + wb_connector->encoder);
> > > if (ret)
> > > goto attach_fail;
> > >
> > > @@ -233,7 +233,7 @@ int drm_writeback_connector_init(struct drm_device
> > > *dev,
> > > attach_fail:
> > > drm_connector_cleanup(connector);
> > > connector_fail:
> > > - drm_encoder_cleanup(_connector->encoder);
> > > + drm_encoder_cleanup(wb_connector->encoder);
> > > fail:
> > > drm_property_blob_put(blob);
> > > return ret;
> > > diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> > > index 9697d27..0ba266e 100644
> > > --- a/include/drm/drm_writeback.h
> > > +++ b/include/drm/drm_writeback.h
> > > @@ -25,13 +25,22 @@ struct drm_writeback_connector {
> > > struct drm_connector base;
> > >
> > > /**
> > > -* @encoder: Internal encoder used by the connector to fulfill
> > > +* @encoder: handle to drm_encoder used by the connector to
> > > fulfill
> > > * the DRM framework requirements. The users of the
> > > * @drm_writeback_connector control the behaviour of the @encoder
> > > * by passing the @enc_funcs parameter to
> > > drm_writeback_connector_init()
> > > * function.
> > > +*
> > > +* For some vendor drivers, the hardware resources are shared
> > > between
> > > +* writeback encoder and rest of the display pipeline.
> > > +* To accommodate such cases, encoder is a handle to the real
> > > encoder
> > > +* hardware.
> > > +*
> > > +* For current existing writeback users, this shall continue to
> > > be the
> > > +* embedded encoder for the writeback connector.
> > > +*
> > > */
> > > - struct drm_encoder encoder;
> > > + struct drm_encoder *encoder;
> > >
> > > /**
> > > * @pixel_formats_blob_ptr:
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH 2/3] drm/msm/gpu: Park scheduler threads for system suspend
On Thu, Mar 10, 2022 at 03:46:05PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> In the system suspend path, we don't want to be racing with the
> scheduler kthreads pushing additional queued up jobs to the hw
> queue (ringbuffer). So park them first. While we are at it,
> move the wait for active jobs to complete into the new system-
> suspend path.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 68 --
> 1 file changed, 64 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 8859834b51b8..0440a98988fc 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -619,22 +619,82 @@ static int active_submits(struct msm_gpu *gpu)
> static int adreno_runtime_suspend(struct device *dev)
> {
> struct msm_gpu *gpu = dev_to_gpu(dev);
> - int remaining;
> +
> + /*
> + * We should be holding a runpm ref, which will prevent
> + * runtime suspend. In the system suspend path, we've
> + * already waited for active jobs to complete.
> + */
> + WARN_ON_ONCE(gpu->active_submits);
> +
> + return gpu->funcs->pm_suspend(gpu);
> +}
> +
> +static void suspend_scheduler(struct msm_gpu *gpu)
> +{
> + int i;
> +
> + /*
> + * Shut down the scheduler before we force suspend, so that
> + * suspend isn't racing with scheduler kthread feeding us
> + * more work.
> + *
> + * Note, we just want to park the thread, and let any jobs
> + * that are already on the hw queue complete normally, as
> + * opposed to the drm_sched_stop() path used for handling
> + * faulting/timed-out jobs. We can't really cancel any jobs
> + * already on the hw queue without racing with the GPU.
> + */
> + for (i = 0; i < gpu->nr_rings; i++) {
> + struct drm_gpu_scheduler *sched = >rb[i]->sched;
> + kthread_park(sched->thread);
Shouldn't we have some proper interfaces for this? Also I'm kinda
wondering how other drivers do this, feels like we should have a standard
way.
Finally not flushing out all in-flight requests sounds a bit like a bad
idea for system suspend/resume since that's also the hibernation path, and
that would mean your shrinker/page reclaim stops working. At least in full
generality. Which ain't good for hibernation.
Adding Christian and Andrey.
-Daniel
> + }
> +}
> +
> +static void resume_scheduler(struct msm_gpu *gpu)
> +{
> + int i;
> +
> + for (i = 0; i < gpu->nr_rings; i++) {
> + struct drm_gpu_scheduler *sched = >rb[i]->sched;
> + kthread_unpark(sched->thread);
> + }
> +}
> +
> +static int adreno_system_suspend(struct device *dev)
> +{
> + struct msm_gpu *gpu = dev_to_gpu(dev);
> + int remaining, ret;
> +
> + suspend_scheduler(gpu);
>
> remaining = wait_event_timeout(gpu->retire_event,
> active_submits(gpu) == 0,
> msecs_to_jiffies(1000));
> if (remaining == 0) {
> dev_err(dev, "Timeout waiting for GPU to suspend\n");
> - return -EBUSY;
> + ret = -EBUSY;
> + goto out;
> }
>
> - return gpu->funcs->pm_suspend(gpu);
> + ret = pm_runtime_force_suspend(dev);
> +out:
> + if (ret)
> + resume_scheduler(gpu);
> +
> + return ret;
> }
> +
> +static int adreno_system_resume(struct device *dev)
> +{
> + resume_scheduler(dev_to_gpu(dev));
> + return pm_runtime_force_resume(dev);
> +}
> +
> #endif
>
> static const struct dev_pm_ops adreno_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> pm_runtime_force_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(adreno_system_suspend, adreno_system_resume)
> SET_RUNTIME_PM_OPS(adreno_runtime_suspend, adreno_runtime_resume, NULL)
> };
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v6 02/35] component: Introduce the aggregate bus_type
On Mon, Jan 31, 2022 at 05:34:26PM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote: > > On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > > > The component framework only provides 'bind' and 'unbind' callbacks to > > > > tell the host driver that it is time to assemble the aggregate driver > > > > now that all the components have probed. The component framework doesn't > > > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > > > mentions this in the code. This lack of support leads to some pretty > > > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > > > drivers that host the aggregate device, and it fully breaks down when > > > > faced with ordering shutdown between the various components, the > > > > aggregate driver, and the host driver that registers the whole thing. > > > > > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > > > using 'prepare' and 'complete' to call the drm helpers > > > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > > > respectively, so that it can move the aggregate driver suspend/resume > > > > callbacks to be before and after the components that make up the drm > > > > device call any suspend/resume hooks they have. This only works as long > > > > as the component devices don't do anything in their own 'prepare' and > > > > 'complete' callbacks. If they did, then the ordering would be incorrect > > > > and we would be doing something in the component drivers before the > > > > aggregate driver could do anything. Yuck! > > > > > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > > > across a problem where we're trying to shutdown the drm device via > > > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > > > chain have already been shutdown. This time, the component devices > > > > aren't the problem (although they could be if they did anything in their > > > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > > > chain that has already been shutdown before the driver hosting the > > > > aggregate device runs shutdown. The ordering of driver probe is like > > > > this: > > > > > > > > 1. msm_pdev_probe() (host driver) > > > > 2. DSI bridge > > > > 3. aggregate bind > > > > > > > > When it comes to shutdown we have this order: > > > > > > > > 1. DSI bridge > > > > 2. msm_pdev_shutdown() (host driver) > > > > > > > > and so the bridge is already off, but we want to communicate to it to > > > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > > > Unfortunately, this time we can't split shutdown into multiple phases > > > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > > > > > Let's make the component_master_ops into an actual device driver that > > > > has > > > > probe/remove/shutdown functions. The driver will only be bound to the > > > > aggregate device once all component drivers have called component_add() > > > > to indicate they're ready to assemble the aggregate driver. This allows > > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > > aggregate driver so that it runs the hooks in the correct order. > > > > > > I know I asked before, but I can not remember the answer. > > > > > > This really looks like it is turning into the aux bus code. Why can't > > > you just use that instead here for this type of thing? You are creating > > > another bus and drivers for that bus that are "fake" which is great, but > > > that's what the aux bus code was supposed to help out with, so we > > > wouldn't have to write more of these. > > > > > > So, if this really is different, can you document it here so I remember > > > next time you resend this patch series? > > > > aux takes a device and splits it into a lot of sub-devices, each with > > their own driver. > > > > This takes a pile of devices, and turns it into a single logical > > device with a single driver. > > > > So aux
Re: [Freedreno] [PATCH v6 02/35] component: Introduce the aggregate bus_type
On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman wrote: > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > The component framework only provides 'bind' and 'unbind' callbacks to > > tell the host driver that it is time to assemble the aggregate driver > > now that all the components have probed. The component framework doesn't > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > mentions this in the code. This lack of support leads to some pretty > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > drivers that host the aggregate device, and it fully breaks down when > > faced with ordering shutdown between the various components, the > > aggregate driver, and the host driver that registers the whole thing. > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > using 'prepare' and 'complete' to call the drm helpers > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > respectively, so that it can move the aggregate driver suspend/resume > > callbacks to be before and after the components that make up the drm > > device call any suspend/resume hooks they have. This only works as long > > as the component devices don't do anything in their own 'prepare' and > > 'complete' callbacks. If they did, then the ordering would be incorrect > > and we would be doing something in the component drivers before the > > aggregate driver could do anything. Yuck! > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > across a problem where we're trying to shutdown the drm device via > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > chain have already been shutdown. This time, the component devices > > aren't the problem (although they could be if they did anything in their > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > chain that has already been shutdown before the driver hosting the > > aggregate device runs shutdown. The ordering of driver probe is like > > this: > > > > 1. msm_pdev_probe() (host driver) > > 2. DSI bridge > > 3. aggregate bind > > > > When it comes to shutdown we have this order: > > > > 1. DSI bridge > > 2. msm_pdev_shutdown() (host driver) > > > > and so the bridge is already off, but we want to communicate to it to > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > Unfortunately, this time we can't split shutdown into multiple phases > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > Let's make the component_master_ops into an actual device driver that has > > probe/remove/shutdown functions. The driver will only be bound to the > > aggregate device once all component drivers have called component_add() > > to indicate they're ready to assemble the aggregate driver. This allows > > us to attach shutdown logic (and in the future runtime PM logic) to the > > aggregate driver so that it runs the hooks in the correct order. > > I know I asked before, but I can not remember the answer. > > This really looks like it is turning into the aux bus code. Why can't > you just use that instead here for this type of thing? You are creating > another bus and drivers for that bus that are "fake" which is great, but > that's what the aux bus code was supposed to help out with, so we > wouldn't have to write more of these. > > So, if this really is different, can you document it here so I remember > next time you resend this patch series? aux takes a device and splits it into a lot of sub-devices, each with their own driver. This takes a pile of devices, and turns it into a single logical device with a single driver. So aux is 1:N, component is N:1. And yes you asked this already, I typed this up already :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v4 00/34] component: Make into an aggregate bus
c| 20 +- > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 25 +- > drivers/gpu/drm/mcde/mcde_drv.c | 23 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 20 +- > drivers/gpu/drm/meson/meson_drv.c | 21 +- > drivers/gpu/drm/msm/msm_drv.c | 46 +- > drivers/gpu/drm/omapdrm/dss/dss.c | 20 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 20 +- > drivers/gpu/drm/sti/sti_drv.c | 20 +- > drivers/gpu/drm/sun4i/sun4i_drv.c | 26 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 28 +- > drivers/gpu/drm/vc4/vc4_drv.c | 20 +- > drivers/iommu/mtk_iommu.c | 14 +- > drivers/iommu/mtk_iommu.h | 6 +- > drivers/iommu/mtk_iommu_v1.c | 14 +- > drivers/misc/mei/hdcp/mei_hdcp.c | 22 +- > drivers/misc/mei/pxp/mei_pxp.c| 22 +- > drivers/power/supply/ab8500_charger.c | 22 +- > drivers/video/fbdev/omap2/omapfb/dss/dss.c| 20 +- > include/drm/drm_of.h | 10 +- > include/linux/component.h | 92 ++- > sound/hda/hdac_component.c| 21 +- > sound/soc/codecs/wcd938x.c| 20 +- > 33 files changed, 772 insertions(+), 490 deletions(-) > > Cc: Arnd Bergmann > Cc: Benjamin Gaignard > Cc: Chen Feng > Cc: Chen-Yu Tsai > Cc: Christian Gmeiner > Cc: Chun-Kuang Hu > Cc: Daniel Vetter > Cc: Emma Anholt > Cc: Greg Kroah-Hartman > Cc: "Heiko Stübner" > Cc: Inki Dae > Cc: James Qian Wang (Arm Technology China) > Cc: Jaroslav Kysela > Cc: Joerg Roedel > Cc: John Stultz > Cc: Joonyoung Shim > Cc: Jyri Sarha > Cc: Kai Vehmanen > Cc: Kyungmin Park > Cc: Laurent Pinchart > Cc: > Cc: > Cc: > Cc: Linus Walleij > Cc: Liviu Dudau > Cc: Lucas Stach > Cc: Mark Brown > Cc: Maxime Ripard > Cc: Neil Armstrong > Cc: Paul Cercueil > Cc: Philipp Zabel > Cc: "Rafael J. Wysocki" > Cc: Rob Clark > Cc: Russell King > Cc: Russell King > Cc: Russell King > Cc: Sandy Huang > Cc: Saravana Kannan > Cc: Sebastian Reichel > Cc: Seung-Woo Kim > Cc: Takashi Iwai > Cc: Tian Tao > Cc: Tomas Winkler > Cc: Tomi Valkeinen > Cc: Will Deacon > Cc: Xinliang Liu > Cc: Xinwei Kong > Cc: Yong Wu > Cc: Vitaly Lubart > Cc: Daniele Ceraolo Spurio > Cc: Rodrigo Vivi > Cc: Kai Vehmanen > > base-commit: 136057256686de39cc3a07c2e39ef6bc43003ff6 > -- > https://chromeos.dev > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
On Thu, Oct 07, 2021 at 04:42:48PM -0400, Stephen Boyd wrote: > Quoting Greg Kroah-Hartman (2021-10-06 22:37:40) > > On Wed, Oct 06, 2021 at 12:37:47PM -0700, Stephen Boyd wrote: > > > > > > Let's make the component driver into an actual device driver that has > > > probe/remove/shutdown functions. The driver will only be bound to the > > > aggregate device once all component drivers have called component_add() > > > to indicate they're ready to assemble the aggregate driver. This allows > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > aggregate driver so that it runs the hooks in the correct order. > > > > Why are you creating a new bus type and not using the auxiliary bus > > instead? > > > > You have seen Documentation/driver-api/auxiliary_bus.rst, right? > > > > Nope, but I read it now. Thanks for the pointer. > > My read of it is that the auxiliary bus is a way to slice up a single IP > block into multiple devices and then have drivers attach to those > different "pieces" of the IP. It avoids polluting the platform bus with > devices that don't belong on the platform bus because they are sub > components of a larger IP block that sits on the platform bus. > > The aggregate bus is solving the reverse problem. It is rounding up a > collection of IP blocks that live on some bus (platform, i2c, spi, > whatever) and presenting them as a single aggregate device (sound card, > display card, whatever) whenever all the component devices call > component_add(). For example, we don't want to do operations on the > entire display pipeline until all the devices that make up the display > are probed and drivers are attached. I suppose the aggregate_device in > this patch series has a 1:1 relationship with the drm class_type that > makes up /sys/class/drm/cardN but there's also a couple sound users and > a power_supply user so I don't know the equivalent there. > > Long term, maybe all of this component code could be placed directly > into the driver core? That's probably even more invasive of a change but > I imagine we could make device links with component_add() as we're > already doing with these patches and then have driver core call some > class function pointer when all the links are probed. That would > handle the 'bind/probe' callback for the aggregate device but it won't > handle the component_bind_all() path where we call bind_component() for > each component device that makes up the aggregate device. Maybe we can > add even more devices for the components and then call probe there too. > > Sorry that's a long-winded non-answer. I don't think they're solving the > same problem so using the same bus type looks wrong. We'd have to take > two different paths depending on what type of device it is (aggregate > vs. auxiliary) so there's not much of anything that is shared code-wise. Yeah component is the reverse of auxiliary, and right now a lot of subsystems have their own hand-rolled version of this. I do hope that component.c does become more of a standard (that's why it's in drivers/base/), but I guess that's a bit tricky if the device model maintainer hasn't seen it yet ... Hopefully putting more proper device model concepts into it can fix this problem :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 01/34] component: Introduce struct aggregate_device
On Wed, Oct 06, 2021 at 12:37:46PM -0700, Stephen Boyd wrote:
> Replace 'struct master' with 'struct aggregate_device' and then rename
> 'master' to 'adev' everywhere in the code. While we're here, put a
> struct device inside the aggregate device so that we can register it
> with a bus_type in the next patch.
>
> The diff is large but that's because this is mostly a rename, where
> sometimes 'master' is replaced with 'adev' and other times it is
> replaced with 'parent' to indicate that the struct device that was being
> used is actually the parent of the aggregate device and driver.
>
> Cc: Daniel Vetter
> Cc: "Rafael J. Wysocki"
> Cc: Rob Clark
> Cc: Russell King
> Cc: Saravana Kannan
> Signed-off-by: Stephen Boyd
This adds device model stuff, please cc Greg KH and ask him to review
this. Maybe also an ack from Rafael would be good whether this makes
sense.
Once we have that I think we can then go acks/review for all the
driver changes and get this sorted. Thanks a lot for pushing this forward.
-Daniel
> ---
> drivers/base/component.c | 250 --
> include/linux/component.h | 2 +-
> 2 files changed, 134 insertions(+), 118 deletions(-)
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index 5e79299f6c3f..0a41bbe14981 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -9,6 +9,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -58,18 +59,21 @@ struct component_match {
> struct component_match_array *compare;
> };
>
> -struct master {
> +struct aggregate_device {
> struct list_head node;
> bool bound;
>
> const struct component_master_ops *ops;
> struct device *parent;
> + struct device dev;
> struct component_match *match;
> +
> + int id;
> };
>
> struct component {
> struct list_head node;
> - struct master *master;
> + struct aggregate_device *adev;
> bool bound;
>
> const struct component_ops *ops;
> @@ -79,7 +83,9 @@ struct component {
>
> static DEFINE_MUTEX(component_mutex);
> static LIST_HEAD(component_list);
> -static LIST_HEAD(masters);
> +static LIST_HEAD(aggregate_devices);
> +
> +static DEFINE_IDA(aggregate_ida);
>
> #ifdef CONFIG_DEBUG_FS
>
> @@ -87,12 +93,12 @@ static struct dentry *component_debugfs_dir;
>
> static int component_devices_show(struct seq_file *s, void *data)
> {
> - struct master *m = s->private;
> + struct aggregate_device *m = s->private;
> struct component_match *match = m->match;
> size_t i;
>
> mutex_lock(_mutex);
> - seq_printf(s, "%-40s %20s\n", "master name", "status");
> + seq_printf(s, "%-40s %20s\n", "aggregate_device name", "status");
> seq_puts(s,
> "-\n");
> seq_printf(s, "%-40s %20s\n\n",
> dev_name(m->parent), m->bound ? "bound" : "not bound");
> @@ -122,46 +128,46 @@ static int __init component_debug_init(void)
>
> core_initcall(component_debug_init);
>
> -static void component_master_debugfs_add(struct master *m)
> +static void component_master_debugfs_add(struct aggregate_device *m)
> {
> debugfs_create_file(dev_name(m->parent), 0444, component_debugfs_dir, m,
> _devices_fops);
> }
>
> -static void component_master_debugfs_del(struct master *m)
> +static void component_master_debugfs_del(struct aggregate_device *m)
> {
> debugfs_remove(debugfs_lookup(dev_name(m->parent),
> component_debugfs_dir));
> }
>
> #else
>
> -static void component_master_debugfs_add(struct master *m)
> +static void component_master_debugfs_add(struct aggregate_device *m)
> { }
>
> -static void component_master_debugfs_del(struct master *m)
> +static void component_master_debugfs_del(struct aggregate_device *m)
> { }
>
> #endif
>
> -static struct master *__master_find(struct device *parent,
> +static struct aggregate_device *__aggregate_find(struct device *parent,
> const struct component_master_ops *ops)
> {
> - struct master *m;
> + struct aggregate_device *m;
>
> - list_for_each_entry(m, , node)
> + list_for_each_entry(m, _devices, node)
> if (m->parent == parent && (!ops || m->ops == ops))
> return m;
>
> return NULL;
> }
>
> -static struct component *find_component(
Re: [Freedreno] [PATCH v2 00/34] component: Make into an aggregate bus
On Thu, Oct 07, 2021 at 04:46:22PM -0400, Stephen Boyd wrote: > Quoting Andrzej Hajda (2021-10-07 03:16:27) > > Hi Stephen, > > > > On 06.10.2021 21:37, Stephen Boyd wrote: > > > This series is from discussion we had on reordering the device lists for > > > drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put > > > the aggregate device onto and then we probe the aggregate device once > > > all the components are probed and call component_add(). The probe/remove > > > hooks are where the bind/unbind calls go, and then a shutdown hook is > > > added that can be used to shutdown the drm display pipeline at the right > > > time. > > > > > > This works for me on my sc7180 board. I no longer get a warning from i2c > > > at shutdown that we're trying to make an i2c transaction after the i2c > > > bus has been shutdown. There's more work to do on the msm drm driver to > > > extract component device resources like clks, regulators, etc. out of > > > the component bind function into the driver probe but I wanted to move > > > everything over now in other component drivers before tackling that > > > problem. > > > > > > As I understand you have DSI host with i2c-controlled DSI bridge. And > > there is an issue that bridge is shutdown before msmdrm. Your solution > > is to 'adjust' device order on pm list. > > I had similar issue and solved it locally by adding notification from > > DSI bridge to DSI host that is has to be removed: mipi_dsi_detach, this > > notification escalates in DSI host to component_del and this allow to > > react properly. > > > > Advantages: > > - it is local (only involves DSI host and DSI device), > > - it does not depend on PM internals, > > - it can be used in other scenarios as well - unbinding DSI device driver > > > > Disadvantage: > > - It is DSI specific (but this is your case), I have advertised some > > time ago more general approach [1][2]. > > > > [1]: https://static.sched.com/hosted_files/osseu18/0f/deferred_problem.pdf > > [2]: https://lwn.net/Articles/625454/ > > > > I think these are all points for or against using the component code in > general? Maybe you can send patches that you think can solve the problem > I'm experiencing and we can review them on the list. Yeah I think this is entirely orthogonal. If you use component, then component should provide a way to handle this. If you use something else, like drm_bridge or dsi or whatever, then that part should provide a solution to stage stuff correctly and handle all the ordering. Now there's a bunch of drivers which mix up component with bridge use and hilarity ensues, but since there's no real effort to fix that I think it's toally fine to just improve component.c meanwhile. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH] drm/msm/a6xx: Track current ctx by seqno
On Thu, Sep 30, 2021 at 8:20 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In theory a context can be destroyed and a new one allocated at the same
> address, making the pointer comparision to detect when we don't need to
> update the current pagetables invalid. Instead assign a sequence number
> to each context on creation, and use this for the check.
>
> Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables")
> Signed-off-by: Rob Clark
Usually the weak reference pattern is to wrap a spinlock or something
around it and clear it out on destruction. Or hold a full reference
(e.g. on intel hw the hw goes unhappy if there's no context/pagetables
at all, so we always need some). But I guess this works too.
-Daniel
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 11 ++-
> drivers/gpu/drm/msm/msm_drv.c | 3 +++
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> 4 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 5e1ae3df42ba..e0a8b2fd1ff0 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -106,7 +106,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
> u32 asid;
> u64 memptr = rbmemptr(ring, ttbr0);
>
> - if (ctx == a6xx_gpu->cur_ctx)
> + if (ctx->seqno == a6xx_gpu->cur_ctx_seqno)
> return;
>
> if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
> @@ -139,7 +139,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
> OUT_PKT7(ring, CP_EVENT_WRITE, 1);
> OUT_RING(ring, 0x31);
>
> - a6xx_gpu->cur_ctx = ctx;
> + a6xx_gpu->cur_ctx_seqno = ctx->seqno;
> }
>
> static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> @@ -1081,7 +1081,7 @@ static int hw_init(struct msm_gpu *gpu)
> /* Always come up on rb 0 */
> a6xx_gpu->cur_ring = gpu->rb[0];
>
> - a6xx_gpu->cur_ctx = NULL;
> + a6xx_gpu->cur_ctx_seqno = 0;
>
> /* Enable the SQE_to start the CP engine */
> gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> index 0bc2d062f54a..8e5527c881b1 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> @@ -19,7 +19,16 @@ struct a6xx_gpu {
> uint64_t sqe_iova;
>
> struct msm_ringbuffer *cur_ring;
> - struct msm_file_private *cur_ctx;
> +
> + /**
> +* cur_ctx_seqno:
> +*
> +* The ctx->seqno value of the context with current pgtables
> +* installed. Tracked by seqno rather than pointer value to
> +* avoid dangling pointers, and cases where a ctx can be freed
> +* and a new one created with the same address.
> +*/
> + int cur_ctx_seqno;
>
> struct a6xx_gmu gmu;
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 624078b3adf2..30c1efc3d8a0 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -711,6 +711,7 @@ static void load_gpu(struct drm_device *dev)
>
> static int context_init(struct drm_device *dev, struct drm_file *file)
> {
> + static atomic_t ident = ATOMIC_INIT(0);
> struct msm_drm_private *priv = dev->dev_private;
> struct msm_file_private *ctx;
>
> @@ -727,6 +728,8 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> ctx->aspace = msm_gpu_create_private_address_space(priv->gpu,
> current);
> file->driver_priv = ctx;
>
> + ctx->seqno = atomic_inc_return();
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index de062450add4..8633d0059a3e 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -59,6 +59,7 @@ struct msm_file_private {
> int queueid;
> struct msm_gem_address_space *aspace;
> struct kref ref;
> + int seqno;
> };
>
> enum msm_mdp_plane_property {
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH 00/15] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Thu, Sep 16, 2021 at 11:15:37PM +0200, Fernando Ramos wrote:
> Hi all,
>
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
> patch series is about.
>
> You will find two types of changes here:
>
> - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with
> "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has
> already been done in previous commits such as b7ea04d2)
>
> - Replacing "drm_modeset_lock_all()" with
> "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> in the remaining places (as it has already been done in previous commits
> such as 57037094)
>
> Most of the changes are straight forward, except for a few cases in the "amd"
> and "i915" drivers where some extra dancing was needed to overcome the
> limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used
> once inside the same function (the reason being that the macro expansion
> includes *labels*, and you can not have two labels named the same inside one
> function)
>
> Notice that, even after this patch series, some places remain where
> "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present,
> all inside drm core (which makes sense), except for two (in "amd" and "i915")
> which cannot be replaced due to the way they are being used.
Can we at least replace those with drm_modeset_lock_all_ctx and delete
drm_modeset_lock_all? That would be really nice goal to make sure these
don't spread further.
Otherwise great stuff, I'm trying to volunteer a few reviewers.
-Daniel
>
> Fernando Ramos (15):
> dmr: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
> dmr/i915: cleanup: drm_modeset_lock_all_ctx() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> dmr/msm: cleanup: drm_modeset_lock_all_ctx() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/shmobile: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/nouveau: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
>
> Documentation/gpu/todo.rst| 17 ---
> Documentation/locking/ww-mutex-design.rst | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +++--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 23 +
> drivers/gpu/drm/drm_client_modeset.c | 14 +++---
> drivers/gpu/drm/drm_crtc_helper.c | 18 ---
> drivers/gpu/drm/drm_fb_helper.c | 10 ++--
> drivers/gpu/drm/drm_framebuffer.c | 6 ++-
> drivers/gpu/drm/gma500/psb_device.c | 14 --
> drivers/gpu/drm/i915/display/intel_audio.c| 12 +++--
> drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
> .../drm/i915/display/intel_display_debugfs.c | 35 -
> drivers/gpu/drm/i915/display/intel_overlay.c | 45 -
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 5 +-
> drivers/gpu/drm/i915/i915_drv.c | 12 +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++-
> .../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 10 ++--
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 +++--
> drivers/gpu/drm/omapdrm/omap_fb.c | 6 ++-
> drivers/gpu/drm/radeon/radeon_device.c| 13 +++--
> drivers/gpu/drm/radeon/radeon_dp_mst.c| 7 ++-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++-
> drivers/gpu/drm/tegra/dsi.c | 6 ++-
> drivers/gpu/drm/tegra/hdmi.c | 5 +-
> drivers/gpu/drm/tegra/sor.c | 10 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +++--
> 28 files changed, 222 insertions(+), 180 deletions(-)
>
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v3 5/9] drm/msm: Add deadline based boost support
ence.h
> index 4783db528bcc..d34e853c555a 100644
> --- a/drivers/gpu/drm/msm/msm_fence.h
> +++ b/drivers/gpu/drm/msm/msm_fence.h
> @@ -50,6 +50,26 @@ struct msm_fence_context {
> volatile uint32_t *fenceptr;
>
> spinlock_t spinlock;
> +
> + /*
> + * TODO this doesn't really deal with multiple deadlines, like
> + * if userspace got multiple frames ahead.. OTOH atomic updates
> + * don't queue, so maybe that is ok
> + */
> +
> + /** next_deadline: Time of next deadline */
> + ktime_t next_deadline;
> +
> + /**
> + * next_deadline_fence:
> + *
> + * Fence value for next pending deadline. The deadline timer is
> + * canceled when this fence is signaled.
> + */
> + uint32_t next_deadline_fence;
> +
> + struct hrtimer deadline_timer;
> + struct kthread_work deadline_work;
> };
>
> struct msm_fence_context * msm_fence_context_alloc(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 0e4b45bff2e6..e031c9b495ed 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -425,6 +425,7 @@ void msm_devfreq_init(struct msm_gpu *gpu);
> void msm_devfreq_cleanup(struct msm_gpu *gpu);
> void msm_devfreq_resume(struct msm_gpu *gpu);
> void msm_devfreq_suspend(struct msm_gpu *gpu);
> +void msm_devfreq_boost(struct msm_gpu *gpu, unsigned factor);
> void msm_devfreq_active(struct msm_gpu *gpu);
> void msm_devfreq_idle(struct msm_gpu *gpu);
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> index 0a1ee20296a2..8a8d7b9028a3 100644
> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> @@ -144,6 +144,26 @@ void msm_devfreq_suspend(struct msm_gpu *gpu)
> devfreq_suspend_device(gpu->devfreq.devfreq);
> }
>
> +void msm_devfreq_boost(struct msm_gpu *gpu, unsigned factor)
> +{
> + struct msm_gpu_devfreq *df = >devfreq;
> + unsigned long freq;
> +
> + /*
> + * Hold devfreq lock to synchronize with get_dev_status()/
> + * target() callbacks
> + */
> + mutex_lock(>devfreq->lock);
> +
> + freq = get_freq(gpu);
> +
> + freq *= factor;
> +
> + msm_devfreq_target(>pdev->dev, , 0);
> +
> + mutex_unlock(>devfreq->lock);
> +}
> +
> void msm_devfreq_active(struct msm_gpu *gpu)
> {
> struct msm_gpu_devfreq *df = >devfreq;
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering
On Thu, Aug 26, 2021 at 09:16:25AM -0700, Rob Clark wrote: > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote: > > > > There's only one exclusive slot, and we must not break the ordering. > > > > Adding a new exclusive fence drops all previous fences from the > > dma_resv. To avoid violating the signalling order we err on the side of > > over-synchronizing by waiting for the existing fences, even if > > userspace asked us to ignore them. > > > > A better fix would be to us a dma_fence_chain or _array like e.g. > > amdgpu now uses, but > > - msm has a synchronous dma_fence_wait for anything from another > > context, so doesn't seem to care much, > > - and it probably makes sense to lift this into dma-resv.c code as a > > proper concept, so that drivers don't have to hack up their own > > solution each on their own. > > > > v2: Improve commit message per Lucas' suggestion. > > > > Cc: Lucas Stach > > Signed-off-by: Daniel Vetter > > Cc: Rob Clark > > Cc: Sean Paul > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedreno@lists.freedesktop.org > > a-b Also pushed to drm-misc-next, thanks for review -Daniel > > > --- > > drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > > b/drivers/gpu/drm/msm/msm_gem_submit.c > > index fb5a2eab27a2..66633dfd58a2 100644 > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > > @@ -330,7 +330,8 @@ static int submit_fence_sync(struct msm_gem_submit > > *submit, bool no_implicit) > > return ret; > > } > > > > - if (no_implicit) > > + /* exclusive fences must be ordered */ > > + if (no_implicit && !write) > > continue; > > > > ret = drm_sched_job_add_implicit_dependencies(>base, > > -- > > 2.32.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v5 12/20] drm/msm: Use scheduler dependency handling
On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote:
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
Merged up to this patch, except for etnaviv.
-Daniel
> ---
> drivers/gpu/drm/msm/msm_gem.h| 5 -
> drivers/gpu/drm/msm/msm_gem_submit.c | 19 +--
> drivers/gpu/drm/msm/msm_ringbuffer.c | 12
> 3 files changed, 5 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index f9e3ffb2309a..8bf0ac707fd7 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -312,11 +312,6 @@ struct msm_gem_submit {
> struct ww_acquire_ctx ticket;
> uint32_t seqno; /* Sequence number of the submit on the ring */
>
> - /* Array of struct dma_fence * to block on before submitting this job.
> - */
> - struct xarray deps;
> - unsigned long last_dep;
> -
> /* Hw fence, which is created when the scheduler executes the job, and
>* is signaled when the hw finishes (via seqno write from cmdstream)
>*/
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 96cea0ba4cfd..fb5a2eab27a2 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> - xa_init_flags(>deps, XA_FLAGS_ALLOC);
> -
> kref_init(>ref);
> submit->dev = dev;
> submit->aspace = queue->ctx->aspace;
> @@ -72,8 +70,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
> {
> struct msm_gem_submit *submit =
> container_of(kref, struct msm_gem_submit, ref);
> - unsigned long index;
> - struct dma_fence *fence;
> unsigned i;
>
> if (submit->fence_id) {
> @@ -82,12 +78,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
> mutex_unlock(>queue->lock);
> }
>
> - xa_for_each (>deps, index, fence) {
> - dma_fence_put(fence);
> - }
> -
> - xa_destroy(>deps);
> -
> dma_fence_put(submit->user_fence);
> dma_fence_put(submit->hw_fence);
>
> @@ -343,8 +333,9 @@ static int submit_fence_sync(struct msm_gem_submit
> *submit, bool no_implicit)
> if (no_implicit)
> continue;
>
> - ret = drm_gem_fence_array_add_implicit(>deps, obj,
> - write);
> + ret = drm_sched_job_add_implicit_dependencies(>base,
> + obj,
> + write);
> if (ret)
> break;
> }
> @@ -588,7 +579,7 @@ static struct drm_syncobj **msm_parse_deps(struct
> msm_gem_submit *submit,
> if (ret)
> break;
>
> - ret = drm_gem_fence_array_add(>deps, fence);
> + ret = drm_sched_job_add_dependency(>base, fence);
> if (ret)
> break;
>
> @@ -798,7 +789,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> goto out_unlock;
> }
>
> - ret = drm_gem_fence_array_add(>deps, in_fence);
> + ret = drm_sched_job_add_dependency(>base, in_fence);
> if (ret)
> goto out_unlock;
> }
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuffer.c
> index bd54c1412649..652b1dedd7c1 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> @@ -11,17 +11,6 @@ static uint num_hw_submissions = 8;
> MODULE_PARM_DESC(num_hw_submissions, "The max # of jobs to write into
> ringbuffer (default 8)");
> module_param(num_hw_submissions, uint, 0600);
>
> -static struct dma_fence *msm_job_dependency(struct drm_sched_job *job,
> - struct drm_sched_entity *s_entity)
> -{
> - struct msm_gem_submit *submit = to_msm_submit(job);
> -
> - if (!xa_empty(>deps))
> - return xa_erase(>deps, submit->last_dep++);
> -
> - ret
[Freedreno] [PATCH] drm/msm: Improve drm/sched point of no return rules
Originally drm_sched_job_init was the point of no return, after which
drivers really should submit a job. I've split that up, which allows
us to fix this issue pretty easily.
Only thing we have to take care of is to not skip to error paths after
that. Other drivers do this the same for out-fence and similar things.
v2: It's not really a bugfix, just an improvement, since all
drm_sched_job_arm does is reserve the fence number. And gaps should be
fine, as long as the drm_sched_job doesn't escape anywhere at all.
For robustness it's still better to align with other drivers here and
not bail out after job_arm().
v3: I misplaced drm_sched_job_arm by _one_ line! Thanks to Rob for
testing and debug help.
Cc: Rob Clark
Cc: Rob Clark
Cc: Sean Paul
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 4d1c4d5f6a2a..71b8c8f752a3 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
return ERR_PTR(ret);
}
- drm_sched_job_arm(>base);
-
xa_init_flags(>deps, XA_FLAGS_ALLOC);
kref_init(>ref);
@@ -880,6 +878,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit->nr_cmds = i;
+ drm_sched_job_arm(>base);
+
submit->user_fence = dma_fence_get(>base.s_fence->finished);
/*
@@ -891,17 +891,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (submit->fence_id < 0) {
ret = submit->fence_id = 0;
submit->fence_id = 0;
- goto out;
}
- if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
+ if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
struct sync_file *sync_file =
sync_file_create(submit->user_fence);
if (!sync_file) {
ret = -ENOMEM;
- goto out;
+ } else {
+ fd_install(out_fence_fd, sync_file->file);
+ args->fence_fd = out_fence_fd;
}
- fd_install(out_fence_fd, sync_file->file);
- args->fence_fd = out_fence_fd;
}
submit_attach_object_fences(submit);
--
2.32.0
Re: [Freedreno] [PATCH v2 4/5] drm/scheduler: Add fence deadline support
On Mon, Aug 16, 2021 at 03:25:20PM -0700, Rob Clark wrote:
> On Mon, Aug 16, 2021 at 8:38 AM Daniel Vetter wrote:
> >
> > On Mon, Aug 16, 2021 at 12:14:35PM +0200, Christian König wrote:
> > > Am 07.08.21 um 20:37 schrieb Rob Clark:
> > > > From: Rob Clark
> > > >
> > > > As the finished fence is the one that is exposed to userspace, and
> > > > therefore the one that other operations, like atomic update, would
> > > > block on, we need to propagate the deadline from from the finished
> > > > fence to the actual hw fence.
> > > >
> > > > Signed-off-by: Rob Clark
> >
> > I guess you're already letting the compositor run at a higher gpu priority
> > so that your deadline'd drm_sched_job isn't stuck behind the app rendering
> > the next frame?
>
> With the scheduler conversion we do have multiple priorities (provided
> by scheduler) for all generations.. but not yet preemption for all
> generations.
>
> But the most common use-case where we need this ends up being display
> composition (either fullscreen app/game or foreground app/game
> composited via overlay) so I haven't thought too much about the next
> step of boosting job priority. I might leave that to someone who
> already has preemption wired up ;-)
Atm no-one, drm/sched isn't really aware that's a concept. I was more
thinking of just boosting that request as a first step. Maybe within the
same priority class we pick jobs with deadlines first, or something like
that.
Preempting is an entire can of worms on top.
-Daniel
>
> BR,
> -R
>
> > I'm not sure whether you wire that one up as part of the conversion to
> > drm/sched. Without that I think we might need to ponder how we can do a
> > prio-boost for these, e.g. within a scheduling class we pick the jobs with
> > the nearest deadline first, before we pick others.
> > -Daniel
> >
> > > > ---
> > > > drivers/gpu/drm/scheduler/sched_fence.c | 25 +
> > > > drivers/gpu/drm/scheduler/sched_main.c | 3 +++
> > > > include/drm/gpu_scheduler.h | 6 ++
> > > > 3 files changed, 34 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
> > > > b/drivers/gpu/drm/scheduler/sched_fence.c
> > > > index 69de2c76731f..f389dca44185 100644
> > > > --- a/drivers/gpu/drm/scheduler/sched_fence.c
> > > > +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> > > > @@ -128,6 +128,30 @@ static void
> > > > drm_sched_fence_release_finished(struct dma_fence *f)
> > > > dma_fence_put(>scheduled);
> > > > }
> > > > +static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
> > > > + ktime_t deadline)
> > > > +{
> > > > + struct drm_sched_fence *fence = to_drm_sched_fence(f);
> > > > + unsigned long flags;
> > > > +
> > > > + spin_lock_irqsave(>lock, flags);
> > > > +
> > > > + /* If we already have an earlier deadline, keep it: */
> > > > + if (test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT, >flags) &&
> > > > + ktime_before(fence->deadline, deadline)) {
> > > > + spin_unlock_irqrestore(>lock, flags);
> > > > + return;
> > > > + }
> > > > +
> > > > + fence->deadline = deadline;
> > > > + set_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT, >flags);
> > > > +
> > > > + spin_unlock_irqrestore(>lock, flags);
> > > > +
> > > > + if (fence->parent)
> > > > + dma_fence_set_deadline(fence->parent, deadline);
> > > > +}
> > > > +
> > > > static const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
> > > > .get_driver_name = drm_sched_fence_get_driver_name,
> > > > .get_timeline_name = drm_sched_fence_get_timeline_name,
> > > > @@ -138,6 +162,7 @@ static const struct dma_fence_ops
> > > > drm_sched_fence_ops_finished = {
> > > > .get_driver_name = drm_sched_fence_get_driver_name,
> > > > .get_timeline_name = drm_sched_fence_get_timeline_name,
> > > > .release = drm_sched_fence_release_finished,
> > > > + .set_deadline = drm_sched_fence_set_deadline_finished,
> > > > };
> > > > struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f)
> > > &g
[Freedreno] [PATCH] drm/msm: Improve drm/sched point of no return rules
Originally drm_sched_job_init was the point of no return, after which
drivers really should submit a job. I've split that up, which allows
us to fix this issue pretty easily.
Only thing we have to take care of is to not skip to error paths after
that. Other drivers do this the same for out-fence and similar things.
v2: It's not really a bugfix, just an improvement, since all
drm_sched_job_arm does is reserve the fence number. And gaps should be
fine, as long as the drm_sched_job doesn't escape anywhere at all.
For robustness it's still better to align with other drivers here and
not bail out after job_arm().
Cc: Rob Clark
Cc: Rob Clark
Cc: Sean Paul
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 4d1c4d5f6a2a..371ed9154e58 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
return ERR_PTR(ret);
}
- drm_sched_job_arm(>base);
-
xa_init_flags(>deps, XA_FLAGS_ALLOC);
kref_init(>ref);
@@ -882,6 +880,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit->user_fence = dma_fence_get(>base.s_fence->finished);
+ drm_sched_job_arm(>base);
+
/*
* Allocate an id which can be used by WAIT_FENCE ioctl to map back
* to the underlying fence.
@@ -891,17 +891,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (submit->fence_id < 0) {
ret = submit->fence_id = 0;
submit->fence_id = 0;
- goto out;
}
- if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
+ if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
struct sync_file *sync_file =
sync_file_create(submit->user_fence);
if (!sync_file) {
ret = -ENOMEM;
- goto out;
+ } else {
+ fd_install(out_fence_fd, sync_file->file);
+ args->fence_fd = out_fence_fd;
}
- fd_install(out_fence_fd, sync_file->file);
- args->fence_fd = out_fence_fd;
}
submit_attach_object_fences(submit);
--
2.32.0
[Freedreno] [PATCH] drm/sched: Split drm_sched_job_init
This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is that I want to push the dependency tracking helpers into the scheduler code, and that means drm_sched_job_init must be called a lot earlier, without arming the job. v2: - don't change .gitignore (Steven) - don't forget v3d (Emma) v3: Emma noticed that I leak the memory allocated in drm_sched_job_init if we bail out before the point of no return in subsequent driver patches. To be able to fix this change drm_sched_job_cleanup() so it can handle being called both before and after drm_sched_job_arm(). Also improve the kerneldoc for this. v4: - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as usual (Melissa) - Christian pointed out that drm_sched_entity_select_rq() also needs to be moved into drm_sched_job_arm, which made me realize that the job->id definitely needs to be moved too. Shuffle things to fit between job_init and job_arm. v5: Reshuffle the split between init/arm once more, amdgpu abuses drm_sched.ready to signal gpu reset failures. Also document this somewhat. (Christian) v6: Rebase on top of the msm drm/sched support. Note that the drm_sched_job_init() call is completely misplaced, and hence also the split-out drm_sched_entity_push_job(). I've put in a FIXME which the next patch will address. v7: Drop the FIXME in msm, after discussions with Rob I agree it shouldn't be a problem where it is now. Acked-by: Christian König Acked-by: Melissa Wen Cc: Melissa Wen Acked-by: Emma Anholt Acked-by: Steven Price (v2) Reviewed-by: Boris Brezillon (v5) Signed-off-by: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Qiang Yu Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: Masahiro Yamada Cc: Kees Cook Cc: Adam Borowski Cc: Nick Terrell Cc: Mauro Carvalho Chehab Cc: Paul Menzel Cc: Sami Tolvanen Cc: Viresh Kumar Cc: Alex Deucher Cc: Dave Airlie Cc: Nirmoy Das Cc: Deepak R Varma Cc: Lee Jones Cc: Kevin Wang Cc: Chen Li Cc: Luben Tuikov Cc: "Marek Olšák" Cc: Dennis Li Cc: Maarten Lankhorst Cc: Andrey Grodzovsky Cc: Sonny Jiang Cc: Boris Brezillon Cc: Tian Tao Cc: etna...@lists.freedesktop.org Cc: l...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: Emma Anholt Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedreno@lists.freedesktop.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 + drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 + drivers/gpu/drm/lima/lima_sched.c| 2 + drivers/gpu/drm/msm/msm_gem_submit.c | 2 + drivers/gpu/drm/panfrost/panfrost_job.c | 2 + drivers/gpu/drm/scheduler/sched_entity.c | 6 +-- drivers/gpu/drm/scheduler/sched_fence.c | 19 --- drivers/gpu/drm/scheduler/sched_main.c | 69 drivers/gpu/drm/v3d/v3d_gem.c| 2 + include/drm/gpu_scheduler.h | 7 ++- 11 files changed, 93 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index c5386d13eb4a..a4ec092af9a7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1226,6 +1226,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, if (r) goto error_unlock; + drm_sched_job_arm(>base); + /* No memory allocation is allowed while holding the notifier lock. * The lock is held until amdgpu_cs_submit is finished and fence is * added to BOs. diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index d33e6d97cc89..5ddb955d2315 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -170,6 +170,8 @@ int amdgpu_job_submit(struct amdgpu_job *job, struct drm_sched_entity *entity, if (r) return r; + drm_sched_job_arm(>base); + *f = dma_fence_get(>base.s_fence->finished); amdgpu_job_free_resources(job); drm_sched_entity_push_job(>base, entity); diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c index feb6da1b6ceb..05f412204118 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c @@ -163,6 +163,8 @@ int etnaviv_sched_push_job(struct drm_sched_entity *sched_entity, if (ret) goto out_unlock; + drm_sched_job_arm(>sched_job); + submit->out_fence = dma_fence_get(>sched_job.s_fence->finished); submi
Re: [Freedreno] [PATCH v2 4/5] drm/scheduler: Add fence deadline support
On Mon, Aug 16, 2021 at 12:14:35PM +0200, Christian König wrote:
> Am 07.08.21 um 20:37 schrieb Rob Clark:
> > From: Rob Clark
> >
> > As the finished fence is the one that is exposed to userspace, and
> > therefore the one that other operations, like atomic update, would
> > block on, we need to propagate the deadline from from the finished
> > fence to the actual hw fence.
> >
> > Signed-off-by: Rob Clark
I guess you're already letting the compositor run at a higher gpu priority
so that your deadline'd drm_sched_job isn't stuck behind the app rendering
the next frame?
I'm not sure whether you wire that one up as part of the conversion to
drm/sched. Without that I think we might need to ponder how we can do a
prio-boost for these, e.g. within a scheduling class we pick the jobs with
the nearest deadline first, before we pick others.
-Daniel
> > ---
> > drivers/gpu/drm/scheduler/sched_fence.c | 25 +
> > drivers/gpu/drm/scheduler/sched_main.c | 3 +++
> > include/drm/gpu_scheduler.h | 6 ++
> > 3 files changed, 34 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
> > b/drivers/gpu/drm/scheduler/sched_fence.c
> > index 69de2c76731f..f389dca44185 100644
> > --- a/drivers/gpu/drm/scheduler/sched_fence.c
> > +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> > @@ -128,6 +128,30 @@ static void drm_sched_fence_release_finished(struct
> > dma_fence *f)
> > dma_fence_put(>scheduled);
> > }
> > +static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
> > + ktime_t deadline)
> > +{
> > + struct drm_sched_fence *fence = to_drm_sched_fence(f);
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>lock, flags);
> > +
> > + /* If we already have an earlier deadline, keep it: */
> > + if (test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT, >flags) &&
> > + ktime_before(fence->deadline, deadline)) {
> > + spin_unlock_irqrestore(>lock, flags);
> > + return;
> > + }
> > +
> > + fence->deadline = deadline;
> > + set_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT, >flags);
> > +
> > + spin_unlock_irqrestore(>lock, flags);
> > +
> > + if (fence->parent)
> > + dma_fence_set_deadline(fence->parent, deadline);
> > +}
> > +
> > static const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
> > .get_driver_name = drm_sched_fence_get_driver_name,
> > .get_timeline_name = drm_sched_fence_get_timeline_name,
> > @@ -138,6 +162,7 @@ static const struct dma_fence_ops
> > drm_sched_fence_ops_finished = {
> > .get_driver_name = drm_sched_fence_get_driver_name,
> > .get_timeline_name = drm_sched_fence_get_timeline_name,
> > .release = drm_sched_fence_release_finished,
> > + .set_deadline = drm_sched_fence_set_deadline_finished,
> > };
> > struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f)
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index a2a953693b45..3ab0900d3596 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -818,6 +818,9 @@ static int drm_sched_main(void *param)
> > if (!IS_ERR_OR_NULL(fence)) {
> > s_fence->parent = dma_fence_get(fence);
> > + if (test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT,
> > +_fence->finished.flags))
> > + dma_fence_set_deadline(fence,
> > s_fence->deadline);
>
> Maybe move this into a dma_sched_fence_set_parent() function.
>
> Apart from that looks good to me.
>
> Regards,
> Christian.
>
> > r = dma_fence_add_callback(fence, _job->cb,
> >drm_sched_job_done_cb);
> > if (r == -ENOENT)
> > diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > index d18af49fd009..0f08ade614ae 100644
> > --- a/include/drm/gpu_scheduler.h
> > +++ b/include/drm/gpu_scheduler.h
> > @@ -144,6 +144,12 @@ struct drm_sched_fence {
> >*/
> > struct dma_fencefinished;
> > + /**
> > +* @deadline: deadline set on _sched_fence.finished which
> > +* potentially needs to be propagated to _sched_fence.parent
> > +*/
> > + ktime_t deadline;
> > +
> > /**
> >* @parent: the fence returned by _sched_backend_ops.run_job
> >* when scheduling the job on hardware. We signal the
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 3/5] drm/atomic-helper: Set fence deadline for vblank
On Sat, Aug 07, 2021 at 11:37:57AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For an atomic commit updating a single CRTC (ie. a pageflip) calculate
> the next vblank time, and inform the fence(s) of that deadline.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 36 +
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index bc3487964fb5..7caa2c3cc304 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1406,6 +1406,40 @@ void drm_atomic_helper_commit_modeset_enables(struct
> drm_device *dev,
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_enables);
>
> +/*
> + * For atomic updates which touch just a single CRTC, calculate the time of
> the
> + * next vblank, and inform all the fences of the of the deadline.
s/of the//
Otherwise lgtm, Reviewed-by: Daniel Vetter
> + */
> +static void set_fence_deadline(struct drm_device *dev,
> +struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc, *wait_crtc = NULL;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_plane *plane;
> + struct drm_plane_state *new_plane_state;
> + ktime_t vbltime;
> + int i;
> +
> + for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> + if (wait_crtc)
> + return;
> + wait_crtc = crtc;
> + }
> +
> + /* If no CRTCs updated, then nothing to do: */
> + if (!wait_crtc)
> + return;
> +
> + if (drm_crtc_next_vblank_time(wait_crtc, ))
> + return;
> +
> + for_each_new_plane_in_state (state, plane, new_plane_state, i) {
> + if (!new_plane_state->fence)
> + continue;
> + dma_fence_set_deadline(new_plane_state->fence, vbltime);
> + }
> +}
> +
> /**
> * drm_atomic_helper_wait_for_fences - wait for fences stashed in plane state
> * @dev: DRM device
> @@ -1435,6 +1469,8 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
> *dev,
> struct drm_plane_state *new_plane_state;
> int i, ret;
>
> + set_fence_deadline(dev, state);
> +
> for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> if (!new_plane_state->fence)
> continue;
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v5 12/20] drm/msm: Use scheduler dependency handling
On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote:
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
Ping for ack please.
-Daniel
> ---
> drivers/gpu/drm/msm/msm_gem.h| 5 -
> drivers/gpu/drm/msm/msm_gem_submit.c | 19 +--
> drivers/gpu/drm/msm/msm_ringbuffer.c | 12
> 3 files changed, 5 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index f9e3ffb2309a..8bf0ac707fd7 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -312,11 +312,6 @@ struct msm_gem_submit {
> struct ww_acquire_ctx ticket;
> uint32_t seqno; /* Sequence number of the submit on the ring */
>
> - /* Array of struct dma_fence * to block on before submitting this job.
> - */
> - struct xarray deps;
> - unsigned long last_dep;
> -
> /* Hw fence, which is created when the scheduler executes the job, and
>* is signaled when the hw finishes (via seqno write from cmdstream)
>*/
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 96cea0ba4cfd..fb5a2eab27a2 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> - xa_init_flags(>deps, XA_FLAGS_ALLOC);
> -
> kref_init(>ref);
> submit->dev = dev;
> submit->aspace = queue->ctx->aspace;
> @@ -72,8 +70,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
> {
> struct msm_gem_submit *submit =
> container_of(kref, struct msm_gem_submit, ref);
> - unsigned long index;
> - struct dma_fence *fence;
> unsigned i;
>
> if (submit->fence_id) {
> @@ -82,12 +78,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
> mutex_unlock(>queue->lock);
> }
>
> - xa_for_each (>deps, index, fence) {
> - dma_fence_put(fence);
> - }
> -
> - xa_destroy(>deps);
> -
> dma_fence_put(submit->user_fence);
> dma_fence_put(submit->hw_fence);
>
> @@ -343,8 +333,9 @@ static int submit_fence_sync(struct msm_gem_submit
> *submit, bool no_implicit)
> if (no_implicit)
> continue;
>
> - ret = drm_gem_fence_array_add_implicit(>deps, obj,
> - write);
> + ret = drm_sched_job_add_implicit_dependencies(>base,
> + obj,
> + write);
> if (ret)
> break;
> }
> @@ -588,7 +579,7 @@ static struct drm_syncobj **msm_parse_deps(struct
> msm_gem_submit *submit,
> if (ret)
> break;
>
> - ret = drm_gem_fence_array_add(>deps, fence);
> + ret = drm_sched_job_add_dependency(>base, fence);
> if (ret)
> break;
>
> @@ -798,7 +789,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> goto out_unlock;
> }
>
> - ret = drm_gem_fence_array_add(>deps, in_fence);
> + ret = drm_sched_job_add_dependency(>base, in_fence);
> if (ret)
> goto out_unlock;
> }
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuffer.c
> index bd54c1412649..652b1dedd7c1 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> @@ -11,17 +11,6 @@ static uint num_hw_submissions = 8;
> MODULE_PARM_DESC(num_hw_submissions, "The max # of jobs to write into
> ringbuffer (default 8)");
> module_param(num_hw_submissions, uint, 0600);
>
> -static struct dma_fence *msm_job_dependency(struct drm_sched_job *job,
> - struct drm_sched_entity *s_entity)
> -{
> - struct msm_gem_submit *submit = to_msm_submit(job);
> -
> - if (!xa_empty(>deps))
> - return xa_erase(>deps, submit->last_dep++);
> -
> - return NULL;
> -}
> -
Re: [Freedreno] [PATCH v2] drm/drv: Remove initialization of static variables
On Fri, Aug 06, 2021 at 10:30:47AM +0800, zhaoxiao wrote:
> Address the following checkpatch errors:
> ERROR: do not initialise statics to false
>
> FILE: :drivers/gpu/drm/msm/msm_drv.c:21:
> -static bool reglog = false;
>
> FILE: :drivers/gpu/drm/msm/msm_drv.c:31:
> -bool dumpstate = false;
>
> Signed-off-by: zhaoxiao
Subject should start out with drm/msm, not drm/drv - that would indicate a
patch touching the drm_drv.c core files, or things related to that.
-Daniel
> ---
> v2: change the patch description
> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 9b8fa2ad0d84..d9ca4bc9620b 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -59,7 +59,7 @@ static const struct drm_mode_config_helper_funcs
> mode_config_helper_funcs = {
> };
>
> #ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
> -static bool reglog = false;
> +static bool reglog;
> MODULE_PARM_DESC(reglog, "Enable register read/write logging");
> module_param(reglog, bool, 0600);
> #else
> @@ -76,7 +76,7 @@ static char *vram = "16m";
> MODULE_PARM_DESC(vram, "Configure VRAM size (for devices without
> IOMMU/GPUMMU)");
> module_param(vram, charp, 0);
>
> -bool dumpstate = false;
> +bool dumpstate;
> MODULE_PARM_DESC(dumpstate, "Dump KMS state on errors");
> module_param(dumpstate, bool, 0600);
>
> --
> 2.20.1
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Fri, Aug 6, 2021 at 8:57 PM Rob Clark wrote:
>
> On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter wrote:
> >
> > On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> > >
> > > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter
> > > wrote:
> > > >
> > > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > > > >
> > > > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter
> > > > > wrote:
> > > > > >
> > > > > > Originally drm_sched_job_init was the point of no return, after
> > > > > > which
> > > > > > drivers must submit a job. I've split that up, which allows us to
> > > > > > fix
> > > > > > this issue pretty easily.
> > > > > >
> > > > > > Only thing we have to take care of is to not skip to error paths
> > > > > > after
> > > > > > that. Other drivers do this the same for out-fence and similar
> > > > > > things.
> > > > > >
> > > > > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> > > > > > Cc: Rob Clark
> > > > > > Cc: Rob Clark
> > > > > > Cc: Sean Paul
> > > > > > Cc: Sumit Semwal
> > > > > > Cc: "Christian König"
> > > > > > Cc: linux-arm-...@vger.kernel.org
> > > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > > Cc: freedreno@lists.freedesktop.org
> > > > > > Cc: linux-me...@vger.kernel.org
> > > > > > Cc: linaro-mm-...@lists.linaro.org
> > > > > > Signed-off-by: Daniel Vetter
> > > > > > ---
> > > > > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> > > > > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > index 6d6c44f0e1f3..d0ed4ddc509e 100644
> > > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > @@ -52,9 +52,6 @@ static struct msm_gem_submit
> > > > > > *submit_create(struct drm_device *dev,
> > > > > > return ERR_PTR(ret);
> > > > > > }
> > > > > >
> > > > > > - /* FIXME: this is way too early */
> > > > > > - drm_sched_job_arm(>base);
> > > > > > -
> > > > > > xa_init_flags(>deps, XA_FLAGS_ALLOC);
> > > > > >
> > > > > > kref_init(>ref);
> > > > > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device
> > > > > > *dev, void *data,
> > > > > >
> > > > > > submit->user_fence =
> > > > > > dma_fence_get(>base.s_fence->finished);
> > > > > >
> > > > > > + /* point of no return, we _have_ to submit no matter what */
> > > > > > + drm_sched_job_arm(>base);
> > > > > > +
> > > > > > /*
> > > > > > * Allocate an id which can be used by WAIT_FENCE ioctl to
> > > > > > map back
> > > > > > * to the underlying fence.
> > > > > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device
> > > > > > *dev, void *data,
> > > > > > if (submit->fence_id < 0) {
> > > > > > ret = submit->fence_id = 0;
> > > > > > submit->fence_id = 0;
> > > > > > - goto out;
> > > > > > }
> > > > > >
> > > > > > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > > > > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > > > > struct sync_file *sync_file =
> > > > > > sync_file_create(submit->user_fence);
> > > > > > if (!sync_file) {
> > > > > > ret = -ENOMEM;
> > > > > > - goto out;
> > > > > > + }
Re: [Freedreno] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
>
> On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
> >
> > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > >
> > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter
> > > wrote:
> > > >
> > > > Originally drm_sched_job_init was the point of no return, after which
> > > > drivers must submit a job. I've split that up, which allows us to fix
> > > > this issue pretty easily.
> > > >
> > > > Only thing we have to take care of is to not skip to error paths after
> > > > that. Other drivers do this the same for out-fence and similar things.
> > > >
> > > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> > > > Cc: Rob Clark
> > > > Cc: Rob Clark
> > > > Cc: Sean Paul
> > > > Cc: Sumit Semwal
> > > > Cc: "Christian König"
> > > > Cc: linux-arm-...@vger.kernel.org
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Cc: freedreno@lists.freedesktop.org
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: linaro-mm-...@lists.linaro.org
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> > > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > index 6d6c44f0e1f3..d0ed4ddc509e 100644
> > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> > > > drm_device *dev,
> > > > return ERR_PTR(ret);
> > > > }
> > > >
> > > > - /* FIXME: this is way too early */
> > > > - drm_sched_job_arm(>base);
> > > > -
> > > > xa_init_flags(>deps, XA_FLAGS_ALLOC);
> > > >
> > > > kref_init(>ref);
> > > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev,
> > > > void *data,
> > > >
> > > > submit->user_fence =
> > > > dma_fence_get(>base.s_fence->finished);
> > > >
> > > > + /* point of no return, we _have_ to submit no matter what */
> > > > + drm_sched_job_arm(>base);
> > > > +
> > > > /*
> > > > * Allocate an id which can be used by WAIT_FENCE ioctl to map
> > > > back
> > > > * to the underlying fence.
> > > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev,
> > > > void *data,
> > > > if (submit->fence_id < 0) {
> > > > ret = submit->fence_id = 0;
> > > > submit->fence_id = 0;
> > > > - goto out;
> > > > }
> > > >
> > > > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > > struct sync_file *sync_file =
> > > > sync_file_create(submit->user_fence);
> > > > if (!sync_file) {
> > > > ret = -ENOMEM;
> > > > - goto out;
> > > > + } else {
> > > > + fd_install(out_fence_fd, sync_file->file);
> > > > + args->fence_fd = out_fence_fd;
> > > > }
> > > > - fd_install(out_fence_fd, sync_file->file);
> > > > - args->fence_fd = out_fence_fd;
> > >
> > > I wonder if instead we should (approximately) undo "drm/msm/submit:
> > > Simplify out-fence-fd handling" so that the point that it could fail
> > > is moved up ahead of the drm_sched_job_arm()?
> >
> > Hm yeah. Up to you how you want to paint this shed, I think either is fine.
> >
> > > Also, does the dma_fence_get() work before drm_sched_job_arm()? From
> > > a quick look, it looks like it won't, but I'm still playing catchup
> > > and haven't had a chance to look at your entire series. If it doesn't
> > > work before drm_sched_job_arm(), then there is
Re: [Freedreno] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
>
> On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > Originally drm_sched_job_init was the point of no return, after which
> > drivers must submit a job. I've split that up, which allows us to fix
> > this issue pretty easily.
> >
> > Only thing we have to take care of is to not skip to error paths after
> > that. Other drivers do this the same for out-fence and similar things.
> >
> > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> > Cc: Rob Clark
> > Cc: Rob Clark
> > Cc: Sean Paul
> > Cc: Sumit Semwal
> > Cc: "Christian König"
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: freedreno@lists.freedesktop.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> > 1 file changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index 6d6c44f0e1f3..d0ed4ddc509e 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> > drm_device *dev,
> > return ERR_PTR(ret);
> > }
> >
> > - /* FIXME: this is way too early */
> > - drm_sched_job_arm(>base);
> > -
> > xa_init_flags(>deps, XA_FLAGS_ALLOC);
> >
> > kref_init(>ref);
> > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > *data,
> >
> > submit->user_fence = dma_fence_get(>base.s_fence->finished);
> >
> > + /* point of no return, we _have_ to submit no matter what */
> > + drm_sched_job_arm(>base);
> > +
> > /*
> > * Allocate an id which can be used by WAIT_FENCE ioctl to map back
> > * to the underlying fence.
> > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > *data,
> > if (submit->fence_id < 0) {
> > ret = submit->fence_id = 0;
> > submit->fence_id = 0;
> > - goto out;
> > }
> >
> > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > struct sync_file *sync_file =
> > sync_file_create(submit->user_fence);
> > if (!sync_file) {
> > ret = -ENOMEM;
> > - goto out;
> > + } else {
> > + fd_install(out_fence_fd, sync_file->file);
> > + args->fence_fd = out_fence_fd;
> > }
> > - fd_install(out_fence_fd, sync_file->file);
> > - args->fence_fd = out_fence_fd;
>
> I wonder if instead we should (approximately) undo "drm/msm/submit:
> Simplify out-fence-fd handling" so that the point that it could fail
> is moved up ahead of the drm_sched_job_arm()?
Hm yeah. Up to you how you want to paint this shed, I think either is fine.
> Also, does the dma_fence_get() work before drm_sched_job_arm()? From
> a quick look, it looks like it won't, but I'm still playing catchup
> and haven't had a chance to look at your entire series. If it doesn't
> work before drm_sched_job_arm(), then there is really no way to
> prevent a error path between the fence-init and job-submit.
Yes. I thought I've checked that I put the _arm() in the right spot,
but I guess I screwed up and you need the fence before the point where
I've put the job_arm()? And yes the error path cannot be avoided for
out-fences, that's what I tried to explain in the commit message.
> But, prior to your series, wouldn't a failure after
> drm_sched_job_init() but before the job is submitted just burn a
> fence-id, and otherwise carry on it's merry way?
Maybe? I'm not sure whether the scheduler gets confused about the gap
and freak out abou that. I'm fairly new to that code and learning
(which is part why I'm working on it). Since you look up in
fences/syncobj after job_init() it should be pretty easy to whip up a
testcase and see what happens. Also as long as nothing fails you won't
see an issue, that's for sure.
-Daniel
> BR,
> -R
>
> > }
> >
> > submit_attach_object_fences(submit);
> > --
> > 2.32.0
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Freedreno] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init
On Thu, Aug 5, 2021 at 4:47 PM Christian König wrote: > > Am 05.08.21 um 16:07 schrieb Daniel Vetter: > > On Thu, Aug 5, 2021 at 3:44 PM Christian König > > wrote: > >> Am 05.08.21 um 12:46 schrieb Daniel Vetter: > >>> This is a very confusingly named function, because not just does it > >>> init an object, it arms it and provides a point of no return for > >>> pushing a job into the scheduler. It would be nice if that's a bit > >>> clearer in the interface. > >>> > >>> But the real reason is that I want to push the dependency tracking > >>> helpers into the scheduler code, and that means drm_sched_job_init > >>> must be called a lot earlier, without arming the job. > >>> > >>> v2: > >>> - don't change .gitignore (Steven) > >>> - don't forget v3d (Emma) > >>> > >>> v3: Emma noticed that I leak the memory allocated in > >>> drm_sched_job_init if we bail out before the point of no return in > >>> subsequent driver patches. To be able to fix this change > >>> drm_sched_job_cleanup() so it can handle being called both before and > >>> after drm_sched_job_arm(). > >>> > >>> Also improve the kerneldoc for this. > >>> > >>> v4: > >>> - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as > >>> usual (Melissa) > >>> > >>> - Christian pointed out that drm_sched_entity_select_rq() also needs > >>> to be moved into drm_sched_job_arm, which made me realize that the > >>> job->id definitely needs to be moved too. > >>> > >>> Shuffle things to fit between job_init and job_arm. > >>> > >>> v5: > >>> Reshuffle the split between init/arm once more, amdgpu abuses > >>> drm_sched.ready to signal gpu reset failures. Also document this > >>> somewhat. (Christian) > >>> > >>> v6: > >>> Rebase on top of the msm drm/sched support. Note that the > >>> drm_sched_job_init() call is completely misplaced, and hence also the > >>> split-out drm_sched_entity_push_job(). I've put in a FIXME which the next > >>> patch will address. > >>> > >>> Acked-by: Melissa Wen > >>> Cc: Melissa Wen > >>> Acked-by: Emma Anholt > >>> Acked-by: Steven Price (v2) > >>> Reviewed-by: Boris Brezillon (v5) > >>> Signed-off-by: Daniel Vetter > >> At least the amdgpu parts look ok of hand, but I can't judge the rest I > >> think. > > The thing that really scares me here and that I got wrong a few times > > is the cleanup for drm_sched_job at the various points. Can you give > > those parts in drm/scheduler/ a full review pls, just to make sure? I > > can note that in the tag ofc, just like a bit more confidence here > > that it's not busted :-) > > I can take another look, but I won't have time for that in the next two > weeks - vacation and kid starting school. Hm ok I'll ask others, since this is kinda needed for the msm fix. At least the msm design relies on this split being present, so fixing it without this split here would be a pile of rather pointless work. -Daniel > Christian. > > > > >> So only Acked-by: Christian König > > Thanks, Daniel > > > >>> Cc: Lucas Stach > >>> Cc: Russell King > >>> Cc: Christian Gmeiner > >>> Cc: Qiang Yu > >>> Cc: Rob Herring > >>> Cc: Tomeu Vizoso > >>> Cc: Steven Price > >>> Cc: Alyssa Rosenzweig > >>> Cc: David Airlie > >>> Cc: Daniel Vetter > >>> Cc: Sumit Semwal > >>> Cc: "Christian König" > >>> Cc: Masahiro Yamada > >>> Cc: Kees Cook > >>> Cc: Adam Borowski > >>> Cc: Nick Terrell > >>> Cc: Mauro Carvalho Chehab > >>> Cc: Paul Menzel > >>> Cc: Sami Tolvanen > >>> Cc: Viresh Kumar > >>> Cc: Alex Deucher > >>> Cc: Dave Airlie > >>> Cc: Nirmoy Das > >>> Cc: Deepak R Varma > >>> Cc: Lee Jones > >>> Cc: Kevin Wang > >>> Cc: Chen Li > >>> Cc: Luben Tuikov > >>> Cc: "Marek Olšák" > >>> Cc: Dennis Li > >>> Cc: Maarten Lankhorst > >>> Cc: Andrey Grodzovsky > >>> Cc: Sonny Jiang > >>> Cc: Boris Brezillon > >>> Cc: Tian Tao > >&
Re: [Freedreno] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init
On Thu, Aug 5, 2021 at 3:44 PM Christian König wrote: > Am 05.08.21 um 12:46 schrieb Daniel Vetter: > > This is a very confusingly named function, because not just does it > > init an object, it arms it and provides a point of no return for > > pushing a job into the scheduler. It would be nice if that's a bit > > clearer in the interface. > > > > But the real reason is that I want to push the dependency tracking > > helpers into the scheduler code, and that means drm_sched_job_init > > must be called a lot earlier, without arming the job. > > > > v2: > > - don't change .gitignore (Steven) > > - don't forget v3d (Emma) > > > > v3: Emma noticed that I leak the memory allocated in > > drm_sched_job_init if we bail out before the point of no return in > > subsequent driver patches. To be able to fix this change > > drm_sched_job_cleanup() so it can handle being called both before and > > after drm_sched_job_arm(). > > > > Also improve the kerneldoc for this. > > > > v4: > > - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as > >usual (Melissa) > > > > - Christian pointed out that drm_sched_entity_select_rq() also needs > >to be moved into drm_sched_job_arm, which made me realize that the > >job->id definitely needs to be moved too. > > > >Shuffle things to fit between job_init and job_arm. > > > > v5: > > Reshuffle the split between init/arm once more, amdgpu abuses > > drm_sched.ready to signal gpu reset failures. Also document this > > somewhat. (Christian) > > > > v6: > > Rebase on top of the msm drm/sched support. Note that the > > drm_sched_job_init() call is completely misplaced, and hence also the > > split-out drm_sched_entity_push_job(). I've put in a FIXME which the next > > patch will address. > > > > Acked-by: Melissa Wen > > Cc: Melissa Wen > > Acked-by: Emma Anholt > > Acked-by: Steven Price (v2) > > Reviewed-by: Boris Brezillon (v5) > > Signed-off-by: Daniel Vetter > > At least the amdgpu parts look ok of hand, but I can't judge the rest I > think. The thing that really scares me here and that I got wrong a few times is the cleanup for drm_sched_job at the various points. Can you give those parts in drm/scheduler/ a full review pls, just to make sure? I can note that in the tag ofc, just like a bit more confidence here that it's not busted :-) > So only Acked-by: Christian König Thanks, Daniel > > > Cc: Lucas Stach > > Cc: Russell King > > Cc: Christian Gmeiner > > Cc: Qiang Yu > > Cc: Rob Herring > > Cc: Tomeu Vizoso > > Cc: Steven Price > > Cc: Alyssa Rosenzweig > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Sumit Semwal > > Cc: "Christian König" > > Cc: Masahiro Yamada > > Cc: Kees Cook > > Cc: Adam Borowski > > Cc: Nick Terrell > > Cc: Mauro Carvalho Chehab > > Cc: Paul Menzel > > Cc: Sami Tolvanen > > Cc: Viresh Kumar > > Cc: Alex Deucher > > Cc: Dave Airlie > > Cc: Nirmoy Das > > Cc: Deepak R Varma > > Cc: Lee Jones > > Cc: Kevin Wang > > Cc: Chen Li > > Cc: Luben Tuikov > > Cc: "Marek Olšák" > > Cc: Dennis Li > > Cc: Maarten Lankhorst > > Cc: Andrey Grodzovsky > > Cc: Sonny Jiang > > Cc: Boris Brezillon > > Cc: Tian Tao > > Cc: etna...@lists.freedesktop.org > > Cc: l...@lists.freedesktop.org > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: Emma Anholt > > Cc: Rob Clark > > Cc: Sean Paul > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedreno@lists.freedesktop.org > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 + > > drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 + > > drivers/gpu/drm/lima/lima_sched.c| 2 + > > drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++ > > drivers/gpu/drm/panfrost/panfrost_job.c | 2 + > > drivers/gpu/drm/scheduler/sched_entity.c | 6 +-- > > drivers/gpu/drm/scheduler/sched_fence.c | 19 --- > > drivers/gpu/drm/scheduler/sched_main.c | 69 > > drivers/gpu/drm/v3d/v3d_gem.c| 2 + > > include/drm/gpu_scheduler.h | 7 ++- > > 11 files changed, 94 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > index 139cd3bf1ad6..32e80bc6af22 100
[Freedreno] [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering
There's only one exclusive slot, and we must not break the ordering. Adding a new exclusive fence drops all previous fences from the dma_resv. To avoid violating the signalling order we err on the side of over-synchronizing by waiting for the existing fences, even if userspace asked us to ignore them. A better fix would be to us a dma_fence_chain or _array like e.g. amdgpu now uses, but - msm has a synchronous dma_fence_wait for anything from another context, so doesn't seem to care much, - and it probably makes sense to lift this into dma-resv.c code as a proper concept, so that drivers don't have to hack up their own solution each on their own. v2: Improve commit message per Lucas' suggestion. Cc: Lucas Stach Signed-off-by: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedreno@lists.freedesktop.org --- drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index fb5a2eab27a2..66633dfd58a2 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -330,7 +330,8 @@ static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit) return ret; } - if (no_implicit) + /* exclusive fences must be ordered */ + if (no_implicit && !write) continue; ret = drm_sched_job_add_implicit_dependencies(>base, -- 2.32.0
[Freedreno] [PATCH v5 12/20] drm/msm: Use scheduler dependency handling
drm_sched_job_init is already at the right place, so this boils down
to deleting code.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/msm/msm_gem.h| 5 -
drivers/gpu/drm/msm/msm_gem_submit.c | 19 +--
drivers/gpu/drm/msm/msm_ringbuffer.c | 12
3 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index f9e3ffb2309a..8bf0ac707fd7 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -312,11 +312,6 @@ struct msm_gem_submit {
struct ww_acquire_ctx ticket;
uint32_t seqno; /* Sequence number of the submit on the ring */
- /* Array of struct dma_fence * to block on before submitting this job.
-*/
- struct xarray deps;
- unsigned long last_dep;
-
/* Hw fence, which is created when the scheduler executes the job, and
* is signaled when the hw finishes (via seqno write from cmdstream)
*/
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 96cea0ba4cfd..fb5a2eab27a2 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
return ERR_PTR(ret);
}
- xa_init_flags(>deps, XA_FLAGS_ALLOC);
-
kref_init(>ref);
submit->dev = dev;
submit->aspace = queue->ctx->aspace;
@@ -72,8 +70,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
{
struct msm_gem_submit *submit =
container_of(kref, struct msm_gem_submit, ref);
- unsigned long index;
- struct dma_fence *fence;
unsigned i;
if (submit->fence_id) {
@@ -82,12 +78,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
mutex_unlock(>queue->lock);
}
- xa_for_each (>deps, index, fence) {
- dma_fence_put(fence);
- }
-
- xa_destroy(>deps);
-
dma_fence_put(submit->user_fence);
dma_fence_put(submit->hw_fence);
@@ -343,8 +333,9 @@ static int submit_fence_sync(struct msm_gem_submit *submit,
bool no_implicit)
if (no_implicit)
continue;
- ret = drm_gem_fence_array_add_implicit(>deps, obj,
- write);
+ ret = drm_sched_job_add_implicit_dependencies(>base,
+ obj,
+ write);
if (ret)
break;
}
@@ -588,7 +579,7 @@ static struct drm_syncobj **msm_parse_deps(struct
msm_gem_submit *submit,
if (ret)
break;
- ret = drm_gem_fence_array_add(>deps, fence);
+ ret = drm_sched_job_add_dependency(>base, fence);
if (ret)
break;
@@ -798,7 +789,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
goto out_unlock;
}
- ret = drm_gem_fence_array_add(>deps, in_fence);
+ ret = drm_sched_job_add_dependency(>base, in_fence);
if (ret)
goto out_unlock;
}
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index bd54c1412649..652b1dedd7c1 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -11,17 +11,6 @@ static uint num_hw_submissions = 8;
MODULE_PARM_DESC(num_hw_submissions, "The max # of jobs to write into
ringbuffer (default 8)");
module_param(num_hw_submissions, uint, 0600);
-static struct dma_fence *msm_job_dependency(struct drm_sched_job *job,
- struct drm_sched_entity *s_entity)
-{
- struct msm_gem_submit *submit = to_msm_submit(job);
-
- if (!xa_empty(>deps))
- return xa_erase(>deps, submit->last_dep++);
-
- return NULL;
-}
-
static struct dma_fence *msm_job_run(struct drm_sched_job *job)
{
struct msm_gem_submit *submit = to_msm_submit(job);
@@ -52,7 +41,6 @@ static void msm_job_free(struct drm_sched_job *job)
}
const struct drm_sched_backend_ops msm_sched_ops = {
- .dependency = msm_job_dependency,
.run_job = msm_job_run,
.free_job = msm_job_free
};
--
2.32.0
[Freedreno] [PATCH v5 05/20] drm/sched: drop entity parameter from drm_sched_push_job
Originally a job was only bound to the queue when we pushed this, but
now that's done in drm_sched_job_init, making that parameter entirely
redundant.
Remove it.
The same applies to the context parameter in
lima_sched_context_queue_task, simplify that too.
v2:
Rebase on top of msm adopting drm/sched
Acked-by: Emma Anholt
Acked-by: Melissa Wen
Reviewed-by: Steven Price (v1)
Reviewed-by: Boris Brezillon (v1)
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Emma Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Nirmoy Das
Cc: Dave Airlie
Cc: Chen Li
Cc: Lee Jones
Cc: Deepak R Varma
Cc: Kevin Wang
Cc: Luben Tuikov
Cc: "Marek Olšák"
Cc: Maarten Lankhorst
Cc: Andrey Grodzovsky
Cc: Dennis Li
Cc: Boris Brezillon
Cc: etna...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Rob Clark
Cc: Sean Paul
Cc: Melissa Wen
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +-
drivers/gpu/drm/lima/lima_gem.c | 3 +--
drivers/gpu/drm/lima/lima_sched.c| 5 ++---
drivers/gpu/drm/lima/lima_sched.h| 3 +--
drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 6 ++
drivers/gpu/drm/v3d/v3d_gem.c| 2 +-
include/drm/gpu_scheduler.h | 3 +--
11 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 32e80bc6af22..1d8a914108af 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1267,7 +1267,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
trace_amdgpu_cs_ioctl(job);
amdgpu_vm_bo_trace_cs(>vm, >ticket);
- drm_sched_entity_push_job(>base, entity);
+ drm_sched_entity_push_job(>base);
amdgpu_vm_move_to_lru_tail(p->adev, >vm);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 5ddb955d2315..b86099c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -174,7 +174,7 @@ int amdgpu_job_submit(struct amdgpu_job *job, struct
drm_sched_entity *entity,
*f = dma_fence_get(>base.s_fence->finished);
amdgpu_job_free_resources(job);
- drm_sched_entity_push_job(>base, entity);
+ drm_sched_entity_push_job(>base);
return 0;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 05f412204118..180bb633d5c5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -178,7 +178,7 @@ int etnaviv_sched_push_job(struct drm_sched_entity
*sched_entity,
/* the scheduler holds on to the job now */
kref_get(>refcount);
- drm_sched_entity_push_job(>sched_job, sched_entity);
+ drm_sched_entity_push_job(>sched_job);
out_unlock:
mutex_unlock(>gpu->fence_lock);
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index de62966243cd..c528f40981bb 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -359,8 +359,7 @@ int lima_gem_submit(struct drm_file *file, struct
lima_submit *submit)
goto err_out2;
}
- fence = lima_sched_context_queue_task(
- submit->ctx->context + submit->pipe, submit->task);
+ fence = lima_sched_context_queue_task(submit->task);
for (i = 0; i < submit->nr_bos; i++) {
if (submit->bos[i].flags & LIMA_SUBMIT_BO_WRITE)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 38f755580507..e968b5a8f0b0 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -177,13 +177,12 @@ void lima_sched_context_fini(struct lima_sched_pipe *pipe,
drm_sched_entity_fini(>base);
}
-struct dma_fence *lima_sched_context_queue_task(struct lima_sched_context
*context,
- struct lima_sched_task *task)
+struct dma_fence *lima_sched_context_queue_task(struct lima_sched_task *task)
{
struct dma_fence *fence = dma_fence_get(>base.s_fence->finished);
trace_lima_task_submit(task);
- drm_sched_entity_push_job(>base, >base);
+ drm_sched_entity_push_job(>base);
return fence;
}
diff --git a/drivers/gpu/drm/lima/lima_
[Freedreno] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
Originally drm_sched_job_init was the point of no return, after which
drivers must submit a job. I've split that up, which allows us to fix
this issue pretty easily.
Only thing we have to take care of is to not skip to error paths after
that. Other drivers do this the same for out-fence and similar things.
Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
Cc: Rob Clark
Cc: Rob Clark
Cc: Sean Paul
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 6d6c44f0e1f3..d0ed4ddc509e 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
return ERR_PTR(ret);
}
- /* FIXME: this is way too early */
- drm_sched_job_arm(>base);
-
xa_init_flags(>deps, XA_FLAGS_ALLOC);
kref_init(>ref);
@@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit->user_fence = dma_fence_get(>base.s_fence->finished);
+ /* point of no return, we _have_ to submit no matter what */
+ drm_sched_job_arm(>base);
+
/*
* Allocate an id which can be used by WAIT_FENCE ioctl to map back
* to the underlying fence.
@@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (submit->fence_id < 0) {
ret = submit->fence_id = 0;
submit->fence_id = 0;
- goto out;
}
- if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
+ if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
struct sync_file *sync_file =
sync_file_create(submit->user_fence);
if (!sync_file) {
ret = -ENOMEM;
- goto out;
+ } else {
+ fd_install(out_fence_fd, sync_file->file);
+ args->fence_fd = out_fence_fd;
}
- fd_install(out_fence_fd, sync_file->file);
- args->fence_fd = out_fence_fd;
}
submit_attach_object_fences(submit);
--
2.32.0
[Freedreno] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init
This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is that I want to push the dependency tracking helpers into the scheduler code, and that means drm_sched_job_init must be called a lot earlier, without arming the job. v2: - don't change .gitignore (Steven) - don't forget v3d (Emma) v3: Emma noticed that I leak the memory allocated in drm_sched_job_init if we bail out before the point of no return in subsequent driver patches. To be able to fix this change drm_sched_job_cleanup() so it can handle being called both before and after drm_sched_job_arm(). Also improve the kerneldoc for this. v4: - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as usual (Melissa) - Christian pointed out that drm_sched_entity_select_rq() also needs to be moved into drm_sched_job_arm, which made me realize that the job->id definitely needs to be moved too. Shuffle things to fit between job_init and job_arm. v5: Reshuffle the split between init/arm once more, amdgpu abuses drm_sched.ready to signal gpu reset failures. Also document this somewhat. (Christian) v6: Rebase on top of the msm drm/sched support. Note that the drm_sched_job_init() call is completely misplaced, and hence also the split-out drm_sched_entity_push_job(). I've put in a FIXME which the next patch will address. Acked-by: Melissa Wen Cc: Melissa Wen Acked-by: Emma Anholt Acked-by: Steven Price (v2) Reviewed-by: Boris Brezillon (v5) Signed-off-by: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Qiang Yu Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: Masahiro Yamada Cc: Kees Cook Cc: Adam Borowski Cc: Nick Terrell Cc: Mauro Carvalho Chehab Cc: Paul Menzel Cc: Sami Tolvanen Cc: Viresh Kumar Cc: Alex Deucher Cc: Dave Airlie Cc: Nirmoy Das Cc: Deepak R Varma Cc: Lee Jones Cc: Kevin Wang Cc: Chen Li Cc: Luben Tuikov Cc: "Marek Olšák" Cc: Dennis Li Cc: Maarten Lankhorst Cc: Andrey Grodzovsky Cc: Sonny Jiang Cc: Boris Brezillon Cc: Tian Tao Cc: etna...@lists.freedesktop.org Cc: l...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: Emma Anholt Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedreno@lists.freedesktop.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 + drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 + drivers/gpu/drm/lima/lima_sched.c| 2 + drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++ drivers/gpu/drm/panfrost/panfrost_job.c | 2 + drivers/gpu/drm/scheduler/sched_entity.c | 6 +-- drivers/gpu/drm/scheduler/sched_fence.c | 19 --- drivers/gpu/drm/scheduler/sched_main.c | 69 drivers/gpu/drm/v3d/v3d_gem.c| 2 + include/drm/gpu_scheduler.h | 7 ++- 11 files changed, 94 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 139cd3bf1ad6..32e80bc6af22 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1226,6 +1226,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, if (r) goto error_unlock; + drm_sched_job_arm(>base); + /* No memory allocation is allowed while holding the notifier lock. * The lock is held until amdgpu_cs_submit is finished and fence is * added to BOs. diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index d33e6d97cc89..5ddb955d2315 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -170,6 +170,8 @@ int amdgpu_job_submit(struct amdgpu_job *job, struct drm_sched_entity *entity, if (r) return r; + drm_sched_job_arm(>base); + *f = dma_fence_get(>base.s_fence->finished); amdgpu_job_free_resources(job); drm_sched_entity_push_job(>base, entity); diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c index feb6da1b6ceb..05f412204118 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c @@ -163,6 +163,8 @@ int etnaviv_sched_push_job(struct drm_sched_entity *sched_entity, if (ret) goto out_unlock; + drm_sched_job_arm(>sched_job); + submit->out_fence = dma_fence_get(>sched_job.s_fence->finished); submit->out_fence_id = idr_alloc_cyclic(>gpu->fence_idr, submit->out_fence, 0, diff --g
Re: [Freedreno] [early pull] drm/msm: drm-msm-next-2021-07-28 for v5.15
On Wed, Jul 28, 2021 at 01:52:42PM -0700, Rob Clark wrote: > Hi Dave & Daniel, > > An early pull for v5.15 (there'll be more coming in a week or two), > consisting of the drm/scheduler conversion and a couple other small > series that one was based one. Mostly sending this now because IIUC > danvet wanted it in drm-next so he could rebase on it. (Daniel, if > you disagree then speak up, and I'll instead include this in the main > pull request once that is ready.) I like, but might be some time until I managed to rebase it all and adjust msm too. Thanks for doing the early pull. -Daniel > > This also has a core patch to drop drm_gem_object_put_locked() now > that the last use of it is removed. > > The following changes since commit ff1176468d368232b684f75e82563369208bc371: > > Linux 5.14-rc3 (2021-07-25 15:35:14 -0700) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2021-07-28 > > for you to fetch changes up to 4541e4f2225c30b0e9442be9eb2fb8b7086cdd1f: > > drm/msm/gem: Mark active before pinning (2021-07-28 09:19:00 -0700) > > > Rob Clark (18): > drm/msm: Let fences read directly from memptrs > drm/msm: Signal fences sooner > drm/msm: Split out devfreq handling > drm/msm: Split out get_freq() helper > drm/msm: Devfreq tuning > drm/msm: Docs and misc cleanup > drm/msm: Small submitqueue creation cleanup > drm/msm: drop drm_gem_object_put_locked() > drm: Drop drm_gem_object_put_locked() > drm/msm/submit: Simplify out-fence-fd handling > drm/msm: Consolidate submit bo state > drm/msm: Track "seqno" fences by idr > drm/msm: Return ERR_PTR() from submit_create() > drm/msm: Conversion to drm scheduler > drm/msm: Drop submit bo_list > drm/msm: Drop struct_mutex in submit path > drm/msm: Utilize gpu scheduler priorities > drm/msm/gem: Mark active before pinning > > drivers/gpu/drm/drm_gem.c | 22 -- > drivers/gpu/drm/msm/Kconfig | 1 + > drivers/gpu/drm/msm/Makefile| 1 + > drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +- > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- > drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +- > drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +- > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +- > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +- > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +- > drivers/gpu/drm/msm/msm_drv.c | 30 ++- > drivers/gpu/drm/msm/msm_fence.c | 53 + > drivers/gpu/drm/msm/msm_fence.h | 44 +++- > drivers/gpu/drm/msm/msm_gem.c | 94 +--- > drivers/gpu/drm/msm/msm_gem.h | 47 ++-- > drivers/gpu/drm/msm/msm_gem_submit.c| 344 > +--- > drivers/gpu/drm/msm/msm_gpu.c | 220 -- > drivers/gpu/drm/msm/msm_gpu.h | 139 ++- > drivers/gpu/drm/msm/msm_gpu_devfreq.c | 203 > drivers/gpu/drm/msm/msm_rd.c| 6 +- > drivers/gpu/drm/msm/msm_ringbuffer.c| 69 +- > drivers/gpu/drm/msm/msm_ringbuffer.h| 12 + > drivers/gpu/drm/msm/msm_submitqueue.c | 53 +++-- > include/drm/drm_gem.h | 2 - > include/uapi/drm/msm_drm.h | 14 +- > 26 files changed, 865 insertions(+), 536 deletions(-) > create mode 100644 drivers/gpu/drm/msm/msm_gpu_devfreq.c -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
