Re: 回复: 回复: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to swapout and swapin

[Pan, Xinhui]

I just sent out patch below yesterday.  swapping unpopulated bo is useless 
indeed.

[RFC PATCH 2/2] drm/ttm: skip swapout when ttm has no backend page.

回复: 回复: 回复: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to swapout and swapin

[Pan, Xinhui]

[AMD Official Use Only]

I just sent out patch below yesterday.  swapping unpopulated bo is useless 
indeed.

[RFC PATCH 2/2] drm/ttm: skip swapout when ttm has no backend page.


发件人: Christian König 
发送时间: 2021年5月20日 14:39
收件人: Pan, Xinhui; Kuehling, Felix; amd-...@lists.freedesktop.org
抄送: Deucher, Alexander; dan...@ffwll.ch; Koenig, Christian; 
dri-devel@lists.freedesktop.org
主题: Re: 回复: 回复: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to 
swapout and swapin

> swapout function create one swap storage which is filled with zero. And set 
> ttm->page_flags as TTM_PAGE_FLAG_SWAPPED.  Just because ttm has no backend 
> page this time, no real data is swapout to this swap storage.

That's the fundamental problem. A TT object which isn't populated
shouldn't be considered for swapout nor eviction in the first place.

I'm going to take a look later today.

Christian.

