ed unconditionally. Also I think locking that's only
conditional on Kconfig is just a bit too suprising to be a good idea
irrespective of this specific case.
-Sima
>
> Best regards,
>
> --
>
> Jocelyn
>
> On 01/03/2024 11:39, Daniel Vetter wrote:
> > Roug
On Tue, Mar 05, 2024 at 09:20:04AM +0106, John Ogness wrote:
> Hi Daniel,
>
> Great to see this moving forward!
>
> On 2024-03-01, Daniel Vetter wrote:
> > But for the initial cut of a drm panic printing support I don't think
> > we need that, because the criti
ls to point to the
> main one.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
Directly applied to drm-fixes as requested on irc.
-Sima
> ---
> .mailmap| 5 +
> MAINTA
m/
Note that the locking is very much not correct there, hence this
separate rfc.
v2:
- fix authorship, this was all my typing
- some typo oopsies
- link to the drm panic work by Jocelyn for context
Signed-off-by: Daniel Vetter
Cc: Jocelyn Falempe
Cc: Andrew Morton
Cc: "Peter Zijlstra
hang the memory
controller on some hw).
Signed-off-by: Daniel Vetter
Cc: Jocelyn Falempe
Cc: Andrew Morton
Cc: "Peter Zijlstra (Intel)"
Cc: Lukas Wunner
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: John Ogness
Cc: Sergey Senozhatsky
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas
", NULL);
> +
> + if (IS_ERR(debug_dir))
> + return PTR_ERR(debug_dir);
> + debug_trigger = debugfs_create_file("trigger", 0200, debug_dir,
> + NULL, &dbg_drm_panic_ops);
> + return 0;
> +}
> +
> +static void __exit debugfs_end(void)
> +{
> + debugfs_remove_recursive(debug_dir);
> +}
> +
> +module_init(debugfs_start);
> +module_exit(debugfs_end);
> +
> +#endif
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
in
in drm_dev_unregister(). Outside of these functions it is not safe to call
into driver code.
At that point it might be simpler to only register one panic notifier per
drm_device, and push the loop into the panic handler again.
Cheers, Sima
> + simpledrm_init_panic_buffer(primary_plane);
>
> /* CRTC */
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t
a joke/test/demo hack" for me.
I think some weston (or whatever compositor you like) config file support
to set a bunch of "really only way to configure is by hand" output
properties would clear the bar here for me. Because that is a feature I
already mentioned that xrandr _does_ have, and which modetest hackery very
much does not.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Feb 28, 2024 at 01:49:34PM -0800, Jessica Zhang wrote:
>
>
> On 2/2/2024 2:15 AM, Maxime Ripard wrote:
> > On Tue, Jan 30, 2024 at 09:53:13AM +0100, Daniel Vetter wrote:
> > > > > > > > Wouldn't it be simpler if we had a vkms-like
| 16 +
> include/uapi/drm/drm_mode.h | 14 +
> 38 files changed, 3882 insertions(+), 30 deletions(-)
> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
> create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.h
> create mode 100644 drivers/gpu/drm/drm_colorop.c
> create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c
> create mode 100644 drivers/gpu/drm/vkms/Kconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h
> create mode 100644 include/drm/drm_colorop.h
>
> --
> 2.44.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Feb 28, 2024 at 01:13:45PM +0200, Laurent Pinchart wrote:
> On Wed, Feb 28, 2024 at 11:41:57AM +0100, Jacopo Mondi wrote:
> > On Tue, Feb 27, 2024 at 03:08:27PM +0200, Laurent Pinchart wrote:
> > > On Mon, Feb 26, 2024 at 04:46:24PM +0100, Daniel Vetter wrote:
> >
On Tue, Feb 27, 2024 at 03:10:06PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 26, 2024 at 05:24:41PM +0100, Jacopo Mondi wrote:
> > On Mon, Feb 26, 2024 at 04:46:24PM +0100, Daniel Vetter wrote:
> > > On Mon, 26 Feb 2024 at 16:39, Jacopo Mondi wrote:
> > > >
m/tegra.git#for-next
> https://gitlab.freedesktop.org/lumag/msm.git#msm-next-lumag
>
> If someone could just send me all the new equivalent URLs when the
> change happens, I will fix them up in my config.
>
> --
> Cheers,
> Stephen Rothwell
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
truct drm_sched_fence), 0,
> - SLAB_HWCACHE_ALIGN, NULL);
> + sched_fence_slab = KMEM_CACHE(drm_sched_fence, SLAB_HWCACHE_ALIGN);
> if (!sched_fence_slab)
> return -ENOMEM;
>
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
request a
> drm-misc access. It will all go through Gitlab now, so it will change a
> few things. We will also need to update and move the issue template to
> the new repo to maintain consistency.
>
> I would expect the transition (if everything goes smoothly) to occur in
> the merge-window time frame (11/03 -> 24/03).
>
> Let me know if you have any questions, or if there's anything we missed,
> Maxime
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; implemented both on the kernel side and for the aforementioned gputop /
> > igt_drm_fdinfo / igt_drm_clients. Where and how exactly TBD.
>
> As soon as the new patch is merged, I'll go and reflect the driver uAPI
> changes
> in all three of these.
Would be good (and kinda p
s!
-Sima
>
> On Tue, Feb 06, 2024 at 03:07:47PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 01, 2024 at 10:42:56PM -0800, Shradha Gupta wrote:
> > > This patchset consists of sanity checks before enabling/disabling
> > > output polling to make sure we do not call poll
x27;old_userfont' and not 'old_data' as the
> latter is always set now. (And it is supposed to be non-NULL. Otherwise
> we would see the bug above again.)
>
> Signed-off-by: Jiri Slaby (SUSE)
> Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_re
8
> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0b
>
> /* add more to the end as needed */
>
> @@ -1568,6 +1569,10 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
> modifier)
> #define A
ps://anongit.freedesktop.org/git/drm/drm
> -https://anongit.freedesktop.org/git/drm/drm.git
> +https://gitlab.freedesktop.org/drm/kernel.git
> +ssh://g...@gitlab.freedesktop.org:drm/kernel.git
> "
> drm_tip_repos[linux-upstream]="
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> --
> 2.43.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, 26 Feb 2024 at 16:21, Maxime Ripard wrote:
>
> Now that the main DRM tree has moved to Gitlab, adjust the MAINTAINERS
> git trees to reflect the location change.
>
> Signed-off-by: Maxime Ripard
Acked-by: Daniel Vetter
> ---
> MAINTAINERS | 4 ++--
> 1 fi
; git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#for-linux-next
> https://gitlab.freedesktop.org/agd5f/linux#drm-next
> https://gitlab.freedesktop.org/drm/msm.git#msm-next
> https://gitlab.freedesktop.org/drm/tegra.git#for-next
> https://gitlab.freedesktop.org/lumag
rivers/accel/habanalabs/gaudi/gaudi.c | 9 +-
> drivers/accel/habanalabs/gaudi2/gaudi2.c | 308 ++++--
> drivers/accel/habanalabs/gaudi2/gaudi2P.h | 15 +-
> drivers/accel/habanalabs/goya/goya.c | 12 +-
> drivers/accel/habanalabs/goya/goya_coresight.c | 3 +-
> .../habanalabs/include/hw_ip/mmu/mmu_general.h | 2 +
> 21 files changed, 1008 insertions(+), 510 deletions(-)
> create mode 100644 drivers/accel/habanalabs/common/mmu/mmu_v2.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 8 +-
> drivers/gpu/drm/xe/xe_tuning.c | 9 +-
> drivers/gpu/drm/xe/xe_uc.c | 33 +-
> drivers/gpu/drm/xe/xe_uc.h | 1 +
> drivers/gpu/drm/xe/xe_uc_fw.c | 60 +-
> drivers/gpu/drm/xe/xe_uc_fw_types.h| 9 +-
> drivers/gpu/drm/xe/xe_vm.c | 287 ++-
> drivers/gpu/drm/xe/xe_vm.h | 7 +-
> drivers/gpu/drm/xe/xe_vm_types.h | 18 +-
> drivers/gpu/drm/xe/xe_vram_freq.c | 128 +++
> drivers/gpu/drm/xe/xe_vram_freq.h | 13 +
> drivers/gpu/drm/xe/xe_wa.c | 191 +
> drivers/gpu/drm/xe/xe_wa_oob.rules | 12 +-
> drivers/gpu/drm/xe/xe_wait_user_fence.c| 2 +-
> drivers/gpu/drm/xe/xe_wopcm_types.h| 4 +-
> include/uapi/drm/xe_drm.h | 34 +-
> 141 files changed, 6518 insertions(+), 1187 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/abi/gsc_proxy_commands_abi.h
> create mode 100644 drivers/gpu/drm/xe/abi/guc_actions_sriov_abi.h
> create mode 100644 drivers/gpu/drm/xe/abi/guc_relay_actions_abi.h
> create mode 100644 drivers/gpu/drm/xe/abi/guc_relay_communication_abi.h
> rename drivers/gpu/drm/xe/{ => display}/xe_display.c (99%)
> rename drivers/gpu/drm/xe/{ => display}/xe_display.h (100%)
> create mode 100644 drivers/gpu/drm/xe/regs/xe_pcode_regs.h
> create mode 100644 drivers/gpu/drm/xe/tests/xe_guc_db_mgr_test.c
> create mode 100644 drivers/gpu/drm/xe/tests/xe_guc_relay_test.c
> create mode 100644 drivers/gpu/drm/xe/tests/xe_kunit_helpers.c
> create mode 100644 drivers/gpu/drm/xe/tests/xe_kunit_helpers.h
> create mode 100644 drivers/gpu/drm/xe/tests/xe_test_mod.c
> create mode 100644 drivers/gpu/drm/xe/xe_gsc_proxy.c
> create mode 100644 drivers/gpu/drm/xe/xe_gsc_proxy.h
> create mode 100644 drivers/gpu/drm/xe/xe_gt_sriov_printk.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_db_mgr.c
> create mode 100644 drivers/gpu/drm/xe/xe_guc_db_mgr.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_hxg_helpers.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_relay.c
> create mode 100644 drivers/gpu/drm/xe/xe_guc_relay.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_relay_types.h
> create mode 100644 drivers/gpu/drm/xe/xe_memirq.c
> create mode 100644 drivers/gpu/drm/xe/xe_memirq.h
> create mode 100644 drivers/gpu/drm/xe/xe_memirq_types.h
> create mode 100644 drivers/gpu/drm/xe/xe_vram_freq.c
> create mode 100644 drivers/gpu/drm/xe/xe_vram_freq.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
> create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83112a.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/Kconfig
> create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 16, 2024 at 05:51:59PM +0100, Christian König wrote:
> Am 16.02.24 um 17:32 schrieb Daniel Vetter:
> > On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> > > This new event can be used to trace where a given dma_fence is added
> > &
On Fri, Feb 16, 2024 at 06:04:43PM +0100, Daniel Vetter wrote:
> On Thu, Feb 15, 2024 at 06:11:16PM +0800, Hsiao Chien Sung wrote:
> > Register CRC related function pointers to support
> > CRC retrieval.
> >
> > Signed-off-by: Hsiao Chien Sung
> > ---
> >
atomic_t current_memory_agp;
> atomic_t agp_in_use;
> --
> 2.43.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
const u32 *ofs;
> + u32 rst_ofs;
> + u32 rst_msk;
> + size_t cnt;
> + u32 *va;
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + dma_addr_t pa;
> + u32 cmdq_event;
> + struct cmdq_client_reg *cmdq_reg;
> + struct cmdq_client cmdq_client;
> + struct cmdq_pkt cmdq_handle;
> +#endif
> +};
> +
> +void mtk_drm_crc_init(struct mtk_drm_crc *crc,
> + const u32 *crc_offset_table, size_t crc_count,
> + u32 reset_offset, u32 reset_mask);
> +void mtk_drm_crc_read(struct mtk_drm_crc *crc, void __iomem *reg);
> +void mtk_drm_crc_destroy(struct mtk_drm_crc *crc);
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +void mtk_drm_crc_cmdq_create(struct device *dev, struct mtk_drm_crc *crc);
> +void mtk_drm_crc_cmdq_start(struct mtk_drm_crc *crc);
> +void mtk_drm_crc_cmdq_stop(struct mtk_drm_crc *crc);
> +#endif
> +
> void mtk_drm_crtc_commit(struct drm_crtc *crtc);
> int mtk_drm_crtc_create(struct drm_device *drm_dev,
> const unsigned int *path,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 215b7234ff13c..231017470607e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -87,6 +87,9 @@ struct mtk_ddp_comp_funcs {
> void (*remove)(struct device *dev, struct mtk_mutex *mutex);
> unsigned int (*encoder_index)(struct device *dev);
> enum drm_mode_status (*mode_valid)(struct device *dev, const struct
> drm_display_mode *mode);
> + size_t (*crc_cnt)(struct device *dev);
> + u32 *(*crc_entry)(struct device *dev);
> + void (*crc_read)(struct device *dev);
> };
>
> struct mtk_ddp_comp {
> --
> 2.18.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; drivers/gpu/drm/panfrost/panfrost_drv.c | 5 -
> > drivers/gpu/drm/panfrost/panfrost_job.c | 24 -
> > drivers/gpu/drm/panfrost/panfrost_job.h | 1 -
> > 7 files changed, 9 insertions(+), 59 deletions(-)
> > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
> > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
> >
> >
> > base-commit: 6b1f93ea345947c94bf3a7a6e668a2acfd310918
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Feb 12, 2024 at 01:27:57PM +0200, Jani Nikula wrote:
> On Sat, 10 Feb 2024, Mario Limonciello wrote:
> > On 2/9/2024 12:57, Daniel Vetter wrote:
> >> On Fri, Feb 09, 2024 at 09:34:13AM -0600, Mario Limonciello wrote:
> >>> On 2/9/2024 05:07, Daniel Vette
On Tue, Feb 13, 2024 at 06:39:20PM +0100, Danilo Krummrich wrote:
> On 2/9/24 19:52, Daniel Vetter wrote:
> > On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote:
> > > On 2/6/24 15:03, Daniel Vetter wrote:
> > > > On Mon, Feb 05, 2024 at 11:00:04PM
; > + trace_drm_mode_atomic_commit(file_priv, crtcs, num_crtcs,
> > arg->flags);
> > +
> > + kfree(crtcs);
> > + }
> > +
> > ret = prepare_signaling(dev, state, arg, file_priv, &fence_state,
> > &num_fences);
> > if (ret)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; +
> +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
> +
> + TP_PROTO(struct dma_fence *fence, const char *reason),
> +
> + TP_ARGS(fence, reason)
> +);
> +
> #endif /* _TRACE_DMA_FENCE_H */
>
> /* This part must be outside protection */
> --
> 2.40.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
mdgpu_umsch_mm.c | 4 +--
> drivers/gpu/drm/drm_atomic_uapi.c | 19 +++
> drivers/gpu/drm/drm_trace.h | 28 +--
> include/trace/events/dma_fence.h | 34 +++
> 14 files changed, 144 insertions(+), 26 deletions(-)
>
> --
> 2.40.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
num_connectors = 0;
I think it'd be neater to have all these right below the
DRM_MODESET_LOCK_A_BEGIN instead of duplicated here and at the beginning
of the function. But it's a bit a bikeshed and in some cases (when you use
it later on) gcc might get pissed too. So either way:
On Sat, Feb 10, 2024 at 12:06:58AM +0530, Arunpravin Paneer Selvam wrote:
> Hi Daniel,
>
> On 2/9/2024 11:34 PM, Daniel Vetter wrote:
> > On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
> > > Few users have observed display corruption when they b
On Fri, Feb 09, 2024 at 09:34:13AM -0600, Mario Limonciello wrote:
> On 2/9/2024 05:07, Daniel Vetter wrote:
> > On Thu, Feb 08, 2024 at 11:57:11AM +0200, Jani Nikula wrote:
> > > On Wed, 07 Feb 2024, Mario Limonciello wrote:
> > > > Some manufacturers have intentio
On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote:
> On 2/6/24 15:03, Daniel Vetter wrote:
> > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote:
> > > On 2/5/24 22:08, Dave Airlie wrote:
> > > > On Tue, 6 Feb 2024 at
9,12 @@ static int __alloc_range(struct drm_buddy *mm,
> } while (1);
>
> list_splice_tail(&allocated, blocks);
> +
> + if (total_allocated < size) {
> + err = -ENOSPC;
> + goto err_free;
> + }
> +
> return 0;
>
> err_undo:
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
stom - Read EDID data using given EDID block read
> > function
> > * @connector: Connector to use
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 7923bc00dc7a..ca41be289fc6 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -410,6 +410,7 @@ struct edid *drm_do_get_edid(struct drm_connector
> > *connector,
> > void *data);
> > struct edid *drm_get_edid(struct drm_connector *connector,
> > struct i2c_adapter *adapter);
> > +const struct drm_edid *drm_get_acpi_edid(struct drm_connector *connector);
>
> There's a comment
>
> /* Interface based on struct drm_edid */
>
> towards the end of the file, gathering all the new API under it.
>
> Other than that, LGTM,
>
> BR,
> Jani.
>
> > u32 drm_edid_get_panel_id(struct i2c_adapter *adapter);
> > struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> > struct i2c_adapter *adapter);
>
> --
> Jani Nikula, Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote:
> On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote:
> > On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote:
> > > The component helper functions are the glue, which is used to bind
> > &g
On Tue, Feb 06, 2024 at 07:42:49PM +0100, Christian König wrote:
> Am 06.02.24 um 15:29 schrieb Daniel Vetter:
> > On Fri, Feb 02, 2024 at 03:40:03PM -0800, Greg Kroah-Hartman wrote:
> > > On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote:
> > > > Removi
On Thu, Feb 08, 2024 at 09:16:50AM +0800, Daniel van Vugt wrote:
> On 8/2/24 04:21, Mario Limonciello wrote:
> > On 2/7/2024 03:51, Daniel Vetter wrote:
> >> On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
> >>> On 6/2/24 23:41, Mario Limonciello w
t handles things directly in the VM binding
> > code.
> >
> > Is this just different thinking at different times here?
> > like since we have VM BIND in xe, it made sense not to bother creating
> > a gem object for userptrs?
> > or is there some other advantages to going one way or the other?
> >
> > Dave.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
hment when
CONFIG_DMA_API_DEBUG is enabled.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Paul Cercueil
---
Entirely untested, but since I sent the mail with the idea I figured I
might as wel
mabuf_ops = {
> .vunmap= vunmap_udmabuf,
> .begin_cpu_access = begin_cpu_udmabuf,
> .end_cpu_access= end_cpu_udmabuf,
> + .begin_access = begin_udmabuf,
> + .end_access= end_udmabuf,
> };
>
> #define SEALS_WANTED (F_SEAL_SHRINK)
>
On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
> On 6/2/24 23:41, Mario Limonciello wrote:
> > On 2/6/2024 08:21, Daniel Vetter wrote:
> >> On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel van Vugt wrote:
> >>> Until now, deferred console takeover o
t; + return 0;
> +}
> +
> +static void etnaviv_pci_remove(struct pci_dev *pdev)
> +{
> + struct device *dev = &pdev->dev;
> +
> + component_master_del(dev, &etnaviv_master_ops);
> +
> + device_for_each_child(dev, NULL, platform_device_remove_callback);
> +
> + pci_clear_master(pdev);
> +}
> +
> +static const struct pci_device_id etnaviv_pci_id_lists[] = {
> + {0x0731, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, JM9100},
> + {0x0731, 0x9230, PCI_ANY_ID, PCI_ANY_ID, 0, 0, JD9230P},
> + {0x0709, 0x0001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GP102},
> + {0x0014, 0x7A15, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GC1000_IN_LS7A1000},
> + {0x0014, 0x7A05, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GC1000_IN_LS2K1000},
> + { }
> +};
> +
> +static struct pci_driver etnaviv_pci_driver = {
> + .name = "etnaviv",
> + .id_table = etnaviv_pci_id_lists,
> + .probe = etnaviv_pci_probe,
> + .remove = etnaviv_pci_remove,
> +};
> +
> +int etnaviv_register_pci_driver(void)
> +{
> + return pci_register_driver(&etnaviv_pci_driver);
> +}
> +
> +void etnaviv_unregister_pci_driver(void)
> +{
> + pci_unregister_driver(&etnaviv_pci_driver);
> +}
> +
> +MODULE_DEVICE_TABLE(pci, etnaviv_pci_id_lists);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h
> new file mode 100644
> index ..1db559ee5e9b
> --- /dev/null
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __ETNAVIV_PCI_DRV_H__
> +#define __ETNAVIV_PCI_DRV_H__
> +
> +#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER
> +
> +int etnaviv_register_pci_driver(void);
> +void etnaviv_unregister_pci_driver(void);
> +
> +#else
> +
> +static inline int etnaviv_register_pci_driver(void) { return 0; }
> +static inline void etnaviv_unregister_pci_driver(void) { }
> +
> +#endif
> +
> +#endif
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
through cracks, I'm assuming you'll
push this to drm-misc-next too, right?
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
IGBUS
on dma-buf mmaps is no-go for drm drivers, because it would break way too
much userspace in ways which are simply not fixable (since sig handlers
are shared in a process, which means the gl/vk driver cannot use it).
Otherwise it's bog standard "fix the kernel bugs" work, just a lot
ndif
> @@ -3417,8 +3447,12 @@ void __exit fb_console_exit(void)
> {
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> console_lock();
> - if (deferred_takeover)
> + if (deferred_takeover) {
> dummycon_unregister_output_notifier(&fbcon_output_nb);
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
> + dummycon_unregister_switch_notifier(&fbcon_switch_nb);
> +#endif
> + }
> console_unlock();
>
> cancel_work_sync(&fbcon_deferred_takeover_work);
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
: Check output polling initialized before disabling
> drm: Check polling initialized before enabling in
> drm_helper_probe_single_connector_modes
On the series:
Reviewed-by: Daniel Vetter
>
> drivers/gpu/drm/drm_modeset_helper.c | 19 ---
> drivers/gpu/drm/drm_
On Tue, Feb 06, 2024 at 02:28:35PM +0100, Christian König wrote:
> Am 31.01.24 um 10:07 schrieb Daniel Vetter:
> > On Tue, Jan 30, 2024 at 02:09:45PM +0100, Christian König wrote:
> > > Am 30.01.24 um 11:40 schrieb Daniel Vetter:
> > > > On Tue, Jan 30, 2024 at 1
I lost track) then I think you won't get any splats
because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to
infinity to not matter.
I'm not sure we should care differently, but I guess it'd be good to
annotate it all in case the wq subsystem's idea of how much such deadlocks
are real changes.
Also Teo is on a mission to get rid of all the global wq flushes, so there
should also be no source of deadlocks from that kind of cross-driver
dependency. Or at least shouldn't be in the future, I'm not sure it all
landed.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
?
> >
> > something like mgag200.force_cache_flush=1 or mgag200.low_latency=1 ?
>
> I think we should either add a config option or command line parameter here.
Yeah I think the situation is cursed enough that we need that, and module
option for mgag200 sounds like the most reasonable way.
> I'd don't think adding nopat to the kernel command line is a good
> suggestion in the long run, servers often have other cards plugged
> into them like nvidia gpus or rdma etc, you don't want to cripple them
> because you want reduced latency on the crappy on-board.
>
> I'd rather we put the default back to what it used to be, which was
> flush the cache though, I'm not sure why we have any objection to
> doing that, it used to work, it was clearly fine in operation, why
> undo it?
Uh that default is a few patches back and I think it's not great if we
change that, since it means all drivers using shadow buffers for fdbev
will again suffer from rendering fbcon into a wc instead of wb buffer.
But Jocelyn has meanwhile dug out more info in another reply, I'll reply
there.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/ _=> need-resched
> # | / _---=> hardirq/softirq
> # || / _--=> preempt-depth
> # ||| / _-=> migrate-disable
> # / delay
> # TASK-PID CPU# | TIMESTAMP FUNCTION
> # | | | | | |
><...>-8983[001] d 534.595415: #1 inner/outer(us):
> 21/20ts:1702024432.844243126 count:3018
><...>-8983[000] dn... 758.560453: #2 inner/outer(us):
> 21/21ts:1702024656.824367474 count:22238
><...>-8983[000] dn... 815.117057: #3 inner/outer(us):
> 21/21ts:1702024713.373220580 count:26455
>
>
> V6.6 + no Write Combine for VRAM (<10us latency)
>
> # tracer: hwlat
> #
> # entries-in-buffer/entries-written: 0/0 #P:56
> #
> #_-=> irqs-off/BH-disabled
> # / _=> need-resched
> # | / _---=> hardirq/softirq
> # || / _--=> preempt-depth
> # ||| / _-=> migrate-disable
> # / delay
> # TASK-PID CPU# | TIMESTAMP FUNCTION
> # | | | | | |
>
>
> Best regards,
>
> --
>
> Jocelyn
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 31, 2024 at 05:22:26PM +, Matt Coster wrote:
> On 25/01/2024 18:44, Daniel Vetter wrote:
> > On Tue, Jan 23, 2024 at 01:04:24PM +, Matt Coster wrote:
> >> From: Donald Robson
> >>
> >> When the kernel driver 'loses' the d
On Tue, Jan 30, 2024 at 07:03:02PM -0800, Matthew Brost wrote:
> Add Matthew Brost to DRM scheduler maintainers.
>
> Cc: Luben Tuikov
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Christian König
> Signed-off-by: Matthew Brost
Definitely need more people taking care of
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:
> > >
that we didn't really make friends with that among core kernel
maintainers. It's a bit too much just a tech demo to be able to merge the
hmm core apis for nvidia's out-of-tree driver.
Also, a few years of learning and experience gaining happened meanwhile -
you always have to loo
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,
On Tue, Jan 30, 2024 at 02:09:45PM +0100, Christian König wrote:
> Am 30.01.24 um 11:40 schrieb Daniel Vetter:
> > On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil wrote:
> > > Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
> > > > I would
On Tue, Jan 30, 2024 at 12:10:31PM +0100, Daniel Vetter wrote:
> On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
> > As vram objects don't have backing pages and thus can't implement
> > drm_gem_object_funcs.get_sg_table callback. This removes drm
_bo export
case, which your patch seems to do? Or maybe I'm just extremely confused.
-Sima
>
> static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
> @@ -83,7 +115,7 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops
> = {
> .vmap = drm_gem_dmabuf_vmap,
> .vunmap = drm_gem_dmabuf_vunmap,
> },
> - .device_attach = drm_gem_map_attach,
> + .device_attach = virtgpu_gem_device_attach,
> .get_uuid = virtgpu_virtio_get_uuid,
> };
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; @@ -1438,6 +1466,7 @@ static const struct drm_plane_funcs dm_plane_funcs = {
> .atomic_duplicate_state = amdgpu_dm_plane_drm_plane_duplicate_state,
> .atomic_destroy_state = amdgpu_dm_plane_drm_plane_destroy_state,
> .format_mod_supported = amdgpu_dm_plane_format_mod_supported,
> + .check_async_props = amdgpu_dm_plane_check_async_props,
> };
>
> int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ddr_t +
len you have above).
The part I don't expect to ever happen, because it hasn't the past 20 or
so years, is that the dma-api will give us information about what is
needed to keep the buffers coherency between various devices and the cpu.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jan 30, 2024 at 10:23:03AM +0100, Christian König wrote:
> Am 30.01.24 um 10:01 schrieb Daniel Vetter:
> > On Fri, Jan 26, 2024 at 05:42:50PM +0100, Christian König wrote:
> > > [SNIP]
> > > Well I think we should have some solution, but I'm not sure if i
On Fri, Jan 26, 2024 at 05:42:50PM +0100, Christian König wrote:
> Am 25.01.24 um 19:01 schrieb Daniel Vetter:
> > On Thu, Jan 25, 2024 at 04:00:16PM +0100, Christian König wrote:
> > > Am 24.01.24 um 11:58 schrieb Paul Cercueil:
> > > > [SNIP]
> &g
ize different pieces of
> > > the panel. Lets talk about the customizable pieces:
> > >
> > > 1) Display resolution with timings (drm_display_mode)
> > > 2) Compression/non-compression
> > > 3) Command mode/Video mode
> > > 4) MIPI mode flags
> > > 5) DCS commands for panel enable/disable and other panel sequences
> > > 6) Power-up/Power-down sequence for the panel
> > >
> > > Without a physical panel, yes its hard to validate if anything is wrong
> > > with
> > > (4) OR (5), the display might not come up at all visually. But from our
> > > experience, thats only a small portion and the real benefit of this
> > > framework will actually be from the validation failures we will catch from
> > > (1) to (4).
> > >
> > > This RFC only provides a way to customize (1) at the moment as we wanted
> > > to
> > > get some feedback from the community about the best way which will work
> > > for
> > > everyone to customize all these parameters.
> > >
> > > We are willing to expand this series based on the generic way we agree on
> > > to
> > > customize other params.
> > >
> > > Yes, debugfs is an option too. But typically MIPI displays need some
> > > parameters configured to attach the panel to the encoder. So perhaps we
> > > can
> > > boot the simulation panel with a default resolution passed through command
> > > line and then across a modeset switch (1) to (4).
> >
> > I think Jani's feeling was that it was going to be super complicated
> > fairly fast so supporting more features would definitely help to get an
> > idea of where this is going.
> >
> > Maxime
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
can get, and link between all the related concepts and functions in the
kerneldoc.
Some overview flow like Boris sketched above in a DOC: section would also
be great.
Cheers, Sima
>
> > */
> > int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jan 26, 2024 at 07:43:29PM +0300, Dmitry Osipenko wrote:
> On 1/26/24 13:18, Boris Brezillon wrote:
> > On Thu, 25 Jan 2024 18:24:04 +0100
> > Daniel Vetter wrote:
> >
> >> On Fri, Jan 05, 2024 at 09:46:03PM +0300, Dmitry Osipenko wrote:
> >>
mutex_unlock(&ubuf->lock);
>
> - dma_sync_sg_for_device(dev, ubuf->sg->sgl, ubuf->sg->nents, direction);
> return 0;
> }
>
> @@ -307,7 +299,6 @@ static long udmabuf_create(struct miscdevice *device,
> exp_info.priv = ubuf;
> exp_info.flags = O_RDWR;
>
> - ubuf->device = device;
> buf = dma_buf_export(&exp_info);
> if (IS_ERR(buf)) {
> ret = PTR_ERR(buf);
> --
> 2.39.2
>
> ___
> 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
ntation in drm_fbdev_generic.c is the only one
left in drm that supports fb_defio, so that would catch all of them. To my
knowledge all the other defio implementations in native fbdev drivers
aren't problematic since none use shmem.
For I while we pondered with proxying the vma to the driver&#x
dog_worker(struct work_struct *work)
> pm_runtime_put(from_pvr_device(pvr_dev)->dev);
>
> out_requeue:
> - if (!pvr_dev->lost) {
> + if (!pvr_device_is_lost(pvr_dev))
> queue_delayed_work(pvr_dev->sched_wq, &pvr_dev->watchdog.work,
> msecs_to_jiffies(WATCHDOG_TIME_MS));
> - }
> }
>
> /**
> @@ -239,21 +223,21 @@ pvr_power_device_suspend(struct device *dev)
> int err = 0;
> int idx;
>
> - if (!drm_dev_enter(drm_dev, &idx))
> + if (!pvr_device_enter(pvr_dev, &idx))
> return -EIO;
>
> if (pvr_dev->fw_dev.booted) {
> err = pvr_power_fw_disable(pvr_dev, false);
> if (err)
> - goto err_drm_dev_exit;
> + goto err_pvr_device_exit;
> }
>
> clk_disable_unprepare(pvr_dev->mem_clk);
> clk_disable_unprepare(pvr_dev->sys_clk);
> clk_disable_unprepare(pvr_dev->core_clk);
>
> -err_drm_dev_exit:
> - drm_dev_exit(idx);
> +err_pvr_device_exit:
> + pvr_device_exit(pvr_dev, idx);
>
> return err;
> }
> @@ -267,12 +251,12 @@ pvr_power_device_resume(struct device *dev)
> int idx;
> int err;
>
> - if (!drm_dev_enter(drm_dev, &idx))
> + if (!pvr_device_enter(pvr_dev, &idx))
> return -EIO;
>
> err = clk_prepare_enable(pvr_dev->core_clk);
> if (err)
> - goto err_drm_dev_exit;
> + goto err_pvr_device_exit;
>
> err = clk_prepare_enable(pvr_dev->sys_clk);
> if (err)
> @@ -288,7 +272,7 @@ pvr_power_device_resume(struct device *dev)
> goto err_mem_clk_disable;
> }
>
> - drm_dev_exit(idx);
> + pvr_device_exit(pvr_dev, idx);
>
> return 0;
>
> @@ -301,8 +285,8 @@ pvr_power_device_resume(struct device *dev)
> err_core_clk_disable:
> clk_disable_unprepare(pvr_dev->core_clk);
>
> -err_drm_dev_exit:
> - drm_dev_exit(idx);
> +err_pvr_device_exit:
> + pvr_device_exit(pvr_dev, idx);
>
> return err;
> }
> @@ -345,7 +329,7 @@ pvr_power_reset(struct pvr_device *pvr_dev, bool
> hard_reset)
>
> down_write(&pvr_dev->reset_sem);
>
> - if (pvr_dev->lost) {
> + if (pvr_device_is_lost(pvr_dev)) {
> err = -EIO;
> goto err_up_write;
> }
> @@ -407,7 +391,7 @@ pvr_power_reset(struct pvr_device *pvr_dev, bool
> hard_reset)
>
> err_device_lost:
> drm_err(from_pvr_device(pvr_dev), "GPU device lost");
> - pvr_device_lost(pvr_dev);
> + pvr_device_set_lost(pvr_dev);
>
> /* Leave IRQs disabled if the device is lost. */
>
> diff --git a/drivers/gpu/drm/imagination/pvr_power.h
> b/drivers/gpu/drm/imagination/pvr_power.h
> index 9a9312dcb2da..360980f454d7 100644
> --- a/drivers/gpu/drm/imagination/pvr_power.h
> +++ b/drivers/gpu/drm/imagination/pvr_power.h
> @@ -12,8 +12,6 @@
> int pvr_watchdog_init(struct pvr_device *pvr_dev);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
only
done with PASID ... but for now I haven't seen that, definitely not in
upstream drivers.
And the moment you have some per-device pagetables or per-device memory
management of some sort (like using gpuva mgr) then I'm 100% agreeing with
Christian that the kfd SVM model is too strict and not a great idea.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
uevent = {
> .get_driver_name = nouveau_fence_get_get_driver_name,
> .get_timeline_name = nouveau_fence_get_timeline_name,
> - .enable_signaling = nouveau_fence_enable_signaling,
> + .enable_signaling = nouveau_fence_no_signaling,
I think you can rip nouveau_fence_no_signaling out too, it doesn't do
anything more than what the signalling codepath does too.
But maybe separate path since maybe this makes an existing leak more of a
sieve, but it really should be an existing one since you cannot assume
that someone external will ever look at whether your fence is signalled or
not.
-Sima
> .signaled = nouveau_fence_is_signaled,
> .release = nouveau_fence_release
> };
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
> b/drivers/gpu/drm/nouveau/nouveau_fence.h
> index 28f5cf013b89..380bb0397ed2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
> @@ -46,8 +46,6 @@ struct nouveau_fence_chan {
> char name[32];
>
> struct nvif_event event;
> - struct work_struct allow_block_work;
> - atomic_t notify_ref;
> int dead, killed;
> };
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
> &
don't think we have
anything in-flight for vram helpers that would cause conflicts. For
merging the drm patch through Jon's -doc tree:
Acked-by: Daniel Vetter
>
> But back to the patchset: Commit 654784284430 ("kernel-doc: bugfix -
> multi-line macros") introduces pre-pr
condition
>
> Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
> Signed-off-by: Erik Kurzinger
Yeah I think this series catches now all the corner cases I spotted in v1.
On the series:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/
n);
> +
> /**
>* @mmap:
>*
> @@ -606,6 +638,11 @@ void dma_buf_detach(struct dma_buf *dmabuf,
> int dma_buf_pin(struct dma_buf_attachment *attach);
> void dma_buf_unpin(struct dma_buf_attachment *attach);
>
> +int dma_buf_begin_access(struct dma_buf_attachment *attach,
> + struct sg_table *sgt, enum dma_data_direction dir);
> +int dma_buf_end_access(struct dma_buf_attachment *attach,
> +struct sg_table *sgt, enum dma_data_direction dir);
> +
> struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>
> int dma_buf_fd(struct dma_buf *dmabuf, int flags);
> --
> 2.43.0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
in theory
flush too much. But in practice on the these funky architectures they
flush enough.
There's also the very hard issue of actually trying to optimize flushes,
because a dma operation might only access part of a buffer, and you might
interleave read/write access by different devices in very innovative ways.
So I'm firmly on the "make it work first, then fast" side of things.
So dma-buf will continue to be a thing that's tested for specific combos,
and then we'll patch them. It's a decade-plus tradition at this point.
Which is all a very long winded way of saying that yes, I think we need
this, and we needed this 12 years ago already if we'd have aimed for
perfect.
I have a bunch of detail comments on the patch itself, but I guess we
first need to find consensus on whether it's a good idea in the first
place.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> *shmem, struct vm_area_struct
> return ret;
> }
>
> - dma_resv_lock(shmem->base.resv, NULL);
> - ret = drm_gem_shmem_get_pages_locked(shmem);
> - dma_resv_unlock(shmem->base.resv);
> -
> + ret = drm_gem_shmem_get_pages(shmem);
> if (ret)
> return ret;
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 18, 2024 at 08:39:23PM +0100, Paul Cercueil wrote:
> Hi Daniel / Sima,
>
> Le jeudi 18 janvier 2024 à 14:59 +0100, Daniel Vetter a écrit :
> > On Thu, Jan 18, 2024 at 02:56:31PM +0100, Daniel Vetter wrote:
> > > On Mon, Jan 15, 2024 at 01:54:27PM +0100, Paul Ce
On Thu, Jan 18, 2024 at 08:57:16AM -0800, T.J. Mercier wrote:
> On Thu, Jan 18, 2024 at 6:49 AM Daniel Vetter wrote:
> >
> > On Thu, Jan 18, 2024 at 11:02:22AM +0100, Christian König wrote:
> > > Am 17.01.24 um 19:11 schrieb T.J. Mercier:
> > > > DMA buffers
nsert_pfn(vma, vmf->address,
> > page_to_pfn(buffer->pages[vmf->pgoff]));
> > }
> > static const struct vm_operations_struct dma_heap_vm_ops = {
> > @@ -185,6 +182,8 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct
> > vm_area_struct *vma)
> > if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> > return -EINVAL;
> > + vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> > +
> > vma->vm_ops = &dma_heap_vm_ops;
> > vma->vm_private_data = buffer;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t_options() behind CONFIG_FB_CORE
> video/nomodeset: Select nomodeset= parameter with CONFIG_VIDEO
On the series:
Reviewed-by: Daniel Vetter
>
> drivers/gpu/drm/Kconfig | 3 +--
> drivers/staging/sm750fb/Kconfig | 1 -
> drivers/video/Kconfig | 5 +-
here's more conditions that should be patched.
Cheers, Sima
> + DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE)) {
> for (i = 0; i < count; ++i)
> drm_syncobj_fence_add_wait(syncobjs[i], &entries[i]);
> }
> --
> 2.43.0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 18, 2024 at 02:56:31PM +0100, Daniel Vetter wrote:
> On Mon, Jan 15, 2024 at 01:54:27PM +0100, Paul Cercueil wrote:
> > Hi Daniel / Sima,
> >
> > Le mardi 09 janvier 2024 à 14:01 +0100, Daniel Vetter a écrit :
> > > On Tue, Jan 09, 2024 at 12:06:5
On Mon, Jan 15, 2024 at 01:54:27PM +0100, Paul Cercueil wrote:
> Hi Daniel / Sima,
>
> Le mardi 09 janvier 2024 à 14:01 +0100, Daniel Vetter a écrit :
> > On Tue, Jan 09, 2024 at 12:06:58PM +0100, Paul Cercueil wrote:
> > > Hi Daniel / Sima,
> > >
> > &
On Wed, Jan 17, 2024 at 03:28:09PM +0100, Jocelyn Falempe wrote:
>
>
> On 12/01/2024 14:41, Daniel Vetter wrote:
> > On Thu, Jan 04, 2024 at 05:00:49PM +0100, Jocelyn Falempe wrote:
> > > This was initialy done for imx6, but should work on most drivers
>
On Fri, Jan 12, 2024 at 02:56:17PM +0100, Maxime Ripard wrote:
> On Fri, Jan 12, 2024 at 02:41:53PM +0100, Daniel Vetter wrote:
> > > + fb = plane->state->fb;
> > > + /* Only support linear modifier */
> > > + if (f
On Tue, Jan 16, 2024 at 11:54:42AM +0100, Jocelyn Falempe wrote:
> On 12/01/2024 14:31, Daniel Vetter wrote:
> > You need to tie these nice kerneldocs into the overall documentation tree,
> > or they're not getting built. Please then also check that all the links
> > and
mpledrm.c | 15 +
> include/drm/drm_drv.h| 21 ++
> include/drm/drm_fb_dma_helper.h | 4 +
> include/drm/drm_format_helper.h | 9 +
> include/drm/drm_panic.h | 101 ++++++
> include/drm/drm_plane.h
ng, as I've explained in the other reply.
Also because it trashes buffers from userspace I think by default we want
to only dump on panic, so KMS_DUMP_PANIC.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
>map = sdev->screen_base;
> + return 0;
> +}
> +
> /*
> * DRM driver
> */
> @@ -1000,6 +1014,7 @@ static struct drm_driver simpledrm_driver = {
> .minor = DRIVER_MINOR,
> .driver_features= DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET,
>
uct drm_plane_state;
> +struct drm_scanout_buffer;
>
> struct drm_gem_dma_object *drm_fb_dma_get_gem_obj(struct drm_framebuffer *fb,
> unsigned int plane);
> @@ -19,5 +20,8 @@ void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
> struct drm_plane_state *old_state,
> struct drm_plane_state *state);
>
> +int drm_panic_gem_get_scanout_buffer(struct drm_device *dev,
> + struct drm_scanout_buffer *sb);
> +
> #endif
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
mory or iomem.
> + * The scanout buffer should be in linear format, and can be directly
The should here is confusing, because it's an either/or.
> + * sent to the display hardware. Tearing is not an issue for the panic
> + * screen.
> + */
> + struct iosys_map map;
I think you're a bit unclear on whether you allow non-null @map for the
case when @draw_pixel_xy is set. Current docs says it's either/or, but you
don't have any checks for iosys_map_is_null(). I'd add something like
WARN_ON(sb->draw_pixel_xy && !iosys_map_is_null(sb->map));
right after the call to ->get_scanout_buffer to lock down this rule.
> + /**
> + * @width: Width of the scanout buffer, in pixels.
> + */
> + unsigned int width;
> + /**
> + * @height: Height of the scanout buffer, in pixels.
> + */
> + unsigned int height;
> + /**
> + * @pitch: Length in bytes between the start of two consecutive lines.
> + */
> + unsigned int pitch;
> + /**
> + * @private:
> + *
> + * In case the driver can't provide a linear buffer, this is a pointer
> to
> + * some private data, that will be passed when calling @draw_pixel_xy()
> + * and @flush()
> + */
> + void *private;
> + /**
> + * @draw_pixel_xy:
> + *
> + * In case the driver can't provide a linear buffer, this is a function
> + * that drm_panic will call for each pixel to draw.
> + * Color will be converted to the format specified by @format.
> + */
> + void (*draw_pixel_xy)(unsigned int x, unsigned int y, u32 color, void
> *private);
> + /**
> + * @flush:
> + *
> + * This function is called after the panic screen is drawn, either using
> + * the iosys_map or the draw_pixel_xy path. In this function, the driver
> + * can send additional commands to the hardware, to make the buffer
> + * visible.
Uh how does flush work for the @map path? I'd just pass the overall
drm_scanout_buffer struct to both of these hooks as the first parameter
and let the driver figure out what it needs.
> + */
> + void (*flush)(void *private);
> +};
> +
> +#ifdef CONFIG_DRM_PANIC
> +
> +void drm_panic_init(void);
> +void drm_panic_exit(void);
> +
> +void drm_panic_register(struct drm_device *dev);
> +void drm_panic_unregister(struct drm_device *dev);
> +
> +#else
> +
> +static inline void drm_panic_init(void) {}
> +static inline void drm_panic_exit(void) {}
> +
> +static inline void drm_panic_register(struct drm_device *dev) {}
> +static inline void drm_panic_unregister(struct drm_device *dev) {}
> +
> +#endif
> +
> +#endif /* __DRM_PANIC_H__ */
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ned long dma_attrs;
> struct sg_table *sg;
> struct page **pages;
> + boolsecure;
> };
>
> #define to_mtk_gem_obj(x)container_of(x, struct mtk_drm_gem_obj, base)
> @@ -37,6 +39,8 @@ struct mtk_drm_gem_ob
er the locked dma_resv_iter_next() whenever possible.
> *
> * Returns the next fence from an unlocked dma_resv obj.
> */
> ___
> 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
301 - 400 of 6210 matches
Mail list logo
