On Thu, Aug 29, 2024 at 01:48:34PM -0700, Jessica Zhang wrote:
> If the clone mode enabled status is changing, a modeset needs to happen
> so that the resources can be reassigned
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++
> 1 file changed, 6 ins
| 23 +
> include/linux/soc/qcom/smem.h |1 +
> include/linux/soc/qcom/socinfo.h | 34 +
> include/uapi/drm/msm_drm.h |1 +
> 71 files changed, 4011 insertions(+), 2470 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
> create mode 100644 drivers/gpu/drm/msm/adreno/a2xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a3xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a4xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a5xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jun 27, 2024 at 02:54:57AM +0530, Akhil P Oommen wrote:
> On Wed, Jun 26, 2024 at 09:59:39AM +0200, Daniel Vetter wrote:
> > On Tue, Jun 25, 2024 at 08:54:41PM +0200, Konrad Dybcio wrote:
> > > Memory barriers help ensure instruction ordering, NOT time and order
>
27;s make extra sure that the GPU can access the memory.. */
> - mb();
> + gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
> }
>
> /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
>
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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:
> > >
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,
s, 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
> &
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 commi
ruct dma_fence *msm_job_run(struct drm_sched_job
> *job)
>
> mutex_unlock(&priv->lru.lock);
>
> + /* TODO move submit path over to using a per-ring lock.. */
> + mutex_lock(&gpu->lock);
> +
> msm_gpu_submit(gpu, submit);
>
> + mutex_unlock(&gpu->lock);
> +
> return dma_fence_get(submit->hw_fence);
> }
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
.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
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: d
igned-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
d 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 me
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
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:
> &g
> + 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
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:
> > >>
&g
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
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, A
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:
> > > >
> > > >
date 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 +
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:
> > >
gt; > >* 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(&p, file);
> > > +
> > > + print_memory_stats(&p, 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
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
> + 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
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:
> > > >
> >
_RESIDENT) {
> + size.resident += obj->size;
> + } else {
> + /* If already purged or not yet backed by pages, don't
> + * count it as purgeable:
> + */
> + s
o = 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 = &fops,
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
> inde
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/drive
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:
> > > &
ion/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
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
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-mis
--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
.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
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
> > > >
dline.
> >
> > 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/dr
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
> >
_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 a
hino 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.or
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, 202
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:
> > >
c0/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(+)
>
> 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
t; @@ -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 mand
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,
p/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
kanti
> 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
BMIT_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
_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 |
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
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:
> > >
-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
t;>>>>>>> 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
; > + *
> > > > + * 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
,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
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:
> > > >
> >
east 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
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(&msm_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(&msm_obj->base));
> > if (!is_vunmapable(msm_obj))
> > return false;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
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
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, 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:
> >
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(&obj->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
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
> &
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
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 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:
> > > >
> &
pts/ 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
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:
> > >
t; > > b/drivers/gpu/drm/msm/ci/msm_sdm845_results.txt
> > > new file mode 100644
> > >
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
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
gt; > * 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
;
> }
> +
> +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
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
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 m
| 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
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.
e 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 mode
andle 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
> }
>
> 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
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
t; 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 = &gpu->devfreq;
> + unsigned long freq;
> +
> + /*
> + * Hold devfreq lock to synchronize with get_dev_status()/
> + * target() callbacks
> + */
> + mutex_lock(&df->devfreq->lock);
> +
> + freq = get_freq(gpu);
> +
> + freq *= factor;
> +
> + msm_devfreq_target(&gpu->pdev->dev, &freq, 0);
> +
> + mutex_unlock(&df->devfreq->lock);
> +}
> +
> void msm_devfreq_active(struct msm_gpu *gpu)
> {
> struct msm_gpu_devfreq *df = &gpu->devfreq;
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
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: "Chri
.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_s
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
&
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/
ich 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)
Sign
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 &drm_sched_fence.finished which
> > +* potentially needs to be propagated to &drm_sched_fence.parent
> > +*/
> > + ktime_t deadline;
> > +
> > /**
> >* @parent: the fence returned by &drm_sched_backend_ops.run_job
> >* when scheduling the job on hardware. We signal the
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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)
>
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: "Chri
glog, 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;
> MO
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:
> > &g
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:
> > > &g
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
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 n
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 schedu
t, 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
---
1 - 100 of 384 matches
Mail list logo
