Re: [RESEND 3/3] drm/amd/display: switch to guid_gen() to generate valid GUIDs

[Daniel Vetter]

On Mon, Aug 12, 2024 at 03:23:12PM +0300, Jani Nikula wrote:
> Instead of just smashing jiffies into a GUID, use guid_gen() to generate
> RFC 4122 compliant GUIDs.
> 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Side note, it baffles me why amdgpu has a copy of this instead of
> plumbing it into drm mst code.

Yeah ec5fa9fcdeca ("drm/amd/display: Adjust the MST resume flow") promised
a follow-up, but that seems to have never materialized. Really should
materialize though. Patch lgtm

Reviewed-by: Daniel Vetter 


> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 72c10fc2c890..ce05e7e2a383 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2568,9 +2568,9 @@ static int dm_late_init(void *handle)
>  
>  static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr *mgr)
>  {
> + u8 buf[UUID_SIZE];
> + guid_t guid;
>   int ret;
> - u8 guid[16];
> - u64 tmp64;
>  
>   mutex_lock(&mgr->lock);
>   if (!mgr->mst_primary)
> @@ -2591,26 +2591,27 @@ static void resume_mst_branch_status(struct 
> drm_dp_mst_topology_mgr *mgr)
>   }
>  
>   /* Some hubs forget their guids after they resume */
> - ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
> - if (ret != 16) {
> + ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, buf, sizeof(buf));
> + if (ret != sizeof(buf)) {
>   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
> suspend?\n");
>   goto out_fail;
>   }
>  
> - if (memchr_inv(guid, 0, 16) == NULL) {
> - tmp64 = get_jiffies_64();
> - memcpy(&guid[0], &tmp64, sizeof(u64));
> - memcpy(&guid[8], &tmp64, sizeof(u64));
> + import_guid(&guid, buf);
>  
> - ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
> + if (guid_is_null(&guid)) {
> + guid_gen(&guid);
> + export_guid(buf, &guid);
>  
> - if (ret != 16) {
> + ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, buf, sizeof(buf));
> +
> + if (ret != sizeof(buf)) {
>   drm_dbg_kms(mgr->dev, "check mstb guid failed - 
> undocked during suspend?\n");
>   goto out_fail;
>   }
>   }
>  
> - import_guid(&mgr->mst_primary->guid, guid);
> + guid_copy(&mgr->mst_primary->guid, &guid);
>  
>  out_fail:
>   mutex_unlock(&mgr->lock);
> -- 
> 2.39.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RESEND 2/3] drm/mst: switch to guid_gen() to generate valid GUIDs

[Daniel Vetter]

On Mon, Aug 12, 2024 at 03:23:11PM +0300, Jani Nikula wrote:
> Instead of just smashing jiffies into a GUID, use guid_gen() to generate
> RFC 4122 compliant GUIDs.
> 
> Signed-off-by: Jani Nikula 

Read a bit the RFC, definitely sounds better than stuffing jiffies into
the guid ...

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 39f1dc45004e..38a9a1441e62 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -2700,18 +2700,10 @@ static void drm_dp_mst_queue_probe_work(struct 
> drm_dp_mst_topology_mgr *mgr)
>  static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
>guid_t *guid)
>  {
> - u64 salt;
> - u8 buf[UUID_SIZE];
> -
>   if (!guid_is_null(guid))
>   return true;
>  
> - salt = get_jiffies_64();
> -
> - memcpy(&buf[0], &salt, sizeof(u64));
> - memcpy(&buf[8], &salt, sizeof(u64));
> -
> - import_guid(guid, buf);
> + guid_gen(guid);
>  
>   return false;
>  }
> -- 
> 2.39.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RESEND 1/3] drm/mst: switch to guid_t type for GUID

[Daniel Vetter]

On Mon, Aug 12, 2024 at 03:23:10PM +0300, Jani Nikula wrote:
> The kernel has a guid_t type for GUIDs. Switch to using it, but avoid
> any functional changes here.
> 
> Signed-off-by: Jani Nikula 

I didn't cross-check everything, I'll trust the compiler on this. But
functionally lgtm

Reviewed-by: Daniel Vetter 

Reading code a bit I did wonder whether we could have send/receive macros
that just work for compile-time statically sized types ... but not even
kmalloc is there yet I think, at least haven't seen anything.
-Sima

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 67 +++
>  include/drm/display/drm_dp_mst_helper.h   | 12 ++--
>  3 files changed, 45 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 7e7929f24ae4..72c10fc2c890 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2610,7 +2610,7 @@ static void resume_mst_branch_status(struct 
> drm_dp_mst_topology_mgr *mgr)
>   }
>   }
>  
> - memcpy(mgr->mst_primary->guid, guid, 16);
> + import_guid(&mgr->mst_primary->guid, guid);
>  
>  out_fail:
>   mutex_unlock(&mgr->lock);
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 379a449a28a2..39f1dc45004e 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -89,7 +89,7 @@ static int drm_dp_send_enum_path_resources(struct 
> drm_dp_mst_topology_mgr *mgr,
>  struct drm_dp_mst_branch *mstb,
>  struct drm_dp_mst_port *port);
>  static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
> -  u8 *guid);
> +  guid_t *guid);
>  
>  static int drm_dp_mst_register_i2c_bus(struct drm_dp_mst_port *port);
>  static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port);
> @@ -801,7 +801,7 @@ static bool drm_dp_sideband_parse_link_address(const 
> struct drm_dp_mst_topology_
>   int idx = 1;
>   int i;
>  
> - memcpy(repmsg->u.link_addr.guid, &raw->msg[idx], 16);
> + import_guid(&repmsg->u.link_addr.guid, &raw->msg[idx]);
>   idx += 16;
>   repmsg->u.link_addr.nports = raw->msg[idx] & 0xf;
>   idx++;
> @@ -829,7 +829,7 @@ static bool drm_dp_sideband_parse_link_address(const 
> struct drm_dp_mst_topology_
>   idx++;
>   if (idx > raw->curlen)
>   goto fail_len;
> - memcpy(repmsg->u.link_addr.ports[i].peer_guid, 
> &raw->msg[idx], 16);
> + import_guid(&repmsg->u.link_addr.ports[i].peer_guid, 
> &raw->msg[idx]);
>   idx += 16;
>   if (idx > raw->curlen)
>   goto fail_len;
> @@ -1029,7 +1029,7 @@ static bool drm_dp_sideband_parse_reply(const struct 
> drm_dp_mst_topology_mgr *mg
>   msg->req_type = (raw->msg[0] & 0x7f);
>  
>   if (msg->reply_type == DP_SIDEBAND_REPLY_NAK) {
> - memcpy(msg->u.nak.guid, &raw->msg[1], 16);
> + import_guid(&msg->u.nak.guid, &raw->msg[1]);
>   msg->u.nak.reason = raw->msg[17];
>   msg->u.nak.nak_data = raw->msg[18];
>   return false;
> @@ -1078,7 +1078,7 @@ drm_dp_sideband_parse_connection_status_notify(const 
> struct drm_dp_mst_topology_
>   if (idx > raw->curlen)
>   goto fail_len;
>  
> - memcpy(msg->u.conn_stat.guid, &raw->msg[idx], 16);
> + import_guid(&msg->u.conn_stat.guid, &raw->msg[idx]);
>   idx += 16;
>   if (idx > raw->curlen)
>   goto fail_len;
> @@ -1107,7 +1107,7 @@ static bool 
> drm_dp_sideband_parse_resource_status_notify(const struct drm_dp_mst
>   if (idx > raw->curlen)
>   goto fail_len;
>  
> - memcpy(msg->u.resource_stat.guid, &raw->msg[idx], 16);
> + import_guid(&msg->u.resource_stat.guid, &raw->msg[idx]);
>   idx += 16;
>   if (idx > raw->curlen)
>   goto fail_len;
> @@ -2174,20 +2174,24 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
> offset, size, buffer);
>  }
>  
> -

Re: [pull] amdgpu, amdkfd, radeon, drm drm-next-6.12

[Daniel Vetter]

On Mon, Aug 26, 2024 at 04:15:26PM -0400, Alex Deucher wrote:
> Hi Dave, Sima,
> 
> New stuff for 6.12.
> 
> The following changes since commit 627a24f5f25d689682f395f3df1411273be4436b:
> 
>   Merge tag 'amd-drm-fixes-6.11-2024-07-18' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-next (2024-07-22 13:03:50 
> +1000)

I ignored some busted fixes sha1:

dim: 2dc3851ef7d9 ("drm/amdgpu/sdma5.2: limit wptr workaround to sdma 5.2.1"): 
Fixes: SHA1 in not pointing at an ancestor:
dim: a03ebf116303 ("drm/amdgpu/sdma5.2: Update wptr registers as well as 
doorbell")

I understand how this can happen in -fixes with cherry-pick, but in -next
it's a bit confusing. But pls don't rebase or the cherry-pick sha1 in
-fixes won't ever make sense :-)

Also I fixed a functional conflict with Christian's patch to drop
full_recovery from drm_sched_start, which landed through -misc. Please
double-check it's all looking good, and maybe backemerge (since I also
pulled in -rc5 with the conflicts with cherry-picks).

Pulled into drm-next, thanks.
-Sima

> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-6.12-2024-08-26
> 
> for you to fetch changes up to 3376f922bfe070eff762164b3fc66981e3079417:
> 
>   drm/amd/pm: Drop unsupported features on smu v14_0_2 (2024-08-23 10:55:22 
> -0400)
> 
> 
> amd-drm-next-6.12-2024-08-26:
> 
> amdgpu:
> - SDMA devcoredump support
> - DCN 4.0.1 updates
> - DC SUBVP fixes
> - Refactor OPP in DC
> - Refactor MMHUBBUB in DC
> - DC DML 2.1 updates
> - DC FAMS2 updates
> - RAS updates
> - GFX12 updates
> - VCN 4.0.3 updates
> - JPEG 4.0.3 updates
> - Enable wave kill (soft recovery) for compute queues
> - Clean up CP error interrupt handling
> - Enable CP bad opcode interrupts
> - VCN 4.x fixes
> - VCN 5.x fixes
> - GPU reset fixes
> - Fix vbios embedded EDID size handling
> - SMU 14.x updates
> - Misc code cleanups and spelling fixes
> - VCN devcoredump support
> - ISP MFD i2c support
> - DC vblank fixes
> - GFX 12 fixes
> - PSR fixes
> - Convert vbios embedded EDID to drm_edid
> - DCN 3.5 updates
> - DMCUB updates
> - Cursor fixes
> - Overdrive support for SMU 14.x
> - GFX CP padding optimizations
> - DCC fixes
> - DSC fixes
> - Preliminary per queue reset infrastructure
> - Initial per queue reset support for GFX 9
> - Initial per queue reset support for GFX 7, 8
> - DCN 3.2 fixes
> - DP MST fixes
> - SR-IOV fixes
> - GFX 9.4.3/4 devcoredump support
> - Add process isolation framework
> - Enable process isolation support for GFX 9.4.3/4
> - Take IOMMU remapping into account for P2P DMA checks
> 
> amdkfd:
> - CRIU fixes
> - Improved input validation for user queues
> - HMM fix
> - Enable process isolation support for GFX 9.4.3/4
> - Initial per queue reset support for GFX 9
> - Allow users to target recommended SDMA engines
> 
> radeon:
> - remove .load and drm_dev_alloc
> - Fix vbios embedded EDID size handling
> - Convert vbios embedded EDID to drm_edid
> - Use GEM references instead of TTM
> - r100 cp init cleanup
> - Fix potential overflows in evergreen CS offset tracking
> 
> UAPI:
> - KFD support for targetting queues on recommended SDMA engines
>   Proposed userspace:
>   
> https://github.com/ROCm/ROCR-Runtime/commit/2f588a24065f41c208c3701945e20be746d8faf7
>   
> https://github.com/ROCm/ROCR-Runtime/commit/eb30a5bbc7719c6ffcf2d2dd2878bc53a47b3f30
> 
> drm/buddy:
> - Add start address support for trim function
> 
> 
> Alex Deucher (47):
>   drm/amdgpu/sdma5.2: Update wptr registers as well as doorbell
>   drm/amdgpu/gfx7: enable wave kill for compute queues
>   drm/amdgpu/gfx8: enable wave kill for compute queues
>   drm/amdgpu/gfx9: enable wave kill for compute queues
>   drm/amdgpu/gfx9.4.3: implement wave kill for compute queues
>   drm/amdgpu/gfx10: enable wave kill for compute queues
>   drm/amdgpu/gfx11: enable wave kill for compute queues
>   drm/amdgpu/gfx12: enable wave kill for compute queues
>   drm/amdgpu/gfx10: properly handle error ints on all pipes
>   drm/amdgpu/gfx11: properly handle error ints on all pipes
>   drm/amdgpu/gfx12: properly handle error ints on all pipes
>   drm/amdgpu/gfx9: properly handle error ints on all pipes
>   drm/amdgpu/gfx: add bad opcode interrupt
>   drm/amdgpu/gfx9: Enable bad opcode interrupt
>   drm/amdgpu/gfx9.4.3: Enable bad opcode interrupt
>   drm/amdgpu: properly handle vbios fake edid sizing
>   drm/radeon: properly handle vbios fake edid sizing
>   drm/amdgpu: Fix APU handling in amdgpu_pm_load_smu_firmware()
>   drm/amdgpu/jpeg2: properly set atomics vmid field
>   drm/amdgpu/jpeg4: properly set atomics vmid field
>   drm/amdgpu/mes: add API for legacy queue reset
>   drm/amdgpu/mes11: add API for legacy queue reset
>   drm/amdgpu/mes12: add AP

Re: [PATCH 1/2] Documentation/gpu: Document the situation with unqualified drm-memory-

[Daniel Vetter]

On Thu, Aug 15, 2024 at 09:37:31AM +0100, Tvrtko Ursulin wrote:
> 
> On 13/08/2024 19:47, Rob Clark wrote:
> > On Tue, Aug 13, 2024 at 6:57 AM Tvrtko Ursulin  wrote:
> > > 
> > > From: Tvrtko Ursulin 
> > > 
> > > Currently it is not well defined what is drm-memory- compared to other
> > > categories.
> > > 
> > > In practice the only driver which emits these keys is amdgpu and in them
> > > exposes the current resident buffer object memory (including shared).
> > > 
> > > To prevent any confusion, document that drm-memory- is deprecated and an
> > > alias for drm-resident-memory-.
> > > 
> > > While at it also clarify that the reserved sub-string 'memory' refers to
> > > the memory region component, and also clarify the intended semantics of
> > > other memory categories.
> > > 
> > > v2:
> > >   * Also mark drm-memory- as deprecated.
> > >   * Add some more text describing memory categories. (Alex)
> > > 
> > > v3:
> > >   * Semantics of the amdgpu drm-memory is actually as drm-resident.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Alex Deucher 
> > > Cc: Christian König 
> > > Cc: Rob Clark 
> > 
> > Reviewed-by: Rob Clark 
> 
> Thanks!
> 
> So this one is stand alone and could be pushed to drm-misc-next.

fwiw on the series Acked-by: Daniel Vetter 

> 2/2 can wait for AMD to give a verdict.

Imo best to wait a bit, unless Alex takes a while to get around to this.
-Sima

> 
> Regards,
> 
> Tvrtko
> 
> > 
> > > ---
> > >   Documentation/gpu/drm-usage-stats.rst | 25 ++---
> > >   1 file changed, 22 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/Documentation/gpu/drm-usage-stats.rst 
> > > b/Documentation/gpu/drm-usage-stats.rst
> > > index a80f95ca1b2f..ff964c707754 100644
> > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > @@ -144,7 +144,9 @@ Memory
> > > 
> > >   Each possible memory type which can be used to store buffer objects by 
> > > the
> > >   GPU in question shall be given a stable and unique name to be returned 
> > > as the
> > > -string here.  The name "memory" is reserved to refer to normal system 
> > > memory.
> > > +string here.
> > > +
> > > +The region name "memory" is reserved to refer to normal system memory.
> > > 
> > >   Value shall reflect the amount of storage currently consumed by the 
> > > buffer
> > >   objects belong to this client, in the respective memory region.
> > > @@ -152,6 +154,9 @@ objects belong to this client, in the respective 
> > > memory region.
> > >   Default unit shall be bytes with optional unit specifiers of 'KiB' or 
> > > 'MiB'
> > >   indicating kibi- or mebi-bytes.
> > > 
> > > +This key is deprecated and is an alias for drm-resident-. Only 
> > > one of
> > > +the two should be present in the output.
> > > +
> > >   - drm-shared-:  [KiB|MiB]
> > > 
> > >   The total size of buffers that are shared with another file (e.g., have 
> > > more
> > > @@ -159,20 +164,34 @@ than a single handle).
> > > 
> > >   - drm-total-:  [KiB|MiB]
> > > 
> > > -The total size of buffers that including shared and private memory.
> > > +The total size of all created buffers including shared and private 
> > > memory. The
> > > +backing store for the buffers does not have to be currently instantiated 
> > > to be
> > > +counted under this category.
> > > 
> > >   - drm-resident-:  [KiB|MiB]
> > > 
> > > -The total size of buffers that are resident in the specified region.
> > > +The total size of buffers that are resident (have their backing store 
> > > present or
> > > +instantiated) in the specified region.
> > > +
> > > +This is an alias for drm-memory- and only one of the two should 
> > > be
> > > +present in the output.
> > > 
> > >   - drm-purgeable-:  [KiB|MiB]
> > > 
> > >   The total size of buffers that are purgeable.
> > > 
> > > +For example drivers which implement a form of 'madvise' like 
> > > functionality can
> > > +here count buffers which have instantiated backing store, but have been 
> > > marked
> > > +with an equivalent of MADV_DONTNEED.
> > > +
> > >   - drm-active-:  [KiB|MiB]
> > > 
> > >   The total size of buffers that are active on one or more engines.
> > > 
> > > +One practical example of this can be presence of unsignaled fences in an 
> > > GEM
> > > +buffer reservation object. Therefore the active category is a subset of
> > > +resident.
> > > +
> > >   Implementation Details
> > >   ==
> > > 
> > > --
> > > 2.44.0
> > > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 1/9] drm: Do delayed switcheroo in drm_lastclose()

[Daniel Vetter]

On Mon, Aug 12, 2024 at 12:41:39PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 12.08.24 um 12:18 schrieb Daniel Vetter:
> > On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote:
> > > > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from
> > > > their lastclose callbacks. Call it from drm_lastclose(), so that the
> > > > driver functions can finally be removed. Only PCI devices with enabled
> > > > switcheroo do the delayed switching. The call has no effect on other
> > > > hardware.
> > > > 
> > > > v2:
> > > > - move change to drm_lastclose() (Sima)
> > > > - update docs for vga_switcheroo_process_delayed_switch()
> > > > 
> > > > Signed-off-by: Thomas Zimmermann 
> > > A bit an aside: The entire vgaswitcheroo code is still a midlayer mess,
> > > where the locking is at the wrong layers resulting in the can_switch check
> > > potentially being racy. But that's a different can of worms.
> > Ok I got a bit annoyed about this mess again, and I think I have a
> > reasonable idea for how to address it. Not sure why this took a decade,
> > and definitely only pick this up if you're really bored.
> 
> No, definitely not. :) I don't think I have hardware for testing
> vga_switcheroo. Does this still exist? It seemed to be a thing of the 2000s.

Yeah good chances the old style switcheroo doesn't have many, if any users
left ...
-Sima

> 
> Best regards
> Thomas
> 
> > 
> > - We add a new vga_switcheroo_client_tryget, which checks the current
> >state, and if it's on, increments a newly added refcount (which vgw
> >switheroo maintains). Otherwise it fails. Drivers call this from their
> >drm_driver->open hook. This check also allows us to drop the
> >layer-violating checks in drm_open_helper for drm_dev->dev_power_state.
> > 
> > - That refcount is dropped with vga_switcheroo_client_put, called from
> >drm_driver->close. If the refcount drops to 0 this function also does
> >delayed switch processing.
> > 
> > - All the can_switch callbacks get removed and instead the vgwswr code
> >directly consults its own refount.
> > 
> > With this we don't have locking inversions anymore, and the old vgw
> > switcheroo code works a lot more like the new mode based on runtime pm and
> > power domains.
> > 
> > With a bit more shuffling I think we can also ditch
> > drm_driver->dev_power_state:
> > 
> > - There's one in the intel backlight code, which is annoying, since it's
> >wants to know whether the current callchain is from a vga switcheroo
> >state change. But doable with a little helper.
> > 
> > - Most others just want a vga_switcheroo_client_is_off() helper, which
> >should be easy. Some are even entirely redundant, at least from a cursor
> >callchain check. There's no races for these because they only matter
> >during system suspend, since you should not mix both runtime and classic
> >vgaswitcheroo logic. We might want some checks for that in that new
> >helper ...
> > 
> > - The one in the fbdev code is annoying, because it's another race.
> >Ideally instead of that check it needs a call to
> >vga_switcheroo_client_tryget/put just around the call to restore modes
> >(we do not want fbdev to block state switches), but that probably means
> >wiring a new callback through drm_client to drivers.
> > 
> > - Might have missed a special case ...
> > 
> > Anyway, I got nerdsniped, had an idea, figured best to type it up. Maybe
> > we want to add a link to this to todo.rst, I think we have a vgaswitcheroo
> > entry already.
> > 
> > Cheers, Sima
> > 
> > 
> > > Reviewed-by: Daniel Vetter 
> > > 
> > > > ---
> > > >   drivers/gpu/drm/drm_file.c   | 4 
> > > >   drivers/gpu/vga/vga_switcheroo.c | 3 +--
> > > >   2 files changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > > > index 714e42b05108..513bef816ae9 100644
> > > > --- a/drivers/gpu/drm/drm_file.c
> > > > +++ b/drivers/gpu/drm/drm_file.c
> > > > @@ -38,6 +38,7 @@
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > +#include 
> > > >   #include 
>

Re: [PATCH v2 1/9] drm: Do delayed switcheroo in drm_lastclose()

[Daniel Vetter]

On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote:
> On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote:
> > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from
> > their lastclose callbacks. Call it from drm_lastclose(), so that the
> > driver functions can finally be removed. Only PCI devices with enabled
> > switcheroo do the delayed switching. The call has no effect on other
> > hardware.
> > 
> > v2:
> > - move change to drm_lastclose() (Sima)
> > - update docs for vga_switcheroo_process_delayed_switch()
> > 
> > Signed-off-by: Thomas Zimmermann 
> 
> A bit an aside: The entire vgaswitcheroo code is still a midlayer mess,
> where the locking is at the wrong layers resulting in the can_switch check
> potentially being racy. But that's a different can of worms.

Ok I got a bit annoyed about this mess again, and I think I have a
reasonable idea for how to address it. Not sure why this took a decade,
and definitely only pick this up if you're really bored.

- We add a new vga_switcheroo_client_tryget, which checks the current
  state, and if it's on, increments a newly added refcount (which vgw
  switheroo maintains). Otherwise it fails. Drivers call this from their
  drm_driver->open hook. This check also allows us to drop the
  layer-violating checks in drm_open_helper for drm_dev->dev_power_state.

- That refcount is dropped with vga_switcheroo_client_put, called from
  drm_driver->close. If the refcount drops to 0 this function also does
  delayed switch processing.

- All the can_switch callbacks get removed and instead the vgwswr code
  directly consults its own refount.

With this we don't have locking inversions anymore, and the old vgw
switcheroo code works a lot more like the new mode based on runtime pm and
power domains.

With a bit more shuffling I think we can also ditch
drm_driver->dev_power_state:

- There's one in the intel backlight code, which is annoying, since it's
  wants to know whether the current callchain is from a vga switcheroo
  state change. But doable with a little helper.

- Most others just want a vga_switcheroo_client_is_off() helper, which
  should be easy. Some are even entirely redundant, at least from a cursor
  callchain check. There's no races for these because they only matter
  during system suspend, since you should not mix both runtime and classic
  vgaswitcheroo logic. We might want some checks for that in that new
  helper ...

- The one in the fbdev code is annoying, because it's another race.
  Ideally instead of that check it needs a call to
  vga_switcheroo_client_tryget/put just around the call to restore modes
  (we do not want fbdev to block state switches), but that probably means
  wiring a new callback through drm_client to drivers.

- Might have missed a special case ...

Anyway, I got nerdsniped, had an idea, figured best to type it up. Maybe
we want to add a link to this to todo.rst, I think we have a vgaswitcheroo
entry already.

Cheers, Sima


> 
> Reviewed-by: Daniel Vetter 
> 
> > ---
> >  drivers/gpu/drm/drm_file.c   | 4 
> >  drivers/gpu/vga/vga_switcheroo.c | 3 +--
> >  2 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index 714e42b05108..513bef816ae9 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -38,6 +38,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -404,6 +405,9 @@ void drm_lastclose(struct drm_device * dev)
> > drm_dbg_core(dev, "driver lastclose completed\n");
> >  
> > drm_client_dev_restore(dev);
> > +
> > +   if (dev_is_pci(dev->dev))
> > +   vga_switcheroo_process_delayed_switch();
> >  }
> >  
> >  /**
> > diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> > b/drivers/gpu/vga/vga_switcheroo.c
> > index 365e6ddbe90f..18f2c92beff8 100644
> > --- a/drivers/gpu/vga/vga_switcheroo.c
> > +++ b/drivers/gpu/vga/vga_switcheroo.c
> > @@ -926,8 +926,7 @@ static void vga_switcheroo_debugfs_init(struct 
> > vgasr_priv *priv)
> >  /**
> >   * vga_switcheroo_process_delayed_switch() - helper for delayed switching
> >   *
> > - * Process a delayed switch if one is pending. DRM drivers should call this
> > - * from their ->lastclose callback.
> > + * Process a delayed switch if one is pending.
> >   *
> >   * Return: 0 on success. -EINVAL if no delayed switch is pending, if the 
> > client
> >   * has unregistered in the meantime or if there are other clients blocking 
> > the
> > -- 
> > 2.46.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 7/9] drm/fbdev-helper: Remove drm_fb_helper_output_poll_changed()

[Daniel Vetter]

On Mon, Aug 12, 2024 at 10:28:28AM +0200, Thomas Zimmermann wrote:
> The function is unused. Remove it.
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 15 ---
>  include/drm/drm_fb_helper.h |  6 --
>  2 files changed, 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fe5667477839..29c53f9f449c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2003,18 +2003,3 @@ void drm_fb_helper_lastclose(struct drm_device *dev)
>   drm_fb_helper_restore_fbdev_mode_unlocked(dev->fb_helper);
>  }
>  EXPORT_SYMBOL(drm_fb_helper_lastclose);
> -
> -/**
> - * drm_fb_helper_output_poll_changed - DRM mode config \.output_poll_changed
> - * helper for fbdev emulation
> - * @dev: DRM device
> - *
> - * This function can be used as the
> - * &drm_mode_config_funcs.output_poll_changed callback for drivers that only
> - * need to call drm_fbdev.hotplug_event().
> - */
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> - drm_fb_helper_hotplug_event(dev->fb_helper);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 375737fd6c36..699f2790b9ac 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -271,9 +271,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
> *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_debug_enter(struct fb_info *info);
>  int drm_fb_helper_debug_leave(struct fb_info *info);
> -
>  void drm_fb_helper_lastclose(struct drm_device *dev);
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev);
>  #else
>  static inline void drm_fb_helper_prepare(struct drm_device *dev,
>struct drm_fb_helper *helper,
> @@ -401,10 +399,6 @@ static inline int drm_fb_helper_debug_leave(struct 
> fb_info *info)
>  static inline void drm_fb_helper_lastclose(struct drm_device *dev)
>  {
>  }
> -
> -static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> -}
>  #endif
>  
>  #endif
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 6/9] drm/fbdev-helper: Update documentation on obsolete callbacks

[Daniel Vetter]

