mm, start, end, order,
> flags, !fallback);
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, May 03, 2024 at 06:06:03PM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2024 16:58, Alex Deucher wrote:
> > On Fri, May 3, 2024 at 11:33 AM Daniel Vetter wrote:
> > >
> > > On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
> > > >
&g
driver, do $bar" is just
guaranteed to fragement the ecosystem, so imo that should be the absolute
last resort.
-Sima
> > > +
> > > - drm-shared-: [KiB|MiB]
> > > The total size of buffers that are shared with another file (e.g.,
> > > have more
> > > @@ -145,6 +150,9 @@ than a single handle).
> > > The total size of buffers that including shared and private memory.
> > > +This is an alias for drm-memory- and only one of the two
> > > should be
> > > +present.
> > > +
> > > - drm-resident-: [KiB|MiB]
> > > The total size of buffers that are resident in the specified region.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 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
gt;>>>>> that?
> > >>>>>> Or through external tools?
> > >>>>> Windows uses the same limit. I'm not aware of any way to override the
> > >>>>> limit on windows off hand.
> > >>>>>
> > >>>>> Alex
> > >>>>>
> > >>>>>
> > >>>>>> Ciao, Thorsten
> > >>>>>>
> > >>>>>>>>>>> Roman posted something that apparently was meant to go to the
> > >>>>>>>>>>> list, so
> > >>>>>>>>>>> let me put it here:
> > >>>>>>>>>>>
> > >>>>>>>>>>> """
> > >>>>>>>>>>> UPDATE: User fililip already posted patch, but it need to be
> > >>>>>>>>>>> merged,
> > >>>>>>>>>>> discussion is on gitlab link below.
> > >>>>>>>>>>>
> > >>>>>>>>>>> (PS: I hope I am replying correctly to "all" now? - using
> > >>>>>>>>>>> original addr.)
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> it seems that commit was already found(see user's 'fililip'
> > >>>>>>>>>>>> comment):
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> https://gitlab.freedesktop.org/drm/amd/-/issues/3183
> > >>>>>>>>>>>> commit 1958946858a62b6b5392ed075aa219d199bcae39
> > >>>>>>>>>>>> Author: Ma Jun
> > >>>>>>>>>>>> Date: Thu Oct 12 09:33:45 2023 +0800
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> drm/amd/pm: Support for getting power1_cap_min value
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Support for getting power1_cap_min value on smu13 and
> > >>>>>>>>>>>> smu11.
> > >>>>>>>>>>>> For other Asics, we still use 0 as the default value.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Signed-off-by: Ma Jun
> > >>>>>>>>>>>> Reviewed-by: Kenneth Feng
> > >>>>>>>>>>>> Signed-off-by: Alex Deucher
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> However, this is not good as it remove under-powering range
> > >>>>>>>>>>>> too far. I
> > >>>>>>>>>>> was getting only about 7% less performance but 90W(!) less
> > >>>>>>>>>>> consumption
> > >>>>>>>>>>> when set to my 115W before. Also I wonder if we as a OS of
> > >>>>>>>>>>> options and
> > >>>>>>>>>>> freedom have to stick to such very high reference for min
> > >>>>>>>>>>> values without
> > >>>>>>>>>>> ability to override them through some sys ctrls. Commit was
> > >>>>>>>>>>> done by amd
> > >>>>>>>>>>> guy and I wonder if because of maybe this post that I made few
> > >>>>>>>>>>> months
> > >>>>>>>>>>> ago(business strategy?):
> > >>>>>>>>>>> https://www.reddit.com/r/Amd/comments/183gye7/rx_6700xt_from_230w_to_capped_115w_at_only_10/
> > >>>>>>>>>>>> This is not a dangerous OC upwards where I can understand
> > >>>>>>>>>>>> desire to
> > >>>>>>>>>>> protect HW, it is downward, having min cap at 190W when card
> > >>>>>>>>>>> pull on
> > >>>>>>>>>>> 115W almost same speed is IMO crazy to deny. We don't talk
> > >>>>>>>>>>> about default
> > >>>>>>>>>>> or reference values here either, just a move to lower the range
> > >>>>>>>>>>> of
> > >>>>>>>>>>> options for whatever reason.
> > >>>>>>>>>>>> I don't know how much power you guys have over them, but please
> > >>>>>>>>>>> consider either reverting this change, or give us an option to
> > >>>>>>>>>>> set
> > >>>>>>>>>>> min_cap through say /sys (right now param is readonly, even for
> > >>>>>>>>>>> root).
> > >>>>>>>>>>>> Thank you in advance for looking into this, with regards:
> > >>>>>>>>>>>> Romano
> > >>>>>>>>>>> """
> > >>>>>>>>>>>
> > >>>>>>>>>>> And while at it, let me add this issue to the tracking as well
> > >>>>>>>>>>>
> > >>>>>>>>>>> [TLDR: I'm adding this report to the list of tracked Linux
> > >>>>>>>>>>> kernel
> > >>>>>>>>>>> regressions; the text you find below is based on a few templates
> > >>>>>>>>>>> paragraphs you might have encountered already in similar form.
> > >>>>>>>>>>> See link in footer if these mails annoy you.]
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks for the report. To be sure the issue doesn't fall
> > >>>>>>>>>>> through the
> > >>>>>>>>>>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel
> > >>>>>>>>>>> regression
> > >>>>>>>>>>> tracking bot:
> > >>>>>>>>>>>
> > >>>>>>>>>>> #regzbot introduced 1958946858a62b /
> > >>>>>>>>>>> #regzbot title drm: amdgpu: under-powering broke
> > >>>>>>>>>>>
> > >>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression
> > >>>>>>>>>>> tracker' hat)
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Everything you wanna know about Linux kernel regression
> > >>>>>>>>>>> tracking:
> > >>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > >>>>>>>>>>> That page also explains what to do if mails like this annoy you.
> > >>>>>>>
> > >
> > >
--
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 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
race_drm_mode_atomic_commit(file_priv, crtcs, num_crtcs,
> > arg->flags);
> > +
> > + kfree(crtcs);
> > + }
> > +
> > ret = prepare_signaling(dev, state, arg, file_priv, _state,
> > _fences);
> > if (ret)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
_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
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 the
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
__alloc_range(struct drm_buddy *mm,
> } while (1);
>
> list_splice_tail(, 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
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 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
ps 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 of it.
Cheers, Sima
--
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 dma-bu
eems 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
e_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
On Wed, 10 Jan 2024 at 13:53, Andri Yngvason wrote:
>
> mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :
> >
> > On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote:
> > > + /* Extract information from crtc to communicate it to userspace as
drm_connector_attach_max_bpc_property(connector, 8, 16);
>
> + connector->active_color_format_property =
> master->base.active_color_format_property;
> + if (connector->active_color_format_property)
> +
> drm_connector_attach_active_color_format_property(>base);
> +
> connector->vrr_capable_property = master->base.vrr_capable_property;
> if (connector->vrr_capable_property)
> drm_connector_attach_vrr_capable_property(connector);
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 10, 2024 at 11:46:35AM +0100, Christian König wrote:
> Am 10.01.24 um 11:22 schrieb Daniel Vetter:
> > On Wed, Jan 10, 2024 at 11:19:37AM +0100, Christian König wrote:
> > > Am 10.01.24 um 10:56 schrieb Julia Zhang:
> > > >
OURCE_QUERY_LAYOUT
> + */
> +#define VIRTIO_GPU_F_RESOURCE_QUERY_LAYOUT 5
> +
> enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_UNDEFINED = 0,
>
> @@ -95,6 +100,7 @@ enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_CMD_SUBMIT_3D,
> VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
> VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
> + VIRTIO_GPU_CMD_RESOURCE_QUERY_LAYOUT,
>
> /* cursor commands */
> VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
> @@ -108,6 +114,7 @@ enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_RESP_OK_EDID,
> VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
> VIRTIO_GPU_RESP_OK_MAP_INFO,
> + VIRTIO_GPU_RESP_OK_RESOURCE_LAYOUT,
>
> /* error responses */
> VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
> @@ -453,4 +460,27 @@ struct virtio_gpu_resource_unmap_blob {
> __le32 padding;
> };
>
> +/* VIRTIO_GPU_CMD_RESOURCE_QUERY_LAYOUT */
> +struct virtio_gpu_resource_query_layout {
> + struct virtio_gpu_ctrl_hdr hdr;
> + __le32 resource_id;
> + __le32 width;
> + __le32 height;
> + __le32 format;
> + __le32 bind;
> +};
> +
> +
> +/* VIRTIO_GPU_RESP_OK_RESOURCE_LAYOUT */
> +#define VIRTIO_GPU_RES_MAX_PLANES 4
> +struct virtio_gpu_resp_resource_layout {
> + struct virtio_gpu_ctrl_hdr hdr;
> + __le64 modifier;
> + __le32 num_planes;
> + struct virtio_gpu_resource_plane {
> + __le64 offset;
> + __le32 stride;
> + } planes[VIRTIO_GPU_RES_MAX_PLANES];
> +};
> +
> #endif
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
er the kms ioctl returns (and not somewhen later for non-blocking
commits).
You probably need a bit of work to be able to handle immutable properties
with the atomic state infrastructure, but I think otherwise this should
fit all rather neatly.
Cheers, Sima
>
> The way I've implemented thing
uct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
> > .ops = {
> > .cache_sgt_mapping = true,
> > @@ -83,7 +95,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,
> > };
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
tatic 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
On Tue, 9 Jan 2024 at 14:25, Tvrtko Ursulin
wrote:
>
>
> On 09/01/2024 12:54, Daniel Vetter wrote:
> > On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
> >>
> >> On 09/01/2024 07:56, Christian König wrote:
> >>> Am 07.12.23 um 19:02
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > index d28e21baef16..0503af75dc26 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > @@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
> > > struct amdgpu_mem_stats {
> > > /* current VRAM usage, includes visible VRAM */
> > > uint64_t vram;
> > > + /* current shared VRAM usage, includes visible VRAM */
> > > + uint64_t vram_shared;
> > > /* current visible VRAM usage */
> > > uint64_t visible_vram;
> > > /* current GTT usage */
> > > uint64_t gtt;
> > > + /* current shared GTT usage */
> > > + uint64_t gtt_shared;
> > > /* current system memory usage */
> > > uint64_t cpu;
> > > + /* current shared system memory usage */
> > > + uint64_t cpu_shared;
> > > /* sum of evicted buffers, includes visible VRAM */
> > > uint64_t evicted_vram;
> > > /* sum of evicted buffers due to CPU access */
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
per.c | 1 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 43 +-
> > drivers/gpu/drm/drm_property.c| 49 ++
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 7 +
> > include/drm/drm_property.h| 6 +
> > include/uapi/drm/drm_mode.h | 8 +
> > 16 files changed, 1377 insertions(+), 109 deletions(-)
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
u/drm/amd/display/dc/core/dc_resource.c | 3 ++
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 10 ++---
> drivers/gpu/drm/amd/display/dc/dc_types.h | 1 +
> .../display/dc/dcn35/dcn35_dio_stream_encoder.c| 10 ++---
> .../gpu/drm/amd/display/dc/link/link_detection.c | 3
hwss/dce/dce_hwseq.h| 18 +-
> .../drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c| 17 +-
> .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c| 34 ++-
> drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h | 5 +
> drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h| 2 +
> drivers/gpu/drm/amd/display/dc/inc/hw/optc.h | 219 ++
> drivers/gpu/drm/amd/display/dc/inc/hw/pg_cntl.h| 2 +
> .../amd/display/dc/link/accessories/link_dp_cts.c | 17 +-
> .../dc/link/protocols/link_dp_irq_handler.c| 15 +-
> drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h| 25 +-
> drivers/gpu/drm/amd/pm/amdgpu_dpm.c| 12 +-
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 29 +-
> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 5 +-
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 315
> +
> 85 files changed, 1688 insertions(+), 773 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/display/dc/inc/hw/optc.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
a
> Alex
>
>
> > >
> > >
> > > BR,
> > > Jani.
> > >
> > >
> > >>
> > >> With the patch. both following git grep commands return nothing in
> > >> amd-staging-drm-next.
> > >>
> > >> $ git grep drm_edid_override_connector_update -- drivers/gpu/drm/amd
> > >> $ git grep edid_override -- drivers/gpu/drm/amd
> > >>
> > >> Best regards,
> > >> Alex Hung
> > >>
> > >>>>>
> > >>>>> What is the goal of the reverts? I don't disagree that we may be
> > >>>>> using the interfaces wrong, but reverting them will regess
> > >>>>> functionality in the driver.
> > >>>>
> > >>>> The commits are in v6.5-rc1, but not yet in a release. No user depends
> > >>>> on them yet. I'd strongly prefer them not reaching v6.5 final and
> > >>>> users.
> > >>>
> > >>> Sorry for confusion here, that's obviously come and gone already. :(
> > >>>
> > >>>> The firmware EDID, override EDID, connector forcing, the EDID property,
> > >>>> etc. have been and somewhat still are a hairy mess that we must keep
> > >>>> untangling, and this isn't helping.
> > >>>>
> > >>>> I've put in crazy amounts of work on this, and I've added kernel-doc
> > >>>> comments about stuff that should and should not be done, but they go
> > >>>> unread and ignored.
> > >>>>
> > >>>> I really don't want to end up having to clean this up myself before I
> > >>>> can embark on further cleanups and refactoring.
> > >>>>
> > >>>> And again, if the functionality in the driver depends on conflating two
> > >>>> things that should be separate, it's probably not such a hot idea to
> > >>>> let
> > >>>> it reach users either. Even if it's just debugfs.
> > >>>>
> > >>>>
> > >>>> BR,
> > >>>> Jani.
> > >>>
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 30, 2023 at 10:29:46AM +0300, Jani Nikula wrote:
> Upstream code should be reviewed in public.
Yup
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
serspace that doesn't support robust interfaces (like an non-robust
OpenGL context or API without any robustness support like libva) leave the
robustness handling entirely to the userspace driver. There is no strong
community consensus on what the userspace driver should do in that case,
since al
.c| 6 +-
> drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 3 +-
> drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 2 +-
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 48 ++
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 37 +-
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 2 +-
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 35 +-
> drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 9 +-
> drivers/gpu/drm/radeon/atom.c | 18 +-
> drivers/gpu/drm/radeon/clearstate_si.h | 3 +-
> drivers/gpu/drm/radeon/r300.c | 6 +-
> drivers/gpu/drm/radeon/radeon_atombios.c | 12 +-
> drivers/gpu/drm/radeon/radeon_atpx_handler.c | 18 +-
> drivers/gpu/drm/radeon/radeon_combios.c| 4 +-
> drivers/gpu/drm/radeon/radeon_connectors.c | 11 +-
> drivers/gpu/drm/radeon/radeon_drv.c| 51 +-
> drivers/gpu/drm/radeon/radeon_drv.h| 13 +
> drivers/gpu/drm/radeon/radeon_encoders.c | 22 +-
> drivers/gpu/drm/radeon/radeon_gart.c | 37 +-
> drivers/gpu/drm/radeon/radeon_gem.c| 4 +-
> drivers/gpu/drm/radeon/radeon_kms.c| 10 +-
> drivers/gpu/drm/radeon/radeon_legacy_tv.c | 6 +-
> drivers/gpu/drm/radeon/radeon_test.c | 8 +-
> drivers/gpu/drm/radeon/radeon_vce.c| 4 +-
> drivers/gpu/drm/radeon/rv770.c | 33 +-
> drivers/gpu/drm/radeon/rv770_smc.c | 36 +-
> drivers/gpu/drm/radeon/sislands_smc.h | 51 +-
> 245 files changed, insertions(+), 2621 deletions(-)
> create mode 100644 Documentation/gpu/amdgpu/flashing.rst
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
> rename drivers/gpu/drm/amd/amdgpu/{aqua_vanjaram_reg_init.c =>
> aqua_vanjaram.c} (99%)
> create mode 100644 drivers/gpu/drm/amd/display/dc/dcn301/dcn301_optc.c
> create mode 100644 drivers/gpu/drm/amd/display/dc/dcn301/dcn301_optc.h
> delete mode 100644 drivers/gpu/drm/amd/display/dmub/inc/dmub_subvp_state.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, 31 Jul 2023 at 04:01, André Almeida wrote:
>
> Em 13/07/2023 04:51, Pekka Paalanen escreveu:
> > On Tue, 11 Jul 2023 10:57:57 +0200
> > Daniel Vetter wrote:
> >
> >> On Fri, Jul 07, 2023 at 07:40:59PM -0300, André Almeida wrote:
> >>>
tc (and their connected
planes/connectors) might result in some oversynchronization issues, and
userspace should therefore avoid them if feasible.
With some sentences added to clarify this:
Reviewed-by: Daniel Vetter
> +
> +A "modeset" is a change in KMS state that might enable, disa
e_payload
>
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 57 --
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 6 ++
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 4 +-
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 87
> ++
m-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
> ktime_to_ns(usage[hw_ip]));
> }
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> index e86834bfea1d..0398f5a159ef 100644
> --- a/d
On Wed, 5 Apr 2023 at 11:11, Tvrtko Ursulin
wrote:
>
>
> On 05/04/2023 09:28, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 12:45, Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> Hi,
> >>
> >> On 03/04/2023 20:40, Joshua Ashton wro
n't thought out well enough.
Adding at least some of the people who probably should be cc'ed on
this. Please add more.
Cheers, Daniel
>
> Regards,
>
> Tvrtko
>
> [1]
> https://lore.kernel.org/dri-devel/20220407152806.3387898-1-tvrtko.ursu...@linux.intel.com/T/
> [2]
> https://lore.kernel.org/lkml/20221019173254.3361334-4-tvrtko.ursu...@linux.intel.com/T/#u
> [3]
> https://lore.kernel.org/lkml/20230314141904.1210824-1-tvrtko.ursu...@linux.intel.com/
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
20 +-
> 134 files changed, 119288 insertions(+), 930 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_2.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_2.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/nbio_v7_9.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/athub/athub_1_8_0_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/athub/athub_1_8_0_sh_mask.h
> create mode 100644 drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_3_offset.h
> create mode 100644 drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_3_sh_mask.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/mmhub/mmhub_1_8_0_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/mmhub/mmhub_1_8_0_sh_mask.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/oss/osssys_4_4_2_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/oss/osssys_4_4_2_sh_mask.h
> delete mode 100644 drivers/gpu/drm/radeon/radeon_fb.c
> create mode 100644 drivers/gpu/drm/radeon/radeon_fbdev.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;
>
> Tim Huang (1):
> drm/amdgpu: allow more APUs to do mode2 reset when go to S4
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Add DSC Support for Synaptics Cascaded MST Hub
> drm/amd/display: Take FEC Overhead into Timeslot Calculation
>
> .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 51
> ++
> .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h| 15 +++
> 2 files cha
9 +
> drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 14
> drivers/gpu/drm/amd/amdgpu/nv.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/vi.c| 17 +
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> drivers/gpu/d
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
that it should be a problem for drivers and not for DRM core.
>
> I was going to re-send the [1], but other things were getting priority.
> It's good that you reminded me about it :) I may re-send it sometime
> soon if there are no new objections.
>
> [1] https://patchwork.freedesktop.org/patch/487481/
>
> [2]
> https://lore.kernel.org/all/20220701090240.1896131-1-dmitry.osipe...@collabora.com/
Hm I still don't like allowing this in general, because in general it just
doesn't work.
I think more like a per-driver opt-in or something might be needed, so
that drivers which "know" that it's ok to just mmap without coherency can
allow that. Allowing this in general essentially gives up on the entire
idea of dma-buf cache flushing completely.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 12, 2023 at 05:45:42PM +0100, Greg KH wrote:
> On Thu, Jan 12, 2023 at 04:26:45PM +0100, Daniel Vetter wrote:
> > On Thu, 12 Jan 2023 at 13:47, Greg KH wrote:
> > > On Wed, Jan 04, 2023 at 07:56:33PM +0200, Dragos-Marian Panait wrote:
> >
On Fri, Jan 13, 2023 at 11:29:57AM -0700, jim.cro...@gmail.com wrote:
> On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
> >
> > On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > > Hi everyone,
> > >
> > > DRM_USE_DYNAMIC_DEBUG=y has a
On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>
> Cc: intel-gfx, drm maintainers
>
> Please have the courtesy of Cc'ing us for changes impacting us, and
> maybe try to involve us earlier instead of surprising us like
> this. Looks like this has been debugged for at least three
bugfixes from random people was nice when it was checkpatch
stuff and I was fairly happy to take these aggressively in drm. But my
gut feeling says things seem to be shifting towards more advanced
tooling, but without more advanced understanding by submitters. Does
that holder in other areas too?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 54 ++
> kernel/module/main.c| 2 +
> lib/dynamic_debug.c | 240 +++-
> lib/test_dynamic_debug.c| 47 ++---
> 13 files changed, 344 insertions(+), 157 deletions(-)
> create mode 100644 include/linux/map.h
>
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
1
Indeed, vga_switcheroo_client_fb_set is a no-op if no client is registered
on that pdev.
Reviewed-by: Daniel Vetter
t-b/ack from amd would be still good I think (or maybe they'll pick this
one up so it goes through their CI).
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/radeon/radeon_device.c
> > index 92905ebb7b45..1c005e0ddd38 100644
> > --- a/drivers/gpu/drm/radeon/radeon_device.c
> > +++ b/drivers/gpu/drm/radeon/radeon_device.c
> > @@ -1022,6 +1022,7 @@ void radeon_atombios_fini(struct radeon_device *rdev)
> >
NE args in sync with changes here,
> + * the enum-values define BIT()s in drm.debug, so are ABI.
> + */
> /**
>* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 8 Dec 2022 at 05:54, Alex Deucher wrote:
>
> On Wed, Nov 30, 2022 at 6:11 AM Daniel Vetter wrote:
> >
> > On Fri, Nov 25, 2022 at 02:52:01PM -0300, André Almeida wrote:
> > > This patchset adds a udev event for DRM device's resets.
> > >
> &g
27
> ++
> drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++
> .../dc/dml/dcn32/display_mode_vba_util_32.c| 6 ++---
> 5 files changed, 39 insertions(+), 9 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
story for the ttm backend, except slightly more complicated in
> > that there might be no currently bound VMA, and yet the GPU could
> > still be accessing the pages due to async unbinds, kernel moves etc,
> > which the wait here (and in i915_ttm_shrink) is meant to protect
> > a
the i915
infra for endless batchbuffers so that you can make very controlled gpu
hangs.
Cheers, Daniel
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30 ++
> drivers/gpu/drm/drm_sysfs.c| 26
return dmabuf->ops->mmap(dmabuf, vma);
> + dma_resv_lock(dmabuf->resv, NULL);
> + ret = dmabuf->ops->mmap(dmabuf, vma);
> + dma_resv_unlock(dmabuf->resv);
> +
> + return ret;
> }
> EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
>
> --
> 2.37.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rs/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c| 151 +
> drivers/gpu/drm/amd/amdgpu/soc21.c| 1 +
> 7 files changed, 281 insertions(+), 149 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 4 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c | 264
> ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 4 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +-
> drivers/gpu/drm/amd/
On Wed, Sep 07, 2022 at 08:45:22AM +0200, Christian König wrote:
> Am 06.09.22 um 21:58 schrieb Daniel Vetter:
> > On Tue, Aug 16, 2022 at 10:33:16AM +0530, Arunpravin Paneer Selvam wrote:
> > >
> > > On 8/15/2022 4:35 PM, Christian König wrote:
> > > >
All the drm patches (excluding nouveau) I haven't commented on:
Reviewed-by: Daniel Vetter
I think nouveau I'll leave up to nouveau folks.
-Daniel
> ---
> drivers/gpu/drm/drm_print.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu
bg is wrapping the drm.debug API, so as to avoid the runtime
> + * bit-test overheads of drm_debug_enabled() in those api calls.
> + * In this case, executed callsites are known enabled, so true.
> + */
> +#define __drm_debug_enabled(category)true
> +#else
> +#define __drm_debug_enabled(category)drm_debug_enabled(category)
> +#endif
> +
> /*
> * struct device based logging
> *
> --
> 2.37.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
> + "DRM_UT_CORE",
> + "DRM_UT_DRIVER",
> + "DRM_UT_KMS",
> + "DRM_UT_PRIME",
> + "DRM_UT_ATOMIC",
> + "DRM_UT_VBL",
> + "DRM_UT_STATE",
> + "DRM_UT_LEASE",
> + "DRM_UT_DP",
> + "DRM_UT_DRMRES");
> +
> MODULE_PARM_DESC(config, "option string to pass to driver core");
> static char *nouveau_config;
> module_param_named(config, nouveau_config, charp, 0400);
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index b3b470440e46..668273e36c2c 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -35,7 +35,7 @@
> #include
>
> /* Do *not* use outside of drm_print.[ch]! */
> -extern unsigned int __drm_debug;
> +extern unsigned long __drm_debug;
>
> /**
> * DOC: print
> @@ -275,6 +275,7 @@ static inline struct drm_printer drm_err_printer(const
> char *prefix)
> *
> */
> enum drm_debug_category {
> + /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
I'd just put this into the kerneldoc, then you can also link to the
DRM_PRINT_DECLARE_DEBUG_CLASSBITS macro or whatever you'll call the thing
so drivers don't have to copypaste it all.
-Daniel
> /**
>* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> --
> 2.37.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
loses the possibility of doing:
>
> drm_dbg(DRM_UT_CORE|DRM_UT_KMS, "weird 2-cat experiment")
>
> but thats already strongly implied by the use of the enum itself; its
> not a normal enum if it can be 2 values simultaneously.
>
> Signed-off-by: Jim Cromie
Reviewe
On Wed, Sep 07, 2022 at 07:47:10AM +0200, Greg KH wrote:
> On Tue, Sep 06, 2022 at 09:18:09PM +0200, Daniel Vetter wrote:
> > On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote:
> > > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote:
> > > > On W
valueable or not.
> > > + */
> > > + bool (*intersects)(struct ttm_resource_manager *man,
> > > + struct ttm_resource *res,
> > > + const struct ttm_place *place,
> > > + size_t size);
> > > +
> > > + /**
> > > + * struct ttm_resource_manager_func member compatible
> > > + *
> > > + * @man: Pointer to a memory type manager.
> > > + * @res: Pointer to a struct ttm_resource to be checked.
> > > + * @place: Placement to check against.
> > > + * @size: Size of the check.
> > > + *
> > > + * Test if @res compatible with @place + @size. Used to check of
> > > + * the need to move the backing store or not.
> > > + */
> > > + bool (*compatible)(struct ttm_resource_manager *man,
> > > + struct ttm_resource *res,
> > > + const struct ttm_place *place,
> > > + size_t size);
> > > +
> > > /**
> > > * struct ttm_resource_manager_func member debug
> > > *
> > > @@ -329,6 +361,14 @@ int ttm_resource_alloc(struct ttm_buffer_object
> > > *bo,
> > > const struct ttm_place *place,
> > > struct ttm_resource **res);
> > > void ttm_resource_free(struct ttm_buffer_object *bo, struct
> > > ttm_resource **res);
> > > +bool ttm_resource_intersects(struct ttm_device *bdev,
> > > + struct ttm_resource *res,
> > > + const struct ttm_place *place,
> > > + size_t size);
> > > +bool ttm_resource_compatible(struct ttm_device *bdev,
> > > + struct ttm_resource *res,
> > > + const struct ttm_place *place,
> > > + size_t size);
> > > bool ttm_resource_compat(struct ttm_resource *res,
> > > struct ttm_placement *placement);
> > > void ttm_resource_set_bo(struct ttm_resource *res,
> > >
> > > base-commit: 730c2bf4ad395acf0aa0820535fdb8ea6abe5df1
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote:
> On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote:
> > >
> > >
> > > On 8/3/22 15:56, jim.cro...@gmail.com wrote:
> &g
/gpu/drm/Kconfig
> > CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig
> > error: Failed to merge in the changes.
> >
> >
> > Before I resend, I should sort out that possible conflict
> > which tree is patchwork applied upon ?
> >
> > or was it just transient ? after 5.19 I rebased a copy onto
> > drm-next/drm-next,
> > and there was nothing to fix - I will revisit presently..
>
>
> Not sure, if it's a minor conflict maybe Greg KH can sort it when
> he pulls it in? If not yeah might be important to rebase first...Greg?
>
> Thanks,
>
> -Jason
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rm.debug adaptation
>
> drm_print: condense enum drm_debug_category
> drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.
> drm_print: interpose drm_*dbg with forwarding macros
> drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro
> drm-print.h: include dyndbg header
> drm-print: add drm_dbg_driver to improve namespace symmetry
> drm_print: refine drm_debug_enabled for jump-label
> drm_print: prefer bare printk KERN_DEBUG on generic fn
> drm_print: add _ddebug descriptor to drm_*dbg prototypes
>
> nouveau-LEVEL_NUM integration: WIP/exploratory.
>
> nouveau: change nvkm_debug/trace to use dev_dbg POC
> nouveau: adapt NV_DEBUG, NV_ATOMIC to use DRM.debug
> nouveau: WIP add 2 LEVEL_NUM classmaps for CLI, SUBDEV
>
> .../admin-guide/dynamic-debug-howto.rst | 246 +-
> MAINTAINERS | 2 +
> drivers/gpu/drm/Kconfig | 12 +
> drivers/gpu/drm/Makefile | 2 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 14 +
> drivers/gpu/drm/display/drm_dp_helper.c | 13 +
> drivers/gpu/drm/drm_crtc_helper.c | 13 +
> drivers/gpu/drm/drm_print.c | 48 +-
> drivers/gpu/drm/i915/i915_params.c| 12 +
> .../gpu/drm/nouveau/include/nvkm/core/debug.h | 16 +
> .../drm/nouveau/include/nvkm/core/subdev.h| 17 +-
> drivers/gpu/drm/nouveau/nouveau_drm.c | 20 +
> drivers/gpu/drm/nouveau/nouveau_drv.h | 16 +-
> drivers/gpu/drm/nouveau/nvkm/core/subdev.c| 23 +
> include/asm-generic/vmlinux.lds.h | 3 +
> include/drm/drm_print.h | 85 +++-
> include/linux/dynamic_debug.h | 176 +--
> kernel/module/internal.h | 4 +-
> kernel/module/main.c | 20 +-
> lib/Kconfig.debug | 10 +
> lib/Makefile | 1 +
> lib/dynamic_debug.c | 450 +++---
> lib/test_dynamic_debug.c | 165 +++
> 23 files changed, 1099 insertions(+), 269 deletions(-)
> create mode 100644 lib/test_dynamic_debug.c
>
> --
> 2.37.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
f
> + * drm_color_lut.
> + */
> + struct drm_property_blob *lut3d;
> +
> /**
>* @target_vblank:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 2df7e171add9..87280694e70d 100644
> --- a/include/drm
t; are also pinned on attachment, hence maybe this lock is indeed
> > unnecessary.. I'll re-check it.
>
> I'm not worried about contention with export/import/etc, but
> contention between multiple threads hitting the shrinker in parallel.
> I guess since you are using trylock,
t you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.
Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable m
On Mon, Jun 06, 2022 at 08:59:36AM -0600, jim.cro...@gmail.com wrote:
> On Wed, May 25, 2022 at 9:02 AM Daniel Vetter wrote:
>
> > On Mon, May 16, 2022 at 04:56:13PM -0600, Jim Cromie wrote:
> > > DRM.debug API is 23 macros, issuing 10 exclusive categories of debug
>
On Sun, 5 Jun 2022 at 20:32, Rob Clark wrote:
>
> On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
> >
> > On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> > wrote:
> > >
> > > Introduce a common DRM SHMEM shrinker framework that allows to reduc
t; +* 1 is not-needed/can-be-purged
> * A negative value is the object is purged.
> -* Positive values are driver specific and not used by the helpers.
> */
> int madv;
>
> @@ -91,6 +102,39 @@ struct drm_gem_shmem_object {
> * @map_
-
> >>> drivers/gpu/drm/Kconfig | 2 +
> >>> .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +++-
> >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++
> >>> .../gpu/drm/i915/display/intel_backlight.c| 7 ++
> >>> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> >>> drivers/gpu/drm/i915/display/intel_opregion.c | 2 +-
> >>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 14
> >>> drivers/gpu/drm/radeon/atombios_encoders.c| 7 ++
> >>> drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
> >>> .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 ++
> >>> drivers/platform/x86/acer-wmi.c | 2 +-
> >>> drivers/platform/x86/asus-laptop.c| 2 +-
> >>> drivers/platform/x86/asus-wmi.c | 4 +-
> >>> drivers/platform/x86/compal-laptop.c | 2 +-
> >>> drivers/platform/x86/dell/dell-laptop.c | 2 +-
> >>> drivers/platform/x86/eeepc-laptop.c | 2 +-
> >>> drivers/platform/x86/fujitsu-laptop.c | 4 +-
> >>> drivers/platform/x86/ideapad-laptop.c | 2 +-
> >>> drivers/platform/x86/intel/oaktrail.c | 2 +-
> >>> drivers/platform/x86/msi-laptop.c | 2 +-
> >>> drivers/platform/x86/msi-wmi.c| 2 +-
> >>> drivers/platform/x86/samsung-laptop.c | 2 +-
> >>> drivers/platform/x86/sony-laptop.c| 2 +-
> >>> drivers/platform/x86/thinkpad_acpi.c | 4 +-
> >>> drivers/platform/x86/toshiba_acpi.c | 2 +-
> >>> include/acpi/video.h | 8 ++-
> >>> 28 files changed, 156 insertions(+), 84 deletions(-)
> >>
> >
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/module/test_dynamic_debug/parameters/$knob
> }
>
> CLS_1="FOO -FOO +FOO -FOO BAR -BAR +BAR -BAR BUZZ -BUZZ +BUZZ -BUZZ"
> CLS_2=" Foo Bar Buzz -Foo -Bar -Buzz +Foo +Bar +Buzz -Foo -Bar -Buzz"
> CLS_3=" bing bong boom -bing -bong -boom +bing +bong +boom -bin
On Mon, 16 May 2022 at 18:23, Leo Li wrote:
>
>
>
> On 2022-05-12 13:39, Daniel Vetter wrote:
> > On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David)
> > wrote:
> >>
> >> [AMD Official Use Only - General]
> >>
> >> Hi Daniel
&g
On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David)
wrote:
>
> [AMD Official Use Only - General]
>
> Hi Daniel
>
> Thanks for your comments and explanations. I replied in-line and look forward
> to more discussion.
>
> regards
> David
>
>
> From: Daniel V
> .../gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c | 2 +
> > .../dc/dcn30/dcn30_dio_stream_encoder.c | 15 ++
> > drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h | 1 +
> > .../drm/amd/display/dc/inc/hw/link_encoder.h | 21 +-
> > .../gpu/drm/amd/display/dmub/inc/dmub_cmd.
On Mon, May 09, 2022 at 05:01:33PM +0200, Christian König wrote:
> Am 09.05.22 um 16:31 schrieb Daniel Vetter:
> > On Wed, May 04, 2022 at 09:47:32AM +0200, Christian König wrote:
> > > [SNIP]
> > > +/* Make sure we have enough room and add an object the con
t; +#include "ttm_execbuf_util.h"
> #include "ttm_object.h"
>
> #include "vmwgfx_fence.h"
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> index f21df053882b..3613a3d52528 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> @@ -31,7 +31,7 @@
> #include
> #include
>
> -#include
> +#include "ttm_execbuf_util.h"
>
> #include "vmwgfx_hashtab.h"
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; +static inline bool drm_exec_has_duplicates(struct drm_exec *exec)
> +{
> + return exec->duplicates.num_objects > 0;
Definitely an aside, but in our i915 efforts to get rid of temporary pins
we run into some fun where the eviction code couldn't differentiate from
memory we need reserved for the CS and memory we just keep locked because
we evicted it and fun stuff like that. So maybe we need a bit more
tracking here eventually, but that's only when we have this somehow glued
into ttm eviction code.
Also the even more massive step would be to glue this into dma-buf so you
can do dynamic dma-buf eviction and still keep track of all the buffers. I
think with some clever pointer tagging and a bit more indirection we could
nest drm_exec structures (so that a driver could insert it's entire
drm_exec structure with a drm_exec-level callback for handling refcounting
and stuff like that).
So anyway I think this all looks good, just one more thing before I think
we should land this:
gem helpers in drm_gem_lock_reservations() has something which is
practically compatible already, except that you bulk-add the entire set of
objects. I think if you add a bulk-prepare function then we could also
replace all those. Maybe even nicer if the bulk-prepare takes the array of
handles and does the handle lookup too, but at least something which can
subsititue drm_gem_lock_reservations with drm_exec would be nice to
validate the helpers a bit more and really make sure we only have one of
them left.
Thoughts?
-Daniel
> +}
> +
> +void drm_exec_init(struct drm_exec *exec, bool interruptible);
> +void drm_exec_fini(struct drm_exec *exec);
> +bool drm_exec_cleanup(struct drm_exec *exec);
> +int drm_exec_prepare_obj(struct drm_exec *exec, struct drm_gem_object *obj,
> + unsigned int num_fences);
> +
> +#endif
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
abled) only kicks in when the refcount drops to zero.
Anyway nothing terrible, just more work to do here I guess, it's good to
drop the earlier approaches still.
On the series:
Acked-by: Daniel Vetter
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h
ng, tmp, >freed, list) {
> > if (mapping->flags & AMDGPU_PTE_PRT && prt_fini_needed) {
> > amdgpu_vm_prt_fini(adev, vm);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> > index 1a814fb8..c1a48f5c1019 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> > @@ -286,6 +286,7 @@ struct amdgpu_vm {
> >
> > /* Last finished delayed update */
> > atomic64_t tlb_seq;
> > + struct dma_fence*last_delayed_tlb_flush;
> >
> > /* Last unlocked submission to the scheduler entities */
> > struct dma_fence*last_unlocked;
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; this instead.
>
> Signed-off-by: Christian König
> Cc: amd-gfx@lists.freedesktop.org
It is honestly all getting rather blurry, I think when it's all landed I
need to audit the entire tree and see what we missed. Anyway:
Reviewed-by: Daniel Vetter
> ---
> drivers/dma-buf/dma
anymore.
> >
> > dEQP only exercises the soft reset. I think WebGL is only able to trigger
> > a soft reset at this point, but Vulkan can also trigger a hard reset.
> >
> > Marek
> > --
> > *From:* Koenig, Christian
> >
> > *S
s a bit much magic, but that's the entire point of your huge prep
series to be able to have all the fences on a dma-resv :-)
Reviewed-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-resv.c | 6 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 1 -
> drivers/gpu/drm/am
evice_delayed_init_work_handler(struct work_struct *work)
> > container_of(work, struct amdgpu_device,
> > delayed_init_work.work);
> > int r;
> > + mdelay(1);
> > +
> > r = amdgpu_ib_ring_tests(adev);
> > if (r)
> > DRM_ERROR("ib ring test failed (%d).\n", r);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
truct abm *abm) {
> > > + struct dce_abm *dce_abm = TO_DMUB_ABM(abm);
> > > + unsigned int backlight = REG_READ(BL1_PWM_CURRENT_ABM_LEVEL);
> > > + struct dc_context *dc = abm->ctx;
> > > + struct amdgpu_device *adev = dc->driver_context;
> > >
uess that could be added to the commit message, but also it's kinda
well known - the i915 patches also didn't explain why we want to
manage our vram with a buddy allocator (I think some of the earlier
versions explained it a bit, but the version with ttm integration that
landed didnt).
But yeah the confusing comments about hiding stuff that somehow
spilled over from other discussions into this didn't help :-/
-Daniel
> Thanks for jumping in here,
> Christian.
>
> >
> > Cheers,
> > Daniel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
is limited, i.e. requests
not currently on the gpu, or on different engines and all that
shouldn't be nuked, if possible.
Also ofc since msm uapi is that the kernel tries to recover there's
not much we can do there, contexts cannot be shot. But still trying to
replay them as much as possible
On Fri, Mar 18, 2022 at 08:12:54AM -0700, Rob Clark wrote:
> On Fri, Mar 18, 2022 at 12:42 AM Christian König
> wrote:
> >
> > Am 17.03.22 um 18:31 schrieb Rob Clark:
> > > On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote:
> > >> [SNIP]
> >
On Thu, Mar 17, 2022 at 08:40:51AM -0700, Rob Clark wrote:
> On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote:
> >
> > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote:
> > > Am 16.03.22 um 16:36 schrieb Rob Clark:
> > > > [SNIP]
>
On Thu, Mar 17, 2022 at 08:34:21AM -0700, Rob Clark wrote:
> On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote:
> >
> > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote:
> > > Am 16.03.22 um 16:36 schrieb Rob Clark:
> > > > [SNIP]
>
1 - 100 of 1246 matches
Mail list logo