Am 20.05.21 um 04:55 schrieb Pan, Xinhui:
> [AMD Official Use Only]
>
> swapout function create one swap storage which is filled with zero. And set 
> ttm->page_flags as TTM_PAGE_FLAG_SWAPPED.  Just because ttm has no backend 
> page this time, no real data is swapout to this swap storage.
>
> swapin function is called during populate as TTM_PAGE_FLAG_SWAPPED is set.
> Now here is the problem, we swapin data to ttm bakend memory from swap 
> storage. That just causes the memory been overwritten.
>
> 
> 发件人: Christian König 
> 发送时间: 2021年5月19日 18:01
> 收件人: Pan, Xinhui; Kuehling, Felix; amd-...@lists.freedesktop.org
> 抄送: Deucher, Alexander; dan...@ffwll.ch; Koenig, Christian; 
> dri-devel@lists.freedesktop.org
> 主题: Re: 回复: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to swapout 
> and swapin
>
> I'm scratching my head how that is even possible.
>
> See when a BO is created in the system domain it is just an empty hull,
> e.g. without backing store and allocated pages.
>
> So the swapout function will just ignore it.
>
> Christian.
>
> Am 19.05.21 um 07:07 schrieb Pan, Xinhui:
>> [AMD Official Use Only]
>>
>> I have reverted Chris'  patch, still hit this failure.
>> Just see two lines in Chris' patch. Any BO in cpu domian would be swapout 
>> first. That is why we hit this issue frequently now. But the bug is there 
>> long time ago.
>>
>> -   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>> -   list_for_each_entry(bo, &glob->swap_lru[i], swap) {
>> [snip]
>> +   for (i = TTM_PL_SYSTEM; i < TTM_NUM_MEM_TYPES; ++i) {
>> +   for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
>>
>>
>> 
>> 发件人: Pan, Xinhui 
>> 发送时间: 2021年5月19日 12:09
>> 收件人: Kuehling, Felix; amd-...@lists.freedesktop.org
>> 抄送: Deucher, Alexander; Koenig, Christian; dri-devel@lists.freedesktop.org; 
>> dan...@ffwll.ch
>> 主题: 回复: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to swapout and 
>> swapin
>>
>> yes, we really dont swapout SG BOs.
>> The problems is that before we validate a userptr BO, we create this BO in 
>> CPU domain by default. So this BO has chance to swapout.
>>
>> we set flag TTM_PAGE_FLAG_SG on userptr BO in popluate() which is too late.
>> I have not try to revert Chris' patch as I think it desnt help. Or I can 
>> have a try later.
>>
>> 
>> 发件人: Kuehling, Felix 
>> 发送时间: 2021年5月19日 11:29
>> 收件人: Pan, Xinhui; amd-...@lists.freedesktop.org
>> 抄送: Deucher, Alexander; Koenig, Christian; dri-devel@lists.freedesktop.org; 
>> dan...@ffwll.ch
>> 主题: Re: [RFC PATCH 1/2] drm/amdgpu: Fix memory corruption due to swapout and 
>> swapin
>>
>> Swapping SG BOs makes no sense, because TTM doesn't own the pages of
>> this type of BO.
>>
>> Last I checked, userptr BOs (and other SG BOs) were protected from
>> swapout by the fact that they would not be added to the swap-LRU. But it
>> looks like Christian just removed the swap-LRU. I guess this broke that
>> protection:
>>
>> commit 2cb51d22d70b18eaf339abf9758bf0b7608da65c
>> Author: Christian König 
>> Date:   Tue Oct 6 16:30:09 2020 +0200
>>
>>drm/ttm: remove swap LRU v3
>>
>>Instead evict round robin from each devices SYSTEM and TT domain.
>>
>>v2: reorder num_pages access reported by Dan's script
>>v3: fix rebase fallout, num_pages should be 32bit
>>
>>Signed-off-by: Christian König 
>>Tested-by: Nirmoy Das 
>>Reviewed-by: Huang Rui 
>>Reviewed-by: Matthew Auld 
>>Link: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F424009%2F&data=04%7C01%7CXinhui.Pan%40amd.com%7C2f5f749422eb44efa95408d91b5a029c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637570895679516712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I9K%2FsTdCESLlS9P5rLOGUqEGCcxi0Jc7aaEOltyBP4M%3D&reserved=0
>>
>> Regards,
>>  Felix
>>
>>
>> On 2021-05-18 10:28 p.m., xinhui pan w

[PATCH] drm/i915: Use DRIVER_NAME for tracing unattached requests

[Matthew Auld]

From: Chris Wilson 

The first tracepoint for a request is trace_dma_fence_init called before
we have associated the request with a device. The tracepoint uses
fence->ops->get_driver_name() as a pretty name, and as we try to report
the device name this oopses as it is then NULL. Support the early
tracepoint by reporting the DRIVER_NAME instead of the actual device
name.

Note that rq->engine remains during the course of request recycling
(SLAB_TYPESAFE_BY_RCU). For the physical engines, the pointer remains
valid, however a virtual engine may be destroyed after the request is
retired. If we process a preempt-to-busy completed request along the
virtual engine, we should make sure we mark the request as no longer
belonging to the virtual engine to remove the dangling pointers from the
tracepoint.

Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Chintan M Patel 
Cc: Andi Shyti 
Cc:  # v5.7+
Signed-off-by: Matthew Auld 
---
 .../drm/i915/gt/intel_execlists_submission.c  | 20 ++-
 drivers/gpu/drm/i915/i915_request.c   |  7 ++-
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index de124870af44..75604e927d34 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3249,6 +3249,18 @@ static struct list_head *virtual_queue(struct 
virtual_engine *ve)
return &ve->base.execlists.default_priolist.requests;
 }
 
+static void
+virtual_submit_completed(struct virtual_engine *ve, struct i915_request *rq)
+{
+   GEM_BUG_ON(!__i915_request_is_complete(rq));
+   GEM_BUG_ON(rq->engine != &ve->base);
+
+   __i915_request_submit(rq);
+
+   /* Remove the dangling pointer to the stale virtual engine */
+   WRITE_ONCE(rq->engine, ve->siblings[0]);
+}
+
 static void rcu_virtual_context_destroy(struct work_struct *wrk)
 {
struct virtual_engine *ve =
@@ -3265,8 +3277,7 @@ static void rcu_virtual_context_destroy(struct 
work_struct *wrk)
 
old = fetch_and_zero(&ve->request);
if (old) {
-   GEM_BUG_ON(!__i915_request_is_complete(old));
-   __i915_request_submit(old);
+   virtual_submit_completed(ve, old);
i915_request_put(old);
}
 
@@ -3538,13 +3549,12 @@ static void virtual_submit_request(struct i915_request 
*rq)
 
/* By the time we resubmit a request, it may be completed */
if (__i915_request_is_complete(rq)) {
-   __i915_request_submit(rq);
+   virtual_submit_completed(ve, rq);
goto unlock;
}
 
if (ve->request) { /* background completion from preempt-to-busy */
-   GEM_BUG_ON(!__i915_request_is_complete(ve->request));
-   __i915_request_submit(ve->request);
+   virtual_submit_completed(ve, ve->request);
i915_request_put(ve->request);
}
 
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 970d8f4986bb..aa124adb1051 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -61,7 +61,12 @@ static struct i915_global_request {
 
 static const char *i915_fence_get_driver_name(struct dma_fence *fence)
 {
-   return dev_name(to_request(fence)->engine->i915->drm.dev);
+   struct i915_request *rq = to_request(fence);
+
+   if (unlikely(!rq->engine)) /* not yet attached to any device */
+   return DRIVER_NAME;
+
+   return dev_name(rq->engine->i915->drm.dev);
 }
 
 static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
-- 
2.26.3

RE: [PATCH v5 1/3] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Dexuan Cui]

> From: Deepak Rawat 
> Sent: Wednesday, May 19, 2021 9:38 AM
> ...
> +static int hyperv_vmbus_suspend(struct hv_device *hdev)
> +{
> + struct drm_device *dev = hv_get_drvdata(hdev);
> + int ret;
> +
> + ret = drm_mode_config_helper_suspend(dev);

If 'ret' is not zero, return immediately?

> +
> + vmbus_close(hdev->channel);
> +
> + return ret;
> +}


> +MODULE_DESCRIPTION("DRM driver for hyperv synthetic video device");

s/hyperv/Hyper-V ?

[PATCH] drm/bridge: anx7625: Synchronously run runtime suspend.

[Pi-Hsun Shih]

Originally when using pm_runtime_put, there's a chance that the runtime
suspend hook will be run after the following anx7625_bridge_mode_set
call, resulting in the display_timing_valid field to be cleared, and the
following power on fail.

Change all pm_runtime_put to pm_runtime_put_sync, so all power off
operations are guaranteed to be done after the call returns.

Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use 
runtime PM framework")
Signed-off-by: Pi-Hsun Shih 
---
 drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 29493cc2d300..7519b7a0f29d 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1255,7 +1255,7 @@ static struct edid *anx7625_get_edid(struct anx7625_data 
*ctx)
 
pm_runtime_get_sync(dev);
edid_num = sp_tx_edid_read(ctx, p_edid->edid_raw_data);
-   pm_runtime_put(dev);
+   pm_runtime_put_sync(dev);
 
if (edid_num < 1) {
DRM_DEV_ERROR(dev, "Fail to read EDID: %d\n", edid_num);
@@ -1573,7 +1573,7 @@ static void anx7625_bridge_disable(struct drm_bridge 
*bridge)
 
anx7625_dp_stop(ctx);
 
-   pm_runtime_put(dev);
+   pm_runtime_put_sync(dev);
 }
 
 static enum drm_connector_status

base-commit: 7a42b92b6d30c3f09629c7d5ada9e3de2aba01af
-- 
2.31.1.751.gd2f1c929bd-goog

Re: Re: [PATCH] drivers/video/fbdev/core/fbmem.c: add pointer judgment

[Arnd Bergmann]

>  > On Wed, May 19, 2021 at 08:00:28PM +0800, songqiang wrote:
> > Signed-off-by: songqiang 
> From: "Matthew Wilcox "
> > You need to explain:
> >
> > - Why you think this patch is needed
> > - Did you observe a problem at runtime?
> > - Is this the output from some checking tool?
> > - Why this is the right way to address the problem
>
On Thu, May 20, 2021 at 7:58 AM 宋强  wrote:
>
> I find null pointer bug when I debug the kernel of loongson，I think the 
> function fb_set_suspend()
> add pointer judgment will more friendly.

When replying to emails on the list, please remember

- avoid top-posting, see https://git-send-email.io/top-posting.html
- use plain text email, html replies get dropped by many mailing lists.

The information from your reply should be part of the patch description when
you send a patch, see
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html


> [  102.011018] Call Trace:
>
> [  102.013443] [] fb_set_suspend+0x50/0x80
> [  102.018819] [] loongson_drm_suspend+0x1a0/0x340 
> [loongson]
> [  102.025827] [] loongson_pmops_freeze+0x18/0x40 [loongson]
> [  102.032748] [] pci_pm_freeze+0x94/0x240
> [  102.038114] [] dpm_run_callback.isra.5+0x20/0x140
> [  102.044341] [] __device_suspend+0x2c8/0x740

It looks like the check would actually belong into the loongson_drm driver.
The driver is not upstream yet, but I assume you have the source for it, so
try to fix the bug there and send the patch to the owners of that driver.

   Arnd

Re: [PATCH 2/2] drm/doc: document drm_mode_get_plane

[Pekka Paalanen]

On Wed, 19 May 2021 10:30:40 -0300
Leandro Ribeiro  wrote:

> On 5/6/21 6:10 AM, Pekka Paalanen wrote:
> > On Wed, 28 Apr 2021 18:36:51 -0300
> > Leandro Ribeiro  wrote:
> >   
> >> Add a small description and document struct fields of
> >> drm_mode_get_plane.
> >>
> >> Signed-off-by: Leandro Ribeiro   
> > 
> > Hi,
> > 
> > thanks a lot for revising these.
> >   
> >> ---
> >>  include/uapi/drm/drm_mode.h | 22 ++
> >>  1 file changed, 22 insertions(+)
> >>
> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >> index a5e76aa06ad5..8fa6495cd948 100644
> >> --- a/include/uapi/drm/drm_mode.h
> >> +++ b/include/uapi/drm/drm_mode.h
> >> @@ -312,16 +312,38 @@ struct drm_mode_set_plane {
> >>__u32 src_w;
> >>  };
> >>
> >> +/**
> >> + * struct drm_mode_get_plane - Get plane metadata.
> >> + *
> >> + * Userspace can perform a GETPLANE ioctl to retrieve information about a
> >> + * plane.
> >> + */
> >>  struct drm_mode_get_plane {
> >> +  /** @plane_id: Object ID of the plane. */  
> > 
> > This is an "in" field, right?
> > 
> > "in" meaning that userspace sets it to the ID of the plane it wants
> > information on.
> > 
> > "out" field is a field written by the kernel as a response.
> > 
> > I'm not sure if the kernel has a habit of documenting these, because we
> > use libdrm to abstract this so users do not need to care, but I think
> > it would be nice.
> >   
> 
> In a quick look, I couldn't find anything. But I can change the phrasing
> to the following:
> 
> "@plane_id: Object ID of the plane whose information should be
> retrieved. IN field, set by userspace."

I think "set by userspace" or "set by caller" would be enough.


> >>__u32 plane_id;
> >>
> >> +  /** @crtc_id: Object ID of the current CRTC. */
> >>__u32 crtc_id;
> >> +  /** @fb_id: Object ID of the current fb. */
> >>__u32 fb_id;
> >>
> >> +  /**
> >> +   * @possible_crtcs: Bitmask of CRTC's compatible with the plane. CRTC's
> >> +   * are created and they receive an index, which corresponds to their
> >> +   * position in the bitmask. CRTC with index 0 will be in bit 0, and so
> >> +   * on. To learn how to find out the index of a certain CRTC, please see
> >> +   * :ref:`crtc_index`.  
> > 
> > This could be shortened to something like bit N corresponds to CRTC
> > index N, and make "CRTC index N" a hyperlink.
> >   
> 
> Nice, I'll apply this change.
> 
> >> +   */
> >>__u32 possible_crtcs;
> >> +  /** @gamma_size: Number of entries of the legacy gamma lookup table. */
> >>__u32 gamma_size;
> >>
> >> +  /** @count_format_types: Number of formats. */
> >>__u32 count_format_types;
> >> +  /**
> >> +   * @format_type_ptr: Pointer to ``__u32`` array of formats that are
> >> +   * supported by the plane. These formats do not require modifiers.
> >> +   */
> >>__u64 format_type_ptr;  
> > 
> > The count/ptr fields have an interesting usage pattern, which I suppose
> > is common for all DRM ioctls. Makes me wonder if it should be documented.
> > 
> > AFAIU, count is in+out field: when set to 0, the kernel uses it to
> > return the count needed. Then userspace allocates space and calls the
> > ioctl again with the right count and ptr set to point to the allocated
> > array of count elements. This is so that kernel never allocates memory
> > on behalf of userspace for the return data, making things much simpler
> > at the cost of maybe needing to call the ioctl twice to first figure
> > out long the array should be.
> > 
> > This can be seen in libdrm code for drmModeGetPlane().
> >
> > There is certainly no point in explaining all that here, that is too
> > much. But if there was a way to annotate the count member as in+out,
> > that would be nice. And the ptr member as "in".
> >   
> 
> This is documented in the description of struct drm_mode_get_connector:
> 
> https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#c.drm_mode_get_connector
> 
> Would be enough to have something similar in struct drm_mode_get_plane?

That would be really nice!


Thanks,
pq


pgpEJpyutQo9v.pgp
Description: OpenPGP digital signature

Re: [RFC] Add DMA_RESV_USAGE flags

[Daniel Vetter]

On Wed, May 19, 2021 at 5:48 PM Michel Dänzer  wrote:
>
> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> > On Wed, May 19, 2021 at 5:52 AM Michel Dänzer  wrote:
> >>
> >> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
> >>> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter  wrote:
> 
>  On Tue, May 18, 2021 at 7:40 PM Christian König
>   wrote:
> >
> > Am 18.05.21 um 18:48 schrieb Daniel Vetter:
> >> On Tue, May 18, 2021 at 2:49 PM Christian König
> >>  wrote:
> >>
> >>> And as long as we are all inside amdgpu we also don't have any 
> >>> oversync,
> >>> the issue only happens when we share dma-bufs with i915 (radeon and
> >>> AFAIK nouveau does the right thing as well).
> >> Yeah because then you can't use the amdgpu dma_resv model anymore and
> >> have to use the one atomic helpers use. Which is also the one that
> >> e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
> >> so as soon as that lands and someone starts using it, something has to
> >> adapt _anytime_ you have a dma-buf hanging around. Not just when it's
> >> shared with another device.
> >
> > Yeah, and that is exactly the reason why I will NAK this uAPI change.
> >
> > This doesn't works for amdgpu at all for the reasons outlined above.
> 
>  Uh that's really not how uapi works. "my driver is right, everyone
>  else is wrong" is not how cross driver contracts are defined. If that
>  means a perf impact until you've fixed your rules, that's on you.
> 
>  Also you're a few years too late with nacking this, it's already uapi
>  in the form of the dma-buf poll() support.
> >>>
> >>> ^^  My fancy new ioctl doesn't expose anything that isn't already
> >>> there.  It just lets you take a snap-shot of a wait instead of doing
> >>> an active wait which might end up with more fences added depending on
> >>> interrupts and retries.  The dma-buf poll waits on all fences for
> >>> POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.
> >>
> >> Note that the dma-buf poll support could be useful to Wayland compositors 
> >> for the same purpose as Jason's new ioctl (only using client buffers which 
> >> have finished drawing for an output frame, to avoid missing a refresh 
> >> cycle due to client drawing), *if* it didn't work differently with amdgpu.
> >>
> >> Am I understanding correctly that Jason's new ioctl would also work 
> >> differently with amdgpu as things stand currently? If so, that would be a 
> >> real bummer and might hinder adoption of the ioctl by Wayland compositors.
> >
> > My new ioctl has identical semantics to poll().  It just lets you take
> > a snapshot in time to wait on later instead of waiting on whatever
> > happens to be set right now.  IMO, having identical semantics to
> > poll() isn't something we want to change.
>
> Agreed.
>
> I'd argue then that making amdgpu poll semantics match those of other drivers 
> is a pre-requisite for the new ioctl, otherwise it seems unlikely that the 
> ioctl will be widely adopted.

This seems backwards, because that means useful improvements in all
other drivers are stalled until amdgpu is fixed.

I think we need agreement on what the rules are, reasonable plan to
get there, and then that should be enough to unblock work in the wider
community. Holding the community at large hostage because one driver
is different is really not great.

I've just finished the subsystem review of everything, and thus far
only found some minor bugs without practical significance. I'll fix
those and then send out a series.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: New uAPI for color management proposal and feedback request

[Pekka Paalanen]

On Wed, 19 May 2021 16:49:35 +0300
Ville Syrjälä  wrote:

> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> > On Wed, 12 May 2021 16:04:16 +0300
> > Ville Syrjälä  wrote:
> >   
> > > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:  
> > > > Hello,
> > > > 
> > > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" 
> > > > drm properties I propose 4 new properties:
> > > > "preferred pixel encoding", "active color depth", "active color range", 
> > > > and "active pixel encoding"
> > > > 
> > > > 
> > > > Motivation:
> > > > 
> > > > Current monitors have a variety pixel encodings available: RGB, YCbCr 
> > > > 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0.
> > > > 
> > > > In addition they might be full or limited RGB range and the monitors 
> > > > accept different bit depths.
> > > > 
> > > > Currently the kernel driver for AMD and Intel GPUs automatically 
> > > > configure the color settings automatically with little
> > > > to no influence of the user. However there are several real world 
> > > > scenarios where the user might disagree with the
> > > > default chosen by the drivers and wants to set his or her own 
> > > > preference.
> > > > 
> > > > Some examples:
> > > > 
> > > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color 
> > > > information, some screens might look better on one
> > > > than the other because of bad internal conversion. The driver currently 
> > > > however has a fixed default that is chosen if
> > > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to 
> > > > change this currently is by editing and overloading
> > > > the edid reported by the monitor to the kernel.
> > > > 
> > > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some 
> > > > hardware might report that it supports the higher
> > > > port clock, but because of bad shielding on the PC, the cable, or the 
> > > > monitor the screen cuts out every few seconds when
> > > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work 
> > > > fine without changing hardware. The drivers
> > > > currently however always default to the "best available" option even if 
> > > > it might be broken.
> > > > 
> > > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit 
> > > > color by rapidly switching between 2 adjacent
> > > > colors. They advertise themselves to the kernel as 10-bit monitors but 
> > > > the user might not like the "fake" 10-bit effect
> > > > and prefer running at the native 8-bit per color.
> > > > 
> > > > 4. Some screens are falsely classified as full RGB range wile they 
> > > > actually use limited RGB range. This results in
> > > > washed out colors in dark and bright scenes. A user override can be 
> > > > helpful to manually fix this issue when it occurs.
> > > > 
> > > > There already exist several requests, discussion, and patches regarding 
> > > > the thematic:
> > > > 
> > > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476
> > > > 
> > > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548
> > > > 
> > > > - https://lkml.org/lkml/2021/5/7/695
> > > > 
> > > > - https://lkml.org/lkml/2021/5/11/416
> > > >   
> > 
> > ...
> >   
> > > > Adoption:
> > > > 
> > > > A KDE dev wants to implement the settings in the KDE settings GUI:
> > > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370
> > > > 
> > > > Tuxedo Computers (my employer) wants to implement the settings desktop 
> > > > environment agnostic in Tuxedo Control Center. I
> > > > will start work on this in parallel to implementing the new kernel 
> > > > code.
> > > 
> > > I suspect everyone would be happier to accept new uapi if we had
> > > multiple compositors signed up to implement it.  
> > 
> > I think having Weston support for these would be good, but for now it
> > won't be much of an UI: just weston.ini to set, and the log to see what
> > happened.
> > 
> > However, knowing what happened is going to be important for color
> > calibration auditing:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> > 
> > Yes, please, very much for read-only properties for the feedback part.
> > Properties that both userspace and kernel will write are hard to deal
> > with in general.
> > 
> > Btw. "max bpc" I can kind of guess that conversion from framebuffer
> > format to the wire bpc happens automatically and only as the final
> > step,  
> 
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.

I tend to forget that dithering is a thing. I guess it could be
temporal and/or spatial depending on hardware?

> > but "Broadcast RGB" is more complicated: is the output from the
> > abstract pixel pipeline sent as-is and "Broadcast RGB" is just another
> > inforframe bit to the monitor, or does "Broadcast RGB" setting actually
> > change what happens in the pixel pipeline *and* set infoframe bits?  
> 
> It does indeed compres

Re: [RFC] Add DMA_RESV_USAGE flags

[Daniel Vetter]

On Wed, May 19, 2021 at 1:24 PM Christian König
 wrote:
>
> Am 18.05.21 um 23:17 schrieb Daniel Vetter:
> > [SNIP]
> >> The problem in this case is not starting a new CS, but synchronizing to
> >> the existing ones.
> >>
> >> See a heavy TLB flush is made completely out of sync. E.g. it doesn't
> >> want to wait for any previous operation.
> >>
> >> In other words imagine the following example:
> >> 1. Both process A and B have a BO mapped.
> >> 2. Process A is heavily using the BO and doing all kind of rendering.
> >> 3. Process B is unmapping the BO.
> >>
> >> Now that process B unmaps the BO needs to trigger page table updates and
> >> a heavy TLB flush, but since this can take really long we want to do it
> >> asynchronously on the hardware.
> >>
> >> With the current approach you basically can't do that because you can't
> >> note that a fence should not participate in synchronization at all.
> >>
> >> E.g. we can't add a fence which doesn't wait for the exclusive one as
> >> shared.
> > Ok I think that's a real problem, and  guess it's also related to all
> > the ttm privatization tricks and all that. So essentially we'd need
> > the opposite of ttm_bo->moving, as in you can't ignore it, but
> > otherwise it completely ignores all the userspace implicit fence
> > stuff.
>
> It goes into that direction, but doesn't sounds like the full solution
> either.
>
> [SNIP]
> > Can we please stop with the "amdgpu is right, everyone else is wrong" 
> > approach?
>
> Well the approach I do here is not "amdgpu is right, everyone else is
> wrong". But rather we had DRM uAPI for i915, nouveau and radeon and
> unfortunately leaked that into DMA-buf without much thinking about it.
>
> I'm also not saying that the approach amdgpu is right. It's just what
> amdgpu needs in it's CS interface.
>
> What I'm saying is that DMA-buf is a device driver independent subsystem
> and we shouldn't make any assumption which come from just a handful of
> DRM driver on it's implicit sync implementation.
>
> > Like I'm pretty much going to type up the patch that does a full drm
> > subsytem audit of everything and whack amdgpu into compliance. Perf
> > hit be damned, you had a few years to fix this with better uapi. Or I
> > find out that there's a giant inconsistent mess, but at least we'd
> > gain some clarity about where exactly we are here and maybe what to do
> > next.
>
> Ok to let us move forward please take a look at the first patches of the
> set. It cleans up quite a bunch of the mess we have in there before even
> coming to adding flags to the shared slots.
>
> I think you will agree on that we should do is cleaning up the use cases
> further and separate implicit sync from resource management.

Just replying on this because I'm a bit busy with reviewing everything
we have in upstream right now.

I agree there's some useful stuff in there, but we have a fundamental
disagreement on how this works. That needs to be resolved first, and
as part of that we need to come up with a plan how to get everyone on
the same page.

Then next thing is a plan how to get the various issues you're raising
around dma_resv rules sorted out.

Once we have that, and only then, does it imo make sense to
review/merge cleanup patches. As long as we have fundamental
disagreements along the lines like we have here there's no point.

I should have a patch set maybe tomorrow or early next week with my
results of the drm subsystem review of how exactly dma_resv is used
currently. Thus far it's a few pages of code analysis, but not yet
complete. Also I found some smaller issues in a few places, so the
discussion is going to involve a few more people until we're settled
here :-/

Cheers, Daniel


> In other words we forbid touching the exclusive and shared fences
> directly and have separate APIs for resource management and implicit sync.
>
> This makes sense anyway, no matter what implicit synchronization
> framework we will install underneath.
>
> Regards,
> Christian.
>
> > -Daniel
> >
> >> Regards,
> >> Christian.
> >>
> >>> After that I think we can look at what exact oversync issue remains
> >>> and why and solve it, but until we have this this just feels like
> >>> another rehash of "amgpu insist its own dma_resv interpration is the
> >>> right one and everyone else should move one over".
> >>>
> >>> Or maybe I've just become real garbage at reading random driver code,
> >>> wouldn't be the first time :-)
> >>>
> >>> Cheers, Daniel
> >>>
>  Regards,
>  Christian.
> 
> > Cheers, Daniel
> >
> >> --Jason
> >>
> >>
>  That's also the reason the Valve guys came up with a solution where 
>  each
>  BO gets a flag for explicit sync, but that only works for exports and
>  not for imports.
> 
> > I915 and iirc msm has explicit flags for this, panfrost was 
> > designed to
> > support this correctly from the start (also with flags I think). 
> > That's at
>

Re: [RFC] Add DMA_RESV_USAGE flags

[Michel Dänzer]

On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
> On Wed, May 19, 2021 at 5:48 PM Michel Dänzer  wrote:
>>
>> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
>>> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer  wrote:

 On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter  wrote:
>>
>> On Tue, May 18, 2021 at 7:40 PM Christian König
>>  wrote:
>>>
>>> Am 18.05.21 um 18:48 schrieb Daniel Vetter:
 On Tue, May 18, 2021 at 2:49 PM Christian König
  wrote:

> And as long as we are all inside amdgpu we also don't have any 
> oversync,
> the issue only happens when we share dma-bufs with i915 (radeon and
> AFAIK nouveau does the right thing as well).
 Yeah because then you can't use the amdgpu dma_resv model anymore and
 have to use the one atomic helpers use. Which is also the one that
 e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
 so as soon as that lands and someone starts using it, something has to
 adapt _anytime_ you have a dma-buf hanging around. Not just when it's
 shared with another device.
>>>
>>> Yeah, and that is exactly the reason why I will NAK this uAPI change.
>>>
>>> This doesn't works for amdgpu at all for the reasons outlined above.
>>
>> Uh that's really not how uapi works. "my driver is right, everyone
>> else is wrong" is not how cross driver contracts are defined. If that
>> means a perf impact until you've fixed your rules, that's on you.
>>
>> Also you're a few years too late with nacking this, it's already uapi
>> in the form of the dma-buf poll() support.
>
> ^^  My fancy new ioctl doesn't expose anything that isn't already
> there.  It just lets you take a snap-shot of a wait instead of doing
> an active wait which might end up with more fences added depending on
> interrupts and retries.  The dma-buf poll waits on all fences for
> POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.

 Note that the dma-buf poll support could be useful to Wayland compositors 
 for the same purpose as Jason's new ioctl (only using client buffers which 
 have finished drawing for an output frame, to avoid missing a refresh 
 cycle due to client drawing), *if* it didn't work differently with amdgpu.

 Am I understanding correctly that Jason's new ioctl would also work 
 differently with amdgpu as things stand currently? If so, that would be a 
 real bummer and might hinder adoption of the ioctl by Wayland compositors.
>>>
>>> My new ioctl has identical semantics to poll().  It just lets you take
>>> a snapshot in time to wait on later instead of waiting on whatever
>>> happens to be set right now.  IMO, having identical semantics to
>>> poll() isn't something we want to change.
>>
>> Agreed.
>>
>> I'd argue then that making amdgpu poll semantics match those of other 
>> drivers is a pre-requisite for the new ioctl, otherwise it seems unlikely 
>> that the ioctl will be widely adopted.
> 
> This seems backwards, because that means useful improvements in all
> other drivers are stalled until amdgpu is fixed.
> 
> I think we need agreement on what the rules are, reasonable plan to
> get there, and then that should be enough to unblock work in the wider
> community. Holding the community at large hostage because one driver
> is different is really not great.

I think we're in violent agreement. :) The point I was trying to make is that 
amdgpu really needs to be fixed to be consistent with other drivers ASAP.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer

[PATCH][next] drm/amdgpu/acpi: Fix null check on memory allocation

[Colin King]

From: Colin Ian King 

The current null check is checking the wrong pointer atif. Fix this
to check the correct pointer atcs.

Addresses-Coverity: ("Uninitialized pointer read")
Fixes: c1c4d8efddde ("drm/amdgpu/acpi: unify ATCS handling (v2)")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index c39f447df21d..b3ee7fb72b81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -901,7 +901,7 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
goto out;
 
atcs = kzalloc(sizeof(*atcs), GFP_KERNEL);
-   if (!atif) {
+   if (!atcs) {
DRM_WARN("Not enough memory to initialize ATCS\n");
goto out;
}
-- 
2.31.1

Re: [PATCH 3/3] drm: document minimum kernel version for DRM_CLIENT_CAP_*

[Pekka Paalanen]

On Tue, 18 May 2021 11:14:52 +
Simon Ser  wrote:

> The kernel versions including the following commits are referenced:
> 
> DRM_CLIENT_CAP_STEREO_3D
> 61d8e3282541 ("drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctl")
> 
> DRM_CLIENT_CAP_UNIVERSAL_PLANES
> 681e7ec73044 ("drm: Allow userspace to ask for universal plane list (v2)")
> c7dbc6c9ae5c ("drm: Remove command line guard for universal planes")
> 
> DRM_CLIENT_CAP_ATOMIC
> 88a48e297b3a ("drm: add atomic properties")
> 8b72ce158cf0 ("drm: Always enable atomic API")
> 
> DRM_CLIENT_CAP_ASPECT_RATIO
> 7595bda2fb43 ("drm: Add DRM client cap for aspect-ratio")
> 
> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
> d67b6a206507 ("drm: writeback: Add client capability for exposing writeback 
> connectors")
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Pekka Paalanen 
> ---
>  include/uapi/drm/drm.h | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 87878aea4526..ec2b122cdcc5 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -780,6 +780,8 @@ struct drm_get_cap {
>   * If set to 1, the DRM core will expose the stereo 3D capabilities of the
>   * monitor by advertising the supported 3D layouts in the flags of struct
>   * drm_mode_modeinfo. See ``DRM_MODE_FLAG_3D_*``.
> + *
> + * This capability is always supported starting from kernel version 3.13.

Does this mean for all DRM drivers, or is it just that the definition
of the cap is recognised but it still depends per-driver if it actually
supports it?

This is always the hard question for me to figure out, and the more
interesting one.

I think adding "for all drivers" would make things much more clear,
like in the other cases you mention "atomic-capable drivers".

>   */
>  #define DRM_CLIENT_CAP_STEREO_3D 1
>  
> @@ -788,6 +790,9 @@ struct drm_get_cap {
>   *
>   * If set to 1, the DRM core will expose all planes (overlay, primary, and
>   * cursor) to userspace.
> + *
> + * This capability has been introduced in kernel version 3.15. Starting from
> + * kernel version 3.17, this capability is always supported.
>   */
>  #define DRM_CLIENT_CAP_UNIVERSAL_PLANES  2
>  
> @@ -797,6 +802,13 @@ struct drm_get_cap {
>   * If set to 1, the DRM core will expose atomic properties to userspace. This
>   * implicitly enables &DRM_CLIENT_CAP_UNIVERSAL_PLANES and
>   * &DRM_CLIENT_CAP_ASPECT_RATIO.

Wait, why does atomic turn on aspect ratio? That's surprising,
since I wouldn't think that atomic depends on aspect ratio features.

> + *
> + * If the driver doesn't support atomic mode-setting, enabling this 
> capability
> + * will fail with -EOPNOTSUPP.
> + *
> + * This capability has been introduced in kernel version 4.0. Starting from
> + * kernel version 4.2, this capability is always supported for atomic-capable
> + * drivers.
>   */
>  #define DRM_CLIENT_CAP_ATOMIC3
>  
> @@ -805,6 +817,8 @@ struct drm_get_cap {
>   *
>   * If set to 1, the DRM core will provide aspect ratio information in modes.
>   * See ``DRM_MODE_FLAG_PIC_AR_*``.
> + *
> + * This capability is always supported starting from kernel version 4.18.
>   */
>  #define DRM_CLIENT_CAP_ASPECT_RATIO4
>  
> @@ -814,6 +828,9 @@ struct drm_get_cap {
>   * If set to 1, the DRM core will expose special connectors to be used for
>   * writing back to memory the scene setup in the commit. The client must 
> enable
>   * &DRM_CLIENT_CAP_ATOMIC first.
> + *
> + * This capability is always supported for atomic-capable drivers starting 
> from
> + * kernel version 4.19.
>   */
>  #define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS  5
>  

These are really nice additions to help people figure out which ones
they would be happy to require unconditionally in userspace.

I just hope this won't encourage anyone to be testing for kernel
version instead of these caps, though.

Anyway,

Acked-by: Pekka Paalanen 


Thanks,
pq


pgpfwpZCPYjHE.pgp
Description: OpenPGP digital signature

Re: [PATCH 2/3] drm: clarify and linkify DRM_CLIENT_CAP_WRITEBACK_CONNECTORS docs

[Pekka Paalanen]

On Tue, 18 May 2021 11:14:47 +
Simon Ser  wrote:

> Make it clear that the client is responsible for enabling ATOMIC
> prior to enabling WRITEBACK_CONNECTORS. Linkify the reference to
> ATOMIC.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Pekka Paalanen 
> ---
>  include/uapi/drm/drm.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 1c947227f72b..87878aea4526 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -812,8 +812,8 @@ struct drm_get_cap {
>   * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
>   *
>   * If set to 1, the DRM core will expose special connectors to be used for
> - * writing back to memory the scene setup in the commit. Depends on client
> - * also supporting DRM_CLIENT_CAP_ATOMIC
> + * writing back to memory the scene setup in the commit. The client must 
> enable
> + * &DRM_CLIENT_CAP_ATOMIC first.
>   */
>  #define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS  5
>  

I'll take your word that this is how it must be done.

Acked-by: Pekka Paalanen 


Thanks,
pq


pgp2kBhQjr6zK.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] drm: reference mode flags in DRM_CLIENT_CAP_* docs

[Pekka Paalanen]

On Tue, 18 May 2021 11:14:42 +
Simon Ser  wrote:

> In the docs for DRM_CLIENT_CAP_STEREO_3D and
> DRM_CLIENT_CAP_ASPECT_RATIO, reference the DRM_MODE_FLAG_* defines
> that get set when the cap is enabled.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Pekka Paalanen 
> ---
>  include/uapi/drm/drm.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 67b94bc3c885..1c947227f72b 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -777,9 +777,9 @@ struct drm_get_cap {
>  /**
>   * DRM_CLIENT_CAP_STEREO_3D
>   *
> - * if set to 1, the DRM core will expose the stereo 3D capabilities of the
> + * If set to 1, the DRM core will expose the stereo 3D capabilities of the
>   * monitor by advertising the supported 3D layouts in the flags of struct
> - * drm_mode_modeinfo.
> + * drm_mode_modeinfo. See ``DRM_MODE_FLAG_3D_*``.
>   */
>  #define DRM_CLIENT_CAP_STEREO_3D 1
>  
> @@ -804,6 +804,7 @@ struct drm_get_cap {
>   * DRM_CLIENT_CAP_ASPECT_RATIO
>   *
>   * If set to 1, the DRM core will provide aspect ratio information in modes.
> + * See ``DRM_MODE_FLAG_PIC_AR_*``.
>   */
>  #define DRM_CLIENT_CAP_ASPECT_RATIO4
>  

Good.

Acked-by: Pekka Paalanen 


Thanks,
pq


pgpcQLIt2WH3a.pgp
Description: OpenPGP digital signature

[PATCH] drm/i915/gt: fix typo issue

[samirweng1979]

From: wengjianfeng 

change 'freqency' to 'frequency'.

Signed-off-by: wengjianfeng 
---
 drivers/gpu/drm/i915/gt/selftest_rps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c 
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index 967641f..71e6658 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -606,7 +606,7 @@ int live_rps_frequency_cs(void *arg)
int err = 0;
 
/*
-* The premise is that the GPU does change freqency at our behest.
+* The premise is that the GPU does change frequency at our behest.
 * Let's check there is a correspondence between the requested
 * frequency, the actual frequency, and the observed clock rate.
 */
@@ -747,7 +747,7 @@ int live_rps_frequency_srm(void *arg)
int err = 0;
 
/*
-* The premise is that the GPU does change freqency at our behest.
+* The premise is that the GPU does change frequency at our behest.
 * Let's check there is a correspondence between the requested
 * frequency, the actual frequency, and the observed clock rate.
 */
-- 
1.9.1

re: drm/amdgpu/acpi: unify ATCS handling (v2) [uninitialized variable error]

[Colin Ian King]

Hi,

Static analysis on linux-next with Coverity has detected an issue in
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c with the following commit:

commit c1c4d8efdddec8a0ccc8525b29740640bd652ce8
Author: Alex Deucher 
Date:   Wed May 19 15:47:42 2021 -0400

drm/amdgpu/acpi: unify ATCS handling (v2)


The analysis is as follows:


805int amdgpu_acpi_init(struct amdgpu_device *adev)
806{
807acpi_handle handle, atif_handle, atcs_handle;
808struct amdgpu_atif *atif;
809struct amdgpu_atcs *atcs;

   1. var_decl: Declaring variable ret without initializer.

810int ret;
811
812/* Get the device handle */

   2. Condition is_acpi_device_node(__to_acpi_device_node_fwnode),
taking true branch.
   3. Condition 0 /* !!(!__builtin_types_compatible_p() &&
!__builtin_types_compatible_p()) */, taking false branch.

813handle = ACPI_HANDLE(&adev->pdev->dev);
814

   4. Condition !adev->bios, taking false branch.
   5. Condition !handle, taking false branch.

815if (!adev->bios || !handle)
816return 0;
817
818/* Probe for ATIF, and initialize it if found */
819atif_handle = amdgpu_atif_probe_handle(handle);

   6. Condition !atif_handle, taking true branch.
820if (!atif_handle)
   7. Jumping to label atcs.

821goto atcs;
822
823atif = kzalloc(sizeof(*atif), GFP_KERNEL);
824if (!atif) {
825DRM_WARN("Not enough memory to initialize ATIF\n");
826goto atcs;
827}
828atif->handle = atif_handle;
829
830/* Call the ATIF method */
831ret = amdgpu_atif_verify_interface(atif);
832if (ret) {
833DRM_DEBUG_DRIVER("Call to ATIF verify_interface
failed: %d\n", ret);
834kfree(atif);
835goto atcs;
836}
837adev->atif = atif;
838
839#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
840if (atif->notifications.brightness_change) {
841if (amdgpu_device_has_dc_support(adev)) {
842#if defined(CONFIG_DRM_AMD_DC)
843struct amdgpu_display_manager *dm = &adev->dm;
844if (dm->backlight_dev)
845atif->bd = dm->backlight_dev;
846#endif
847} else {
848struct drm_encoder *tmp;
849
850/* Find the encoder controlling the brightness */
851list_for_each_entry(tmp,
&adev_to_drm(adev)->mode_config.encoder_list,
852head) {
853struct amdgpu_encoder *enc =
to_amdgpu_encoder(tmp);
854
855if ((enc->devices &
(ATOM_DEVICE_LCD_SUPPORT)) &&
856enc->enc_priv) {
857struct
amdgpu_encoder_atom_dig *dig = enc->enc_priv;
858if (dig->bl_dev) {
859atif->bd = dig->bl_dev;
860break;
861}
862}
863}
864}
865}
866#endif
867
868if (atif->functions.sbios_requests &&
!atif->functions.system_params) {
869/* XXX check this workraround, if sbios request
function is
870 * present we have to see how it's configured in the
system
871 * params
872 */
873atif->functions.system_params = true;
874}
875
876if (atif->functions.system_params) {
877ret = amdgpu_atif_get_notification_params(atif);
878if (ret) {
879DRM_DEBUG_DRIVER("Call to GET_SYSTEM_PARAMS
failed: %d\n",
880ret);
881/* Disable notification */
882atif->notification_cfg.enabled = false;
883}
884}
885
886if (atif->functions.query_backlight_transfer_characteristics) {
887ret = amdgpu_atif_query_backlight_caps(atif);
888if (ret) {
889DRM_DEBUG_DRIVER("Call to
QUERY_BACKLIGHT_TRANSFER_CHARACTERISTICS failed: %d\n",
890ret);
891atif->backlight_caps.caps_valid = false;
892}
893} else {
894atif->backlight_caps.caps_valid = false;
895}
896
897atcs:
898/* Probe for ATCS, and initialize it if found */
899atcs_handle = amdgpu_atcs_probe_handle(handle);

   8. Condition !atcs_handle, taking true branch.
900if (!atcs_handle)
   9. Jumping to label out.

901goto out;
902
903atcs = kzalloc(sizeof(*atcs), GFP_KERNEL);
 CID 114228: Uninitialize

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Tvrtko Ursulin]

On 19/05/2021 19:23, Daniel Vetter wrote:

On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
 wrote:



On 18/05/2021 10:40, Tvrtko Ursulin wrote:


On 18/05/2021 10:16, Daniel Stone wrote:

Hi,

On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
 wrote:

I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect drm files while walking procfs.


Maybe I'm missing something, but is the per-PID walk actually a
measurable performance issue rather than just a bit unpleasant?


Per pid and per each open fd.

As said in the other thread what bothers me a bit in this scheme is that
the cost of obtaining GPU usage scales based on non-GPU criteria.

For use case of a top-like tool which shows all processes this is a
smaller additional cost, but then for a gpu-top like tool it is somewhat
higher.


To further expand, not only cost would scale per pid multiplies per open
fd, but to detect which of the fds are DRM I see these three options:

1) Open and parse fdinfo.
2) Name based matching ie /dev/dri/.. something.
3) Stat the symlink target and check for DRM major.


stat with symlink following should be plenty fast.


Maybe. I don't think my point about keeping the dentry cache needlessly 
hot is getting through at all. On my lightly loaded desktop:


 $ sudo lsof | wc -l
 599551

 $ sudo lsof | grep "/dev/dri/" | wc -l
 1965

It's going to look up ~600k pointless dentries in every iteration. Just 
to find a handful of DRM ones. Hard to say if that is better or worse 
than just parsing fdinfo text for all files. Will see.



All sound quite sub-optimal to me.

Name based matching is probably the least evil on system resource usage
(Keeping the dentry cache too hot? Too many syscalls?), even though
fundamentally I don't it is the right approach.

What happens with dup(2) is another question.


We need benchmark numbers showing that on anything remotely realistic
it's an actual problem. Until we've demonstrated it's a real problem
we don't need to solve it.


Point about dup(2) is whether it is possible to distinguish the 
duplicated fds in fdinfo. If a DRM client dupes, and we found two 
fdinfos each saying client is using 20% GPU, we don't want to add it up 
to 40%.



E.g. top with any sorting enabled also parses way more than it
displays on every update. It seems to be doing Just Fine (tm).


Ha, perceptions differ. I see it using 4-5% while building the kernel on 
a Xeon server which I find quite a lot. :)



Does anyone have any feedback on the /proc//gpu idea at all?


When we know we have a problem to solve we can take a look at solutions.


Yes I don't think the problem would be to add a better solution later, 
so happy to try the fdinfo first. I am simply pointing out a fundamental 
design inefficiency. Even if machines are getting faster and faster I 
don't think that should be an excuse to waste more and more under the 
hood, when a more efficient solution can be designed from the start.


Regards,

Tvrtko

[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=211277

--- Comment #30 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 296891
  --> https://bugzilla.kernel.org/attachment.cgi?id=296891&action=edit
all kernel messages with ip_block_mask=0x0ff (Debian kernel 5.10.0-6)

Also crashes with ip_block_mask=0x0ff
Tested with the current Debian Testing kernel 5.10.0-6.

I attached all kernel messages from /var/log/messages from boot to crash.
I think that should be the dmesg output.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [V2][PATCH 1/2] drm: xlnx: add is_layer_vid() to simplify the code

[Laurent Pinchart]

Hi Quanyang,

Thank you for the patch.

On Tue, May 18, 2021 at 05:50:18PM +0800, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang 
> 
> Add a new function is_layer_vid() to simplify the code that
> judges if a layer is the video layer.

I like this, and especially passing the layer pointer to functions
instead of the layer ID. I'm however wondering is we shouldn't name the
function xlnx_zynqmp_disp_layer_is_video(), for consistency. If that's
fine with you I can make the change when applying the patch to my tree,
there's no need to submit a new version.

> Acked-by: Paul Cercueil 
> Signed-off-by: Quanyang Wang 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 39 +-
>  1 file changed, 22 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 109d627968ac..eefb278e24c6 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -434,30 +434,35 @@ static void zynqmp_disp_avbuf_write(struct 
> zynqmp_disp_avbuf *avbuf,
>   writel(val, avbuf->base + reg);
>  }
>  
> +static bool is_layer_vid(const struct zynqmp_disp_layer *layer)
> +{
> + return layer->id == ZYNQMP_DISP_LAYER_VID;
> +}
> +
>  /**
>   * zynqmp_disp_avbuf_set_format - Set the input format for a layer
>   * @avbuf: Audio/video buffer manager
> - * @layer: The layer ID
> + * @layer: The layer
>   * @fmt: The format information
>   *
>   * Set the video buffer manager format for @layer to @fmt.
>   */
>  static void zynqmp_disp_avbuf_set_format(struct zynqmp_disp_avbuf *avbuf,
> -  enum zynqmp_disp_layer_id layer,
> +  struct zynqmp_disp_layer *layer,
>const struct zynqmp_disp_format *fmt)
>  {
>   unsigned int i;
>   u32 val;
>  
>   val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_FMT);
> - val &= layer == ZYNQMP_DISP_LAYER_VID
> + val &= is_layer_vid(layer)
>   ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
>   : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
>   val |= fmt->buf_fmt;
>   zynqmp_disp_avbuf_write(avbuf, ZYNQMP_DISP_AV_BUF_FMT, val);
>  
>   for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {
> - unsigned int reg = layer == ZYNQMP_DISP_LAYER_VID
> + unsigned int reg = is_layer_vid(layer)
>? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
>: ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
>  
> @@ -573,19 +578,19 @@ static void zynqmp_disp_avbuf_disable_audio(struct 
> zynqmp_disp_avbuf *avbuf)
>  /**
>   * zynqmp_disp_avbuf_enable_video - Enable a video layer
>   * @avbuf: Audio/video buffer manager
> - * @layer: The layer ID
> + * @layer: The layer
>   * @mode: Operating mode of layer
>   *
>   * Enable the video/graphics buffer for @layer.
>   */
>  static void zynqmp_disp_avbuf_enable_video(struct zynqmp_disp_avbuf *avbuf,
> -enum zynqmp_disp_layer_id layer,
> +struct zynqmp_disp_layer *layer,
>  enum zynqmp_disp_layer_mode mode)
>  {
>   u32 val;
>  
>   val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);
> - if (layer == ZYNQMP_DISP_LAYER_VID) {
> + if (is_layer_vid(layer)) {
>   val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
>   if (mode == ZYNQMP_DISP_LAYER_NONLIVE)
>   val |= ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MEM;
> @@ -605,17 +610,17 @@ static void zynqmp_disp_avbuf_enable_video(struct 
> zynqmp_disp_avbuf *avbuf,
>  /**
>   * zynqmp_disp_avbuf_disable_video - Disable a video layer
>   * @avbuf: Audio/video buffer manager
> - * @layer: The layer ID
> + * @layer: The layer
>   *
>   * Disable the video/graphics buffer for @layer.
>   */
>  static void zynqmp_disp_avbuf_disable_video(struct zynqmp_disp_avbuf *avbuf,
> - enum zynqmp_disp_layer_id layer)
> + struct zynqmp_disp_layer *layer)
>  {
>   u32 val;
>  
>   val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);
> - if (layer == ZYNQMP_DISP_LAYER_VID) {
> + if (is_layer_vid(layer)) {
>   val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
>   val |= ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_NONE;
>   } else {
> @@ -807,7 +812,7 @@ static void zynqmp_disp_blend_layer_set_csc(struct 
> zynqmp_disp_blend *blend,
>   }
>   }
>  
> - if (layer->id == ZYNQMP_DISP_LAYER_VID)
> + if (is_layer_vid(layer))
>   reg = ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF(0);
>   else
>   reg = ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF(0);
> @@ -818,7 +823,7 @@ static void zynqmp_disp_blend_layer_set_csc(struct 
> zynqmp_disp_blend *blend,
>   zynqmp_disp_blend_wr

[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=211277

--- Comment #31 from Jerome C (m...@jeromec.com) ---
(In reply to kolAflash from comment #30)
> Created attachment 296891 [details]
> all kernel messages with ip_block_mask=0x0ff (Debian kernel 5.10.0-6)
> 
> Also crashes with ip_block_mask=0x0ff
> Tested with the current Debian Testing kernel 5.10.0-6.
> 
> I attached all kernel messages from /var/log/messages from boot to crash.
> I think that should be the dmesg output.

hiya, you may not know this but use in "amdgpu.ip_block_mask=0x0ff" and not
"ip_block_mask=0x0ff"

"ip_block_mask=0x0ff" will only apply to linux

"amdgpu.ip_block_mask=0x0ff" will only apply to amdgpu module

I can see in your kernel logs that VCN is still enabled

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Daniel Vetter]

On Wed, May 19, 2021 at 7:19 PM Matthew Brost  wrote:
>
> On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > Add entry fpr i915 new parallel submission uAPI plan.
> > >
> > > v2:
> > >  (Daniel Vetter):
> > >   - Expand logical order explaination
> > >   - Add dummy header
> > >   - Only allow N BBs in execbuf IOCTL
> > >   - Configure parallel submission per slot not per gem context
> > >
> > > Cc: Tvrtko Ursulin 
> > > Cc: Tony Ye 
> > > CC: Carl Zhang 
> > > Cc: Daniel Vetter 
> > > Cc: Jason Ekstrand 
> > > Signed-off-by: Matthew Brost 
> > > ---
> > >  Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
> > >  Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > >  2 files changed, 196 insertions(+), 1 deletion(-)
> > >  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > >
> > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > new file mode 100644
> > > index ..8c64b983ccad
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > @@ -0,0 +1,144 @@
> > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > > i915_context_engines_parallel_submit */
> > > +
> > > +/*
> > > + * i915_context_engines_parallel_submit:
> > > + *
> > > + * Setup a slot to allow multiple BBs to be submitted in a single 
> > > execbuf IOCTL.
> > > + * Those BBs will then be scheduled to run on the GPU in parallel. 
> > > Multiple
> > > + * hardware contexts are created internally in the i915 run these BBs. 
> > > Once a
> > > + * slot is configured for N BBs only N BBs can be submitted in each 
> > > execbuf
> > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell the 
> > > execbuf
> > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are 
> > > based on
> > > + * the slots configuration).
> > > + *
> > > + * Their are two currently defined ways to control the placement of the
> > > + * hardware contexts on physical engines: default behavior (no flags) and
> > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in 
> > > the
> > > + * future as new hardware / use cases arise. Details of how to use this
> > > + * interface below above the flags.
> > > + *
> > > + * Returns -EINVAL if hardware context placement configuration invalid 
> > > or if the
> > > + * placement configuration isn't supported on the platform / submission
> > > + * interface.
> > > + * Returns -ENODEV if extension isn't supported on the platform / 
> > > submission
> > > + * inteface.
> > > + */
> > > +struct i915_context_engines_parallel_submit {
> > > +   struct i915_user_extension base;
> > > +
> > > +   __u16 engine_index; /* slot for parallel engine */
> > > +   __u16 width;/* number of contexts per parallel engine */
> > > +   __u16 num_siblings; /* number of siblings per context */
> > > +   __u16 mbz16;
> >
> > Ok the big picture looks reasonable now, the flags still confuse me.
> >
>
> Yea, it is a bit confusing.
>
> > > +/*
> > > + * Default placement behvavior (currently unsupported):
> > > + *
> > > + * Rather than restricting parallel submission to a single class with a
> > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a 
> > > mode that
> > > + * enables parallel submission across multiple engine classes. In this 
> > > case each
> > > + * context's logical engine mask indicates where that context can 
> > > placed. It is
> > > + * implied in this mode that all contexts have mutual exclusive 
> > > placement (e.g.
> > > + * if one context is running CS0 no other contexts can run on CS0).
> > > + *
> > > + * Example 1 pseudo code:
> > > + * CSX[Y] = engine class X, logical instance Y
> > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > + * set_engines(INVALID)
> > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> > > + *
> > > + * Results in the following valid placements:
> > > + * CS0[0], CS1[0]
> > > + * CS0[0], CS1[1]
> > > + * CS0[1], CS1[0]
> > > + * CS0[1], CS1[1]
> > > + *
> > > + * This can also be though of as 2 virtual engines:
> > > + * VE[0] = CS0[0], CS0[1]
> > > + * VE[1] = CS1[0], CS1[1]
> > > + *
> > > + * Example 2 pseudo code:
> > > + * CS[X] = generic engine of same class, logical instance X
> > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > + * set_engines(INVALID)
> > > + * set_parallel(engine_index=0, width=2, num_siblings=3,
> > > + * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
> > > + *
> > > + * Results in the following valid placements:
> > > + * CS[0], CS[1]
> > > + * CS[0], CS[2]
> > > + * CS[1], CS[0]
> > > + * CS[1], CS[2]
> > > + * CS[2], CS[0]
> > > + * CS[2], CS[1]
> > > + *
> > > + *
> > > + * This can also be though of as 

Re: [V2][PATCH 2/2] drm: xlnx: consolidate the functions which programming AUDIO_VIDEO_SELECT register

[Laurent Pinchart]

Hi Quanyang,

Thank you for the patch.

On Tue, May 18, 2021 at 05:50:19PM +0800, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang 
> 
> For now, the functions zynqmp_disp_avbuf_enable/disable_audio and
> zynqmp_disp_avbuf_enable/disable_video are all programming the register
> AV_BUF_OUTPUT_AUDIO_VIDEO_SELECT to select the output for audio or video.
> And in the future, many drm properties (like video_tpg, audio_tpg,
> audio_pl, etc) also need to access it. So let's introduce some variables
> of enum type and consolidate the code to unify handling this.
> 
> Signed-off-by: Quanyang Wang 
> ---
>  drivers/gpu/drm/xlnx/zynqmp_disp.c  | 168 ++--
>  drivers/gpu/drm/xlnx/zynqmp_disp_regs.h |  23 +---
>  2 files changed, 106 insertions(+), 85 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index eefb278e24c6..3672d2f5665b 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -102,12 +102,39 @@ enum zynqmp_disp_layer_id {
>  
>  /**
>   * enum zynqmp_disp_layer_mode - Layer mode
> - * @ZYNQMP_DISP_LAYER_NONLIVE: non-live (memory) mode
> + * @ZYNQMP_DISP_LAYER_MEM: memory mode
>   * @ZYNQMP_DISP_LAYER_LIVE: live (stream) mode
> + * @ZYNQMP_DISP_LAYER_TPG: tpg mode (only for video layer)
> + * @ZYNQMP_DISP_LAYER_DISABLE: disable mode

"Disable" isn't really a mode :-S

>   */
>  enum zynqmp_disp_layer_mode {
> - ZYNQMP_DISP_LAYER_NONLIVE,
> - ZYNQMP_DISP_LAYER_LIVE
> + ZYNQMP_DISP_LAYER_MEM,
> + ZYNQMP_DISP_LAYER_LIVE,
> + ZYNQMP_DISP_LAYER_TPG,
> + ZYNQMP_DISP_LAYER_DISABLE
> +};
> +
> +enum avbuf_vid_mode {
> + VID_MODE_LIVE,
> + VID_MODE_MEM,
> + VID_MODE_TPG,
> + VID_MODE_NONE
> +};

I don't like this much. The enum here doesn't clearly show that the
values correspond to hardware register values. I'd rather address this
in drivers/gpu/drm/xlnx/zynqmp_disp_regs.h, see below for a proposal.

> +
> +enum avbuf_gfx_mode {
> + GFX_MODE_DISABLE,
> + GFX_MODE_MEM,
> + GFX_MODE_LIVE,
> + GFX_MODE_NONE
> +};
> +
> +enum avbuf_aud_mode {
> + AUD1_MODE_LIVE,
> + AUD1_MODE_MEM,
> + AUD1_MODE_TPG,
> + AUD1_MODE_DISABLE,
> + AUD2_MODE_DISABLE,
> + AUD2_MODE_ENABLE

Combining AUD1 and AUD2 in the same enum, with the
" - AUD2_MODE_DISABLE" below, is really a hack. Let's keep
hardware-related valeus in drivers/gpu/drm/xlnx/zynqmp_disp_regs.h.

Overall I'm not really fond of this rework I'm afraid, I think the
result is way less readable. Given that this isn't required yet as
support for the TPG or the PL input isn't part of this series, unless it
can be rewritten in a better way already, I'd prefer dropping this patch
for now and including it in a series that enables TPG or PL input.

I also think it could be beneficial to split the patch in two, it seems
to do a bit too much.

>  };
>  
>  /**
> @@ -542,92 +569,102 @@ static void zynqmp_disp_avbuf_disable_channels(struct 
> zynqmp_disp_avbuf *avbuf)
>  }
>  
>  /**
> - * zynqmp_disp_avbuf_enable_audio - Enable audio
> + * zynqmp_disp_avbuf_output_select - Select the buffer manager outputs
>   * @avbuf: Audio/video buffer manager
> + * @layer: The layer
> + * @mode: The mode for this layer
>   *
> - * Enable all audio buffers with a non-live (memory) source.
> + * Select the buffer manager outputs for @layer.
>   */
> -static void zynqmp_disp_avbuf_enable_audio(struct zynqmp_disp_avbuf *avbuf)
> +static void zynqmp_disp_avbuf_output_select(struct zynqmp_disp_avbuf *avbuf,
> +struct zynqmp_disp_layer *layer,
> +u32 mode)
>  {
> - u32 val;
> + u32 reg;
>  
> - val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);
> - val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_AUD1_MASK;
> - val |= ZYNQMP_DISP_AV_BUF_OUTPUT_AUD1_MEM;
> - val |= ZYNQMP_DISP_AV_BUF_OUTPUT_AUD2_EN;
> - zynqmp_disp_avbuf_write(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT, val);
> + reg = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);
> +
> + /* Select audio mode when the layer is NULL */

This is also a hack, I don't really like it. I'd much prefer keeping
audio handling in separate functions.

> + if (layer == NULL) {
> + if (mode >= AUD2_MODE_DISABLE) {
> + reg &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_AUD2_MASK;
> + reg |= FIELD_PREP(ZYNQMP_DISP_AV_BUF_OUTPUT_AUD2_MASK,
> + (mode - AUD2_MODE_DISABLE));
> + } else {
> + reg &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_AUD1_MASK;
> + reg |= FIELD_PREP(ZYNQMP_DISP_AV_BUF_OUTPUT_AUD1_MASK, 
> mode);
> + }
> + } else if (is_layer_vid(layer)) {
> + reg &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
> + reg |= FIELD_PREP(ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK, mode);
> + } else {
> + 

Re: [RFC] Add DMA_RESV_USAGE flags

[Christian König]

Am 20.05.21 um 10:13 schrieb Michel Dänzer:

On 2021-05-20 9:55 a.m., Daniel Vetter wrote:

On Wed, May 19, 2021 at 5:48 PM Michel Dänzer  wrote:

On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:

On Wed, May 19, 2021 at 5:52 AM Michel Dänzer  wrote:

On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:

On Tue, May 18, 2021 at 4:17 PM Daniel Vetter  wrote:

On Tue, May 18, 2021 at 7:40 PM Christian König
 wrote:

Am 18.05.21 um 18:48 schrieb Daniel Vetter:

On Tue, May 18, 2021 at 2:49 PM Christian König
 wrote:


And as long as we are all inside amdgpu we also don't have any oversync,
the issue only happens when we share dma-bufs with i915 (radeon and
AFAIK nouveau does the right thing as well).

Yeah because then you can't use the amdgpu dma_resv model anymore and
have to use the one atomic helpers use. Which is also the one that
e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
so as soon as that lands and someone starts using it, something has to
adapt _anytime_ you have a dma-buf hanging around. Not just when it's
shared with another device.

Yeah, and that is exactly the reason why I will NAK this uAPI change.

This doesn't works for amdgpu at all for the reasons outlined above.

Uh that's really not how uapi works. "my driver is right, everyone
else is wrong" is not how cross driver contracts are defined. If that
means a perf impact until you've fixed your rules, that's on you.

Also you're a few years too late with nacking this, it's already uapi
in the form of the dma-buf poll() support.

^^  My fancy new ioctl doesn't expose anything that isn't already
there.  It just lets you take a snap-shot of a wait instead of doing
an active wait which might end up with more fences added depending on
interrupts and retries.  The dma-buf poll waits on all fences for
POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.

Note that the dma-buf poll support could be useful to Wayland compositors for 
the same purpose as Jason's new ioctl (only using client buffers which have 
finished drawing for an output frame, to avoid missing a refresh cycle due to 
client drawing), *if* it didn't work differently with amdgpu.

Am I understanding correctly that Jason's new ioctl would also work differently 
with amdgpu as things stand currently? If so, that would be a real bummer and 
might hinder adoption of the ioctl by Wayland compositors.

My new ioctl has identical semantics to poll().  It just lets you take
a snapshot in time to wait on later instead of waiting on whatever
happens to be set right now.  IMO, having identical semantics to
poll() isn't something we want to change.

Agreed.

I'd argue then that making amdgpu poll semantics match those of other drivers 
is a pre-requisite for the new ioctl, otherwise it seems unlikely that the 
ioctl will be widely adopted.

This seems backwards, because that means useful improvements in all
other drivers are stalled until amdgpu is fixed.

I think we need agreement on what the rules are, reasonable plan to
get there, and then that should be enough to unblock work in the wider
community. Holding the community at large hostage because one driver
is different is really not great.

I think we're in violent agreement. :) The point I was trying to make is that 
amdgpu really needs to be fixed to be consistent with other drivers ASAP.


Well from my point of view I rather think that the rules of DMA-buf 
implicit sync should be fixed, cause those are based on an ancient DRM 
approach.


And I'm seriously not accepting any changes to amdgpu involving per BO 
flags for CS.


Regards,
Christian.

XDC 2021: Registration & Call for Proposals now open!

[Szwichtenberg, Radoslaw]

Hello!

Registration & Call for Proposals are now open for XDC 2021, which will
take place on September 15-17, 2021. This year we will repeat as
virtual event.

https://indico.freedesktop.org/event/1/

As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!

In order to register as attendee, you will therefore need to register
via the XDC website. As XDC moved to a new Indico infrastructure, if
you previously registered on the XDC website, you need to create a new
account again.

https://indico.freedesktop.org/event/1/registrations/1/

In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2021. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.

We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more:

https://indico.freedesktop.org/event/1/abstracts/

The deadline for submissions is Sunday, 4 July 2021.

Last year we modified our Reimbursement Policy to accept speaker
expenses for X.Org virtual events like XDC 2021. Check it out here:

https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
radoslaw.szwichtenb...@intel.com,  
adding on CC the X.org board (board
at foundation.x.org).

And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:


https://twitter.com/XOrgDevConf

Best,

Radek

P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please use
the mentioned links for the moment.


Radosław Szwichtenberg
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173, 80-298 Gdansk
KRS 101882 - NIP 957-07-52-316

Re: [V2][PATCH 1/2] drm: xlnx: add is_layer_vid() to simplify the code

[quanyang.wang]

Hi Laurent,

Thank you for your review.

On 5/20/21 5:37 PM, Laurent Pinchart wrote:

Hi Quanyang,

Thank you for the patch.

On Tue, May 18, 2021 at 05:50:18PM +0800, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

Add a new function is_layer_vid() to simplify the code that
judges if a layer is the video layer.


I like this, and especially passing the layer pointer to functions
instead of the layer ID. I'm however wondering is we shouldn't name the
function xlnx_zynqmp_disp_layer_is_video(), for consistency. If that's
fine with you I can make the change when applying the patch to my tree,
there's no need to submit a new version.
That's fine. Please help change the function name to 
xlnx_zynqmp_disp_layer_is_video().


Thanks,
Quanyang



Acked-by: Paul Cercueil 
Signed-off-by: Quanyang Wang 


Reviewed-by: Laurent Pinchart 


---
  drivers/gpu/drm/xlnx/zynqmp_disp.c | 39 +-
  1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 109d627968ac..eefb278e24c6 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -434,30 +434,35 @@ static void zynqmp_disp_avbuf_write(struct 
zynqmp_disp_avbuf *avbuf,
writel(val, avbuf->base + reg);
  }
  
+static bool is_layer_vid(const struct zynqmp_disp_layer *layer)

+{
+   return layer->id == ZYNQMP_DISP_LAYER_VID;
+}
+
  /**
   * zynqmp_disp_avbuf_set_format - Set the input format for a layer
   * @avbuf: Audio/video buffer manager
- * @layer: The layer ID
+ * @layer: The layer
   * @fmt: The format information
   *
   * Set the video buffer manager format for @layer to @fmt.
   */
  static void zynqmp_disp_avbuf_set_format(struct zynqmp_disp_avbuf *avbuf,
-enum zynqmp_disp_layer_id layer,
+struct zynqmp_disp_layer *layer,
 const struct zynqmp_disp_format *fmt)
  {
unsigned int i;
u32 val;
  
  	val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_FMT);

-   val &= layer == ZYNQMP_DISP_LAYER_VID
+   val &= is_layer_vid(layer)
? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
: ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
val |= fmt->buf_fmt;
zynqmp_disp_avbuf_write(avbuf, ZYNQMP_DISP_AV_BUF_FMT, val);
  
  	for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {

-   unsigned int reg = layer == ZYNQMP_DISP_LAYER_VID
+   unsigned int reg = is_layer_vid(layer)
 ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
 : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
  
@@ -573,19 +578,19 @@ static void zynqmp_disp_avbuf_disable_audio(struct zynqmp_disp_avbuf *avbuf)

  /**
   * zynqmp_disp_avbuf_enable_video - Enable a video layer
   * @avbuf: Audio/video buffer manager
- * @layer: The layer ID
+ * @layer: The layer
   * @mode: Operating mode of layer
   *
   * Enable the video/graphics buffer for @layer.
   */
  static void zynqmp_disp_avbuf_enable_video(struct zynqmp_disp_avbuf *avbuf,
-  enum zynqmp_disp_layer_id layer,
+  struct zynqmp_disp_layer *layer,
   enum zynqmp_disp_layer_mode mode)
  {
u32 val;
  
  	val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);

-   if (layer == ZYNQMP_DISP_LAYER_VID) {
+   if (is_layer_vid(layer)) {
val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
if (mode == ZYNQMP_DISP_LAYER_NONLIVE)
val |= ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MEM;
@@ -605,17 +610,17 @@ static void zynqmp_disp_avbuf_enable_video(struct 
zynqmp_disp_avbuf *avbuf,
  /**
   * zynqmp_disp_avbuf_disable_video - Disable a video layer
   * @avbuf: Audio/video buffer manager
- * @layer: The layer ID
+ * @layer: The layer
   *
   * Disable the video/graphics buffer for @layer.
   */
  static void zynqmp_disp_avbuf_disable_video(struct zynqmp_disp_avbuf *avbuf,
-   enum zynqmp_disp_layer_id layer)
+   struct zynqmp_disp_layer *layer)
  {
u32 val;
  
  	val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);

-   if (layer == ZYNQMP_DISP_LAYER_VID) {
+   if (is_layer_vid(layer)) {
val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
val |= ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_NONE;
} else {
@@ -807,7 +812,7 @@ static void zynqmp_disp_blend_layer_set_csc(struct 
zynqmp_disp_blend *blend,
}
}
  
-	if (layer->id == ZYNQMP_DISP_LAYER_VID)

+   if (is_layer_vid(layer))
reg = ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF(0);
else
reg = ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF(0);
@@ -818,7 +823,7 @@ static void zynqmp_disp_blend_layer

Requests For Proposals for hosting XDC 2022 are now open

[Samuel Iglesias Gonsálvez]

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2022. Since
XDC 2021 is being held in Europe this year (although virtually), we've
decided to host in North America. However, the board is open to other
locations, especially if there's an interesting co-location with
another conference.

Of course though, due to the ongoing COVID-19 pandemic it's not yet
clear whether or not it will be possible to host XDC 2022 in person,
although is seems very likely. Because of this, we would like to
make it clear that sponsors should prepare for both the possibility
of an in person conference, and the possibility of a virtual
conference. We will work with organizers on coming up with a
deadline for deciding whether or not we'll be going virtual, likely
sometime around July 2022.

If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:

https://www.x.org/wiki/Events/RFP/

When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible
dates along with estimated costs. Proposals can be submitted to board
at foundation.x.org until the deadline of *September 1st, 2021*. 

Additionally, an quirk early heads-up to the board if you're
considering hosting would be appreciated, in case we need to adjust the
schedule a bit. Also, earlier is better since there generally will be a
bit of Q&A with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.

Thanks,

Sam



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] drm/bridge: anx7625: Synchronously run runtime suspend.

[Robert Foss]

On Thu, 20 May 2021 at 12:12, Tzung-Bi Shih  wrote:
>
> On Thu, May 20, 2021 at 2:45 PM Pi-Hsun Shih  wrote:
> > Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use 
> > runtime PM framework")
> > Signed-off-by: Pi-Hsun Shih 
>
> Tested-by: Tzung-Bi Shih 

Reviewed-by: Robert Foss 

Re: [PATCH] drm/bridge: anx7625: Synchronously run runtime suspend.

[Robert Foss]

Applied to drm-misc-next

On Thu, 20 May 2021 at 12:25, Robert Foss  wrote:
>
> On Thu, 20 May 2021 at 12:12, Tzung-Bi Shih  wrote:
> >
> > On Thu, May 20, 2021 at 2:45 PM Pi-Hsun Shih  wrote:
> > > Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use 
> > > runtime PM framework")
> > > Signed-off-by: Pi-Hsun Shih 
> >
> > Tested-by: Tzung-Bi Shih 
>
> Reviewed-by: Robert Foss 

Re: [RFC] Add DMA_RESV_USAGE flags

[Christian König]

Am 20.05.21 um 09:55 schrieb Daniel Vetter:

On Wed, May 19, 2021 at 5:48 PM Michel Dänzer  wrote:

On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:

On Wed, May 19, 2021 at 5:52 AM Michel Dänzer  wrote:

On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:

On Tue, May 18, 2021 at 4:17 PM Daniel Vetter  wrote:

On Tue, May 18, 2021 at 7:40 PM Christian König
 wrote:

Am 18.05.21 um 18:48 schrieb Daniel Vetter:

On Tue, May 18, 2021 at 2:49 PM Christian König
 wrote:


And as long as we are all inside amdgpu we also don't have any oversync,
the issue only happens when we share dma-bufs with i915 (radeon and
AFAIK nouveau does the right thing as well).

Yeah because then you can't use the amdgpu dma_resv model anymore and
have to use the one atomic helpers use. Which is also the one that
e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
so as soon as that lands and someone starts using it, something has to
adapt _anytime_ you have a dma-buf hanging around. Not just when it's
shared with another device.

Yeah, and that is exactly the reason why I will NAK this uAPI change.

This doesn't works for amdgpu at all for the reasons outlined above.

Uh that's really not how uapi works. "my driver is right, everyone
else is wrong" is not how cross driver contracts are defined. If that
means a perf impact until you've fixed your rules, that's on you.

Also you're a few years too late with nacking this, it's already uapi
in the form of the dma-buf poll() support.

^^  My fancy new ioctl doesn't expose anything that isn't already
there.  It just lets you take a snap-shot of a wait instead of doing
an active wait which might end up with more fences added depending on
interrupts and retries.  The dma-buf poll waits on all fences for
POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.

Note that the dma-buf poll support could be useful to Wayland compositors for 
the same purpose as Jason's new ioctl (only using client buffers which have 
finished drawing for an output frame, to avoid missing a refresh cycle due to 
client drawing), *if* it didn't work differently with amdgpu.

Am I understanding correctly that Jason's new ioctl would also work differently 
with amdgpu as things stand currently? If so, that would be a real bummer and 
might hinder adoption of the ioctl by Wayland compositors.

My new ioctl has identical semantics to poll().  It just lets you take
a snapshot in time to wait on later instead of waiting on whatever
happens to be set right now.  IMO, having identical semantics to
poll() isn't something we want to change.

Agreed.

I'd argue then that making amdgpu poll semantics match those of other drivers 
is a pre-requisite for the new ioctl, otherwise it seems unlikely that the 
ioctl will be widely adopted.

This seems backwards, because that means useful improvements in all
other drivers are stalled until amdgpu is fixed.


Well there is nothing to fix in amdgpu, what we need to is to come up 
with an DMA-buf implicit syncing model which works for everyone.


I've pointed this problem out at FOSDEM roughly 6 years ago, before 
DMA-buf was even merged upstream and way before amdgpu even existed. And 
the response was yeah, maybe we need to look at this as well.


Over the years I've mentioned now at least 5 times that this isn't going 
to work in some situations and came up with different approaches how to 
fix it.


And you still have the nerves to tell me that this isn't a problem and 
we should fix amdgpu instead? Sorry, but I'm really running out of ideas 
how to explain why this isn't working for everybody.


That amdgpu wants to be special is true, but it is a fundamental problem 
that we have designed the implicit sync in DMA-buf only around the needs 
of DRM drivers at that time instead of going a step back and saying hey 
what would be an approach which works for everyone.


You just need to apply my example from FOSDEM with ring buffers in a 
single BO to the DMA-buf implicit sync model and immediately see how it 
falls apart.



I think we need agreement on what the rules are, reasonable plan to
get there, and then that should be enough to unblock work in the wider
community. Holding the community at large hostage because one driver
is different is really not great.


Well forcing a drivers into a synchronization model not ideal for their 
hardware isn't great either.


The patches I provided at least clean up the naming convention and 
provide clean interfaces for iterating over the shared fence container. 
On top of that use case driven APIs can be implemented.


And yes I'm perfectly aware that this means that we need to touch all 
drivers and memory management handlers, but I'm pretty sure that 
untangling implicit synchronization from resource management is worth 
the effort no matter what changes to the sync model we are going to do.


Regards,
Christian.



I've just finished the subsystem review of everything, and thus far
only found some minor bugs witho

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Tvrtko Ursulin]

On 20/05/2021 10:54, Daniel Vetter wrote:

On Wed, May 19, 2021 at 7:19 PM Matthew Brost  wrote:


On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:

On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:

Add entry fpr i915 new parallel submission uAPI plan.

v2:
  (Daniel Vetter):
   - Expand logical order explaination
   - Add dummy header
   - Only allow N BBs in execbuf IOCTL
   - Configure parallel submission per slot not per gem context

Cc: Tvrtko Ursulin 
Cc: Tony Ye 
CC: Carl Zhang 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Signed-off-by: Matthew Brost 
---
  Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
  Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
  2 files changed, 196 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h

diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf 
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based 
on
+ * the slots configuration).
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if 
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+   struct i915_user_extension base;
+
+   __u16 engine_index; /* slot for parallel engine */
+   __u16 width;/* number of contexts per parallel engine */
+   __u16 num_siblings; /* number of siblings per context */
+   __u16 mbz16;


Ok the big picture looks reasonable now, the flags still confuse me.



Yea, it is a bit confusing.


+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode 
that
+ * enables parallel submission across multiple engine classes. In this case 
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * CS0[0], CS1[1]
+ * CS0[1], CS1[0]
+ * CS0[1], CS1[1]
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS0[0], CS0[1]
+ * VE[1] = CS1[0], CS1[1]
+ *
+ * Example 2 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=3,
+ * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ * CS[0], CS[2]
+ * CS[1], CS[0]
+ * CS[1], CS[2]
+ * CS[2], CS[0]
+ * CS[2], CS[1]
+ *
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS[0], CS[1], CS[2]
+ * VE[1] = CS[0], CS[1], CS[2]
+
+ * This enables a use case where all engines are created equally, we don't care
+ * where they are scheduled, we just want a certain number of resources, for
+ * those resources to be scheduled in parallel, and possibly across multiple
+ * engine classes.
+ */


So I don't really get what this does compared to setting the flag below.
Is this just about running the batchbuffers the wrong way round, i.e. if
you have (simplest case)

width=2, num_sibglings=1, engines=CS[0], CS[1]

Then both
CS[0], CS[1]
and
CS[1], CS[0]
are possible options for running 2 batches? Iow, the backend is 

Re: [RFC PATCH 2/2] drm/ttm: skip swapout when ttm has no backend page.

[Christian König]

Am 19.05.21 um 04:28 schrieb xinhui pan:

Signed-off-by: xinhui pan 
---
  drivers/gpu/drm/ttm/ttm_device.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 510e3e001dab..a9772fcc8f9c 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -146,6 +146,7 @@ int ttm_device_swapout(struct ttm_device *bdev, struct 
ttm_operation_ctx *ctx,
uint32_t num_pages;
  
  if (!bo->ttm ||

+   !bo->ttm->pages || !bo->ttm->pages[0] ||


This should call ttm_tt_is_populated() instead.

But apart from that it sounds like the right approach to fix this.

Thanks,
Christian.


bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)
continue;

Re: [V2][PATCH 2/2] drm: xlnx: consolidate the functions which programming AUDIO_VIDEO_SELECT register

[quanyang.wang]

Hi Laurent,
Thank you for your review.

On 5/20/21 5:56 PM, Laurent Pinchart wrote:

Hi Quanyang,

Thank you for the patch.

On Tue, May 18, 2021 at 05:50:19PM +0800, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

For now, the functions zynqmp_disp_avbuf_enable/disable_audio and
zynqmp_disp_avbuf_enable/disable_video are all programming the register
AV_BUF_OUTPUT_AUDIO_VIDEO_SELECT to select the output for audio or video.
And in the future, many drm properties (like video_tpg, audio_tpg,
audio_pl, etc) also need to access it. So let's introduce some variables
of enum type and consolidate the code to unify handling this.

Signed-off-by: Quanyang Wang 
---
  drivers/gpu/drm/xlnx/zynqmp_disp.c  | 168 ++--
  drivers/gpu/drm/xlnx/zynqmp_disp_regs.h |  23 +---
  2 files changed, 106 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index eefb278e24c6..3672d2f5665b 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -102,12 +102,39 @@ enum zynqmp_disp_layer_id {
  
  /**

   * enum zynqmp_disp_layer_mode - Layer mode
- * @ZYNQMP_DISP_LAYER_NONLIVE: non-live (memory) mode
+ * @ZYNQMP_DISP_LAYER_MEM: memory mode
   * @ZYNQMP_DISP_LAYER_LIVE: live (stream) mode
+ * @ZYNQMP_DISP_LAYER_TPG: tpg mode (only for video layer)
+ * @ZYNQMP_DISP_LAYER_DISABLE: disable mode


"Disable" isn't really a mode :-S

Yes, as per Register Reference for AV_BUF_OUTPUT_AUDIO_VIDEO_SELECT
VID_STREAM2_SEL 3:2 rw  0x2 STREAM2 Enable
00: Disable graphics from memory/live
01: Enable graphics from memory
10: Enable graphics from live
11: None
VID_STREAM1_SEL 1:0 rw  STREAM1 Select:
0: Live Video
1: Video from memory
2: Pattern Generator
3: None (black frames)

The NONE mode maybe better.



   */
  enum zynqmp_disp_layer_mode {
-   ZYNQMP_DISP_LAYER_NONLIVE,
-   ZYNQMP_DISP_LAYER_LIVE
+   ZYNQMP_DISP_LAYER_MEM,
+   ZYNQMP_DISP_LAYER_LIVE,
+   ZYNQMP_DISP_LAYER_TPG,
+   ZYNQMP_DISP_LAYER_DISABLE
+};
+
+enum avbuf_vid_mode {
+   VID_MODE_LIVE,
+   VID_MODE_MEM,
+   VID_MODE_TPG,
+   VID_MODE_NONE
+};


I don't like this much. The enum here doesn't clearly show that the
values correspond to hardware register values. I'd rather address this
in drivers/gpu/drm/xlnx/zynqmp_disp_regs.h, see below for a proposal.

The value of LIVE/MEM/TPG is different from two layer.
In Video layer, 0 is live, 1 is mem, 2 is tpg and 3 is blackscreen.
But for gfx mode, 0 is disable, 1 is mem, 2 is live and 3 is blackscreen.
If we define ZYNQMP_DISP_AV_BUF_OUTPUT_LIVE is 0, it only works for 
video layer but not graphic layer. So I define one enumeration type to 
abstract the both layer mode and also define two enumeration for each 
layer in order to write enumeration vairables directly to register.



+
+enum avbuf_gfx_mode {
+   GFX_MODE_DISABLE,
+   GFX_MODE_MEM,
+   GFX_MODE_LIVE,
+   GFX_MODE_NONE
+};
+
+enum avbuf_aud_mode {
+   AUD1_MODE_LIVE,
+   AUD1_MODE_MEM,
+   AUD1_MODE_TPG,
+   AUD1_MODE_DISABLE,
+   AUD2_MODE_DISABLE,
+   AUD2_MODE_ENABLE


Combining AUD1 and AUD2 in the same enum, with the
" - AUD2_MODE_DISABLE" below, is really a hack. Let's keep
hardware-related valeus in drivers/gpu/drm/xlnx/zynqmp_disp_regs.h.

OK, I will revert this part.


Overall I'm not really fond of this rework I'm afraid, I think the
result is way less readable. Given that this isn't required yet as
support for the TPG or the PL input isn't part of this series, unless it
can be rewritten in a better way already, I'd prefer dropping this patch
for now and including it in a series that enables TPG or PL input.
Yes, I agree. It's not a good time to add this patch now. I will rewrite 
it in a better way. Please drop this patch.




I also think it could be beneficial to split the patch in two, it seems
to do a bit too much.

Would you please give some suggestions?



  };
  
  /**

@@ -542,92 +569,102 @@ static void zynqmp_disp_avbuf_disable_channels(struct 
zynqmp_disp_avbuf *avbuf)
  }
  
  /**

- * zynqmp_disp_avbuf_enable_audio - Enable audio
+ * zynqmp_disp_avbuf_output_select - Select the buffer manager outputs
   * @avbuf: Audio/video buffer manager
+ * @layer: The layer
+ * @mode: The mode for this layer
   *
- * Enable all audio buffers with a non-live (memory) source.
+ * Select the buffer manager outputs for @layer.
   */
-static void zynqmp_disp_avbuf_enable_audio(struct zynqmp_disp_avbuf *avbuf)
+static void zynqmp_disp_avbuf_output_select(struct zynqmp_disp_avbuf *avbuf,
+  struct zynqmp_disp_layer *layer,
+

Re: [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Christian König]

Am 19.05.21 um 18:51 schrieb Matthew Brost:

On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:

Oh, yeah we call that gang submit on the AMD side.

Had already some internal discussions how to implement this, but so far
couldn't figure out how to cleanly introduce that into the DRM scheduler.

Can you briefly describe in a few words how that is supposed to work on the
Intel side?


Sure, I've done a quick PoC internally and have been able to hook this
into the DRM scheduler.

Basically each BB still maps to a single job as each job is somewhat
unique (e.g. each job has its own ring, lrc, seqno, etc...). However all
the jobs configured to run in parallel map to a single sched_entity
which maintains the order each job was generated from the execbuf IOCTL
(1 - N). When the backend receives jobs 1 to N - 1 it basically just
updates some internal state. When the backend sees job N (last job) it
actually does the submit for jobs 1 - N which with GuC submission is a
simple command moving the LRC tail of the N jobs.

Daniel has suggested that we create a single job for the NN BBs but that
would be huge rework to the internals of the i915 and likely won't
happen by the time this code first lands.

Also worth noting one way a job isn't really a treated individually is
the excl slot with dma-resv. In that case we create a composite fence of
all jobs (dma_fence_array).


Yeah, that's something we have discussed as well.

How do you prevent the scheduler from over committing to a single ring 
buffer in this scenario?


Christian.



Matt


Thanks,
Christian.

Am 19.05.21 um 01:58 schrieb Matthew Brost:

Add entry fpr i915 new parallel submission uAPI plan.

v2:
   (Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context

Cc: Tvrtko Ursulin 
Cc: Tony Ye 
CC: Carl Zhang 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Signed-off-by: Matthew Brost 
---
   Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
   Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
   2 files changed, 196 insertions(+), 1 deletion(-)
   create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h

diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf 
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based 
on
+ * the slots configuration).
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if 
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+   struct i915_user_extension base;
+
+   __u16 engine_index; /* slot for parallel engine */
+   __u16 width;/* number of contexts per parallel engine */
+   __u16 num_siblings; /* number of siblings per context */
+   __u16 mbz16;
+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode 
that
+ * enables parallel submission across multiple engine classes. In this case 
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * CS0

[PATCH v3] drm: xlnx: zynqmp: Add zynqmp_disp_layer_is_video() to simplify the code

[Laurent Pinchart]

From: Quanyang Wang 

Add a new function zynqmp_disp_layer_is_video() to simplify the code
that judges if a layer is the video layer.

Acked-by: Paul Cercueil 
Signed-off-by: Quanyang Wang 
Reviewed-by: Laurent Pinchart 
[Renamed is_layer_vid() to zynqmp_disp_layer_is_video()]]
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 39 +-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 01c6ce7784dd..a578ab3d5f89 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -434,30 +434,35 @@ static void zynqmp_disp_avbuf_write(struct 
zynqmp_disp_avbuf *avbuf,
writel(val, avbuf->base + reg);
 }
 
+static bool zynqmp_disp_layer_is_video(const struct zynqmp_disp_layer *layer)
+{
+   return layer->id == ZYNQMP_DISP_LAYER_VID;
+}
+
 /**
  * zynqmp_disp_avbuf_set_format - Set the input format for a layer
  * @avbuf: Audio/video buffer manager
- * @layer: The layer ID
+ * @layer: The layer
  * @fmt: The format information
  *
  * Set the video buffer manager format for @layer to @fmt.
  */
 static void zynqmp_disp_avbuf_set_format(struct zynqmp_disp_avbuf *avbuf,
-enum zynqmp_disp_layer_id layer,
+struct zynqmp_disp_layer *layer,
 const struct zynqmp_disp_format *fmt)
 {
unsigned int i;
u32 val;
 
val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_FMT);
-   val &= layer == ZYNQMP_DISP_LAYER_VID
+   val &= zynqmp_disp_layer_is_video(layer)
? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
: ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
val |= fmt->buf_fmt;
zynqmp_disp_avbuf_write(avbuf, ZYNQMP_DISP_AV_BUF_FMT, val);
 
for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {
-   unsigned int reg = layer == ZYNQMP_DISP_LAYER_VID
+   unsigned int reg = zynqmp_disp_layer_is_video(layer)
 ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
 : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
 
@@ -573,19 +578,19 @@ static void zynqmp_disp_avbuf_disable_audio(struct 
zynqmp_disp_avbuf *avbuf)
 /**
  * zynqmp_disp_avbuf_enable_video - Enable a video layer
  * @avbuf: Audio/video buffer manager
- * @layer: The layer ID
+ * @layer: The layer
  * @mode: Operating mode of layer
  *
  * Enable the video/graphics buffer for @layer.
  */
 static void zynqmp_disp_avbuf_enable_video(struct zynqmp_disp_avbuf *avbuf,
-  enum zynqmp_disp_layer_id layer,
+  struct zynqmp_disp_layer *layer,
   enum zynqmp_disp_layer_mode mode)
 {
u32 val;
 
val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);
-   if (layer == ZYNQMP_DISP_LAYER_VID) {
+   if (zynqmp_disp_layer_is_video(layer)) {
val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
if (mode == ZYNQMP_DISP_LAYER_NONLIVE)
val |= ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MEM;
@@ -605,17 +610,17 @@ static void zynqmp_disp_avbuf_enable_video(struct 
zynqmp_disp_avbuf *avbuf,
 /**
  * zynqmp_disp_avbuf_disable_video - Disable a video layer
  * @avbuf: Audio/video buffer manager
- * @layer: The layer ID
+ * @layer: The layer
  *
  * Disable the video/graphics buffer for @layer.
  */
 static void zynqmp_disp_avbuf_disable_video(struct zynqmp_disp_avbuf *avbuf,
-   enum zynqmp_disp_layer_id layer)
+   struct zynqmp_disp_layer *layer)
 {
u32 val;
 
val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_OUTPUT);
-   if (layer == ZYNQMP_DISP_LAYER_VID) {
+   if (zynqmp_disp_layer_is_video(layer)) {
val &= ~ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_MASK;
val |= ZYNQMP_DISP_AV_BUF_OUTPUT_VID1_NONE;
} else {
@@ -807,7 +812,7 @@ static void zynqmp_disp_blend_layer_set_csc(struct 
zynqmp_disp_blend *blend,
}
}
 
-   if (layer->id == ZYNQMP_DISP_LAYER_VID)
+   if (zynqmp_disp_layer_is_video(layer))
reg = ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF(0);
else
reg = ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF(0);
@@ -818,7 +823,7 @@ static void zynqmp_disp_blend_layer_set_csc(struct 
zynqmp_disp_blend *blend,
zynqmp_disp_blend_write(blend, reg + 8, coeffs[i + swap[2]]);
}
 
-   if (layer->id == ZYNQMP_DISP_LAYER_VID)
+   if (zynqmp_disp_layer_is_video(layer))
reg = ZYNQMP_DISP_V_BLEND_IN1CSC_OFFSET(0);
else
reg = ZYNQMP_DISP_V_BLEND_IN2CSC_OFFSET(0);
@@ -1025,7 +1030,7 @@ zynqmp_disp_layer_find_format(struct zynqmp_disp_layer 
*layer,
  */
 static void zynqmp

Re: [PATCH] dma-buf: fix unintended pin/unpin warnings

[Christian König]

Am 17.05.21 um 16:57 schrieb Daniel Vetter:

On Mon, May 17, 2021 at 10:09:13AM -0400, Alex Deucher wrote:

On Mon, May 17, 2021 at 7:57 AM Christian König
 wrote:

DMA-buf internal users call the pin/unpin functions without having a
dynamic attachment. Avoid the warning and backtrace in the logs.

Signed-off-by: Christian König 
Bugs: https://gitlab.freedesktop.org/drm/intel/-/issues/3481
Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
CC: sta...@kernel.org

Reviewed-by: Alex Deucher 

Hm this means we're losing the dma_resv_assert_held check, do we have that
in amdgpu callbacks to make sure we're not accidentally breaking stuff
later on?


Mhm, well this is just for calling the pin/unpin internally from the 
DMA-buf framework itself.


Need to double check, but I think all those cases either have a 
dma_resv_assert_held() or are locking the reservation themselves before 
calling the function.


But yeah, rather good point.

Christian.



But yeah lgtm, Reviewed-by: Daniel Vetter 


---
  drivers/dma-buf/dma-buf.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..eadd1eaa2fb5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -760,7 +760,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,

 if (dma_buf_is_dynamic(attach->dmabuf)) {
 dma_resv_lock(attach->dmabuf->resv, NULL);
-   ret = dma_buf_pin(attach);
+   ret = dmabuf->ops->pin(attach);
 if (ret)
 goto err_unlock;
 }
@@ -786,7 +786,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,

  err_unpin:
 if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_buf_unpin(attach);
+   dmabuf->ops->unpin(attach);

  err_unlock:
 if (dma_buf_is_dynamic(attach->dmabuf))
@@ -843,7 +843,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
dma_buf_attachment *attach)
 __unmap_dma_buf(attach, attach->sgt, attach->dir);

 if (dma_buf_is_dynamic(attach->dmabuf)) {
-   dma_buf_unpin(attach);
+   dmabuf->ops->unpin(attach);
 dma_resv_unlock(attach->dmabuf->resv);
 }
 }
@@ -956,7 +956,7 @@ struct sg_table *dma_buf_map_attachment(struct 
dma_buf_attachment *attach,
 if (dma_buf_is_dynamic(attach->dmabuf)) {
 dma_resv_assert_held(attach->dmabuf->resv);
 if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
-   r = dma_buf_pin(attach);
+   r = attach->dmabuf->ops->pin(attach);
 if (r)
 return ERR_PTR(r);
 }
@@ -968,7 +968,7 @@ struct sg_table *dma_buf_map_attachment(struct 
dma_buf_attachment *attach,

 if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) &&
  !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
-   dma_buf_unpin(attach);
+   attach->dmabuf->ops->unpin(attach);

 if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
 attach->sgt = sg_table;
--
2.25.1

[PATCH] drm: xlnx: zynqmp_dpsub: Pass disp structure to all internal functions

[Laurent Pinchart]

The internal functions dealing with the audio/video buffer manager, the
blender, and the audio mixer, all receive pointers to the respective
objects. Those objects are embedded in the zynqmp_disp structure, and a
very small. Treating them as separate objects would require expanding
them with back-pointers to the zynqmp_disp in order to access fields
such as the device pointer for debug messages, and this isn't worth it.

Instead, merge those structures with the zynqmp_disp structure, and pass
the zynqmp_disp pointer to all internal functions.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 266 +
 1 file changed, 121 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index a578ab3d5f89..a061a75a9de7 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -158,43 +158,17 @@ struct zynqmp_disp_layer {
enum zynqmp_disp_layer_mode mode;
 };
 
-/**
- * struct zynqmp_disp_blend - Blender
- * @base: Registers I/O base address
- */
-struct zynqmp_disp_blend {
-   void __iomem *base;
-};
-
-/**
- * struct zynqmp_disp_avbuf - Audio/video buffer manager
- * @base: Registers I/O base address
- */
-struct zynqmp_disp_avbuf {
-   void __iomem *base;
-};
-
-/**
- * struct zynqmp_disp_audio - Audio mixer
- * @base: Registers I/O base address
- * @clk: Audio clock
- * @clk_from_ps: True of the audio clock comes from PS, false from PL
- */
-struct zynqmp_disp_audio {
-   void __iomem *base;
-   struct clk *clk;
-   bool clk_from_ps;
-};
-
 /**
  * struct zynqmp_disp - Display controller
  * @dev: Device structure
  * @drm: DRM core
  * @dpsub: Display subsystem
  * @crtc: DRM CRTC
- * @blend: Blender (video rendering pipeline)
- * @avbuf: Audio/video buffer manager
- * @audio: Audio mixer
+ * @blend.base: Register I/O base address for the blender
+ * @avbuf.base: Register I/O base address for the audio/video buffer manager
+ * @audio.base: Registers I/O base address for the audio mixer
+ * @audio.clk: Audio clock
+ * @audio.clk_from_ps: True of the audio clock comes from PS, false from PL
  * @layers: Layers (planes)
  * @event: Pending vblank event request
  * @pclk: Pixel clock
@@ -207,9 +181,17 @@ struct zynqmp_disp {
 
struct drm_crtc crtc;
 
-   struct zynqmp_disp_blend blend;
-   struct zynqmp_disp_avbuf avbuf;
-   struct zynqmp_disp_audio audio;
+   struct {
+   void __iomem *base;
+   } blend;
+   struct {
+   void __iomem *base;
+   } avbuf;
+   struct {
+   void __iomem *base;
+   struct clk *clk;
+   bool clk_from_ps;
+   } audio;
 
struct zynqmp_disp_layer layers[ZYNQMP_DISP_NUM_LAYERS];
 
@@ -423,15 +405,14 @@ static const struct zynqmp_disp_format avbuf_gfx_fmts[] = 
{
},
 };
 
-static u32 zynqmp_disp_avbuf_read(struct zynqmp_disp_avbuf *avbuf, int reg)
+static u32 zynqmp_disp_avbuf_read(struct zynqmp_disp *disp, int reg)
 {
-   return readl(avbuf->base + reg);
+   return readl(disp->avbuf.base + reg);
 }
 
-static void zynqmp_disp_avbuf_write(struct zynqmp_disp_avbuf *avbuf,
-   int reg, u32 val)
+static void zynqmp_disp_avbuf_write(struct zynqmp_disp *disp, int reg, u32 val)
 {
-   writel(val, avbuf->base + reg);
+   writel(val, disp->avbuf.base + reg);
 }
 
 static bool zynqmp_disp_layer_is_video(const struct zynqmp_disp_layer *layer)
@@ -441,38 +422,38 @@ static bool zynqmp_disp_layer_is_video(const struct 
zynqmp_disp_layer *layer)
 
 /**
  * zynqmp_disp_avbuf_set_format - Set the input format for a layer
- * @avbuf: Audio/video buffer manager
+ * @disp: Display controller
  * @layer: The layer
  * @fmt: The format information
  *
  * Set the video buffer manager format for @layer to @fmt.
  */
-static void zynqmp_disp_avbuf_set_format(struct zynqmp_disp_avbuf *avbuf,
+static void zynqmp_disp_avbuf_set_format(struct zynqmp_disp *disp,
 struct zynqmp_disp_layer *layer,
 const struct zynqmp_disp_format *fmt)
 {
unsigned int i;
u32 val;
 
-   val = zynqmp_disp_avbuf_read(avbuf, ZYNQMP_DISP_AV_BUF_FMT);
+   val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
val &= zynqmp_disp_layer_is_video(layer)
? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
: ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
val |= fmt->buf_fmt;
-   zynqmp_disp_avbuf_write(avbuf, ZYNQMP_DISP_AV_BUF_FMT, val);
+   zynqmp_disp_avbuf_write(disp, ZYNQMP_DISP_AV_BUF_FMT, val);
 
for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {
unsigned int reg = zynqmp_disp_layer_is_video(layer)
 ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
 : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
 
-   zy

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave & Daniel -

drm-intel-fixes-2021-05-20:
drm/i915 fixes for v5.13-rc3:
- Pin the L-shape quirked object as unshrinkable to fix crashes
- Disable HiZ Raw Stall Optimization on broken gen7 to fix glitches, gfx 
corruption
- GVT: Move mdev attribute groups into kvmgt module to fix kconfig deps issue

BR,
Jani.

The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc:

  Linux 5.13-rc2 (2021-05-16 15:27:44 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-05-20

for you to fetch changes up to eddd1b8f467f82b8e9e137ef9dbaa842ecca6a2c:

  Merge tag 'gvt-fixes-2021-05-19' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2021-05-19 11:22:24 +0300)


drm/i915 fixes for v5.13-rc3:
- Pin the L-shape quirked object as unshrinkable to fix crashes
- Disable HiZ Raw Stall Optimization on broken gen7 to fix glitches, gfx 
corruption
- GVT: Move mdev attribute groups into kvmgt module to fix kconfig deps issue


Chris Wilson (1):
  drm/i915/gem: Pin the L-shape quirked object as unshrinkable

Jani Nikula (1):
  Merge tag 'gvt-fixes-2021-05-19' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Simon Rettberg (1):
  drm/i915/gt: Disable HiZ Raw Stall Optimization on broken gen7

Zhenyu Wang (1):
  drm/i915/gvt: Move mdev attribute groups into kvmgt module

 drivers/gpu/drm/i915/Kconfig   |   1 -
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   2 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c |   5 +-
 drivers/gpu/drm/i915/gvt/gvt.c | 124 +
 drivers/gpu/drm/i915/gvt/gvt.h |   3 -
 drivers/gpu/drm/i915/gvt/hypercall.h   |   2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 122 +---
 drivers/gpu/drm/i915/gvt/mpt.h |   4 +-
 drivers/gpu/drm/i915/i915_gem.c|  11 ++-
 9 files changed, 129 insertions(+), 145 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

[PATCH 00/38] Rid W=1 warnings from GPU

[Lee Jones]

This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

Lee Jones (38):
  drm/mediatek/mtk_disp_color: Strip incorrect doc and demote header
  drm/mediatek/mtk_disp_gamma: Strip and demote non-conformant
kernel-doc header
  drm/radeon/radeon_cs: Fix incorrectly documented function
'radeon_cs_parser_fini'
  drm/mediatek/mtk_disp_ovl: Strip and demote non-conformant header
  drm/mediatek/mtk_disp_rdma: Strip and demote non-conformant kernel-doc
header
  drm/sti/sti_hdmi_tx3g4c28phy: Provide function names for kernel-doc
headers
  drm/sti/sti_hda: Provide missing function names
  drm/sti/sti_tvout: Provide a bunch of missing function names
  drm/sti/sti_hqvdp: Fix incorrectly named function 'sti_hqvdp_vtg_cb()'
  drm/amd/amdgpu/amdgpu_ids: Correct some function name disparity
  drm/amd/amdgpu/amdgpu_debugfs: Fix a couple of misnamed functions
  drm/amd/amdgpu/amdgpu_gmc: Fix a little naming related doc-rot
  drm/amd/amdgpu/cik_sdma: Fix a few incorrectly named functions
  drm/amd/amdgpu/gfx_v7_0: Repair function names in the documentation
  drm/msm/disp/dpu1/dpu_encoder_phys_cmd: Remove unused variable
'cmd_enc'
  drm/amd/amdgpu/si_dma: Fix some function name disparity
  drm/amd/amdgpu/dce_v6_0: Repair function name of
'si_get_number_of_dram_channels()'
  drm/msm/disp/dpu1/dpu_hw_interrupts: Demote a bunch of kernel-doc
abuses
  drm/radeon/cik: Fix incorrectly named function 'cik_irq_suspend()'
  drm/radeon/radeon_vm: Fix function naming disparities
  drm/amd/include/aldebaran_ip_offset: Mark top-level IP_BASE as
__maybe_unused
  drm/msm/disp/dpu1/dpu_plane: Fix a couple of naming issues
  drm/amd/amdgpu/gmc_v7_0: Fix potential copy/paste issue
  drm/amd/amdgpu/mmhub_v9_4: Fix naming disparity with
'mmhub_v9_4_set_fault_enable_default()'
  drm/msm/msm_gem: Demote kernel-doc abuses
  drm/amd/amdgpu/gmc_v10_0: Fix potential copy/paste issue
  drm/msm/dp/dp_catalog: Correctly document param 'dp_catalog'
  drm/msm/dp/dp_link: Fix some potential doc-rot
  drm/radeon/r100: Realign doc header with function
'r100_cs_packet_parse_vline()'
  drm/amd/amdgpu/gfx_v9_4_2: Mark functions called by reference as
static
  drm/amd/amdgpu/sdma_v2_4: Correct misnamed function
'sdma_v2_4_ring_emit_hdp_flush()'
  drm/amd/amdgpu/sdma_v4_0: Realign functions with their headers
  drm/amd/amdgpu/sdma_v5_0: Fix typo in function name
  drm/amd/amdgpu/amdgpu_vce: Fix a few incorrectly named functions
  drm/amd/amdgpu/sdma_v5_2: Repair typo in function name
  drm/amd/amdgpu/vcn_v1_0: Fix some function naming disparity
  drm/amd/amdgpu/gfx_v10_0: Demote kernel-doc abuse
  drm/amd/amdgpu/smuio_v13_0: Realign
'smuio_v13_0_is_host_gpu_xgmi_supported()' header

 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c   |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  8 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   | 10 +++---
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c |  8 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c |  6 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c   | 14 
 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c|  4 +--
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/si_dma.c   |  6 ++--
 drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c |  4 +--
 .../gpu/drm/amd/include/aldebaran_ip_offset.h |  2 +-
 drivers/gpu/drm/mediatek/mtk_disp_color.c |  3 +-
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c |  4 +--
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c   |  3 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c  |  4 +--
 .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  4 ---
 .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 32 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  4 +--
 drivers/gpu/drm/msm/dp/dp_catalog.c   |  2 +-
 drivers/gpu/drm/msm/dp/dp_link.c  |  6 ++--
 drivers/gpu/drm/msm/msm_gem.c |  4 +--
 drivers/gpu/drm/radeon/cik.c  |  2 +-
 drivers/gpu/drm/radeon/r100.c |  2 +-
 drivers/gpu/drm/radeon/radeon_cs.c|  2 +-
 drivers/gpu/drm/radeon/radeon_vm.c|  4 +--
 drivers/gpu/drm/sti/sti_hda.c |  6 ++--
 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c|  4 +--
 drivers/gpu/drm/sti/sti_hqvdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_tvout.c   | 18 +--
 38 files changed, 92 insertio

[PATCH 02/38] drm/mediatek/mtk_disp_gamma: Strip and demote non-conformant kernel-doc header

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or 
member 'clk' not described in 'mtk_disp_gamma'
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or 
member 'regs' not described in 'mtk_disp_gamma'
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or 
member 'cmdq_reg' not described in 'mtk_disp_gamma'
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c:42: warning: Function parameter or 
member 'data' not described in 'mtk_disp_gamma'

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 3ebf91e0ab412..3a5815ab40795 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -29,10 +29,8 @@ struct mtk_disp_gamma_data {
bool has_dither;
 };
 
-/**
+/*
  * struct mtk_disp_gamma - DISP_GAMMA driver structure
- * @ddp_comp - structure containing type enum and hardware resources
- * @crtc - associated crtc to report irq events to
  */
 struct mtk_disp_gamma {
struct clk *clk;
-- 
2.31.1

[PATCH 01/38] drm/mediatek/mtk_disp_color: Strip incorrect doc and demote header

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_disp_color.c:45: warning: Function parameter or 
member 'clk' not described in 'mtk_disp_color'
 drivers/gpu/drm/mediatek/mtk_disp_color.c:45: warning: Function parameter or 
member 'regs' not described in 'mtk_disp_color'
 drivers/gpu/drm/mediatek/mtk_disp_color.c:45: warning: Function parameter or 
member 'cmdq_reg' not described in 'mtk_disp_color'

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/mediatek/mtk_disp_color.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c 
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 63f411ab393b7..6f4c80bbc0eb6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -30,9 +30,8 @@ struct mtk_disp_color_data {
unsigned int color_offset;
 };
 
-/**
+/*
  * struct mtk_disp_color - DISP_COLOR driver structure
- * @ddp_comp: structure containing type enum and hardware resources
  * @crtc: associated crtc to report irq events to
  * @data: platform colour driver data
  */
-- 
2.31.1

[PATCH 04/38] drm/mediatek/mtk_disp_ovl: Strip and demote non-conformant header

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or 
member 'clk' not described in 'mtk_disp_ovl'
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or 
member 'regs' not described in 'mtk_disp_ovl'
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or 
member 'cmdq_reg' not described in 'mtk_disp_ovl'
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or 
member 'vblank_cb' not described in 'mtk_disp_ovl'
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c:83: warning: Function parameter or 
member 'vblank_cb_data' not described in 'mtk_disp_ovl'

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 961f87f8d4d15..fa9d79963cd34 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -66,9 +66,8 @@ struct mtk_disp_ovl_data {
bool smi_id_en;
 };
 
-/**
+/*
  * struct mtk_disp_ovl - DISP_OVL driver structure
- * @ddp_comp: structure containing type enum and hardware resources
  * @crtc: associated crtc to report vblank events to
  * @data: platform data
  */
-- 
2.31.1

[PATCH 03/38] drm/radeon/radeon_cs: Fix incorrectly documented function 'radeon_cs_parser_fini'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/radeon_cs.c:417: warning: expecting prototype for 
cs_parser_fini(). Prototype was for radeon_cs_parser_fini() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Jerome Glisse 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 48162501c1ee6..80a3bee933d6d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -405,7 +405,7 @@ static int cmp_size_smaller_first(void *priv, const struct 
list_head *a,
 }
 
 /**
- * cs_parser_fini() - clean parser states
+ * radeon_cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
  * @error: error number
  * @backoff:   indicator to backoff the reservation
-- 
2.31.1

[PATCH 06/38] drm/sti/sti_hdmi_tx3g4c28phy: Provide function names for kernel-doc headers

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c:77: warning: expecting prototype 
for Start hdmi phy macro cell tx3g4c28(). Prototype was for 
sti_hdmi_tx3g4c28phy_start() instead
 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c:187: warning: expecting prototype 
for Stop hdmi phy macro cell tx3g4c28(). Prototype was for 
sti_hdmi_tx3g4c28phy_stop() instead

Cc: Benjamin Gaignard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Vincent Abriou 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c 
b/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
index d5f94dca0d323..d25ecd4f4b673 100644
--- a/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
+++ b/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
@@ -67,7 +67,7 @@ static struct hdmi_phy_config 
hdmiphy_config[NB_HDMI_PHY_CONFIG] = {
 };
 
 /**
- * Start hdmi phy macro cell tx3g4c28
+ * sti_hdmi_tx3g4c28phy_start - Start hdmi phy macro cell tx3g4c28
  *
  * @hdmi: pointer on the hdmi internal structure
  *
@@ -179,7 +179,7 @@ static bool sti_hdmi_tx3g4c28phy_start(struct sti_hdmi 
*hdmi)
 }
 
 /**
- * Stop hdmi phy macro cell tx3g4c28
+ * sti_hdmi_tx3g4c28phy_stop - Stop hdmi phy macro cell tx3g4c28
  *
  * @hdmi: pointer on the hdmi internal structure
  */
-- 
2.31.1

[PATCH 07/38] drm/sti/sti_hda: Provide missing function names

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/sti/sti_hda.c:283: warning: expecting prototype for Search for 
a video mode in the supported modes table(). Prototype was for 
hda_get_mode_idx() instead
 drivers/gpu/drm/sti/sti_hda.c:301: warning: expecting prototype for Enable the 
HD DACS(). Prototype was for hda_enable_hd_dacs() instead
 drivers/gpu/drm/sti/sti_hda.c:383: warning: This comment starts with '/**', 
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst

Cc: Benjamin Gaignard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Fabien Dessenne 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/sti/sti_hda.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 5c2b650b561d5..03f3377f918c0 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -272,7 +272,7 @@ static void hda_write(struct sti_hda *hda, u32 val, int 
offset)
 }
 
 /**
- * Search for a video mode in the supported modes table
+ * hda_get_mode_idx - Search for a video mode in the supported modes table
  *
  * @mode: mode being searched
  * @idx: index of the found mode
@@ -292,7 +292,7 @@ static bool hda_get_mode_idx(struct drm_display_mode mode, 
int *idx)
 }
 
 /**
- * Enable the HD DACS
+ * hda_enable_hd_dacs - Enable the HD DACS
  *
  * @hda: pointer to HD analog structure
  * @enable: true if HD DACS need to be enabled, else false
@@ -380,7 +380,7 @@ static void hda_debugfs_init(struct sti_hda *hda, struct 
drm_minor *minor)
 }
 
 /**
- * Configure AWG, writing instructions
+ * sti_hda_configure_awg - Configure AWG, writing instructions
  *
  * @hda: pointer to HD analog structure
  * @awg_instr: pointer to AWG instructions table
-- 
2.31.1

[PATCH 08/38] drm/sti/sti_tvout: Provide a bunch of missing function names

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/sti/sti_tvout.c:166: warning: expecting prototype for Set the 
clipping mode of a VIP(). Prototype was for tvout_vip_set_color_order() instead
 drivers/gpu/drm/sti/sti_tvout.c:187: warning: expecting prototype for Set the 
clipping mode of a VIP(). Prototype was for tvout_vip_set_clip_mode() instead
 drivers/gpu/drm/sti/sti_tvout.c:203: warning: expecting prototype for Set the 
rounded value of a VIP(). Prototype was for tvout_vip_set_rnd() instead
 drivers/gpu/drm/sti/sti_tvout.c:223: warning: expecting prototype for Select 
the VIP input(). Prototype was for tvout_vip_set_sel_input() instead
 drivers/gpu/drm/sti/sti_tvout.c:258: warning: expecting prototype for Select 
the input video signed or unsigned(). Prototype was for 
tvout_vip_set_in_vid_fmt() instead
 drivers/gpu/drm/sti/sti_tvout.c:274: warning: expecting prototype for Set 
preformatter matrix(). Prototype was for tvout_preformatter_set_matrix() instead
 drivers/gpu/drm/sti/sti_tvout.c:299: warning: expecting prototype for Start 
VIP block for DVO output(). Prototype was for tvout_dvo_start() instead
 drivers/gpu/drm/sti/sti_tvout.c:353: warning: expecting prototype for Start 
VIP block for HDMI output(). Prototype was for tvout_hdmi_start() instead
 drivers/gpu/drm/sti/sti_tvout.c:402: warning: expecting prototype for Start 
HDF VIP and HD DAC(). Prototype was for tvout_hda_start() instead

Cc: Benjamin Gaignard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Philipp Zabel 
Cc: Vincent Abriou 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/sti/sti_tvout.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index df3817f0fd302..2499715a69b79 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -153,7 +153,7 @@ static void tvout_write(struct sti_tvout *tvout, u32 val, 
int offset)
 }
 
 /**
- * Set the clipping mode of a VIP
+ * tvout_vip_set_color_order - Set the clipping mode of a VIP
  *
  * @tvout: tvout structure
  * @reg: register to set
@@ -177,7 +177,7 @@ static void tvout_vip_set_color_order(struct sti_tvout 
*tvout, int reg,
 }
 
 /**
- * Set the clipping mode of a VIP
+ * tvout_vip_set_clip_mode - Set the clipping mode of a VIP
  *
  * @tvout: tvout structure
  * @reg: register to set
@@ -193,7 +193,7 @@ static void tvout_vip_set_clip_mode(struct sti_tvout 
*tvout, int reg, u32 range)
 }
 
 /**
- * Set the rounded value of a VIP
+ * tvout_vip_set_rnd - Set the rounded value of a VIP
  *
  * @tvout: tvout structure
  * @reg: register to set
@@ -209,7 +209,7 @@ static void tvout_vip_set_rnd(struct sti_tvout *tvout, int 
reg, u32 rnd)
 }
 
 /**
- * Select the VIP input
+ * tvout_vip_set_sel_input - Select the VIP input
  *
  * @tvout: tvout structure
  * @reg: register to set
@@ -247,7 +247,7 @@ static void tvout_vip_set_sel_input(struct sti_tvout *tvout,
 }
 
 /**
- * Select the input video signed or unsigned
+ * tvout_vip_set_in_vid_fmt - Select the input video signed or unsigned
  *
  * @tvout: tvout structure
  * @reg: register to set
@@ -264,7 +264,7 @@ static void tvout_vip_set_in_vid_fmt(struct sti_tvout 
*tvout,
 }
 
 /**
- * Set preformatter matrix
+ * tvout_preformatter_set_matrix - Set preformatter matrix
  *
  * @tvout: tvout structure
  * @mode: display mode structure
@@ -289,7 +289,7 @@ static void tvout_preformatter_set_matrix(struct sti_tvout 
*tvout,
 }
 
 /**
- * Start VIP block for DVO output
+ * tvout_dvo_start - Start VIP block for DVO output
  *
  * @tvout: pointer on tvout structure
  * @main_path: true if main path has to be used in the vip configuration
@@ -343,7 +343,7 @@ static void tvout_dvo_start(struct sti_tvout *tvout, bool 
main_path)
 }
 
 /**
- * Start VIP block for HDMI output
+ * tvout_hdmi_start - Start VIP block for HDMI output
  *
  * @tvout: pointer on tvout structure
  * @main_path: true if main path has to be used in the vip configuration
@@ -392,7 +392,7 @@ static void tvout_hdmi_start(struct sti_tvout *tvout, bool 
main_path)
 }
 
 /**
- * Start HDF VIP and HD DAC
+ * tvout_hda_start - Start HDF VIP and HD DAC
  *
  * @tvout: pointer on tvout structure
  * @main_path: true if main path has to be used in the vip configuration
-- 
2.31.1

[PATCH 12/38] drm/amd/amdgpu/amdgpu_gmc: Fix a little naming related doc-rot

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:487: warning: expecting prototype for 
amdgpu_tmz_set(). Prototype was for amdgpu_gmc_tmz_set() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:533: warning: expecting prototype for 
amdgpu_noretry_set(). Prototype was for amdgpu_gmc_noretry_set() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index a129ecc738693..58feb0a422c34 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -528,7 +528,7 @@ int amdgpu_gmc_allocate_vm_inv_eng(struct amdgpu_device 
*adev)
 }
 
 /**
- * amdgpu_tmz_set -- check and set if a device supports TMZ
+ * amdgpu_gmc_tmz_set -- check and set if a device supports TMZ
  * @adev: amdgpu_device pointer
  *
  * Check and set if an the device @adev supports Trusted Memory
@@ -574,7 +574,7 @@ void amdgpu_gmc_tmz_set(struct amdgpu_device *adev)
 }
 
 /**
- * amdgpu_noretry_set -- set per asic noretry defaults
+ * amdgpu_gmc_noretry_set -- set per asic noretry defaults
  * @adev: amdgpu_device pointer
  *
  * Set a per asic default for the no-retry parameter.
-- 
2.31.1

[PATCH 09/38] drm/sti/sti_hqvdp: Fix incorrectly named function 'sti_hqvdp_vtg_cb()'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/sti/sti_hqvdp.c:796: warning: expecting prototype for 
sti_vdp_vtg_cb(). Prototype was for sti_hqvdp_vtg_cb() instead

Cc: Benjamin Gaignard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Philipp Zabel 
Cc: Fabien Dessenne 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index edbb99f53de19..d09b08995b12a 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -782,7 +782,7 @@ static void sti_hqvdp_disable(struct sti_hqvdp *hqvdp)
 }
 
 /**
- * sti_vdp_vtg_cb
+ * sti_hqvdp_vtg_cb
  * @nb: notifier block
  * @evt: event message
  * @data: private data
-- 
2.31.1

[PATCH 11/38] drm/amd/amdgpu/amdgpu_debugfs: Fix a couple of misnamed functions

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1004: warning: expecting prototype 
for amdgpu_debugfs_regs_gfxoff_write(). Prototype was for 
amdgpu_debugfs_gfxoff_write() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1053: warning: expecting prototype 
for amdgpu_debugfs_regs_gfxoff_status(). Prototype was for 
amdgpu_debugfs_gfxoff_read() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index bcaf271b39bf5..a9bbb0034e1ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -990,7 +990,7 @@ static ssize_t amdgpu_debugfs_gpr_read(struct file *f, char 
__user *buf,
 }
 
 /**
- * amdgpu_debugfs_regs_gfxoff_write - Enable/disable GFXOFF
+ * amdgpu_debugfs_gfxoff_write - Enable/disable GFXOFF
  *
  * @f: open file handle
  * @buf: User buffer to write data from
@@ -1041,7 +1041,7 @@ static ssize_t amdgpu_debugfs_gfxoff_write(struct file 
*f, const char __user *bu
 
 
 /**
- * amdgpu_debugfs_regs_gfxoff_status - read gfxoff status
+ * amdgpu_debugfs_gfxoff_read - read gfxoff status
  *
  * @f: open file handle
  * @buf: User buffer to store read data in
-- 
2.31.1

[PATCH 19/38] drm/radeon/cik: Fix incorrectly named function 'cik_irq_suspend()'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/cik.c:7450: warning: expecting prototype for 
cik_irq_disable(). Prototype was for cik_irq_suspend() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/cik.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 42a8afa839cbb..73ea5189dfb1a 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7439,7 +7439,7 @@ static void cik_irq_disable(struct radeon_device *rdev)
 }
 
 /**
- * cik_irq_disable - disable interrupts for suspend
+ * cik_irq_suspend - disable interrupts for suspend
  *
  * @rdev: radeon_device pointer
  *
-- 
2.31.1

[PATCH 17/38] drm/amd/amdgpu/dce_v6_0: Repair function name of 'si_get_number_of_dram_channels()'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:468: warning: expecting prototype for 
cik_get_number_of_dram_channels(). Prototype was for 
si_get_number_of_dram_channels() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Luben Tuikov 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index dbcb09cf83e63..c7803dc2b2d53 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -456,7 +456,7 @@ static void dce_v6_0_program_fmt(struct drm_encoder 
*encoder)
 }
 
 /**
- * cik_get_number_of_dram_channels - get the number of dram channels
+ * si_get_number_of_dram_channels - get the number of dram channels
  *
  * @adev: amdgpu_device pointer
  *
-- 
2.31.1

[PATCH 14/38] drm/amd/amdgpu/gfx_v7_0: Repair function names in the documentation

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2126: warning: expecting prototype for 
gfx_v7_0_ring_emit_hdp(). Prototype was for gfx_v7_0_ring_emit_hdp_flush() 
instead
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2262: warning: expecting prototype for 
gfx_v7_0_ring_emit_ib(). Prototype was for gfx_v7_0_ring_emit_ib_gfx() instead
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3207: warning: expecting prototype for 
gfx_v7_0_ring_emit_vm_flush(). Prototype was for 
gfx_v7_0_ring_emit_pipeline_sync() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index c35fdd2ef2d4d..685212c3ddae5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -2116,7 +2116,7 @@ static int gfx_v7_0_ring_test_ring(struct amdgpu_ring 
*ring)
 }
 
 /**
- * gfx_v7_0_ring_emit_hdp - emit an hdp flush on the cp
+ * gfx_v7_0_ring_emit_hdp_flush - emit an hdp flush on the cp
  *
  * @ring: amdgpu_ring structure holding ring information
  *
@@ -2242,7 +2242,7 @@ static void gfx_v7_0_ring_emit_fence_compute(struct 
amdgpu_ring *ring,
  * IB stuff
  */
 /**
- * gfx_v7_0_ring_emit_ib - emit an IB (Indirect Buffer) on the ring
+ * gfx_v7_0_ring_emit_ib_gfx - emit an IB (Indirect Buffer) on the ring
  *
  * @ring: amdgpu_ring structure holding ring information
  * @job: job to retrieve vmid from
@@ -3196,7 +3196,7 @@ static int gfx_v7_0_cp_resume(struct amdgpu_device *adev)
 }
 
 /**
- * gfx_v7_0_ring_emit_vm_flush - cik vm flush using the CP
+ * gfx_v7_0_ring_emit_pipeline_sync - cik vm flush using the CP
  *
  * @ring: the ring to emit the commands to
  *
-- 
2.31.1

[PATCH 13/38] drm/amd/amdgpu/cik_sdma: Fix a few incorrectly named functions

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:735: warning: expecting prototype for 
cik_sdma_vm_copy_pages(). Prototype was for cik_sdma_vm_copy_pte() instead
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:762: warning: expecting prototype for 
cik_sdma_vm_write_pages(). Prototype was for cik_sdma_vm_write_pte() instead
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:792: warning: expecting prototype for 
cik_sdma_vm_set_pages(). Prototype was for cik_sdma_vm_set_pte_pde() instead
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:814: warning: expecting prototype for 
cik_sdma_vm_pad_ib(). Prototype was for cik_sdma_ring_pad_ib() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Evan Quan 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
index c4bb8eed246d6..c8ebd108548d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
@@ -720,7 +720,7 @@ static int cik_sdma_ring_test_ib(struct amdgpu_ring *ring, 
long timeout)
 }
 
 /**
- * cik_sdma_vm_copy_pages - update PTEs by copying them from the GART
+ * cik_sdma_vm_copy_pte - update PTEs by copying them from the GART
  *
  * @ib: indirect buffer to fill with commands
  * @pe: addr of the page entry
@@ -746,7 +746,7 @@ static void cik_sdma_vm_copy_pte(struct amdgpu_ib *ib,
 }
 
 /**
- * cik_sdma_vm_write_pages - update PTEs by writing them manually
+ * cik_sdma_vm_write_pte - update PTEs by writing them manually
  *
  * @ib: indirect buffer to fill with commands
  * @pe: addr of the page entry
@@ -775,7 +775,7 @@ static void cik_sdma_vm_write_pte(struct amdgpu_ib *ib, 
uint64_t pe,
 }
 
 /**
- * cik_sdma_vm_set_pages - update the page tables using sDMA
+ * cik_sdma_vm_set_pte_pde - update the page tables using sDMA
  *
  * @ib: indirect buffer to fill with commands
  * @pe: addr of the page entry
@@ -804,7 +804,7 @@ static void cik_sdma_vm_set_pte_pde(struct amdgpu_ib *ib, 
uint64_t pe,
 }
 
 /**
- * cik_sdma_vm_pad_ib - pad the IB to the required number of dw
+ * cik_sdma_ring_pad_ib - pad the IB to the required number of dw
  *
  * @ring: amdgpu_ring structure holding ring information
  * @ib: indirect buffer to fill with padding
-- 
2.31.1

[PATCH 10/38] drm/amd/amdgpu/amdgpu_ids: Correct some function name disparity

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:200: warning: expecting prototype for 
amdgpu_vm_grab_idle(). Prototype was for amdgpu_vmid_grab_idle() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:272: warning: expecting prototype for 
amdgpu_vm_grab_reserved(). Prototype was for amdgpu_vmid_grab_reserved() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:337: warning: expecting prototype for 
amdgpu_vm_grab_used(). Prototype was for amdgpu_vmid_grab_used() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:410: warning: expecting prototype for 
amdgpu_vm_grab_id(). Prototype was for amdgpu_vmid_grab() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index b4971e90b98cf..c7f3aae23c625 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -183,7 +183,7 @@ bool amdgpu_vmid_had_gpu_reset(struct amdgpu_device *adev,
 }
 
 /**
- * amdgpu_vm_grab_idle - grab idle VMID
+ * amdgpu_vmid_grab_idle - grab idle VMID
  *
  * @vm: vm to allocate id for
  * @ring: ring we want to submit job to
@@ -256,7 +256,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm,
 }
 
 /**
- * amdgpu_vm_grab_reserved - try to assign reserved VMID
+ * amdgpu_vmid_grab_reserved - try to assign reserved VMID
  *
  * @vm: vm to allocate id for
  * @ring: ring we want to submit job to
@@ -325,7 +325,7 @@ static int amdgpu_vmid_grab_reserved(struct amdgpu_vm *vm,
 }
 
 /**
- * amdgpu_vm_grab_used - try to reuse a VMID
+ * amdgpu_vmid_grab_used - try to reuse a VMID
  *
  * @vm: vm to allocate id for
  * @ring: ring we want to submit job to
@@ -397,7 +397,7 @@ static int amdgpu_vmid_grab_used(struct amdgpu_vm *vm,
 }
 
 /**
- * amdgpu_vm_grab_id - allocate the next free VMID
+ * amdgpu_vmid_grab - allocate the next free VMID
  *
  * @vm: vm to allocate id for
  * @ring: ring we want to submit job to
-- 
2.31.1

[PATCH 05/38] drm/mediatek/mtk_disp_rdma: Strip and demote non-conformant kernel-doc header

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or 
member 'clk' not described in 'mtk_disp_rdma'
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or 
member 'regs' not described in 'mtk_disp_rdma'
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or 
member 'cmdq_reg' not described in 'mtk_disp_rdma'
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or 
member 'vblank_cb' not described in 'mtk_disp_rdma'
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or 
member 'vblank_cb_data' not described in 'mtk_disp_rdma'
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c:72: warning: Function parameter or 
member 'fifo_size' not described in 'mtk_disp_rdma'

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 728aaadfea8cf..705f28ceb4ddd 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -55,10 +55,8 @@ struct mtk_disp_rdma_data {
unsigned int fifo_size;
 };
 
-/**
+/*
  * struct mtk_disp_rdma - DISP_RDMA driver structure
- * @ddp_comp: structure containing type enum and hardware resources
- * @crtc: associated crtc to report irq events to
  * @data: local driver data
  */
 struct mtk_disp_rdma {
-- 
2.31.1

[PATCH 22/38] drm/msm/disp/dpu1/dpu_plane: Fix a couple of naming issues

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:373: warning: expecting prototype 
for _dpu_plane_set_panic_lut(). Prototype was for _dpu_plane_set_danger_lut() 
instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:498: warning: expecting prototype 
for _dpu_plane_set_vbif_qos(). Prototype was for _dpu_plane_set_qos_remap() 
instead

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 7a993547eb751..ed05a7ab58f53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -364,7 +364,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
 }
 
 /**
- * _dpu_plane_set_panic_lut - set danger/safe LUT of the given plane
+ * _dpu_plane_set_danger_lut - set danger/safe LUT of the given plane
  * @plane: Pointer to drm plane
  * @fb:Pointer to framebuffer associated with the 
given plane
  */
@@ -491,7 +491,7 @@ static void _dpu_plane_set_ot_limit(struct drm_plane *plane,
 }
 
 /**
- * _dpu_plane_set_vbif_qos - set vbif QoS for the given plane
+ * _dpu_plane_set_qos_remap - set vbif QoS for the given plane
  * @plane: Pointer to drm plane
  */
 static void _dpu_plane_set_qos_remap(struct drm_plane *plane)
-- 
2.31.1

[PATCH 26/38] drm/amd/amdgpu/gmc_v10_0: Fix potential copy/paste issue

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c:955: warning: expecting prototype for 
gmc_v8_0_gart_fini(). Prototype was for gmc_v10_0_gart_fini() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index f02dc904e4cfe..105ed1bf4a88c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
@@ -947,7 +947,7 @@ static int gmc_v10_0_sw_init(void *handle)
 }
 
 /**
- * gmc_v8_0_gart_fini - vm fini callback
+ * gmc_v10_0_gart_fini - vm fini callback
  *
  * @adev: amdgpu_device pointer
  *
-- 
2.31.1

[PATCH 15/38] drm/msm/disp/dpu1/dpu_encoder_phys_cmd: Remove unused variable 'cmd_enc'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function 
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning: variable 
‘cmd_enc’ set but not used [-Wunused-but-set-variable]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: AngeloGioacchino Del Regno 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b2be39b9144e4..088900841bf8b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -685,10 +685,6 @@ static int dpu_encoder_phys_cmd_wait_for_tx_complete(
 static int dpu_encoder_phys_cmd_wait_for_commit_done(
struct dpu_encoder_phys *phys_enc)
 {
-   struct dpu_encoder_phys_cmd *cmd_enc;
-
-   cmd_enc = to_dpu_encoder_phys_cmd(phys_enc);
-
/* only required for master controller */
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return 0;
-- 
2.31.1

[PATCH 30/38] drm/amd/amdgpu/gfx_v9_4_2: Mark functions called by reference as static

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1008:5: warning: no previous prototype 
for ‘gfx_v9_4_2_query_ras_error_count’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1054:6: warning: no previous prototype 
for ‘gfx_v9_4_2_reset_ras_error_count’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1063:5: warning: no previous prototype 
for ‘gfx_v9_4_2_ras_error_inject’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1133:6: warning: no previous prototype 
for ‘gfx_v9_4_2_query_ras_error_status’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1143:6: warning: no previous prototype 
for ‘gfx_v9_4_2_reset_ras_error_status’ [-Wmissing-prototypes]
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1153:6: warning: no previous prototype 
for ‘gfx_v9_4_2_enable_watchdog_timer’ [-Wmissing-prototypes]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
index dbad9ef002d59..87ec96a18a5dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
@@ -1641,8 +1641,8 @@ static int gfx_v9_4_2_query_utc_edc_count(struct 
amdgpu_device *adev,
return 0;
 }
 
-int gfx_v9_4_2_query_ras_error_count(struct amdgpu_device *adev,
-  void *ras_error_status)
+static int gfx_v9_4_2_query_ras_error_count(struct amdgpu_device *adev,
+   void *ras_error_status)
 {
struct ras_err_data *err_data = (struct ras_err_data *)ras_error_status;
uint32_t sec_count = 0, ded_count = 0;
@@ -1690,7 +1690,7 @@ static void gfx_v9_4_2_reset_ea_err_status(struct 
amdgpu_device *adev)
mutex_unlock(&adev->grbm_idx_mutex);
 }
 
-void gfx_v9_4_2_reset_ras_error_count(struct amdgpu_device *adev)
+static void gfx_v9_4_2_reset_ras_error_count(struct amdgpu_device *adev)
 {
if (!amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__GFX))
return;
@@ -1699,7 +1699,7 @@ void gfx_v9_4_2_reset_ras_error_count(struct 
amdgpu_device *adev)
gfx_v9_4_2_query_utc_edc_count(adev, NULL, NULL);
 }
 
-int gfx_v9_4_2_ras_error_inject(struct amdgpu_device *adev, void *inject_if)
+static int gfx_v9_4_2_ras_error_inject(struct amdgpu_device *adev, void 
*inject_if)
 {
struct ras_inject_if *info = (struct ras_inject_if *)inject_if;
int ret;
@@ -1772,7 +1772,7 @@ static void gfx_v9_4_2_query_utc_err_status(struct 
amdgpu_device *adev)
}
 }
 
-void gfx_v9_4_2_query_ras_error_status(struct amdgpu_device *adev)
+static void gfx_v9_4_2_query_ras_error_status(struct amdgpu_device *adev)
 {
if (!amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__GFX))
return;
@@ -1782,7 +1782,7 @@ void gfx_v9_4_2_query_ras_error_status(struct 
amdgpu_device *adev)
gfx_v9_4_2_query_sq_timeout_status(adev);
 }
 
-void gfx_v9_4_2_reset_ras_error_status(struct amdgpu_device *adev)
+static void gfx_v9_4_2_reset_ras_error_status(struct amdgpu_device *adev)
 {
if (!amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__GFX))
return;
@@ -1792,7 +1792,7 @@ void gfx_v9_4_2_reset_ras_error_status(struct 
amdgpu_device *adev)
gfx_v9_4_2_reset_sq_timeout_status(adev);
 }
 
-void gfx_v9_4_2_enable_watchdog_timer(struct amdgpu_device *adev)
+static void gfx_v9_4_2_enable_watchdog_timer(struct amdgpu_device *adev)
 {
uint32_t i;
uint32_t data;
-- 
2.31.1

[PATCH 32/38] drm/amd/amdgpu/sdma_v4_0: Realign functions with their headers

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:764: warning: expecting prototype for 
sdma_v4_0_page_ring_set_wptr(). Prototype was for sdma_v4_0_ring_set_wptr() 
instead
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:830: warning: expecting prototype for 
sdma_v4_0_ring_set_wptr(). Prototype was for sdma_v4_0_page_ring_set_wptr() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index d197185f77890..ae5464e2535a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -754,7 +754,7 @@ static uint64_t sdma_v4_0_ring_get_wptr(struct amdgpu_ring 
*ring)
 }
 
 /**
- * sdma_v4_0_page_ring_set_wptr - commit the write pointer
+ * sdma_v4_0_ring_set_wptr - commit the write pointer
  *
  * @ring: amdgpu ring pointer
  *
@@ -820,7 +820,7 @@ static uint64_t sdma_v4_0_page_ring_get_wptr(struct 
amdgpu_ring *ring)
 }
 
 /**
- * sdma_v4_0_ring_set_wptr - commit the write pointer
+ * sdma_v4_0_page_ring_set_wptr - commit the write pointer
  *
  * @ring: amdgpu ring pointer
  *
-- 
2.31.1

[PATCH 18/38] drm/msm/disp/dpu1/dpu_hw_interrupts: Demote a bunch of kernel-doc abuses

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:17: warning: expecting 
prototype for Register offsets in MDSS register file for the interrupt 
registers(). Prototype was for MDP_SSPP_TOP0_OFF() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:35: warning: expecting 
prototype for WB interrupt status bit definitions(). Prototype was for 
DPU_INTR_WB_0_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:42: warning: expecting 
prototype for WDOG timer interrupt status bit definitions(). Prototype was for 
DPU_INTR_WD_TIMER_0_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:51: warning: expecting 
prototype for Pingpong interrupt status bit definitions(). Prototype was for 
DPU_INTR_PING_PONG_0_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:71: warning: expecting 
prototype for Interface interrupt status bit definitions(). Prototype was for 
DPU_INTR_INTF_0_UNDERRUN() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:85: warning: expecting 
prototype for Pingpong Secondary interrupt status bit definitions(). Prototype 
was for DPU_INTR_PING_PONG_S0_AUTOREFRESH_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:94: warning: expecting 
prototype for Pingpong TEAR detection interrupt status bit definitions(). 
Prototype was for DPU_INTR_PING_PONG_0_TEAR_DETECTED() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:102: warning: expecting 
prototype for Pingpong TE detection interrupt status bit definitions(). 
Prototype was for DPU_INTR_PING_PONG_0_TE_DETECTED() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:110: warning: expecting 
prototype for Ctl start interrupt status bit definitions(). Prototype was for 
DPU_INTR_CTL_0_START() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:119: warning: expecting 
prototype for Concurrent WB overflow interrupt status bit definitions(). 
Prototype was for DPU_INTR_CWB_2_OVERFLOW() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:125: warning: expecting 
prototype for Histogram VIG done interrupt status bit definitions(). Prototype 
was for DPU_INTR_HIST_VIG_0_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:133: warning: expecting 
prototype for Histogram VIG reset Sequence done interrupt status bit 
definitions(). Prototype was for DPU_INTR_HIST_VIG_0_RSTSEQ_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:141: warning: expecting 
prototype for Histogram DSPP done interrupt status bit definitions(). Prototype 
was for DPU_INTR_HIST_DSPP_0_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:149: warning: expecting 
prototype for Histogram DSPP reset Sequence done interrupt status bit 
definitions(). Prototype was for DPU_INTR_HIST_DSPP_0_RSTSEQ_DONE() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:157: warning: expecting 
prototype for INTF interrupt status bit definitions(). Prototype was for 
DPU_INTR_VIDEO_INTO_STATIC() instead
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:170: warning: expecting 
prototype for AD4 interrupt status bit definitions(). Prototype was for 
DPU_INTR_BACKLIGHT_UPDATED() instead

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Krishna Manikandan 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 32 +--
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 48c96b8121268..aaf251741dc27 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -10,7 +10,7 @@
 #include "dpu_hw_util.h"
 #include "dpu_hw_mdss.h"
 
-/**
+/*
  * Register offsets in MDSS register file for the interrupt registers
  * w.r.t. to the MDP base
  */
@@ -29,14 +29,14 @@
 #define MDP_INTF_1_OFF_REV_7xxx 0x35000
 #define MDP_INTF_5_OFF_REV_7xxx 0x39000
 
-/**
+/*
  * WB interrupt status bit definitions
  */
 #define DPU_INTR_WB_0_DONE BIT(0)
 #define DPU_INTR_WB_1_DONE BIT(1)
 #define DPU_INTR_WB_2_DONE BIT(4)
 
-/**
+/*
  * WDOG timer interrupt status bit definitions
  */
 #define DPU_INTR_WD_TIMER_0_DONE BIT(2)
@@ -45,7 +45,7 @@
 #define DPU_INTR_WD_TIMER_3_DONE BIT(6)
 #define DPU_INTR_WD_TIMER_4_DONE BIT(7)
 
-/**
+/*
  * Pingpong interrupt status bit definitions
  */
 #define DPU_INTR_PING_PONG_0_DONE BIT(8)
@@ -65,7 +65,7 @@
 #define DPU_INTR_PING_PONG_2_AUTOREFRESH_DONE BIT(22)
 #define DPU_INTR_PING_PONG_3_AUTOREFRESH_DONE BIT(23)
 
-/**
+/*
  * Interface interrupt status bit definitions
  */
 #define DPU_INTR_INTF_0_UNDERRUN BIT(24)
@@ -79,7 +79,7 @@
 #define DPU_INTR_INTF_3_VSYNC BIT(31)
 #define DPU_INTR_INTF_5_VSYNC BIT(23)
 
-/**
+/*
  * Pingpong Seco

[PATCH 23/38] drm/amd/amdgpu/gmc_v7_0: Fix potential copy/paste issue

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:526: warning: expecting prototype for 
gmc_v8_0_set_fault_enable_default(). Prototype was for 
gmc_v7_0_set_fault_enable_default() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 210ada2289ec9..8e282169f99eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -516,7 +516,7 @@ static void gmc_v7_0_get_vm_pte(struct amdgpu_device *adev,
 }
 
 /**
- * gmc_v8_0_set_fault_enable_default - update VM fault handling
+ * gmc_v7_0_set_fault_enable_default - update VM fault handling
  *
  * @adev: amdgpu_device pointer
  * @value: true redirects VM faults to the default page
-- 
2.31.1

[PATCH 38/38] drm/amd/amdgpu/smuio_v13_0: Realign 'smuio_v13_0_is_host_gpu_xgmi_supported()' header

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c:99: warning: expecting prototype for 
smuio_v13_0_supports_host_gpu_xgmi(). Prototype was for 
smuio_v13_0_is_host_gpu_xgmi_supported() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Hawking Zhang 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c 
b/drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c
index 3c47c94846d6d..39b7c206770f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c
@@ -106,7 +106,7 @@ static u32 smuio_v13_0_get_socket_id(struct amdgpu_device 
*adev)
 }
 
 /**
- * smuio_v13_0_supports_host_gpu_xgmi - detect xgmi interface between cpu and 
gpu/s.
+ * smuio_v13_0_is_host_gpu_xgmi_supported - detect xgmi interface between cpu 
and gpu/s.
  *
  * @adev: amdgpu device pointer
  *
-- 
2.31.1

[PATCH 37/38] drm/amd/amdgpu/gfx_v10_0: Demote kernel-doc abuse

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:51: warning: This comment starts with 
'/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index fc12e3c3e9cae..c833be31e4ae6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -47,7 +47,7 @@
 #include "gfx_v10_0.h"
 #include "nbio_v2_3.h"
 
-/**
+/*
  * Navi10 has two graphic rings to share each graphic pipe.
  * 1. Primary ring
  * 2. Async ring
-- 
2.31.1

[PATCH 29/38] drm/radeon/r100: Realign doc header with function 'r100_cs_packet_parse_vline()'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/r100.c:1423: warning: expecting prototype for 
r100_cs_packet_next_vline(). Prototype was for r100_cs_packet_parse_vline() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/r100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fcfcaec25a9ef..3c4e7c15fd159 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1406,7 +1406,7 @@ int r100_cs_parse_packet0(struct radeon_cs_parser *p,
 }
 
 /**
- * r100_cs_packet_next_vline() - parse userspace VLINE packet
+ * r100_cs_packet_parse_vline() - parse userspace VLINE packet
  * @p: parser structure holding parsing context.
  *
  * Userspace sends a special sequence for VLINE waits.
-- 
2.31.1

[PATCH 20/38] drm/radeon/radeon_vm: Fix function naming disparities

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/radeon/radeon_vm.c:61: warning: expecting prototype for 
radeon_vm_num_pde(). Prototype was for radeon_vm_num_pdes() instead
 drivers/gpu/drm/radeon/radeon_vm.c:642: warning: expecting prototype for 
radeon_vm_update_pdes(). Prototype was for radeon_vm_update_page_directory() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 2dc9c9f98049b..36a38adaaea96 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -51,7 +51,7 @@
  */
 
 /**
- * radeon_vm_num_pde - return the number of page directory entries
+ * radeon_vm_num_pdes - return the number of page directory entries
  *
  * @rdev: radeon_device pointer
  *
@@ -626,7 +626,7 @@ static uint32_t radeon_vm_page_flags(uint32_t flags)
 }
 
 /**
- * radeon_vm_update_pdes - make sure that page directory is valid
+ * radeon_vm_update_page_directory - make sure that page directory is valid
  *
  * @rdev: radeon_device pointer
  * @vm: requested vm
-- 
2.31.1

[PATCH 31/38] drm/amd/amdgpu/sdma_v2_4: Correct misnamed function 'sdma_v2_4_ring_emit_hdp_flush()'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c:281: warning: expecting prototype for 
sdma_v2_4_hdp_flush_ring_emit(). Prototype was for 
sdma_v2_4_ring_emit_hdp_flush() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
index 9f0dda040ec88..4509bd4cce2d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
@@ -271,7 +271,7 @@ static void sdma_v2_4_ring_emit_ib(struct amdgpu_ring *ring,
 }
 
 /**
- * sdma_v2_4_hdp_flush_ring_emit - emit an hdp flush on the DMA ring
+ * sdma_v2_4_ring_emit_hdp_flush - emit an hdp flush on the DMA ring
  *
  * @ring: amdgpu ring pointer
  *
-- 
2.31.1

[PATCH 25/38] drm/msm/msm_gem: Demote kernel-doc abuses

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/msm_gem.c:364: warning: This comment starts with '/**', 
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 drivers/gpu/drm/msm/msm_gem.c:763: warning: This comment starts with '/**', 
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/msm_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 56df86e5f7400..15434deb19334 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -372,7 +372,7 @@ static void del_vma(struct msm_gem_vma *vma)
kfree(vma);
 }
 
-/**
+/*
  * If close is true, this also closes the VMA (releasing the allocated
  * iova range) in addition to removing the iommu mapping.  In the eviction
  * case (!close), we keep the iova allocated, but only remove the iommu
@@ -773,7 +773,7 @@ void msm_gem_purge(struct drm_gem_object *obj)
0, (loff_t)-1);
 }
 
-/**
+/*
  * Unpin the backing pages and make them available to be swapped out.
  */
 void msm_gem_evict(struct drm_gem_object *obj)
-- 
2.31.1

[PATCH 34/38] drm/amd/amdgpu/amdgpu_vce: Fix a few incorrectly named functions

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:98: warning: expecting prototype for 
amdgpu_vce_init(). Prototype was for amdgpu_vce_sw_init() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:214: warning: expecting prototype for 
amdgpu_vce_fini(). Prototype was for amdgpu_vce_sw_fini() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:590: warning: expecting prototype for 
amdgpu_vce_cs_validate_bo(). Prototype was for amdgpu_vce_validate_bo() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:724: warning: expecting prototype for 
amdgpu_vce_cs_parse(). Prototype was for amdgpu_vce_ring_parse_cs() instead
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:960: warning: expecting prototype for 
amdgpu_vce_cs_parse_vm(). Prototype was for amdgpu_vce_ring_parse_cs_vm() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index ea6a62f67e380..7ad83da613edd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -87,7 +87,7 @@ static int amdgpu_vce_get_destroy_msg(struct amdgpu_ring 
*ring, uint32_t handle,
  bool direct, struct dma_fence **fence);
 
 /**
- * amdgpu_vce_init - allocate memory, load vce firmware
+ * amdgpu_vce_sw_init - allocate memory, load vce firmware
  *
  * @adev: amdgpu_device pointer
  * @size: size for the new BO
@@ -204,7 +204,7 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev, unsigned 
long size)
 }
 
 /**
- * amdgpu_vce_fini - free memory
+ * amdgpu_vce_sw_fini - free memory
  *
  * @adev: amdgpu_device pointer
  *
@@ -574,7 +574,7 @@ static int amdgpu_vce_get_destroy_msg(struct amdgpu_ring 
*ring, uint32_t handle,
 }
 
 /**
- * amdgpu_vce_cs_validate_bo - make sure not to cross 4GB boundary
+ * amdgpu_vce_validate_bo - make sure not to cross 4GB boundary
  *
  * @p: parser context
  * @ib_idx: indirect buffer to use
@@ -715,7 +715,7 @@ static int amdgpu_vce_validate_handle(struct 
amdgpu_cs_parser *p,
 }
 
 /**
- * amdgpu_vce_cs_parse - parse and validate the command stream
+ * amdgpu_vce_ring_parse_cs - parse and validate the command stream
  *
  * @p: parser context
  * @ib_idx: indirect buffer to use
@@ -951,7 +951,7 @@ int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser *p, 
uint32_t ib_idx)
 }
 
 /**
- * amdgpu_vce_cs_parse_vm - parse the command stream in VM mode
+ * amdgpu_vce_ring_parse_cs_vm - parse the command stream in VM mode
  *
  * @p: parser context
  * @ib_idx: indirect buffer to use
-- 
2.31.1

[PATCH 24/38] drm/amd/amdgpu/mmhub_v9_4: Fix naming disparity with 'mmhub_v9_4_set_fault_enable_default()'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c:446: warning: expecting prototype for 
mmhub_v1_0_set_fault_enable_default(). Prototype was for 
mmhub_v9_4_set_fault_enable_default() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c
index 47c8dd9d1c78e..c4ef822bbe8c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c
@@ -436,7 +436,7 @@ static void mmhub_v9_4_gart_disable(struct amdgpu_device 
*adev)
 }
 
 /**
- * mmhub_v1_0_set_fault_enable_default - update GART/VM fault handling
+ * mmhub_v9_4_set_fault_enable_default - update GART/VM fault handling
  *
  * @adev: amdgpu_device pointer
  * @value: true redirects VM faults to the default page
-- 
2.31.1

[PATCH 28/38] drm/msm/dp/dp_link: Fix some potential doc-rot

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/dp/dp_link.c:374: warning: expecting prototype for 
dp_parse_video_pattern_params(). Prototype was for 
dp_link_parse_video_pattern_params() instead
 drivers/gpu/drm/msm/dp/dp_link.c:573: warning: expecting prototype for 
dp_parse_phy_test_params(). Prototype was for dp_link_parse_phy_test_params() 
instead
 drivers/gpu/drm/msm/dp/dp_link.c:975: warning: expecting prototype for 
dp_link_process_downstream_port_status_change(). Prototype was for 
dp_link_process_ds_port_status_change() instead

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chandan Uddaraju 
Cc: Kuogee Hsieh 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/dp/dp_link.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da78c4a5..1099604bd1c86 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -364,7 +364,7 @@ static int dp_link_parse_timing_params3(struct 
dp_link_private *link,
 }
 
 /**
- * dp_parse_video_pattern_params() - parses video pattern parameters from DPCD
+ * dp_link_parse_video_pattern_params() - parses video pattern parameters from 
DPCD
  * @link: Display Port Driver data
  *
  * Returns 0 if it successfully parses the video link pattern and the link
@@ -563,7 +563,7 @@ static int dp_link_parse_link_training_params(struct 
dp_link_private *link)
 }
 
 /**
- * dp_parse_phy_test_params() - parses the phy link parameters
+ * dp_link_parse_phy_test_params() - parses the phy link parameters
  * @link: Display Port Driver data
  *
  * Parses the DPCD (Byte 0x248) for the DP PHY link pattern that is being
@@ -961,7 +961,7 @@ static int dp_link_process_link_status_update(struct 
dp_link_private *link)
 }
 
 /**
- * dp_link_process_downstream_port_status_change() - process port status 
changes
+ * dp_link_process_ds_port_status_change() - process port status changes
  * @link: Display Port Driver data
  *
  * This function will handle downstream port updates that are initiated by
-- 
2.31.1

[PATCH 21/38] drm/amd/include/aldebaran_ip_offset: Mark top-level IP_BASE as __maybe_unused

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:259:29: warning: 
‘XGMI2_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:252:29: warning: 
‘XGMI1_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:245:29: warning: 
‘XGMI0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:238:29: warning: 
‘WAFL1_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:231:29: warning: 
‘WAFL0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:161:29: warning: 
‘PCIE0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:119:29: warning: 
‘L2IMU0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:112:29: warning: 
‘L1IMUPCIE0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:105:29: warning: 
‘L1IMUIOAGR0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:98:29: warning: 
‘IOHC0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:91:29: warning: 
‘IOAPIC0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:84:29: warning: 
‘IOAGR0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:63:29: warning: 
‘FUSE_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:49:29: warning: 
‘DBGU_IO0_BASE’ defined but not used [-Wunused-const-variable=]
 drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:42:29: warning: 
‘CLK_BASE’ defined but not used [-Wunused-const-variable=]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Hawking Zhang 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/include/aldebaran_ip_offset.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/include/aldebaran_ip_offset.h 
b/drivers/gpu/drm/amd/include/aldebaran_ip_offset.h
index 644ffec2b0ce8..cdd426b41c20e 100644
--- a/drivers/gpu/drm/amd/include/aldebaran_ip_offset.h
+++ b/drivers/gpu/drm/amd/include/aldebaran_ip_offset.h
@@ -30,7 +30,7 @@ struct IP_BASE_INSTANCE {
 
 struct IP_BASE {
 struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
-};
+} __maybe_unused;
 
 static const struct IP_BASE ATHUB_BASE = { { { { 0x0C20, 0x02408C00, 0, 0, 
0, 0 } },
 { { 0, 0, 0, 0, 0, 0 } },
-- 
2.31.1

[PATCH 27/38] drm/msm/dp/dp_catalog: Correctly document param 'dp_catalog'

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/dp/dp_catalog.c:206: warning: Function parameter or member 
'dp_catalog' not described in 'dp_catalog_aux_reset'
 drivers/gpu/drm/msm/dp/dp_catalog.c:206: warning: Excess function parameter 
'aux' description in 'dp_catalog_aux_reset'

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chandan Uddaraju 
Cc: Stephen Boyd 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/dp/dp_catalog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c 
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index b1a9b1b98f5f6..e4d9df3c04011 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -193,7 +193,7 @@ int dp_catalog_aux_clear_hw_interrupts(struct dp_catalog 
*dp_catalog)
 /**
  * dp_catalog_aux_reset() - reset AUX controller
  *
- * @aux: DP catalog structure
+ * @dp_catalog: DP catalog structure
  *
  * return: void
  *
-- 
2.31.1

Re: [PATCH 03/38] drm/radeon/radeon_cs: Fix incorrectly documented function 'radeon_cs_parser_fini'

[Christian König]

Am 20.05.21 um 14:02 schrieb Lee Jones:

Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/radeon/radeon_cs.c:417: warning: expecting prototype for 
cs_parser_fini(). Prototype was for radeon_cs_parser_fini() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Jerome Glisse 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 48162501c1ee6..80a3bee933d6d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -405,7 +405,7 @@ static int cmp_size_smaller_first(void *priv, const struct 
list_head *a,
  }
  
  /**

- * cs_parser_fini() - clean parser states
+ * radeon_cs_parser_fini() - clean parser states
   * @parser:   parser structure holding parsing context.
   * @error:error number
   * @backoff:  indicator to backoff the reservation

[PATCH 36/38] drm/amd/amdgpu/vcn_v1_0: Fix some function naming disparity

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:775: warning: expecting prototype for 
vcn_v1_0_start(). Prototype was for vcn_v1_0_start_spg_mode() instead
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:: warning: expecting prototype for 
vcn_v1_0_stop(). Prototype was for vcn_v1_0_stop_spg_mode() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 0c1beefa3e498..2c9af18683feb 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -765,7 +765,7 @@ static void vcn_1_0_enable_static_power_gating(struct 
amdgpu_device *adev)
 }
 
 /**
- * vcn_v1_0_start - start VCN block
+ * vcn_v1_0_start_spg_mode - start VCN block
  *
  * @adev: amdgpu_device pointer
  *
@@ -1101,7 +1101,7 @@ static int vcn_v1_0_start(struct amdgpu_device *adev)
 }
 
 /**
- * vcn_v1_0_stop - stop VCN block
+ * vcn_v1_0_stop_spg_mode - stop VCN block
  *
  * @adev: amdgpu_device pointer
  *
-- 
2.31.1

[PATCH 16/38] drm/amd/amdgpu/si_dma: Fix some function name disparity

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/si_dma.c:320: warning: expecting prototype for 
cik_dma_vm_copy_pte(). Prototype was for si_dma_vm_copy_pte() instead
 drivers/gpu/drm/amd/amdgpu/si_dma.c:412: warning: expecting prototype for 
si_dma_pad_ib(). Prototype was for si_dma_ring_pad_ib() instead
 drivers/gpu/drm/amd/amdgpu/si_dma.c:425: warning: expecting prototype for 
cik_sdma_ring_emit_pipeline_sync(). Prototype was for 
si_dma_ring_emit_pipeline_sync() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/si_dma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si_dma.c 
b/drivers/gpu/drm/amd/amdgpu/si_dma.c
index cb703e307238d..195b45bcb8ad9 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dma.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dma.c
@@ -305,7 +305,7 @@ static int si_dma_ring_test_ib(struct amdgpu_ring *ring, 
long timeout)
 }
 
 /**
- * cik_dma_vm_copy_pte - update PTEs by copying them from the GART
+ * si_dma_vm_copy_pte - update PTEs by copying them from the GART
  *
  * @ib: indirect buffer to fill with commands
  * @pe: addr of the page entry
@@ -402,7 +402,7 @@ static void si_dma_vm_set_pte_pde(struct amdgpu_ib *ib,
 }
 
 /**
- * si_dma_pad_ib - pad the IB to the required number of dw
+ * si_dma_ring_pad_ib - pad the IB to the required number of dw
  *
  * @ring: amdgpu_ring pointer
  * @ib: indirect buffer to fill with padding
@@ -415,7 +415,7 @@ static void si_dma_ring_pad_ib(struct amdgpu_ring *ring, 
struct amdgpu_ib *ib)
 }
 
 /**
- * cik_sdma_ring_emit_pipeline_sync - sync the pipeline
+ * si_dma_ring_emit_pipeline_sync - sync the pipeline
  *
  * @ring: amdgpu_ring pointer
  *
-- 
2.31.1

[PATCH 33/38] drm/amd/amdgpu/sdma_v5_0: Fix typo in function name

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:563: warning: expecting prototype for 
sdma_v_0_ctx_switch_enable(). Prototype was for sdma_v5_0_ctx_switch_enable() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
index 75d7310f84392..2a2b9d50afb70 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
@@ -571,7 +571,7 @@ static void sdma_v5_0_rlc_stop(struct amdgpu_device *adev)
 }
 
 /**
- * sdma_v_0_ctx_switch_enable - stop the async dma engines context switch
+ * sdma_v5_0_ctx_switch_enable - stop the async dma engines context switch
  *
  * @adev: amdgpu_device pointer
  * @enable: enable/disable the DMA MEs context switch.
-- 
2.31.1

[PATCH 35/38] drm/amd/amdgpu/sdma_v5_2: Repair typo in function name

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:501: warning: expecting prototype for 
sdma_v_0_ctx_switch_enable(). Prototype was for sdma_v5_2_ctx_switch_enable() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
index ecb82c39b1062..deb907f960906 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
@@ -517,7 +517,7 @@ static void sdma_v5_2_rlc_stop(struct amdgpu_device *adev)
 }
 
 /**
- * sdma_v_0_ctx_switch_enable - stop the async dma engines context switch
+ * sdma_v5_2_ctx_switch_enable - stop the async dma engines context switch
  *
  * @adev: amdgpu_device pointer
  * @enable: enable/disable the DMA MEs context switch.
-- 
2.31.1

Re: [PATCH 10/38] drm/amd/amdgpu/amdgpu_ids: Correct some function name disparity

[Christian König]

Am 20.05.21 um 14:02 schrieb Lee Jones:

Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:200: warning: expecting prototype for 
amdgpu_vm_grab_idle(). Prototype was for amdgpu_vmid_grab_idle() instead
  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:272: warning: expecting prototype for 
amdgpu_vm_grab_reserved(). Prototype was for amdgpu_vmid_grab_reserved() instead
  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:337: warning: expecting prototype for 
amdgpu_vm_grab_used(). Prototype was for amdgpu_vmid_grab_used() instead
  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:410: warning: expecting prototype for 
amdgpu_vm_grab_id(). Prototype was for amdgpu_vmid_grab() instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index b4971e90b98cf..c7f3aae23c625 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -183,7 +183,7 @@ bool amdgpu_vmid_had_gpu_reset(struct amdgpu_device *adev,
  }
  
  /**

- * amdgpu_vm_grab_idle - grab idle VMID
+ * amdgpu_vmid_grab_idle - grab idle VMID
   *
   * @vm: vm to allocate id for
   * @ring: ring we want to submit job to
@@ -256,7 +256,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm,
  }
  
  /**

- * amdgpu_vm_grab_reserved - try to assign reserved VMID
+ * amdgpu_vmid_grab_reserved - try to assign reserved VMID
   *
   * @vm: vm to allocate id for
   * @ring: ring we want to submit job to
@@ -325,7 +325,7 @@ static int amdgpu_vmid_grab_reserved(struct amdgpu_vm *vm,
  }
  
  /**

- * amdgpu_vm_grab_used - try to reuse a VMID
+ * amdgpu_vmid_grab_used - try to reuse a VMID
   *
   * @vm: vm to allocate id for
   * @ring: ring we want to submit job to
@@ -397,7 +397,7 @@ static int amdgpu_vmid_grab_used(struct amdgpu_vm *vm,
  }
  
  /**

- * amdgpu_vm_grab_id - allocate the next free VMID
+ * amdgpu_vmid_grab - allocate the next free VMID
   *
   * @vm: vm to allocate id for
   * @ring: ring we want to submit job to

Re: [PATCH 20/38] drm/radeon/radeon_vm: Fix function naming disparities

[Christian König]

Am 20.05.21 um 14:02 schrieb Lee Jones:

Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/radeon/radeon_vm.c:61: warning: expecting prototype for 
radeon_vm_num_pde(). Prototype was for radeon_vm_num_pdes() instead
  drivers/gpu/drm/radeon/radeon_vm.c:642: warning: expecting prototype for 
radeon_vm_update_pdes(). Prototype was for radeon_vm_update_page_directory() 
instead

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 2dc9c9f98049b..36a38adaaea96 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -51,7 +51,7 @@
   */
  
  /**

- * radeon_vm_num_pde - return the number of page directory entries
+ * radeon_vm_num_pdes - return the number of page directory entries
   *
   * @rdev: radeon_device pointer
   *
@@ -626,7 +626,7 @@ static uint32_t radeon_vm_page_flags(uint32_t flags)
  }
  
  /**

- * radeon_vm_update_pdes - make sure that page directory is valid
+ * radeon_vm_update_page_directory - make sure that page directory is valid
   *
   * @rdev: radeon_device pointer
   * @vm: requested vm

[PATCH v2 0/3] drm: xlnx: zynqmp_dpsub: Fix plane handling

[Laurent Pinchart]

Hello,

This small patch series fixes an issue related to plane blending (patch
1/3), add global alpha support to the overlay plane (patch 2/3) and
exposes plane ordering to userspace (patch 3/3). There isn't much to say
here, please refer to individual patches for details.

Compared to v1, I've dropped making the video plane primary, as that
seems to cause issues with existing userspace, and I've been told in the
meantime that the DRM/KMS API doesn't require the overlay planes to be
on top of the primary plane (even if not doing so is somehow
counterintuitive, given the name "overlay").

Laurent Pinchart (3):
  drm: xlnx: zynqmp_dpsub: Fix graphics layer blending
  drm: xlnx: zynqmp_dpsub: Add global alpha support
  drm: xlnx: zynqmp_dpsub: Expose plane ordering to userspace

 drivers/gpu/drm/xlnx/zynqmp_disp.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart

[PATCH v2 2/3] drm: xlnx: zynqmp_dpsub: Add global alpha support

[Laurent Pinchart]

The graphics plane has a global alpha setting. Expose it through the
plane's alpha property.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 27b3829fb7e0..d87af7cb3340 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1164,7 +1164,8 @@ zynqmp_disp_plane_atomic_disable(struct drm_plane *plane,
zynqmp_disp_layer_disable(layer);
 
if (zynqmp_disp_layer_is_gfx(layer))
-   zynqmp_disp_blend_set_global_alpha(layer->disp, false, 0);
+   zynqmp_disp_blend_set_global_alpha(layer->disp, false,
+  plane->state->alpha >> 8);
 }
 
 static void
@@ -1195,7 +1196,8 @@ zynqmp_disp_plane_atomic_update(struct drm_plane *plane,
zynqmp_disp_layer_update(layer, new_state);
 
if (zynqmp_disp_layer_is_gfx(layer))
-   zynqmp_disp_blend_set_global_alpha(layer->disp, true, 255);
+   zynqmp_disp_blend_set_global_alpha(layer->disp, true,
+  plane->state->alpha >> 8);
 
/* Enable or re-enable the plane is the format has changed. */
if (format_changed)
@@ -1249,6 +1251,9 @@ static int zynqmp_disp_create_planes(struct zynqmp_disp 
*disp)
 
drm_plane_helper_add(&layer->plane,
 &zynqmp_disp_plane_helper_funcs);
+
+   if (zynqmp_disp_layer_is_gfx(layer))
+   drm_plane_create_alpha_property(&layer->plane);
}
 
return 0;
-- 
Regards,

Laurent Pinchart

[PATCH v2 1/3] drm: xlnx: zynqmp_dpsub: Fix graphics layer blending

[Laurent Pinchart]

To display the graphics layer, the global alpha needs to be enabled.
Enable it when the graphics plane is enabled (with full opacity), and
disable it otherwise.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index a061a75a9de7..27b3829fb7e0 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -415,6 +415,11 @@ static void zynqmp_disp_avbuf_write(struct zynqmp_disp 
*disp, int reg, u32 val)
writel(val, disp->avbuf.base + reg);
 }
 
+static bool zynqmp_disp_layer_is_gfx(const struct zynqmp_disp_layer *layer)
+{
+   return layer->id == ZYNQMP_DISP_LAYER_GFX;
+}
+
 static bool zynqmp_disp_layer_is_video(const struct zynqmp_disp_layer *layer)
 {
return layer->id == ZYNQMP_DISP_LAYER_VID;
@@ -1157,6 +1162,9 @@ zynqmp_disp_plane_atomic_disable(struct drm_plane *plane,
return;
 
zynqmp_disp_layer_disable(layer);
+
+   if (zynqmp_disp_layer_is_gfx(layer))
+   zynqmp_disp_blend_set_global_alpha(layer->disp, false, 0);
 }
 
 static void
@@ -1186,6 +1194,9 @@ zynqmp_disp_plane_atomic_update(struct drm_plane *plane,
 
zynqmp_disp_layer_update(layer, new_state);
 
+   if (zynqmp_disp_layer_is_gfx(layer))
+   zynqmp_disp_blend_set_global_alpha(layer->disp, true, 255);
+
/* Enable or re-enable the plane is the format has changed. */
if (format_changed)
zynqmp_disp_layer_enable(layer);
@@ -1447,7 +1458,6 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc,
 
zynqmp_disp_blend_set_output_format(disp, ZYNQMP_DPSUB_FORMAT_RGB);
zynqmp_disp_blend_set_bg_color(disp, 0, 0, 0);
-   zynqmp_disp_blend_set_global_alpha(disp, false, 0);
 
zynqmp_disp_enable(disp);
 
-- 
Regards,

Laurent Pinchart

[PATCH v2 3/3] drm: xlnx: zynqmp_dpsub: Expose plane ordering to userspace

[Laurent Pinchart]

While the DPSUB has a fixed plane order, it still makes sense to expose
it to userspace to avoid hardcoding assumptions. Do so by adding an
immutable zpos property to planes.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index d87af7cb3340..e377974f8198 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1252,6 +1252,7 @@ static int zynqmp_disp_create_planes(struct zynqmp_disp 
*disp)
drm_plane_helper_add(&layer->plane,
 &zynqmp_disp_plane_helper_funcs);
 
+   drm_plane_create_zpos_immutable_property(&layer->plane, i);
if (zynqmp_disp_layer_is_gfx(layer))
drm_plane_create_alpha_property(&layer->plane);
}
-- 
Regards,

Laurent Pinchart

Re: [PATCH v6 1/3] gpu: drm: separate panel orientation property creating and value setting

[Sean Paul]

On Thu, Apr 29, 2021 at 12:28 AM Hsin-Yi Wang  wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>
> [4.480976] [ cut here ]
> [4.485603] WARNING: CPU: 5 PID: 369 at 
> drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> 
> [4.609772] Call trace:
> [4.612208]  __drm_mode_object_add+0xb4/0xbc
> [4.616466]  drm_mode_object_add+0x20/0x2c
> [4.620552]  drm_property_create+0xdc/0x174
> [4.624723]  drm_property_create_enum+0x34/0x98
> [4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> [4.634716]  boe_panel_get_modes+0x88/0xd8
> [4.638802]  drm_panel_get_modes+0x2c/0x48
> [4.642887]  panel_bridge_get_modes+0x1c/0x28
> [4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> [4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> [4.658266]  drm_mode_getconnector+0x1b4/0x45c
> [4.662699]  drm_ioctl_kernel+0xac/0x128
> [4.11]  drm_ioctl+0x268/0x410
> [4.670002]  drm_compat_ioctl+0xdc/0xf0
> [4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> [4.678436]  el0_svc_common+0xf4/0x1c0
> [4.682174]  do_el0_svc_compat+0x28/0x3c
> [4.686088]  el0_svc_compat+0x10/0x1c
> [4.689738]  el0_sync_compat_handler+0xa8/0xcc
> [4.694171]  el0_sync_compat+0x178/0x180
> [4.698082] ---[ end trace b4f2db9d9c88610b ]---
> [4.702721] [ cut here ]
> [4.707329] WARNING: CPU: 5 PID: 369 at 
> drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> 
> [4.833830] Call trace:
> [4.836266]  drm_object_attach_property+0x48/0xb8
> [4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> [4.846432]  boe_panel_get_modes+0x88/0xd8
> [4.850516]  drm_panel_get_modes+0x2c/0x48
> [4.854600]  panel_bridge_get_modes+0x1c/0x28
> [4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> [4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> [4.869978]  drm_mode_getconnector+0x1b4/0x45c
> [4.874410]  drm_ioctl_kernel+0xac/0x128
> [4.878320]  drm_ioctl+0x268/0x410
> [4.881711]  drm_compat_ioctl+0xdc/0xf0
> [4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> [4.890142]  el0_svc_common+0xf4/0x1c0
> [4.893879]  do_el0_svc_compat+0x28/0x3c
> [4.897791]  el0_svc_compat+0x10/0x1c
> [4.901441]  el0_sync_compat_handler+0xa8/0xcc
> [4.905873]  el0_sync_compat+0x178/0x180
> [4.909783] ---[ end trace b4f2db9d9c88610c ]---
>

+intel-gfx for i915 changes

Reviewed-by: Sean Paul 

> Signed-off-by: Hsin-Yi Wang 
> ---
> v6, v5:
> don't create property in set_panel_orientation.
>
> v4, v3:
> create property in dsi driver and set value in panel.
>
> v2:
> create property in connector init
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.2600890-1-hsi...@chromium.org/
>
> v1:
> set panel orientation in dsi driver
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsi...@chromium.org/
> ---
>  drivers/gpu/drm/drm_connector.c | 58 ++---
>  drivers/gpu/drm/i915/display/icl_dsi.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c |  1 +
>  drivers/gpu/drm/i915/display/vlv_dsi.c  |  1 +
>  include/drm/drm_connector.h |  2 +
>  5 files changed, 47 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..7189baaabf41 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
> = {
>   * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   * coordinates, so if userspace rotates the picture to adjust for
>   * the orientation it must also apply the same transformation to the
> - * touchscreen input coordinates. This property is initialized by calling
> + * touchscreen input coordinates. This property value is set by calling
>   * drm_connector_set_panel_orientation() or
>   * drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the 
> property

Re: [PATCH v7 03/10] dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child

[Rob Herring]

On Wed, May 19, 2021 at 4:06 PM Doug Anderson  wrote:
>
> Hi,
>
> On Wed, May 19, 2021 at 1:02 PM Rob Herring  wrote:
> >
> > On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote:
> > > We want to be able to list an eDP panel as a child of a ti-sn65dsi86
> > > node to represent the fact that the panel is connected to the bridge's
> > > DP AUX bus. Though the panel and the bridge chip are connected in
> > > several ways, the DP AUX bus is the primary control interface between
> > > the two and thus makes the most sense to model in device tree
> > > hierarchy.
> > >
> > > Listing a panel in this way makes it possible for the panel driver to
> > > easily get access to the DP AUX bus that it resides on, which can be
> > > useful to help in auto-detecting the panel and for turning on various
> > > bits.
> > >
> > > NOTE: it's still possible to continue using the bridge chip and point
> > > to a panel that _isn't_ listed as a child of the bridge chip (since
> > > it's worked that way previously), but that should be deprecated since
> > > there is no downside to listing the panel under the bridge chip.
> > >
> > > The idea for this bus's design was hashed out over IRC [1].
> > >
> > > [1] 
> > > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11
> > >
> > > Signed-off-by: Douglas Anderson 
> > > ---
> > > Possibly we might want something fancier that could be included by
> > > other eDP controller bindings. If we want to do this, I'd love to be
> > > pointed at a good example to follow.
> > >
> > > Changes in v7:
> > > - ti-sn65dsi86: Add aux-bus child patch new for v7.
> > >
> > >  .../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++-
> > >  1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml 
> > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
> > > index 26932d2e86ab..51f5a29e216c 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
> > > @@ -70,6 +70,11 @@ properties:
> > >  const: 1
> > >  description: See ../../pwm/pwm.yaml for description of the cell 
> > > formats.
> > >
> > > +  aux-bus:
> >
> > As this is a node:
> >
> > type: object
> >
> > > +description:
> > > +  It is recommended that you place your panel under the aux-bus node
> > > +  here to represent the control hierarchy.
> > > +
> > >ports:
> > >  $ref: /schemas/graph.yaml#/properties/ports
> > >
> > > @@ -201,11 +206,26 @@ examples:
> > >
> > >port@1 {
> > >  reg = <1>;
> > > -endpoint {
> > > +sn65dsi86_out: endpoint {
> > >remote-endpoint = <&panel_in_edp>;
> > >  };
> > >};
> > >  };
> > > +
> > > +aux-bus {
> > > +  panel {
> >
> > We should perhaps have a separate aux-bus schema.
>
> Yeah. Before spending lots of time digging into how to do this I
> wanted to see if anyone was going to give me a big-old NAK on the
> whole approach. ;-)
>
> I guess I'd make a file called "dp-aux-bus.yaml" (maybe right under
> bindings/display?) and then I'd include it like this:
>
> aux-bus:
>   $ref: "../dp-aux-bus.yaml#"

Right.

> > Something should
> > define the child node is 'panel' and nothing else.
>
> At the moment the code also requires that the node name is 'aux-bus'.
> Any objections to that?

No. There's 2 ways to do that. The above does and adding $nodename in
dp-aux-bus.yaml will. The latter also means the schema will be applied
automatically to any node named 'aux-bus'. That means the schema will
be applied twice unless you have 'select: false'. The main advantage
of the latter case is it gets applied even without all the users
converted to schema.

> > Though perhaps
> > connectors are valid too?
>
> They might be. We could always add it later?

Sure.

Rob

[PATCH -next] drm/amdgpu: fix unused-but-set-variable warnings

[Wei Yongjun]

GCC reports the following warnings with W=1:

drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c:190:22: warning:
 variable 'ring' set but not used [-Wunused-but-set-variable]
  190 |  struct amdgpu_ring *ring;
  |  ^~~~
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c:162:22: warning:
 variable 'ring' set but not used [-Wunused-but-set-variable]
  162 |  struct amdgpu_ring *ring;
  |  ^~~~
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:383:22: warning:
 variable 'ring' set but not used [-Wunused-but-set-variable]
  383 |  struct amdgpu_ring *ring;
  |  ^~~~

Those variables are not really used, so remove them
to fix the warnings.

Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c | 2 --
 drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 2 --
 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c  | 3 ---
 3 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c 
b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
index 938ef4ce5b76..af6f45c3f6fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
@@ -187,14 +187,12 @@ static int jpeg_v2_5_hw_init(void *handle)
 static int jpeg_v2_5_hw_fini(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
-   struct amdgpu_ring *ring;
int i;
 
for (i = 0; i < adev->jpeg.num_jpeg_inst; ++i) {
if (adev->jpeg.harvest_config & (1 << i))
continue;
 
-   ring = &adev->jpeg.inst[i].ring_dec;
if (adev->jpeg.cur_state != AMD_PG_STATE_GATE &&
  RREG32_SOC15(JPEG, i, mmUVD_JRBC_STATUS))
jpeg_v2_5_set_powergating_state(adev, 
AMD_PG_STATE_GATE);
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
index 94be35357f7d..b4d53d1a6123 100644
--- a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
@@ -159,9 +159,7 @@ static int jpeg_v3_0_hw_init(void *handle)
 static int jpeg_v3_0_hw_fini(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
-   struct amdgpu_ring *ring;
 
-   ring = &adev->jpeg.inst->ring_dec;
if (adev->jpeg.cur_state != AMD_PG_STATE_GATE &&
  RREG32_SOC15(JPEG, 0, mmUVD_JRBC_STATUS))
jpeg_v3_0_set_powergating_state(adev, AMD_PG_STATE_GATE);
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index 946335d0f19c..d60358767d10 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -380,15 +380,12 @@ static int vcn_v3_0_hw_init(void *handle)
 static int vcn_v3_0_hw_fini(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
-   struct amdgpu_ring *ring;
int i;
 
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
if (adev->vcn.harvest_config & (1 << i))
continue;
 
-   ring = &adev->vcn.inst[i].ring_dec;
-
if (!amdgpu_sriov_vf(adev)) {
if ((adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG) ||
(adev->vcn.cur_state != 
AMD_PG_STATE_GATE &&

Re: [PATCH] video: hgafb: correctly handle card detect failure during probe

[Greg Kroah-Hartman]

On Thu, May 20, 2021 at 07:10:39PM +0530, Anirudh Rayabharam wrote:
> On Mon, May 17, 2021 at 12:57:14AM +0530, Anirudh Rayabharam wrote:
> > The return value of hga_card_detect() is not properly handled causing
> > the probe to succeed even though hga_card_detect() failed. Since probe
> > succeeds, hgafb_open() can be called which will end up operating on an
> > unmapped hga_vram. This results in an out-of-bounds access as reported
> > by kernel test robot [1].
> > 
> > To fix this, correctly detect failure of hga_card_detect() by checking
> > for a non-zero error code.
> > 
> > [1]: 
> > https://lore.kernel.org/lkml/20210516150019.GB25903@xsang-OptiPlex-9020/
> > 
> > Reported-by: kernel test robot 
> > Fixes: dc13cac4862c ("video: hgafb: fix potential NULL pointer dereference")
> 
> Greg, this is one of the UMN fixes we did. So, do you want to take this
> patch into your tree?

Yes, will queue it up in a few days after Linus takes the current pull
request I sent him for this.

thanks,

greg k-h

Re: [RFC 1/3] dma-fence: Add boost fence op

[Rob Clark]

On Wed, May 19, 2021 at 11:47 PM Christian König
 wrote:
>
> Uff, that looks very hardware specific to me.

Howso?  I'm not sure I agree.. and even if it was not useful for some
hw, it should be useful for enough drivers (and harm no drivers), so I
still think it is a good idea

The fallback plan is to go the i915 route and stop using atomic
helpers and do the same thing inside the driver, but that doesn't help
any of the cases where you have a separate kms and gpu driver.

> As far as I can see you can also implement completely inside the backend
> by starting a timer on enable_signaling, don't you?

Not really.. I mean, the fact that something waited on a fence could
be a useful input signal to gpu freq governor, but it is entirely
insufficient..

If the cpu is spending a lot of time waiting on a fence, cpufreq will
clock down so you spend less time waiting.  And no problem has been
solved.  You absolutely need the concept of a missed deadline, and a
timer doesn't give you that.

BR,
-R

> Christian.
>
> Am 19.05.21 um 20:38 schrieb Rob Clark:
> > From: Rob Clark 
> >
> > Add a way to hint to the fence signaler that a fence waiter has missed a
> > deadline waiting on the fence.
> >
> > In some cases, missing a vblank can result in lower gpu utilization,
> > when really we want to go in the opposite direction and boost gpu freq.
> > The boost callback gives some feedback to the fence signaler that we
> > are missing deadlines, so it can take this into account in it's freq/
> > utilization calculations.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >   include/linux/dma-fence.h | 26 ++
> >   1 file changed, 26 insertions(+)
> >
> > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> > index 9f12efaaa93a..172702521acc 100644
> > --- a/include/linux/dma-fence.h
> > +++ b/include/linux/dma-fence.h
> > @@ -231,6 +231,17 @@ struct dma_fence_ops {
> >   signed long (*wait)(struct dma_fence *fence,
> >   bool intr, signed long timeout);
> >
> > + /**
> > +  * @boost:
> > +  *
> > +  * Optional callback, to indicate that a fence waiter missed a 
> > deadline.
> > +  * This can serve as a signal that (if possible) whatever signals the
> > +  * fence should boost it's clocks.
> > +  *
> > +  * This can be called in any context that can call dma_fence_wait().
> > +  */
> > + void (*boost)(struct dma_fence *fence);
> > +
> >   /**
> >* @release:
> >*
> > @@ -586,6 +597,21 @@ static inline signed long dma_fence_wait(struct 
> > dma_fence *fence, bool intr)
> >   return ret < 0 ? ret : 0;
> >   }
> >
> > +/**
> > + * dma_fence_boost - hint from waiter that it missed a deadline
> > + *
> > + * @fence: the fence that caused the missed deadline
> > + *
> > + * This function gives a hint from a fence waiter that a deadline was
> > + * missed, so that the fence signaler can factor this in to device
> > + * power state decisions
> > + */
> > +static inline void dma_fence_boost(struct dma_fence *fence)
> > +{
> > + if (fence->ops->boost)
> > + fence->ops->boost(fence);
> > +}
> > +
> >   struct dma_fence *dma_fence_get_stub(void);
> >   u64 dma_fence_context_alloc(unsigned num);
> >
>

Re: [PATCH] drm/i915/gt: fix typo issue

[Matthew Auld]

On Thu, 20 May 2021 at 09:23, samirweng1979  wrote:
>
> From: wengjianfeng 
>
> change 'freqency' to 'frequency'.
>
> Signed-off-by: wengjianfeng 

Pushed to intel-gt-next. Thanks.

[PULL] drm-misc-fixes

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week fix for drm-misc-fixes

Maxime

drm-misc-fixes-2021-05-20:
Just a single fix for a dma-buf related WARN
The following changes since commit c55b44c9386f3ee1b08752638559f19deaf6040d:

  Merge drm/drm-fixes into drm-misc-fixes (2021-05-11 13:35:52 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-05-20

for you to fetch changes up to 7e008b02557ccece4d2c31fb0eaf6243cbc87121:

  dma-buf: fix unintended pin/unpin warnings (2021-05-20 14:02:27 +0200)


Just a single fix for a dma-buf related WARN


Christian König (1):
  dma-buf: fix unintended pin/unpin warnings

 drivers/dma-buf/dma-buf.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Daniel Vetter]

On Wed, May 19, 2021 at 11:17:24PM +, Nieto, David M wrote:
> [AMD Official Use Only]
> 
> Parsing over 550 processes for fdinfo is taking between 40-100ms single
> threaded in a 2GHz skylake IBRS within a VM using simple string
> comparisons and DIRent parsing. And that is pretty much the worst case
> scenario with some more optimized implementations.

I think this is plenty ok, and if it's not you could probably make this
massively faster with io_uring for all the fs operations and whack a
parser-generator on top for real parsing speed.

So imo we shouldn't worry about algorithmic inefficiency of the fdinfo
approach at all, and focuse more on trying to reasonably (but not too
much, this is still drm render stuff after all) standardize how it works
and how we'll extend it all. I think there's tons of good suggestions in
this thread on this topic already.

/me out
-Daniel

> 
> David
> 
> From: Daniel Vetter 
> Sent: Wednesday, May 19, 2021 11:23 AM
> To: Tvrtko Ursulin 
> Cc: Daniel Stone ; jhubb...@nvidia.com 
> ; nouv...@lists.freedesktop.org 
> ; Intel Graphics Development 
> ; Maling list - DRI developers 
> ; Simon Ser ; Koenig, 
> Christian ; arit...@nvidia.com 
> ; Nieto, David M 
> Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness
> 
> On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
>  wrote:
> >
> >
> > On 18/05/2021 10:40, Tvrtko Ursulin wrote:
> > >
> > > On 18/05/2021 10:16, Daniel Stone wrote:
> > >> Hi,
> > >>
> > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
> > >>  wrote:
> > >>> I was just wondering if stat(2) and a chrdev major check would be a
> > >>> solid criteria to more efficiently (compared to parsing the text
> > >>> content) detect drm files while walking procfs.
> > >>
> > >> Maybe I'm missing something, but is the per-PID walk actually a
> > >> measurable performance issue rather than just a bit unpleasant?
> > >
> > > Per pid and per each open fd.
> > >
> > > As said in the other thread what bothers me a bit in this scheme is that
> > > the cost of obtaining GPU usage scales based on non-GPU criteria.
> > >
> > > For use case of a top-like tool which shows all processes this is a
> > > smaller additional cost, but then for a gpu-top like tool it is somewhat
> > > higher.
> >
> > To further expand, not only cost would scale per pid multiplies per open
> > fd, but to detect which of the fds are DRM I see these three options:
> >
> > 1) Open and parse fdinfo.
> > 2) Name based matching ie /dev/dri/.. something.
> > 3) Stat the symlink target and check for DRM major.
> 
> stat with symlink following should be plenty fast.
> 
> > All sound quite sub-optimal to me.
> >
> > Name based matching is probably the least evil on system resource usage
> > (Keeping the dentry cache too hot? Too many syscalls?), even though
> > fundamentally I don't it is the right approach.
> >
> > What happens with dup(2) is another question.
> 
> We need benchmark numbers showing that on anything remotely realistic
> it's an actual problem. Until we've demonstrated it's a real problem
> we don't need to solve it.
> 
> E.g. top with any sorting enabled also parses way more than it
> displays on every update. It seems to be doing Just Fine (tm).
> 
> > Does anyone have any feedback on the /proc//gpu idea at all?
> 
> When we know we have a problem to solve we can take a look at solutions.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=04%7C01%7CDavid.Nieto%40amd.com%7Cf6aea97532cf41f916de08d91af32cc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637570453997158377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4CFrY9qWbJREcIcSzeO9KIn2P%2Fw6k%2BYdNlh6rdS%2BEh4%3D&reserved=0

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

Re: [RFC 1/3] dma-fence: Add boost fence op

[Christian König]

Am 20.05.21 um 16:07 schrieb Rob Clark:

On Wed, May 19, 2021 at 11:47 PM Christian König
 wrote:

Uff, that looks very hardware specific to me.

Howso?  I'm not sure I agree.. and even if it was not useful for some
hw, it should be useful for enough drivers (and harm no drivers), so I
still think it is a good idea

The fallback plan is to go the i915 route and stop using atomic
helpers and do the same thing inside the driver, but that doesn't help
any of the cases where you have a separate kms and gpu driver.


Yeah, that's certainly not something we want.


As far as I can see you can also implement completely inside the backend
by starting a timer on enable_signaling, don't you?

Not really.. I mean, the fact that something waited on a fence could
be a useful input signal to gpu freq governor, but it is entirely
insufficient..

If the cpu is spending a lot of time waiting on a fence, cpufreq will
clock down so you spend less time waiting.  And no problem has been
solved.  You absolutely need the concept of a missed deadline, and a
timer doesn't give you that.


Ok then I probably don't understand the use case here.

What exactly do you try to solve?

Thanks,
Christian.



BR,
-R


Christian.

Am 19.05.21 um 20:38 schrieb Rob Clark:

From: Rob Clark 

Add a way to hint to the fence signaler that a fence waiter has missed a
deadline waiting on the fence.

In some cases, missing a vblank can result in lower gpu utilization,
when really we want to go in the opposite direction and boost gpu freq.
The boost callback gives some feedback to the fence signaler that we
are missing deadlines, so it can take this into account in it's freq/
utilization calculations.

Signed-off-by: Rob Clark 
---
   include/linux/dma-fence.h | 26 ++
   1 file changed, 26 insertions(+)

diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 9f12efaaa93a..172702521acc 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -231,6 +231,17 @@ struct dma_fence_ops {
   signed long (*wait)(struct dma_fence *fence,
   bool intr, signed long timeout);

+ /**
+  * @boost:
+  *
+  * Optional callback, to indicate that a fence waiter missed a deadline.
+  * This can serve as a signal that (if possible) whatever signals the
+  * fence should boost it's clocks.
+  *
+  * This can be called in any context that can call dma_fence_wait().
+  */
+ void (*boost)(struct dma_fence *fence);
+
   /**
* @release:
*
@@ -586,6 +597,21 @@ static inline signed long dma_fence_wait(struct dma_fence 
*fence, bool intr)
   return ret < 0 ? ret : 0;
   }

+/**
+ * dma_fence_boost - hint from waiter that it missed a deadline
+ *
+ * @fence: the fence that caused the missed deadline
+ *
+ * This function gives a hint from a fence waiter that a deadline was
+ * missed, so that the fence signaler can factor this in to device
+ * power state decisions
+ */
+static inline void dma_fence_boost(struct dma_fence *fence)
+{
+ if (fence->ops->boost)
+ fence->ops->boost(fence);
+}
+
   struct dma_fence *dma_fence_get_stub(void);
   u64 dma_fence_context_alloc(unsigned num);

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Christian König]

Am 20.05.21 um 16:11 schrieb Daniel Vetter:

On Wed, May 19, 2021 at 11:17:24PM +, Nieto, David M wrote:

[AMD Official Use Only]

Parsing over 550 processes for fdinfo is taking between 40-100ms single
threaded in a 2GHz skylake IBRS within a VM using simple string
comparisons and DIRent parsing. And that is pretty much the worst case
scenario with some more optimized implementations.

I think this is plenty ok, and if it's not you could probably make this
massively faster with io_uring for all the fs operations and whack a
parser-generator on top for real parsing speed.


Well if it becomes a problem fixing the debugfs "clients" file and 
making it sysfs shouldn't be much of a problem later on.


Christian.



So imo we shouldn't worry about algorithmic inefficiency of the fdinfo
approach at all, and focuse more on trying to reasonably (but not too
much, this is still drm render stuff after all) standardize how it works
and how we'll extend it all. I think there's tons of good suggestions in
this thread on this topic already.

/me out
-Daniel


David

From: Daniel Vetter 
Sent: Wednesday, May 19, 2021 11:23 AM
To: Tvrtko Ursulin 
Cc: Daniel Stone ; jhubb...@nvidia.com ; nouv...@lists.freedesktop.org 
; Intel Graphics Development ; Maling list - DRI 
developers ; Simon Ser ; Koenig, Christian 
; arit...@nvidia.com ; Nieto, David M 
Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
 wrote:


On 18/05/2021 10:40, Tvrtko Ursulin wrote:

On 18/05/2021 10:16, Daniel Stone wrote:

Hi,

On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
 wrote:

I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect drm files while walking procfs.

Maybe I'm missing something, but is the per-PID walk actually a
measurable performance issue rather than just a bit unpleasant?

Per pid and per each open fd.

As said in the other thread what bothers me a bit in this scheme is that
the cost of obtaining GPU usage scales based on non-GPU criteria.

For use case of a top-like tool which shows all processes this is a
smaller additional cost, but then for a gpu-top like tool it is somewhat
higher.

To further expand, not only cost would scale per pid multiplies per open
fd, but to detect which of the fds are DRM I see these three options:

1) Open and parse fdinfo.
2) Name based matching ie /dev/dri/.. something.
3) Stat the symlink target and check for DRM major.

stat with symlink following should be plenty fast.


All sound quite sub-optimal to me.

Name based matching is probably the least evil on system resource usage
(Keeping the dentry cache too hot? Too many syscalls?), even though
fundamentally I don't it is the right approach.

What happens with dup(2) is another question.

We need benchmark numbers showing that on anything remotely realistic
it's an actual problem. Until we've demonstrated it's a real problem
we don't need to solve it.

E.g. top with any sorting enabled also parses way more than it
displays on every update. It seems to be doing Just Fine (tm).


Does anyone have any feedback on the /proc//gpu idea at all?

When we know we have a problem to solve we can take a look at solutions.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=04%7C01%7CChristian.Koenig%40amd.com%7Ced2eccaa081d4cd336d408d91b991ee0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637571166744508313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZihrnanU70nJAM6bHYCjRnURDDCIdwGI85imjGd%2FNgs%3D&reserved=0

Re: [PATCH] dma-buf: fix unintended pin/unpin warnings

[Daniel Vetter]

On Thu, May 20, 2021 at 01:37:47PM +0200, Christian König wrote:
> Am 17.05.21 um 16:57 schrieb Daniel Vetter:
> > On Mon, May 17, 2021 at 10:09:13AM -0400, Alex Deucher wrote:
> > > On Mon, May 17, 2021 at 7:57 AM Christian König
> > >  wrote:
> > > > DMA-buf internal users call the pin/unpin functions without having a
> > > > dynamic attachment. Avoid the warning and backtrace in the logs.
> > > > 
> > > > Signed-off-by: Christian König 
> > > > Bugs: https://gitlab.freedesktop.org/drm/intel/-/issues/3481
> > > > Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
> > > > CC: sta...@kernel.org
> > > Reviewed-by: Alex Deucher 
> > Hm this means we're losing the dma_resv_assert_held check, do we have that
> > in amdgpu callbacks to make sure we're not accidentally breaking stuff
> > later on?
> 
> Mhm, well this is just for calling the pin/unpin internally from the DMA-buf
> framework itself.

It's both, but currently I think no users for it (since it would be
pinning for display).

Maybe we could do __ internal wrappers to keep the lockdep checks?

> Need to double check, but I think all those cases either have a
> dma_resv_assert_held() or are locking the reservation themselves before
> calling the function.

Yeah right now it's still all good, but that changes easily :-)

> But yeah, rather good point.

Do you plan to type something that I can ack?
-Daniel

> 
> Christian.
> 
> > 
> > But yeah lgtm, Reviewed-by: Daniel Vetter 
> > 
> > > > ---
> > > >   drivers/dma-buf/dma-buf.c | 10 +-
> > > >   1 file changed, 5 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > > index f264b70c383e..eadd1eaa2fb5 100644
> > > > --- a/drivers/dma-buf/dma-buf.c
> > > > +++ b/drivers/dma-buf/dma-buf.c
> > > > @@ -760,7 +760,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, 
> > > > struct device *dev,
> > > > 
> > > >  if (dma_buf_is_dynamic(attach->dmabuf)) {
> > > >  dma_resv_lock(attach->dmabuf->resv, NULL);
> > > > -   ret = dma_buf_pin(attach);
> > > > +   ret = dmabuf->ops->pin(attach);
> > > >  if (ret)
> > > >  goto err_unlock;
> > > >  }
> > > > @@ -786,7 +786,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, 
> > > > struct device *dev,
> > > > 
> > > >   err_unpin:
> > > >  if (dma_buf_is_dynamic(attach->dmabuf))
> > > > -   dma_buf_unpin(attach);
> > > > +   dmabuf->ops->unpin(attach);
> > > > 
> > > >   err_unlock:
> > > >  if (dma_buf_is_dynamic(attach->dmabuf))
> > > > @@ -843,7 +843,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> > > > dma_buf_attachment *attach)
> > > >  __unmap_dma_buf(attach, attach->sgt, attach->dir);
> > > > 
> > > >  if (dma_buf_is_dynamic(attach->dmabuf)) {
> > > > -   dma_buf_unpin(attach);
> > > > +   dmabuf->ops->unpin(attach);
> > > >  dma_resv_unlock(attach->dmabuf->resv);
> > > >  }
> > > >  }
> > > > @@ -956,7 +956,7 @@ struct sg_table *dma_buf_map_attachment(struct 
> > > > dma_buf_attachment *attach,
> > > >  if (dma_buf_is_dynamic(attach->dmabuf)) {
> > > >  dma_resv_assert_held(attach->dmabuf->resv);
> > > >  if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
> > > > -   r = dma_buf_pin(attach);
> > > > +   r = attach->dmabuf->ops->pin(attach);
> > > >  if (r)
> > > >  return ERR_PTR(r);
> > > >  }
> > > > @@ -968,7 +968,7 @@ struct sg_table *dma_buf_map_attachment(struct 
> > > > dma_buf_attachment *attach,
> > > > 
> > > >  if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) &&
> > > >   !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
> > > > -   dma_buf_unpin(attach);
> > > > +   attach->dmabuf->ops->unpin(attach);
> > > > 
> > > >  if (!IS_ERR(sg_table) && 
> > > > attach->dmabuf->ops->cache_sgt_mapping) {
> > > >  attach->sgt = sg_table;
> > > > --
> > > > 2.25.1
> > > > 
> 

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

Re: [RFC] Add DMA_RESV_USAGE flags

[Daniel Vetter]

On Thu, May 20, 2021 at 10:13:38AM +0200, Michel Dänzer wrote:
> On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer  wrote:
> >>
> >> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> >>> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer  wrote:
> 
>  On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
> > On Tue, May 18, 2021 at 4:17 PM Daniel Vetter  wrote:
> >>
> >> On Tue, May 18, 2021 at 7:40 PM Christian König
> >>  wrote:
> >>>
> >>> Am 18.05.21 um 18:48 schrieb Daniel Vetter:
>  On Tue, May 18, 2021 at 2:49 PM Christian König
>   wrote:
> 
> > And as long as we are all inside amdgpu we also don't have any 
> > oversync,
> > the issue only happens when we share dma-bufs with i915 (radeon and
> > AFAIK nouveau does the right thing as well).
>  Yeah because then you can't use the amdgpu dma_resv model anymore and
>  have to use the one atomic helpers use. Which is also the one that
>  e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
>  so as soon as that lands and someone starts using it, something has 
>  to
>  adapt _anytime_ you have a dma-buf hanging around. Not just when it's
>  shared with another device.
> >>>
> >>> Yeah, and that is exactly the reason why I will NAK this uAPI change.
> >>>
> >>> This doesn't works for amdgpu at all for the reasons outlined above.
> >>
> >> Uh that's really not how uapi works. "my driver is right, everyone
> >> else is wrong" is not how cross driver contracts are defined. If that
> >> means a perf impact until you've fixed your rules, that's on you.
> >>
> >> Also you're a few years too late with nacking this, it's already uapi
> >> in the form of the dma-buf poll() support.
> >
> > ^^  My fancy new ioctl doesn't expose anything that isn't already
> > there.  It just lets you take a snap-shot of a wait instead of doing
> > an active wait which might end up with more fences added depending on
> > interrupts and retries.  The dma-buf poll waits on all fences for
> > POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.
> 
>  Note that the dma-buf poll support could be useful to Wayland 
>  compositors for the same purpose as Jason's new ioctl (only using client 
>  buffers which have finished drawing for an output frame, to avoid 
>  missing a refresh cycle due to client drawing), *if* it didn't work 
>  differently with amdgpu.
> 
>  Am I understanding correctly that Jason's new ioctl would also work 
>  differently with amdgpu as things stand currently? If so, that would be 
>  a real bummer and might hinder adoption of the ioctl by Wayland 
>  compositors.
> >>>
> >>> My new ioctl has identical semantics to poll().  It just lets you take
> >>> a snapshot in time to wait on later instead of waiting on whatever
> >>> happens to be set right now.  IMO, having identical semantics to
> >>> poll() isn't something we want to change.
> >>
> >> Agreed.
> >>
> >> I'd argue then that making amdgpu poll semantics match those of other 
> >> drivers is a pre-requisite for the new ioctl, otherwise it seems unlikely 
> >> that the ioctl will be widely adopted.
> > 
> > This seems backwards, because that means useful improvements in all
> > other drivers are stalled until amdgpu is fixed.
> > 
> > I think we need agreement on what the rules are, reasonable plan to
> > get there, and then that should be enough to unblock work in the wider
> > community. Holding the community at large hostage because one driver
> > is different is really not great.
> 
> I think we're in violent agreement. :) The point I was trying to make is
> that amdgpu really needs to be fixed to be consistent with other drivers
> ASAP.

It's not that easy at all. I think best case we're looking at about a one
year plan to get this into shape, taking into account usual release/distro
update latencies.

Best case.

But also it's not a really big issue, since this shouldn't stop
compositors from using poll on dma-buf fd or the sync_file stuff from
Jason: The use-case for this in compositors is to avoid a single client
stalling the entire desktop. If a driver lies by not setting the exclusive
fence when expected, you simply don't get this stall avoidance benefit of
misbehaving clients. But also this needs a gpu scheduler and higher
priority for the compositor (or a lot of hw planes so you can composite
with them alone), so it's all fairly academic issue.

Iow amdgpu being different on these wont cause any actual issues I think.

The only case that does break is when the compositor does an mmap on the
dma-buf fd and relies on poll to indicate when the rendering is done. Not
even sure amdgpu supports mmap on dma-buf or not. That's the only case I
could think of which would result in actual co

[PATCH v2] Documentation: gpu: Mention the requirements for new properties

[Maxime Ripard]

New KMS properties come with a bunch of requirements to avoid each
driver from running their own, inconsistent, set of properties,
eventually leading to issues like property conflicts, inconsistencies
between drivers and semantics, etc.

Let's document what we expect.

Cc: Alexandre Belloni 
Cc: Alexandre Torgue 
Cc: Alex Deucher 
Cc: Alison Wang 
Cc: Alyssa Rosenzweig 
Cc: Andrew Jeffery 
Cc: Andrzej Hajda 
Cc: Anitha Chrisanthus 
Cc: Benjamin Gaignard 
Cc: Ben Skeggs 
Cc: Boris Brezillon 
Cc: Brian Starkey 
Cc: Chen Feng 
Cc: Chen-Yu Tsai 
Cc: Christian Gmeiner 
Cc: "Christian König" 
Cc: Chun-Kuang Hu 
Cc: Edmund Dea 
Cc: Eric Anholt 
Cc: Fabio Estevam 
Cc: Gerd Hoffmann 
Cc: Haneen Mohammed 
Cc: Hans de Goede 
Cc: "Heiko Stübner" 
Cc: Huang Rui 
Cc: Hyun Kwon 
Cc: Inki Dae 
Cc: Jani Nikula 
Cc: Jernej Skrabec 
Cc: Jerome Brunet 
Cc: Joel Stanley 
Cc: John Stultz 
Cc: Jonas Karlman 
Cc: Jonathan Hunter 
Cc: Joonas Lahtinen 
Cc: Joonyoung Shim 
Cc: Jyri Sarha 
Cc: Kevin Hilman 
Cc: Kieran Bingham 
Cc: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Laurent Pinchart 
Cc: Linus Walleij 
Cc: Liviu Dudau 
Cc: Lucas Stach 
Cc: Ludovic Desroches 
Cc: Marek Vasut 
Cc: Martin Blumenstingl 
Cc: Matthias Brugger 
Cc: Maxime Coquelin 
Cc: Maxime Ripard 
Cc: Melissa Wen 
Cc: Neil Armstrong 
Cc: Nicolas Ferre 
Cc: "Noralf Trønnes" 
Cc: NXP Linux Team 
Cc: Oleksandr Andrushchenko 
Cc: Patrik Jakobsson 
Cc: Paul Cercueil 
Cc: Pengutronix Kernel Team 
Cc: Philippe Cornu 
Cc: Philipp Zabel 
Cc: Qiang Yu 
Cc: Rob Clark 
Cc: Robert Foss 
Cc: Rob Herring 
Cc: Rodrigo Siqueira 
Cc: Rodrigo Vivi 
Cc: Roland Scheidegger 
Cc: Russell King 
Cc: Sam Ravnborg 
Cc: Sandy Huang 
Cc: Sascha Hauer 
Cc: Sean Paul 
Cc: Seung-Woo Kim 
Cc: Shawn Guo 
Cc: Stefan Agner 
Cc: Steven Price 
Cc: Sumit Semwal 
Cc: Thierry Reding 
Cc: Tian Tao 
Cc: Tomeu Vizoso 
Cc: Tomi Valkeinen 
Cc: VMware Graphics 
Cc: Xinliang Liu 
Cc: Xinwei Kong 
Cc: Yannick Fertre 
Cc: Zack Rusin 
Reviewed-by: Daniel Vetter 
Signed-off-by: Maxime Ripard 

---

Changes from v2:
  - Typos and wording reported by Daniel and Alex
---
 Documentation/gpu/drm-kms.rst | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..c28b464dd397 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -463,6 +463,25 @@ KMS Properties
 This section of the documentation is primarily aimed at user-space developers.
 For the driver APIs, see the other sections.
 
+Requirements
+
+
+KMS drivers might need to add extra properties to support new features.
+Each new property introduced in a driver need to meet a few
+requirements, in addition to the one mentioned above.:
+
+- It must be standardized, with some documentation to describe how the
+  property can be used.
+
+- It must provide a generic helper in the core code to register that
+  property on the object it attaches to.
+
+- Its content must be decoded by the core and provided in the object's
+  associated state structure. That includes anything drivers might want to
+  precompute, like :c:type:`struct drm_clip_rect ` for planes.
+
+- An IGT test must be submitted where reasonable.
+
 Property Types and Blob Property Support
 
 
-- 
2.31.1

Re: [PATCH] drm/i915: Use DRIVER_NAME for tracing unattached requests

[Daniel Vetter]

On Thu, May 20, 2021 at 08:35:14AM +0100, Matthew Auld wrote:
> From: Chris Wilson 
> 
> The first tracepoint for a request is trace_dma_fence_init called before
> we have associated the request with a device. The tracepoint uses
> fence->ops->get_driver_name() as a pretty name, and as we try to report
> the device name this oopses as it is then NULL. Support the early
> tracepoint by reporting the DRIVER_NAME instead of the actual device
> name.
> 
> Note that rq->engine remains during the course of request recycling
> (SLAB_TYPESAFE_BY_RCU). For the physical engines, the pointer remains
> valid, however a virtual engine may be destroyed after the request is
> retired. If we process a preempt-to-busy completed request along the
> virtual engine, we should make sure we mark the request as no longer
> belonging to the virtual engine to remove the dangling pointers from the
> tracepoint.

Why can't we assign the request beforehand? The idea behind these
tracepoints is that they actually match up, if trace_dma_fence_init is
different, then we're breaking that.
-Daniel

> 
> Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring 
> seqno")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Chintan M Patel 
> Cc: Andi Shyti 
> Cc:  # v5.7+
> Signed-off-by: Matthew Auld 
> ---
>  .../drm/i915/gt/intel_execlists_submission.c  | 20 ++-
>  drivers/gpu/drm/i915/i915_request.c   |  7 ++-
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index de124870af44..75604e927d34 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3249,6 +3249,18 @@ static struct list_head *virtual_queue(struct 
> virtual_engine *ve)
>   return &ve->base.execlists.default_priolist.requests;
>  }
>  
> +static void
> +virtual_submit_completed(struct virtual_engine *ve, struct i915_request *rq)
> +{
> + GEM_BUG_ON(!__i915_request_is_complete(rq));
> + GEM_BUG_ON(rq->engine != &ve->base);
> +
> + __i915_request_submit(rq);
> +
> + /* Remove the dangling pointer to the stale virtual engine */
> + WRITE_ONCE(rq->engine, ve->siblings[0]);
> +}
> +
>  static void rcu_virtual_context_destroy(struct work_struct *wrk)
>  {
>   struct virtual_engine *ve =
> @@ -3265,8 +3277,7 @@ static void rcu_virtual_context_destroy(struct 
> work_struct *wrk)
>  
>   old = fetch_and_zero(&ve->request);
>   if (old) {
> - GEM_BUG_ON(!__i915_request_is_complete(old));
> - __i915_request_submit(old);
> + virtual_submit_completed(ve, old);
>   i915_request_put(old);
>   }
>  
> @@ -3538,13 +3549,12 @@ static void virtual_submit_request(struct 
> i915_request *rq)
>  
>   /* By the time we resubmit a request, it may be completed */
>   if (__i915_request_is_complete(rq)) {
> - __i915_request_submit(rq);
> + virtual_submit_completed(ve, rq);
>   goto unlock;
>   }
>  
>   if (ve->request) { /* background completion from preempt-to-busy */
> - GEM_BUG_ON(!__i915_request_is_complete(ve->request));
> - __i915_request_submit(ve->request);
> + virtual_submit_completed(ve, ve->request);
>   i915_request_put(ve->request);
>   }
>  
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 970d8f4986bb..aa124adb1051 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -61,7 +61,12 @@ static struct i915_global_request {
>  
>  static const char *i915_fence_get_driver_name(struct dma_fence *fence)
>  {
> - return dev_name(to_request(fence)->engine->i915->drm.dev);
> + struct i915_request *rq = to_request(fence);
> +
> + if (unlikely(!rq->engine)) /* not yet attached to any device */
> + return DRIVER_NAME;
> +
> + return dev_name(rq->engine->i915->drm.dev);
>  }
>  
>  static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
> -- 
> 2.26.3
> 

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

Re: [RFC] Add DMA_RESV_USAGE flags

[Michel Dänzer]

On 2021-05-20 4:18 p.m., Daniel Vetter wrote:
> On Thu, May 20, 2021 at 10:13:38AM +0200, Michel Dänzer wrote:
>> On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
>>> On Wed, May 19, 2021 at 5:48 PM Michel Dänzer  wrote:

 On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer  wrote:
>>
>> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
>>> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter  wrote:

 On Tue, May 18, 2021 at 7:40 PM Christian König
  wrote:
>
> Am 18.05.21 um 18:48 schrieb Daniel Vetter:
>> On Tue, May 18, 2021 at 2:49 PM Christian König
>>  wrote:
>>
>>> And as long as we are all inside amdgpu we also don't have any 
>>> oversync,
>>> the issue only happens when we share dma-bufs with i915 (radeon and
>>> AFAIK nouveau does the right thing as well).
>> Yeah because then you can't use the amdgpu dma_resv model anymore and
>> have to use the one atomic helpers use. Which is also the one that
>> e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
>> so as soon as that lands and someone starts using it, something has 
>> to
>> adapt _anytime_ you have a dma-buf hanging around. Not just when it's
>> shared with another device.
>
> Yeah, and that is exactly the reason why I will NAK this uAPI change.
>
> This doesn't works for amdgpu at all for the reasons outlined above.

 Uh that's really not how uapi works. "my driver is right, everyone
 else is wrong" is not how cross driver contracts are defined. If that
 means a perf impact until you've fixed your rules, that's on you.

 Also you're a few years too late with nacking this, it's already uapi
 in the form of the dma-buf poll() support.
>>>
>>> ^^  My fancy new ioctl doesn't expose anything that isn't already
>>> there.  It just lets you take a snap-shot of a wait instead of doing
>>> an active wait which might end up with more fences added depending on
>>> interrupts and retries.  The dma-buf poll waits on all fences for
>>> POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.
>>
>> Note that the dma-buf poll support could be useful to Wayland 
>> compositors for the same purpose as Jason's new ioctl (only using client 
>> buffers which have finished drawing for an output frame, to avoid 
>> missing a refresh cycle due to client drawing), *if* it didn't work 
>> differently with amdgpu.
>>
>> Am I understanding correctly that Jason's new ioctl would also work 
>> differently with amdgpu as things stand currently? If so, that would be 
>> a real bummer and might hinder adoption of the ioctl by Wayland 
>> compositors.
>
> My new ioctl has identical semantics to poll().  It just lets you take
> a snapshot in time to wait on later instead of waiting on whatever
> happens to be set right now.  IMO, having identical semantics to
> poll() isn't something we want to change.

 Agreed.

 I'd argue then that making amdgpu poll semantics match those of other 
 drivers is a pre-requisite for the new ioctl, otherwise it seems unlikely 
 that the ioctl will be widely adopted.
>>>
>>> This seems backwards, because that means useful improvements in all
>>> other drivers are stalled until amdgpu is fixed.
>>>
>>> I think we need agreement on what the rules are, reasonable plan to
>>> get there, and then that should be enough to unblock work in the wider
>>> community. Holding the community at large hostage because one driver
>>> is different is really not great.
>>
>> I think we're in violent agreement. :) The point I was trying to make is
>> that amdgpu really needs to be fixed to be consistent with other drivers
>> ASAP.
> 
> It's not that easy at all. I think best case we're looking at about a one
> year plan to get this into shape, taking into account usual release/distro
> update latencies.
> 
> Best case.
> 
> But also it's not a really big issue, since this shouldn't stop
> compositors from using poll on dma-buf fd or the sync_file stuff from
> Jason: The use-case for this in compositors is to avoid a single client
> stalling the entire desktop. If a driver lies by not setting the exclusive
> fence when expected, you simply don't get this stall avoidance benefit of
> misbehaving clients. But also this needs a gpu scheduler and higher
> priority for the compositor (or a lot of hw planes so you can composite
> with them alone), so it's all fairly academic issue.

AFAIK current AMD GPUs have everything needed to make this work, it would just 
need to be hooked up for high priority EGL contexts (which at least mutter 
already uses when available) in amdgpu & radeonsi.


-- 
Earthling Michel Dänzer   | 

Re: [RFC 1/3] dma-fence: Add boost fence op

[Rob Clark]

On Thu, May 20, 2021 at 7:11 AM Christian König
 wrote:
>
>
>
> Am 20.05.21 um 16:07 schrieb Rob Clark:
> > On Wed, May 19, 2021 at 11:47 PM Christian König
> >  wrote:
> >> Uff, that looks very hardware specific to me.
> > Howso?  I'm not sure I agree.. and even if it was not useful for some
> > hw, it should be useful for enough drivers (and harm no drivers), so I
> > still think it is a good idea
> >
> > The fallback plan is to go the i915 route and stop using atomic
> > helpers and do the same thing inside the driver, but that doesn't help
> > any of the cases where you have a separate kms and gpu driver.
>
> Yeah, that's certainly not something we want.
>
> >> As far as I can see you can also implement completely inside the backend
> >> by starting a timer on enable_signaling, don't you?
> > Not really.. I mean, the fact that something waited on a fence could
> > be a useful input signal to gpu freq governor, but it is entirely
> > insufficient..
> >
> > If the cpu is spending a lot of time waiting on a fence, cpufreq will
> > clock down so you spend less time waiting.  And no problem has been
> > solved.  You absolutely need the concept of a missed deadline, and a
> > timer doesn't give you that.
>
> Ok then I probably don't understand the use case here.
>
> What exactly do you try to solve?

Basically situations where you are ping-ponging between GPU and CPU..
for example if you are double buffering instead of triple buffering,
and doing vblank sync'd pageflips.  The GPU, without any extra signal,
could get stuck at 30fps and a low gpu freq, because it ends up idle
while waiting for an extra vblank cycle for the next back-buffer to
become available.  Whereas if it boosted up to a higher freq and
stopped missing a vblank deadline, it would be less idle due to
getting the next back-buffer sooner (due to not missing a vblank
deadline).

BR,
-R

> Thanks,
> Christian.
>
> >
> > BR,
> > -R
> >
> >> Christian.
> >>
> >> Am 19.05.21 um 20:38 schrieb Rob Clark:
> >>> From: Rob Clark 
> >>>
> >>> Add a way to hint to the fence signaler that a fence waiter has missed a
> >>> deadline waiting on the fence.
> >>>
> >>> In some cases, missing a vblank can result in lower gpu utilization,
> >>> when really we want to go in the opposite direction and boost gpu freq.
> >>> The boost callback gives some feedback to the fence signaler that we
> >>> are missing deadlines, so it can take this into account in it's freq/
> >>> utilization calculations.
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> ---
> >>>include/linux/dma-fence.h | 26 ++
> >>>1 file changed, 26 insertions(+)
> >>>
> >>> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> >>> index 9f12efaaa93a..172702521acc 100644
> >>> --- a/include/linux/dma-fence.h
> >>> +++ b/include/linux/dma-fence.h
> >>> @@ -231,6 +231,17 @@ struct dma_fence_ops {
> >>>signed long (*wait)(struct dma_fence *fence,
> >>>bool intr, signed long timeout);
> >>>
> >>> + /**
> >>> +  * @boost:
> >>> +  *
> >>> +  * Optional callback, to indicate that a fence waiter missed a 
> >>> deadline.
> >>> +  * This can serve as a signal that (if possible) whatever signals 
> >>> the
> >>> +  * fence should boost it's clocks.
> >>> +  *
> >>> +  * This can be called in any context that can call dma_fence_wait().
> >>> +  */
> >>> + void (*boost)(struct dma_fence *fence);
> >>> +
> >>>/**
> >>> * @release:
> >>> *
> >>> @@ -586,6 +597,21 @@ static inline signed long dma_fence_wait(struct 
> >>> dma_fence *fence, bool intr)
> >>>return ret < 0 ? ret : 0;
> >>>}
> >>>
> >>> +/**
> >>> + * dma_fence_boost - hint from waiter that it missed a deadline
> >>> + *
> >>> + * @fence: the fence that caused the missed deadline
> >>> + *
> >>> + * This function gives a hint from a fence waiter that a deadline was
> >>> + * missed, so that the fence signaler can factor this in to device
> >>> + * power state decisions
> >>> + */
> >>> +static inline void dma_fence_boost(struct dma_fence *fence)
> >>> +{
> >>> + if (fence->ops->boost)
> >>> + fence->ops->boost(fence);
> >>> +}
> >>> +
> >>>struct dma_fence *dma_fence_get_stub(void);
> >>>u64 dma_fence_context_alloc(unsigned num);
> >>>
>