On Mon, Aug 12, 2024 at 10:28:27AM +0200, Thomas Zimmermann wrote:
> The old callbacks lastclose and output_poll_changed are deprecated and
> unused. Remove them from the documentation.
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 22 +++---
>  1 file changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 3f7da78849e4..fe5667477839 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -89,14 +89,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
>   * interfaces. Drivers that use one of the shared memory managers, TTM, 
> SHMEM,
>   * DMA, should instead use the corresponding fbdev emulation.
>   *
> - * Existing fbdev implementations should restore the fbdev console by using
> - * drm_fb_helper_lastclose() as their &drm_driver.lastclose callback.
> - * They should also notify the fb helper code from updates to the output
> - * configuration by using drm_fb_helper_output_poll_changed() as their
> - * &drm_mode_config_funcs.output_poll_changed callback. New implementations
> - * of fbdev should be build on top of struct &drm_client_funcs, which handles
> - * this automatically. Setting the old callbacks should be avoided.
> - *
>   * For suspend/resume consider using drm_mode_config_helper_suspend() and
>   * drm_mode_config_helper_resume() which takes care of fbdev as well.
>   *
> @@ -260,12 +252,12 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct 
> drm_fb_helper *fb_helper,
>   * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
>   * @fb_helper: driver-allocated fbdev helper, can be NULL
>   *
> - * This should be called from driver's drm &drm_driver.lastclose callback
> - * when implementing an fbcon on top of kms using this helper. This ensures 
> that
> - * the user isn't greeted with a black screen when e.g. X dies.
> + * This helper should be called from fbdev emulation's 
> &drm_client_funcs.restore
> + * callback. It ensures that the user isn't greeted with a black screen when 
> the
> + * userspace compositor releases the display device.
>   *
> - * RETURNS:
> - * Zero if everything went ok, negative error code otherwise.
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
>   */
>  int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
> *fb_helper)
>  {
> @@ -2003,8 +1995,8 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
>   * drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev emulation
>   * @dev: DRM device
>   *
> - * This function can be used as the &drm_driver->lastclose callback for 
> drivers
> - * that only need to call drm_fb_helper_restore_fbdev_mode_unlocked().
> + * This function is obsolete. Call 
> drm_fb_helper_restore_fbdev_mode_unlocked()
> + * instead.
>   */
>  void drm_fb_helper_lastclose(struct drm_device *dev)
>  {
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 3/9] drm/nouveau: Do not set struct drm_driver.lastclose

[Daniel Vetter]

On Mon, Aug 12, 2024 at 10:28:24AM +0200, Thomas Zimmermann wrote:
> Remove the implementation of struct drm_driver.lastclose. The hook
> was only necessary before in-kernel DRM clients existed, but is now
> obsolete. The code in nouveau_vga_lastclose() is performed by
> drm_lastclose().
> 
> v2:
> - update commit description
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
>  drivers/gpu/drm/nouveau/nouveau_vga.c | 7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.h | 1 -
>  3 files changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index ac7c60fb14d3..4a9a9b9c3935 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -1303,7 +1303,6 @@ driver_stub = {
>  DRIVER_RENDER,
>   .open = nouveau_drm_open,
>   .postclose = nouveau_drm_postclose,
> - .lastclose = nouveau_vga_lastclose,
>  
>  #if defined(CONFIG_DEBUG_FS)
>   .debugfs_init = nouveau_drm_debugfs_init,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index 2525e08938b3..ee637f1fe03d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -127,10 +127,3 @@ nouveau_vga_fini(struct nouveau_drm *drm)
>   if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
>   vga_switcheroo_fini_domain_pm_ops(drm->dev->dev);
>  }
> -
> -
> -void
> -nouveau_vga_lastclose(struct drm_device *dev)
> -{
> - vga_switcheroo_process_delayed_switch();
> -}
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.h 
> b/drivers/gpu/drm/nouveau/nouveau_vga.h
> index 951a83f984dd..63be415d2a44 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.h
> @@ -4,6 +4,5 @@
>  
>  void nouveau_vga_init(struct nouveau_drm *);
>  void nouveau_vga_fini(struct nouveau_drm *);
> -void nouveau_vga_lastclose(struct drm_device *dev);
>  
>  #endif
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 2/9] drm/amdgpu: Do not set struct drm_driver.lastclose

[Daniel Vetter]

On Mon, Aug 12, 2024 at 10:28:23AM +0200, Thomas Zimmermann wrote:
> Remove the implementation of struct drm_driver.lastclose. The hook
> was only necessary before in-kernel DRM clients existed, but is now
> obsolete. The code in amdgpu_driver_lastclose_kms() is performed by
> drm_lastclose().
> 
> v2:
> - update commit message
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 17 -
>  3 files changed, 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 137a88b8de45..4baeb6519fda 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1484,7 +1484,6 @@ extern const int amdgpu_max_kms_ioctl;
>  
>  int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
>  void amdgpu_driver_unload_kms(struct drm_device *dev);
> -void amdgpu_driver_lastclose_kms(struct drm_device *dev);
>  int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file 
> *file_priv);
>  void amdgpu_driver_postclose_kms(struct drm_device *dev,
>struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 094498a0964b..5dd39e6c6223 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2953,7 +2953,6 @@ static const struct drm_driver amdgpu_kms_driver = {
>   DRIVER_SYNCOBJ_TIMELINE,
>   .open = amdgpu_driver_open_kms,
>   .postclose = amdgpu_driver_postclose_kms,
> - .lastclose = amdgpu_driver_lastclose_kms,
>   .ioctls = amdgpu_ioctls_kms,
>   .num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
>   .dumb_create = amdgpu_mode_dumb_create,
> @@ -2980,7 +2979,6 @@ const struct drm_driver amdgpu_partition_driver = {
>   DRIVER_SYNCOBJ_TIMELINE,
>   .open = amdgpu_driver_open_kms,
>   .postclose = amdgpu_driver_postclose_kms,
> - .lastclose = amdgpu_driver_lastclose_kms,
>   .ioctls = amdgpu_ioctls_kms,
>   .num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
>   .dumb_create = amdgpu_mode_dumb_create,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 66782be5917b..0a799942343d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1269,23 +1269,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
>   return 0;
>  }
>  
> -
> -/*
> - * Outdated mess for old drm with Xorg being in charge (void function now).
> - */
> -/**
> - * amdgpu_driver_lastclose_kms - drm callback for last close
> - *
> - * @dev: drm dev pointer
> - *
> - * Switch vga_switcheroo state after last close (all asics).
> - */
> -void amdgpu_driver_lastclose_kms(struct drm_device *dev)
> -{
> - drm_fb_helper_lastclose(dev);
> - vga_switcheroo_process_delayed_switch();
> -}
> -
>  /**
>   * amdgpu_driver_open_kms - drm callback for open
>   *
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 1/9] drm: Do delayed switcheroo in drm_lastclose()

[Daniel Vetter]

On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote:
> Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from
> their lastclose callbacks. Call it from drm_lastclose(), so that the
> driver functions can finally be removed. Only PCI devices with enabled
> switcheroo do the delayed switching. The call has no effect on other
> hardware.
> 
> v2:
> - move change to drm_lastclose() (Sima)
> - update docs for vga_switcheroo_process_delayed_switch()
> 
> Signed-off-by: Thomas Zimmermann 

A bit an aside: The entire vgaswitcheroo code is still a midlayer mess,
where the locking is at the wrong layers resulting in the can_switch check
potentially being racy. But that's a different can of worms.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_file.c   | 4 
>  drivers/gpu/vga/vga_switcheroo.c | 3 +--
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 714e42b05108..513bef816ae9 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -404,6 +405,9 @@ void drm_lastclose(struct drm_device * dev)
>   drm_dbg_core(dev, "driver lastclose completed\n");
>  
>   drm_client_dev_restore(dev);
> +
> + if (dev_is_pci(dev->dev))
> + vga_switcheroo_process_delayed_switch();
>  }
>  
>  /**
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index 365e6ddbe90f..18f2c92beff8 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -926,8 +926,7 @@ static void vga_switcheroo_debugfs_init(struct vgasr_priv 
> *priv)
>  /**
>   * vga_switcheroo_process_delayed_switch() - helper for delayed switching
>   *
> - * Process a delayed switch if one is pending. DRM drivers should call this
> - * from their ->lastclose callback.
> + * Process a delayed switch if one is pending.
>   *
>   * Return: 0 on success. -EINVAL if no delayed switch is pending, if the 
> client
>   * has unregistered in the meantime or if there are other clients blocking 
> the
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 8/8] drm: Remove struct drm_mode_config_funcs.output_poll_changed

[Daniel Vetter]

On Wed, Aug 07, 2024 at 10:41:40AM +0200, Thomas Zimmermann wrote:
> The output_poll_changed hook in struct drm_mode_config_funcs is
> unused. Remove it. The helper drm_client_dev_hotplug() implements
> the callback's functionality.
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_probe_helper.c | 10 +-
>  include/drm/drm_mode_config.h  | 16 
>  2 files changed, 1 insertion(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 285290067056..92f21764246f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -714,7 +714,7 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
>   * @dev: drm_device whose connector state changed
>   *
>   * This function fires off the uevent for userspace and also calls the
> - * output_poll_changed function, which is most commonly used to inform the 
> fbdev
> + * client hotplug function, which is most commonly used to inform the fbdev
>   * emulation code and allow it to update the fbcon output configuration.
>   *
>   * Drivers should call this from their hotplug handling code when a change is
> @@ -730,11 +730,7 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
>   */
>  void drm_kms_helper_hotplug_event(struct drm_device *dev)
>  {
> - /* send a uevent + call fbdev */
>   drm_sysfs_hotplug_event(dev);
> - if (dev->mode_config.funcs->output_poll_changed)
> - dev->mode_config.funcs->output_poll_changed(dev);
> -
>   drm_client_dev_hotplug(dev);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_hotplug_event);
> @@ -750,11 +746,7 @@ void drm_kms_helper_connector_hotplug_event(struct 
> drm_connector *connector)
>  {
>   struct drm_device *dev = connector->dev;
>  
> - /* send a uevent + call fbdev */
>   drm_sysfs_connector_hotplug_event(connector);
> - if (dev->mode_config.funcs->output_poll_changed)
> - dev->mode_config.funcs->output_poll_changed(dev);
> -
>   drm_client_dev_hotplug(dev);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_connector_hotplug_event);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab0f167474b1..271765e2e9f2 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -97,22 +97,6 @@ struct drm_mode_config_funcs {
>*/
>   const struct drm_format_info *(*get_format_info)(const struct 
> drm_mode_fb_cmd2 *mode_cmd);
>  
> - /**
> -  * @output_poll_changed:
> -  *
> -  * Callback used by helpers to inform the driver of output configuration
> -  * changes.
> -  *
> -  * Drivers implementing fbdev emulation use 
> drm_kms_helper_hotplug_event()
> -  * to call this hook to inform the fbdev helper of output changes.
> -  *
> -  * This hook is deprecated, drivers should instead implement fbdev
> -  * support with struct drm_client, which takes care of any necessary
> -  * hotplug event forwarding already without further involvement by
> -  * the driver.
> -  */
> - void (*output_poll_changed)(struct drm_device *dev);
> -
>   /**
>* @mode_valid:
>*
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 6/8] drm/fbdev-helper: Remove drm_fb_helper_output_poll_changed()

[Daniel Vetter]

On Wed, Aug 07, 2024 at 10:41:38AM +0200, Thomas Zimmermann wrote:
> The function is unused. Remove it.
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

Without the next patch to remove ->lastclose there's some confusion text
left in the DOC: section in drm_fb_helper.c, but no point to split that up
perfectly imo. Was just trying to find it and didn't find it only looking
at the poll_changed patches ...
-Sima

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 15 ---
>  include/drm/drm_fb_helper.h |  6 --
>  2 files changed, 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6667dfba8a2..3cafb28236f7 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2015,18 +2015,3 @@ void drm_fb_helper_lastclose(struct drm_device *dev)
>  
>  }
>  EXPORT_SYMBOL(drm_fb_helper_lastclose);
> -
> -/**
> - * drm_fb_helper_output_poll_changed - DRM mode config \.output_poll_changed
> - * helper for fbdev emulation
> - * @dev: DRM device
> - *
> - * This function can be used as the
> - * &drm_mode_config_funcs.output_poll_changed callback for drivers that only
> - * need to call drm_fbdev.hotplug_event().
> - */
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> - drm_fb_helper_hotplug_event(dev->fb_helper);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 375737fd6c36..699f2790b9ac 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -271,9 +271,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
> *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_debug_enter(struct fb_info *info);
>  int drm_fb_helper_debug_leave(struct fb_info *info);
> -
>  void drm_fb_helper_lastclose(struct drm_device *dev);
> -void drm_fb_helper_output_poll_changed(struct drm_device *dev);
>  #else
>  static inline void drm_fb_helper_prepare(struct drm_device *dev,
>struct drm_fb_helper *helper,
> @@ -401,10 +399,6 @@ static inline int drm_fb_helper_debug_leave(struct 
> fb_info *info)
>  static inline void drm_fb_helper_lastclose(struct drm_device *dev)
>  {
>  }
> -
> -static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev)
> -{
> -}
>  #endif
>  
>  #endif
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 5/8] drm/nouveau: Implement switcheroo reprobe with drm_client_dev_hotplug()

[Daniel Vetter]

On Wed, Aug 07, 2024 at 10:41:37AM +0200, Thomas Zimmermann wrote:
> Replace the callto drm_fb_helper_output_poll_changed() with a call
> to drm_client_dev_hotplug(). It's equivalent in functionality, but
> use the DRM client infrastructure.
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index ee637f1fe03d..ab4e11dc0b8a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -58,8 +58,9 @@ static void
>  nouveau_switcheroo_reprobe(struct pci_dev *pdev)
>  {
>   struct nouveau_drm *drm = pci_get_drvdata(pdev);
> + struct drm_device *dev = drm->dev;
>  
> - drm_fb_helper_output_poll_changed(drm->dev);
> + drm_client_dev_hotplug(dev);
>  }
>  
>  static bool
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 4/8] drm/nouveau: Do not set struct drm_mode_config_funcs.output_poll_changed

[Daniel Vetter]

On Wed, Aug 07, 2024 at 10:41:36AM +0200, Thomas Zimmermann wrote:
> The output_poll_changed hook was only necessary before in-kernel
> DRM clients existed, but is now obsolete. The client code handles
> display otplugging internally.
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 1 -
>  drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index e4c8ce6dd40a..eed579a6c858 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2648,7 +2648,6 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev)
>  static const struct drm_mode_config_funcs
>  nv50_disp_func = {
>   .fb_create = nouveau_user_framebuffer_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
>   .atomic_check = nv50_disp_atomic_check,
>   .atomic_commit = nv50_disp_atomic_commit,
>   .atomic_state_alloc = nv50_disp_atomic_state_alloc,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 8a87e9697a42..e2fd561cd23f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -391,7 +391,6 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
>  
>  static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
>   .fb_create = nouveau_user_framebuffer_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
>  };
>  
>  
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/8] drm/fbdev-helper: Do delayed switcheroo in lastclose helper

[Daniel Vetter]

On Wed, Aug 07, 2024 at 10:41:33AM +0200, Thomas Zimmermann wrote:
> Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from
> their lastclose callbacks. Call it from the fbdev lastclose helper,
> so that the driver functions can finally be removed.
> 
> The fbdev call is part of all lastclose handling that restores the
> DRM fbcon terminal. Only PCI devices with enabled switcheroo do the
> delayed switching. The call has no effect on other drivers.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 3f7da78849e4..f6667dfba8a2 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2009,6 +2009,10 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
>  void drm_fb_helper_lastclose(struct drm_device *dev)
>  {
>   drm_fb_helper_restore_fbdev_mode_unlocked(dev->fb_helper);
> +
> + if (dev_is_pci(dev->dev))
> + vga_switcheroo_process_delayed_switch();

I think if you want to move this, it needs to be in drm core. Otherwise
the vgaswitcheroo delayed switching stops working if you disable fbdev
support. Which doesn't make much sense.
-Sima

> +
>  }
>  EXPORT_SYMBOL(drm_fb_helper_lastclose);
>  
> -- 
> 2.46.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 0/2] drm: minimum backlight overrides and implementation for amdgpu

[Daniel Vetter]

On Wed, Jul 31, 2024 at 08:40:12PM +0300, Jani Nikula wrote:
> On Wed, 31 Jul 2024, Thomas Weißschuh  wrote:
> > The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> > is "12". This leads to a fairly bright minimum display backlight.
> >
> > Add a generic override helper for the user to override the settings
> > provided by the firmware through the kernel cmdline.
> > Also add amdgpu as a user of that helper.
> >
> > One solution would be a fixed firmware version, which was announced but
> > has no timeline.
> 
> The flip side is that if we add this now, it pretty much has a timeline:
> We'll have to carry and support it forever.
> 
> It's not a great prospect for something so specific. Not to mention that
> the limits are generally there for electrical minimums that should not
> be overridden. And before you know it, we'll have bug reports about
> flickering screens...

Yeah I think for this specific case where a fixed firmware is already
kinda promised, a quirk is the right fix. Otherwise we open up a can of
worms here ... so personally I like v2 a lot more.
-Sima

> 
> BR,
> Jani.
> 
> 
> >
> > This helper does conflict with the mode override via the cmdline.
> > Only one can be specified.
> > IMO the mode override can be extended to also handle "min-brightness"
> > when that becomes necessary.
> >
> > ---
> > Changes in v3:
> > - Switch to cmdline override parameter
> > - Link to v2: 
> > https://lore.kernel.org/r/20240623-amdgpu-min-backlight-quirk-v2-0-cecf7f49d...@weissschuh.net
> >
> > Changes in v2:
> > - Introduce proper drm backlight quirk infrastructure
> > - Quirk by EDID and DMI instead of only DMI
> > - Limit quirk to only single Framework 13 matte panel
> > - Link to v1: 
> > https://lore.kernel.org/r/20240610-amdgpu-min-backlight-quirk-v1-1-8459895a5...@weissschuh.net
> >
> > ---
> > Thomas Weißschuh (2):
> >   drm/connector: add drm_connector_get_cmdline_min_brightness_override()
> >   drm/amd/display: implement minimum brightness override
> >
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 
> >  drivers/gpu/drm/drm_connector.c   | 34 
> > +++++++
> >  include/drm/drm_connector.h   |  2 ++
> >  3 files changed, 42 insertions(+)
> > ---
> > base-commit: 36821612eb3091a21f7f4a907b497064725080c3
> > change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
> >
> > Best regards,
> 
> -- 
> Jani Nikula, Intel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/sched: add optional errno to drm_sched_start()

[Daniel Vetter]

On Tue, Jul 30, 2024 at 02:06:08PM +0200, Christian König wrote:
> Am 30.07.24 um 10:36 schrieb Daniel Vetter:
> > > In the end you have a really nice circle dependency.
> > Maybe a follow up, so for arb robustness or vk context where we want the
> > context to die and refuse to accept any more jobs: We can get at that
> > error somehow? I think that's really the only worry I have with a job
> > error approach for all this ...
> 
> See drm_sched_entity_error(). The idea is that the driver uses this function
> in two ways:

Ah that's the other piece I missed ...

> 1. In it's prepare callback so that when one submission fails all following
> from the same ctx are marked with an error number as well.
> 
> This is intentionally done in a driver callback so that driver decides if
> they want subsequent submissions to fail or not. That can be helpful for
> example for in kernel paging queues where submissions don't depend on each
> other and a failed submission shouldn't cancel all following.
> 
> For an example see amdgpu_job_prepare_job().
> 
> 2. In it's submission IOCTL to reject new submissions and inform userspace
> that it needs to kick of some error handling.

Would be good to add that to the docs, I think just one sentence in the
drm_sched_start should fish out the errno with drm_sched_entity_error()
would have avoided my confusion.

Plus I think your above text would make a good addition to the kerneldoc
for drm_sched_entity_error() itself.

Cheers, Sima

> 
> Cheers,
> Christian.
> 
> > 
> > > > If we really want to stuff this into per-job fences then I think we 
> > > > should
> > > > at least try to document this mess in the sync_file uapi, for a bit of
> > > > consistency.
> > > Good point. Going to add some documentation.
> > Sounds good.
> > 
> > Cheers, Sima
> > 
> > > Regards,
> > > Christian.
> > > 
> > > > But yeah without the full picture no idea really what we want here.
> > > > -Sima
> > > > 
> > > > > ---
> > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
> > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 4 ++--
> > > > >drivers/gpu/drm/etnaviv/etnaviv_sched.c | 4 ++--
> > > > >drivers/gpu/drm/imagination/pvr_queue.c | 4 ++--
> > > > >drivers/gpu/drm/lima/lima_sched.c   | 2 +-
> > > > >drivers/gpu/drm/nouveau/nouveau_sched.c | 2 +-
> > > > >drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> > > > >drivers/gpu/drm/panthor/panthor_mmu.c   | 2 +-
> > > > >drivers/gpu/drm/scheduler/sched_main.c  | 7 ---
> > > > >drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
> > > > >include/drm/gpu_scheduler.h | 2 +-
> > > > >11 files changed, 17 insertions(+), 16 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c 
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > > > > index 2320df51c914..18135d8235f9 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > > > > @@ -300,7 +300,7 @@ static int 
> > > > > suspend_resume_compute_scheduler(struct amdgpu_device *adev, bool sus
> > > > >   if (r)
> > > > >   goto out;
> > > > >   } else {
> > > > > - drm_sched_start(&ring->sched);
> > > > > + drm_sched_start(&ring->sched, 0);
> > > > >   }
> > > > >   }
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > index c186fdb198ad..861827deb03f 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > @@ -5862,7 +5862,7 @@ int amdgpu_device_gpu_recover(struct 
> > > > > amdgpu_device *adev,
> > > > >   if (!amdgpu_ring_sched_ready(ring))
> > > > >   continue;
> > > > > - drm_sched_start

Re: [PATCH] drm/sched: add optional errno to drm_sched_start()

[Daniel Vetter]

On Mon, Jul 29, 2024 at 08:43:05PM +0200, Christian König wrote:
> Am 26.07.24 um 16:21 schrieb Daniel Vetter:
> > On Fri, Jul 26, 2024 at 09:55:50AM +0200, Christian König wrote:
> > > The current implementation of drm_sched_start uses a hardcoded
> > > -ECANCELED to dispose of a job when the parent/hw fence is NULL.
> > > This results in drm_sched_job_done being called with -ECANCELED for
> > > each job with a NULL parent in the pending list, making it difficult
> > > to distinguish between recovery methods, whether a queue reset or a
> > > full GPU reset was used.
> > > 
> > > To improve this, we first try a soft recovery for timeout jobs and
> > > use the error code -ENODATA. If soft recovery fails, we proceed with
> > > a queue reset, where the error code remains -ENODATA for the job.
> > > Finally, for a full GPU reset, we use error codes -ECANCELED or
> > > -ETIME. This patch adds an error code parameter to drm_sched_start,
> > > allowing us to differentiate between queue reset and GPU reset
> > > failures. This enables user mode and test applications to validate
> > > the expected correctness of the requested operation. After a
> > > successful queue reset, the only way to continue normal operation is
> > > to call drm_sched_job_done with the specific error code -ENODATA.
> > > 
> > > v1: Initial implementation by Jesse utilized 
> > > amdgpu_device_lock_reset_domain
> > >  and amdgpu_device_unlock_reset_domain to allow user mode to track
> > >  the queue reset status and distinguish between queue reset and
> > >  GPU reset.
> > > v2: Christian suggested using the error codes -ENODATA for queue reset
> > >  and -ECANCELED or -ETIME for GPU reset, returned to
> > >  amdgpu_cs_wait_ioctl.
> > > v3: To meet the requirements, we introduce a new function
> > >  drm_sched_start_ex with an additional parameter to set
> > >  dma_fence_set_error, allowing us to handle the specific error
> > >  codes appropriately and dispose of bad jobs with the selected
> > >  error code depending on whether it was a queue reset or GPU reset.
> > > v4: Alex suggested using a new name, drm_sched_start_with_recovery_error,
> > >  which more accurately describes the function's purpose.
> > >  Additionally, it was recommended to add documentation details
> > >  about the new method.
> > > v5: Fixed declaration of new function 
> > > drm_sched_start_with_recovery_error.(Alex)
> > > v6 (chk): rebase on upstream changes, cleanup the commit message,
> > >drop the new function again and update all callers,
> > >apply the errno also to scheduler fences with hw fences
> > > 
> > > Signed-off-by: Jesse Zhang 
> > > Signed-off-by: Vitaly Prosyak 
> > > Signed-off-by: Christian König 
> > > Cc: Alex Deucher 
> > Maybe I'm extremely missing the point, but it's kind hard to be sure
> > without the testcase/mesa side code too, but for gl robustness I don't
> > think this is enough, because you also need to know whether it was your
> > context or someone else that caused the gpu reset. Probably biased, but I
> > think the per-ctx guilty/reset counters is more then right code here. Or
> > something along those lines.
> 
> Exactly that ctx based approach blew up pretty nicely because it doesn't
> match the lifetime of the ctx.
> 
> On the one hand you don't want the ctx to outlive the file descriptor which
> it was created with since it points back to the fd, on the other hand when
> you need it for error handling you need to keep it around until all
> submissions are completed.

Why does the ctx need to point back to the fd? At least with the reset
stats query approach you only ever go from fd to ctx, not the other way
around. Going from ctx to fd is indeed all kinds of enormous fun and
really not great.

I guess the "jobs keep ctx alive" is the age old ctx refcounting fun, and
there's leaks involved if they outlive the fd in bad ways ... :-/

> In the end you have a really nice circle dependency.

Maybe a follow up, so for arb robustness or vk context where we want the
context to die and refuse to accept any more jobs: We can get at that
error somehow? I think that's really the only worry I have with a job
error approach for all this ...

> > If we really want to stuff this into per-job fences then I think we should
> > at least try to document this mess in the sync_file uapi, for a bit of
> > consistency.
> 
> Good point. Goi

Re: [PATCH] drm/sched: add optional errno to drm_sched_start()

[Daniel Vetter]

093616fe53c 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -674,9 +674,10 @@ EXPORT_SYMBOL(drm_sched_stop);
>   * drm_sched_start - recover jobs after a reset
>   *
>   * @sched: scheduler instance
> + * @errno: error to set on the pending fences
>   *
>   */
> -void drm_sched_start(struct drm_gpu_scheduler *sched)
> +void drm_sched_start(struct drm_gpu_scheduler *sched, int errno)
>  {
>   struct drm_sched_job *s_job, *tmp;
>  
> @@ -691,13 +692,13 @@ void drm_sched_start(struct drm_gpu_scheduler *sched)
>   atomic_add(s_job->credits, &sched->credit_count);
>  
>   if (!fence) {
> - drm_sched_job_done(s_job, -ECANCELED);
> + drm_sched_job_done(s_job, errno ?: -ECANCELED);
>   continue;
>   }
>  
>   if (dma_fence_add_callback(fence, &s_job->cb,
>  drm_sched_job_done_cb))
> - drm_sched_job_done(s_job, fence->error);
> + drm_sched_job_done(s_job, fence->error ?: errno);
>   }
>  
>   drm_sched_start_timeout_unlocked(sched);
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
> index 42d4f4a2dba2..cac02284cd19 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -653,7 +653,7 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct 
> drm_sched_job *sched_job)
>  
>   /* Unblock schedulers and restart their jobs. */
>   for (q = 0; q < V3D_MAX_QUEUES; q++) {
> - drm_sched_start(&v3d->queue[q].sched);
> + drm_sched_start(&v3d->queue[q].sched, 0);
>   }
>  
>   mutex_unlock(&v3d->reset_lock);
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index fe8edb917360..a8d19b10f9b8 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -579,7 +579,7 @@ bool drm_sched_wqueue_ready(struct drm_gpu_scheduler 
> *sched);
>  void drm_sched_wqueue_stop(struct drm_gpu_scheduler *sched);
>  void drm_sched_wqueue_start(struct drm_gpu_scheduler *sched);
>  void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job 
> *bad);
> -void drm_sched_start(struct drm_gpu_scheduler *sched);
> +void drm_sched_start(struct drm_gpu_scheduler *sched, int errno);
>  void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched);
>  void drm_sched_increase_karma(struct drm_sched_job *bad);
>  void drm_sched_reset_karma(struct drm_sched_job *bad);
> -- 
> 2.34.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()

[Daniel Vetter]

On Wed, Jul 10, 2024 at 05:13:18PM -0400, Hamza Mahfooz wrote:
> On 7/10/24 04:43, Daniel Vetter wrote:
> > On Tue, Jul 09, 2024 at 10:02:08AM -0400, Hamza Mahfooz wrote:
> > > On 7/9/24 06:09, Daniel Vetter wrote:
> > > > On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> > > > > On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > > > > > Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
> > > > > > enable PSR more quickly for displays that support it.
> > > > > > 
> > > > > > Signed-off-by: Hamza Mahfooz 
> > > > > > ---
> > > > > >.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 
> > > > > > ++-
> > > > > >1 file changed, 22 insertions(+), 8 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > > > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > > index fdbc9b57a23d..ee6c31e9d3c4 100644
> > > > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > > > @@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct 
> > > > > > drm_device *dev,
> > > > > >static void manage_dm_interrupts(struct amdgpu_device *adev,
> > > > > >  struct amdgpu_crtc *acrtc,
> > > > > > -bool enable)
> > > > > > +struct dm_crtc_state *acrtc_state)
> > > > > >{
> > > > > > /*
> > > > > >  * We have no guarantee that the frontend index maps to the same
> > > > > > @@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct 
> > > > > > amdgpu_device *adev,
> > > > > >  *
> > > > > >  * TODO: Use a different interrupt or check DC itself for the 
> > > > > > mapping.
> > > > > >  */
> > > > > > -   int irq_type =
> > > > > > -   amdgpu_display_crtc_idx_to_irq_type(
> > > > > > -   adev,
> > > > > > -   acrtc->crtc_id);
> > > > > > +   int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
> > > > > > +  
> > > > > > acrtc->crtc_id);
> > > > > > +   struct dc_crtc_timing *timing;
> > > > > > +   int offdelay;
> > > > > > +
> > > > > > +   if (acrtc_state) {
> > > > > > +   timing = &acrtc_state->stream->timing;
> > > > > > +
> > > > > > +   /* at least 2 frames */
> > > > > > +   offdelay = 2000 / 
> > > > > > div64_u64(div64_u64((timing->pix_clk_100hz *
> > > > > > +  (uint64_t)100),
> > > > > > + timing->v_total),
> > > > > > +   timing->h_total) + 1;
> > > > > 
> > > > > Yeah, _especially_ when you have a this short timeout your really 
> > > > > have to
> > > > > instead fix the vblank driver code properly so you can enable
> > > > > vblank_disable_immediate. This is just cheating :-)
> > > > 
> > > > Michel mentioned on irc that DC had immediate vblank disabling, but this
> > > > was reverted with f64e6e0b6afe ("Revert "drm/amdgpu/display: set
> > > > vblank_disable_immediate for DC"").
> > > > 
> > > > I haven't looked at the details of the bug report, but stuttering is
> > > > exactly what happens when the driver's vblank code has these races. 
> > > > Going
> > > > for a very low timeout instead of zero just means it's a bit harder to 
> > > > hit
> > > > the issue, and much, much harder to debug properly.
> > > > 
> > > > So yeah even more reasons to look at the underlying root-cause here I
> > > > think.
> > > > -Sima
> > > 
> > > The issue is that DMUB (display firmware) isn't able to keep up with all 
> > >

Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()

[Daniel Vetter]

On Tue, Jul 09, 2024 at 10:02:08AM -0400, Hamza Mahfooz wrote:
> On 7/9/24 06:09, Daniel Vetter wrote:
> > On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > > > Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
> > > > enable PSR more quickly for displays that support it.
> > > > 
> > > > Signed-off-by: Hamza Mahfooz 
> > > > ---
> > > >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
> > > >   1 file changed, 22 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > index fdbc9b57a23d..ee6c31e9d3c4 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > @@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct 
> > > > drm_device *dev,
> > > >   static void manage_dm_interrupts(struct amdgpu_device *adev,
> > > >  struct amdgpu_crtc *acrtc,
> > > > -bool enable)
> > > > +struct dm_crtc_state *acrtc_state)
> > > >   {
> > > > /*
> > > >  * We have no guarantee that the frontend index maps to the same
> > > > @@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct 
> > > > amdgpu_device *adev,
> > > >  *
> > > >  * TODO: Use a different interrupt or check DC itself for the 
> > > > mapping.
> > > >  */
> > > > -   int irq_type =
> > > > -   amdgpu_display_crtc_idx_to_irq_type(
> > > > -   adev,
> > > > -   acrtc->crtc_id);
> > > > +   int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
> > > > +  
> > > > acrtc->crtc_id);
> > > > +   struct dc_crtc_timing *timing;
> > > > +   int offdelay;
> > > > +
> > > > +   if (acrtc_state) {
> > > > +   timing = &acrtc_state->stream->timing;
> > > > +
> > > > +   /* at least 2 frames */
> > > > +   offdelay = 2000 / 
> > > > div64_u64(div64_u64((timing->pix_clk_100hz *
> > > > +  (uint64_t)100),
> > > > + timing->v_total),
> > > > +   timing->h_total) + 1;
> > > 
> > > Yeah, _especially_ when you have a this short timeout your really have to
> > > instead fix the vblank driver code properly so you can enable
> > > vblank_disable_immediate. This is just cheating :-)
> > 
> > Michel mentioned on irc that DC had immediate vblank disabling, but this
> > was reverted with f64e6e0b6afe ("Revert "drm/amdgpu/display: set
> > vblank_disable_immediate for DC"").
> > 
> > I haven't looked at the details of the bug report, but stuttering is
> > exactly what happens when the driver's vblank code has these races. Going
> > for a very low timeout instead of zero just means it's a bit harder to hit
> > the issue, and much, much harder to debug properly.
> > 
> > So yeah even more reasons to look at the underlying root-cause here I
> > think.
> > -Sima
> 
> The issue is that DMUB (display firmware) isn't able to keep up with all of
> the requests that the driver is making. The issue is fairly difficult to
> reproduce (I've only seen it once after letting the system run with a
> program that would engage PSR every so often, after several hours).
> It is also worth noting that we have the same 2 idle frame wait on the
> windows
> driver, for the same reasons. So, in all likelihood if it is your opinion
> that
> the series should be NAKed, we will probably have to move the wait into the
> driver as a workaround.

Well that's an entirely different reason, and needs to be recorded in the
commit log that disabling/enabling vblank is too expensive and why. Also
would be good to record that windows does the same.

I'm also not entirely sure this is a good interface, so some
thoughts/question:

- is the issue o

Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()

[Daniel Vetter]

On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
> > enable PSR more quickly for displays that support it.
> > 
> > Signed-off-by: Hamza Mahfooz 
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
> >  1 file changed, 22 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index fdbc9b57a23d..ee6c31e9d3c4 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct drm_device 
> > *dev,
> >  
> >  static void manage_dm_interrupts(struct amdgpu_device *adev,
> >  struct amdgpu_crtc *acrtc,
> > -bool enable)
> > +struct dm_crtc_state *acrtc_state)
> >  {
> > /*
> >  * We have no guarantee that the frontend index maps to the same
> > @@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct 
> > amdgpu_device *adev,
> >  *
> >  * TODO: Use a different interrupt or check DC itself for the mapping.
> >  */
> > -   int irq_type =
> > -   amdgpu_display_crtc_idx_to_irq_type(
> > -   adev,
> > -   acrtc->crtc_id);
> > +   int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
> > +  acrtc->crtc_id);
> > +   struct dc_crtc_timing *timing;
> > +   int offdelay;
> > +
> > +   if (acrtc_state) {
> > +   timing = &acrtc_state->stream->timing;
> > +
> > +   /* at least 2 frames */
> > +   offdelay = 2000 / div64_u64(div64_u64((timing->pix_clk_100hz *
> > +  (uint64_t)100),
> > + timing->v_total),
> > +   timing->h_total) + 1;
> 
> Yeah, _especially_ when you have a this short timeout your really have to
> instead fix the vblank driver code properly so you can enable
> vblank_disable_immediate. This is just cheating :-)

Michel mentioned on irc that DC had immediate vblank disabling, but this
was reverted with f64e6e0b6afe ("Revert "drm/amdgpu/display: set
vblank_disable_immediate for DC"").

I haven't looked at the details of the bug report, but stuttering is
exactly what happens when the driver's vblank code has these races. Going
for a very low timeout instead of zero just means it's a bit harder to hit
the issue, and much, much harder to debug properly.

So yeah even more reasons to look at the underlying root-cause here I
think.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()

[Daniel Vetter]

On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
> enable PSR more quickly for displays that support it.
> 
> Signed-off-by: Hamza Mahfooz 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
>  1 file changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index fdbc9b57a23d..ee6c31e9d3c4 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct drm_device 
> *dev,
>  
>  static void manage_dm_interrupts(struct amdgpu_device *adev,
>struct amdgpu_crtc *acrtc,
> -  bool enable)
> +  struct dm_crtc_state *acrtc_state)
>  {
>   /*
>* We have no guarantee that the frontend index maps to the same
> @@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct amdgpu_device 
> *adev,
>*
>* TODO: Use a different interrupt or check DC itself for the mapping.
>*/
> - int irq_type =
> - amdgpu_display_crtc_idx_to_irq_type(
> - adev,
> - acrtc->crtc_id);
> + int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
> +acrtc->crtc_id);
> + struct dc_crtc_timing *timing;
> + int offdelay;
> +
> + if (acrtc_state) {
> + timing = &acrtc_state->stream->timing;
> +
> + /* at least 2 frames */
> + offdelay = 2000 / div64_u64(div64_u64((timing->pix_clk_100hz *
> +(uint64_t)100),
> +   timing->v_total),
> + timing->h_total) + 1;

Yeah, _especially_ when you have a this short timeout your really have to
instead fix the vblank driver code properly so you can enable
vblank_disable_immediate. This is just cheating :-)
-Sima

> +
> + if (acrtc_state->stream->link->psr_settings.psr_version <
> + DC_PSR_VERSION_UNSUPPORTED &&
> + amdgpu_ip_version(adev, DCE_HWIP, 0) >= IP_VERSION(3, 5, 0))
> + drm_crtc_set_vblank_offdelay(&acrtc->base, offdelay);
>  
> - if (enable) {
>   drm_crtc_vblank_on(&acrtc->base);
>   amdgpu_irq_get(
>   adev,
> @@ -9319,7 +9332,7 @@ static void amdgpu_dm_commit_streams(struct 
> drm_atomic_state *state,
>   if (old_crtc_state->active &&
>   (!new_crtc_state->active ||
>drm_atomic_crtc_needs_modeset(new_crtc_state))) {
> - manage_dm_interrupts(adev, acrtc, false);
> + manage_dm_interrupts(adev, acrtc, NULL);
>   dc_stream_release(dm_old_crtc_state->stream);
>   }
>   }
> @@ -9834,7 +9847,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>drm_atomic_crtc_needs_modeset(new_crtc_state))) {
>   dc_stream_retain(dm_new_crtc_state->stream);
>   acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
> - manage_dm_interrupts(adev, acrtc, true);
> + manage_dm_interrupts(adev, acrtc,
> +  to_dm_crtc_state(new_crtc_state));
>   }
>   /* Handle vrr on->off / off->on transitions */
>   amdgpu_dm_handle_vrr_transition(dm_old_crtc_state, 
> dm_new_crtc_state);
> -- 
> 2.45.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/2] drm/vblank: allow dynamic per-crtc vblank off delay

[Daniel Vetter]

dle_vblank_events) so that the timestamp is always accurate.
>*/
>   disable_irq = (dev->vblank_disable_immediate &&
> -drm_vblank_offdelay > 0 &&
> +vblank->offdelay_ms > 0 &&
>  !atomic_read(&vblank->refcount));
>  
>   drm_handle_vblank_events(dev, pipe);
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 7f3957943dd1..f92f28b816af 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -187,6 +187,12 @@ struct drm_vblank_crtc {
>*/
>   int linedur_ns;
>  
> + /**
> +  * @offdelay_ms: Vblank off delay in ms, used to determine how long
> +  * @disable_timer waits before disabling.
> +  */
> +     int offdelay_ms;
> +
>   /**
>* @hwmode:
>*
> @@ -255,6 +261,7 @@ void drm_calc_timestamping_constants(struct drm_crtc 
> *crtc,
>  wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
>  void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
>  u32 max_vblank_count);
> +void drm_crtc_set_vblank_offdelay(struct drm_crtc *crtc, int offdelay);
>  
>  /*
>   * Helpers for struct drm_crtc_funcs
> -- 
> 2.45.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu, radeon drm-fixes-6.10

[Daniel Vetter]

On Sat, 6 Jul 2024 at 18:36, Alex Deucher  wrote:
>
> On Fri, Jul 5, 2024 at 7:15 AM Daniel Vetter  wrote:
> >
> > On Wed, Jul 03, 2024 at 02:47:23PM -0400, Alex Deucher wrote:
> > > Hi Dave, Sima,
> > >
> > > Fixes for 6.10.
> > >
> > > The following changes since commit 
> > > 22a40d14b572deb80c0648557f4bd502d7e83826:
> > >
> > >   Linux 6.10-rc6 (2024-06-30 14:40:44 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.freedesktop.org/agd5f/linux.git 
> > > tags/amd-drm-fixes-6.10-2024-07-03
> > >
> > > for you to fetch changes up to d0417264437a8fa05f894cabba5a26715b32d78e:
> > >
> > >   drm/amdgpu/atomfirmware: silence UBSAN warning (2024-07-02 18:34:05 
> > > -0400)
> >
> > Pulled, thanks.
> >
> > Also I noticed you have some cherry-picks from -next in here, would be
> > good to add a cherry-pick from annotation like drm-intel/xe does (or dim
> > cherry-pick does).
> >
> > It doesn't help to prevent Greg KH from getting confused, but it does help
> > everyone else since cherry-picks tend to cause confusing conflicts.
> >
>
> Ok.  Will do.  I used to do that in the past, but got dinged for
> referencing commits not in Linus' tree for -fixes, but I guess with
> the -next tree that's less of an issue these days.


You'll still get dinged by Greg, but frankly when he doesn't get it
since like 10 years (that's how long intel cherry-picks everything for
-fixes) it's not an us problem anymore, and it's really useful imo.
-Sima

>
> Alex
>
>
> > Cheers, Sima
> > >
> > > 
> > > amd-drm-fixes-6.10-2024-07-03:
> > >
> > > amdgpu:
> > > - Freesync fixes
> > > - DML1 bandwidth fix
> > > - DCN 3.5 fixes
> > > - DML2 fix
> > > - Silence an UBSAN warning
> > >
> > > radeon:
> > > - GPUVM fix
> > >
> > > 
> > > Alex Deucher (1):
> > >   drm/amdgpu/atomfirmware: silence UBSAN warning
> > >
> > > Alvin Lee (1):
> > >   drm/amd/display: Account for cursor prefetch BW in DML1 mode support
> > >
> > > Fangzhi Zuo (1):
> > >   drm/amd/display: Update efficiency bandwidth for dcn351
> > >
> > > Pierre-Eric Pelloux-Prayer (1):
> > >   drm/radeon: check bo_va->bo is non-NULL before using it
> > >
> > > Roman Li (1):
> > >   drm/amd/display: Fix array-index-out-of-bounds in 
> > > dml2/FCLKChangeSupport
> > >
> > > Tom Chung (3):
> > >   drm/amd/display: Reset freesync config before update new state
> > >   drm/amd/display: Add refresh rate range check
> > >   drm/amd/display: Fix refresh rate range for some panel
> > >
> > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 53 
> > > +-
> > >  .../amd/display/dc/dml/dcn32/display_mode_vba_32.c |  3 ++
> > >  .../amd/display/dc/dml2/dml2_translation_helper.c  |  1 +
> > >  drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c   |  2 +-
> > >  drivers/gpu/drm/amd/include/atomfirmware.h |  2 +-
> > >  drivers/gpu/drm/radeon/radeon_gem.c|  2 +-
> > >  6 files changed, 59 insertions(+), 4 deletions(-)
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu, radeon drm-fixes-6.10

[Daniel Vetter]

On Wed, Jul 03, 2024 at 02:47:23PM -0400, Alex Deucher wrote:
> Hi Dave, Sima,
> 
> Fixes for 6.10.
> 
> The following changes since commit 22a40d14b572deb80c0648557f4bd502d7e83826:
> 
>   Linux 6.10-rc6 (2024-06-30 14:40:44 -0700)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.10-2024-07-03
> 
> for you to fetch changes up to d0417264437a8fa05f894cabba5a26715b32d78e:
> 
>   drm/amdgpu/atomfirmware: silence UBSAN warning (2024-07-02 18:34:05 -0400)

Pulled, thanks.

Also I noticed you have some cherry-picks from -next in here, would be
good to add a cherry-pick from annotation like drm-intel/xe does (or dim
cherry-pick does).

It doesn't help to prevent Greg KH from getting confused, but it does help
everyone else since cherry-picks tend to cause confusing conflicts.

Cheers, Sima
> 
> 
> amd-drm-fixes-6.10-2024-07-03:
> 
> amdgpu:
> - Freesync fixes
> - DML1 bandwidth fix
> - DCN 3.5 fixes
> - DML2 fix
> - Silence an UBSAN warning
> 
> radeon:
> - GPUVM fix
> 
> 
> Alex Deucher (1):
>   drm/amdgpu/atomfirmware: silence UBSAN warning
> 
> Alvin Lee (1):
>   drm/amd/display: Account for cursor prefetch BW in DML1 mode support
> 
> Fangzhi Zuo (1):
>   drm/amd/display: Update efficiency bandwidth for dcn351
> 
> Pierre-Eric Pelloux-Prayer (1):
>   drm/radeon: check bo_va->bo is non-NULL before using it
> 
> Roman Li (1):
>   drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport
> 
> Tom Chung (3):
>   drm/amd/display: Reset freesync config before update new state
>   drm/amd/display: Add refresh rate range check
>   drm/amd/display: Fix refresh rate range for some panel
> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 53 
> +-
>  .../amd/display/dc/dml/dcn32/display_mode_vba_32.c |  3 ++
>  .../amd/display/dc/dml2/dml2_translation_helper.c  |  1 +
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c   |  2 +-
>  drivers/gpu/drm/amd/include/atomfirmware.h |  2 +-
>  drivers/gpu/drm/radeon/radeon_gem.c|  2 +-
>  6 files changed, 59 insertions(+), 4 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu, radeon drm-next-6.11

[Daniel Vetter]

drivers/gpu/drm/amd/display/dc/dcn20/Makefile  |   1 -
>  drivers/gpu/drm/amd/display/dc/dcn30/Makefile  |   2 -
>  drivers/gpu/drm/amd/display/dc/dcn31/Makefile  |   2 +-
>  drivers/gpu/drm/amd/display/dc/dio/Makefile|  36 +++
>  .../dc/{ => dio}/dcn10/dcn10_link_encoder.c|   0
>  .../dc/{ => dio}/dcn10/dcn10_link_encoder.h|   0
>  .../dc/{ => dio}/dcn10/dcn10_stream_encoder.c  |   0
>  .../dc/{ => dio}/dcn10/dcn10_stream_encoder.h  |   0
>  .../dc/{ => dio}/dcn20/dcn20_link_encoder.c|   0
>  .../dc/{ => dio}/dcn20/dcn20_link_encoder.h|   0
>  .../dc/{ => dio}/dcn20/dcn20_stream_encoder.c  |   0
>  .../dc/{ => dio}/dcn20/dcn20_stream_encoder.h  |   0
>  .../dc/{ => dio}/dcn30/dcn30_dio_link_encoder.c|   0
>  .../dc/{ => dio}/dcn30/dcn30_dio_link_encoder.h|   0
>  .../dc/{ => dio}/dcn30/dcn30_dio_stream_encoder.c  |   0
>  .../dc/{ => dio}/dcn30/dcn30_dio_stream_encoder.h  |   0
>  .../dc/{ => dio}/dcn31/dcn31_dio_link_encoder.c|   0
>  .../dc/{ => dio}/dcn31/dcn31_dio_link_encoder.h|   0
>  .../gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c   |   2 +-
>  .../amd/display/dc/dml/dcn32/display_mode_vba_32.c |   3 +
>  .../drm/amd/display/dc/dml2/dml21/dml21_wrapper.c  |  22 +++--
>  .../dml2/dml21/src/dml2_core/dml2_core_factory.c   |   2 +-
>  .../dml2/dml21/src/dml2_dpmm/dml2_dpmm_factory.c   |   2 +-
>  .../dc/dml2/dml21/src/dml2_mcg/dml2_mcg_factory.c  |   2 +-
>  .../dc/dml2/dml21/src/dml2_pmo/dml2_pmo_factory.c  |   2 +-
>  .../amd/display/dc/dml2/dml2_translation_helper.c  |   1 +
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c   |  14 +--
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.c |  15 ---
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.h |   2 -
>  .../amd/display/dc/hubbub/dcn401/dcn401_hubbub.c   |   6 ++
>  .../drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c   |  15 ++-
>  .../drm/amd/display/dc/hwss/dce110/dce110_hwseq.c  |  62 +++-
>  .../drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c|   2 +-
>  .../drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c|   6 ++
>  .../drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c  |  47 +++--
>  .../drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.h  |   1 +
>  .../dc/link/protocols/link_edp_panel_control.c |   2 +-
>  .../display/dc/resource/dcn314/dcn314_resource.c   |  22 -
>  .../display/dc/resource/dcn315/dcn315_resource.c   |   2 +-
>  .../amd/display/dc/resource/dcn35/dcn35_resource.c |   2 -
>  .../display/dc/resource/dcn401/dcn401_resource.c   |   3 +
>  drivers/gpu/drm/amd/display/dc/spl/dc_spl.c|   8 +-
>  drivers/gpu/drm/amd/display/dmub/dmub_srv.h|   1 +
>  drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h|   5 +-
>  drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c  |   1 +
>  .../drm/amd/display/modules/freesync/freesync.c|   2 +-
>  drivers/gpu/drm/amd/include/atomfirmware.h |   2 +-
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c  |   1 +
>  drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0.c |  20 ++--
>  .../gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c   |  30 +++---
>  drivers/gpu/drm/radeon/radeon_gem.c|   2 +-
>  include/uapi/drm/drm_fourcc.h  |   5 +-
>  94 files changed, 624 insertions(+), 318 deletions(-)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn10/dcn10_link_encoder.c 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn10/dcn10_link_encoder.h 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn10/dcn10_stream_encoder.c 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn10/dcn10_stream_encoder.h 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_link_encoder.c 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_link_encoder.h 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_stream_encoder.c 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_stream_encoder.h 
> (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => 
> dio}/dcn30/dcn30_dio_link_encoder.c (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => 
> dio}/dcn30/dcn30_dio_link_encoder.h (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => 
> dio}/dcn30/dcn30_dio_stream_encoder.c (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => 
> dio}/dcn30/dcn30_dio_stream_encoder.h (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => 
> dio}/dcn31/dcn31_dio_link_encoder.c (100%)
>  rename drivers/gpu/drm/amd/display/dc/{ => 
> dio}/dcn31/dcn31_dio_link_encoder.h (100%)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu, amdkfd drm-next-6.11

[Daniel Vetter]

0/dcn20_hubp.h |  14 ++
>  .../drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c   |  71 +++---
>  .../drm/amd/display/dc/hubp/dcn401/dcn401_hubp.h   |  14 +-
>  .../drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c|  17 --
>  .../drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c|  34 ++-
>  .../drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c|   5 +-
>  .../drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c|  11 +-
>  .../drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c  | 169 +
>  .../drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.h  |   2 +
>  .../drm/amd/display/dc/hwss/dcn401/dcn401_init.c   |   2 +-
>  drivers/gpu/drm/amd/display/dc/hwss/hw_sequencer.h |   9 +
>  drivers/gpu/drm/amd/display/dc/inc/core_types.h|   3 +
>  drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h   |   4 +
>  drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h   |   1 +
>  .../drm/amd/display/dc/inc/hw/timing_generator.h   |   1 +
>  .../amd/display/dc/link/accessories/link_dp_cts.c  |   2 +-
>  drivers/gpu/drm/amd/display/dc/link/link_factory.c |   6 +-
>  .../display/dc/link/protocols/link_dp_capability.c |  31 ++-
>  .../display/dc/link/protocols/link_dp_training.c   |   3 +-
>  .../gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.h |   3 +-
>  .../gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c |  13 +
>  .../gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.h |   2 +
>  .../drm/amd/display/dc/optc/dcn401/dcn401_optc.c   |   1 +
>  .../drm/amd/display/dc/optc/dcn401/dcn401_optc.h   |   1 +
>  .../amd/display/dc/resource/dcn20/dcn20_resource.c |   9 +-
>  .../amd/display/dc/resource/dcn35/dcn35_resource.c |   5 +-
>  .../display/dc/resource/dcn401/dcn401_resource.c   |   9 +
>  .../display/dc/resource/dcn401/dcn401_resource.h   |   2 +
>  drivers/gpu/drm/amd/display/include/dpcd_defs.h    |   5 +
>  .../drm/amd/display/modules/hdcp/hdcp1_execution.c |  24 +-
>  .../gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c|  12 +-
>  .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c|   3 -
>  drivers/gpu/drm/amd/include/amd_shared.h   |   2 +
>  .../amd/include/asic_reg/dcn/dcn_4_1_0_offset.h|  18 ++
>  .../amd/include/asic_reg/dcn/dcn_4_1_0_sh_mask.h   | 110 
>  .../drm/amd/include/ivsrcid/isp/irqsrcs_isp_4_1.h  |  62 +
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c  |   3 +-
>  .../gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c   |  30 +--
>  138 files changed, 2467 insertions(+), 749 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_0.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_0.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.h
>  create mode 100644 drivers/gpu/drm/amd/include/ivsrcid/isp/irqsrcs_isp_4_1.h

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/6] drm/amdgpu: allow ioctls to opt-out of runtime pm

[Daniel Vetter]

On Tue, Jun 25, 2024 at 09:07:12AM +0200, Pierre-Eric Pelloux-Prayer wrote:
> 
> Le 20/06/2024 à 15:36, Christian König a écrit :
> > Am 20.06.24 um 15:06 schrieb Pierre-Eric Pelloux-Prayer:
> > > Le 19/06/2024 à 11:26, Christian König a écrit :
> > > > Am 18.06.24 um 17:23 schrieb Pierre-Eric Pelloux-Prayer:
> > > > > Waking up a device can take multiple seconds, so if it's not
> > > > > going to be used we might as well not resume it.
> > > > > 
> > > > > The safest default behavior for all ioctls is to resume the GPU,
> > > > > so this change allows specific ioctls to opt-out of generic
> > > > > runtime pm.
> > > > 
> > > > I'm really wondering if we shouldn't put that into the IOCTL
> > > > description.
> > > > 
> > > > See amdgpu_ioctls_kms and DRM_IOCTL_DEF_DRV() for what I mean.
> > > 
> > > Are you suggesting to add a new entry in enum drm_ioctl_flags to
> > > indicate ioctls which need the device to be awake?
> > > 
> > > Something like: "DRM_NO_DEVICE = BIT(6)" and then use it for both
> > > core and amdgpu ioctls?
> > 
> > Yeah something like that. Maybe name that DRM_SW_ONLY or something like
> > that.
> 
> + dri-devel to gauge interest in adding such a flag in shared code.

Eh please no. That's just fundamentally the wrong way round to do runtime
pm, but amdgpu goes way, way back in desing in that record to the vga
switcheroo, where the simple hack was to just add runtime pm handling at
the entry points and call it done.

If you look at any other drm driver, the runtime pm handling is done way
down when touching the actual relevant hardware blocks. Because especially
on arm it's actually a pile of runtime pm domains.

So essentially this is like pushing a big driver lock down the callchain
until it's actually at the right level. First step would be to push it
into each of the amdgpu ioctl callbacks, so that you can drop
amdgpu_drm_ioctl and use drm_ioctl again directly. And then push it
further until you can remove it from all the places where it's not needed.

DRM_SW_ONLY otoh is pure midlayer mistake design.

Cheers, Sima

> 
> Pierre-Eric
> 
> 
> 
> > 
> > Christian.
> > 
> > > 
> > > Pierre-Eric
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > Regards,
> > > > Christian.
> > > > 
> > > > > 
> > > > > Signed-off-by: Pierre-Eric Pelloux-Prayer
> > > > > 
> > > > > ---
> > > > >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 25
> > > > > -
> > > > >   1 file changed, 20 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > index 60d5758939ae..a9831b243bfc 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > @@ -2855,18 +2855,33 @@ long amdgpu_drm_ioctl(struct file *filp,
> > > > >   {
> > > > >   struct drm_file *file_priv = filp->private_data;
> > > > >   struct drm_device *dev;
> > > > > +    bool needs_device;
> > > > >   long ret;
> > > > >   dev = file_priv->minor->dev;
> > > > > -    ret = pm_runtime_get_sync(dev->dev);
> > > > > -    if (ret < 0)
> > > > > -    goto out;
> > > > > +
> > > > > +    /* Some ioctl can opt-out of powermanagement handling
> > > > > + * if they don't require the device to be resumed.
> > > > > + */
> > > > > +    switch (cmd) {
> > > > > +    default:
> > > > > +    needs_device = true;
> > > > > +    }
> > > > > +
> > > > > +    if (needs_device) {
> > > > > +    ret = pm_runtime_get_sync(dev->dev);
> > > > > +    if (ret < 0)
> > > > > +    goto out;
> > > > > +    }
> > > > >   ret = drm_ioctl(filp, cmd, arg);
> > > > > -    pm_runtime_mark_last_busy(dev->dev);
> > > > >   out:
> > > > > -    pm_runtime_put_autosuspend(dev->dev);
> > > > > +    if (needs_device) {
> > > > > +    pm_runtime_mark_last_busy(dev->dev);
> > > > > +    pm_runtime_put_autosuspend(dev->dev);
> > > > > +    }
> > > > > +
> > > > >   return ret;
> > > > >   }

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/amdgpu: fix a possible null pointer dereference

[Daniel Vetter]

On Sun, 23 Jun 2024 at 14:22, Joshua Ashton  wrote:

> Maybe that wasn't you or whatever, but your last patch that did this got
> some CVE assigned to it that didn't really make any sense, given this is
> just a null deref that'd end up as an oops?
>
> It can only happen if the kzalloc in drm_mode_create fails.
>
> I imagine that the `continue` is not the best cause of action anyway,
> it's probably not worth adding some broken connector with a bunch of
> missing modes.
> It's just going to make things appear more broken and be unexpected to
> userspace.
>
> Maybe this is some new thing that we do now I am out of the loop on...
>

Kernel CVE handling changed a lot, for background:

 https://lwn.net/Articles/978711/

No one needs to ask for CVEs, you'll all get them pretty much automatically
for everything now.

Cheers, Sima


> - Joshie 🐸✨
>
> On 6/23/24 10:20 AM, Joshua Ashton wrote:
> > Are you planning on submitting a bogus CVE for this patch too?
> >
> > - Joshie 🐸✨
> >
> > On June 22, 2024 9:22:19 AM GMT+01:00, Ma Ke  wrote:
> >> In amdgpu_connector_add_common_modes(), the return value of
> drm_cvt_mode()
> >> is assigned to mode, which will lead to a NULL pointer dereference on
> >> failure of drm_cvt_mode(). Add a check to avoid npd.
> >>
> >> Signed-off-by: Ma Ke 
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> >> index 9caba10315a8..6cf946adb6fe 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> >> @@ -458,6 +458,8 @@ static void
> amdgpu_connector_add_common_modes(struct drm_encoder *encoder,
> >>  continue;
> >>
> >>  mode = drm_cvt_mode(dev, common_modes[i].w,
> common_modes[i].h, 60, false, false, false);
> >> +if (!mode)
> >> +continue;
> >>  drm_mode_probed_add(connector, mode);
> >>  }
> >> }
>
>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3] drm/fb-helper: Detect when lid is closed during initialization

[Daniel Vetter]

gt; +
>   cancel_work_sync(&fb_helper->resume_work);
>   cancel_work_sync(&fb_helper->damage_work);
>  
> @@ -1842,6 +1970,10 @@ __drm_fb_helper_initial_config_and_unlock(struct 
> drm_fb_helper *fb_helper)
>   width = dev->mode_config.max_width;
>   height = dev->mode_config.max_height;
>  
> + ret = drm_fb_helper_create_lid_handler(fb_helper);
> + if (ret)
> + return ret;
> +
>   drm_client_modeset_probe(&fb_helper->client, width, height);
>   ret = drm_fb_helper_single_fb_probe(fb_helper);
>   if (ret < 0) {
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 63767cf24371..619af597784c 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -316,6 +316,12 @@ struct drm_device {
>* Root directory for debugfs files.
>*/
>   struct dentry *debugfs_root;
> +
> + /**
> +  * @lid_closed: Flag to tell the lid switch state
> +  */
> + bool lid_closed;
> +
>  };
>  
>  #endif
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 375737fd6c36..7fb36c10299d 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -143,6 +143,8 @@ struct drm_fb_helper {
>   spinlock_t damage_lock;
>   struct work_struct damage_work;
>   struct work_struct resume_work;
> + struct work_struct lid_work;
> + struct workqueue_struct *input_wq;
>  
>   /**
>* @lock:
> -- 
> 2.43.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/buddy: Fix the range bias clear memory allocation issue

[Daniel Vetter]

On Wed, May 08, 2024 at 12:27:20PM +0530, Arunpravin Paneer Selvam wrote:
> Problem statement: During the system boot time, an application request
> for the bulk volume of cleared range bias memory when the clear_avail
> is zero, we dont fallback into normal allocation method as we had an
> unnecessary clear_avail check which prevents the fallback method leads
> to fb allocation failure following system goes into unresponsive state.
> 
> Solution: Remove the unnecessary clear_avail check in the range bias
> allocation function.
> 
> Signed-off-by: Arunpravin Paneer Selvam 
> Fixes: 96950929eb23 ("drm/buddy: Implement tracking clear page feature")
> Reviewed-by: Matthew Auld 
> ---
>  drivers/gpu/drm/drm_buddy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Can you please also add a kunit test case to exercise this corner case and
make sure it stays fixed?

Thanks, Sima
> 
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 284ebae71cc4..831929ac95eb 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -574,7 +574,7 @@ __drm_buddy_alloc_range_bias(struct drm_buddy *mm,
>  
>   block = __alloc_range_bias(mm, start, end, order,
>  flags, fallback);
> - if (IS_ERR(block) && mm->clear_avail)
> + if (IS_ERR(block))
>   return __alloc_range_bias(mm, start, end, order,
> flags, !fallback);
>  
> -- 
> 2.25.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] Documentation/gpu: Document the situation with unqualified drm-memory-

[Daniel Vetter]

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:
> > > > 
> > > > [And I forgot dri-devel.. doing well!]
> > > > 
> > > > On 03/05/2024 13:40, Tvrtko Ursulin wrote:
> > > > > 
> > > > > [Correcting Christian's email]
> > > > > 
> > > > > On 03/05/2024 13:36, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin 
> > > > > > 
> > > > > > Currently it is not well defined what is drm-memory- compared to 
> > > > > > other
> > > > > > categories.
> > > > > > 
> > > > > > In practice the only driver which emits these keys is amdgpu and in 
> > > > > > them
> > > > > > exposes the total memory use (including shared).
> > > > > > 
> > > > > > Document that drm-memory- and drm-total-memory- are aliases to
> > > > > > prevent any
> > > > > > confusion in the future.
> > > > > > 
> > > > > > While at it also clarify that the reserved sub-string 'memory' 
> > > > > > refers to
> > > > > > the memory region component.
> > > > > > 
> > > > > > Signed-off-by: Tvrtko Ursulin 
> > > > > > Cc: Alex Deucher 
> > > > > > Cc: Christian König 
> > > > > 
> > > > > Mea culpa, I copied the mistake from
> > > > > 77d17c4cd0bf52eacfad88e63e8932eb45d643c5. :)
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Tvrtko
> > > > > 
> > > > > > Cc: Rob Clark 
> > > > > > ---
> > > > > >Documentation/gpu/drm-usage-stats.rst | 10 +-
> > > > > >1 file changed, 9 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > > > > b/Documentation/gpu/drm-usage-stats.rst
> > > > > > index 6dc299343b48..ef5c0a0aa477 100644
> > > > > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > > > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > > > > @@ -128,7 +128,9 @@ Memory
> > > > > >Each possible memory type which can be used to store buffer
> > > > > > objects by the
> > > > > >GPU in question shall be given a stable and unique name to be
> > > > > > returned as the
> > > > > > -string here.  The name "memory" is reserved to refer to normal
> > > > > > system memory.
> > > > > > +string here.
> > > > > > +
> > > > > > +The region name "memory" is reserved to refer to normal system 
> > > > > > memory.
> > > > > >Value shall reflect the amount of storage currently consumed by
> > > > > > the buffer
> > > > > >objects belong to this client, in the respective memory region.
> > > > > > @@ -136,6 +138,9 @@ objects belong to this client, in the respective
> > > > > > memory region.
> > > > > >Default unit shall be bytes with optional unit specifiers of 
> > > > > > 'KiB'
> > > > > > or 'MiB'
> > > > > >indicating kibi- or mebi-bytes.
> > > > > > +This is an alias for drm-total- and only one of the two
> > > > > > should be
> > > > > > +present.
> > > 
> > > This feels a bit awkward and seems to needlessly complicate fdinfo uapi.
> > > 
> > > - Could we just patch amdgpu to follow everyone else, and avoid the
> > >special case? If there's no tool that relies on the special amdgpu
> > >prefix then that would be a lot easier.
> > > 
> > > - If that's not on the table, could we make everyone (with a suitable
> > >helper or something) just print both variants, so that we again have
> > >consisent fdinfo output? Or breaks that a different set of existing
> > >tools.
> > > 
> > > - Finally maybe could we get away with fixing amd by adding the common
> > >f

Re: [PATCH] Documentation/gpu: Document the situation with unqualified drm-memory-

[Daniel Vetter]

On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
> 
> [And I forgot dri-devel.. doing well!]
> 
> On 03/05/2024 13:40, Tvrtko Ursulin wrote:
> > 
> > [Correcting Christian's email]
> > 
> > On 03/05/2024 13:36, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > Currently it is not well defined what is drm-memory- compared to other
> > > categories.
> > > 
> > > In practice the only driver which emits these keys is amdgpu and in them
> > > exposes the total memory use (including shared).
> > > 
> > > Document that drm-memory- and drm-total-memory- are aliases to
> > > prevent any
> > > confusion in the future.
> > > 
> > > While at it also clarify that the reserved sub-string 'memory' refers to
> > > the memory region component.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Alex Deucher 
> > > Cc: Christian König 
> > 
> > Mea culpa, I copied the mistake from
> > 77d17c4cd0bf52eacfad88e63e8932eb45d643c5. :)
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > Cc: Rob Clark 
> > > ---
> > >   Documentation/gpu/drm-usage-stats.rst | 10 +-
> > >   1 file changed, 9 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > b/Documentation/gpu/drm-usage-stats.rst
> > > index 6dc299343b48..ef5c0a0aa477 100644
> > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > @@ -128,7 +128,9 @@ Memory
> > >   Each possible memory type which can be used to store buffer
> > > objects by the
> > >   GPU in question shall be given a stable and unique name to be
> > > returned as the
> > > -string here.  The name "memory" is reserved to refer to normal
> > > system memory.
> > > +string here.
> > > +
> > > +The region name "memory" is reserved to refer to normal system memory.
> > >   Value shall reflect the amount of storage currently consumed by
> > > the buffer
> > >   objects belong to this client, in the respective memory region.
> > > @@ -136,6 +138,9 @@ objects belong to this client, in the respective
> > > memory region.
> > >   Default unit shall be bytes with optional unit specifiers of 'KiB'
> > > or 'MiB'
> > >   indicating kibi- or mebi-bytes.
> > > +This is an alias for drm-total- and only one of the two
> > > should be
> > > +present.

This feels a bit awkward and seems to needlessly complicate fdinfo uapi.

- Could we just patch amdgpu to follow everyone else, and avoid the
  special case? If there's no tool that relies on the special amdgpu
  prefix then that would be a lot easier.

- If that's not on the table, could we make everyone (with a suitable
  helper or something) just print both variants, so that we again have
  consisent fdinfo output? Or breaks that a different set of existing
  tools.

- Finally maybe could we get away with fixing amd by adding the common
  format there, deprecating the old, fixing the tools that would break and
  then maybe if we're lucky, remove the old one from amdgpu in a year or
  so?

Uapi that's "either do $foo or on this one 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

Re: [RFC PATCH v4 00/42] Color Pipeline API w/ VKMS

[Daniel Vetter]

u/drm/drm_ioctl.c   |   7 +
>  drivers/gpu/drm/drm_mode_config.c |   7 +
>  drivers/gpu/drm/drm_plane.c   |  52 ++
>  drivers/gpu/drm/tests/Makefile|   3 +-
>  drivers/gpu/drm/tests/drm_fixp_test.c |  69 ++
>  drivers/gpu/drm/vkms/Kconfig  |  20 +
>  drivers/gpu/drm/vkms/Makefile |   4 +-
>  drivers/gpu/drm/vkms/tests/.kunitconfig   |   4 +
>  drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 449 ++
>  drivers/gpu/drm/vkms/vkms_colorop.c   | 100 +++
>  drivers/gpu/drm/vkms/vkms_composer.c  | 135 ++-
>  drivers/gpu/drm/vkms/vkms_drv.h   |   8 +
>  drivers/gpu/drm/vkms/vkms_luts.c  | 802 ++
>  drivers/gpu/drm/vkms/vkms_luts.h  |  12 +
>  drivers/gpu/drm/vkms/vkms_plane.c |   2 +
>  include/drm/drm_atomic.h  | 122 +++
>  include/drm/drm_atomic_uapi.h |   3 +
>  include/drm/drm_colorop.h | 301 +++
>  include/drm/drm_file.h|   7 +
>  include/drm/drm_fixed.h   |  35 +-
>  include/drm/drm_mode_config.h |  18 +
>  include/drm/drm_plane.h   |  13 +
>  include/uapi/drm/drm.h|  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

Re: Kernel 6.7+ broke under-powering of my RX 6700XT. (Archlinux, mesa/amdgpu)

[Daniel Vetter]

958946858a62b was applied.
> > >>>>>>
> > >>>>>> Side note: I assume those "lower bounds checking" is done round about
> > >>>>>> the same way by the Windows driver? Does that one allow users to go
> > >>>>>> lower somehow? Say after modifying the registry or something like 
> > >>>>>> 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

Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event

[Daniel Vetter]

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
> > > as a dependency of some other work.
> > How?
> > 
> > What I'd expected here is that you add a dependency chain from one fence
> > to another, but this only has one fence.
> 
> That's what I though initially as well, but at the point we add the
> dependency fences to the scheduler job we don't have the scheduler fence
> initialized yet.
> 
> We could change this so that we only trace all the fences after we have
> initialized the scheduler fence, but then we loose the information where the
> dependency comes from.

Hm right, I thought we'd dump the hashed pointe value into the fence
events too, then you could make the connection. But we don't, so this is a
bit annoying ...

And walking the entire scheduler dependency chain at trace_dma_fence_emit
time (or something similar) maybe?
-Sima

> > How do you figure out what's the
> > next dma_fence that will stall on this dependency?
> 
> I'm not fully sure on that either. Pierre?
> 
> Christian.
> 
> 
> >   Like in the gpu
> > scheduler we do know what will be the fence that userspace gets back, so
> > we can make that connection. And same for the atomic code (although you
> > don't wire that up at all).
> > 
> > I'm very confused on how this works and rather worried it's a brittle
> > amdgpu-only solution ...
> > -Sima
> > 
> > > I plan to use it in amdgpu.
> > > 
> > > Signed-off-by: Pierre-Eric Pelloux-Prayer 
> > > 
> > > ---
> > >   drivers/dma-buf/dma-fence.c  |  1 +
> > >   include/trace/events/dma_fence.h | 34 
> > >   2 files changed, 35 insertions(+)
> > > 
> > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > > index e0fd99e61a2d..671a499a5ccd 100644
> > > --- a/drivers/dma-buf/dma-fence.c
> > > +++ b/drivers/dma-buf/dma-fence.c
> > > @@ -23,6 +23,7 @@
> > >   EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
> > >   EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
> > >   EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
> > > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_sync_to);
> > >   static DEFINE_SPINLOCK(dma_fence_stub_lock);
> > >   static struct dma_fence dma_fence_stub;
> > > diff --git a/include/trace/events/dma_fence.h 
> > > b/include/trace/events/dma_fence.h
> > > index 3963e79ca7b4..9b3875f7aa79 100644
> > > --- a/include/trace/events/dma_fence.h
> > > +++ b/include/trace/events/dma_fence.h
> > > @@ -83,6 +83,40 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
> > >   TP_ARGS(fence)
> > >   );
> > > +DECLARE_EVENT_CLASS(dma_fence_from,
> > > +
> > > + TP_PROTO(struct dma_fence *fence, const char *reason),
> > > +
> > > + TP_ARGS(fence, reason),
> > > +
> > > + TP_STRUCT__entry(
> > > + __string(driver, fence->ops->get_driver_name(fence))
> > > + __string(timeline, fence->ops->get_timeline_name(fence))
> > > + __field(unsigned int, context)
> > > + __field(unsigned int, seqno)
> > > + __string(reason, reason)
> > > + ),
> > > +
> > > + TP_fast_assign(
> > > + __assign_str(driver, fence->ops->get_driver_name(fence));
> > > + __assign_str(timeline, fence->ops->get_timeline_name(fence));
> > > + __entry->context = fence->context;
> > > + __entry->seqno = fence->seqno;
> > > + __assign_str(reason, reason);
> > > + ),
> > > +
> > > + TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
> > > +   __get_str(driver), __get_str(timeline), __entry->context,
> > > +   __entry->seqno, __get_str(reason))
> > > +);
> > > +
> > > +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

Re: [PATCH v4 1/3] drm: Add drm_get_acpi_edid() helper

[Daniel Vetter]

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 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 intentionally put an EDID that differs from
> >>>>>> the EDID on the internal panel on laptops.  Drivers can call this
> >>>>>> helper to attempt to fetch the EDID from the BIOS's ACPI _DDC method.
> >>>>>>
> >>>>>> Signed-off-by: Mario Limonciello 
> >>>>>> ---
> >>>>>>drivers/gpu/drm/Kconfig|  5 +++
> >>>>>>drivers/gpu/drm/drm_edid.c | 77 
> >>>>>> ++
> >>>>>>include/drm/drm_edid.h |  1 +
> >>>>>>3 files changed, 83 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >>>>>> index 6ec33d36f3a4..ec2bb71e8b36 100644
> >>>>>> --- a/drivers/gpu/drm/Kconfig
> >>>>>> +++ b/drivers/gpu/drm/Kconfig
> >>>>>> @@ -21,6 +21,11 @@ menuconfig DRM
> >>>>>>select KCMP
> >>>>>>select VIDEO_CMDLINE
> >>>>>>select VIDEO_NOMODESET
> >>>>>> +  select ACPI_VIDEO if ACPI
> >>>>>> +  select BACKLIGHT_CLASS_DEVICE if ACPI
> >>>>>> +  select INPUT if ACPI
> >>>>>> +  select X86_PLATFORM_DEVICES if ACPI && X86
> >>>>>> +  select ACPI_WMI if ACPI && X86
> >>>>>
> >>>>> I think I'll defer to drm maintainers on whether this is okay or
> >>>>> something to be avoided.
> >>>>
> >>>> Uh yeah this is a bit much, and select just messes with everything. Just
> >>>> #ifdef this in the code with a dummy alternative, if users configure 
> >>>> their
> >>>> kernel without acpi but need it, they get to keep all the pieces.
> >>>>
> >>>> Alternatively make a DRM_ACPI_HELPERS symbol, but imo a Kconfig for every
> >>>> function is also not great. And just using #ifdef in the code also works
> >>>> for CONFIG_OF, which is exactly the same thing for platforms using dt to
> >>>> describe hw.
> >>>>
> >>>> Also I'd expect ACPI code to already provide dummy functions if ACPI is
> >>>> provided, so you probably dont even need all that much #ifdef in the 
> >>>> code.
> >>>>
> >>>> What we defo cant do is select platform/hw stuff just because you enable
> >>>> CONFIG_DRM.
> >>>> -Sima
> >>>
> >>> The problem was with linking.  I'll experiment with #ifdef for the next
> >>> version.
> >> 
> >> Ah yes, if e.g. acpi is a module but drm is built-in then it will compile,
> >> but not link.
> >> 
> >> You need
> >> 
> >>depends on (ACPI || ACPI=n)
> >> 
> >> for this. Looks a bit funny but works for all combinations.
> >
> > Nope; this fails at link time with this combination:
> >
> > CONFIG_ACPI=y
> > CONFIG_ACPI_VIDEO=m
> > CONFIG_DRM=y
> >
> > ld: drivers/gpu/drm/drm_edid.o: in function `drm_do_probe_acpi_edid':
> > drm_edid.c:(.text+0xd34): undefined reference to `acpi_video_get_edid'
> > make[5]: *** [scripts/Makefile.vmlinux:37: vmlinux] Error 1
> >
> > So the logical solution is to try
> > depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> >
> > But that leads me back to the rabbit hole of why I had the selects moved 
> > to drm instead of drivers in the first place:
> >
> > drivers/gpu/drm/Kconfig:8:error: recursive dependency detected!
> > drivers/gpu/drm/Kconfig:8:  symbol DRM depends on ACPI_VIDEO
> > drivers/acpi/Kconfig:213:   symbol ACPI_VIDEO depends on 
> > BACKLIGHT_CLASS_DEVICE
> > drivers/video/backlight/Kconfig:136:symbol BACKLIGHT_CLASS_DEVICE is 
> > selected by DRM_RADEON
> > drivers/gpu/drm/radeon/Kconfig:3:   symbol DRM_RADEON depend

Re: [PATCH v2 6/6] drm: add drm_mode_atomic_commit event

[Daniel Vetter]

On Tue, Feb 13, 2024 at 11:20:17AM -0500, Steven Rostedt wrote:
> On Tue, 13 Feb 2024 16:50:31 +0100
> Pierre-Eric Pelloux-Prayer  wrote:
> 
> > @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > drm_mode_object_put(obj);
> > }
> >  
> > +   if (trace_drm_mode_atomic_commit_enabled()) {
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int *crtcs;
> > +   int i, num_crtcs;
> > +
> > +   crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
> > +   GFP_KERNEL);
> 
> If the above allocation fails, this will cause a NULL kernel dereference.

Yeah can't we somehow iterate directly into the trace subsystem? If
nothing else works I guess just a per-crtc event should do.

The more fundamental issue: I don't get how this works. For atomic we
have:
- explicitly handed in in-fences as dependencies with the IN_FENCE
  property
- dependencies that drivers fish out of the dma_resv object of the
  underlying gem buffer objects for each framebuffer. That has become
  pretty much entirely generic code since everyone uses the same, and so
  imo the dependency tracking should be fully generic too

- atomic has an out-fence too, so we could even do the full fence->fence
  dependency tracking. It's just not created as a userspace object if all
  userspace asks for is a drm vblank event, but it is very much there. And
  I think if you want fence tracking, we really should have fence tracking
  :-) Also the out-fence should be 100% generic (or it's a driver bug)
  because the driver functions hide the differences between generating a
  vblank event and signalling a dma_fence.

Cheers, Sima


> 
> -- Steve
> 
> > +
> > +   num_crtcs = 0;
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +   crtcs[num_crtcs++] = drm_crtc_index(crtc);
> > +
> > +   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

Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event

[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
> as a dependency of some other work.

How?

What I'd expected here is that you add a dependency chain from one fence
to another, but this only has one fence. How do you figure out what's the
next dma_fence that will stall on this dependency? Like in the gpu
scheduler we do know what will be the fence that userspace gets back, so
we can make that connection. And same for the atomic code (although you
don't wire that up at all).

I'm very confused on how this works and rather worried it's a brittle
amdgpu-only solution ...
-Sima

> I plan to use it in amdgpu.
> 
> Signed-off-by: Pierre-Eric Pelloux-Prayer 
> ---
>  drivers/dma-buf/dma-fence.c  |  1 +
>  include/trace/events/dma_fence.h | 34 
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index e0fd99e61a2d..671a499a5ccd 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -23,6 +23,7 @@
>  EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
>  EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
>  EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
> +EXPORT_TRACEPOINT_SYMBOL(dma_fence_sync_to);
>  
>  static DEFINE_SPINLOCK(dma_fence_stub_lock);
>  static struct dma_fence dma_fence_stub;
> diff --git a/include/trace/events/dma_fence.h 
> b/include/trace/events/dma_fence.h
> index 3963e79ca7b4..9b3875f7aa79 100644
> --- a/include/trace/events/dma_fence.h
> +++ b/include/trace/events/dma_fence.h
> @@ -83,6 +83,40 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
>   TP_ARGS(fence)
>  );
>  
> +DECLARE_EVENT_CLASS(dma_fence_from,
> +
> + TP_PROTO(struct dma_fence *fence, const char *reason),
> +
> + TP_ARGS(fence, reason),
> +
> + TP_STRUCT__entry(
> + __string(driver, fence->ops->get_driver_name(fence))
> + __string(timeline, fence->ops->get_timeline_name(fence))
> + __field(unsigned int, context)
> + __field(unsigned int, seqno)
> + __string(reason, reason)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(driver, fence->ops->get_driver_name(fence));
> + __assign_str(timeline, fence->ops->get_timeline_name(fence));
> + __entry->context = fence->context;
> + __entry->seqno = fence->seqno;
> + __assign_str(reason, reason);
> + ),
> +
> + TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
> +   __get_str(driver), __get_str(timeline), __entry->context,
> +   __entry->seqno, __get_str(reason))
> +);
> +
> +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

Re: [PATCH v2 0/6] dma-fence, drm, amdgpu new trace events

[Daniel Vetter]

On Tue, Feb 13, 2024 at 04:50:25PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> This series adds new events to make it easier for tools
> like gpuvis or umr to graph the GPUs, kernel and applications
> activity.
> 
> UMR patches using these events can be found here:
> https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37
> 
> V1:
> https://patchwork.kernel.org/project/linux-media/patch/20240117184329.479554-1-pierre-eric.pelloux-pra...@amd.com/
> 
> Changes from V1:
> * uses trace_dma_fence_sync_to from dma-fence-chain.c
> * new amdgpu events
> * new drm plane commit event

I think a patch to add this to the drm/sched dependency tracking would be
really neat. With the addition of drm_sched_job_add_dependency() and
friends that would wire up some basic dependency tracking for a _lot_ of
drivers.

It should also be done before the amdgpu specific additions, because
amdgpu is also using that and we don't want to duplicate fence dependency
tracking in drivers that should be in common code.

Cheer, Sima
> 
> Pierre-Eric Pelloux-Prayer (6):
>   tracing, dma-buf: add a trace_dma_fence_sync_to event
>   dma-buf/fence-chain: use trace_dma_fence_sync_to
>   amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync
>   drm/amdgpu: add BO clear event
>   drm/amdgpu: add a amdgpu_cs_ioctl2 event
>   drm: add drm_mode_atomic_commit event
> 
>  drivers/dma-buf/dma-fence-chain.c |  4 +++
>  drivers/dma-buf/dma-fence.c   |  1 +
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |  8 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 16 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  8 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  | 11 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h  |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 28 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_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

Re: [PATCH] drm/buddy: Fix alloc_range() error handling code

[Daniel Vetter]

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 boot
> > > the machine to KDE Plasma or playing games. We have root
> > > caused the problem that whenever alloc_range() couldn't
> > > find the required memory blocks the function was returning
> > > SUCCESS in some of the corner cases.
> > > 
> > > The right approach would be if the total allocated size
> > > is less than the required size, the function should
> > > return -ENOSPC.
> > > 
> > > Cc:   # 6.7+
> > > Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
> > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
> > > Tested-by: Mario Limonciello 
> > > Link: 
> > > https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
> > > Acked-by: Christian König 
> > > Reviewed-by: Matthew Auld 
> > > Signed-off-by: Arunpravin Paneer Selvam 
> > New unit test for this would be most excellent - these kind of missed edge
> > cases is exactly what kunit is for. Can you please follow up with, since
> > we don't want to hold up the bugfix for longer?
> Matthew Auld has added a new unit test for this case. Please let us know if
> this will suffice.
> https://patchwork.freedesktop.org/patch/577497/?series=129671&rev=1

Ah yeah, might be best to submit them both together as one series (you
just need to add your own signed-off-by if you resend other people's
patches). That way bots can pick it up together, since new testcase and
bugfix only make sense together.
-Sima

> 
> Thanks,
> Arun.
> > -Sima
> > 
> > > ---
> > >   drivers/gpu/drm/drm_buddy.c | 6 ++
> > >   1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> > > index f57e6d74fb0e..c1a99bf4dffd 100644
> > > --- a/drivers/gpu/drm/drm_buddy.c
> > > +++ b/drivers/gpu/drm/drm_buddy.c
> > > @@ -539,6 +539,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

Re: [PATCH v4 1/3] drm: Add drm_get_acpi_edid() helper

[Daniel Vetter]

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 intentionally put an EDID that differs from
> > > > the EDID on the internal panel on laptops.  Drivers can call this
> > > > helper to attempt to fetch the EDID from the BIOS's ACPI _DDC method.
> > > > 
> > > > Signed-off-by: Mario Limonciello 
> > > > ---
> > > >   drivers/gpu/drm/Kconfig|  5 +++
> > > >   drivers/gpu/drm/drm_edid.c | 77 ++
> > > >   include/drm/drm_edid.h |  1 +
> > > >   3 files changed, 83 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > > index 6ec33d36f3a4..ec2bb71e8b36 100644
> > > > --- a/drivers/gpu/drm/Kconfig
> > > > +++ b/drivers/gpu/drm/Kconfig
> > > > @@ -21,6 +21,11 @@ menuconfig DRM
> > > > select KCMP
> > > > select VIDEO_CMDLINE
> > > > select VIDEO_NOMODESET
> > > > +   select ACPI_VIDEO if ACPI
> > > > +   select BACKLIGHT_CLASS_DEVICE if ACPI
> > > > +   select INPUT if ACPI
> > > > +   select X86_PLATFORM_DEVICES if ACPI && X86
> > > > +   select ACPI_WMI if ACPI && X86
> > > 
> > > I think I'll defer to drm maintainers on whether this is okay or
> > > something to be avoided.
> > 
> > Uh yeah this is a bit much, and select just messes with everything. Just
> > #ifdef this in the code with a dummy alternative, if users configure their
> > kernel without acpi but need it, they get to keep all the pieces.
> > 
> > Alternatively make a DRM_ACPI_HELPERS symbol, but imo a Kconfig for every
> > function is also not great. And just using #ifdef in the code also works
> > for CONFIG_OF, which is exactly the same thing for platforms using dt to
> > describe hw.
> > 
> > Also I'd expect ACPI code to already provide dummy functions if ACPI is
> > provided, so you probably dont even need all that much #ifdef in the code.
> > 
> > What we defo cant do is select platform/hw stuff just because you enable
> > CONFIG_DRM.
> > -Sima
> 
> The problem was with linking.  I'll experiment with #ifdef for the next
> version.

Ah yes, if e.g. acpi is a module but drm is built-in then it will compile,
but not link.

You need

depends on (ACPI || ACPI=n)

for this. Looks a bit funny but works for all combinations.

Since this gets mess it might be useful to have a DRM_ACPI_HELPERS Kconfig
that controls all this.
-Sima

> 
> > 
> > > 
> > > 
> > > > help
> > > >   Kernel-level support for the Direct Rendering Infrastructure 
> > > > (DRI)
> > > >   introduced in XFree86 4.0. If you say Y here, you need to 
> > > > select
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 923c4423151c..c649b4f9fd8e 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -28,6 +28,7 @@
> > > >* DEALINGS IN THE SOFTWARE.
> > > >*/
> > > > +#include 
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > @@ -2188,6 +2189,49 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, 
> > > > unsigned int block, size_t len)
> > > > return ret == xfers ? 0 : -1;
> > > >   }
> > > > +/**
> > > > + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> > > > + * @data: struct drm_device
> > > > + * @buf: EDID data buffer to be filled
> > > > + * @block: 128 byte EDID block to start fetching from
> > > > + * @len: EDID data buffer length to fetch
> > > > + *
> > > > + * Try to fetch EDID information by calling acpi_video_get_edid() 
> > > > function.
> > > > + *
> > > > + * Return: 0 on success or error code on failure.
> > > > + */
> > > > +static int
> > > > +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t 
> > > > len)
> > > > +{
> > > > +   struct drm_device *ddev = data;
> > > > +   struct acpi_device *acpidev

Re: [PATCH] drm/buddy: Fix alloc_range() error handling code

[Daniel Vetter]

On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
> Few users have observed display corruption when they boot
> the machine to KDE Plasma or playing games. We have root
> caused the problem that whenever alloc_range() couldn't
> find the required memory blocks the function was returning
> SUCCESS in some of the corner cases.
> 
> The right approach would be if the total allocated size
> is less than the required size, the function should
> return -ENOSPC.
> 
> Cc:   # 6.7+
> Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
> Tested-by: Mario Limonciello 
> Link: 
> https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
> Acked-by: Christian König 
> Reviewed-by: Matthew Auld 
> Signed-off-by: Arunpravin Paneer Selvam 

New unit test for this would be most excellent - these kind of missed edge
cases is exactly what kunit is for. Can you please follow up with, since
we don't want to hold up the bugfix for longer?
-Sima

> ---
>  drivers/gpu/drm/drm_buddy.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index f57e6d74fb0e..c1a99bf4dffd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -539,6 +539,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

Re: [PATCH v4 1/3] drm: Add drm_get_acpi_edid() helper

[Daniel Vetter]

erhaps drm_edid_read_acpi() to be in line with all the other struct
> drm_edid based EDID reading functions.
> 
> > + * @connector: connector we're probing
> > + *
> > + * Use the BIOS to attempt to grab EDID data if possible.
> > + *
> > + * The returned pointer must be freed using drm_edid_free().
> > + *
> > + * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > + */
> > +const struct drm_edid *drm_get_acpi_edid(struct drm_connector *connector)
> > +{
> > +   const struct drm_edid *drm_edid;
> > +
> > +   switch (connector->connector_type) {
> > +   case DRM_MODE_CONNECTOR_LVDS:
> > +   case DRM_MODE_CONNECTOR_eDP:
> > +   break;
> > +   default:
> > +   return NULL;
> > +   }
> > +
> > +   if (connector->force == DRM_FORCE_OFF)
> > +   return NULL;
> > +
> > +   drm_edid = drm_edid_read_custom(connector, drm_do_probe_acpi_edid, 
> > connector->dev);
> > +
> > +   /* Note: Do *not* call connector updates here. */
> > +
> > +   return drm_edid;
> > +}
> > +EXPORT_SYMBOL(drm_get_acpi_edid);
> > +
> >  /**
> >   * drm_edid_read_custom - 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

Re: [PATCH 3/3] drm/amdgpu: wire up the can_remove() callback

[Daniel Vetter]

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:
> > > > Removing an amdgpu device that still has user space references allocated
> > > > to it causes undefined behaviour.
> > > Then fix that please.  There should not be anything special about your
> > > hardware that all of the tens of thousands of other devices can't handle
> > > today.
> > > 
> > > What happens when I yank your device out of a system with a pci hotplug
> > > bus?  You can't prevent that either, so this should not be any different
> > > at all.
> > > 
> > > sorry, but please, just fix your driver.
> > fwiw Christian König from amd already rejected this too, I have no idea
> > why this was submitted
> 
> Well that was my fault.
> 
> I commented on an internal bug tracker that when sysfs bind/undbind is a
> different code path from PCI remove/re-scan we could try to reject it.
> 
> Turned out it isn't a different code path.

Yeah it's exactly the same code, and removing the sysfs stuff means we
cant test hotunplug without physical hotunplugging stuff anymore. So
really not great - if one is buggy so is the other, and sysfs allows us to
control the timing a lot better to hit specific issues.
-Sima

> >   since the very elaborate plan I developed with a
> > bunch of amd folks was to fix the various lifetime lolz we still have in
> > drm. We unfortunately export the world of internal objects to userspace as
> > uabi objects with dma_buf, dma_fence and everything else, but it's all
> > fixable and we have the plan even documented:
> > 
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#device-hot-unplug
> > 
> > So yeah anything that isn't that plan of record is very much no-go for drm
> > drivers. Unless we change that plan of course, but that needs a
> > documentation patch first and a big discussion.
> > 
> > Aside from an absolute massive pile of kernel-internal refcounting bugs
> > the really big one we agreed on after a lot of discussion is that SIGBUS
> > 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 of it.
> 
> Ignoring a few memory leaks because of messed up refcounting we actually got
> that working quite nicely.
> 
> At least hot unplug / hot add seems to be working rather reliable in our
> internal testing.
> 
> So it can't be that messed up.
> 
> Regards,
> Christian.
> 
> > 
> > Cheers, Sima
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 3/3] drm/amdgpu: wire up the can_remove() callback

[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:
> > Removing an amdgpu device that still has user space references allocated
> > to it causes undefined behaviour.
> 
> Then fix that please.  There should not be anything special about your
> hardware that all of the tens of thousands of other devices can't handle
> today.
> 
> What happens when I yank your device out of a system with a pci hotplug
> bus?  You can't prevent that either, so this should not be any different
> at all.
> 
> sorry, but please, just fix your driver.

fwiw Christian König from amd already rejected this too, I have no idea
why this was submitted since the very elaborate plan I developed with a
bunch of amd folks was to fix the various lifetime lolz we still have in
drm. We unfortunately export the world of internal objects to userspace as
uabi objects with dma_buf, dma_fence and everything else, but it's all
fixable and we have the plan even documented:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#device-hot-unplug

So yeah anything that isn't that plan of record is very much no-go for drm
drivers. Unless we change that plan of course, but that needs a
documentation patch first and a big discussion.

Aside from an absolute massive pile of kernel-internal refcounting bugs
the really big one we agreed on after a lot of discussion is that SIGBUS
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 of it.

Cheers, Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 1/1] drm/virtio: Implement device_attach

[Daniel Vetter]

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-buf
> > callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
> > and implement virtgpu specific map/unmap/attach callbacks to support
> > both of shmem objects and vram objects.
> > 
> > Signed-off-by: Julia Zhang 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_prime.c | 40 +++---
> >  1 file changed, 36 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> > b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > index 44425f20d91a..b490a5343b06 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > @@ -49,11 +49,26 @@ virtgpu_gem_map_dma_buf(struct dma_buf_attachment 
> > *attach,
> >  {
> > struct drm_gem_object *obj = attach->dmabuf->priv;
> > struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> > +   struct sg_table *sgt;
> > +   int ret;
> >  
> > if (virtio_gpu_is_vram(bo))
> > return virtio_gpu_vram_map_dma_buf(bo, attach->dev, dir);
> >  
> > -   return drm_gem_map_dma_buf(attach, dir);
> > +   sgt = drm_prime_pages_to_sg(obj->dev,
> > +   to_drm_gem_shmem_obj(obj)->pages,
> > +   obj->size >> PAGE_SHIFT);
> > +   if (IS_ERR(sgt))
> > +   return sgt;
> > +
> > +   ret = dma_map_sgtable(attach->dev, sgt, dir, DMA_ATTR_SKIP_CPU_SYNC);
> > +   if (ret) {
> > +   sg_free_table(sgt);
> > +   kfree(sgt);
> > +   return ERR_PTR(ret);
> > +   }
> > +
> > +   return sgt;
> >  }
> >  
> >  static void virtgpu_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> > @@ -63,12 +78,29 @@ static void virtgpu_gem_unmap_dma_buf(struct 
> > dma_buf_attachment *attach,
> > struct drm_gem_object *obj = attach->dmabuf->priv;
> > struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> >  
> > +   if (!sgt)
> > +   return;
> > +
> > if (virtio_gpu_is_vram(bo)) {
> > virtio_gpu_vram_unmap_dma_buf(attach->dev, sgt, dir);
> > -   return;
> > +   } else {
> > +   dma_unmap_sgtable(attach->dev, sgt, dir, 
> > DMA_ATTR_SKIP_CPU_SYNC);
> > +   sg_free_table(sgt);
> > +   kfree(sgt);
> > }
> > +}
> > +
> > +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf,
> > +struct dma_buf_attachment *attach)
> > +{
> > +   struct drm_gem_object *obj = attach->dmabuf->priv;
> > +   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> > +   int ret = 0;
> > +
> > +   if (!virtio_gpu_is_vram(bo) && obj->funcs->pin)
> > +   ret = obj->funcs->pin(obj);
> >  
> > -   drm_gem_unmap_dma_buf(attach, sgt, dir);
> > +   return ret;
> 
> This doesn't look like what I've expected. There should be no need to
> change the map/unmap functions, especially not for the usual gem bo case.
> We should definitely keep using the exact same code for that. Instead all
> I expected is roughly
> 
> virtgpu_gem_device_attach()
> {
>   if (virtio_gpu_is_vram(bo)) {
>   if (can_access_virtio_vram_directly(attach->dev)
>   return 0;
>   else
>   return -EBUSY;
>   } else {
>   return drm_gem_map_attach();
>   }
> }
> 
> Note that I think can_access_virtio_vram_directly() needs to be
> implemented first. I'm not even sure it's possible, might be that all the
> importers need to set the attachment->peer2peer flag. Which is why this
> thing exists really. But that's a pile more work to do.
> 
> Frankly the more I look at the original patch that added vram export
> support the more this just looks like a "pls revert, this is just too
> broken".

The commit I mean is this one: ea5ea3d8a117 ("drm/virtio: support mapping
exported vram"). The commit message definitely needs to cite that one, and
also needs a cc: stable because not rejecting invalid imports is a pretty
big deal.

Also adding David.
-Sima

> 
> We should definitely not open-code any functions for the gem_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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 1/1] drm/virtio: Implement device_attach

[Daniel Vetter]

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-buf
> callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
> and implement virtgpu specific map/unmap/attach callbacks to support
> both of shmem objects and vram objects.
> 
> Signed-off-by: Julia Zhang 
> ---
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 40 +++---
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> b/drivers/gpu/drm/virtio/virtgpu_prime.c
> index 44425f20d91a..b490a5343b06 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -49,11 +49,26 @@ virtgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
>  {
>   struct drm_gem_object *obj = attach->dmabuf->priv;
>   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> + struct sg_table *sgt;
> + int ret;
>  
>   if (virtio_gpu_is_vram(bo))
>   return virtio_gpu_vram_map_dma_buf(bo, attach->dev, dir);
>  
> - return drm_gem_map_dma_buf(attach, dir);
> + sgt = drm_prime_pages_to_sg(obj->dev,
> + to_drm_gem_shmem_obj(obj)->pages,
> + obj->size >> PAGE_SHIFT);
> + if (IS_ERR(sgt))
> + return sgt;
> +
> + ret = dma_map_sgtable(attach->dev, sgt, dir, DMA_ATTR_SKIP_CPU_SYNC);
> + if (ret) {
> + sg_free_table(sgt);
> + kfree(sgt);
> + return ERR_PTR(ret);
> + }
> +
> + return sgt;
>  }
>  
>  static void virtgpu_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> @@ -63,12 +78,29 @@ static void virtgpu_gem_unmap_dma_buf(struct 
> dma_buf_attachment *attach,
>   struct drm_gem_object *obj = attach->dmabuf->priv;
>   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
>  
> + if (!sgt)
> + return;
> +
>   if (virtio_gpu_is_vram(bo)) {
>   virtio_gpu_vram_unmap_dma_buf(attach->dev, sgt, dir);
> - return;
> + } else {
> + dma_unmap_sgtable(attach->dev, sgt, dir, 
> DMA_ATTR_SKIP_CPU_SYNC);
> + sg_free_table(sgt);
> + kfree(sgt);
>   }
> +}
> +
> +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf,
> +  struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_object *obj = attach->dmabuf->priv;
> + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> + int ret = 0;
> +
> + if (!virtio_gpu_is_vram(bo) && obj->funcs->pin)
> + ret = obj->funcs->pin(obj);
>  
> - drm_gem_unmap_dma_buf(attach, sgt, dir);
> + return ret;

This doesn't look like what I've expected. There should be no need to
change the map/unmap functions, especially not for the usual gem bo case.
We should definitely keep using the exact same code for that. Instead all
I expected is roughly

virtgpu_gem_device_attach()
{
if (virtio_gpu_is_vram(bo)) {
if (can_access_virtio_vram_directly(attach->dev)
return 0;
else
return -EBUSY;
} else {
return drm_gem_map_attach();
}
}

Note that I think can_access_virtio_vram_directly() needs to be
implemented first. I'm not even sure it's possible, might be that all the
importers need to set the attachment->peer2peer flag. Which is why this
thing exists really. But that's a pile more work to do.

Frankly the more I look at the original patch that added vram export
support the more this just looks like a "pls revert, this is just too
broken".

We should definitely not open-code any functions for the gem_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

Re: [PATCH v3 3/3] drm/amdgpu: Implement check_async_props for planes

[Daniel Vetter]

On Sun, Jan 28, 2024 at 06:25:15PM -0300, André Almeida wrote:
> AMD GPUs can do async flips with changes on more properties than just
> the FB ID, so implement a custom check_async_props for AMD planes.
> 
> Allow amdgpu to do async flips with overlay planes as well.
> 
> Signed-off-by: André Almeida 
> ---
> v3: allow overlay planes

This comment very much written with a lack of clearly better ideas, but:

Do we really need this much flexibility, especially for the first driver
adding the first few additional properties?

A simple bool on struct drm_plane to indicate whether async flips are ok
or not should also do this job here? Maybe a bit of work to roll that out
to the primary planes for current drivers, but not much. And wouldn't need
drivers to implement some very uapi-marshalling atomic code ...

Also we could probably remove the current drm_mode_config.async_flip flag
and entirely replace it with the per-plane one.
-Sima
> 
>  .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 29 +++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 116121e647ca..ed75b69636b4 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -25,6 +25,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1430,6 +1431,33 @@ static void 
> amdgpu_dm_plane_drm_plane_destroy_state(struct drm_plane *plane,
>   drm_atomic_helper_plane_destroy_state(plane, state);
>  }
>  
> +static int amdgpu_dm_plane_check_async_props(struct drm_property *prop,
> +   struct drm_plane *plane,
> +   struct drm_plane_state *plane_state,
> +   struct drm_mode_object *obj,
> +   u64 prop_value, u64 old_val)
> +{
> + struct drm_mode_config *config = &plane->dev->mode_config;
> + int ret;
> +
> + if (prop != config->prop_fb_id &&
> + prop != config->prop_in_fence_fd) {
> + ret = drm_atomic_plane_get_property(plane, plane_state,
> + prop, &old_val);
> + return drm_atomic_check_prop_changes(ret, old_val, prop_value, 
> prop);
> + }
> +
> + if (plane_state->plane->type != DRM_PLANE_TYPE_PRIMARY &&
> + plane_state->plane->type != DRM_PLANE_TYPE_OVERLAY) {
> + drm_dbg_atomic(prop->dev,
> +"[OBJECT:%d] Only primary or overlay planes can 
> be changed during async flip\n",
> +obj->id);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  static const struct drm_plane_funcs dm_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
>   .disable_plane  = drm_atomic_helper_disable_plane,
> @@ -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

Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

[Daniel Vetter]

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 
> > > connector properties */
> > > + for_each_new_connector_in_state(state, connector, new_con_state, i) 
> > > {
> > > + struct drm_crtc *crtc = new_con_state->crtc;
> > > + struct dc_stream_state *stream;
> > > +
> > > + if (crtc) {
> > > + new_crtc_state = 
> > > drm_atomic_get_new_crtc_state(state, crtc);
> > > + dm_new_crtc_state = 
> > > to_dm_crtc_state(new_crtc_state);
> > > + stream = dm_new_crtc_state->stream;
> > > +
> > > + if (stream) {
> > > + 
> > > drm_connector_set_active_color_format_property(connector,
> > > + 
> > > convert_dc_pixel_encoding_into_drm_color_format(
> > > + 
> > > dm_new_crtc_state->stream->timing.pixel_encoding));
> > > + }
> > > + } else {
> > > + 
> > > drm_connector_set_active_color_format_property(connector, 0);
> >
> > Just realized an even bigger reason why your current design doesn't work:
> > You don't have locking here.
> >
> > And you cannot grab the required lock, which is
> > drm_dev->mode_config.mutex, because that would result in deadlocks. So
> > this really needs to use the atomic state based design I've described.
> >
>
> Maybe we should just drop "actual color format" and instead fail the
> modeset if the "preferred color format" property cannot be satisfied?
> It seems like the simplest thing to do here, though it is perhaps less
> convenient for userspace. In that case, the "preferred color format"
> property should just be called "color format".

Yeah that's more in line with how other atomic properties work. This
way userspace can figure out what works with a TEST_ONLY commit too.
And for this to work you probably want to have an "automatic" setting
too.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

[Daniel Vetter]

_dm/amdgpu_dm_mst_types.c
> @@ -600,6 +600,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
> *mgr,
>   if (connector->max_bpc_property)
>   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(&aconnector->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

Re: [PATCH 1/1] drm/virtio: Implement device_attach

[Daniel Vetter]

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:
> > > > drm_gem_map_attach() requires drm_gem_object_funcs.get_sg_table to be
> > > > implemented, or else return ENOSYS. Virtio has no get_sg_table
> > > > implemented for vram object. To fix this, add a new device_attach to
> > > > call drm_gem_map_attach() for shmem object and return 0 for vram object
> > > > instead of calling drm_gem_map_attach for both of these two kinds of
> > > > object.
> > > Well as far as I can see this is nonsense from the DMA-buf side of things.
> > > 
> > > SG tables are always needed as long as you don't re-import the same object
> > > into your driver and then you shouldn't end up in this function in the 
> > > first
> > > place.
> > > 
> > > So that drm_gem_map_attach() requires get_sg_table to be implemented is
> > > intentional and should never be overridden like this.
> > See my reply, tldr; you're allowed to reject ->attach with -EBUSY to
> > handle exactly this case of non-shareable buffer types. But definitely
> > don't silently fail, that's a "we'll oops on map_attachment" kind of bug
> > :-)
> 
> Ah, yes that makes much more sense!
> 
> So basically just the "return 0;" needs to be "return -EBUSY;".

Well plus 2nd patch to polish the virtio_dma_buf docs a bit, that would be
nice :-D
-Sima

> 
> Regards,
> Christian.
> 
> > -Sima
> > 
> > > Regards,
> > > Christian.
> > > 
> > > > Signed-off-by: Julia Zhang 
> > > > ---
> > > >drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +-
> > > >1 file changed, 13 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> > > > b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > > > index 44425f20d91a..f0b0ff6f3813 100644
> > > > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> > > > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > > > @@ -71,6 +71,18 @@ static void virtgpu_gem_unmap_dma_buf(struct 
> > > > dma_buf_attachment *attach,
> > > > drm_gem_unmap_dma_buf(attach, sgt, dir);
> > > >}
> > > > +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf,
> > > > +struct dma_buf_attachment *attach)
> > > > +{
> > > > +   struct drm_gem_object *obj = attach->dmabuf->priv;
> > > > +   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> > > > +
> > > > +   if (virtio_gpu_is_vram(bo))
> > > > +   return 0;
> > > > +
> > > > +   return drm_gem_map_attach(dma_buf, attach);
> > > > +}
> > > > +
> > > >static const struct 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

Re: [PATCH 1/1] drm/virtio: Implement RESOURCE_GET_LAYOUT ioctl

[Daniel Vetter]

_u64 offset;
> + __u32 stride;
> + } planes[VIRTIO_GPU_MAX_RESOURCE_PLANES];
> +};
> +
>  /*
>   * Event code that's given when VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is in
>   * effect.  The event size is sizeof(drm_event), since there is no additional
> @@ -261,6 +278,10 @@ struct drm_virtgpu_context_init {
>   DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_CONTEXT_INIT,   \
>   struct drm_virtgpu_context_init)
>  
> +#define DRM_IOCTL_VIRTGPU_RESOURCE_QUERY_LAYOUT  
> \
> + DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_RESOURCE_QUERY_LAYOUT,  \
> + struct drm_virtgpu_resource_query_layout)
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> index f556fde07b76..547575232376 100644
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -65,6 +65,11 @@
>   */
>  #define VIRTIO_GPU_F_CONTEXT_INIT4
>  
> +/*
> + * VIRTIO_GPU_CMD_RESOURCE_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

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

[Daniel Vetter]

On Tue, Jan 09, 2024 at 11:12:11PM +, Andri Yngvason wrote:
> Hi Daniel,
> 
> þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone :
> 
> > On Tue, 9 Jan 2024 at 18:12, Andri Yngvason  wrote:
> > > + * active color format:
> > > + * This read-only property tells userspace the color format
> > actually used
> > > + * by the hardware display engine "on the cable" on a connector.
> > The chosen
> > > + * value depends on hardware capabilities, both display engine and
> > > + * connected monitor. Drivers shall use
> > > + * drm_connector_attach_active_color_format_property() to install
> > this
> > > + * property. Possible values are "not applicable", "rgb",
> > "ycbcr444",
> > > + * "ycbcr422", and "ycbcr420".
> >
> > How does userspace determine what's happened without polling? Will it
> > only change after an `ALLOW_MODESET` commit, and be guaranteed to be
> > updated after the commit has completed and the event being sent?
> > Should it send a HOTPLUG event? Other?
> >
> 
> Userspace does not determine what's happened without polling. The purpose
> of this property is not for programmatic verification that the preferred
> property was applied. It is my understanding that it's mostly intended for
> debugging purposes. It should only change as a consequence of modesetting,
> although I didn't actually look into what happens if you set the "preferred
> color format" outside of a modeset.

This feels a bit irky to me, since we don't have any synchronization and
it kinda breaks how userspace gets to know about stuff.

For context the current immutable properties are all stuff that's derived
from the sink (like edid, or things like that). Userspace is guaranteed to
get a hotplug event (minus driver bugs as usual) if any of these change,
and we've added infrastructure so that the hotplug event even contains the
specific property so that userspace can avoid re-read (which can cause
some costly re-probing) them all.

As an example you can look at drm_connector_set_link_status_property,
which drivers follow by a call to drm_kms_helper_connector_hotplug_event
to make sure userspace knows about what's up. Could be optimized I think.

This thing here works entirely differently, and I think we need somewhat
new semantics for this:

- I agree it should be read-only for userspace, so immutable sounds right.

- But I also agree with Daniel Stone that this should be tied more
  directly to the modeset state.

So I think the better approach would be to put the output type into
drm_connector_state, require that drivers compute it in their
->atomic_check code (which in the future would allow us to report it out
for TEST_ONLY commits too), and so guarantee that the value is updated
right after 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 things in sway, calling the
> "preferred_signal_format" command triggers a modeset with the "preferred
> color format" set and calling "get_outputs", immediately queries the
> "actual color format" and displays it.
> 
> Regards,
> Andri

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/1] drm/virtio: Implement device_attach

[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:
> > drm_gem_map_attach() requires drm_gem_object_funcs.get_sg_table to be
> > implemented, or else return ENOSYS. Virtio has no get_sg_table
> > implemented for vram object. To fix this, add a new device_attach to
> > call drm_gem_map_attach() for shmem object and return 0 for vram object
> > instead of calling drm_gem_map_attach for both of these two kinds of
> > object.
> 
> Well as far as I can see this is nonsense from the DMA-buf side of things.
> 
> SG tables are always needed as long as you don't re-import the same object
> into your driver and then you shouldn't end up in this function in the first
> place.
> 
> So that drm_gem_map_attach() requires get_sg_table to be implemented is
> intentional and should never be overridden like this.

See my reply, tldr; you're allowed to reject ->attach with -EBUSY to
handle exactly this case of non-shareable buffer types. But definitely
don't silently fail, that's a "we'll oops on map_attachment" kind of bug
:-)
-Sima

> 
> Regards,
> Christian.
> 
> > 
> > Signed-off-by: Julia Zhang 
> > ---
> >   drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +-
> >   1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> > b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > index 44425f20d91a..f0b0ff6f3813 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > @@ -71,6 +71,18 @@ static void virtgpu_gem_unmap_dma_buf(struct 
> > dma_buf_attachment *attach,
> > drm_gem_unmap_dma_buf(attach, sgt, dir);
> >   }
> > +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf,
> > +struct dma_buf_attachment *attach)
> > +{
> > +   struct drm_gem_object *obj = attach->dmabuf->priv;
> > +   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> > +
> > +   if (virtio_gpu_is_vram(bo))
> > +   return 0;
> > +
> > +   return drm_gem_map_attach(dma_buf, attach);
> > +}
> > +
> >   static const struct 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

Re: [PATCH 1/1] drm/virtio: Implement device_attach

[Daniel Vetter]

On Wed, Jan 10, 2024 at 05:56:28PM +0800, Julia Zhang wrote:
> drm_gem_map_attach() requires drm_gem_object_funcs.get_sg_table to be
> implemented, or else return ENOSYS. Virtio has no get_sg_table
> implemented for vram object. To fix this, add a new device_attach to
> call drm_gem_map_attach() for shmem object and return 0 for vram object
> instead of calling drm_gem_map_attach for both of these two kinds of
> object.
> 
> Signed-off-by: Julia Zhang 
> ---
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> b/drivers/gpu/drm/virtio/virtgpu_prime.c
> index 44425f20d91a..f0b0ff6f3813 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -71,6 +71,18 @@ static void virtgpu_gem_unmap_dma_buf(struct 
> dma_buf_attachment *attach,
>   drm_gem_unmap_dma_buf(attach, sgt, dir);
>  }
>  
> +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf,
> +  struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_object *obj = attach->dmabuf->priv;
> + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> +
> + if (virtio_gpu_is_vram(bo))
> + return 0;

You need to reject attach here because these vram buffer objects cannot be
used by any other driver. In that case dma_buf_attach _must_ fail, not
silently succeed.

Because if it silently succeeds then the subsequent dma_buf_map_attachment
will blow up because you don't have the ->get_sg_table hook implemented.

Per the documentation the error code for this case must be -EBUSY, see the
section for the attach hook here:

https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#c.dma_buf_ops

Since you're looking into this area, please make sure there's not other
similar mistake in virtio code.

Also can you please make a kerneldoc patch for struct virtio_dma_buf_ops
to improve the documentation there? I think it would be good to move those
to the inline style and then at least put a kernel-doc hyperlink to struct
dma_buf_ops.attach and mention that attach must fail for non-shareable
buffers.

In general the virtio_dma_buf kerneldoc seems to be on the "too minimal,
explains nothing" side of things :-/

Cheers, Sima

> +
> + return drm_gem_map_attach(dma_buf, attach);
> +}
> +
>  static const struct 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,
>  };
>  
> -- 
> 2.34.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Daniel Vetter]

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 schrieb Alex Deucher:
> >>>> Add shared stats.  Useful for seeing shared memory.
> >>>>
> >>>> v2: take dma-buf into account as well
> >>>>
> >>>> Signed-off-by: Alex Deucher 
> >>>> Cc: Rob Clark 
> >>>> ---
> >>>>drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
> >>>>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
> >>>>drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
> >>>>3 files changed, 21 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> >>>> index 5706b282a0c7..c7df7fa3459f 100644
> >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> >>>> @@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
> >>>> struct drm_file *file)
> >>>>   stats.requested_visible_vram/1024UL);
> >>>>drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
> >>>>   stats.requested_gtt/1024UL);
> >>>> +drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
> >>>> stats.vram_shared/1024UL);
> >>>> +drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
> >>>> stats.gtt_shared/1024UL);
> >>>> +drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
> >>>> stats.cpu_shared/1024UL);
> >>>> +
> >>>>for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
> >>>>if (!usage[hw_ip])
> >>>>continue;
> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> index d79b4ca1ecfc..1b37d95475b8 100644
> >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> @@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
> >>>>  struct amdgpu_mem_stats *stats)
> >>>>{
> >>>>uint64_t size = amdgpu_bo_size(bo);
> >>>> +struct drm_gem_object *obj;
> >>>>unsigned int domain;
> >>>> +bool shared;
> >>>>/* Abort if the BO doesn't currently have a backing store */
> >>>>if (!bo->tbo.resource)
> >>>>return;
> >>>> +obj = &bo->tbo.base;
> >>>> +shared = (obj->handle_count > 1) || obj->dma_buf;
> >>>
> >>> I still think that looking at handle_count is the completely wrong
> >>> approach, we should really only look at obj->dma_buf.
> >>
> >> Yeah it is all a bit tricky with the handle table walk. I don't think it is
> >> even possible to claim it is shared with obj->dma_buf could be the same
> >> process creating say via udmabuf and importing into drm. It is a wild
> >> scenario yes, but it could be private memory in that case. Not sure where 
> >> it
> >> would leave us if we said this is just a limitation of a BO based tracking.
> >>
> >> Would adding a new category "imported" help?
> >>
> >> Hmm or we simply change drm-usage-stats.rst:
> >>
> >> """
> >> - drm-shared-:  [KiB|MiB]
> >>
> >> The total size of buffers that are shared with another file (ie. have more
> >> than than a single handle).
> >> """
> >>
> >> Changing ie into eg coule be get our of jail free card to allow the
> >> "(obj->handle_count > 1) || obj->dma_buf;" condition?
> >>
> >> Because of the shared with another _file_ wording would cover my wild
> >> udmabuf self-import case. Unless there are more such creative private 
> >> import
> >> options.
> >
> > Yeah I think clarifying that we can only track sharing with other fd and
> > have no idea whether this means sharing with another process or not is
> &g

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Daniel Vetter]

    if (amdgpu_bo_in_cpu_visible_vram(bo))
> > >   stats->visible_vram += size;
> > > +    if (shared)
> > > +    stats->vram_shared += size;
> > >   break;
> > >   case AMDGPU_GEM_DOMAIN_GTT:
> > >   stats->gtt += size;
> > > +    if (shared)
> > > +    stats->gtt_shared += size;
> > >   break;
> > >   case AMDGPU_GEM_DOMAIN_CPU:
> > >   default:
> > >   stats->cpu += size;
> > > +    if (shared)
> > > +    stats->cpu_shared += size;
> > >   break;
> > >   }
> > > 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

Re: [PATCH v5 00/32] drm/amd/display: add AMD driver-specific properties for color mgmt

[Daniel Vetter]

On Tue, 28 Nov 2023 at 23:11, Harry Wentland  wrote:
>
> On 2023-11-16 14:57, Melissa Wen wrote:
> > Hello,
> >
> > This series extends the current KMS color management API with AMD
> > driver-specific properties to enhance the color management support on
> > AMD Steam Deck. The key additions to the color pipeline include:
> >
>
> snip
>
> > Melissa Wen (18):
> >   drm/drm_mode_object: increase max objects to accommodate new color
> > props
> >   drm/drm_property: make replace_property_blob_from_id a DRM helper
> >   drm/drm_plane: track color mgmt changes per plane
>
> If all patches are merged through amd-staging-drm-next I worry that
> conflicts creep in if any code around replace_property_blob_from_id
> changes in DRM.
>
> My plan is to merge DRM patches through drm-misc-next, as well
> as include them in the amd-staging-drm-next merge. They should then
> fall out at the next amd-staging-drm-next pull and (hopefully)
> ensure that there is no conflict.
>
> If no objections I'll go ahead with that later this week.

Double-merging tends to be the worst because git doesn't realize the
commits match, which actually makes the conflicts worse when they
happen (because the 3-way merge diff gets absolute confused by all the
changed context and misplaces everything to the max). So please don't,
_only_ every cherry-pick when a patch in -next is also needed in
-fixes, and we didn't put it into the right tree. But even that is a
bit tricky and should only be done by maintainers (using dim
cherry-pick if it's drm-misc) because the conflicts tend to be bad and
need to be sorted out with backmerges sooner than later.

For this case merge everything through one tree with the right acks,
pull to drm-next asap and then backmerge into the other tree. Here
probably amdgpu-next with drm-misc maintainer acks for the 3 core
patches. Or if amdgpu-next pull won't come for a while, put them into
drm-misc-next and just wait a week until it's in drm-next, then
forward amdgpu-next.

Cheers, Sima

> Harry
>
> >   drm/amd/display: add driver-specific property for plane degamma LUT
> >   drm/amd/display: explicitly define EOTF and inverse EOTF
> >   drm/amd/display: document AMDGPU pre-defined transfer functions
> >   drm/amd/display: add plane 3D LUT driver-specific properties
> >   drm/amd/display: add plane shaper LUT and TF driver-specific
> > properties
> >   drm/amd/display: add CRTC gamma TF driver-specific property
> >   drm/amd/display: add comments to describe DM crtc color mgmt behavior
> >   drm/amd/display: encapsulate atomic regamma operation
> >   drm/amd/display: decouple steps for mapping CRTC degamma to DC plane
> >   drm/amd/display: reject atomic commit if setting both plane and CRTC
> > degamma
> >   drm/amd/display: add plane shaper LUT support
> >   drm/amd/display: add plane shaper TF support
> >   drm/amd/display: add plane 3D LUT support
> >   drm/amd/display: add plane CTM driver-specific property
> >   drm/amd/display: add plane CTM support
> >
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  91 ++
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  34 +-
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 108 +++
> >  .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 818 --
> >  .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c|  72 ++
> >  .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 232 -
> >  .../gpu/drm/amd/display/include/fixed31_32.h  |  12 +
> >  drivers/gpu/drm/arm/malidp_crtc.c |   2 +-
> >  drivers/gpu/drm/drm_atomic.c  |   1 +
> >  drivers/gpu/drm/drm_atomic_state_helper.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

Re: [pull] amdgpu drm-fixes-6.7

[Daniel Vetter]

On Fri, Nov 17, 2023 at 01:34:41AM -0500, Alex Deucher wrote:
> Hi Dave, Sima,
> 
> Fixes for 6.7.
> 
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
> 
>   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.7-2023-11-17
> 
> for you to fetch changes up to e8c2d3e25b844ad8f7c8b269a7cfd65285329264:
> 
>   drm/amdgpu/gmc9: disable AGP aperture (2023-11-17 00:58:41 -0500)

Pulled to drm-fixes, thanks!
-Sima
> 
> 
> amd-drm-fixes-6.7-2023-11-17:
> 
> amdgpu:
> - DMCUB fixes
> - SR-IOV fix
> - GMC9 fix
> - Documentation fix
> - DSC MST fix
> - CS chunk parsing fix
> - SMU13.0.6 fixes
> - 8K tiled display fix
> - Fix potential NULL pointer dereferences
> - Cursor lag fix
> - Backlight fix
> - DCN s0ix fix
> - XGMI fix
> - DCN encoder disable logic fix
> - AGP aperture fixes
> 
> 
> Alex Deucher (5):
>   drm/amdgpu/gmc11: fix logic typo in AGP check
>   drm/amdgpu: add a module parameter to control the AGP aperture
>   drm/amdgpu/gmc11: disable AGP aperture
>   drm/amdgpu/gmc10: disable AGP aperture
>   drm/amdgpu/gmc9: disable AGP aperture
> 
> Asad Kamal (2):
>   drm/amd/pm: Update metric table for smu v13_0_6
>   drm/amd/pm: Fill pcie error counters for gpu v1_4
> 
> Duncan Ma (1):
>   drm/amd/display: Negate IPS allow and commit bits
> 
> Fangzhi Zuo (1):
>   drm/amd/display: Fix DSC not Enabled on Direct MST Sink
> 
> José Pekkarinen (1):
>   drm/amd/display: fix NULL dereference
> 
> Le Ma (1):
>   drm/amdgpu: finalizing mem_partitions at the end of GMC v9 sw_fini
> 
> Lewis Huang (1):
>   drm/amd/display: Change the DMCUB mailbox memory location from FB to 
> inbox
> 
> Lijo Lazar (1):
>   drm/amd/pm: Don't send unload message for reset
> 
> Mario Limonciello (1):
>   drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer()
> 
> Muhammad Ahmed (1):
>   drm/amd/display: Add null checks for 8K60 lightup
> 
> Nicholas Kazlauskas (1):
>   drm/amd/display: Guard against invalid RPTR/WPTR being set
> 
> Nicholas Susanto (1):
>   drm/amd/display: Fix encoder disable logic
> 
> Paul Hsieh (1):
>   drm/amd/display: Clear dpcd_sink_ext_caps if not set
> 
> Shiwu Zhang (1):
>   drm/amdgpu: add and populate the port num into xgmi topology info
> 
> Srinivasan Shanmugam (1):
>   drm/amdgpu: Address member 'ring' not described in 'amdgpu_ vce, 
> uvd_entity_init()'
> 
> Tianci Yin (1):
>   drm/amd/display: Enable fast plane updates on DCN3.2 and above
> 
> Victor Lu (1):
>   drm/amdgpu: Do not program VF copy regs in mmhub v1.8 under SRIOV (v2)
> 
> Yang Wang (1):
>   drm/amdgpu: fix ras err_data null pointer issue in amdgpu_ras.c
> 
> YuanShang (1):
>   drm/amdgpu: correct chunk_ptr to a pointer to chunk.
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 10 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|  5 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c |  5 ++-
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  7 +--
>  drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c|  6 +--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 24 ++-
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |  5 +--
>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 29 ++---
>  .../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c   | 18 
>  drivers/gpu/drm/amd/display/dc/core/dc.c   |  6 +--
>  drivers/gpu/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 ++
>  drivers/gpu/drm/amd/display/dmub/dmub_srv.h| 22 ++
>  drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c| 50 
> +-
>  .../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_pmfw.h| 10 -
>  .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c   | 10 -
>  26 files changed, 160 insertions(+), 84 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu drm-next-6.7

[Daniel Vetter]

  |   7 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_svm.c   |   8 +-
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |   3 +
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h|   2 +-
>  .../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c   |  21 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c   |  27 +-
>  drivers/gpu/drm/amd/display/dc/dc.h|   2 +-
>  drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c   |  74 +
>  drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h   |   8 +
>  drivers/gpu/drm/amd/display/dc/dc_dp_types.h   |   3 +-
>  drivers/gpu/drm/amd/display/dc/dc_types.h  |   4 +-
>  drivers/gpu/drm/amd/display/dc/dce/dce_abm.h   |  15 -
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.h  | 186 +---
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c   |  10 +-
>  drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dccg.c  |  73 ++---
>  .../gpu/drm/amd/display/dc/dcn35/dcn35_pg_cntl.c   |  10 +-
>  .../gpu/drm/amd/display/dc/dcn35/dcn35_pg_cntl.h   |   1 +
>  .../gpu/drm/amd/display/dc/dcn35/dcn35_resource.c  |  37 ++-
>  .../amd/display/dc/dml/dcn30/display_mode_vba_30.c |   2 +-
>  .../amd/display/dc/dml2/dml2_dc_resource_mgmt.c|  61 ++--
>  .../drm/amd/display/dc/dml2/dml2_internal_types.h  |   4 +-
>  .../amd/display/dc/dml2/dml2_translation_helper.c  |  55 +++-
>  .../amd/display/dc/dml2/dml2_translation_helper.h  |   2 +-
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c   |  18 +-
>  drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.c |   2 +-
>  drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c|  11 +
>  .../gpu/drm/amd/display/dc/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

Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()

[Daniel Vetter]

new IP prior public
> exposure, but for released hardware, you really need to do the reviews
> on the mailing lists.

Aye. Maybe with the clarification that if the embargoed code touches
areas that are common code (or really should be handled in common
code), then the cross-driver parts also need to be reviewed in public
as upfront prep patches. If that's not possible (try to fix your
process to make that possible please), at least ping stakeholders in
private to give them a heads up, so that when the IP enabling gets
published it's not going to be held up in the review for the necessary
common changes. What's not good is if code that should be reviewed on
dri-devel bypasses all that just because it's part of a hardware
enabling series.

Cheers, Sima

> 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

Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()

[Daniel Vetter]

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

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

[Daniel Vetter]

> reset in
> +first place. DRM devices should make use of devcoredump to store relevant
> +information about the reset, so this information can be added to user bug
> +reports.

Since we do not seem to have a solid consensus in the community about
non-robust userspace, maybe we could just document that lack of consensus
to unblock this patch? Something like this:

Non-Robust Userspace


Userspace 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 all reasonable approaches have some clear downsides.

With the s/UMD/KMD/ further up and maybe something added to record the
non-robustness non-consensus:

Acked-by: Daniel Vetter 

Cheers, Daniel



> +
>  .. _drm_driver_ioctl:
>  
>  IOCTL Support on Device Nodes
> -- 
> 2.41.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu, amdkfd, radeon drm-next-6.6

[Daniel Vetter]

/amd/display/dc/dcn21/dcn21_dccg.c  |   2 +-
>  drivers/gpu/drm/amd/display/dc/dcn21/dcn21_dccg.h  |   1 -
>  .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c  |   4 +-
>  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c |  25 +-
>  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c  |   4 +-
>  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h  |   3 +
>  .../gpu/drm/amd/display/dc/dcn30/dcn30_resource.c  |   4 +-
>  drivers/gpu/drm/amd/display/dc/dcn301/Makefile |   3 +-
>  .../gpu/drm/amd/display/dc/dcn301/dcn301_optc.c| 185 +++
>  .../gpu/drm/amd/display/dc/dcn301/dcn301_optc.h|  36 ++
>  .../drm/amd/display/dc/dcn301/dcn301_resource.c|  10 +-
>  .../drm/amd/display/dc/dcn303/dcn303_resource.c|   2 +-
>  drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c  |  52 +-
>  drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.h  |   5 +
>  .../amd/display/dc/dcn31/dcn31_dio_link_encoder.c  |   2 +-
>  .../display/dc/dcn31/dcn31_hpo_dp_stream_encoder.c |   2 +-
>  .../gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c|   1 +
>  .../drm/amd/display/dc/dcn314/dcn314_resource.c|  18 +-
>  .../drm/amd/display/dc/dcn315/dcn315_resource.c|   2 +-
>  drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c  |   5 +-
>  drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hwseq.c |   2 -
>  .../gpu/drm/amd/display/dc/dcn32/dcn32_resource.c  |   2 +-
>  .../amd/display/dc/dcn32/dcn32_resource_helpers.c  |  24 +-
>  .../amd/display/dc/dml/dcn21/display_mode_vba_21.c |   2 +-
>  .../amd/display/dc/dml/dcn31/display_mode_vba_31.c |   2 +-
>  .../gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c |  31 +-
>  .../display/dc/dml/dcn314/display_mode_vba_314.c   |   2 +-
>  .../gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c   |  24 +-
>  .../dc/dml/dcn32/display_mode_vba_util_32.c|   9 +-
>  drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c|  66 ++-
>  drivers/gpu/drm/amd/display/dc/inc/hw/abm.h|   6 +
>  drivers/gpu/drm/amd/display/dc/inc/hw/aux_engine.h |   2 -
>  drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h   |   5 +
>  .../amd/display/dc/irq/dcn314/irq_service_dcn314.c |   7 +-
>  .../amd/display/dc/link/accessories/link_dp_cts.c  | 107 ++--
>  .../amd/display/dc/link/hwss/link_hwss_hpo_dp.c|  10 +
>  .../gpu/drm/amd/display/dc/link/link_detection.c   |   3 +-
>  drivers/gpu/drm/amd/display/dc/link/link_dpms.c|  21 +-
>  .../gpu/drm/amd/display/dc/link/link_validation.c  |   8 +-
>  .../drm/amd/display/dc/link/protocols/link_ddc.c   |   2 +-
>  .../display/dc/link/protocols/link_dp_capability.c |  22 +-
>  .../display/dc/link/protocols/link_dp_training.c   |   9 +-
>  .../link_dp_training_fixed_vs_pe_retimer.c |  90 +++-
>  .../dc/link/protocols/link_edp_panel_control.c |  80 +--
>  .../dc/link/protocols/link_edp_panel_control.h |   1 +
>  drivers/gpu/drm/amd/display/dmub/dmub_srv.h|   7 +
>  drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h| 131 +
>  .../drm/amd/display/dmub/inc/dmub_subvp_state.h| 183 ---
>  drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c  |   8 +
>  drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.h  |   2 +
>  drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c|  31 +-
>  .../drm/amd/display/include/link_service_types.h   |   2 +-
>  drivers/gpu/drm/amd/include/amd_shared.h   |   1 +
>  drivers/gpu/drm/amd/include/kgd_kfd_interface.h|   9 +-
>  drivers/gpu/drm/amd/include/kgd_pp_interface.h |  69 +++
>  drivers/gpu/drm/amd/include/mes_v11_api_def.h  |   4 +-
>  drivers/gpu/drm/amd/include/yellow_carp_offset.h   |   6 +-
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c |   3 +-
>  drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h |   3 +-
>  drivers/gpu/drm/amd/pm/inc/smu_v13_0_0_pptable.h   |  21 +-
>  .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c|  14 +-
>  .../gpu/drm/amd/pm/swsmu/inc/smu_11_0_cdr_table.h  |   6 +-
>  drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h   |   4 +
>  .../gpu/drm/amd/pm/swsmu/inc/smu_v13_0_7_pptable.h |  21 +-
>  drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c  |   6 +-
>  drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c|  27 +-
>  .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c|  99 +---
>  drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c   | 109 +++-
>  drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.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

Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set

[Daniel Vetter]

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:
> >>> From: Pekka Paalanen 
> >>>
> >>> Specify how the atomic state is maintained between userspace and
> >>> kernel, plus the special case for async flips.
> >>>
> >>> Signed-off-by: Pekka Paalanen 
> >>> Signed-off-by: André Almeida 
> >>> ---
> >>> v4: total rework by Pekka
> >>> ---
> >>>   Documentation/gpu/drm-uapi.rst | 41 ++
> >>>   1 file changed, 41 insertions(+)
> >>>
> >>> diff --git a/Documentation/gpu/drm-uapi.rst 
> >>> b/Documentation/gpu/drm-uapi.rst
> >>> index 65fb3036a580..6a1662c08901 100644
> >>> --- a/Documentation/gpu/drm-uapi.rst
> >>> +++ b/Documentation/gpu/drm-uapi.rst
> >>> @@ -486,3 +486,44 @@ and the CRTC index is its position in this array.
> >>>
> >>>   .. kernel-doc:: include/uapi/drm/drm_mode.h
> >>>  :internal:
> >>> +
> >>> +KMS atomic state
> >>> +
> >>> +
> >>> +An atomic commit can change multiple KMS properties in an atomic fashion,
> >>> +without ever applying intermediate or partial state changes.  Either the 
> >>> whole
> >>> +commit succeeds or fails, and it will never be applied partially. This 
> >>> is the
> >>> +fundamental improvement of the atomic API over the older non-atomic API 
> >>> which is
> >>> +referred to as the "legacy API".  Applying intermediate state could 
> >>> unexpectedly
> >>> +fail, cause visible glitches, or delay reaching the final state.
> >>> +
> >>> +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which 
> >>> means the
> >>> +complete state change is validated but not applied.  Userspace should 
> >>> use this
> >>> +flag to validate any state change before asking to apply it. If 
> >>> validation fails
> >>> +for any reason, userspace should attempt to fall back to another, perhaps
> >>> +simpler, final state.  This allows userspace to probe for various 
> >>> configurations
> >>> +without causing visible glitches on screen and without the need to undo a
> >>> +probing change.
> >>> +
> >>> +The changes recorded in an atomic commit apply on top the current KMS 
> >>> state in
> >>> +the kernel. Hence, the complete new KMS state is the complete old KMS 
> >>> state with
> >>> +the committed property settings done on top. The kernel will 
> >>> automatically avoid
> >>> +no-operation changes, so it is safe and even expected for userspace to 
> >>> send
> >>> +redundant property settings.  No-operation changes do not count towards 
> >>> actually
> >>> +needed changes, e.g.  setting MODE_ID to a different blob with identical
> >>> +contents as the current KMS state shall not be a modeset on its own.
> >>
> >> Small clarification: The kernel indeed tries very hard to make redundant
> >> changes a no-op, and I think we should consider any issues here bugs. But
> >> it still has to check, which means it needs to acquire the right locks and
> >> put in the right (cross-crtc) synchronization points, and due to
> >> implmentation challenges it's very hard to try to avoid that in all cases.
> >> So adding redundant changes especially across crtc (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 
> >
> > After talking on IRC yesterday, we realized that the no-op rule is
> > nowhere near as generic as I have believed. Roughly:
> > https://oftc.irclog.whitequark.org/dri-devel/2023-07-12#1689152446-1689157291;
> >
> >
>
> How about:
>
> The changes recorded in an atomic commit apply on top the current KMS
> state in the kernel. Hence, the complete new KMS state is the complete
> old KMS state with the committed property settings done on top. The
> kernel will try to avoid no-operation changes, so it is safe for

Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set

[Daniel Vetter]

On Fri, Jul 07, 2023 at 07:40:59PM -0300, André Almeida wrote:
> From: Pekka Paalanen 
> 
> Specify how the atomic state is maintained between userspace and
> kernel, plus the special case for async flips.
> 
> Signed-off-by: Pekka Paalanen 
> Signed-off-by: André Almeida 
> ---
> v4: total rework by Pekka
> ---
>  Documentation/gpu/drm-uapi.rst | 41 ++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 65fb3036a580..6a1662c08901 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -486,3 +486,44 @@ and the CRTC index is its position in this array.
>  
>  .. kernel-doc:: include/uapi/drm/drm_mode.h
> :internal:
> +
> +KMS atomic state
> +
> +
> +An atomic commit can change multiple KMS properties in an atomic fashion,
> +without ever applying intermediate or partial state changes.  Either the 
> whole
> +commit succeeds or fails, and it will never be applied partially. This is the
> +fundamental improvement of the atomic API over the older non-atomic API 
> which is
> +referred to as the "legacy API".  Applying intermediate state could 
> unexpectedly
> +fail, cause visible glitches, or delay reaching the final state.
> +
> +An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which means 
> the
> +complete state change is validated but not applied.  Userspace should use 
> this
> +flag to validate any state change before asking to apply it. If validation 
> fails
> +for any reason, userspace should attempt to fall back to another, perhaps
> +simpler, final state.  This allows userspace to probe for various 
> configurations
> +without causing visible glitches on screen and without the need to undo a
> +probing change.
> +
> +The changes recorded in an atomic commit apply on top the current KMS state 
> in
> +the kernel. Hence, the complete new KMS state is the complete old KMS state 
> with
> +the committed property settings done on top. The kernel will automatically 
> avoid
> +no-operation changes, so it is safe and even expected for userspace to send
> +redundant property settings.  No-operation changes do not count towards 
> actually
> +needed changes, e.g.  setting MODE_ID to a different blob with identical
> +contents as the current KMS state shall not be a modeset on its own.

Small clarification: The kernel indeed tries very hard to make redundant
changes a no-op, and I think we should consider any issues here bugs. But
it still has to check, which means it needs to acquire the right locks and
put in the right (cross-crtc) synchronization points, and due to
implmentation challenges it's very hard to try to avoid that in all cases.
So adding redundant changes especially across crtc (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, disable, or 
> temporarily
> +disrupt the emitted video signal, possibly causing visible glitches on 
> screen. A
> +modeset may also take considerably more time to complete than other kinds of
> +changes, and the video sink might also need time to adapt to the new signal
> +properties. Therefore a modeset must be explicitly allowed with the flag
> +DRM_MODE_ATOMIC_ALLOW_MODESET.  This in combination with
> +DRM_MODE_ATOMIC_TEST_ONLY allows userspace to determine if a state change is
> +likely to cause visible disruption on screen and avoid such changes when end
> +users do not expect them.
> +
> +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is allowed to
> +effectively change only the FB_ID property on any planes. No-operation 
> changes
> +are ignored as always. Changing any other property will cause the commit to 
> be
> +rejected.
> -- 
> 2.41.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu drm-fixes-6.3

[Daniel Vetter]

On Wed, Apr 12, 2023 at 05:56:37PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Fixes for 6.3.
> 
> The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d:
> 
>   Linux 6.3-rc6 (2023-04-09 11:15:57 -0700)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.3-2023-04-12
> 
> for you to fetch changes up to b9a24d8bd51e2db425602fa82d7f4c06aa3db852:
> 
>   drm/amd/pm: correct the pcie link state check for SMU13 (2023-04-12 
> 16:11:22 -0400)

Pulled, thanks
> 
> 
> amd-drm-fixes-6.3-2023-04-12:
> 
> amdgpu:
> - SMU13 fixes
> - DP MST fix
> 
> 
> Evan Quan (1):
>   drm/amd/pm: correct the pcie link state check for SMU13
> 
> Horatio Zhang (2):
>   drm/amd/pm: correct SMU13.0.7 pstate profiling clock settings
>   drm/amd/pm: correct SMU13.0.7 max shader clock reporting
> 
> Wayne Lin (1):
>   drm/amd/display: Pass the right info to drm_dp_remove_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 
> +++---
>  4 files changed, 135 insertions(+), 19 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 3/7] drm/amdgpu: Switch to fdinfo helper

[Daniel Vetter]

On Tue, Apr 11, 2023 at 03:56:08PM -0700, Rob Clark wrote:
> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  3 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |  2 +-
>  3 files changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index f5ffca24def4..3611cfd5f076 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2752,7 +2752,7 @@ static const struct file_operations 
> amdgpu_driver_kms_fops = {
>   .compat_ioctl = amdgpu_kms_compat_ioctl,
>  #endif
>  #ifdef CONFIG_PROC_FS
> - .show_fdinfo = amdgpu_show_fdinfo
> + .show_fdinfo = drm_fop_show_fdinfo,
>  #endif
>  };
>  
> @@ -2807,6 +2807,7 @@ static const struct drm_driver amdgpu_kms_driver = {
>   .dumb_map_offset = amdgpu_mode_dumb_mmap,
>   .fops = &amdgpu_driver_kms_fops,
>   .release = &amdgpu_driver_release_kms,
> + .show_fdinfo = amdgpu_show_fdinfo,
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> index 99a7855ab1bc..c2fdd5e448d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> @@ -53,9 +53,8 @@ static const char *amdgpu_ip_name[AMDGPU_HW_IP_NUM] = {
>   [AMDGPU_HW_IP_VCN_JPEG] =   "jpeg",
>  };
>  
> -void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
> +void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file)
>  {
> - struct drm_file *file = f->private_data;
>   struct amdgpu_device *adev = drm_to_adev(file->minor->dev);
>   struct amdgpu_fpriv *fpriv = file->driver_priv;
>   struct amdgpu_vm *vm = &fpriv->vm;
> @@ -86,18 +85,15 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file 
> *f)
>* **
>*/
>  
> - seq_printf(m, "pasid:\t%u\n", fpriv->vm.pasid);
> - seq_printf(m, "drm-driver:\t%s\n", file->minor->dev->driver->name);
> - seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", domain, bus, dev, fn);
> - seq_printf(m, "drm-client-id:\t%Lu\n", vm->immediate.fence_context);
> - seq_printf(m, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
> - seq_printf(m, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
> - seq_printf(m, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
> + drm_printf(p, "pasid:\t%u\n", fpriv->vm.pasid);
> + drm_printf(p, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
> + drm_printf(p, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
> + drm_printf(p, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);

random aside, but we're not super consistent here, some of these have an
additional ' ' space.

I guess a next step would be a drm_fdinfo_printf(drm_printer *p, const
char *name, const char *printf, ...) and maybe some specialized ones that
dtrt for specific parameters, like drm_fdinfo_llu().

But that's for next one I guess :-)
-Daniel


>   for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
>   if (!usage[hw_ip])
>   continue;
>  
> - seq_printf(m, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
> + drm_printf(p, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
>  ktime_to_ns(usage[hw_ip]));
>   }
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> index e86834bfea1d..0398f5a159ef 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> @@ -37,6 +37,6 @@
>  #include "amdgpu_ids.h"
>  
>  uint32_t amdgpu_get_ip_count(struct amdgpu_device *adev, int id);
> -void amdgpu_show_fdinfo(struct seq_file *m, struct file *f);
> +void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file);
>  
>  #endif
> -- 
> 2.39.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: fdinfo blew up? (Was: [RFC PATCH 0/4] uapi, drm: Add and implement RLIMIT_GPUPRIO)

[Daniel Vetter]

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 wrote:
> >>> Hello all!
> >>>
> >>> I would like to propose a new API for allowing processes to control
> >>> the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
> >>>
> >>> The main reason for this is for compositors such as Gamescope and
> >>> SteamVR vrcompositor to be able to create realtime async compute
> >>> queues on AMD without the need of CAP_SYS_NICE.
> >>>
> >>> The current situation is bad for a few reasons, one being that in order
> >>> to setcap the executable, typically one must run as root which involves
> >>> a pretty high privelage escalation in order to achieve one
> >>> small feat, a realtime async compute queue queue for VR or a compositor.
> >>> The executable cannot be setcap'ed inside a
> >>> container nor can the setcap'ed executable be run in a container with
> >>> NO_NEW_PRIVS.
> >>>
> >>> I go into more detail in the description in
> >>> `uapi: Add RLIMIT_GPUPRIO`.
> >>>
> >>> My initial proposal here is to add a new RLIMIT, `RLIMIT_GPUPRIO`,
> >>> which seems to make most initial sense to me to solve the problem.
> >>>
> >>> I am definitely not set that this is the best formulation however
> >>> or if this should be linked to DRM (in terms of it's scheduler
> >>> priority enum/definitions) in any way and and would really like other
> >>> people's opinions across the stack on this.
> >>>
> >>> Once initial concern is that potentially this RLIMIT could out-live
> >>> the lifespan of DRM. It sounds crazy saying it right now, something
> >>> that definitely popped into my mind when touching `resource.h`. :-)
> >>>
> >>> Anyway, please let me know what you think!
> >>> Definitely open to any feedback and advice you may have. :D
> >>
> >> Interesting! I tried to solved the similar problem two times in the past 
> >> already.
> >>
> >> First time I was proposing to tie nice to DRM scheduling priority [1] - if 
> >> the latter has been left at default - drawing the analogy with the 
> >> nice+ionice handling. That was rejected and I was nudged towards the 
> >> cgroups route.
> >>
> >> So with that second attempt I implemented a hierarchical opaque 
> >> drm.priority cgroup controller [2]. I think it would allow you to solve 
> >> your use case too by placing your compositor in a cgroup with an elevated 
> >> priority level.
> >>
> >> Implementation wise in my proposal it was left to individual drivers to 
> >> "meld" the opaque cgroup drm.priority with the driver specific priority 
> >> concept.
> >>
> >> That too wasn't too popular with the feedback (AFAIR) that the priority is 
> >> a too subsystem specific concept.
> >>
> >> Finally I was left with a weight based drm cgroup controller, exactly 
> >> following the controls of the CPU and IO ones, but with much looser 
> >> runtime guarantees. [3]
> >>
> >> I don't think this last one works for your use case, at least not at the 
> >> current state for drm scheduling capability, where the implementation is a 
> >> "bit" too reactive for realtime.
> >>
> >> Depending on how the discussion around your rlimit proposal goes, perhaps 
> >> one alternative could be to go the cgroup route and add an attribute like 
> >> drm.realtime. That perhaps sounds abstract and generic enough to be 
> >> passable. Built as a simplification of [2] it wouldn't be too complicated.
> >>
> >> On the actual proposal of RLIMIT_GPUPRIO...
> >>
> >> The name would be problematic since we have generic hw accelerators (not 
> >> just GPUs) under the DRM subsystem. Perhaps RLIMIT_DRMPRIO would be better 
> >> but I think you will need to copy some more mailing lists and people on 
> >> that one. Because I can imagine one or two more fundamental questions this 
> >> opens up, as you have eluded in your cover letter as well.
> >
> > So I don't want to get into the bikeshed, I think Tvrtko summarized
> > pretty well that this is 

Re: [RFC PATCH 0/4] uapi, drm: Add and implement RLIMIT_GPUPRIO

[Daniel Vetter]

;ll achieve is just yet another rfc that
goes nowhere. Or maybe something like the minimal fdinfo stuff
(minimal I guess to avoid wider discussion) which then blew up because
it wasn'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

Re: [pull] amdgpu, amdkfd, radeon drm-next-6.4

[Daniel Vetter]

;  drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 3 +-
>  drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c   | 2 +
>  drivers/gpu/drm/radeon/Makefile| 3 +-
>  drivers/gpu/drm/radeon/radeon.h| 2 +
>  drivers/gpu/drm/radeon/radeon_display.c| 4 -
>  drivers/gpu/drm/radeon/radeon_drv.c| 3 +-
>  drivers/gpu/drm/radeon/radeon_drv.h| 1 -
>  drivers/gpu/drm/radeon/radeon_fb.c |   400 -
>  drivers/gpu/drm/radeon/radeon_fbdev.c  |   422 +
>  drivers/gpu/drm/radeon/radeon_gem.c|24 +
>  drivers/gpu/drm/radeon/radeon_kms.c|18 -
>  drivers/gpu/drm/radeon/radeon_mode.h   |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

Re: [pull] amdgpu drm-fixes-6.3

[Daniel Vetter]

On Thu, Mar 30, 2023 at 11:38:59AM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> A regression fix for 6.3.
> 
> The following changes since commit 68dc1846c3a44d5e633be145c169ce2fd5420695:
> 
>   drm/amd/display: Take FEC Overhead into Timeslot Calculation (2023-03-29 
> 17:21:06 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.3-2023-03-30
> 
> for you to fetch changes up to 2fec9dc8e0acc3dfb56d1389151bcf405f087b10:
> 
>   drm/amdgpu: allow more APUs to do mode2 reset when go to S4 (2023-03-30 
> 11:23:58 -0400)
> 
> 
> amd-drm-fixes-6.3-2023-03-30:
> 
> amdgpu:
> - Hibernation regression fix

Yeah for a regression fix a 2nd pull makes sense, pulled, thanks.
> 
> 
> 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

Re: [pull] amdgpu drm-fixes-6.3

[Daniel Vetter]

On Wed, Mar 29, 2023 at 06:00:59PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Fixes for 6.3.
> 
> The following changes since commit 197b6b60ae7bc51dd0814953c562833143b292aa:
> 
>   Linux 6.3-rc4 (2023-03-26 14:40:20 -0700)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.3-2023-03-29
> 
> for you to fetch changes up to 68dc1846c3a44d5e633be145c169ce2fd5420695:
> 
>   drm/amd/display: Take FEC Overhead into Timeslot Calculation (2023-03-29 
> 17:21:06 -0400)

Pulled, thanks

> 
> 
> amd-drm-fixes-6.3-2023-03-29:
> 
> amdgpu:
> - Two DP MST fixes
> 
> 
> Fangzhi Zuo (2):
>   drm/amd/display: 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 changed, 58 insertions(+), 8 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] amdgpu drm-fixes-6.3

[Daniel Vetter]

On Thu, Mar 23, 2023 at 12:19:39PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Fixes for 6.3.
> 
> The following changes since commit e8d018dd0257f744ca50a729e3d042cf2ec9da65:
> 
>   Linux 6.3-rc3 (2023-03-19 13:27:55 -0700)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.3-2023-03-23
> 
> for you to fetch changes up to f9537b1fa7fb51c2162bc15ce469cbbf1ca0fbfe:
> 
>   drm/amd/display: Set dcn32 caps.seamless_odm (2023-03-23 09:39:34 -0400)

Pulled, thanks.
-Daniel

> 
> 
> amd-drm-fixes-6.3-2023-03-23:
> 
> amdgpu:
> - S4 fix
> - Soft reset fixes
> - SR-IOV fix
> - Remove an out of date comment in the DC code
> - ASPM fix
> - DCN 3.2 fixes
> 
> 
> Alex Hung (1):
>   drm/amd/display: remove outdated 8bpc comments
> 
> Hersen Wu (2):
>   drm/amd/display: fix wrong index used in dccg32_set_dpstreamclk
>   drm/amd/display: Set dcn32 caps.seamless_odm
> 
> Jane Jian (1):
>   drm/amdgpu/gfx: set cg flags to enter/exit safe mode
> 
> Kai-Heng Feng (1):
>   drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi
> 
> Tim Huang (2):
>   drm/amdgpu: reposition the gpu reset checking for reuse
>   drm/amdgpu: skip ASIC reset for APUs when go to S4
> 
> Tong Liu01 (1):
>   drm/amdgpu: add mes resume when do gfx post soft reset
> 
> YuBiao Wang (1):
>   drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobs
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  5 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   | 41 
> --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  5 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  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/drm/amd/display/dc/dcn32/dcn32_dccg.c  |  3 +-
>  .../gpu/drm/amd/display/dc/dcn32/dcn32_resource.c  |  1 +
>  11 files changed, 72 insertions(+), 41 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini()

[Daniel Vetter]

On Fri, Feb 17, 2023 at 09:18:54AM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 16.02.23 um 21:11 schrieb Daniel Vetter:
> > On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> > > Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> > > calling fbdev implementation. Avoids a possible stale mutex with
> > > generic fbdev code.
> > > 
> > > As indicated by its name, drm_fb_helper_prepare() prepares struct
> > > drm_fb_helper before setting up the fbdev support with a call to
> > > drm_fb_helper_init(). In legacy fbdev emulation, this happens next
> > > to each other. If successful, drm_fb_helper_fini() later tear down
> > > the fbdev device and also unprepare via drm_fb_helper_unprepare().
> > > 
> > > Generic fbdev emulation prepares struct drm_fb_helper immediately
> > > after allocating the instance. It only calls drm_fb_helper_init()
> > > as part of processing a hotplug event. If the hotplug-handling fails,
> > > it runs drm_fb_helper_fini(). This unprepares the fb-helper instance
> > > and the next hotplug event runs on stale data.
> > > 
> > > Solve this by moving drm_fb_helper_unprepare() from drm_fb_helper_fini()
> > > into the fbdev implementations. Call it right before freeing the
> > > fb-helper instance.
> > > 
> > > Fixes: 4825797c36da ("drm/fb-helper: Introduce drm_fb_helper_unprepare()")
> > > Cc: Thomas Zimmermann 
> > > Cc: Javier Martinez Canillas 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: dri-de...@lists.freedesktop.org
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > 
> > This reminds me of an old patch I just recently stumbled over again:
> > 
> > https://lore.kernel.org/dri-devel/Y3St2VHJ7jEmcNFw@phenom.ffwll.local/
> > 
> > Should I resurrect that one maybe and send it out? I think that also ties
> > a bit into your story here.
> 
> I don't think it will be necessary. I began to convert the existing fbdev
> emulation to make use of drm_client, which should resove a number of
> problems. I expect to post this after the various trees have merged the
> recent changes to fbdev helpers.

The only version the patch is fixing is the client one, the old one is
unfixable (I think at least, hence just the comments). Note that the link
is pre-splitting, I do have a rebased version here.

I'll just send that out and head into vacations :-)
-Daniel

> 
> Best regards
> Thomas
> 
> > 
> > > ---
> > >   drivers/gpu/drm/armada/armada_fbdev.c  | 3 +++
> > >   drivers/gpu/drm/drm_fb_helper.c| 2 --
> > >   drivers/gpu/drm/drm_fbdev_generic.c| 2 ++
> > >   drivers/gpu/drm/exynos/exynos_drm_fbdev.c  | 3 ++-
> > >   drivers/gpu/drm/gma500/framebuffer.c   | 2 ++
> > >   drivers/gpu/drm/i915/display/intel_fbdev.c | 1 +
> > >   drivers/gpu/drm/msm/msm_fbdev.c| 2 ++
> > >   drivers/gpu/drm/omapdrm/omap_fbdev.c   | 2 ++
> > >   drivers/gpu/drm/radeon/radeon_fb.c | 2 ++
> > >   drivers/gpu/drm/tegra/fb.c | 1 +
> > >   10 files changed, 17 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> > > b/drivers/gpu/drm/armada/armada_fbdev.c
> > > index 07e410c62b7a..0e44f53e9fa4 100644
> > > --- a/drivers/gpu/drm/armada/armada_fbdev.c
> > > +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> > > @@ -147,6 +147,7 @@ int armada_fbdev_init(struct drm_device *dev)
> > >err_fb_setup:
> > >   drm_fb_helper_fini(fbh);
> > >err_fb_helper:
> > > + drm_fb_helper_unprepare(fbh);
> > >   priv->fbdev = NULL;
> > >   return ret;
> > >   }
> > > @@ -164,6 +165,8 @@ void armada_fbdev_fini(struct drm_device *dev)
> > >   if (fbh->fb)
> > >   fbh->fb->funcs->destroy(fbh->fb);
> > > + drm_fb_helper_unprepare(fbh);
> > > +
> > >   priv->fbdev = NULL;
> > >   }
> > >   }
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 28c428e9c530..a39998047f8a 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -590,8 +590,6 @@ void drm_fb_helper_fini(struct drm_fb_helper 
> > > *fb

Re: [PATCH] drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini()

[Daniel Vetter]

On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> calling fbdev implementation. Avoids a possible stale mutex with
> generic fbdev code.
> 
> As indicated by its name, drm_fb_helper_prepare() prepares struct
> drm_fb_helper before setting up the fbdev support with a call to
> drm_fb_helper_init(). In legacy fbdev emulation, this happens next
> to each other. If successful, drm_fb_helper_fini() later tear down
> the fbdev device and also unprepare via drm_fb_helper_unprepare().
> 
> Generic fbdev emulation prepares struct drm_fb_helper immediately
> after allocating the instance. It only calls drm_fb_helper_init()
> as part of processing a hotplug event. If the hotplug-handling fails,
> it runs drm_fb_helper_fini(). This unprepares the fb-helper instance
> and the next hotplug event runs on stale data.
> 
> Solve this by moving drm_fb_helper_unprepare() from drm_fb_helper_fini()
> into the fbdev implementations. Call it right before freeing the
> fb-helper instance.
> 
> Fixes: 4825797c36da ("drm/fb-helper: Introduce drm_fb_helper_unprepare()")
> Cc: Thomas Zimmermann 
> Cc: Javier Martinez Canillas 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org
> 
> Signed-off-by: Thomas Zimmermann 

This reminds me of an old patch I just recently stumbled over again:

https://lore.kernel.org/dri-devel/Y3St2VHJ7jEmcNFw@phenom.ffwll.local/

Should I resurrect that one maybe and send it out? I think that also ties
a bit into your story here.

> ---
>  drivers/gpu/drm/armada/armada_fbdev.c  | 3 +++
>  drivers/gpu/drm/drm_fb_helper.c| 2 --
>  drivers/gpu/drm/drm_fbdev_generic.c| 2 ++
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c  | 3 ++-
>  drivers/gpu/drm/gma500/framebuffer.c   | 2 ++
>  drivers/gpu/drm/i915/display/intel_fbdev.c | 1 +
>  drivers/gpu/drm/msm/msm_fbdev.c| 2 ++
>  drivers/gpu/drm/omapdrm/omap_fbdev.c   | 2 ++
>  drivers/gpu/drm/radeon/radeon_fb.c | 2 ++
>  drivers/gpu/drm/tegra/fb.c | 1 +
>  10 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 07e410c62b7a..0e44f53e9fa4 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -147,6 +147,7 @@ int armada_fbdev_init(struct drm_device *dev)
>   err_fb_setup:
>   drm_fb_helper_fini(fbh);
>   err_fb_helper:
> + drm_fb_helper_unprepare(fbh);
>   priv->fbdev = NULL;
>   return ret;
>  }
> @@ -164,6 +165,8 @@ void armada_fbdev_fini(struct drm_device *dev)
>   if (fbh->fb)
>   fbh->fb->funcs->destroy(fbh->fb);
>  
> + drm_fb_helper_unprepare(fbh);
> +
>   priv->fbdev = NULL;
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 28c428e9c530..a39998047f8a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -590,8 +590,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)

I think it would be good to update the kerneldoc of _init() and _fini()
here to mention each another like we usually do with these pairs. Same
with prepare/unprepare() although the latter rerfences _prepare() already.

>   }
>   mutex_unlock(&kernel_fb_helper_lock);
>  
> - drm_fb_helper_unprepare(fb_helper);
> -
>   if (!fb_helper->client.funcs)
>   drm_client_release(&fb_helper->client);
>  }
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 365f80717fa1..4d6325e91565 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -65,6 +65,8 @@ static void drm_fbdev_fb_destroy(struct fb_info *info)
>  
>   drm_client_framebuffer_delete(fb_helper->buffer);
>   drm_client_release(&fb_helper->client);
> +
> + drm_fb_helper_unprepare(fb_helper);
>   kfree(fb_helper);
>  }
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index b89e33af8da8..4929ffe5a09a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -183,8 +183,8 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
>  
>  err_setup:
>   drm_fb_helper_fini(helper);
> -
>  err_init:
> + drm_fb_helper_unprepare(helper);
>   private->fb_helper = NULL;
>   kfree(fbdev);
>

Re: [PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import

[Daniel Vetter]

On Tue, Jan 17, 2023 at 04:06:05AM +0300, Dmitry Osipenko wrote:
> 16.01.2023 18:11, Christian König пишет:
> > 
> >>>>>
> >>>>>> mmapping the memory with that new offset should still work. The
> >>>>>> imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
> >>>>>> supports mapping of SG BOs.
> >>>>>
> >>>>> Actually it shouldn't. This can go boom really easily.
> >>>>
> >>>> OK. I don't think we're doing this, but after Xiaogang raised the
> >>>> question I went looking through the code whether it's theoretically
> >>>> possible. I didn't find anything in the code that says that mmapping
> >>>> imported dmabufs would be prohibited or even dangerous. On the
> >>>> contrary, I found that ttm_bo_vm explicitly supports mmapping SG BOs.
> >>>>
> >>>>
> >>>>>
> >>>>> When you have imported a BO the only correct way of to mmap() it is
> >>>>> to do so on the original exporter.
> >>>>
> >>>> That seems sensible, and this is what we do today. That said, if
> >>>> mmapping an imported BO is dangerous, I'm missing a mechanism to
> >>>> protect against this. It could be as simple as setting
> >>>> AMDGPU_GEM_CREATE_NO_CPU_ACCESS in amdgpu_dma_buf_create_obj.
> >>>
> >>> At least for the GEM mmap() handler this is double checked very early
> >>> by looking at obj->import_attach and then either rejecting it or
> >>> redirecting the request to the DMA-buf file instead.
> >>
> >> Can you point me at where this check is? I see a check for
> >> obj->import_attach in drm_gem_dumb_map_offset. But I can't see how
> >> this function is called in amdgpu. I don't think it is used at all.
> > 
> > Uff, good question! @Thomas and @Dmitry: I clearly remember that one of
> > you guys was involved in the DRM/GEM mmap cleanup and DMA-buf with
> > workarounds for the KFD and DMA-buf.
> > 
> > What was the final solution to this? I can't find it of hand any more.
> 
> I was looking at it. The AMDGPU indeed allows to map imported GEMs, but
> then touching the mapped area by CPU results in a bus fault. You,
> Christian, suggested that this an AMDGPU bug that should be fixed by
> prohibiting the mapping in the first place and I was going to fix it,
> but then the plan changed from prohibiting the mapping into fixing it.
> 
> The first proposal was to make DRM core to handle the dma-buf mappings
> for all drivers universally [1]. Then we decided that will be better to
> prohibit mapping of imported GEMs [2]. In the end, Rob Clark argued that
> better to implement the [1], otherwise current userspace (Android) will
> be broken if mapping will be prohibited.
> 
> The last question was about the cache syncing of imported dma-bufs, how
> to ensure that drivers will do the cache maintenance/syncing properly.
> Rob suggested 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

Re: [PATCH 5.10 1/1] drm/amdkfd: Check for null pointer after calling kmemdup

[Daniel Vetter]

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:
> > > > From: Jiasheng Jiang 
> > > >
> > > > [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
> > > >
> > > > As the possible failure of the allocation, kmemdup() may return NULL
> > > > pointer.
> > > > Therefore, it should be better to check the 'props2' in order to prevent
> > > > the dereference of NULL pointer.
> > > >
> > > > Fixes: 3a87177eb141 ("drm/amdkfd: Add topology support for dGPUs")
> > > > Signed-off-by: Jiasheng Jiang 
> > > > Reviewed-by: Felix Kuehling 
> > > > Signed-off-by: Felix Kuehling 
> > > > Signed-off-by: Alex Deucher 
> > > > Signed-off-by: Dragos-Marian Panait 
> > > > ---
> > > >  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> > > > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > > index 86b4dadf772e..02e3c650ed1c 100644
> > > > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > > > @@ -408,6 +408,9 @@ static int kfd_parse_subtype_iolink(struct 
> > > > crat_subtype_iolink *iolink,
> > > >   return -ENODEV;
> > > >   /* same everything but the other direction */
> > > >   props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
> > > > + if (!props2)
> > > > + return -ENOMEM;
> > >
> > > Not going to queue this up as this is a bogus CVE.
> > 
> > Are we at the point where CVE presence actually contraindicates
> > backporting?
> 
> Some would say that that point passed a long time ago :)
> 
> > At least I'm getting a bit the feeling there's a surge of
> > automated (security) fixes that just don't hold up to any scrutiny.
> 
> That has been happening a lot more in the past 6-8 months than in years
> past with the introduction of more automated tools being present.

Ok, gut feeling confirmed, I'll try and keep more a lookout for these.

I guess next step is that people will use chatgpt to write the patches for
these bugs.

> > Last week I had to toss out an fbdev locking patch due to static
> > checker that has no clue at all how refcounting works, and so
> > complained that things need more locking ... (that was -fixes, but
> > would probably have gone to stable too if I didn't catch it).
> > 
> > Simple 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?
> 
> Again, yes, I have seen that a lot recently, especially with regards to
> patches that purport to fix bugs yet obviously were never tested.
> 
> That being said, there are a few developers who are doing great things
> with fault-injection testing and providing good patches for that.  So we
> can't just say that everyone using these tools has no clue.

Oh yes there's definitely awesome stuff happening, which is why I do not
want to throw them all out. And waiting until the name is recognizeable
for individual maintainers like me that don't see the entire fixes flood
is also not really an approach.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression

[Daniel Vetter]

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 regression on rc-*
> > >
> > > Regression is due to a chicken-egg problem loading modules; on
> > > `modprobe i915`, drm is loaded 1st, and drm.debug is set.  When
> > > drm_debug_enabled() tested __drm_debug at runtime, that just worked.
> > >
> > > But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
> > > post-load enablement of drm_dbg/dyndbg callsites (static-keys), via
> > > dyndbg's callback on __drm_debug.  Since all drm-drivers need drm.ko,
> > > it is loaded 1st, then drm.debug=X is applied, then drivers load, but
> > > too late for drm_dbgs to be enabled.
> > >
> > > STATUS
> > >
> > > For all-loadable drm,i915,amdgpu configs, it almost works, but
> > > propagating drm.debug to dependent modules doesnt actually apply,
> > > though the motions are there.  This is not the problem I want to chase
> > > here.
> > >
> > > The more basic trouble is:
> > >
> > > For builtin drm + helpers, things are broken pretty early; at the
> > > beginning of dynamic_debug_init().  As the ddebug_sanity() commit-msg
> > > describes in some detail, the records added by _USE fail to reference
> > > the struct ddebug_class_map created and exported by _DEFINE, but get
> > > separate addresses to "other" data that segv's when used as the
> > > expected pointer. FWIW, the pointer val starts with "revi".
> >
> > So I honestly have no idea here, linker stuff is way beyond where I have
> > clue. So what's the way forward here?
> >
> 
> Ive fixed this aspect.
> Unsurprisingly, it wasnt the linker :-}

Awesome!

> > The DEFINE/USE split does like the right thing to do at least from the
> > "how it's used in drivers" pov. But if we're just running circles not
> > quite getting there I dunno :-/
> > -Daniel
> >
> 
> Sending new rev next.
> I think its getting close.

Thanks a lot for keeping on pushing this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Daniel Vetter]

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 months, and
> the huge revert at this point is going to set us back with what's been
> developed on top of it for i915 DP MST and DSC.

tbf I assumed this wont land when I've seen it fly by. It feels a bit much
like living under a rock for half a year and then creating a mess for
everyone else who's been building on top of this is not great.

Like yes it's a regression, but apparently not a blantantly obvious one,
and I think if we just ram this in there's considerable community goodwill
down the drain. Someone needs to get that goodwill up the drain again.

> It's a regression, I get that, but this is also going to be really nasty
> to deal with. It's a 2500-line commit, plus the dependencies, which I
> don't think are accounted for here. (What's the baseline for the revert
> anyway?) I don't expect all the dependent commits to be easy to revert
> or backport to v6.1 or v6.2.
> 
> *sad trombone*

Yeah that's the other thing. 2500 patch revert is not cc stable material.
So this isn't even really helping users all that much.

Unless it also comes with full amounts of backports of the reverts on all
affected drivers for all curent stable trees, fully validated.

This is bad. I do think we need to have some understanding first of what
"fix this in amdgpu" would look like as plan B. Because plan A does not
look like a happy one at all.
-Daniel

> BR,
> Jani.
> 
> 
> On Thu, 12 Jan 2023, Wayne Lin  wrote:
> > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> >
> > [Why]
> > Changes cause regression on amdgpu mst.
> > E.g.
> > In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove 
> > payload
> > one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
> > maintained payload table. But previous change tries to go through all the
> > payloads in mst_state and update amdpug hw maintained table in once 
> > everytime
> > driver only tries to add/remove a specific payload stream only. The newly
> > design idea conflicts with the implementation in amdgpu nowadays.
> >
> > [How]
> > Revert this patch first. After addressing all regression problems caused by
> > this previous patch, will add it back and adjust it.
> >
> > Signed-off-by: Wayne Lin 
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
> > Cc: sta...@vger.kernel.org # 6.1
> > Cc: Lyude Paul 
> > Cc: Harry Wentland 
> > Cc: Mario Limonciello 
> > Cc: Ville Syrjälä 
> > Cc: Ben Skeggs 
> > Cc: Stanislav Lisovskiy 
> > Cc: Fangzhi Zuo 
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  53 +-
> >  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  87 ++-
> >  .../amd/display/include/link_service_types.h  |   3 -
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  67 +-
> >  drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 167 ++--
> >  include/drm/display/drm_dp_mst_helper.h   | 177 +++--
> >  9 files changed, 878 insertions(+), 530 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 77277d90b6e2..674f5dc1102b 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct 
> > drm_encoder *encoder,
> > const struct drm_display_mode *adjusted_mode = 
> > &crtc_state->adjusted_mode;
> > struct drm_dp_mst_topology_mgr *mst_mgr;
> > struct drm_dp_mst_port *mst_port;
> > -   struct drm_dp_mst_topology_state *mst_state;
> > enum dc_color_depth color_depth;
> > int clock, bpp = 0;
> > bool is_y420 = false;
> > @@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct 
> > drm_encoder *encoder,
> > if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> > return 0;
> >  
> > -   mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
> > -   if (IS_ERR(mst_state))
> > -   return PTR_ERR(mst_state);
> > -
> > -   if (!mst_state->pbn_div)
> > -   mst_state->pbn_div = 
> > dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
> > -
> > if (!state->duplicated) {
> > int max_bpc = conn_state->max_requested_bpc;
> > is_y420 = drm_mode_is_420_also(&connector->display_info, 
> > adjusted_mode) &&
> > @@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct 
> > drm_encoder *encoder,
> > clock = adjusted_mode->clock;
> > dm_new_connect

Re: [PATCH 5.10 1/1] drm/amdkfd: Check for null pointer after calling kmemdup

[Daniel Vetter]

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:
> > From: Jiasheng Jiang 
> >
> > [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
> >
> > As the possible failure of the allocation, kmemdup() may return NULL
> > pointer.
> > Therefore, it should be better to check the 'props2' in order to prevent
> > the dereference of NULL pointer.
> >
> > Fixes: 3a87177eb141 ("drm/amdkfd: Add topology support for dGPUs")
> > Signed-off-by: Jiasheng Jiang 
> > Reviewed-by: Felix Kuehling 
> > Signed-off-by: Felix Kuehling 
> > Signed-off-by: Alex Deucher 
> > Signed-off-by: Dragos-Marian Panait 
> > ---
> >  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > index 86b4dadf772e..02e3c650ed1c 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > @@ -408,6 +408,9 @@ static int kfd_parse_subtype_iolink(struct 
> > crat_subtype_iolink *iolink,
> >   return -ENODEV;
> >   /* same everything but the other direction */
> >   props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
> > + if (!props2)
> > + return -ENOMEM;
>
> Not going to queue this up as this is a bogus CVE.

Are we at the point where CVE presence actually contraindicates
backporting? At least I'm getting a bit the feeling there's a surge of
automated (security) fixes that just don't hold up to any scrutiny.
Last week I had to toss out an fbdev locking patch due to static
checker that has no clue at all how refcounting works, and so
complained that things need more locking ... (that was -fixes, but
would probably have gone to stable too if I didn't catch it).

Simple 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

Re: [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression

[Daniel Vetter]

On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> Hi everyone,
> 
> DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> 
> Regression is due to a chicken-egg problem loading modules; on
> `modprobe i915`, drm is loaded 1st, and drm.debug is set.  When
> drm_debug_enabled() tested __drm_debug at runtime, that just worked.
> 
> But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
> post-load enablement of drm_dbg/dyndbg callsites (static-keys), via
> dyndbg's callback on __drm_debug.  Since all drm-drivers need drm.ko,
> it is loaded 1st, then drm.debug=X is applied, then drivers load, but
> too late for drm_dbgs to be enabled.
> 
> STATUS
> 
> For all-loadable drm,i915,amdgpu configs, it almost works, but
> propagating drm.debug to dependent modules doesnt actually apply,
> though the motions are there.  This is not the problem I want to chase
> here.
> 
> The more basic trouble is:
> 
> For builtin drm + helpers, things are broken pretty early; at the
> beginning of dynamic_debug_init().  As the ddebug_sanity() commit-msg
> describes in some detail, the records added by _USE fail to reference
> the struct ddebug_class_map created and exported by _DEFINE, but get
> separate addresses to "other" data that segv's when used as the
> expected pointer. FWIW, the pointer val starts with "revi".

So I honestly have no idea here, linker stuff is way beyond where I have
clue. So what's the way forward here?

The DEFINE/USE split does like the right thing to do at least from the
"how it's used in drivers" pov. But if we're just running circles not
quite getting there I dunno :-/
-Daniel

> 
> OVERVIEW
> 
> DECLARE_DYNDBG_CLASSMAP is broken: it is one-size-fits-all-poorly.
> It muddles the distinction between a (single) definition, and multiple
> references.  Something exported should suffice.
> 
> The core of this patchset splits it into:
> 
> DYNDBG_CLASSMAP_DEFINEused once per subsystem to define each classmap
> DYNDBG_CLASSMAP_USE   declare dependence on a DEFINEd classmap
> 
> This makes the weird coordinated-changes-by-identical-classmaps
> "feature" unnecessary; the DEFINE can export the var, and USE refers
> to the exported var.
> 
> So this patchset adds another section: __dyndbg_class_refs.
> 
> It is like __dyndbg_classes; it is scanned under ddebug_add_module(),
> and attached to each module's ddebug_table.  Once attached, it can be
> used like classes to validate and apply class FOO >control queries.
> 
> It also maps the class user -> definer explicitly, so that when the
> module is loaded, the section scan can find the kernel-param that is
> wired to dyndbg's kparam-callback, and apply its state-var, forex:
> __drm_debug to the just loaded helper/driver module.
> 
> Theres plenty to address Im sure.
> 
> Jim Cromie (17):
>   test-dyndbg: fixup CLASSMAP usage error
>   test-dyndbg: show that DEBUG enables prdbgs at compiletime
>   dyndbg: fix readback value on LEVEL_NAMES interfaces
>   dyndbg: replace classmap list with a vector
>   dyndbg: make ddebug_apply_class_bitmap more selective
>   dyndbg: dynamic_debug_init - use pointer inequality, not strcmp
>   dyndbg: drop NUM_TYPE_ARRAY
>   dyndbg: reduce verbose/debug clutter
>   dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with
> DYNDBG_CLASSMAP(_DEFINE|_USE)
>   dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)
>   dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args
>   dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements
>   drm_print: fix stale macro-name in comment
>   dyndbg: unwrap __ddebug_add_module inner function NOTYET
>   dyndbg: ddebug_sanity()
>   dyndbg: mess-w-dep-class
>   dyndbg: miss-on HACK
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  14 +-
>  drivers/gpu/drm/display/drm_dp_helper.c |  14 +-
>  drivers/gpu/drm/drm_crtc_helper.c   |  14 +-
>  drivers/gpu/drm/drm_print.c |  22 +--
>  drivers/gpu/drm/i915/i915_params.c  |  14 +-
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  14 +-
>  include/asm-generic/vmlinux.lds.h   |   3 +
>  include/drm/drm_print.h |   6 +-
>  include/linux/dynamic_debug.h   |  57 --
>  include/linux/map.h     |  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

Re: [RFC PATCH 13/17] drm_print: fix stale macro-name in comment

[Daniel Vetter]

On Mon, Dec 05, 2022 at 05:34:20PM -0700, Jim Cromie wrote:
> Cited commit uses stale macro name, fix this, and explain better.
> 
> When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
> onto BITs in drm.debug.  This still uses enum drm_debug_category, but
> it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
> This requires that the macro args: DRM_UT_* list must be kept in sync
> and in order.
> 
> Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
> drivers.")
> Signed-off-by: Jim Cromie 

Should I land this already?
-Daniel

> ---
> . emphasize ABI non-change despite enum val change - Jani Nikula
> . reorder to back of patchset to follow API name changes.
> ---
>  include/drm/drm_print.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 6a27e8f26770..7695ba31b3a4 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
> char *prefix)
>   *
>   */
>  enum drm_debug_category {
> - /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
> + /*
> +  * Keep DYNDBG_CLASSMAP_DEFINE 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

Re: [PATCH] drm/fb-helper: Set framebuffer for vga-switcheroo clients

[Daniel Vetter]

On Wed, Jan 11, 2023 at 04:38:13PM +0100, Thomas Zimmermann wrote:
> Set the framebuffer info for drivers that support VGA switcheroo. Only
> affects the amdgpu driver, which uses VGA switcheroo and generic fbdev
> emulation. For other drivers, this does nothing.
> 
> Amdgpu's lastclose helper called vga_switcheroo_process_delayed_switch().
> But as amdgpu uses generic fbdev emulation, it's better to call the helper
> from drm_lastclose(), after the kernel client's screen has been restored.
> So all drivers and clients can benefit. Radeon and nouveau with modernized
> fbdev code are possible candidates.
> 
> There was an earlier patchset to do something similar. [1]
> 
> Suggested-by: Alexander Deucher 
> Signed-off-by: Thomas Zimmermann 
> Link: 
> https://lore.kernel.org/amd-gfx/20221020143603.563929-1-alexander.deuc...@amd.com/
>  # 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 |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 12 
>  drivers/gpu/drm/drm_fb_helper.c |  8 
>  drivers/gpu/drm/drm_file.c  |  3 +++
>  5 files changed, 11 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 63c921c55fb9..7120b9b6e580 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1330,7 +1330,6 @@ extern const int amdgpu_max_kms_ioctl;
>  
>  int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
>  void amdgpu_driver_unload_kms(struct drm_device *dev);
> -void amdgpu_driver_lastclose_kms(struct drm_device *dev);
>  int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file 
> *file_priv);
>  void amdgpu_driver_postclose_kms(struct drm_device *dev,
>struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index ebc6e6cbe2ab..02d636f781a2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2784,7 +2784,6 @@ static const struct drm_driver amdgpu_kms_driver = {
>   DRIVER_SYNCOBJ_TIMELINE,
>   .open = amdgpu_driver_open_kms,
>   .postclose = amdgpu_driver_postclose_kms,
> - .lastclose = amdgpu_driver_lastclose_kms,
>   .ioctls = amdgpu_ioctls_kms,
>   .num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
>   .dumb_create = amdgpu_mode_dumb_create,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 7aa7e52ca784..886739576d3d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1104,18 +1104,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
>  /*
>   * Outdated mess for old drm with Xorg being in charge (void function now).
>   */
> -/**
> - * amdgpu_driver_lastclose_kms - drm callback for last close
> - *
> - * @dev: drm dev pointer
> - *
> - * Switch vga_switcheroo state after last close (all asics).
> - */
> -void amdgpu_driver_lastclose_kms(struct drm_device *dev)
> -{
> - drm_fb_helper_lastclose(dev);
> - vga_switcheroo_process_delayed_switch();
> -}
>  
>  /**
>   * amdgpu_driver_open_kms - drm callback for open
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 427631706128..5e445c61252d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -30,7 +30,9 @@
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
>  #include 
> +#include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1940,6 +1942,7 @@ static int drm_fb_helper_single_fb_probe(struct 
> drm_fb_helper *fb_helper,
>int preferred_bpp)
>  {
>   struct drm_client_dev *client = &fb_helper->client;
> + struct drm_device *dev = fb_helper->dev;
>   struct drm_fb_helper_surface_size sizes;
>   int ret;
>  
> @@ -1961,6 +1964,11 @@ static int drm_fb_helper_single_fb_probe(struct 
> drm_fb_helper *fb_helper,
>   return ret;
>  
>   strcpy(fb_helper->fb->comm, "[fbcon]");
> +
> + /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */
> + if (dev_is_pci(dev->dev))
> + 

Re: [PATCH] drm/radeon: free iio for atombios when driver shutdown

[Daniel Vetter]

Just a quick drive-by. For these simple cases where we just need to make
sure that memory is freed using drmm_kmalloc and friends should help
simplify things. Probably not worth it for radeon, but figured I'll throw
it out there.

For more functional code switching to drmm is harder because you need the
right order. But for these all that matters is that stuff gets freed so
there's no leak, and drmm can take care of that without ordering
constraints.
-Daniel

On Fri, Jan 06, 2023 at 10:36:53AM -0500, Alex Deucher wrote:
> Applied.  Thanks!
> 
> Alex
> 
> On Fri, Jan 6, 2023 at 5:00 AM Liwei Song  wrote:
> >
> > Fix below kmemleak when unload radeon driver:
> >
> > unreferenced object 0x9f8608ede200 (size 512):
> >   comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s)
> >   hex dump (first 32 bytes):
> > 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00  
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> >   backtrace:
> > [<62fadebe>] kmem_cache_alloc_trace+0x2f1/0x500
> > [<b6883cea>] atom_parse+0x117/0x230 [radeon]
> > [<158c23fd>] radeon_atombios_init+0xab/0x170 [radeon]
> > [<683f672e>] si_init+0x57/0x750 [radeon]
> > [<566cc31f>] radeon_device_init+0x559/0x9c0 [radeon]
> > [<46efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon]
> > [<b5155064>] drm_dev_register+0xdd/0x1d0
> > [<45fec835>] radeon_pci_probe+0xbd/0x100 [radeon]
> > [<e69ecca3>] pci_device_probe+0xe1/0x160
> > [<19484b76>] really_probe.part.0+0xc1/0x2c0
> > [<3f2649da>] __driver_probe_device+0x96/0x130
> > [<231c5bb1>] driver_probe_device+0x24/0xf0
> > [<00a42377>] __driver_attach+0x77/0x190
> > [<d7574da6>] bus_for_each_dev+0x7f/0xd0
> > [<633166d2>] driver_attach+0x1e/0x30
> > [<313b05b8>] bus_add_driver+0x12c/0x1e0
> >
> > iio was allocated in atom_index_iio() called by atom_parse(),
> > but it doesn't got released when the dirver is shutdown.
> > Fix this kmemleak by free it in radeon_atombios_fini().
> >
> > Signed-off-by: Liwei Song 
> > ---
> >  drivers/gpu/drm/radeon/radeon_device.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> > 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)
> >  {
> > if (rdev->mode_info.atom_context) {
> > kfree(rdev->mode_info.atom_context->scratch);
> > +   kfree(rdev->mode_info.atom_context->iio);
> > }
> > kfree(rdev->mode_info.atom_context);
> > rdev->mode_info.atom_context = NULL;
> > --
> > 2.33.1
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] drm_print: fix stale macro-name in comment

[Daniel Vetter]

On Mon, Dec 05, 2022 at 09:10:05AM -0700, Jim Cromie wrote:
> Cited commit uses stale macro name, fix this, and explain better.
> 
> When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
> onto BITs in drm.debug.  This still uses enum drm_debug_category, but
> it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
> This requires that the macro args: DRM_UT_* list must be kept in sync
> and in order.
> 
> Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
> drivers.")
> Signed-off-by: Jim Cromie 

What's the status of this series?

Greg, you landed the original entire pile that wasn't quite ready yet? Or
should I apply these two?
-Daniel

> ---
> . emphasize ABI non-change despite enum val change - Jani Nikula
> . reorder to back of patchset to follow API name changes.
> ---
>  include/drm/drm_print.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a44fb7ef257f..e4c0c7e6d49d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
> char *prefix)
>   *
>   */
>  enum drm_debug_category {
> - /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
> + /*
> +  * Keep DYNDBG_CLASSMAP_DEFINE 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

Re: [PATCH v3 0/2] drm: Add GPU reset sysfs

[Daniel Vetter]

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.
> > >
> > > Userspace apps can trigger GPU resets by misuse of graphical APIs or 
> > > driver
> > > bugs. Either way, the GPU reset might lead the system to a broken 
> > > state[1], that
> > > might be recovered if user has access to a tty or a remote shell. 
> > > Arguably, this
> > > recovery could happen automatically by the system itself, thus this is 
> > > the goal
> > > of this patchset.
> > >
> > > For debugging and report purposes, device coredump support was already 
> > > added
> > > for amdgpu[2], but it's not suitable for programmatic usage like this one 
> > > given
> > > the uAPI not being stable and the need for parsing.
> > >
> > > GL/VK is out of scope for this use, giving that we are dealing with device
> > > resets regardless of API.
> > >
> > > A basic userspace daemon is provided at [3] showing how the interface is 
> > > used
> > > to recovery from resets.
> > >
> > > [1] A search for "reset" in DRM/AMD issue tracker shows reports of resets
> > > making the system unusable:
> > > https://gitlab.freedesktop.org/drm/amd/-/issues/?search=reset
> > >
> > > [2] 
> > > https://lore.kernel.org/amd-gfx/20220602081538.1652842-2-amaranath.somalapu...@amd.com/
> > >
> > > [3] https://gitlab.freedesktop.org/andrealmeid/gpu-resetd
> > >
> > > v2: 
> > > https://lore.kernel.org/dri-devel/20220308180403.75566-1-contactshashanksha...@gmail.com/
> > >
> > > André Almeida (1):
> > >   drm/amdgpu: Add work function for GPU reset event
> > >
> > > Shashank Sharma (1):
> > >   drm: Add GPU reset sysfs event
> >
> > This seems a bit much amd specific, and a bit much like an ad-hoc stopgap.
> >
> > On the amd specific piece:
> >
> > - amd's gpus suck the most for gpu hangs, because aside from the shader
> >   unblock, there's only device reset, which thrashes vram and display and
> >   absolutely everything. Which is terrible. Everyone else has engine only
> >   reset since years (i.e. doesn't thrash display or vram), and very often
> >   even just context reset (i.e. unless the driver is busted somehow or hw
> >   bug, malicious userspace will _only_ ever impact itself).
> >
> > - robustness extensions for gl/vk already have very clear specifications
> >   of all cases of reset, and this work here just ignores that. Yes on amd
> >   you only have device reset, but this is drm infra, so you need to be
> >   able to cope with ctx reset or reset which only affected a limited set
> >   of context. If this is for compute and compute apis lack robustness
> >   extensions, then those apis need to be fixed to fill that gap.
> >
> > - the entire deamon thing feels a bit like overkill and I'm not sure why
> >   it exists. I think for a start it would be much simpler if we just have
> >   a (per-device maybe) sysfs knob to enable automatic killing of process
> >   that die and which don't have arb robustness enabled (for gl case, for
> >   vk case the assumption is that _every_ app supports VK_DEVICE_LOST and
> >   can recover).
>
> Thinking about this a bit more, I think there are useful cases for the
> GPU reset event and a daemon.  When I refer to a daemon here, it could
> be a standalone thing or integrated into the desktop manager like
> logind or whatever.
> 1. For APIs that don't have robustness support (e.g., video
> encode/decode APIs).  This one I could kind of go either way on since,
> it probably makes sense to just kill the app if it there is no
> robustness mechanism in the API.

I think transcode might also be a case where the userspace driver can
recover, at least on the decode side. But that would most likely
require some extension to make it clear to the app what's going on.

Or people just use vk video and be done, reset support comes built-in there :-)

> 2. Telemetry collection.  It would be useful to have a central place
> to collect telemetry information about what apps seem to be
> problematic, etc.

Yeah I think standardizing reset messages and maybe device state dumps
makes sense. But that's telemetry, not making decisions about what to
kill.

> 3. A policy manager in userspace.  If you want to make some decision
&g

Re: [pull] amdgpu, amdkfd drm-fixes-6.2

[Daniel Vetter]

On Wed, Jan 04, 2023 at 10:38:39PM -0500, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Fixes for 6.2.
> 
> The following changes since commit c8de526215fdab9f2dd0d9675582cf9f1391a919:
> 
>   Merge tag 'drm-misc-next-fixes-2023-01-03' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-01-03 
> 21:02:57 +0100)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.2-2023-01-04
> 
> for you to fetch changes up to 6fe6ece398f7431784847e922a2c8c385dc58a35:
> 
>   Revert "drm/amd/display: Enable Freesync Video Mode by default" (2023-01-04 
> 22:29:32 -0500)

Pulled, thanks a lot.
-Daniel
> 
> 
> amd-drm-fixes-6.2-2023-01-04:
> 
> amdgpu:
> - DCN 3.2 fix
> - Display fix
> 
> amdkfd:
> - Fix kernel warning
> 
> 
> Michel Dänzer (1):
>   Revert "drm/amd/display: Enable Freesync Video Mode by default"
> 
> Mukul Joshi (1):
>   drm/amdkfd: Fix kernel warning during topology setup
> 
> Samson Tam (1):
>   drm/amd/display: Uninitialized variables causing 4k60 UCLK to stay at 
> DPM1 and not DPM0
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 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

Re: [Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait

[Daniel Vetter]

On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
 wrote:
> On 29/11/2022 18:05, Matthew Auld wrote:
> > On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> + Matt
> >>
> >> On 25/11/2022 10:21, Christian König wrote:
> >>> TTM is just wrapping core DMA functionality here, remove the mid-layer.
> >>> No functional change.
> >>>
> >>> Signed-off-by: Christian König 
> >>> ---
> >>>drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
> >>>1 file changed, 6 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> index 5247d88b3c13..d409a77449a3 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> @@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object 
> >>> *obj,
> >>>static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
> >>>{
> >>>struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> >>> - int err;
> >>> + long err;
> >>>
> >>>WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
> >>>
> >>> - err = ttm_bo_wait(bo, true, false);
> >>> - if (err)
> >>> + err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
> >>> + true, 15 * HZ);
> >>
> >> This 15 second stuck out a bit for me and then on a slightly deeper look
> >> it seems this timeout will "leak" into a few of i915 code paths. If we
> >> look at the difference between the legacy shmem and ttm backend I am not
> >> sure if the legacy one is blocking or not - but if it can block I don't
> >> think it would have an arbitrary timeout like this. Matt your thoughts?
> >
> > Not sure what is meant by leak here, but the legacy shmem must also
> > wait/block when unbinding each VMA, before calling truncate. It's the
>
> By "leak" I meant if 15s timeout propagates into some code paths visible
> from userspace which with a legacy backend instead have an indefinite
> wait. If we have that it's probably not very good to have this
> inconsistency, or to apply an arbitrary timeout to those path to start with.
>
> > same 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
> > against. If the wait times out it should just fail gracefully. I guess
> > we could just use MAX_SCHEDULE_TIMEOUT here? Not sure if it really
> > matters though.
>
> Right, depends if it can leak or not to userspace and diverge between
> backends.

Generally lock_timeout() is a design bug. It's either
lock_interruptible (or maybe lock_killable) or try_lock, but
lock_timeout is just duct-tape. I haven't dug in to figure out what
should be here, but it smells fishy.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 0/2] drm: Add GPU reset sysfs

[Daniel Vetter]

gpu
  reset options you can think of, with resulting different reporting
  requirements to make sure robustness extensions work correctly.

- pid isn't enough once you have engine/context reset, you need pid (well
  drm_file really, but I guess we can bind those to pid somehow) and gpu
  ctx id. Both gl and vk allow you to allocate limitless gpu context on
  the same device, and so this matters.

- igt for this stuff. Probably needs some work to generalize 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 +++
>  include/drm/drm_sysfs.h| 13 ++
>  4 files changed, 73 insertions(+)
> 
> -- 
> 2.38.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v7 18/21] dma-buf: Move dma_buf_mmap() to dynamic locking specification

[Daniel Vetter]

On Mon, 17 Oct 2022 at 19:25, Dmitry Osipenko
 wrote:
>
> Move dma_buf_mmap() function to the dynamic locking specification by
> taking the reservation lock. Neither of the today's drivers take the
> reservation lock within the mmap() callback, hence it's safe to enforce
> the locking.
>
> Acked-by: Sumit Semwal 
> Acked-by: Christian König 
> Signed-off-by: Dmitry Osipenko 

Just noticed this while reading code ... this patch seems to have
missed dma_buf_mmap_internal()?

Might be good if at least some drivers gain a dma_resv_assert_held in
that path to make sure we're not quite this bad, together with fixing
this issue.
-Daniel

> ---
>  drivers/dma-buf/dma-buf.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f54c649f922a..f149b384f4dd 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1390,6 +1390,8 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
>  int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
>  unsigned long pgoff)
>  {
> +   int ret;
> +
> if (WARN_ON(!dmabuf || !vma))
> return -EINVAL;
>
> @@ -1410,7 +1412,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
> vm_area_struct *vma,
> vma_set_file(vma, dmabuf->file);
> vma->vm_pgoff = pgoff;
>
> -   return dmabuf->ops->mmap(dmabuf, vma);
> +   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

Re: [pull] amdgpu drm-fixes-6.0

[Daniel Vetter]

On Fri, Sep 30, 2022 at 05:04:54PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Sorry, some last minute changes to deal with updated firmwares/bioses and
> board revisions containing new IPs added in this cycle.  It required
> pulling in some cleanup patches for the RLC firmware handing, but they
> are only applied to GC 11 in this case.  I figured that would be cleaner
> then a bunch of local fixes that would cause merge conflicts for -next,
> and time was getting short for 6.0. They are only applied to GC 11, so no
> chance of regression on existing asics.
> 
> V2: fixed S-O-Bs.
> 
> The following changes since commit 83ca5fb40e758e0a0257bf4e3a1148dd52c6d0f2:
> 
>   drm/amd/display: Prevent OTG shutdown during PSR SU (2022-09-29 10:07:42 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.0-2022-09-30-1

Pullled and forwarded.

Cheers, Daniel

> 
> for you to fetch changes up to 0fd85e89b5bf18447e56099a010ee5be5dc9f2b0:
> 
>   drm/amdgpu/gfx11: switch to amdgpu_gfx_rlc_init_microcode (2022-09-30 
> 16:59:06 -0400)
> 
> 
> amd-drm-fixes-6.0-2022-09-30-1:
> 
> amdgpu:
> - VCN 4.x fixes
> - RLC fixes for GC 11.x
> 
> 
> Hawking Zhang (8):
>   drm/amdgpu: save rlcv/rlcp ucode version in amdgpu_gfx
>   drm/amdgpu: add helper to init rlc fw in header v2_0
>   drm/amdgpu: add helper to init rlc fw in header v2_1
>   drm/amdgpu: add helper to init rlc fw in header v2_2
>   drm/amdgpu: add helper to init rlc fw in header v2_3
>   drm/amdgpu: add helper to init rlc fw in header v2_4
>   drm/amdgpu: add helper to init rlc firmware
>   drm/amdgpu/gfx11: switch to amdgpu_gfx_rlc_init_microcode
> 
> Sonny Jiang (2):
>   drm/amdgpu: Enable VCN DPG for GC11_0_1
>   drm/amdgpu: Enable sram on vcn_4_0_2
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h   |   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/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

Re: [pull] amdgpu drm-fixes-6.0

[Daniel Vetter]

On Fri, Sep 30, 2022 at 09:58:10AM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Sorry, some last minute changes to deal with updated firmwares/bioses and
> board revisions containing new IPs added in this cycle.  It required
> pulling in some cleanup patches for the RLC firmware handing, but they
> are only applied to GC 11 in this case.  I figured that would be cleaner
> then a bunch of local fixes that would cause merge conflicts for -next,
> and time was getting short for 6.0. They are only applied to GC 11, so no
> chance of regression on existing asics.
> 
> The following changes since commit 83ca5fb40e758e0a0257bf4e3a1148dd52c6d0f2:
> 
>   drm/amd/display: Prevent OTG shutdown during PSR SU (2022-09-29 10:07:42 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-fixes-6.0-2022-09-30
> 
> for you to fetch changes up to 5369e662f99087b4ad38b151aaefecb690117f10:
> 
>   drm/amdgpu/gfx11: switch to amdgpu_gfx_rlc_init_microcode (2022-09-29 
> 15:22:31 -0400)
> 
> 
> amd-drm-fixes-6.0-2022-09-30:

dim isn't entirely happy:

dim: 5369e662f990 ("drm/amdgpu/gfx11: switch to 
amdgpu_gfx_rlc_init_microcode"): committer Signed-off-by missing.
dim: dd00f3eeba5b ("drm/amdgpu: save rlcv/rlcp ucode version in amdgpu_gfx"): 
committer Signed-off-by missing.

Can you pls respin?
-Daniel

> 
> amdgpu:
> - VCN 4.x fixes
> - RLC fixes for GC 11.x
> 
> 
> Hawking Zhang (8):
>   drm/amdgpu: save rlcv/rlcp ucode version in amdgpu_gfx
>   drm/amdgpu: add helper to init rlc fw in header v2_0
>   drm/amdgpu: add helper to init rlc fw in header v2_1
>   drm/amdgpu: add helper to init rlc fw in header v2_2
>   drm/amdgpu: add helper to init rlc fw in header v2_3
>   drm/amdgpu: add helper to init rlc fw in header v2_4
>   drm/amdgpu: add helper to init rlc firmware
>   drm/amdgpu/gfx11: switch to amdgpu_gfx_rlc_init_microcode
> 
> Sonny Jiang (2):
>   drm/amdgpu: Enable VCN DPG for GC11_0_1
>   drm/amdgpu: Enable sram on vcn_4_0_2
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h   |   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/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

Re: [PATCH v6 1/6] drm/ttm: Add new callbacks to ttm res mgr

[Daniel Vetter]

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:
> > > > Am 12.08.22 um 15:30 schrieb Arunpravin Paneer Selvam:
> > > > > We are adding two new callbacks to ttm resource manager
> > > > > function to handle intersection and compatibility of
> > > > > placement and resources.
> > > > > 
> > > > > v2: move the amdgpu and ttm_range_manager changes to
> > > > >   separate patches (Christian)
> > > > > v3: rename "intersect" to "intersects" (Matthew)
> > > > > v4: move !place check to the !res if and return false
> > > > >   in ttm_resource_compatible() function (Christian)
> > > > > v5: move bits of code from patch number 6 to avoid
> > > > >   temporary driver breakup (Christian)
> > > > > 
> > > > > Signed-off-by: Christian König 
> > > > > Signed-off-by: Arunpravin Paneer Selvam
> > > > > 
> > > > Patch #6 could still be cleaned up more now that we have the workaround
> > > > code in patch #1, but that not really a must have.
> > > > 
> > > > Reviewed-by: Christian König  for the entire
> > > > series.
> > > > 
> > > > Do you already have commit rights?
> > > Hi Christian,
> > > I applied for drm-misc commit rights, waiting for the project maintainers 
> > > to
> > > approve my request.
> > Why do all drivers have to implement the current behaviour? Can we have a
> > default implementation, which gets called if nothing is set instead?
> 
> We do have a default implementation in the range manager which is used by
> radeon, GEM VRAM helpers, VMWGFX and amdgpu (but there only for some
> domains).
> 
> > I'm a bit confused why the bloat here ...
> 
> Drivers do have specialized implementations of the backend, e.g. VMWGFX have
> his handle backend, amdgpu the VRAM backend with special placements, i915 is
> completely special as well.
> 
> Here we only move the decision if resources intersect or are compatible into
> those specialized backends. Previously we had all this in a centralized
> callback for all backends of a driver.
> 
> See the switch in amdgpu_ttm_bo_eviction_valuable() for an example. Final
> goal is to move all this stuff into the specialized backends and remove this
> callback.
> 
> The only driver where I couldn't figure out why we have duplicated all this
> from the standard implementation is Nouveau.

Yeah I didn't read this too carefully, apologies.

> > Also please document new callbacks precisely with inline kerneldoc. I know
> > ttm docs aren't great yet, but they don't get better if we don't start
> > somewhere. I think the in-depth comments for modeset vfuncs (e.g. in
> > drm_modeset_helper_vtables.h) are a good standard here.
> 
> I thought we already did that. Please be a bit more specific.

Yeah rushed this too, but the kerneldoc isn't too great yet. It's
definitely not formatted correctly (you can't do a full function
definition in a struct unfortunately, see the examples I linked). And it
would be good to specificy what the default implementation is, that there
is one (i.e. the hook is optional) and when exactly a driver would want to
overwrite this. Atm it's a one-liner that explains exactly as much as you
can guess from the function interface anyway, that's not super userful.
-Daniel



> 
> Thanks,
> Christian.
> 
> > -Daniel
> > 
> > > Thanks,
> > > Arun
> > > > Regards,
> > > > Christian.
> > > > 
> > > > > ---
> > > > >    drivers/gpu/drm/ttm/ttm_bo.c   |  9 ++--
> > > > >    drivers/gpu/drm/ttm/ttm_resource.c | 77 
> > > > > +-
> > > > >    include/drm/ttm/ttm_resource.h | 40 
> > > > >    3 files changed, 119 insertions(+), 7 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> > > > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > index c1bd006a5525..f066e8124c50 100644
> > > > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > @@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object
> > > > >

Re: [PATCH v6 39/57] dyndbg/drm: POC add tracebits sysfs-knob

[Daniel Vetter]

On Sun, Sep 04, 2022 at 03:41:16PM -0600, Jim Cromie wrote:
> clone DRM.debug interface to DRM.tracebits: ie map bits to
> drm-debug-categories, except this interface enables messages to
> tracefs, not to syslog.
> 
> 1- we reuse the class-map added previously.
>this reflects the single source of both syslog/trace events
> 
> 2- add a 2nd struct ddebug_classes_bitmap_param
>refs 1, reusing it.
>flags = "T", to enable trace-events on this callsite.
> 
> 3- module_param_cb([2]) - does the sysfs part
> 
> Signed-off-by: Jim Cromie 

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/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index c50edbf443d3..75d0cecd7e86 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -45,6 +45,9 @@
>  unsigned long __drm_debug;
>  EXPORT_SYMBOL(__drm_debug);
>  
> +unsigned long __drm_trace;
> +EXPORT_SYMBOL(__drm_trace);
> +
>  MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug 
> category.\n"
>  "\t\tBit 0 (0x01)  will enable CORE messages (drm core code)\n"
>  "\t\tBit 1 (0x02)  will enable DRIVER messages (drm controller code)\n"
> @@ -77,6 +80,13 @@ static struct ddebug_class_param drm_debug_bitmap = {
>   .map = &drm_debug_classes,
>  };
>  module_param_cb(debug, ¶m_ops_dyndbg_classes, &drm_debug_bitmap, 0600);
> +
> +static struct ddebug_class_param drm_trace_bitmap = {
> + .bits = &__drm_trace,
> + .flags = "T",
> + .map = &drm_debug_classes,
> +};
> +module_param_cb(tracecats, ¶m_ops_dyndbg_classes, &drm_trace_bitmap, 
> 0600);
>  #endif
>  
>  void __drm_puts_coredump(struct drm_printer *p, const char *str)
> -- 
> 2.37.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v6 28/57] drm_print: refine drm_debug_enabled for jump-label

[Daniel Vetter]

On Sun, Sep 04, 2022 at 03:41:05PM -0600, Jim Cromie wrote:
> In order to use dynamic-debug's jump-label optimization in drm-debug,
> its clarifying to refine drm_debug_enabled into 3 uses:
> 
> 1.   drm_debug_enabled - legacy, public
> 2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
> 3.  _drm_debug_enabled - pr_debug instrumented, observable
> 
> 1. The legacy version always checks the bits.
> 
> 2. is privileged, for use by __drm_dbg(), __drm_dev_dbg(), which do an
> early return unless the category is enabled.  For dyndbg builds, debug
> callsites are selectively "pre-enabled", so __drm_debug_enabled()
> short-circuits to true there.  Remaining callers of 1 may be able to
> use 2, case by case.
> 
> 3. is 1st wrapped in a macro, with a pr_debug, which reports each
> usage in /proc/dynamic_debug/control, making it observable in the
> logs.  The macro lets the pr_debug see the real caller, not an inline
> function.
> 
> When plugged into 1, 3 identified ~10 remaining callers of the
> function, leading to the follow-on cleanup patch, and would allow
> activating the pr_debugs, estimating the callrate, and the potential
> savings by using the wrapper macro.  It is unused ATM, but it fills
> out the picture.
> 
> Signed-off-by: Jim Cromie 

So instead of having 3 here as a "you need to hack it in to see what
should be converted" I have a bit a different idea: Could we make the
public version also a dyndbg callsite (like the printing wrappers), but
instead of a dynamic call we'd have a dynamically fixed value we get out?
I think that would take care of everything you have here as an open.

Otherwise I'd just drop 3 for the series we're going to merge.
-Daniel

> ---
>  drivers/gpu/drm/drm_print.c |  4 ++--
>  include/drm/drm_print.h | 28 
>  2 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 29a29949ad0b..cb203d63b286 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -285,7 +285,7 @@ void __drm_dev_dbg(const struct device *dev, enum 
> drm_debug_category category,
>   struct va_format vaf;
>   va_list args;
>  
> - if (!drm_debug_enabled(category))
> + if (!__drm_debug_enabled(category))
>   return;
>  
>   va_start(args, format);
> @@ -308,7 +308,7 @@ void ___drm_dbg(enum drm_debug_category category, const 
> char *format, ...)
>   struct va_format vaf;
>   va_list args;
>  
> - if (!drm_debug_enabled(category))
> + if (!__drm_debug_enabled(category))
>   return;
>  
>   va_start(args, format);
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index dfdd81c3287c..7631b5fb669e 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -321,11 +321,39 @@ enum drm_debug_category {
>   DRM_UT_DRMRES
>  };
>  
> +/*
> + * 3 name flavors of drm_debug_enabled:
> + *   drm_debug_enabled - public/legacy, always checks bits
> + *  _drm_debug_enabled - instrumented to observe call-rates, est overheads.
> + * __drm_debug_enabled - privileged - knows jump-label state, can 
> short-circuit
> + */
>  static inline bool drm_debug_enabled(enum drm_debug_category category)
>  {
>   return unlikely(__drm_debug & BIT(category));
>  }
>  
> +/*
> + * Wrap fn in macro, so that the pr_debug sees the actual caller, not
> + * the inline fn.  Using this name creates a callsite entry / control
> + * point in /proc/dynamic_debug/control.
> + */
> +#define _drm_debug_enabled(category) \
> + ({  \
> + pr_debug("todo: maybe avoid via dyndbg\n"); \
> + drm_debug_enabled(category);\
> + })
> +
> +#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
> +/*
> + * dyndbg 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