Re: [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[Jani Nikula]

On Thu, 14 Jan 2021, Steven Rostedt  wrote:
> [ Forgot to add those on the commit itself ]
>
> -- Steve
>
>
> On Thu, 14 Jan 2021 16:32:06 -0500
> Steven Rostedt  wrote:
>
>> On reboot, one of my test boxes now triggers the following warning:
>> 
>>  [ cut here ]
>>  RPM raw-wakeref not held
>>  WARNING: CPU: 4 PID: 1 at drivers/gpu/drm/i915/intel_runtime_pm.h:106 
>> gen6_write32+0x1bc/0x2a0 [i915]
>>  Modules linked in: ebtable_filter ebtables bridge stp llc ip6t_REJECT 
>> nf_reject_ipv6 vsock vmw_vmci xt_state xt_conntrack nf_conntrack 
>> nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables snd_hda_codec_hdmi 
>> snd_hda_codec_realtek snd_hda_codec_generic le
>> 15 snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep i2c_algo_bit 
>> snd_hda_core snd_seq intel_rapl_msr snd_seq_device intel_rapl_common snd_pcm 
>> x86_pkg_temp_thermal intel_powerclamp snd_timer snd coretemp kvm_intel 
>> soundcore kvm mei_wdt irqbypass joydev 
>> _pmc_bxt hp_wmi wmi_bmof sparse_keymap rfkill iTCO_vendor_support 
>> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
>> drm_kms_helper i2c_i801 cec drm rapl intel_cstate intel_uncore mei_me 
>> i2c_smbus e1000e tpm_infineon wmi serio_raw mei video lpc_i
>> 
>>  CPU: 4 PID: 1 Comm: systemd-shutdow Not tainted 5.9.0-rc4-test+ #861
>>  Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
>> 07/14/2016
>>  RIP: 0010:gen6_write32+0x1bc/0x2a0 [i915]
>>  Code: 5d 82 e0 0f 0b e9 b5 fe ff ff 80 3d 95 6b 22 00 00 0f 85 b2 fe ff ff 
>> 48 c7 c7 04 d2 a4 c0 c6 05 81 6b 22 00 01 e8 f6 5c 82 e0 <0f> 0b e9 98 fe ff 
>> ff 80 3d 6d 6b 22 00 00 0f 85 95 fe ff ff 48 c7
>>  RSP: 0018:b9c1c002fd08 EFLAGS: 00010296
>>  RAX: 0018 RBX: 99aec8881010 RCX: 99aeda40
>>  RDX:  RSI: a115d9ef RDI: a115d9ef
>>  RBP: 00044004 R08: 0001 R09: 
>>  R10: 0001 R11: 0001 R12: 
>>  R13: 0001 R14:  R15: 
>>  FS:  7f91257a9940() GS:99aeda40() knlGS:
>>  CS:  0010 DS:  ES:  CR0: 80050033
>>  CR2: 7f9126829400 CR3: 0001088f0006 CR4: 001706e0
>>  Call Trace:
>>   gen3_irq_reset+0x2e/0xd0 [i915]
>>   intel_irq_reset+0x59/0x6a0 [i915]
>>   intel_runtime_pm_disable_interrupts+0xe/0x30 [i915]
>>   i915_driver_shutdown+0x2e/0x40 [i915]
>>   pci_device_shutdown+0x34/0x60
>>   device_shutdown+0x15d/0x1b3
>>   kernel_restart+0xe/0x30
>>   __do_sys_reboot+0x1d7/0x210
>>   ? vfs_writev+0x9d/0xe0
>>   ? syscall_enter_from_user_mode+0x1d/0x70
>>   ? trace_hardirqs_on+0x2c/0xe0
>>   do_syscall_64+0x33/0x40
>>   entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>  RIP: 0033:0x7f912675f2d7
>>  Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 
>> 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 
>> 77 01 c3 48 8b 15 81 8b 0c 00 f7 d8 64 89 02 b8
>>  RSP: 002b:7ffeca28e148 EFLAGS: 0206 ORIG_RAX: 00a9
>>  RAX: ffda RBX:  RCX: 7f912675f2d7
>>  RDX: 01234567 RSI: 28121969 RDI: fee1dead
>>  RBP: 7ffeca28e3d0 R08: 000a R09: 
>>  R10: 0232 R11: 0206 R12: 0001
>>  R13:  R14:  R15: 7ffeca28e4b8
>>  ---[ end trace 2ed17eabd3ab6938 ]---
>>  [ cut here ]
>> 
>> The bisect came to this commit:
>> 
>>   fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
>>   ("drm/i915: Shut down displays gracefully on reboot")
>> 
>> Which makes sense, as it happens on shutdown.

Please try this pull, heading to -rc4, which cointains "drm/i915:
Disable RPM wakeref assertions during driver shutdown":

http://lore.kernel.org/r/87sg73pz42@intel.com


BR,
Jani.

>> 
>> -- Steve
>

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Christian König]

Am 14.01.21 um 22:13 schrieb Felix Kuehling:

Am 2021-01-14 um 11:51 a.m. schrieb Jerome Glisse:

On Thu, Jan 14, 2021 at 02:37:36PM +0100, Christian König wrote:

Am 14.01.21 um 12:52 schrieb Daniel Vetter:

[SNIP]

I had a new idea, i wanted to think more about it but have not yet,
anyway here it is. Adding a new callback to dma fence which ask the
question can it dead lock ? Any time a GPU driver has pending page
fault (ie something calling into the mm) it answer yes, otherwise
no. The GPU shrinker would ask the question before waiting on any
dma-fence and back of if it gets yes. Shrinker can still try many
dma buf object for which it does not get a yes on associated fence.

This does not solve the mmu notifier case, for this you would just
invalidate the gem userptr object (with a flag but not releasing the
page refcount) but you would not wait for the GPU (ie no dma fence
wait in that code path anymore). The userptr API never really made
the contract that it will always be in sync with the mm view of the
world so if different page get remapped to same virtual address
while GPU is still working with the old pages it should not be an
issue (it would not be in our usage of userptr for compositor and
what not).

The current working idea in my mind goes into a similar direction.

But instead of a callback I'm adding a complete new class of HMM fences.

Waiting in the MMU notfier, scheduler, TTM etc etc is only allowed for
the dma_fences and HMM fences are ignored in container objects.

When you handle an implicit or explicit synchronization request from
userspace you need to block for HMM fences to complete before taking any
resource locks.

Isnt' that what I call gang scheduling? I.e. you either run in HMM
mode, or in legacy fencing mode (whether implicit or explicit doesn't
really matter I think). By forcing that split we avoid the problem,
but it means occasionally full stalls on mixed workloads.

But that's not what Jerome wants (afaiui at least), I think his idea
is to track the reverse dependencies of all the fences floating
around, and then skip evicting an object if you have to wait for any
fence that is problematic for the current calling context. And I don't
think that's very feasible in practice.

So what kind of hmm fences do you have in mind here?

It's a bit more relaxed than your gang schedule.

See the requirements are as follow:

1. dma_fences never depend on hmm_fences.
2. hmm_fences can never preempt dma_fences.
3. dma_fences must be able to preempt hmm_fences or we always reserve enough
hardware resources (CUs) to guarantee forward progress of dma_fences.

Critical sections are MMU notifiers, page faults, GPU schedulers and
dma_reservation object locks.

4. It is valid to wait for a dma_fences in critical sections.
5. It is not valid to wait for hmm_fences in critical sections.

Fence creation either happens during command submission or by adding
something like a barrier or signal command to your userspace queue.

6. If we have an hmm_fence as implicit or explicit dependency for creating a
dma_fence we must wait for that before taking any locks or reserving
resources.
7. If we have a dma_fence as implicit or explicit dependency for creating an
hmm_fence we can wait later on. So busy waiting or special WAIT hardware
commands are valid.

This prevents hard cuts, e.g. can mix hmm_fences and dma_fences at the same
time on the hardware.

In other words we can have a high priority gfx queue running jobs based on
dma_fences and a low priority compute queue running jobs based on
hmm_fences.

Only when we switch from hmm_fence to dma_fence we need to block the
submission until all the necessary resources (both memory as well as CUs)
are available.

This is somewhat an extension to your gang submit idea.

What is hmm_fence ? You should not have fence with hmm at all.
So i am kind of scare now.

I kind of had the same question trying to follow Christian and Daniel's
discussion. I think an HMM fence would be any fence resulting from the
completion of a user mode operation in a context with HMM-based memory
management that may stall indefinitely due to page faults.


It was more of a placeholder for something which can be used for inter 
process synchronization.



But on a hardware engine that cannot preempt page-faulting work and has
not reserved resources to guarantee forward progress for kernel jobs, I
think all fences will need to be HMM fences, because any work submitted
to such an engine can stall by getting stuck behind a stalled user mode
operation.

So for example, you have a DMA engine that can preempt during page
faults, but a graphics engine that cannot. Then work submitted to the
DMA engine can use dma_fence. But work submitted to the graphics engine
must use hmm_fence. To avoid deadlocks, dma_fences must never depend on
hmm_fences and resolution of page faults must never depend on hmm_fences.


Yeah, it's a bit more complicated but in general that fits.

Regards,
Christian.

Re: [pull] amdgpu drm-next-5.12

[Dave Airlie]

On Fri, 15 Jan 2021 at 07:22, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> More new stuff for 5.12.
>
> The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:
>
>   drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 
> 210921) (2021-01-08 15:18:57 -0500)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-5.12-2021-01-14
>
> for you to fetch changes up to df1f0560d28f4895e2d61af826728efb61976f9f:
>
>   drm/amd/display: Simplify bool comparison (2021-01-14 13:20:21 -0500)

arm 32/64 builds say no.

  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.o
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:
In function ‘vangogh_get_smu_metrics_data’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:300:10:
error: ‘boot_cpu_data’ undeclared (first use in this function); did
you mean ‘bl_get_data’?
  boot_cpu_data.x86_max_cores * sizeof(uint16_t));
  ^
  bl_get_data
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:300:10:
note: each undeclared identifier is reported only once for each
function it appears in
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:
In function ‘vangogh_read_sensor’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1320:11:
error: ‘boot_cpu_data’ undeclared (first use in this function); did
you mean ‘bl_get_data’?
   *size = boot_cpu_data.x86_max_cores * sizeof(uint16_t);
   ^
   bl_get_data
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:
In function ‘vangogh_od_edit_dpm_table’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1460:19:
error: ‘boot_cpu_data’ undeclared (first use in this function); did
you mean ‘bl_get_data’?
   if (input[0] >= boot_cpu_data.x86_max_cores) {
   ^
   bl_get_data
make[5]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:279:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.o] Error 1


Not sure using boot_cpu_data in a driver is that good an idea, maybe
there is a better interface to get that sort of information, but even
so it should build on arm.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work

[Chen, Xiaogang]

On 1/14/2021 1:24 AM, Grodzovsky, Andrey wrote:
>
>
> On 1/14/21 12:11 AM, Chen, Xiaogang wrote:
>> On 1/12/2021 10:54 PM, Grodzovsky, Andrey wrote:
>>>
>>> On 1/4/21 1:01 AM, Xiaogang.Chen wrote:
 From: Xiaogang Chen 

 amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by
 using work queue and uses single work_struct. If previous interrupt
 has not been handled new interrupts(same type) will be discarded and
 driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out.
 If some important hpd, hpd_rx related interrupts are missed by driver
 the hot (un)plug devices may cause system hang or unstable, such as
 system resumes from S3 sleep with mst device connected.

 This patch dynamically allocates new amdgpu_dm_irq_handler_data for
 new interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work
 has not been handled. So the new interrupt works can be queued to the
 same workqueue_struct, instead discard the new interrupts.
 All allocated amdgpu_dm_irq_handler_data are put into a single linked
 list and will be reused after.
>>>
>>>
>>> I believe this creates a possible concurrency between already 
>>> executing work item
>>> and the new incoming one for which you allocate a new work item on 
>>> the fly. While
>>> handle_hpd_irq is serialized with aconnector->hpd_lock I am seeing 
>>> that for handle_hpd_rx_irq
>>> it's not locked for MST use case (which is the most frequently used 
>>> with this interrupt).  Did you
>>> verified that handle_hpd_rx_irq is reentrant ?
>>>
>> handle_hpd_rx_irq is put at a work queue. Its execution is serialized 
>> by the work queue. So there is no reentrant.
>>
> You are using system_highpri_wq which has the property that it has 
> multiple workers thread pool spread across all the
> active CPUs, see all work queue definitions here 
> https://elixir.bootlin.com/linux/v5.11-rc3/source/include/linux/workqueue.h#L358
> I beleieve that what you saying about no chance of reentrnacy would be 
> correct if it would be same work item dequeued for execution
> while previous instance is still running, see the explanation here - 
> https://elixir.bootlin.com/linux/v5.11-rc3/source/kernel/workqueue.c#L1435.
> Non reentrancy is guaranteed only for the same work item. If you want 
> non reentrancy (full serializtion) for different work items you should 
> create
> you own single threaded work-queue using create_singlethread_workqueue
>
>
Thank you. I think the easiest way is using aconnector->hpd_lock at 
handle_hpd_rx_irq to lock for dc_link->type == dc_connection_mst_branch 
case, right? I will do that at next version if you think it is ok.

>> amdgpu_dm_irq_schedule_work does queuing of work(put 
>> handle_hpd_rx_irq into work queue). The first call is 
>> dm_irq_work_func, then call handle_hpd_rx_irq.
>>>

 Signed-off-by: Xiaogang Chen 
 ---
   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  14 +--
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  | 114 
 ++---
   2 files changed, 80 insertions(+), 48 deletions(-)

 diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
 b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
 index c9d82b9..730e540 100644
 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
 +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
 @@ -69,18 +69,6 @@ struct common_irq_params {
   };
     /**
 - * struct irq_list_head - Linked-list for low context IRQ handlers.
 - *
 - * @head: The list_head within  handler_data
 - * @work: A work_struct containing the deferred handler work
 - */
 -struct irq_list_head {
 -    struct list_head head;
 -    /* In case this interrupt needs post-processing, 'work' will 
 be queued*/
 -    struct work_struct work;
 -};
 -
 -/**
    * struct dm_compressor_info - Buffer info used by frame buffer 
 compression
    * @cpu_addr: MMIO cpu addr
    * @bo_ptr: Pointer to the buffer object
 @@ -270,7 +258,7 @@ struct amdgpu_display_manager {
    * Note that handlers are called in the same order as they were
    * registered (FIFO).
    */
 -    struct irq_list_head 
 irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
 +    struct list_head 
 irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
     /**
    * @irq_handler_list_high_tab:
 diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c 
 b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
 index 3577785..ada344a 100644
 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
 +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
 @@ -82,6 +82,7 @@ struct amdgpu_dm_irq_handler_data {
   struct amdgpu_display_manager *dm;
   /* DAL irq source which registered for this interrupt. */
   enum 

[git pull] drm nouveau ampere modesetting support

[Dave Airlie]

Hi Linus,

As mentioned in the previous pull, Ben has requested if we can include
Ampere modesetting support under fixes, it's for new GPUs and
shouldn't affect existing hardware. It's a bit bigger than just adding
a PCI ID, and I'm fine if you think we should hold it off until later.

Dave.

topic/nouveau-ampere-modeset-2021-01-15:
drm nouveau ampere display support.

This is a pull request to add display support for new Ampere hardware.

It has no effect on older GPUs.
The following changes since commit c8f6364f35f32786dd40336cfa35b9166d91b8ab:

  Merge branch '04.00-ampere-lite-fixes' of
git://github.com/skeggsb/linux into drm-fixes (2021-01-15 13:26:44
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm
tags/topic/nouveau-ampere-modeset-2021-01-15

for you to fetch changes up to 584265dfec70e78ce2085b82ed389f27e06fbca0:

  Merge branch '04.01-ampere-lite' of git://github.com/skeggsb/linux
into topic/nouveau-ampere-modeset (2021-01-15 14:48:18 +1000)


drm nouveau ampere display support.

This is a pull request to add display support for new Ampere hardware.

It has no effect on older GPUs.


Ben Skeggs (15):
  drm/nouveau/core: recognise GA10[024]
  drm/nouveau/pci/ga10[024]: initial support
  drm/nouveau/bios/ga10[024]: initial support
  drm/nouveau/devinit/ga10[024]: initial support
  drm/nouveau/mc/ga10[024]: initial support
  drm/nouveau/privring/ga10[024]: initial support
  drm/nouveau/imem/ga10[024]: initial support
  drm/nouveau/fb/ga10[024]: initial support
  drm/nouveau/timer/ga10[024]: initial support
  drm/nouveau/mmu/ga10[024]: initial support
  drm/nouveau/bar/ga10[024]: initial support
  drm/nouveau/gpio/ga10[024]: initial support
  drm/nouveau/i2c/ga10[024]: initial support
  drm/nouveau/dmaobj/ga10[24]: initial support
  drm/nouveau/disp/ga10[24]: initial support

Dave Airlie (1):
  Merge branch '04.01-ampere-lite' of
git://github.com/skeggsb/linux into topic/nouveau-ampere-modeset

 drivers/gpu/drm/nouveau/dispnv50/Kbuild|   1 +
 drivers/gpu/drm/nouveau/dispnv50/core.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/curs.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wimm.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.h|   8 ++
 drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c|  10 +-
 drivers/gpu/drm/nouveau/dispnv50/wndwc67e.c| 106 
 drivers/gpu/drm/nouveau/include/nvif/cl0080.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvif/class.h   |   5 +
 drivers/gpu/drm/nouveau/include/nvkm/core/device.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/engine/disp.h |   1 +
 .../gpu/drm/nouveau/include/nvkm/subdev/devinit.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h   |   2 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/gpio.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/mc.h   |   1 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c|   1 +
 drivers/gpu/drm/nouveau/nvif/disp.c|   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  75 ++-
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c  |   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild|   3 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c  |  33 -
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ga102.c   |  46 +++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h |   4 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h|   2 +
 .../gpu/drm/nouveau/nvkm/engine/disp/rootga102.c   |  52 
 .../gpu/drm/nouveau/nvkm/engine/disp/rootnv50.h|   1 +
 .../gpu/drm/nouveau/nvkm/engine/disp/sorga102.c| 140 +
 .../gpu/drm/nouveau/nvkm/engine/disp/sortu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/tu102.c   |   2 +-
 .../gpu/drm/nouveau/nvkm/subdev/bios/shadowramin.c |   3 +
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/Kbuild |   1 +
 .../gpu/drm/nouveau/nvkm/subdev/devinit/ga100.c|  76 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/priv.h |   1 +
 .../gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild  |   3 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c |  40 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c |  40 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h   |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramga102.c  |  40 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/Kbuild|   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/ga102.c   | 118 +
 drivers/gpu/drm/nouveau/nvkm/subdev/mc/Kbuild  |   1 +
 

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[Linus Torvalds]

On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt  wrote:
>
> Thanks, I take it, it will be going into mainline soon.

Just got merged - it might be a good idea to verify that your problem is solved.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes for 5.11-rc4

[pr-tracker-bot]

The pull request you sent on Fri, 15 Jan 2021 14:01:12 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-15

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5ee88057889bbca5f5bb96031b62b3756b33e164

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for 5.11-rc4

[Dave Airlie]

Hey Linus,

Back to mostly regular scheduling for me. Big thanks to Daniel for
stepping into my duties for the last few turns.

Regular fixes for rc4, a bunch of fixes across i915, amdgpu and
nouveau here, along with a couple of TTM fixes, and dma-buf and one
core pageflip/modifier interaction fix. One notable i915 fix is a HSW
GT1 regression fix that has been outstanding for quite a while.
(Thanks to Matt Turner for kicking Intel into getting it fixed).

Ben Skeggs has asked about the possibility of pulling nvidia ampere
basic display support into fixes as new hardware with nothing outside
touched, I'll queue up a separate pull after this one and you can
decide if it's appropriate.

Dave.

drm-fixes-2021-01-15:
drm fixes for 5.11-rc4

dma-buf:
- Fix a memory leak in CMAV heap

core:
- Fix format check for legacy pageflips

ttm:
- Pass correct address to dma_mapping_error()
- Use mutex in pool shrinker

i915:
- Allow the sysadmin to override security mitigations
- Restore clear-residual mitigations for ivb/byt
- Limit VFE threads based on GT
- GVT: fix vfio edid and full display detection
- Fix DSI DSC power refcounting
- Fix LPT CPU mode backlight takeover
- Disable RPM wakeref assertions during driver shutdown
- Fix DSI sequence sleeps

amdgpu:
- Update repo location in MAINTAINERS
- Add some new renoir PCI IDs
- Revert CRC UAPI changes
- Revert OLED display fix which cases clocking problems for some systems
- Misc vangogh fixes
- GFX fix for sienna cichlid
- DCN1.0 fix for pipe split
- Fix incorrect PSP command

amdkfd:
- Fix possible out of bounds read in vcrat creation

nouveau:
- irq handling fix
- expansion ROM fix
- hw init dpcd disable
- aux semaphore owner field fix
- vram heap sizing fix
- notifier at 0 is valid fix
The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:

  Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-15

for you to fetch changes up to c8f6364f35f32786dd40336cfa35b9166d91b8ab:

  Merge branch '04.00-ampere-lite-fixes' of
git://github.com/skeggsb/linux into drm-fixes (2021-01-15 13:26:44
+1000)


drm fixes for 5.11-rc4

dma-buf:
- Fix a memory leak in CMAV heap

core:
- Fix format check for legacy pageflips

ttm:
- Pass correct address to dma_mapping_error()
- Use mutex in pool shrinker

i915:
- Allow the sysadmin to override security mitigations
- Restore clear-residual mitigations for ivb/byt
- Limit VFE threads based on GT
- GVT: fix vfio edid and full display detection
- Fix DSI DSC power refcounting
- Fix LPT CPU mode backlight takeover
- Disable RPM wakeref assertions during driver shutdown
- Fix DSI sequence sleeps

amdgpu:
- Update repo location in MAINTAINERS
- Add some new renoir PCI IDs
- Revert CRC UAPI changes
- Revert OLED display fix which cases clocking problems for some systems
- Misc vangogh fixes
- GFX fix for sienna cichlid
- DCN1.0 fix for pipe split
- Fix incorrect PSP command

amdkfd:
- Fix possible out of bounds read in vcrat creation

nouveau:
- irq handling fix
- expansion ROM fix
- hw init dpcd disable
- aux semaphore owner field fix
- vram heap sizing fix
- notifier at 0 is valid fix


Alex Deucher (1):
  MAINTAINERS: update radeon/amdgpu/amdkfd git trees

Alexandre Demers (1):
  drm/amdgpu: fix DRM_INFO flood if display core is not supported
(bug 210921)

Bas Nieuwenhuizen (1):
  drm: Check actual format for legacy pageflip.

Ben Skeggs (7):
  drm/nouveau/bios: fix issue shadowing expansion ROMs
  drm/nouveau/privring: ack interrupts the same way as RM
  drm/nouveau/i2c/gk110: split out from i2c/gk104
  drm/nouveau/i2c/gk110-: disable hw-initiated dpcd reads
  drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
  drm/nouveau/mmu: fix vram heap sizing
  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0

Chris Wilson (4):
  drm/i915: Disable RPM wakeref assertions during driver shutdown
  drm/i915/gt: Limit VFE threads based on GT
  drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail
  drm/i915: Allow the sysadmin to override security mitigations

Christian König (1):
  drm/ttm: make the pool shrinker lock a mutex

Colin Xu (1):
  drm/i915/gvt: Fix vfio_edid issue for BXT/APL

Dave Airlie (4):
  Merge tag 'drm-misc-fixes-2021-01-12' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2021-01-14' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'amd-drm-fixes-5.11-2021-01-14' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge branch '04.00-ampere-lite-fixes' of
git://github.com/skeggsb/linux into drm-fixes

Hans de Goede (1):
  drm/i915/dsi: Use unconditional msleep for the panel_on_delay

linux-next: build warnings after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function 
'amdgpu_display_user_framebuffer_create':
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:929:24: warning: unused variable 
'adev' [-Wunused-variable]
  929 |  struct amdgpu_device *adev = drm_to_adev(dev);
  |^~~~

Introduced by commit

  8f66090b7bb7 ("drm/amdgpu: Remove references to struct drm_device.pdev")

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function 
'amdgpu_device_resize_fb_bar':
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1109:6: warning: unused variable 
'space_needed' [-Wunused-variable]
 1109 |  u64 space_needed = roundup_pow_of_two(adev->gmc.real_vram_size);
  |  ^~~~

Introduced by commit

  453f617a30aa ("drm/amdgpu: Resize BAR0 to the maximum available size, even if 
it doesn't cover VRAM")

-- 
Cheers,
Stephen Rothwell


pgpGmFg1COevh.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panel-simple: Undo enable if HPD never asserts

[Douglas Anderson]

If the HPD signal never asserts in panel_simple_prepare() and we
return an error, we should unset the enable GPIO and disable the
regulator to make it consistent for the caller.

At the moment I have some hardware where HPD sometimes doesn't assert.
Obviously that needs to be debugged, but this patch makes it so that
if I add a retry that I can make things work.

Fixes: 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying 
prepare()")
Signed-off-by: Douglas Anderson 
---

 drivers/gpu/drm/panel/panel-simple.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 71ae200ac48a..b89394b44f43 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -406,7 +406,7 @@ static int panel_simple_prepare(struct drm_panel *panel)
if (IS_ERR(p->hpd_gpio)) {
err = panel_simple_get_hpd_gpio(panel->dev, p, false);
if (err)
-   return err;
+   goto error;
}
 
err = readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio,
@@ -418,13 +418,19 @@ static int panel_simple_prepare(struct drm_panel *panel)
if (err) {
dev_err(panel->dev,
"error waiting for hpd GPIO: %d\n", err);
-   return err;
+   goto error;
}
}
 
p->prepared_time = ktime_get();
 
return 0;
+
+error:
+   gpiod_set_value_cansleep(p->enable_gpio, 0);
+   regulator_disable(p->supply);
+
+   return err;
 }
 
 static int panel_simple_enable(struct drm_panel *panel)
-- 
2.30.0.284.gd98b1dd5eaa7-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] nouveau: ampere modesetting

[Ben Skeggs]

Hey Dave,

This series of patches to add modesetting support for Ampere has been
pulled out of a larger, more invasive series.  As there's currently no
firmware available for us to use, the rest of it isn't important right
now, and it'd be nice to have something non-invasive to provide what
support we currently can (and is possible to backport to earlier
kernels).

No other chipset should be impacted by these patches, as the changes
are largely confined to adding Ampere versions of the code handling
each IP block.

I'd like to extend thanks to NVIDIA for providing hardware, and for
their assistance with confirming/clarifying some of the changes.

Ben.

The following changes since commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e:

  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
(2021-01-15 10:25:17 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux 04.01-ampere-lite

for you to fetch changes up to 8ef23b6f6a79e6fa2a169081d2d76011fffa0482:

  drm/nouveau/disp/ga10[24]: initial support (2021-01-15 10:25:24 +1000)


Ben Skeggs (15):
  drm/nouveau/core: recognise GA10[024]
  drm/nouveau/pci/ga10[024]: initial support
  drm/nouveau/bios/ga10[024]: initial support
  drm/nouveau/devinit/ga10[024]: initial support
  drm/nouveau/mc/ga10[024]: initial support
  drm/nouveau/privring/ga10[024]: initial support
  drm/nouveau/imem/ga10[024]: initial support
  drm/nouveau/fb/ga10[024]: initial support
  drm/nouveau/timer/ga10[024]: initial support
  drm/nouveau/mmu/ga10[024]: initial support
  drm/nouveau/bar/ga10[024]: initial support
  drm/nouveau/gpio/ga10[024]: initial support
  drm/nouveau/i2c/ga10[024]: initial support
  drm/nouveau/dmaobj/ga10[24]: initial support
  drm/nouveau/disp/ga10[24]: initial support

 drivers/gpu/drm/nouveau/dispnv50/Kbuild|   1 +
 drivers/gpu/drm/nouveau/dispnv50/core.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/curs.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wimm.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.h|   8 +++
 drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c|  10 ++--
 drivers/gpu/drm/nouveau/dispnv50/wndwc67e.c| 106
+++
 drivers/gpu/drm/nouveau/include/nvif/cl0080.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvif/class.h   |   5 ++
 drivers/gpu/drm/nouveau/include/nvkm/core/device.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/engine/disp.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/devinit.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h   |   2 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/gpio.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/mc.h   |   1 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c|   1 +
 drivers/gpu/drm/nouveau/nvif/disp.c|   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  75
++--
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c  |   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild|   3 ++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c  |  33 ++---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ga102.c   |  46 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h |   4 ++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h|   2 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/rootga102.c   |  52
+++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.h|   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/sorga102.c| 140

 drivers/gpu/drm/nouveau/nvkm/engine/disp/sortu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/tu102.c   |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowramin.c |   3 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/Kbuild |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/ga100.c|  76

 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/priv.h |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild  |   3 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c |  40 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c |  40 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h   |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramga102.c  |  40 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/Kbuild|   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/ga102.c   | 118

[PULL] nouveau-fixes 5.11

[Ben Skeggs]

Hey Dave,

As requested, here's a tree with the non-Ampere-specific fixes split
out, as most of them are potentially relevant to already-supported
GPUs.

I'll send another pull request with bare-bones GA102/GA104 support shortly.

Ben.

The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:

  Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)

are available in the Git repository at:

  git://github.com/skeggsb/linux 04.00-ampere-lite-fixes

for you to fetch changes up to caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e:

  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
(2021-01-15 10:25:17 +1000)


Ben Skeggs (7):
  drm/nouveau/bios: fix issue shadowing expansion ROMs
  drm/nouveau/privring: ack interrupts the same way as RM
  drm/nouveau/i2c/gk110: split out from i2c/gk104
  drm/nouveau/i2c/gk110-: disable hw-initiated dpcd reads
  drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
  drm/nouveau/mmu: fix vram heap sizing
  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0

 drivers/gpu/drm/nouveau/dispnv50/disp.c|  4 ++--
 drivers/gpu/drm/nouveau/dispnv50/disp.h|  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c|  2 +-
 drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h  |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  | 12 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h  |  7 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c   | 10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 17 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gk110.c| 45
++
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gm200.c|  7 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.h  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/priv.h |  4 
 drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c   | 10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c   | 10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c |  6 +++---
 17 files changed, 112 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gk110.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9, 05/11] drm/mediatek: add fifo_size into rdma private data

[Chun-Kuang Hu]

Hi, Yongqiang:

Chun-Kuang Hu  於 2021年1月7日 週四 下午6:05寫道：
>
> Hi, Yongqiang:
>
> Yongqiang Niu  於 2021年1月7日 週四 上午11:12寫道：
> >
> > Get the fifo size from device tree
> > because each rdma in the same SoC may have different fifo size
>
> Reviewed-by: Chun-Kuang Hu 

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> >
> > Signed-off-by: Yongqiang Niu 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 19 ++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > index d46b8ae..8c64d5c 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > @@ -64,6 +64,7 @@ struct mtk_disp_rdma {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_crtc *crtc;
> > const struct mtk_disp_rdma_data *data;
> > +   u32 fifo_size;
> >  };
> >
> >  static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> > @@ -132,12 +133,18 @@ static void mtk_rdma_config(struct mtk_ddp_comp 
> > *comp, unsigned int width,
> > unsigned int threshold;
> > unsigned int reg;
> > struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> > +   u32 rdma_fifo_size;
> >
> > mtk_ddp_write_mask(cmdq_pkt, width, comp,
> >DISP_REG_RDMA_SIZE_CON_0, 0xfff);
> > mtk_ddp_write_mask(cmdq_pkt, height, comp,
> >DISP_REG_RDMA_SIZE_CON_1, 0xf);
> >
> > +   if (rdma->fifo_size)
> > +   rdma_fifo_size = rdma->fifo_size;
> > +   else
> > +   rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> > +
> > /*
> >  * Enable FIFO underflow since DSI and DPI can't be blocked.
> >  * Keep the FIFO pseudo size reset default of 8 KiB. Set the
> > @@ -146,7 +153,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
> > unsigned int width,
> >  */
> > threshold = width * height * vrefresh * 4 * 7 / 100;
> > reg = RDMA_FIFO_UNDERFLOW_EN |
> > - RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> > + RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> >   RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
> > mtk_ddp_write(cmdq_pkt, reg, comp, DISP_REG_RDMA_FIFO_CON);
> >  }
> > @@ -292,6 +299,16 @@ static int mtk_disp_rdma_probe(struct platform_device 
> > *pdev)
> > return comp_id;
> > }
> >
> > +   if (of_find_property(dev->of_node, "mediatek,rdma-fifo-size", 
> > )) {
> > +   ret = of_property_read_u32(dev->of_node,
> > +  "mediatek,rdma-fifo-size",
> > +  >fifo_size);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to get rdma fifo size\n");
> > +   return ret;
> > +   }
> > +   }
> > +
> > ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
> > _disp_rdma_funcs);
> > if (ret) {
> > --
> > 1.8.1.1.dirty
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3, 11/15] drm/mediatek: fix aal size config

[Chun-Kuang Hu]

Hi, Yongqiang:

Yongqiang Niu  於 2021年1月11日 週一 下午3:48寫道：
>
> the orginal setting is not correct, fix it follow hardware data sheet.
> if keep this error setting, mt8173/mt8183 display ok
> but mt8192 display abnormal.
>

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

> Fixes: 0664d1392c26 (drm/mediatek: Add AAL engine basic function)
>
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index fc01fea..6081800 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -174,7 +174,7 @@ static void mtk_aal_config(struct mtk_ddp_comp *comp, 
> unsigned int w,
>unsigned int h, unsigned int vrefresh,
>unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
>  {
> -   mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_AAL_SIZE);
> +   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_AAL_SIZE);
>  }
>
>  static void mtk_aal_start(struct mtk_ddp_comp *comp)
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -12

[Mikhail Gavrilov]

On Thu, 14 Jan 2021 at 18:56, Christian König  wrote:
> Unfortunately not of hand.
>
> I also don't see any bug reports from other people and can't reproduce
> the last backtrace you send out TTM here.

Because only the most desperate will install kernels with enabled
debug flags and then load the system by opening a huge number of
programs and tabs. So you shouldn't be surprised that I'm the only one
here.
This is what my desktop looks like every day: https://imgur.com/a/Kxlmrem

> Do you have any local modifications or special setup in your system?
> Like bpf scripts or something like that?

No, my I didn't write any bpf scripts, but looks like my distribution
Fedora Rawhide uses some bpf scripts by default out of box:

# bpftool prog
20: cgroup_device  tag 40ddf486530245f5  gpl
loaded_at 2021-01-15T01:30:04+0500  uid 0
xlated 504B  jited 309B  memlock 4096B
21: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:04+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
22: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:04+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
23: cgroup_device  tag ca8e50a3c7fb034b  gpl
loaded_at 2021-01-15T01:30:05+0500  uid 0
xlated 496B  jited 307B  memlock 4096B
24: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:05+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
25: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:05+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
26: cgroup_device  tag be31ae23198a0378  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 464B  jited 288B  memlock 4096B
27: cgroup_device  tag ee0e253c78993a24  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 416B  jited 255B  memlock 4096B
28: cgroup_device  tag 438c5618576e5b0c  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 568B  jited 354B  memlock 4096B
29: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
30: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
31: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
32: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:13+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
33: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:14+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
34: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:14+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
35: cgroup_device  tag ee0e253c78993a24  gpl
loaded_at 2021-01-15T01:30:14+0500  uid 0
xlated 416B  jited 255B  memlock 4096B
38: cgroup_device  tag 3a0ef5414c2f6fca  gpl
loaded_at 2021-01-15T01:30:14+0500  uid 0
xlated 744B  jited 447B  memlock 4096B
39: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:14+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
40: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:14+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
41: cgroup_device  tag ee0e253c78993a24  gpl
loaded_at 2021-01-15T01:30:18+0500  uid 0
xlated 416B  jited 255B  memlock 4096B
42: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:18+0500  uid 0
xlated 64B  jited 54B  memlock 4096B
43: cgroup_skb  tag 6deef7357e7b4530  gpl
loaded_at 2021-01-15T01:30:18+0500  uid 0
xlated 64B  jited 54B  memlock 4096B

I catched yet another couples of leaks , but nothing new:
https://pastebin.com/2EgvYJdz

[1] do_detailed_mode+0x7c1/0x13d0 [drm]
[2] drm_mode_duplicate+0x45/0x220 [drm]
[3] do_seccomp+0x215/0x2280
[4] __vmalloc_node_range+0x464/0x7b0
[5] bpf_prog_alloc_no_stats+0xa2/0x2b0
[6] bpf_prog_store_orig_filter+0x7b/0x1c0
[7] kmemdup+0x1a/0x40

Did the following trace message confuse anyone?
==
BUG: KASAN: slab-out-of-bounds in
kfd_create_crat_image_virtual+0x12d2/0x1380 [amdgpu]
Read of size 1 at addr 88812a6b4181 by task systemd-udevd/491

CPU: 20 PID: 491 Comm: systemd-udevd Not tainted
5.11.0-0.rc3.20210114git65f0d2414b70.125.fc34.x86_64 #1
Hardware name: System manufacturer System Product Name/ROG STRIX
X570-I GAMING, BIOS 2802 10/21/2020
Call Trace:
 dump_stack+0xae/0xe5
 print_address_description.constprop.0+0x18/0x160
 ? kfd_create_crat_image_virtual+0x12d2/0x1380 [amdgpu]
 kasan_report.cold+0x7f/0x10e
 ? kfd_create_crat_image_virtual+0x12d2/0x1380 [amdgpu]
 kfd_create_crat_image_virtual+0x12d2/0x1380 [amdgpu]
 ? kfd_create_crat_image_acpi+0x340/0x340 [amdgpu]
 ? __raw_spin_lock_init+0x39/0x110
 kfd_topology_init+0x2ac/0x400 [amdgpu]
 ? kfd_create_topology_device+0x320/0x320 [amdgpu]
 ? __class_register+0x2ad/0x430
 ? __class_create+0xc5/0x130
 kgd2kfd_init+0x95/0xf0 [amdgpu]
 

Re: [PATCH v3, 01/15] dt-bindings: mediatek: add description for postmask

[Chun-Kuang Hu]

Rob Herring  於 2021年1月15日 週五 上午3:11寫道：
>
> On Mon, 11 Jan 2021 15:43:37 +0800, Yongqiang Niu wrote:
> > add description for postmask
> > postmask is used control round corner for display frame
> >
> > Signed-off-by: Yongqiang Niu 
> > ---
> >  Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Acked-by: Rob Herring 

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 7/7] drm/msm/a5xx: Disable UCHE global filter

[Jordan Crouse]

On Wed, Jan 13, 2021 at 07:33:39PM +0100, AngeloGioacchino Del Regno wrote:
> From: Konrad Dybcio 
> 
> Port over the command from downstream to prevent undefined
> behaviour.

Reviewed-by: Jordan Crouse 

> Signed-off-by: Konrad Dybcio 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/gpu/drm/msm/adreno/a5xx.xml.h | 2 ++
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx.xml.h 
> b/drivers/gpu/drm/msm/adreno/a5xx.xml.h
> index 346cc6ff3a36..7b9fcfe95c04 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx.xml.h
> +++ b/drivers/gpu/drm/msm/adreno/a5xx.xml.h
> @@ -2367,6 +2367,8 @@ static inline uint32_t A5XX_VSC_RESOLVE_CNTL_Y(uint32_t 
> val)
>  
>  #define REG_A5XX_UCHE_ADDR_MODE_CNTL 0x0e80
>  
> +#define REG_A5XX_UCHE_MODE_CNTL  
> 0x0e81
> +
>  #define REG_A5XX_UCHE_SVM_CNTL   
> 0x0e82
>  
>  #define REG_A5XX_UCHE_WRITE_THRU_BASE_LO 0x0e87
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 23fc851756de..7e553d3efeb2 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -754,6 +754,9 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
>   adreno_is_a512(adreno_gpu))
>   gpu_rmw(gpu, REG_A5XX_RB_DBG_ECO_CNTL, 0, (1 << 9));
>  
> + /* Disable UCHE global filter as SP can invalidate/flush independently 
> */
> + gpu_write(gpu, REG_A5XX_UCHE_MODE_CNTL, BIT(29));
> +
>   /* Enable USE_RETENTION_FLOPS */
>   gpu_write(gpu, REG_A5XX_CP_CHICKEN_DBG, 0x0200);
>  
> -- 
> 2.29.2
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/7] drm/msm/a5xx: Disable flat shading optimization

[Jordan Crouse]

On Wed, Jan 13, 2021 at 07:33:38PM +0100, AngeloGioacchino Del Regno wrote:
> From: Konrad Dybcio 
> 
> Port over the command from downstream to prevent undefined
> behaviour.

Reviewed-by: Jordan Crouse 

> Signed-off-by: Konrad Dybcio 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 24ab51bb5a01..23fc851756de 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -791,6 +791,9 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
>   adreno_is_a540(adreno_gpu))
>   gpu_write(gpu, REG_A5XX_UCHE_DBG_ECO_CNTL_2, regbit);
>  
> + /* Disable All flat shading optimization (ALLFLATOPTDIS) */
> + gpu_rmw(gpu, REG_A5XX_VPC_DBG_ECO_CNTL, 0, (1 << 10));
> +
>   /* Protect registers from the CP */
>   gpu_write(gpu, REG_A5XX_CP_PROTECT_CNTL, 0x0007);
>  
> -- 
> 2.29.2
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/7] drm/msm/a5xx: Fix VPC protect value in gpu_write()

[Jordan Crouse]

On Wed, Jan 13, 2021 at 07:33:37PM +0100, AngeloGioacchino Del Regno wrote:
> From: Konrad Dybcio 
> 
> The upstream API for some reason uses logbase2 instead of
> just passing the argument as-is, whereas downstream CAF
> kernel does the latter.
> 
> Hence, a mistake has been made when porting:
> 4 is the value that's supposed to be passed, but
> log2(4) = 2. Changing the value to 16 (= 2^4) fixes
> the issue.

I like keeping it in human readable values because its easier to visually
identify how many registers are saved without doing math.

Reviewed-by: Jordan Crouse 

> Signed-off-by: Konrad Dybcio 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 66980f4cd93e..24ab51bb5a01 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -821,7 +821,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
>  
>   /* VPC */
>   gpu_write(gpu, REG_A5XX_CP_PROTECT(14), ADRENO_PROTECT_RW(0xE68, 8));
> - gpu_write(gpu, REG_A5XX_CP_PROTECT(15), ADRENO_PROTECT_RW(0xE70, 4));
> + gpu_write(gpu, REG_A5XX_CP_PROTECT(15), ADRENO_PROTECT_RW(0xE70, 16));
>  
>   /* UCHE */
>   gpu_write(gpu, REG_A5XX_CP_PROTECT(16), ADRENO_PROTECT_RW(0xE80, 16));
> -- 
> 2.29.2
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 5/5] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

[Lyude Paul]

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
-   /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
-   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
-   { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can 

[PATCH v7 4/5] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

[Lyude Paul]

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9b0589cf8d17..31a478f63d52 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -612,15 +612,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -629,13 +668,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2=force VESA interface, 3=force Intel interface)");
 
 #if IS_ENABLED(CONFIG_DRM_I915_GVT)
 

[PATCH v7 3/5] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

[Lyude Paul]

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
  to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 247 --
 drivers/gpu/drm/i915/display/intel_panel.c|  40 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 269 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ee23cc1518df..a2ea651ece79 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index de764dae1e66..9b0589cf8d17 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,178 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector 

[PATCH v7 2/5] drm/i915: Keep track of pwm-related backlight hooks separately

[Lyude Paul]

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.

v8:
* Go back to getting initial brightness level with
  intel_pwm_get_backlight(), the other fix we had was definitely wrong.
v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
  intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
  intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
  indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
  intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 

squash! drm/i915: Keep track of pwm-related backlight hooks separately

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 331 ++
 2 files changed, 188 insertions(+), 147 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b1f4ec144207..ee23cc1518df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_level_min;
+   u32 pwm_level_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 

[PATCH v7 1/5] drm/i915: Pass port to intel_panel_bl_funcs.get()

[Lyude Paul]

In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().

So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_display_types.h|  2 +-
 .../drm/i915/display/intel_dp_aux_backlight.c |  4 +-
 .../i915/display/intel_dsi_dcs_backlight.c|  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 40 ---
 4 files changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 585bb1edea04..b1f4ec144207 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -228,7 +228,7 @@ struct intel_encoder {
 struct intel_panel_bl_funcs {
/* Connector and platform specific backlight functions */
int (*setup)(struct intel_connector *connector, enum pipe pipe);
-   u32 (*get)(struct intel_connector *connector);
+   u32 (*get)(struct intel_connector *connector, enum pipe pipe);
void (*set)(const struct drm_connector_state *conn_state, u32 level);
void (*disable)(const struct drm_connector_state *conn_state, u32 
level);
void (*enable)(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9775f33d1aac..de764dae1e66 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -128,7 +128,7 @@ static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct 
intel_connector *connec
  * Read the current backlight value from DPCD register(s) based
  * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
  */
-static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector, 
enum pipe unused)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -381,7 +381,7 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
return -ENODEV;
 
panel->backlight.min = 0;
-   panel->backlight.level = intel_dp_aux_vesa_get_backlight(connector);
+   panel->backlight.level = intel_dp_aux_vesa_get_backlight(connector, 
pipe);
panel->backlight.enabled = 
intel_dp_aux_vesa_backlight_dpcd_mode(connector) &&
   panel->backlight.level != 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index 88628764956d..584c14c4cbd0 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -43,7 +43,7 @@
 
 #define PANEL_PWM_MAX_VALUE0xFF
 
-static u32 dcs_get_backlight(struct intel_connector *connector)
+static u32 dcs_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
struct intel_encoder *encoder = intel_attached_encoder(connector);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7a4239d1c241..7587aaefc7a0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -530,21 +530,21 @@ static u32 intel_panel_compute_brightness(struct 
intel_connector *connector,
return val;
 }
 
-static u32 lpt_get_backlight(struct intel_connector *connector)
+static u32 lpt_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
 
return intel_de_read(dev_priv, BLC_PWM_PCH_CTL2) & 
BACKLIGHT_DUTY_CYCLE_MASK;
 }
 
-static u32 pch_get_backlight(struct intel_connector *connector)
+static u32 pch_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
struct drm_i915_private 

[PATCH v7 0/5] drm/i915: Add support for Intel's eDP backlight controls

[Lyude Paul]

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v7:
* Add another patch that allows passing the current display pipe to
  intel_panel_bl_funcs.get(), which should fix the lockdep issues we
  were seeing with Intel's CI

Lyude Paul (5):
  drm/i915: Pass port to intel_panel_bl_funcs.get()
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  16 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 290 +++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 .../i915/display/intel_dsi_dcs_backlight.c|   2 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 395 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 12 files changed, 519 insertions(+), 311 deletions(-)

-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[Steven Rostedt]

On Thu, 14 Jan 2021 21:35:53 +
Chris Wilson  wrote:

> Quoting Steven Rostedt (2021-01-14 21:32:06)
> > On reboot, one of my test boxes now triggers the following warning:  
> 
> 057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver 
> shutdown")
> is included with the drm-intel-fixes PR.

Thanks, I take it, it will be going into mainline soon.

-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[Chris Wilson]

Quoting Steven Rostedt (2021-01-14 21:32:06)
> On reboot, one of my test boxes now triggers the following warning:

057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver shutdown")
is included with the drm-intel-fixes PR.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[Steven Rostedt]

[ Forgot to add those on the commit itself ]

-- Steve


On Thu, 14 Jan 2021 16:32:06 -0500
Steven Rostedt  wrote:

> On reboot, one of my test boxes now triggers the following warning:
> 
>  [ cut here ]
>  RPM raw-wakeref not held
>  WARNING: CPU: 4 PID: 1 at drivers/gpu/drm/i915/intel_runtime_pm.h:106 
> gen6_write32+0x1bc/0x2a0 [i915]
>  Modules linked in: ebtable_filter ebtables bridge stp llc ip6t_REJECT 
> nf_reject_ipv6 vsock vmw_vmci xt_state xt_conntrack nf_conntrack 
> nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables snd_hda_codec_hdmi 
> snd_hda_codec_realtek snd_hda_codec_generic le
> 15 snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep i2c_algo_bit 
> snd_hda_core snd_seq intel_rapl_msr snd_seq_device intel_rapl_common snd_pcm 
> x86_pkg_temp_thermal intel_powerclamp snd_timer snd coretemp kvm_intel 
> soundcore kvm mei_wdt irqbypass joydev 
> _pmc_bxt hp_wmi wmi_bmof sparse_keymap rfkill iTCO_vendor_support 
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel drm_kms_helper 
> i2c_i801 cec drm rapl intel_cstate intel_uncore mei_me i2c_smbus e1000e 
> tpm_infineon wmi serio_raw mei video lpc_i
> 
>  CPU: 4 PID: 1 Comm: systemd-shutdow Not tainted 5.9.0-rc4-test+ #861
>  Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
> 07/14/2016
>  RIP: 0010:gen6_write32+0x1bc/0x2a0 [i915]
>  Code: 5d 82 e0 0f 0b e9 b5 fe ff ff 80 3d 95 6b 22 00 00 0f 85 b2 fe ff ff 
> 48 c7 c7 04 d2 a4 c0 c6 05 81 6b 22 00 01 e8 f6 5c 82 e0 <0f> 0b e9 98 fe ff 
> ff 80 3d 6d 6b 22 00 00 0f 85 95 fe ff ff 48 c7
>  RSP: 0018:b9c1c002fd08 EFLAGS: 00010296
>  RAX: 0018 RBX: 99aec8881010 RCX: 99aeda40
>  RDX:  RSI: a115d9ef RDI: a115d9ef
>  RBP: 00044004 R08: 0001 R09: 
>  R10: 0001 R11: 0001 R12: 
>  R13: 0001 R14:  R15: 
>  FS:  7f91257a9940() GS:99aeda40() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 7f9126829400 CR3: 0001088f0006 CR4: 001706e0
>  Call Trace:
>   gen3_irq_reset+0x2e/0xd0 [i915]
>   intel_irq_reset+0x59/0x6a0 [i915]
>   intel_runtime_pm_disable_interrupts+0xe/0x30 [i915]
>   i915_driver_shutdown+0x2e/0x40 [i915]
>   pci_device_shutdown+0x34/0x60
>   device_shutdown+0x15d/0x1b3
>   kernel_restart+0xe/0x30
>   __do_sys_reboot+0x1d7/0x210
>   ? vfs_writev+0x9d/0xe0
>   ? syscall_enter_from_user_mode+0x1d/0x70
>   ? trace_hardirqs_on+0x2c/0xe0
>   do_syscall_64+0x33/0x40
>   entry_SYSCALL_64_after_hwframe+0x44/0xa9
>  RIP: 0033:0x7f912675f2d7
>  Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 
> 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 
> 77 01 c3 48 8b 15 81 8b 0c 00 f7 d8 64 89 02 b8
>  RSP: 002b:7ffeca28e148 EFLAGS: 0206 ORIG_RAX: 00a9
>  RAX: ffda RBX:  RCX: 7f912675f2d7
>  RDX: 01234567 RSI: 28121969 RDI: fee1dead
>  RBP: 7ffeca28e3d0 R08: 000a R09: 
>  R10: 0232 R11: 0206 R12: 0001
>  R13:  R14:  R15: 7ffeca28e4b8
>  ---[ end trace 2ed17eabd3ab6938 ]---
>  [ cut here ]
> 
> The bisect came to this commit:
> 
>   fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
>   ("drm/i915: Shut down displays gracefully on reboot")
> 
> Which makes sense, as it happens on shutdown.
> 
> -- Steve

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[Steven Rostedt]

On reboot, one of my test boxes now triggers the following warning:

 [ cut here ]
 RPM raw-wakeref not held
 WARNING: CPU: 4 PID: 1 at drivers/gpu/drm/i915/intel_runtime_pm.h:106 
gen6_write32+0x1bc/0x2a0 [i915]
 Modules linked in: ebtable_filter ebtables bridge stp llc ip6t_REJECT 
nf_reject_ipv6 vsock vmw_vmci xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 ip6table_filter ip6_tables snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic le
15 snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep i2c_algo_bit 
snd_hda_core snd_seq intel_rapl_msr snd_seq_device intel_rapl_common snd_pcm 
x86_pkg_temp_thermal intel_powerclamp snd_timer snd coretemp kvm_intel 
soundcore kvm mei_wdt irqbypass joydev 
_pmc_bxt hp_wmi wmi_bmof sparse_keymap rfkill iTCO_vendor_support 
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel drm_kms_helper 
i2c_i801 cec drm rapl intel_cstate intel_uncore mei_me i2c_smbus e1000e 
tpm_infineon wmi serio_raw mei video lpc_i

 CPU: 4 PID: 1 Comm: systemd-shutdow Not tainted 5.9.0-rc4-test+ #861
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 RIP: 0010:gen6_write32+0x1bc/0x2a0 [i915]
 Code: 5d 82 e0 0f 0b e9 b5 fe ff ff 80 3d 95 6b 22 00 00 0f 85 b2 fe ff ff 48 
c7 c7 04 d2 a4 c0 c6 05 81 6b 22 00 01 e8 f6 5c 82 e0 <0f> 0b e9 98 fe ff ff 80 
3d 6d 6b 22 00 00 0f 85 95 fe ff ff 48 c7
 RSP: 0018:b9c1c002fd08 EFLAGS: 00010296
 RAX: 0018 RBX: 99aec8881010 RCX: 99aeda40
 RDX:  RSI: a115d9ef RDI: a115d9ef
 RBP: 00044004 R08: 0001 R09: 
 R10: 0001 R11: 0001 R12: 
 R13: 0001 R14:  R15: 
 FS:  7f91257a9940() GS:99aeda40() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 7f9126829400 CR3: 0001088f0006 CR4: 001706e0
 Call Trace:
  gen3_irq_reset+0x2e/0xd0 [i915]
  intel_irq_reset+0x59/0x6a0 [i915]
  intel_runtime_pm_disable_interrupts+0xe/0x30 [i915]
  i915_driver_shutdown+0x2e/0x40 [i915]
  pci_device_shutdown+0x34/0x60
  device_shutdown+0x15d/0x1b3
  kernel_restart+0xe/0x30
  __do_sys_reboot+0x1d7/0x210
  ? vfs_writev+0x9d/0xe0
  ? syscall_enter_from_user_mode+0x1d/0x70
  ? trace_hardirqs_on+0x2c/0xe0
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 RIP: 0033:0x7f912675f2d7
 Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 89 
fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 
c3 48 8b 15 81 8b 0c 00 f7 d8 64 89 02 b8
 RSP: 002b:7ffeca28e148 EFLAGS: 0206 ORIG_RAX: 00a9
 RAX: ffda RBX:  RCX: 7f912675f2d7
 RDX: 01234567 RSI: 28121969 RDI: fee1dead
 RBP: 7ffeca28e3d0 R08: 000a R09: 
 R10: 0232 R11: 0206 R12: 0001
 R13:  R14:  R15: 7ffeca28e4b8
 ---[ end trace 2ed17eabd3ab6938 ]---
 [ cut here ]

The bisect came to this commit:

  fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
  ("drm/i915: Shut down displays gracefully on reboot")

Which makes sense, as it happens on shutdown.

-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-5.12

[Alex Deucher]

Hi Dave, Daniel,

More new stuff for 5.12.

The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:

  drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921) 
(2021-01-08 15:18:57 -0500)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-next-5.12-2021-01-14

for you to fetch changes up to df1f0560d28f4895e2d61af826728efb61976f9f:

  drm/amd/display: Simplify bool comparison (2021-01-14 13:20:21 -0500)


amd-drm-next-5.12-2021-01-14:

amdgpu:
- W=1 fixes from Lee Jones
- Enable GPU reset on Navy Flounder
- Kernel doc fixes
- SMU workload profile fixes for APUs
- Display updates
- SR-IOV fixes
- Vangogh SMU feature enablment and bug fixes
- GPU reset support for Vangogh
- Misc cleanups


Alex Deucher (5):
  MAINTAINERS: update radeon/amdgpu/amdkfd git trees
  drm/amdgpu: add mode2 reset support for vangogh
  drm/amdgpu/nv: add mode2 reset handling
  drm/amdgpu: fix mode2 reset sequence for vangogh
  drm/amdgpu: Enable GPU reset for vangogh

Aric Cyr (2):
  drm/amd/display: 3.2.117
  drm/amd/display: 3.2.118

Bhawanpreet Lakha (2):
  drm/amd/display: enable HUBP blank behaviour
  drm/amd/display: Fix deadlock during gpu reset v3

Charlene Liu (1):
  drm/amd/display: change SMU repsonse timeout to 2s

Chiawen Huang (1):
  drm/amd/display: removed unnecessary check when dpp clock increasing

Colin Ian King (1):
  drm/amdgpu: Add missing BOOTUP_DEFAULT to profile_name[]

Emily.Deng (1):
  drm/amdgpu: Decrease compute timeout to 10 s for sriov multiple VF

Huang Rui (10):
  drm/amd/pm: remove vcn/jpeg powergating feature checking for vangogh
  drm/amd/pm: enhance the real response for smu message (v2)
  drm/amd/pm: clean up get_allowed_feature_mask function
  drm/amd/pm: initial feature_enabled/feature_support bitmap for vangogh
  drm/amd/pm: don't mark all apu as true on feature mask
  drm/amdgpu: revise the mode2 reset for vangogh
  drm/amd/pm: fix the return value of pm message
  drm/amd/pm: implement the processor clocks which read by metric
  drm/amd/pm: implement processor fine grain feature for vangogh (v3)
  drm/amdgpu: fix vram type and bandwidth error for DDR5 and DDR4

Jack Zhang (1):
  drm/amdgpu/sriov Stop data exchange for wholegpu reset

Jacky Liao (1):
  drm/amd/display: Fix assert being hit with GAMCOR memory shut down

Jeremy Cline (1):
  drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu()

Jiansong Chen (1):
  drm/amdgpu: enable gpu recovery for navy_flounder

Jinzhou Su (4):
  drm/amd/pm: Add GFXOFF interface for Vangogh
  drm/amd/pm: Enable GfxOff for Vangogh
  drm/amdgpu: Add Secure Display TA header file
  drm/amdgpu: Add secure display TA interface

Jun Lei (1):
  drm/amd/display: implement T12 compliance

Lee Jones (90):
  drm/amd/amdgpu/amdgpu_ih: Update 'amdgpu_ih_decode_iv_helper()'s function 
header
  drm/amd/amdgpu/vega20_ih: Add missing descriptions for 'ih' and fix 
spelling error
  drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Provide description of 
'call_back_func'
  drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix documentation for 'mpll_param'
  drm/amd/pm/powerplay/hwmgr/vega12_hwmgr: Fix legacy function header 
formatting
  drm/amd/pm/powerplay/hwmgr/vega20_hwmgr: Fix legacy function header 
formatting
  drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix formatting and spelling issues
  drm/amd/pm/powerplay/hwmgr/hwmgr: Move prototype into shared header
  drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix a bunch of kernel-doc 
formatting issues
  drm/amd/display/dc/basics/conversion: Demote obvious kernel-doc abuse
  drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs: Demote non-kernel-doc 
comment blocks
  drm/amd/display/dc/bios/command_table_helper: Fix kernel-doc formatting
  drm/amd/display/dc/bios/command_table_helper2: Fix legacy formatting 
problems
  drm/amd/display/dc/bios/bios_parser: Make local functions static
  drm/amd/display/dc/bios/bios_parser: Fix a whole bunch of legacy doc 
formatting
  drm/amd/display/dc/bios/bios_parser2: Fix some formatting issues and 
missing parameter docs
  drm/amd/display/dc/dce/dce_audio: Make function invoked by reference 
static
  drm/amd/display/dc/dce/dce_stream_encoder: Remove unused variable 'regval'
  drm/amd/display/dc/dce/dce_link_encoder: Make functions invoked by 
reference static
  drm/amd/display/dc/dce/dce_clock_source: Fix formatting/spelling of 
worthy function headers
  drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix worthy function headers, 
demote barely documented one
  drm/amd/display/dc/dce/dce_transform: Remove 3 unused/legacy variables
  drm/amd/display/dc/dce/dce_dmcu: 

[PATCH rdma-core v5 3/6] mlx5: Support dma-buf based memory region

[Jianxin Xiong]

Implement the new provider method for registering dma-buf based memory
regions.

Signed-off-by: Jianxin Xiong 
---
 providers/mlx5/mlx5.c  |  2 ++
 providers/mlx5/mlx5.h  |  3 +++
 providers/mlx5/verbs.c | 22 ++
 3 files changed, 27 insertions(+)

diff --git a/providers/mlx5/mlx5.c b/providers/mlx5/mlx5.c
index a2a1696..b3c49af 100644
--- a/providers/mlx5/mlx5.c
+++ b/providers/mlx5/mlx5.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2012 Mellanox Technologies, Inc.  All rights reserved.
+ * Copyright (c) 2020 Intel Corporation.  All rights reserved.
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -95,6 +96,7 @@ static const struct verbs_context_ops mlx5_ctx_common_ops = {
.async_event   = mlx5_async_event,
.dealloc_pd= mlx5_free_pd,
.reg_mr= mlx5_reg_mr,
+   .reg_dmabuf_mr = mlx5_reg_dmabuf_mr,
.rereg_mr  = mlx5_rereg_mr,
.dereg_mr  = mlx5_dereg_mr,
.alloc_mw  = mlx5_alloc_mw,
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index bafe077..decc7f8 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2012 Mellanox Technologies, Inc.  All rights reserved.
+ * Copyright (c) 2020 Intel Corporation.  All rights reserved.
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -941,6 +942,8 @@ void mlx5_async_event(struct ibv_context *context,
 struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd);
 struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
   uint64_t hca_va, int access);
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t 
length,
+ uint64_t iova, int fd, int access);
 int mlx5_rereg_mr(struct verbs_mr *mr, int flags, struct ibv_pd *pd, void 
*addr,
  size_t length, int access);
 int mlx5_dereg_mr(struct verbs_mr *mr);
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index b2391e8..cc0bc42 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2012 Mellanox Technologies, Inc.  All rights reserved.
+ * Copyright (c) 2020 Intel Corporation.  All rights reserved.
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -626,6 +627,27 @@ struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, 
size_t length,
return >vmr.ibv_mr;
 }
 
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t 
length,
+ uint64_t iova, int fd, int acc)
+{
+   struct mlx5_mr *mr;
+   int ret;
+
+   mr = calloc(1, sizeof(*mr));
+   if (!mr)
+   return NULL;
+
+   ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, acc,
+   >vmr);
+   if (ret) {
+   free(mr);
+   return NULL;
+   }
+   mr->alloc_flags = acc;
+
+   return >vmr.ibv_mr;
+}
+
 struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd)
 {
struct mlx5_mr *mr;
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH rdma-core v5 0/6] Add user space dma-buf support

[Jianxin Xiong]

This is the fifth version of the patch series. Change log:

v5:
* Use a different mr_type for dmabuf so that ibv_dofork_range() is not
  called inside ibv_dereg_mr() for dmabuf based mr

v4: https://www.spinics.net/lists/linux-rdma/msg98135.html
* Rework the cmake funciton rdma_cython_module to support both single
  source (.pyx) and multiple source (.pyx + [.c]*) scenarios instead
  of using two separate functions
* Rename 'dri_*' to 'drm_*' for the dmabuf allocation interface
* Add option to dmabuf allocation routine to allow allocation from GTT
  instead of VRAM
* Add proper CPU access flags when allocating dmabufs
* Remove 'radeon' driver support from the dmabuf allocation routines
* Add comand line arguments to the tests for selecting GPU unit and
  setting the option for allocating from GTT

v3: https://www.spinics.net/lists/linux-rdma/msg98059.html
* Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API
* Change the way of allocating dma-buf object - use /dev/dri/renderD*
  instead of /dev/dri/card* and use GEM object instead of dumb buffer
* Add cmake function to allow building modules with mixed cython and C
  source files
* Add new tests that use dma-buf MRs for send/recv and rdma traffic
* Skip dma-buf tests on unsupported systems
* Remove some use of random values in the new tests
* Add dealloc() and close() methods to the new classes
* Replace string.format with f-string in python code
* Fix some coding style issues: spacing, indentation, typo, comments

v2: https://www.spinics.net/lists/linux-rdma/msg97936.html
* Put the kernel header updates into a separate commit
* Add comments for the data structure used in python ioctl calls
* Fix issues related to symbol versioning
* Fix styling issues: extra spaces, unncecessary variable, typo
* Fix an inproper error code usage
* Put the new op into ibv_context_ops instead if verbs_context

v1: https://www.spinics.net/lists/linux-rdma/msg97865.html
* Add user space API for registering dma-buf based memory regions
* Update pyverbs with the new API
* Add new tests

This is the user space counter-part of the kernel patch set to add
dma-buf support to the RDMA subsystem.

This series consists of six patches. The first patch updates the
kernel headers for dma-buf support. Patch 2 adds the new API function
and updates the man pages. Patch 3 implements the new API in the mlx5
provider. Patch 4 adds new class definitions to pyverbs for the new API.
Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in
the utility code of the tests.

Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895

Jianxin Xiong (6):
  Update kernel headers
  verbs: Support dma-buf based memory region
  mlx5: Support dma-buf based memory region
  pyverbs: Add dma-buf based MR support
  tests: Add tests for dma-buf based memory regions
  tests: Bug fix for get_access_flags()

 buildlib/pyverbs_functions.cmake |  78 ++---
 debian/libibverbs1.symbols   |   2 +
 kernel-headers/rdma/ib_user_ioctl_cmds.h |  14 ++
 libibverbs/CMakeLists.txt|   2 +-
 libibverbs/cmd_mr.c  |  38 +
 libibverbs/driver.h  |   8 +
 libibverbs/dummy_ops.c   |  11 ++
 libibverbs/libibverbs.map.in |   6 +
 libibverbs/man/ibv_reg_mr.3  |  27 ++-
 libibverbs/verbs.c   |  18 ++
 libibverbs/verbs.h   |  11 ++
 providers/mlx5/mlx5.c|   2 +
 providers/mlx5/mlx5.h|   3 +
 providers/mlx5/verbs.c   |  22 +++
 pyverbs/CMakeLists.txt   |  11 +-
 pyverbs/dmabuf.pxd   |  15 ++
 pyverbs/dmabuf.pyx   |  73 
 pyverbs/dmabuf_alloc.c   | 278 +++
 pyverbs/dmabuf_alloc.h   |  19 +++
 pyverbs/libibverbs.pxd   |   2 +
 pyverbs/mr.pxd   |   6 +
 pyverbs/mr.pyx   | 105 +++-
 tests/args_parser.py |   4 +
 tests/test_mr.py | 264 -
 tests/utils.py   |  30 +++-
 25 files changed, 1013 insertions(+), 36 deletions(-)
 create mode 100644 pyverbs/dmabuf.pxd
 create mode 100644 pyverbs/dmabuf.pyx
 create mode 100644 pyverbs/dmabuf_alloc.c
 create mode 100644 pyverbs/dmabuf_alloc.h

-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH rdma-core v5 6/6] tests: Bug fix for get_access_flags()

[Jianxin Xiong]

The filter definition is wrong and causes get_access_flags() always
returning empty list. As the result the MR tests using this function
are effectively skipped (but report success).

Signed-off-by: Jianxin Xiong 
---
 tests/utils.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/utils.py b/tests/utils.py
index 8546329..c41cb3b 100644
--- a/tests/utils.py
+++ b/tests/utils.py
@@ -58,8 +58,8 @@ def filter_illegal_access_flags(element):
 :param element: A list of access flags to check
 :return: True if this list is legal, else False
 """
-if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE:
-if e.IBV_ACCESS_LOCAL_WRITE:
+if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE in 
element:
+if not e.IBV_ACCESS_LOCAL_WRITE in element:
 return False
 return True
 
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH rdma-core v5 4/6] pyverbs: Add dma-buf based MR support

[Jianxin Xiong]

Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.

Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.

Signed-off-by: Jianxin Xiong 
---
 buildlib/pyverbs_functions.cmake |  78 +++
 pyverbs/CMakeLists.txt   |  11 +-
 pyverbs/dmabuf.pxd   |  15 +++
 pyverbs/dmabuf.pyx   |  73 ++
 pyverbs/dmabuf_alloc.c   | 278 +++
 pyverbs/dmabuf_alloc.h   |  19 +++
 pyverbs/libibverbs.pxd   |   2 +
 pyverbs/mr.pxd   |   6 +
 pyverbs/mr.pyx   | 105 ++-
 9 files changed, 557 insertions(+), 30 deletions(-)
 create mode 100644 pyverbs/dmabuf.pxd
 create mode 100644 pyverbs/dmabuf.pyx
 create mode 100644 pyverbs/dmabuf_alloc.c
 create mode 100644 pyverbs/dmabuf_alloc.h

diff --git a/buildlib/pyverbs_functions.cmake b/buildlib/pyverbs_functions.cmake
index 953cec2..0792410 100644
--- a/buildlib/pyverbs_functions.cmake
+++ b/buildlib/pyverbs_functions.cmake
@@ -1,35 +1,61 @@
 # SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
 # Copyright (c) 2018, Mellanox Technologies. All rights reserved.  See COPYING 
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved.  See COPYING file
+
+function(build_module_from_cfiles PY_MODULE MODULE_NAME ALL_CFILES 
LINKER_FLAGS)
+  string(REGEX REPLACE "\\.so$" "" SONAME 
"${MODULE_NAME}${CMAKE_PYTHON_SO_SUFFIX}")
+  add_library(${SONAME} SHARED ${ALL_CFILES})
+  set_target_properties(${SONAME} PROPERTIES
+COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing 
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type 
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option 
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
+LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
+PREFIX "")
+  target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs 
rdmacm ${LINKER_FLAGS})
+  install(TARGETS ${SONAME}
+DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+endfunction()
 
 function(rdma_cython_module PY_MODULE LINKER_FLAGS)
-  foreach(PYX_FILE ${ARGN})
-get_filename_component(FILENAME ${PYX_FILE} NAME_WE)
-get_filename_component(DIR ${PYX_FILE} DIRECTORY)
-   if (DIR)
-   set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}/${FILENAME}.pyx")
-   else()
-   set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${FILENAME}.pyx")
-   endif()
-set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
-include_directories(${PYTHON_INCLUDE_DIRS})
-add_custom_command(
-  OUTPUT "${CFILE}"
-  MAIN_DEPENDENCY "${PYX}"
-  COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
-  "-I${PYTHON_INCLUDE_DIRS}"
-  COMMENT "Cythonizing ${PYX}"
+  set(ALL_CFILES "")
+  set(MODULE_NAME "")
+  foreach(SRC_FILE ${ARGN})
+get_filename_component(FILENAME ${SRC_FILE} NAME_WE)
+get_filename_component(DIR ${SRC_FILE} DIRECTORY)
+get_filename_component(EXT ${SRC_FILE} EXT)
+if (DIR)
+  set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}")
+else()
+  set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+endif()
+if (${EXT} STREQUAL ".pyx")
+  # each .pyx file starts a new module, finish the previous module first
+  if (ALL_CFILES AND MODULE_NAME)
+build_module_from_cfiles(${PY_MODULE} ${MODULE_NAME} "${ALL_CFILES}" 
"${LINKER_FLAGS}")
+  endif()
+  set(PYX "${SRC_PATH}/${FILENAME}.pyx")
+  set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
+  include_directories(${PYTHON_INCLUDE_DIRS})
+  add_custom_command(
+OUTPUT "${CFILE}"
+MAIN_DEPENDENCY "${PYX}"
+COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
+"-I${PYTHON_INCLUDE_DIRS}"
+COMMENT "Cythonizing ${PYX}"
   )
-
-string(REGEX REPLACE "\\.so$" "" SONAME 
"${FILENAME}${CMAKE_PYTHON_SO_SUFFIX}")
-add_library(${SONAME} SHARED ${CFILE})
-set_target_properties(${SONAME} PROPERTIES
-  COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing 
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type 
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option 
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
-  LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
-  PREFIX "")
-target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs 
rdmacm ${LINKER_FLAGS})
-install(TARGETS ${SONAME}
-  DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+  set(MODULE_NAME ${FILENAME})
+  set(ALL_CFILES "${CFILE}")
+elseif(${EXT} STREQUAL ".c")
+  # .c files belong to the same module as the most recent .pyx file,
+  # ignored if appearing before all .pyx files
+  set(CFILE 

[PATCH rdma-core v5 2/6] verbs: Support dma-buf based memory region

[Jianxin Xiong]

Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.

Signed-off-by: Jianxin Xiong 
---
 debian/libibverbs1.symbols   |  2 ++
 libibverbs/CMakeLists.txt|  2 +-
 libibverbs/cmd_mr.c  | 38 ++
 libibverbs/driver.h  |  8 
 libibverbs/dummy_ops.c   | 11 +++
 libibverbs/libibverbs.map.in |  6 ++
 libibverbs/man/ibv_reg_mr.3  | 27 +--
 libibverbs/verbs.c   | 18 ++
 libibverbs/verbs.h   | 11 +++
 9 files changed, 120 insertions(+), 3 deletions(-)

diff --git a/debian/libibverbs1.symbols b/debian/libibverbs1.symbols
index 9130f41..fcf4d87 100644
--- a/debian/libibverbs1.symbols
+++ b/debian/libibverbs1.symbols
@@ -9,6 +9,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
  IBVERBS_1.9@IBVERBS_1.9 30
  IBVERBS_1.10@IBVERBS_1.10 31
  IBVERBS_1.11@IBVERBS_1.11 32
+ IBVERBS_1.12@IBVERBS_1.12 33
  (symver)IBVERBS_PRIVATE_33 33
  _ibv_query_gid_ex@IBVERBS_1.11 32
  _ibv_query_gid_table@IBVERBS_1.11 32
@@ -99,6 +100,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
  ibv_rate_to_mbps@IBVERBS_1.1 1.1.8
  ibv_rate_to_mult@IBVERBS_1.0 1.1.6
  ibv_read_sysfs_file@IBVERBS_1.0 1.1.6
+ ibv_reg_dmabuf_mr@IBVERBS_1.12 33
  ibv_reg_mr@IBVERBS_1.0 1.1.6
  ibv_reg_mr@IBVERBS_1.1 1.1.6
  ibv_reg_mr_iova@IBVERBS_1.7 25
diff --git a/libibverbs/CMakeLists.txt b/libibverbs/CMakeLists.txt
index 0fe4256..d075225 100644
--- a/libibverbs/CMakeLists.txt
+++ b/libibverbs/CMakeLists.txt
@@ -21,7 +21,7 @@ configure_file("libibverbs.map.in"
 
 rdma_library(ibverbs "${CMAKE_CURRENT_BINARY_DIR}/libibverbs.map"
   # See Documentation/versioning.md
-  1 1.11.${PACKAGE_VERSION}
+  1 1.12.${PACKAGE_VERSION}
   all_providers.c
   cmd.c
   cmd_ah.c
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index 42dbe42..af0fad7 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2018 Mellanox Technologies, Ltd.  All rights reserved.
+ * Copyright (c) 2020 Intel Corporation.  All rights reserved.
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr 
*vmr,
return 0;
 }
 
+int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
+ uint64_t iova, int fd, int access,
+ struct verbs_mr *vmr)
+{
+   DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
+  UVERBS_METHOD_REG_DMABUF_MR,
+  9);
+   struct ib_uverbs_attr *handle;
+   uint32_t lkey, rkey;
+   int ret;
+
+   handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+   fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, );
+   fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, );
+
+   fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
+   fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
+   fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
+   fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
+   fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
+   fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS, 
access);
+
+   ret = execute_ioctl(pd->context, cmdb);
+   if (ret)
+   return errno;
+
+   vmr->ibv_mr.handle = read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+  handle);
+   vmr->ibv_mr.context = pd->context;
+   vmr->ibv_mr.lkey = lkey;
+   vmr->ibv_mr.rkey = rkey;
+   vmr->ibv_mr.pd = pd;
+   vmr->ibv_mr.addr = (void *)offset;
+   vmr->ibv_mr.length = length;
+   vmr->mr_type = IBV_MR_TYPE_DMABUF_MR;
+   return 0;
+}
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index 427c225..0798152 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -2,6 +2,7 @@
  * Copyright (c) 2004, 2005 Topspin Communications.  All rights reserved.
  * Copyright (c) 2005, 2006 Cisco Systems, Inc.  All rights reserved.
  * Copyright (c) 2005 PathScale, Inc.  All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -87,6 +88,7 @@ enum ibv_mr_type {
IBV_MR_TYPE_MR,
IBV_MR_TYPE_NULL_MR,
IBV_MR_TYPE_IMPORTED_MR,
+   IBV_MR_TYPE_DMABUF_MR,
 };
 
 struct verbs_mr {
@@ -371,6 +373,9 @@ struct verbs_context_ops {
struct ibv_mr *(*reg_dm_mr)(struct ibv_pd *pd, struct ibv_dm *dm,
uint64_t dm_offset, size_t length,
unsigned int access);

[PATCH rdma-core v5 5/6] tests: Add tests for dma-buf based memory regions

[Jianxin Xiong]

Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.

Signed-off-by: Jianxin Xiong 
---
 tests/args_parser.py |   4 +
 tests/test_mr.py | 264 ++-
 tests/utils.py   |  26 +
 3 files changed, 293 insertions(+), 1 deletion(-)

diff --git a/tests/args_parser.py b/tests/args_parser.py
index 71a0f34..4e12d52 100644
--- a/tests/args_parser.py
+++ b/tests/args_parser.py
@@ -16,6 +16,10 @@ class ArgsParser(object):
 parser = argparse.ArgumentParser()
 parser.add_argument('--dev',
 help='RDMA device to run the tests on')
+parser.add_argument('--gpu', nargs='?', type=int, const=0, default=0,
+help='GPU unit to allocate dmabuf from')
+parser.add_argument('--gtt', action='store_true', default=False,
+help='Allocate dmabuf from GTT instead of VRAM')
 parser.add_argument('-v', '--verbose', dest='verbosity',
 action='store_const',
 const=2, help='Verbose output')
diff --git a/tests/test_mr.py b/tests/test_mr.py
index adc649c..6915853 100644
--- a/tests/test_mr.py
+++ b/tests/test_mr.py
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
 # Copyright (c) 2019 Mellanox Technologies, Inc. All rights reserved. See 
COPYING file
+# Copyright (c) 2020 Intel Corporation. All rights reserved. See COPYING file
 """
 Test module for pyverbs' mr module.
 """
@@ -9,9 +10,10 @@ import errno
 
 from tests.base import PyverbsAPITestCase, RCResources, RDMATestCase
 from pyverbs.pyverbs_error import PyverbsRDMAError, PyverbsError
-from pyverbs.mr import MR, MW, DMMR, MWBindInfo, MWBind
+from pyverbs.mr import MR, MW, DMMR, DmaBufMR, MWBindInfo, MWBind
 from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
 from pyverbs.wr import SendWR
+from pyverbs.dmabuf import DmaBuf
 import pyverbs.device as d
 from pyverbs.pd import PD
 import pyverbs.enums as e
@@ -366,3 +368,263 @@ class DMMRTest(PyverbsAPITestCase):
 dm_mr = DMMR(pd, dm_mr_len, e.IBV_ACCESS_ZERO_BASED,
  dm=dm, offset=dm_mr_offset)
 dm_mr.close()
+
+
+def check_dmabuf_support(unit=0):
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.ENOENT:
+raise unittest.SkipTest(f'Device /dev/dri/renderD{device_num} is 
not present')
+if ex.error_code == errno.EACCES:
+raise unittest.SkipTest(f'Lack of permission to access 
/dev/dri/renderD{device_num}')
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest(f'Allocating dmabuf is not supported by 
/dev/dri/renderD{device_num}')
+
+
+def check_dmabuf_mr_support(pd, unit=0):
+"""
+Check if dma-buf MR registration is supported by the driver.
+Skip the test on failure
+"""
+try:
+DmaBufMR(pd, 1, 0, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest('Reg dma-buf MR is not supported by the 
RDMA driver')
+
+
+class DmaBufMRTest(PyverbsAPITestCase):
+"""
+Test various functionalities of the DmaBufMR class.
+"""
+def setUp(self):
+super().setUp()
+self.unit = self.config['gpu']
+self.gtt = self.config['gtt']
+
+def test_dmabuf_reg_mr(self):
+"""
+Test ibv_reg_dmabuf_mr()
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+  gtt=self.gtt) as mr:
+pass
+
+def test_dmabuf_dereg_mr(self):
+"""
+Test ibv_dereg_mr() with DmaBufMR
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+  gtt=self.gtt) as mr:
+

[PATCH rdma-core v5 1/6] Update kernel headers

[Jianxin Xiong]

To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").

Signed-off-by: Jianxin Xiong 
---
 kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h 
b/kernel-headers/rdma/ib_user_ioctl_cmds.h
index 7968a18..dafc7eb 100644
--- a/kernel-headers/rdma/ib_user_ioctl_cmds.h
+++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2018, Mellanox Technologies inc.  All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -251,6 +252,7 @@ enum uverbs_methods_mr {
UVERBS_METHOD_MR_DESTROY,
UVERBS_METHOD_ADVISE_MR,
UVERBS_METHOD_QUERY_MR,
+   UVERBS_METHOD_REG_DMABUF_MR,
 };
 
 enum uverbs_attrs_mr_destroy_ids {
@@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
UVERBS_ATTR_QUERY_MR_RESP_IOVA,
 };
 
+enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
+   UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+   UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+   UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+   UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+   UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+   UVERBS_ATTR_REG_DMABUF_MR_FD,
+   UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+   UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+   UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+};
+
 enum uverbs_attrs_create_counters_cmd_attr_ids {
UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
 };
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Felix Kuehling]

Am 2021-01-14 um 11:51 a.m. schrieb Jerome Glisse:
> On Thu, Jan 14, 2021 at 02:37:36PM +0100, Christian König wrote:
>> Am 14.01.21 um 12:52 schrieb Daniel Vetter:
>>> [SNIP]
> I had a new idea, i wanted to think more about it but have not yet,
> anyway here it is. Adding a new callback to dma fence which ask the
> question can it dead lock ? Any time a GPU driver has pending page
> fault (ie something calling into the mm) it answer yes, otherwise
> no. The GPU shrinker would ask the question before waiting on any
> dma-fence and back of if it gets yes. Shrinker can still try many
> dma buf object for which it does not get a yes on associated fence.
>
> This does not solve the mmu notifier case, for this you would just
> invalidate the gem userptr object (with a flag but not releasing the
> page refcount) but you would not wait for the GPU (ie no dma fence
> wait in that code path anymore). The userptr API never really made
> the contract that it will always be in sync with the mm view of the
> world so if different page get remapped to same virtual address
> while GPU is still working with the old pages it should not be an
> issue (it would not be in our usage of userptr for compositor and
> what not).
 The current working idea in my mind goes into a similar direction.

 But instead of a callback I'm adding a complete new class of HMM fences.

 Waiting in the MMU notfier, scheduler, TTM etc etc is only allowed for
 the dma_fences and HMM fences are ignored in container objects.

 When you handle an implicit or explicit synchronization request from
 userspace you need to block for HMM fences to complete before taking any
 resource locks.
>>> Isnt' that what I call gang scheduling? I.e. you either run in HMM
>>> mode, or in legacy fencing mode (whether implicit or explicit doesn't
>>> really matter I think). By forcing that split we avoid the problem,
>>> but it means occasionally full stalls on mixed workloads.
>>>
>>> But that's not what Jerome wants (afaiui at least), I think his idea
>>> is to track the reverse dependencies of all the fences floating
>>> around, and then skip evicting an object if you have to wait for any
>>> fence that is problematic for the current calling context. And I don't
>>> think that's very feasible in practice.
>>>
>>> So what kind of hmm fences do you have in mind here?
>> It's a bit more relaxed than your gang schedule.
>>
>> See the requirements are as follow:
>>
>> 1. dma_fences never depend on hmm_fences.
>> 2. hmm_fences can never preempt dma_fences.
>> 3. dma_fences must be able to preempt hmm_fences or we always reserve enough
>> hardware resources (CUs) to guarantee forward progress of dma_fences.
>>
>> Critical sections are MMU notifiers, page faults, GPU schedulers and
>> dma_reservation object locks.
>>
>> 4. It is valid to wait for a dma_fences in critical sections.
>> 5. It is not valid to wait for hmm_fences in critical sections.
>>
>> Fence creation either happens during command submission or by adding
>> something like a barrier or signal command to your userspace queue.
>>
>> 6. If we have an hmm_fence as implicit or explicit dependency for creating a
>> dma_fence we must wait for that before taking any locks or reserving
>> resources.
>> 7. If we have a dma_fence as implicit or explicit dependency for creating an
>> hmm_fence we can wait later on. So busy waiting or special WAIT hardware
>> commands are valid.
>>
>> This prevents hard cuts, e.g. can mix hmm_fences and dma_fences at the same
>> time on the hardware.
>>
>> In other words we can have a high priority gfx queue running jobs based on
>> dma_fences and a low priority compute queue running jobs based on
>> hmm_fences.
>>
>> Only when we switch from hmm_fence to dma_fence we need to block the
>> submission until all the necessary resources (both memory as well as CUs)
>> are available.
>>
>> This is somewhat an extension to your gang submit idea.
> What is hmm_fence ? You should not have fence with hmm at all.
> So i am kind of scare now.

I kind of had the same question trying to follow Christian and Daniel's
discussion. I think an HMM fence would be any fence resulting from the
completion of a user mode operation in a context with HMM-based memory
management that may stall indefinitely due to page faults.

But on a hardware engine that cannot preempt page-faulting work and has
not reserved resources to guarantee forward progress for kernel jobs, I
think all fences will need to be HMM fences, because any work submitted
to such an engine can stall by getting stuck behind a stalled user mode
operation.

So for example, you have a DMA engine that can preempt during page
faults, but a graphics engine that cannot. Then work submitted to the
DMA engine can use dma_fence. But work submitted to the graphics engine
must use hmm_fence. To avoid deadlocks, dma_fences must never depend on
hmm_fences 

Re: [PATCH v4 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU

[Rob Herring]

On Tue, Jan 12, 2021 at 02:49:32PM +0800, Nick Fan wrote:
> Add devicetree schema for Arm Mali Valhall GPU
> 
> Define a compatible string for the Mali Valhall GPU
> for Mediatek's SoC platform.
> 
> Signed-off-by: Nick Fan 
> ---
>  .../bindings/gpu/arm,mali-valhall.yaml| 252 ++
>  1 file changed, 252 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml 
> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> new file mode 100644
> index ..ecf249a58435
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> @@ -0,0 +1,252 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM Mali Valhall GPU
> +
> +maintainers:
> +  - Rob Herring 
> +
> +properties:
> +  $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
> +  compatible:
> +items:
> +  - enum:
> +  - mediatek,mt8192-mali
> +  - const: arm,mali-valhall
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +items:
> +  - description: GPU interrupt
> +  - description: MMU interrupt
> +  - description: Job interrupt
> +
> +  interrupt-names:
> +items:
> +  - const: gpu
> +  - const: mmu
> +  - const: job
> +
> +  clocks:
> +minItems: 1
> +
> +  power-domains:
> +minItems: 1
> +maxItems: 5
> +
> +  mali-supply: true
> +  sram-supply: true
> +
> +  operating-points-v2: true
> +
> +  "#cooling-cells":
> +const: 2
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-names
> +  - clocks
> +
> +additionalProperties: false
> +
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: mediatek,mt8192-mali
> +then:
> +  properties:
> +sram-supply: true
> +power-domains:
> +  description:
> +List of phandle and PM domain specifier as documented in
> +Documentation/devicetree/bindings/power/power_domain.txt
> +  minItems: 5
> +  maxItems: 5
> +power-domain-names:
> +  items:
> +- const: core0
> +- const: core1
> +- const: core2
> +- const: core3
> +- const: core4
> +
> +  required:
> +- sram-supply
> +- power-domains
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +gpu@1300 {
> +   compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
> +   reg = <0x1300 0x4000>;
> +   interrupts =
> +   ,
> +   ,
> +   ;
> +   interrupt-names =
> +   "gpu",
> +   "mmu",
> +   "job";
> +
> +   clocks = < 0>;
> +
> +   power-domains =
> +   < 4>,
> +   < 5>,
> +   < 6>,
> +   < 7>,
> +   < 8>;
> +
> +   operating-points-v2 = <_opp_table>;
> +   mali-supply = <_7_vbuck1>;
> +   sram-supply = <_vsram_others_ldo_reg>;
> +};
> +
> +gpu_opp_table: opp_table0 {

Make this a child node of the gpu node.

> +  compatible = "operating-points-v2";
> +  opp-shared;
> +
> +  opp-35800 {
> +  opp-hz = /bits/ 64 <35800>;
> +  opp-hz-real = /bits/ 64 <35800>,
> +/bits/ 64 <35800>;

This is not part of the OPP binding. It's not clear what it's purpose 
would be given the values are always the same as opp-hz.


> +  opp-microvolt = <606250>,
> +  <75>;
> +  };
> +
> +  opp-39900 {
> +  opp-hz = /bits/ 64 <39900>;
> +  opp-hz-real = /bits/ 64 <39900>,
> +/bits/ 64 <39900>;
> +  opp-microvolt = <618750>,
> +  <75>;
> +  };
> +
> +  opp-44000 {
> +  opp-hz = /bits/ 64 <44000>;
> +  opp-hz-real = /bits/ 64 <44000>,
> +/bits/ 64 <44000>;
> +  opp-microvolt = <631250>,
> +  <75>;
> +  };
> +
> +  opp-48200 {
> +  opp-hz = /bits/ 64 <48200>;
> +  opp-hz-real = /bits/ 64 <48200>,
> +/bits/ 64 <48200>;
> +  opp-microvolt = <643750>,
> +  <75>;
> +  };
> +
> +  opp-52300 {
> +  opp-hz = /bits/ 64 <52300>;
> +  opp-hz-real = /bits/ 64 <52300>,
> +/bits/ 64 <52300>;
> +

[pull] amdgpu, amdkfd drm-fixes-5.11

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.11.

The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:

  Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-5.11-2021-01-14

for you to fetch changes up to 2f0fa789f7b9fb022440f8f846cae175233987aa:

  drm/amd/display: Fix to be able to stop crc calculation (2021-01-14 14:06:43 
-0500)


amd-drm-fixes-5.11-2021-01-14:

amdgpu:
- Update repo location in MAINTAINERS
- Add some new renoir PCI IDs
- Revert CRC UAPI changes
- Revert OLED display fix which cases clocking problems for some systems
- Misc vangogh fixes
- GFX fix for sienna cichlid
- DCN1.0 fix for pipe split
- Fix incorrect PSP command

amdkfd:
- Fix possible out of bounds read in vcrat creation


Alex Deucher (1):
  MAINTAINERS: update radeon/amdgpu/amdkfd git trees

Alexandre Demers (1):
  drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 
210921)

Huang Rui (1):
  drm/amdgpu: fix vram type and bandwidth error for DDR5 and DDR4

Jeremy Cline (1):
  drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu()

Li, Roman (1):
  drm/amd/display: disable dcn10 pipe split by default

Likun Gao (1):
  drm/amdgpu: set power brake sequence

Nikola Cornij (1):
  drm/amd/display: Add a missing DCN3.01 API mapping

Prike Liang (1):
  drm/amdgpu: add green_sardine device id (v2)

Qingqing Zhuo (1):
  drm/amd/display: NULL pointer hang

Rodrigo Siqueira (4):
  Revert "drm/amd/display: Fixed Intermittent blue screen on OLED panel"
  Revert "drm/amd/display: Fix unused variable warning"
  Revert "drm/amdgpu/disply: fix documentation warnings in display manager"
  Revert "drm/amd/display: Expose new CRC window property"

Victor Zhao (1):
  drm/amdgpu/psp: fix psp gfx ctrl cmds

Wayne Lin (1):
  drm/amd/display: Fix to be able to stop crc calculation

Wesley Chalmers (1):
  drm/amd/display: Initialize stack variable

chen gong (1):
  drm/amdgpu/gfx10: add updated GOLDEN_TSC_COUNT_UPPER/LOWER register 
offsets for VGH

mengwang (1):
  drm/amdgpu: add new device id for Renior

 MAINTAINERS|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c   |  53 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   2 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  48 ++-
 drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h|   2 +-
 drivers/gpu/drm/amd/amdgpu/soc15.c |   3 +-
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c  |  11 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 142 ++---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  38 --
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |  54 +---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h  |   5 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |   8 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c   |   2 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |   4 +-
 .../drm/amd/display/dc/dcn301/dcn301_resource.c|   1 +
 .../display/dc/dml/dcn20/display_mode_vba_20v2.c   |  11 +-
 17 files changed, 125 insertions(+), 265 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Daniel Vetter]

On Thu, Jan 14, 2021 at 08:08:06PM +0100, Christian König wrote:
> Am 14.01.21 um 17:36 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 5:01 PM Christian König
> >  wrote:
> > > Am 14.01.21 um 16:40 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > > So I think we have to somehow solve this in the kernel or we will go 
> > > > > in
> > > > > circles all the time.
> > > > > 
> > > > > > So from that pov I think the kernel should at most deal with an
> > > > > > hmm_fence for cross-process communication and maybe some standard 
> > > > > > wait
> > > > > > primitives (for userspace to use, not for the kernel).
> > > > > > 
> > > > > > The only use case this would forbid is using page faults for legacy
> > > > > > implicit/explicit dma_fence synced workloads, and I think that's
> > > > > > perfectly ok to not allow. Especially since the motivation here for
> > > > > > all this is compute, and compute doesn't pass around dma_fences
> > > > > > anyway.
> > > > > As Alex said we will rather soon see this for gfx as well and we most
> > > > > likely will see combinations of old dma_fence based integrated 
> > > > > graphics
> > > > > with new dedicated GPUs.
> > > > > 
> > > > > So I don't think we can say we reduce the problem to compute and don't
> > > > > support anything else.
> > > > I'm not against pagefaults for gfx, just in pushing the magic into the
> > > > kernel. I don't think that works, because it means we add stall points
> > > > where usespace, especially vk userspace, really doesn't want it. So
> > > > same way like timeline syncobj, we need to push the compat work into
> > > > userspace.
> > > > 
> > > > There's going to be a few stall points:
> > > > - fully new stack, we wait for the userspace fence in the atomic
> > > > commit path (which we can, if we're really careful, since we pin all
> > > > buffers upfront and so there's no risk)
> > > > - userspace fencing gpu in the client, compositor protocol can pass
> > > > around userspace fences, but the compositor still uses dma_fence for
> > > > itself. There's some stalling in the compositor, which it does already
> > > > anyway when it's collecting new frames from clients
> > > > - userspace fencing gpu in the client, but no compositor protocol: We
> > > > wait in the swapchain, but in a separate thread so that nothing blocks
> > > > that shouldn't block
> > > > 
> > > > If we instead go with "magic waits in the kernel behind userspace's
> > > > back", like what your item 6 would imply, then we're not really
> > > > solving anything.
> > > > 
> > > > For actual implementation I think the best would be an extension of
> > > > drm_syncobj. Those already have at least conceptually future/infinite
> > > > fences, and we already have fd passing, so "just" need some protocol
> > > > to pass them around. Plus we could use the same uapi for timeline
> > > > syncobj using dma_fence as for hmm_fence, so also easier to transition
> > > > for userspace to the new world since don't need the new hw capability
> > > > to roll out the new uapi and protocols.
> > > > 
> > > > That's not that hard to roll out, and technically a lot better than
> > > > hacking up dma_resv and hoping we don't end up stalling in wrong
> > > > places, which sounds very "k" to me :-)
> > > Yeah, that's what I totally agree upon :)
> > > 
> > > My idea was just the last resort since we are mixing userspace sync and
> > > memory management so creative here.
> > > 
> > > Stalling in userspace will probably get some push back as well, but
> > > maybe not as much as stalling in the kernel.
> > I guess we need to have last-resort stalling in the kernel, but no
> > more than what we do with drm_syncobj future fences right now. Like
> > when anything asks for a dma_fence out of an hmm_fence drm_syncob, we
> > just stall until the hmm_fence is signalled, and then create a
> > dma_fence that's already signalled and return that to the caller.
> 
> Good idea. BTW: We should somehow teach lockdep that this materialization of
> any future fence should not happen while holding a reservation lock?

Good idea, should be easy to add (although the explanation why it works
needs a comment).

> > Obviously this shouldn't happen, since anyone who's timeline aware
> > will check whether the fence has at least materialized first and stall
> > somewhere more useful for that first.
> 
> Well if I'm not completely mistaken it should help with existing stuff like
> an implicit fence for atomic modeset etc...

Modeset is special:
- we fully pin buffers before we even start waiting. That means the loop
  can't close, since no one can try to evict our pinned buffer and would
  hence end up waiting on our hmm fence. We also only unpin the after
  everything is done.

- there's out-fences, but as long as we require that the in and out
  fences are of the same type that should be all fine. Also since the
  explicit in/out fence stuff is there already it shouldn't be too hard to
  add support for syncobj fences 

[Bug 211189] vgaarb overrides boot device unexpectedly with Intel and discrete AMDGPU

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your dmesg output.  I agree this looks like an sbios issue since
the the efifb is apparently bound to the radeon chip.

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

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 211189] New: vgaarb overrides boot device unexpectedly with Intel and discrete AMDGPU

[Bjorn Helgaas]

[cc'd efifb and vgaarb maintainers on bugzilla, but not sure whether
people pay attention to that]

On Thu, Jan 14, 2021 at 10:42:53AM +, bugzilla-dae...@bugzilla.kernel.org 
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=211189
> 
> Bug ID: 211189
>Summary: vgaarb overrides boot device unexpectedly with Intel
> and discrete AMDGPU
>Product: Drivers
>Version: 2.5
> Kernel Version: 5.10.7-200.fc33.x86_64
>   Hardware: x86-64
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: PCI
>   Assignee: drivers_...@kernel-bugs.osdl.org
>   Reporter: domi...@greysector.net
> Regression: No
> 
> The system is a MSI Z77A-GD65 mainboard configured to boot in UEFI mode.
> Despite setting integrated GPU (from i5-3570K CPU) as the default in firmware
> setup, the kernel sets the discrete GPU (Radeon HD 7950) as boot_vga. This
> results in wrong order in e.g. switcherooctl:
> $ switcherooctl list
> Device: 0
>   Name:Advanced Micro Devices, Inc. [AMD®/ATI] Tahiti PRO [Radeon HD
> 7950/8950 OEM / R9 280]
>   Default: yes
>   Environment: DRI_PRIME=pci-_01_00_0
> 
> Device: 1
>   Name:Intel® HD Graphics 4000
>   Default: no
>   Environment: DRI_PRIME=pci-_00_02_0
> $ lspci -vnn
> ...
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 
> v2/3rd
> Gen Core processor Graphics Controller [8086:0162] (rev 09) (prog-if 00 [VGA
> controller])
> DeviceName:  Onboard IGD
> Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:2111]
> Flags: bus master, fast devsel, latency 0, IRQ 31
> Memory at f780 (64-bit, non-prefetchable) [size=4M]
> Memory at d000 (64-bit, prefetchable) [size=256M]
> I/O ports at f000 [size=64]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Capabilities: [d0] Power Management version 2
> Capabilities: [a4] PCI Advanced Features
> Kernel driver in use: i915
> Kernel modules: i915
> ...
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] [1002:679a] (prog-if 
> 00
> [VGA controller])
> Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:2761]
> Flags: bus master, fast devsel, latency 0, IRQ 32
> Memory at e000 (64-bit, prefetchable) [size=256M]
> Memory at f7d0 (64-bit, non-prefetchable) [size=256K]
> I/O ports at e000 [size=256]
> Expansion ROM at 000c [disabled] [size=128K]
> Capabilities: [48] Vendor Specific Information: Len=08 
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Legacy Endpoint, MSI 00
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010
> 
> Capabilities: [150] Advanced Error Reporting
> Capabilities: [270] Secondary PCI Express
> Capabilities: [2b0] Address Translation Service (ATS)
> Capabilities: [2c0] Page Request Interface (PRI)
> Capabilities: [2d0] Process Address Space ID (PASID)
> Kernel driver in use: amdgpu
> Kernel modules: radeon, amdgpu
> 
> $ for f in /sys/bus/pci/devices/*/boot_vga ; do echo -n "$f:" ; cat $f ; done
> /sys/bus/pci/devices/:00:02.0/boot_vga:0
> /sys/bus/pci/devices/:01:00.0/boot_vga:1
> 
> $ dmesg
> ...
> [0.267216] pci :01:00.0: BAR 0: assigned to efifb

This is from drivers/video/fbdev/efifb.c and makes me wonder if this
is a firmware defect.  You set 00:02.0 to be the default in firmware
setup, but apparently the EFI FB is using 01:00.0?

> [0.268571] pci :00:02.0: vgaarb: setting as boot VGA device
> [0.268571] pci :00:02.0: vgaarb: VGA device added:
> decodes=io+mem,owns=io+mem,locks=none
> [0.268571] pci :01:00.0: vgaarb: VGA device added:
> decodes=io+mem,owns=io+mem,locks=none
> [0.268571] pci :00:02.0: vgaarb: no bridge control possible
> [0.268571] pci :01:00.0: vgaarb: bridge control possible
> [0.268571] pci :01:00.0: vgaarb: overriding boot device
> [0.268571] vgaarb: loaded
> [0.754748] efifb: probing for efifb
> [0.754766] efifb: No BGRT, not showing boot graphics
> [0.754768] efifb: framebuffer at 0xe000, using 8100k, total 8100k
> [0.754769] efifb: mode is 1920x1080x32, linelength=7680, pages=1
> [0.754770] efifb: scrolling: redraw
> [0.754772] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [2.984727] i915 :00:02.0: vgaarb: changed VGA decodes:
> olddecodes=io+mem,decodes=none:owns=io+mem
> [3.011601] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on minor
> 0
> [3.213870] [drm] 

[Bug 211189] vgaarb overrides boot device unexpectedly with Intel and discrete AMDGPU

[bugzilla-daemon]

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

Bjorn Helgaas (bj...@helgaas.com) changed:

   What|Removed |Added

 CC||airl...@linux.ie,
   ||bj...@helgaas.com,
   ||pjo...@redhat.com
  Component|PCI |Video(DRI - non Intel)
   Assignee|drivers_...@kernel-bugs.osd |drivers_video-dri@kernel-bu
   |l.org   |gs.osdl.org

--- Comment #1 from Bjorn Helgaas (bj...@helgaas.com) ---
Reassigning to video/DRI since I don't think this is a PCI problem.  If the
integrated GPU (00:02.0) is set to the default in firmware setup, this:

  pci :01:00.0: BAR 0: assigned to efifb

makes me wonder if this is a firmware issue.

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

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3, 01/15] dt-bindings: mediatek: add description for postmask

[Rob Herring]

On Mon, 11 Jan 2021 15:43:37 +0800, Yongqiang Niu wrote:
> add description for postmask
> postmask is used control round corner for display frame
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Christian König]

Am 14.01.21 um 17:36 schrieb Daniel Vetter:

On Thu, Jan 14, 2021 at 5:01 PM Christian König
 wrote:

Am 14.01.21 um 16:40 schrieb Daniel Vetter:

[SNIP]

So I think we have to somehow solve this in the kernel or we will go in
circles all the time.


So from that pov I think the kernel should at most deal with an
hmm_fence for cross-process communication and maybe some standard wait
primitives (for userspace to use, not for the kernel).

The only use case this would forbid is using page faults for legacy
implicit/explicit dma_fence synced workloads, and I think that's
perfectly ok to not allow. Especially since the motivation here for
all this is compute, and compute doesn't pass around dma_fences
anyway.

As Alex said we will rather soon see this for gfx as well and we most
likely will see combinations of old dma_fence based integrated graphics
with new dedicated GPUs.

So I don't think we can say we reduce the problem to compute and don't
support anything else.

I'm not against pagefaults for gfx, just in pushing the magic into the
kernel. I don't think that works, because it means we add stall points
where usespace, especially vk userspace, really doesn't want it. So
same way like timeline syncobj, we need to push the compat work into
userspace.

There's going to be a few stall points:
- fully new stack, we wait for the userspace fence in the atomic
commit path (which we can, if we're really careful, since we pin all
buffers upfront and so there's no risk)
- userspace fencing gpu in the client, compositor protocol can pass
around userspace fences, but the compositor still uses dma_fence for
itself. There's some stalling in the compositor, which it does already
anyway when it's collecting new frames from clients
- userspace fencing gpu in the client, but no compositor protocol: We
wait in the swapchain, but in a separate thread so that nothing blocks
that shouldn't block

If we instead go with "magic waits in the kernel behind userspace's
back", like what your item 6 would imply, then we're not really
solving anything.

For actual implementation I think the best would be an extension of
drm_syncobj. Those already have at least conceptually future/infinite
fences, and we already have fd passing, so "just" need some protocol
to pass them around. Plus we could use the same uapi for timeline
syncobj using dma_fence as for hmm_fence, so also easier to transition
for userspace to the new world since don't need the new hw capability
to roll out the new uapi and protocols.

That's not that hard to roll out, and technically a lot better than
hacking up dma_resv and hoping we don't end up stalling in wrong
places, which sounds very "k" to me :-)

Yeah, that's what I totally agree upon :)

My idea was just the last resort since we are mixing userspace sync and
memory management so creative here.

Stalling in userspace will probably get some push back as well, but
maybe not as much as stalling in the kernel.

I guess we need to have last-resort stalling in the kernel, but no
more than what we do with drm_syncobj future fences right now. Like
when anything asks for a dma_fence out of an hmm_fence drm_syncob, we
just stall until the hmm_fence is signalled, and then create a
dma_fence that's already signalled and return that to the caller.


Good idea. BTW: We should somehow teach lockdep that this 
materialization of any future fence should not happen while holding a 
reservation lock?



Obviously this shouldn't happen, since anyone who's timeline aware
will check whether the fence has at least materialized first and stall
somewhere more useful for that first.


Well if I'm not completely mistaken it should help with existing stuff 
like an implicit fence for atomic modeset etc...



Ok if we can at least remove implicit sync from the picture then the
question remains how do we integrate HMM into drm_syncobj then?

 From an uapi pov probably just an ioctl to create an hmm drm_syncobj,
and a syncobj ioctl to query whether it's a hmm_fence or dma_fence
syncobj, so that userspace can be a bit more clever with where it
should stall - for an hmm_fence the stall will most likely be directly
on the gpu in many cases (so the ioctl should also give us all the
details about that if it's an hmm fence).

I think the real work is going through all the hardware and trying to
figure out what the common ground for userspace fences are. Stuff like
can they be in system memory, or need something special (wc maybe, but
I hope system memory should be fine for everyone), and how you count,
wrap and compare. I also have no idea how/if we can optimized cpu
waits across different drivers.


I think that this is absolutely hardware dependent. E.g. for example AMD 
will probably have handles, so that the hardware scheduler can counter 
problems like priority inversion.


What we should probably do is to handle this similar to how DMA-buf is 
handled - if it's the same driver and device the drm_syncobj we can use 
the same handle for 

Re: [PATCH v6 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

[Lyude Paul]

On Thu, 2021-01-14 at 09:12 +0200, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Lyude Paul  wrote:
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a single set of platform-specific hooks that are
> > used for controlling it.
> > 
> > HDR backlights, in particular VESA and Intel's HDR backlight
> > implementations, can end up being more complicated. With Intel's
> > proprietary interface, HDR backlight controls always run through the
> > DPCD. When the backlight is in SDR backlight mode however, the driver
> > may need to bypass the TCON and control the backlight directly through
> > PWM.
> > 
> > So, in order to support this we'll need to split our backlight callbacks
> > into two groups: a set of high-level backlight control callbacks in
> > intel_panel, and an additional set of pwm-specific backlight control
> > callbacks. This also implies a functional changes for how these
> > callbacks are used:
> > 
> > * We now keep track of two separate backlight level ranges, one for the
> >   high-level backlight, and one for the pwm backlight range
> > * We also keep track of backlight enablement and PWM backlight
> >   enablement separately
> > * Since the currently set backlight level might not be the same as the
> >   currently programmed PWM backlight level, we stop setting
> >   panel->backlight.level with the currently programmed PWM backlight
> >   level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> >   on the higher level backlight control functions to retrieve the
> >   current PWM backlight level (in this case, intel_pwm_get_backlight()).
> >   Note that there are still a few PWM backlight setup callbacks that
> >   do actually need to retrieve the current PWM backlight level, although
> >   we no longer save this value in panel->backlight.level like before.
> > 
> > Additionally, we drop the call to lpt_get_backlight() in
> > lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> > we get from it and only write it back if we're in CPU mode, and switching
> > to PCH mode. The reason for this is because in the original codepath for
> > this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> > responsible for fetching the initial backlight level. On lpt systems, the
> > only time we could ever be in PCH backlight mode is during the initial
> > driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> > will always be the callback used for retrieving the current backlight
> > level. After this patch we still need to fetch and write-back the PCH
> > backlight value if we're switching from CPU mode to PCH, but because
> > intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> > using the get() hook, which always ends up being lpt_get_backlight(). Thus
> > - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> > made redundant.
> > 
> > v7:
> > * Use panel->backlight.pwm_funcs->get() to get the backlight level in
> >   intel_pwm_setup_backlight(), lest we upset lockdep
> 
> I think this change is wrong, as it now bypasses
> intel_panel_invert_pwm_level(). Please explain. I don't see anything in
> there that could trigger a lockdep warning.

yeah-this was definitely me misunderstanding what the issue we were hitting here
was.

> 
> Perhaps it's the below you're referring to, but I think the root cause
> is different?
> 
> > @@ -1788,22 +1780,17 @@ static int vlv_setup_backlight(struct
> > intel_connector *connector, enum pipe pipe
> > panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> >  
> > ctl = intel_de_read(dev_priv, VLV_BLC_PWM_CTL(pipe));
> > -   panel->backlight.max = ctl >> 16;
> > +   panel->backlight.pwm_level_max = ctl >> 16;
> >  
> > -   if (!panel->backlight.max)
> > -   panel->backlight.max = get_backlight_max_vbt(connector);
> > +   if (!panel->backlight.pwm_level_max)
> > +   panel->backlight.pwm_level_max =
> > get_backlight_max_vbt(connector);
> >  
> > -   if (!panel->backlight.max)
> > +   if (!panel->backlight.pwm_level_max)
> > return -ENODEV;
> >  
> > -   panel->backlight.min = get_backlight_min_vbt(connector);
> > +   panel->backlight.pwm_level_min = get_backlight_min_vbt(connector);
> >  
> > -   val = _vlv_get_backlight(dev_priv, pipe);
> 
> Turns out this is a meaningful change, as the higher level
> vlv_get_backlight() function that will be called instead hits:
> 
> <4>[   12.870202] i915 :00:02.0: drm_WARN_ON(!drm_modeset_is_locked(
> >mode_config.connection_mutex))
> 
> in intel_connector_get_pipe(connector).
> 
> It's a real problem. See this, it's obvious (in retrospect):
> 
>  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19348/fi-bsw-kefka/igt@run...@aborted.html
>  
> 

Re: [PATCH] drm/amd/display: Simplify bool comparison

[Alex Deucher]

On Wed, Jan 13, 2021 at 8:51 AM Yang Li  wrote:
>
> Fix the following coccicheck warning:
> ./drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c:3141:30-39:
> WARNING: Comparison to bool
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 

Applied all 4 patches.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c 
> b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
> index 45f0289..f33e3de 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
> @@ -3138,7 +3138,7 @@ static void CalculateFlipSchedule(
> 4.0 * (TimeForFetchingMetaPTEImmediateFlip / 
> LineTime + 0.125),
> 1) / 4.0;
>
> -   if ((GPUVMEnable == true || DCCEnable == true)) {
> +   if ((GPUVMEnable || DCCEnable)) {
> mode_lib->vba.ImmediateFlipBW[0] = 
> BandwidthAvailableForImmediateFlip
> * ImmediateFlipBytes / 
> TotImmediateFlipBytes;
> TimeForFetchingRowInVBlankImmediateFlip = dml_max(
> --
> 1.8.3.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Repeat assignment to max_slave_planes

[Alex Deucher]

On Thu, Jan 14, 2021 at 4:29 AM ZhiJie.Zhang  wrote:
>
> Signed-off-by: ZhiJie.Zhang 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> index 3f63822b8e28..9a86d43a6233 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> @@ -1272,7 +1272,6 @@ static bool underlay_create(struct dc_context *ctx, 
> struct resource_pool *pool)
>
> /* update the public caps to indicate an underlay is available */
> ctx->dc->caps.max_slave_planes = 1;
> -   ctx->dc->caps.max_slave_planes = 1;
>
> return true;
>  }
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/10] drm: amd: amdgpu_dm.h: fix a wrong kernel-doc markup

[Alex Deucher]

On Thu, Jan 14, 2021 at 2:53 AM Mauro Carvalho Chehab
 wrote:
>
> There's a missing colon, causing the markup to be ignored,
> solving those warnings:
>
> ../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:340: warning: 
> Incorrect use of kernel-doc format:  * @active_vblank_irq_count
> ../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:379: warning: 
> Function parameter or member 'active_vblank_irq_count' not described in 
> 'amdgpu_display_manager'
>
> Signed-off-by: Mauro Carvalho Chehab 

Thanks, actually applied the same patch from Lukas Bulwahn a couple of days ago.

Alex

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index f084e2fc9569..5ee1b766884e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -337,7 +337,7 @@ struct amdgpu_display_manager {
> const struct gpu_info_soc_bounding_box_v1_0 *soc_bounding_box;
>
> /**
> -* @active_vblank_irq_count
> +* @active_vblank_irq_count:
>  *
>  * number of currently active vblank irqs
>  */
> --
> 2.29.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 22/30] drm/amd/display/dc/core/dc_link: Fix a couple of function documentation issues

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:214: warning: 
> Function parameter or member 'link' not described in 'dc_link_detect_sink'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:350: warning: 
> Function parameter or member 'link' not described in 
> 'dc_link_is_dp_sink_present'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:841: warning: 
> Function parameter or member 'link' not described in 'dc_link_detect_helper'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:841: warning: 
> Function parameter or member 'reason' not described in 'dc_link_detect_helper'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:3403: warning: 
> Cannot understand  
> *
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 3366a49f11dc7..271c4f66edb56 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -206,6 +206,7 @@ static bool program_hpd_filter(const struct dc_link *link)
>  /**
>   * dc_link_detect_sink() - Determine if there is a sink connected
>   *
> + * @link: pointer to the dc link
>   * @type: Returned connection type
>   * Does not detect downstream devices, such as MST sinks
>   * or display connected through active dongles
> @@ -342,7 +343,7 @@ static enum signal_type get_basic_signal_type(struct 
> graphics_object_id encoder,
> return SIGNAL_TYPE_NONE;
>  }
>
> -/**
> +/*
>   * dc_link_is_dp_sink_present() - Check if there is a native DP
>   * or passive DP-HDMI dongle connected
>   */
> @@ -828,7 +829,7 @@ static bool wait_for_entering_dp_alt_mode(struct dc_link 
> *link)
> return false;
>  }
>
> -/**
> +/*
>   * dc_link_detect() - Detect if a sink is attached to a given link
>   *
>   * link->local_sink is created or destroyed as needed.
> @@ -3400,10 +3401,7 @@ void core_link_set_avmute(struct pipe_ctx *pipe_ctx, 
> bool enable)
>  }
>
>  /**
> - 
> *
> - *  Function: dc_link_enable_hpd_filter
> - *
> - *  @brief
> + *  dc_link_enable_hpd_filter:
>   * If enable is true, programs HPD filter on associated HPD line using
>   * delay_on_disconnect/delay_on_connect values dependent on
>   * link->connector_signal
> @@ -3411,9 +3409,8 @@ void core_link_set_avmute(struct pipe_ctx *pipe_ctx, 
> bool enable)
>   * If enable is false, programs HPD filter on associated HPD line with no
>   * delays on connect or disconnect
>   *
> - *  @param [in] link: pointer to the dc link
> - *  @param [in] enable: boolean specifying whether to enable hbd
> - 
> *
> + *  @link:   pointer to the dc link
> + *  @enable: boolean specifying whether to enable hbd
>   */
>  void dc_link_enable_hpd_filter(struct dc_link *link, bool enable)
>  {
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 21/30] drm/amd/display/dc/core/dc_resource: Demote some kernel-doc abuses

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1710: warning: 
> Function parameter or member 'old_stream' not described in 
> 'dc_is_stream_unchanged'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1710: warning: 
> Function parameter or member 'stream' not described in 
> 'dc_is_stream_unchanged'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1726: warning: 
> Function parameter or member 'old_stream' not described in 
> 'dc_is_stream_scaling_unchanged'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1726: warning: 
> Function parameter or member 'stream' not described in 
> 'dc_is_stream_scaling_unchanged'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1843: warning: 
> Function parameter or member 'dc' not described in 'dc_add_stream_to_ctx'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1843: warning: 
> Function parameter or member 'new_ctx' not described in 'dc_add_stream_to_ctx'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1843: warning: 
> Function parameter or member 'stream' not described in 'dc_add_stream_to_ctx'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1870: warning: 
> Function parameter or member 'dc' not described in 'dc_remove_stream_from_ctx'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1870: warning: 
> Function parameter or member 'new_ctx' not described in 
> 'dc_remove_stream_from_ctx'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1870: warning: 
> Function parameter or member 'stream' not described in 
> 'dc_remove_stream_from_ctx'
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> index d423092c45dcd..185412d0c1429 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> @@ -1697,7 +1697,7 @@ static bool are_stream_backends_same(
> return true;
>  }
>
> -/**
> +/*
>   * dc_is_stream_unchanged() - Compare two stream states for equivalence.
>   *
>   * Checks if there a difference between the two states
> @@ -1718,7 +1718,7 @@ bool dc_is_stream_unchanged(
> return true;
>  }
>
> -/**
> +/*
>   * dc_is_stream_scaling_unchanged() - Compare scaling rectangles of two 
> streams.
>   */
>  bool dc_is_stream_scaling_unchanged(
> @@ -1833,7 +1833,7 @@ static struct audio *find_first_free_audio(
> return 0;
>  }
>
> -/**
> +/*
>   * dc_add_stream_to_ctx() - Add a new dc_stream_state to a dc_state.
>   */
>  enum dc_status dc_add_stream_to_ctx(
> @@ -1860,7 +1860,7 @@ enum dc_status dc_add_stream_to_ctx(
> return res;
>  }
>
> -/**
> +/*
>   * dc_remove_stream_from_ctx() - Remove a stream from a dc_state.
>   */
>  enum dc_status dc_remove_stream_from_ctx(
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 20/30] drm/amd/display/dc/core/dc: Fix a bunch of documentation misdemeanours

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:287: warning: Cannot 
> understand  
> *
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:366: warning: Function 
> parameter or member 'crc_window' not described in 'dc_stream_configure_crc'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:430: warning: Function 
> parameter or member 'r_cr' not described in 'dc_stream_get_crc'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:430: warning: Function 
> parameter or member 'g_y' not described in 'dc_stream_get_crc'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:430: warning: Function 
> parameter or member 'b_cb' not described in 'dc_stream_get_crc'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2026: warning: Function 
> parameter or member 'dc' not described in 
> 'dc_check_update_surfaces_for_stream'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2026: warning: Function 
> parameter or member 'updates' not described in 
> 'dc_check_update_surfaces_for_stream'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2026: warning: Function 
> parameter or member 'surface_count' not described in 
> 'dc_check_update_surfaces_for_stream'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2026: warning: Function 
> parameter or member 'stream_update' not described in 
> 'dc_check_update_surfaces_for_stream'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2026: warning: Function 
> parameter or member 'stream_status' not described in 
> 'dc_check_update_surfaces_for_stream'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2822: warning: Function 
> parameter or member 'dc' not described in 'dc_interrupt_set'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2822: warning: Function 
> parameter or member 'src' not described in 'dc_interrupt_set'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2822: warning: Function 
> parameter or member 'enable' not described in 'dc_interrupt_set'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2962: warning: Function 
> parameter or member 'link' not described in 'dc_link_add_remote_sink'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2962: warning: Function 
> parameter or member 'edid' not described in 'dc_link_add_remote_sink'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2962: warning: Function 
> parameter or member 'len' not described in 'dc_link_add_remote_sink'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2962: warning: Function 
> parameter or member 'init_data' not described in 'dc_link_add_remote_sink'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3022: warning: Function 
> parameter or member 'link' not described in 'dc_link_remove_remote_sink'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3022: warning: Function 
> parameter or member 'sink' not described in 'dc_link_remove_remote_sink'
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 33 
>  1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 0a07e608485ff..3ee3978fae977 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -284,20 +284,16 @@ static void dc_perf_trace_destroy(struct dc_perf_trace 
> **perf_trace)
>  }
>
>  /**
> - 
> *
> - *  Function: dc_stream_adjust_vmin_vmax
> + *  dc_stream_adjust_vmin_vmax:
>   *
> - *  @brief
> - * Looks up the pipe context of dc_stream_state and updates the
> - * vertical_total_min and vertical_total_max of the DRR, Dynamic Refresh
> - * Rate, which is a power-saving feature that targets reducing panel
> - * refresh rate while the screen is static
> + *  Looks up the pipe context of dc_stream_state and updates the
> + *  vertical_total_min and vertical_total_max of the DRR, Dynamic Refresh
> + *  Rate, which is a power-saving feature that targets reducing panel
> + *  refresh rate while the screen is static
>   *
> - *  @param [in] dc: dc reference
> - *  @param [in] stream: Initial dc stream state
> - *  @param [in] adjust: Updated parameters for vertical_total_min and
> - *  vertical_total_max
> - 
> *
> + *  @dc: dc reference
> + *  @stream: Initial dc stream state
> + *  @adjust: Updated parameters for vertical_total_min and vertical_total_max
>   */
>  bool 

Re: [PATCH 19/30] drm/amd/display/dc/core/dc_link_dp: Mark 'result_write_min_hblank' as __maybe_unused

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> It looks like it could be used inside the DC_TRACE_LEVEL_MESSAGE() macro.
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function 
> ‘dpcd_set_source_specific_data’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4403:18: warning: 
> variable ‘result_write_min_hblank’ set but not used 
> [-Wunused-but-set-variable]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 3c33b8fe218e5..b9e5e0eee3d24 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -4400,7 +4400,7 @@ void dp_set_fec_enable(struct dc_link *link, bool 
> enable)
>  void dpcd_set_source_specific_data(struct dc_link *link)
>  {
> if (!link->dc->vendor_signature.is_valid) {
> -   enum dc_status result_write_min_hblank = DC_NOT_SUPPORTED;
> +   enum dc_status __maybe_unused result_write_min_hblank = 
> DC_NOT_SUPPORTED;
> struct dpcd_amd_signature amd_signature;
> amd_signature.AMD_IEEE_TxSignature_byte1 = 0x0;
> amd_signature.AMD_IEEE_TxSignature_byte2 = 0x0;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/cma-helper: Implement mmap as GEM CMA object functions

[Daniel Vetter]

On Thu, Jan 14, 2021 at 02:26:41PM +0100, Thomas Zimmermann wrote:
> From d0583fe22cd0cd29749ff679e46e13b58de325cb Mon Sep 17 00:00:00 2001
> From: Thomas Zimmermann 
> Date: Thu, 14 Jan 2021 14:21:51 +0100
> Subject: [PATCH] drm/cma: Set vma ops in mmap function
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 7942cf05cd93..0bd192736169 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -489,6 +489,8 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct 
> vm_area_struct *vma)
>   struct drm_gem_cma_object *cma_obj;
>   int ret;
>  
> + vma->vm_ops = obj->funcs->vm_ops;

I think this should be done in core, otherwise we have tons of refcount
leaks. I think this was an oversight when we've done that refactoring.

Also drivers can easily overwrite this one if they really have to, but not
assigned this is a clear bug.
-Daniel

> +
>   /*
>* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
>* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
> -- 
> 2.29.2
> 


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 18/30] drm/amd/display/dc/core/dc_link: Move some local data from the stack to the heap

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function 
> ‘dc_link_construct’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1588:1: warning: the 
> frame size of 1176 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 8ccda8b9ac2eb..3366a49f11dc7 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -1364,13 +1364,17 @@ static bool dc_link_construct(struct dc_link *link,
> struct dc_context *dc_ctx = init_params->ctx;
> struct encoder_init_data enc_init_data = { 0 };
> struct panel_cntl_init_data panel_cntl_init_data = { 0 };
> -   struct integrated_info info = {{{ 0 }}};
> +   struct integrated_info *info;
> struct dc_bios *bios = init_params->dc->ctx->dc_bios;
> const struct dc_vbios_funcs *bp_funcs = bios->funcs;
> struct bp_disp_connector_caps_info disp_connect_caps_info = { 0 };
>
> DC_LOGGER_INIT(dc_ctx->logger);
>
> +   info = kzalloc(sizeof(info), GFP_KERNEL);
> +   if (!info)
> +   goto create_fail;
> +
> link->irq_source_hpd = DC_IRQ_SOURCE_INVALID;
> link->irq_source_hpd_rx = DC_IRQ_SOURCE_INVALID;
>
> @@ -1532,12 +1536,12 @@ static bool dc_link_construct(struct dc_link *link,
> }
>
> if (bios->integrated_info)
> -   info = *bios->integrated_info;
> +   memcpy(info, bios->integrated_info, sizeof(*info));
>
> /* Look for channel mapping corresponding to connector and device tag 
> */
> for (i = 0; i < MAX_NUMBER_OF_EXT_DISPLAY_PATH; i++) {
> struct external_display_path *path =
> -   _disp_conn_info.path[i];
> +   >ext_disp_conn_info.path[i];
>
> if (path->device_connector_id.enum_id == 
> link->link_id.enum_id &&
> path->device_connector_id.id == link->link_id.id &&
> @@ -1584,6 +1588,8 @@ static bool dc_link_construct(struct dc_link *link,
> link->hpd_gpio = NULL;
> }
>
> +   kfree(info);
> +
> return false;
>  }
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/30] drm/amd/display/dc/dce60/dce60_resource: Include our own header containing prototypes

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:1115:23: 
> warning: no previous prototype for ‘dce60_create_resource_pool’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:1312:23: 
> warning: no previous prototype for ‘dce61_create_resource_pool’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:1505:23: 
> warning: no previous prototype for ‘dce64_create_resource_pool’ 
> [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Mauro Rossi 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c
> index 64f4a0da146bf..dcfa0a3efa00d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c
> @@ -60,6 +60,8 @@
>  #include "dce/dce_i2c.h"
>  /* TODO remove this include */
>
> +#include "dce60_resource.h"
> +
>  #ifndef mmMC_HUB_RDREQ_DMIF_LIMIT
>  #include "gmc/gmc_6_0_d.h"
>  #include "gmc/gmc_6_0_sh_mask.h"
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/30] drm/amd/display/dc/dce80/dce80_resource: Include our own header containing prototypes

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:1126:23: 
> warning: no previous prototype for ‘dce80_create_resource_pool’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:1325:23: 
> warning: no previous prototype for ‘dce81_create_resource_pool’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:1520:23: 
> warning: no previous prototype for ‘dce83_create_resource_pool’ 
> [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Anthony Koo 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> index fe5d716084363..725d92e40cd30 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> @@ -60,6 +60,8 @@
>  #include "dce/dce_i2c.h"
>  /* TODO remove this include */
>
> +#include "dce80_resource.h"
> +
>  #ifndef mmMC_HUB_RDREQ_DMIF_LIMIT
>  #include "gmc/gmc_7_1_d.h"
>  #include "gmc/gmc_7_1_sh_mask.h"
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/30] drm/amd/display/dc/dce80/Makefile: Ignore -Woverride-init warning

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  In file included from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:29:
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_8_0_sh_mask.h:9546:58: 
> warning: initialized field overwritten [-Woverride-init]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:213:16: note: in 
> expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:102:2: note: in 
> expansion of macro ‘AUX_SF’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:305:2: note: 
> in expansion of macro ‘DCE10_AUX_MASK_SH_LIST’
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_8_0_sh_mask.h:9546:58: 
> note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’)
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:213:16: note: in 
> expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:102:2: note: in 
> expansion of macro ‘AUX_SF’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:305:2: note: 
> in expansion of macro ‘DCE10_AUX_MASK_SH_LIST’
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_8_0_sh_mask.h:9545:56: 
> warning: initialized field overwritten [-Woverride-init]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:213:16: note: in 
> expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:102:2: note: in 
> expansion of macro ‘AUX_SF’
>
> NB: Snipped lots for the sake of brevity
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce80/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce80/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dce80/Makefile
> index 666fcb2bdbba0..0a9d1a350d8bd 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce80/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dce80/Makefile
> @@ -23,6 +23,8 @@
>  # Makefile for the 'controller' sub-component of DAL.
>  # It provides the control and status of HW CRTC block.
>
> +CFLAGS_$(AMDDALPATH)/dc/dce80/dce80_resource.o = $(call cc-disable-warning, 
> override-init)
> +
>  DCE80 = dce80_timing_generator.o dce80_hw_sequencer.o \
> dce80_resource.o
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/30] drm/amd/display/dc/dce60/Makefile: Ignore -Woverride-init warning

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  In file included from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:28:
>  drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:568:43: 
> warning: initialized field overwritten [-Woverride-init]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:155:14: 
> note: in expansion of macro ‘mmCRTC0_DCFE_MEM_LIGHT_SLEEP_CNTL’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:2: note: in 
> expansion of macro ‘SRI’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:181:3: note: 
> in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:185:3: note: 
> in expansion of macro ‘transform_regs’
>  drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:568:43: note: 
> (near initialization for ‘xfm_regs[0].DCFE_MEM_LIGHT_SLEEP_CNTL’)
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:155:14: 
> note: in expansion of macro ‘mmCRTC0_DCFE_MEM_LIGHT_SLEEP_CNTL’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:2: note: in 
> expansion of macro ‘SRI’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:181:3: note: 
> in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:185:3: note: 
> in expansion of macro ‘transform_regs’
>  drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:645:43: 
> warning: initialized field overwritten [-Woverride-init]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:155:14: 
> note: in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:2: note: in 
> expansion of macro ‘SRI’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:181:3: note: 
> in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’
>
>  NB: Snipped lots for the sake of brevity
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Mauro Rossi 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> index 7036c3bd0f871..dda596fa1cd76 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> @@ -23,6 +23,8 @@
>  # Makefile for the 'controller' sub-component of DAL.
>  # It provides the control and status of HW CRTC block.
>
> +CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, 
> override-init)
> +
>  DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \
> dce60_resource.o
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/30] drm/amd/display/dc/dce100/dce100_resource: Include our own header containing prototypes

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  In file included from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:54:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:537:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:537:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:542:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:542:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:547:2: 
> note: in expansion of macro ‘DCE10_AUX_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:547:2: 
> note: in expansion of macro ‘DCE10_AUX_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:551:2: 
> note: in expansion of macro ‘DCE10_AUX_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:551:2: 
> note: in expansion of macro ‘DCE10_AUX_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:889:16: 
> warning: no previous prototype for ‘dce100_add_stream_to_ctx’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:916:16: 
> warning: no previous prototype for ‘dce100_validate_plane’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:925:24: 
> warning: no previous prototype for 
> ‘dce100_find_first_free_match_stream_enc_for_link’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:1156:23: 
> warning: no previous prototype for ‘dce100_create_resource_pool’ 
> [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Anthony Koo 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> index 648169086bcf8..635ef0e7c7826 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> @@ -58,6 +58,8 @@
>  #include "dce/dce_abm.h"
>  #include "dce/dce_i2c.h"
>
> +#include "dce100_resource.h"
> +
>  #ifndef mmMC_HUB_RDREQ_DMIF_LIMIT
>  #include "gmc/gmc_8_2_d.h"
>  #include "gmc/gmc_8_2_sh_mask.h"
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/30] drm/amd/display/dc/dce100/Makefile: Ignore -Woverride-init warning

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  In file included from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:54:
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_10_0_sh_mask.h:5084:45:
>  warning: initialized field overwritten [-Woverride-init]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:155:28: note: 
> in expansion of macro ‘GRPH_CONTROL__GRPH_NUM_BANKS__SHIFT’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:170:2: note: in 
> expansion of macro ‘SFB’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:291:2: note: in 
> expansion of macro ‘MI_GFX8_TILE_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:537:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_10_0_sh_mask.h:5084:45:
>  note: (near initialization for ‘mi_shifts.GRPH_NUM_BANKS’)
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:155:28: note: 
> in expansion of macro ‘GRPH_CONTROL__GRPH_NUM_BANKS__SHIFT’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:170:2: note: in 
> expansion of macro ‘SFB’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:291:2: note: in 
> expansion of macro ‘MI_GFX8_TILE_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:537:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_10_0_sh_mask.h:5083:43:
>  warning: initialized field overwritten [-Woverride-init]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:155:28: note: 
> in expansion of macro ‘GRPH_CONTROL__GRPH_NUM_BANKS_MASK’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:170:2: note: in 
> expansion of macro ‘SFB’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:291:2: note: in 
> expansion of macro ‘MI_GFX8_TILE_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:542:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>  
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_10_0_sh_mask.h:5083:43:
>  note: (near initialization for ‘mi_masks.GRPH_NUM_BANKS’)
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:155:28: note: 
> in expansion of macro ‘GRPH_CONTROL__GRPH_NUM_BANKS_MASK’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:170:2: note: in 
> expansion of macro ‘SFB’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_mem_input.h:291:2: note: in 
> expansion of macro ‘MI_GFX8_TILE_MASK_SH_LIST’
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:542:3: 
> note: in expansion of macro ‘MI_DCE8_MASK_SH_LIST’
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce100/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce100/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dce100/Makefile
> index a822d4e2a1693..ff20c47f559e3 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce100/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dce100/Makefile
> @@ -23,6 +23,8 @@
>  # Makefile for the 'controller' sub-component of DAL.
>  # It provides the control and status of HW CRTC block.
>
> +CFLAGS_$(AMDDALPATH)/dc/dce100/dce100_resource.o = $(call 
> cc-disable-warning, override-init)
> +
>  DCE100 = dce100_resource.o dce100_hw_sequencer.o
>
>  AMD_DAL_DCE100 = $(addprefix $(AMDDALPATH)/dc/dce100/,$(DCE100))
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/30] drm/amd/display/dc/core/dc: Staticise local function 'apply_ctx_interdependent_lock'

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:806:6: warning: no 
> previous prototype for ‘apply_ctx_interdependent_lock’ [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 8f1cadb823c71..0a07e608485ff 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -803,7 +803,8 @@ static void disable_all_writeback_pipes_for_stream(
> stream->writeback_info[i].wb_enabled = false;
>  }
>
> -void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state *context, 
> struct dc_stream_state *stream, bool lock)
> +static void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state 
> *context,
> + struct dc_stream_state *stream, 
> bool lock)
>  {
> int i = 0;
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/30] drm/amd/display/dc/dce112/dce112_resource: Include our own header file containing prototypes

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:883:6: 
> warning: no previous prototype for ‘dce112_validate_bandwidth’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:1008:16: 
> warning: no previous prototype for ‘dce112_add_stream_to_ctx’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:1407:23: 
> warning: no previous prototype for ‘dce112_create_resource_pool’ 
> [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Anthony Koo 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> index c68e576a21990..ee55cda854bf4 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> @@ -59,7 +59,9 @@
>  #include "dce/dce_11_2_sh_mask.h"
>
>  #include "dce100/dce100_resource.h"
> -#define DC_LOGGER \
> +#include "dce112_resource.h"
> +
> +#define DC_LOGGER  \
> dc->ctx->logger
>
>  #ifndef mmDP_DPHY_INTERNAL_CTRL
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/30] drm/amd/display/dc/core/dc_link_dp: Staticify local function 'linkRateInKHzToLinkRateMultiplier'

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3710:19: warning: 
> no previous prototype for ‘linkRateInKHzToLinkRateMultiplier’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function 
> ‘dpcd_set_source_specific_data’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4403:18: warning: 
> variable ‘result_write_min_hblank’ set but not used 
> [-Wunused-but-set-variable]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 2fc12239b22cb..3c33b8fe218e5 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -3707,7 +3707,7 @@ bool detect_dp_sink_caps(struct dc_link *link)
> /* TODO save sink caps in link->sink */
>  }
>
> -enum dc_link_rate linkRateInKHzToLinkRateMultiplier(uint32_t 
> link_rate_in_khz)
> +static enum dc_link_rate linkRateInKHzToLinkRateMultiplier(uint32_t 
> link_rate_in_khz)
>  {
> enum dc_link_rate link_rate;
> // LinkRate is normally stored as a multiplier of 0.27 Gbps per lane. 
> Do the translation.
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/30] drm/amd/display/dc/core/dc_link: Remove unused variable 'status'

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function 
> ‘query_hdcp_capability’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:599:28: warning: 
> variable ‘status’ set but not used [-Wunused-but-set-variable]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index f4a2088ab1792..8ccda8b9ac2eb 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -596,8 +596,6 @@ static void query_hdcp_capability(enum signal_type 
> signal, struct dc_link *link)
> dc_process_hdcp_msg(signal, link, );
>
> if (signal == SIGNAL_TYPE_DISPLAY_PORT || signal == 
> SIGNAL_TYPE_DISPLAY_PORT_MST) {
> -   enum hdcp_message_status status = HDCP_MESSAGE_UNSUPPORTED;
> -
> msg14.data = >hdcp_caps.bcaps.raw;
> msg14.length = sizeof(link->hdcp_caps.bcaps.raw);
> msg14.msg_id = HDCP_MESSAGE_ID_READ_BCAPS;
> @@ -605,7 +603,7 @@ static void query_hdcp_capability(enum signal_type 
> signal, struct dc_link *link)
> msg14.link = HDCP_LINK_PRIMARY;
> msg14.max_retries = 5;
>
> -   status = dc_process_hdcp_msg(signal, link, );
> +   dc_process_hdcp_msg(signal, link, );
> }
>
>  }
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/30] drm/amd/display/dc/core/dc_resource: Staticify local functions

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1120:5: warning: 
> no previous prototype for ‘shift_border_left_to_dst’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1131:6: warning: 
> no previous prototype for ‘restore_border_left_from_dst’ 
> [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> index 07c22556480be..d423092c45dcd 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> @@ -1117,7 +1117,7 @@ static void calculate_inits_and_adj_vp(struct pipe_ctx 
> *pipe_ctx)
>   * We also need to make sure pipe_ctx->plane_res.scl_data.h_active uses the
>   * original h_border_left value in its calculation.
>   */
> -int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
> +static int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
>  {
> int store_h_border_left = pipe_ctx->stream->timing.h_border_left;
>
> @@ -1128,8 +1128,8 @@ int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
> return store_h_border_left;
>  }
>
> -void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
> -  int store_h_border_left)
> +static void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
> +int store_h_border_left)
>  {
> pipe_ctx->stream->dst.x -= store_h_border_left;
> pipe_ctx->stream->timing.h_border_left = store_h_border_left;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/30] drm/amd/display/modules/info_packet/info_packet: Correct kernel-doc formatting

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/modules/info_packet/info_packet.c:412: 
> warning: Cannot understand  
> *
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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 

Applied.  Thanks!

Alex

> ---
>  .../amd/display/modules/info_packet/info_packet.c   | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c 
> b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> index 0fdf7a3e96dea..57f198de5e2cb 100644
> --- a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> +++ b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> @@ -409,16 +409,11 @@ void mod_build_vsc_infopacket(const struct 
> dc_stream_state *stream,
>  }
>
>  /**
> - 
> *
> - *  Function: mod_build_hf_vsif_infopacket
> + *  mod_build_hf_vsif_infopacket - Prepare HDMI Vendor Specific info frame.
> + * Follows HDMI Spec to build up Vendor 
> Specific info frame
>   *
> - *  @brief
> - * Prepare HDMI Vendor Specific info frame.
> - * Follows HDMI Spec to build up Vendor Specific info frame
> - *
> - *  @param [in] stream: contains data we may need to construct VSIF (i.e. 
> timing_3d_format, etc.)
> - *  @param [out] info_packet:   output structure where to store VSIF
> - 
> *
> + *  @stream:  contains data we may need to construct VSIF (i.e. 
> timing_3d_format, etc.)
> + *  @info_packet: output structure where to store VSIF
>   */
>  void mod_build_hf_vsif_infopacket(const struct dc_stream_state *stream,
> struct dc_info_packet *info_packet)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/30] drm/amd/display/modules/power/power_helpers: Staticify local functions

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:281:6: 
> warning: no previous prototype for ‘fill_iram_v_2’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:455:6: 
> warning: no previous prototype for ‘fill_iram_v_2_2’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:601:6: 
> warning: no previous prototype for ‘fill_iram_v_2_3’ [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
> b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> index 4fd8bce95d843..3d4c66933f518 100644
> --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> @@ -278,7 +278,7 @@ static void fill_backlight_transform_table_v_2_2(struct 
> dmcu_iram_parameters par
> }
>  }
>
> -void fill_iram_v_2(struct iram_table_v_2 *ram_table, struct 
> dmcu_iram_parameters params)
> +static void fill_iram_v_2(struct iram_table_v_2 *ram_table, struct 
> dmcu_iram_parameters params)
>  {
> unsigned int set = params.set;
>
> @@ -452,7 +452,7 @@ void fill_iram_v_2(struct iram_table_v_2 *ram_table, 
> struct dmcu_iram_parameters
> params, ram_table);
>  }
>
> -void fill_iram_v_2_2(struct iram_table_v_2_2 *ram_table, struct 
> dmcu_iram_parameters params)
> +static void fill_iram_v_2_2(struct iram_table_v_2_2 *ram_table, struct 
> dmcu_iram_parameters params)
>  {
> unsigned int set = params.set;
>
> @@ -598,7 +598,7 @@ void fill_iram_v_2_2(struct iram_table_v_2_2 *ram_table, 
> struct dmcu_iram_parame
> params, ram_table, true);
>  }
>
> -void fill_iram_v_2_3(struct iram_table_v_2_2 *ram_table, struct 
> dmcu_iram_parameters params, bool big_endian)
> +static void fill_iram_v_2_3(struct iram_table_v_2_2 *ram_table, struct 
> dmcu_iram_parameters params, bool big_endian)
>  {
> unsigned int i, j;
> unsigned int set = params.set;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/30] drm/amd/display/dmub/src/dmub_dcn30: Include our own header containing prototypes

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn30.c:83:6: warning: 
> no previous prototype for ‘dmub_dcn30_backdoor_load’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn30.c:118:6: warning: 
> no previous prototype for ‘dmub_dcn30_setup_windows’ [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Bhawanpreet Lakha 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dmub/src/dmub_dcn30.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn30.c 
> b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn30.c
> index f00df02ded81b..7e6f4dbabe45b 100644
> --- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn30.c
> +++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn30.c
> @@ -26,6 +26,7 @@
>  #include "../dmub_srv.h"
>  #include "dmub_reg.h"
>  #include "dmub_dcn20.h"
> +#include "dmub_dcn30.h"
>
>  #include "sienna_cichlid_ip_offset.h"
>  #include "dcn/dcn_3_0_0_offset.h"
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/30] drm/amd/include/renoir_ip_offset: Mark top-level IP_BASE as __maybe_unused

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:226:29: warning: 
> ‘UVD0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:219:29: warning: 
> ‘USB0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:212:29: warning: 
> ‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:205:29: warning: 
> ‘THM_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:198:29: warning: 
> ‘SMUIO_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:191:29: warning: 
> ‘SDMA0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:184:29: warning: 
> ‘PCIE0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:177:29: warning: 
> ‘OSSSYS_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:172:29: warning: 
> ‘DCN_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:165:29: warning: 
> ‘NBIF0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:158:29: warning: 
> ‘MP1_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:151:29: warning: 
> ‘MP0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:144:29: warning: 
> ‘MMHUB_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:137:29: warning: 
> ‘L2IMU0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:130:29: warning: 
> ‘ISP_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:123:29: warning: 
> ‘IOHC0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:116:29: warning: 
> ‘HDP_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:109:29: warning: 
> ‘HDA_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:102:29: warning: 
> ‘GC_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:95:29: warning: 
> ‘FUSE_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:88:29: warning: 
> ‘DPCS_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:81:29: warning: 
> ‘DMU_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:74:29: warning: 
> ‘DIO_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:67:29: warning: 
> ‘DF_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:60:29: warning: 
> ‘DBGU_IO0_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:53:29: warning: 
> ‘CLK_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:46:29: warning: 
> ‘ATHUB_BASE’ defined but not used [-Wunused-const-variable=]
>  drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:39:29: warning: 
> ‘ACP_BASE’ defined but not used [-Wunused-const-variable=]
>
> 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 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/include/renoir_ip_offset.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/include/renoir_ip_offset.h 
> b/drivers/gpu/drm/amd/include/renoir_ip_offset.h
> index 07633e22e99a1..7dff85c81e5a7 100644
> --- a/drivers/gpu/drm/amd/include/renoir_ip_offset.h
> +++ b/drivers/gpu/drm/amd/include/renoir_ip_offset.h
> @@ -33,7 +33,7 @@ struct IP_BASE_INSTANCE
>  struct IP_BASE
>  {
>  struct IP_BASE_INSTANCE instance[MAX_INSTANCE];
> -};
> +} __maybe_unused;
>
>
>  static const struct IP_BASE ACP_BASE ={ { { { 0x02403800, 0x0048, 0, 0, 
> 0 } },
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 

Re: [PATCH 01/30] drm/amd/display/dc/dc_helper: Include our own header, containing prototypes

[Alex Deucher]

On Wed, Jan 13, 2021 at 3:08 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:299:10: warning: no 
> previous prototype for ‘generic_reg_get’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:307:10: warning: no 
> previous prototype for ‘generic_reg_get2’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:317:10: warning: no 
> previous prototype for ‘generic_reg_get3’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:329:10: warning: no 
> previous prototype for ‘generic_reg_get4’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:343:10: warning: no 
> previous prototype for ‘generic_reg_get5’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:359:10: warning: no 
> previous prototype for ‘generic_reg_get6’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:377:10: warning: no 
> previous prototype for ‘generic_reg_get7’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:397:10: warning: no 
> previous prototype for ‘generic_reg_get8’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:503:6: warning: no 
> previous prototype for ‘generic_write_indirect_reg’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:511:10: warning: no 
> previous prototype for ‘generic_read_indirect_reg’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:529:10: warning: no 
> previous prototype for ‘generic_indirect_reg_get’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:560:10: warning: no 
> previous prototype for ‘generic_indirect_reg_update_ex’ [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Noah Abradjian 
> Cc: Rodrigo Siqueira 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dc_helper.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_helper.c 
> b/drivers/gpu/drm/amd/display/dc/dc_helper.c
> index 57edb25fc3812..a612ba6dc3898 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_helper.c
> +++ b/drivers/gpu/drm/amd/display/dc/dc_helper.c
> @@ -34,6 +34,7 @@
>
>  #include "dc.h"
>  #include "dc_dmub_srv.h"
> +#include "reg_helper.h"
>
>  static inline void submit_dmub_read_modify_write(
> struct dc_reg_helper_state *offload,
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/40] drm/amd/display/dc/calcs/dce_calcs: Demote non-conformant kernel-doc function headers

[Alex Deucher]

On Mon, Jan 11, 2021 at 2:20 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2753: warning: 
> Function parameter or member 'vbios' not described in 
> 'is_display_configuration_supported'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2753: warning: 
> Function parameter or member 'calcs_output' not described in 
> 'is_display_configuration_supported'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3030: warning: 
> Function parameter or member 'ctx' not described in 'bw_calcs'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3030: warning: 
> Function parameter or member 'dceip' not described in 'bw_calcs'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3030: warning: 
> Function parameter or member 'vbios' not described in 'bw_calcs'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3030: warning: 
> Function parameter or member 'pipe' not described in 'bw_calcs'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3030: warning: 
> Function parameter or member 'pipe_count' not described in 'bw_calcs'
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3030: warning: 
> Function parameter or member 'calcs_output' not described in 'bw_calcs'
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lee Jones 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index f69c2b84d432b..967d6d80bd38e 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -2743,7 +2743,7 @@ void bw_calcs_init(struct bw_calcs_dceip *bw_dceip,
> kfree(vbios);
>  }
>
> -/**
> +/*
>   * Compare calculated (required) clocks against the clocks available at
>   * maximum voltage (max Performance Level).
>   */
> @@ -3014,13 +3014,12 @@ static bool all_displays_in_sync(const struct 
> pipe_ctx pipe[],
> return true;
>  }
>
> -/**
> +/*
>   * Return:
>   * true -  Display(s) configuration supported.
>   * In this case 'calcs_output' contains data for HW programming
>   * false - Display(s) configuration not supported (not enough bandwidth).
>   */
> -
>  bool bw_calcs(struct dc_context *ctx,
> const struct bw_calcs_dceip *dceip,
> const struct bw_calcs_vbios *vbios,
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Jerome Glisse]

On Thu, Jan 14, 2021 at 02:37:36PM +0100, Christian König wrote:
> Am 14.01.21 um 12:52 schrieb Daniel Vetter:
> > [SNIP]
> > > > I had a new idea, i wanted to think more about it but have not yet,
> > > > anyway here it is. Adding a new callback to dma fence which ask the
> > > > question can it dead lock ? Any time a GPU driver has pending page
> > > > fault (ie something calling into the mm) it answer yes, otherwise
> > > > no. The GPU shrinker would ask the question before waiting on any
> > > > dma-fence and back of if it gets yes. Shrinker can still try many
> > > > dma buf object for which it does not get a yes on associated fence.
> > > > 
> > > > This does not solve the mmu notifier case, for this you would just
> > > > invalidate the gem userptr object (with a flag but not releasing the
> > > > page refcount) but you would not wait for the GPU (ie no dma fence
> > > > wait in that code path anymore). The userptr API never really made
> > > > the contract that it will always be in sync with the mm view of the
> > > > world so if different page get remapped to same virtual address
> > > > while GPU is still working with the old pages it should not be an
> > > > issue (it would not be in our usage of userptr for compositor and
> > > > what not).
> > > The current working idea in my mind goes into a similar direction.
> > > 
> > > But instead of a callback I'm adding a complete new class of HMM fences.
> > > 
> > > Waiting in the MMU notfier, scheduler, TTM etc etc is only allowed for
> > > the dma_fences and HMM fences are ignored in container objects.
> > > 
> > > When you handle an implicit or explicit synchronization request from
> > > userspace you need to block for HMM fences to complete before taking any
> > > resource locks.
> > Isnt' that what I call gang scheduling? I.e. you either run in HMM
> > mode, or in legacy fencing mode (whether implicit or explicit doesn't
> > really matter I think). By forcing that split we avoid the problem,
> > but it means occasionally full stalls on mixed workloads.
> > 
> > But that's not what Jerome wants (afaiui at least), I think his idea
> > is to track the reverse dependencies of all the fences floating
> > around, and then skip evicting an object if you have to wait for any
> > fence that is problematic for the current calling context. And I don't
> > think that's very feasible in practice.
> > 
> > So what kind of hmm fences do you have in mind here?
> 
> It's a bit more relaxed than your gang schedule.
> 
> See the requirements are as follow:
> 
> 1. dma_fences never depend on hmm_fences.
> 2. hmm_fences can never preempt dma_fences.
> 3. dma_fences must be able to preempt hmm_fences or we always reserve enough
> hardware resources (CUs) to guarantee forward progress of dma_fences.
> 
> Critical sections are MMU notifiers, page faults, GPU schedulers and
> dma_reservation object locks.
> 
> 4. It is valid to wait for a dma_fences in critical sections.
> 5. It is not valid to wait for hmm_fences in critical sections.
> 
> Fence creation either happens during command submission or by adding
> something like a barrier or signal command to your userspace queue.
> 
> 6. If we have an hmm_fence as implicit or explicit dependency for creating a
> dma_fence we must wait for that before taking any locks or reserving
> resources.
> 7. If we have a dma_fence as implicit or explicit dependency for creating an
> hmm_fence we can wait later on. So busy waiting or special WAIT hardware
> commands are valid.
> 
> This prevents hard cuts, e.g. can mix hmm_fences and dma_fences at the same
> time on the hardware.
> 
> In other words we can have a high priority gfx queue running jobs based on
> dma_fences and a low priority compute queue running jobs based on
> hmm_fences.
> 
> Only when we switch from hmm_fence to dma_fence we need to block the
> submission until all the necessary resources (both memory as well as CUs)
> are available.
> 
> This is somewhat an extension to your gang submit idea.

What is hmm_fence ? You should not have fence with hmm at all.
So i am kind of scare now.

Cheers,
Jérôme

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 21/40] drm/amd/display/dc/calcs/dce_calcs: Remove unused variables 'v_filter_init_mode' and 'sclk_lvl'

[Alex Deucher]

Applied.  Thanks!

Alex

On Fri, Jan 8, 2021 at 3:15 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function 
> ‘calculate_bandwidth’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:109:18: warning: 
> variable ‘v_filter_init_mode’ set but not used [-Wunused-but-set-variable]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function 
> ‘bw_calcs’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3031:21: warning: 
> variable ‘sclk_lvl’ set but not used [-Wunused-but-set-variable]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> 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/display/dc/calcs/dce_calcs.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index ef41b287cbe23..158d927c03e55 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -106,7 +106,6 @@ static void calculate_bandwidth(
> bool lpt_enabled;
> enum bw_defines sclk_message;
> enum bw_defines yclk_message;
> -   enum bw_defines v_filter_init_mode[maximum_number_of_surfaces];
> enum bw_defines tiling_mode[maximum_number_of_surfaces];
> enum bw_defines surface_type[maximum_number_of_surfaces];
> enum bw_defines voltage;
> @@ -792,12 +791,8 @@ static void calculate_bandwidth(
> data->v_filter_init[i] = 
> bw_add(data->v_filter_init[i], bw_int_to_fixed(1));
> }
> if (data->stereo_mode[i] == bw_def_top_bottom) {
> -   v_filter_init_mode[i] = bw_def_manual;
> data->v_filter_init[i] = 
> bw_min2(data->v_filter_init[i], bw_int_to_fixed(4));
> }
> -   else {
> -   v_filter_init_mode[i] = bw_def_auto;
> -   }
> if (data->stereo_mode[i] == bw_def_top_bottom) {
> data->num_lines_at_frame_start = 
> bw_int_to_fixed(1);
> }
> @@ -3028,7 +3023,7 @@ bool bw_calcs(struct dc_context *ctx,
> calcs_output->all_displays_in_sync = false;
>
> if (data->number_of_displays != 0) {
> -   uint8_t yclk_lvl, sclk_lvl;
> +   uint8_t yclk_lvl;
> struct bw_fixed high_sclk = vbios->high_sclk;
> struct bw_fixed mid1_sclk = vbios->mid1_sclk;
> struct bw_fixed mid2_sclk = vbios->mid2_sclk;
> @@ -3049,7 +3044,6 @@ bool bw_calcs(struct dc_context *ctx,
> calculate_bandwidth(dceip, vbios, data);
>
> yclk_lvl = data->y_clk_level;
> -   sclk_lvl = data->sclk_level;
>
> calcs_output->nbp_state_change_enable =
> data->nbp_state_change_enable;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Daniel Vetter]

On Thu, Jan 14, 2021 at 5:01 PM Christian König
 wrote:
>
> Am 14.01.21 um 16:40 schrieb Daniel Vetter:
> > [SNIP]
> >> So I think we have to somehow solve this in the kernel or we will go in
> >> circles all the time.
> >>
> >>> So from that pov I think the kernel should at most deal with an
> >>> hmm_fence for cross-process communication and maybe some standard wait
> >>> primitives (for userspace to use, not for the kernel).
> >>>
> >>> The only use case this would forbid is using page faults for legacy
> >>> implicit/explicit dma_fence synced workloads, and I think that's
> >>> perfectly ok to not allow. Especially since the motivation here for
> >>> all this is compute, and compute doesn't pass around dma_fences
> >>> anyway.
> >> As Alex said we will rather soon see this for gfx as well and we most
> >> likely will see combinations of old dma_fence based integrated graphics
> >> with new dedicated GPUs.
> >>
> >> So I don't think we can say we reduce the problem to compute and don't
> >> support anything else.
> > I'm not against pagefaults for gfx, just in pushing the magic into the
> > kernel. I don't think that works, because it means we add stall points
> > where usespace, especially vk userspace, really doesn't want it. So
> > same way like timeline syncobj, we need to push the compat work into
> > userspace.
> >
> > There's going to be a few stall points:
> > - fully new stack, we wait for the userspace fence in the atomic
> > commit path (which we can, if we're really careful, since we pin all
> > buffers upfront and so there's no risk)
> > - userspace fencing gpu in the client, compositor protocol can pass
> > around userspace fences, but the compositor still uses dma_fence for
> > itself. There's some stalling in the compositor, which it does already
> > anyway when it's collecting new frames from clients
> > - userspace fencing gpu in the client, but no compositor protocol: We
> > wait in the swapchain, but in a separate thread so that nothing blocks
> > that shouldn't block
> >
> > If we instead go with "magic waits in the kernel behind userspace's
> > back", like what your item 6 would imply, then we're not really
> > solving anything.
> >
> > For actual implementation I think the best would be an extension of
> > drm_syncobj. Those already have at least conceptually future/infinite
> > fences, and we already have fd passing, so "just" need some protocol
> > to pass them around. Plus we could use the same uapi for timeline
> > syncobj using dma_fence as for hmm_fence, so also easier to transition
> > for userspace to the new world since don't need the new hw capability
> > to roll out the new uapi and protocols.
> >
> > That's not that hard to roll out, and technically a lot better than
> > hacking up dma_resv and hoping we don't end up stalling in wrong
> > places, which sounds very "k" to me :-)
>
> Yeah, that's what I totally agree upon :)
>
> My idea was just the last resort since we are mixing userspace sync and
> memory management so creative here.
>
> Stalling in userspace will probably get some push back as well, but
> maybe not as much as stalling in the kernel.

I guess we need to have last-resort stalling in the kernel, but no
more than what we do with drm_syncobj future fences right now. Like
when anything asks for a dma_fence out of an hmm_fence drm_syncob, we
just stall until the hmm_fence is signalled, and then create a
dma_fence that's already signalled and return that to the caller.
Obviously this shouldn't happen, since anyone who's timeline aware
will check whether the fence has at least materialized first and stall
somewhere more useful for that first.

> Ok if we can at least remove implicit sync from the picture then the
> question remains how do we integrate HMM into drm_syncobj then?

From an uapi pov probably just an ioctl to create an hmm drm_syncobj,
and a syncobj ioctl to query whether it's a hmm_fence or dma_fence
syncobj, so that userspace can be a bit more clever with where it
should stall - for an hmm_fence the stall will most likely be directly
on the gpu in many cases (so the ioctl should also give us all the
details about that if it's an hmm fence).

I think the real work is going through all the hardware and trying to
figure out what the common ground for userspace fences are. Stuff like
can they be in system memory, or need something special (wc maybe, but
I hope system memory should be fine for everyone), and how you count,
wrap and compare. I also have no idea how/if we can optimized cpu
waits across different drivers.

Plus ideally we get some actual wayland protocol going for passing
drm_syncobj around, so we can test it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/cma-helper: Implement mmap as GEM CMA object functions

[Kieran Bingham]

Hi Thomas,

On 14/01/2021 15:15, Thomas Zimmermann wrote:
 On 23/11/2020 11:56, Thomas Zimmermann wrote:
> The new GEM object function drm_gem_cma_mmap() sets the VMA flags
> and offset as in the old implementation and immediately maps in the
> buffer's memory pages.
>
> Changing CMA helpers to use the GEM object function allows for the
> removal of the special implementations for mmap and gem_prime_mmap
> callbacks. The regular functions drm_gem_mmap() and
> drm_gem_prime_mmap()
> are now used.

 I've encountered a memory leak regression in our Renesas R-Car DU
 tests,
 and git bisection has led me to this patch (as commit f5ca8eb6f9).

 Running the tests sequentially, while grepping /proc/meminfo for
 Cma, it
 is evident that CMA memory is not released, until exhausted and the
 allocations fail (seen in [0]) shown by the error report:

>   self.fbs.append(pykms.DumbFramebuffer(self.card, mode.hdisplay,
> mode.vdisplay, "XR24"))
> ValueError: DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory


 Failing tests at f5ca8eb6f9 can be seen at [0], while the tests pass
 successfully [1] on the commit previous to that (bc2532ab7c2):

 Reverting f5ca8eb6f9 also produces a successful pass [2]

    [0] https://paste.ubuntu.com/p/VjPGPgswxR/ # Failed at f5ca8eb6f9
    [1] https://paste.ubuntu.com/p/78RRp2WpNR/ # Success at bc2532ab7c2
    [2] https://paste.ubuntu.com/p/qJKjZZN2pt/ # Success with revert


 I don't believe we handle mmap specially in the RCar-DU driver, so I
 wonder if this issue has hit anyone else as well?

 Any ideas of a repair without a revert ? Or do we just need to submit a
 revert?
>>>
>>> I think we might not be setting the VMA ops and therefore not finalize
>>> the BO correctly. Could you please apply the attched (quick-and-dirty)
>>> patch and try again?
>>
>> Thanks for the quick response.
>>
>> I can confirm the quick-and-dirty patch resolves the issue:
>>    https://paste.ubuntu.com/p/sKDp3dNvwV/
>>
>> You can add a
>> Tested-by: Kieran Bingham 
> 
> Great! If you don't mind, I'd also add you in the Reported-by tag.

Certainly!

>>
>> if it stays like that, but I suspect there might be a better place to
>> initialise the ops rather than in the mmap call itself.
> 
> I think that's the fix, basically. We could put such a line as a
> fall-back somewhere into the DRM core code. But I don't know if this
> really works with all drivers. Maybe there's one that requires vm_ops to
> be NULL.

Ok, that's reaching beyond code I've explored, so I'll leave it to you.


> Thanks for reporting this issue and testing quickly.

Thanks for fixing so quickly :-)

Regards

Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 06/10] drm: rcar-du: Handle CRTC configuration from commit tail handler

[Kieran Bingham]

The CRTC mode setting and routing configuration are performed at the
earliest of atomic enable and atomic begin, to ensure that a valid
configuration is applied to the hardware before the CRTC gets enabled
and before planes are setup (the latter being required in particular by
the VSP). This requires the rcar_du_crtc structure to track the CRTC
enabled state.

Simplify the code and remove the manual state tracking by moving CRTC
setup to a new rcar_du_crtc_atomic_modeset() function, called directly
from the commit tail handler. The function iterates over all CRTCs in
the state transaction and performs CRTC mode setting, routing
configuration and VSP configuration.

drm_crtc_vblank_on() has to be called from the atomic begin handler, to
ensure that vertical blanking reporting is enabled before the call to
drm_crtc_vblank_get() in the atomic flush handler. As the
drm_crtc_vblank_on() and drm_crtc_vblank_off() calls don't need to be
balanced this is not an issue. A balanced alternative would have been to
call drm_crtc_vblank_on() and drm_crtc_vblank_off() from the CRTC exit
and enter standby handlers respectively, but
drm_atomic_helper_commit_modeset_disables() complains if
drm_crtc_vblank_off() hasn't been called by the atomic disable handler.

As a result, the vsp1_du_atomic_flush() operation can be called with the
DRM pipeline disabled. Correct operation has been ensured by "media:
vsp1: drm: Don't configure hardware when the pipeline is disabled".

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Deconstruct rcar_du_crtc_setup() completely

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 89 +++---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  4 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  1 +
 3 files changed, 42 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 55c0e0259153..7ca721e6b9d7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -519,22 +519,6 @@ static void rcar_du_cmm_setup(struct drm_crtc *crtc)
  * Start/Stop and Suspend/Resume
  */
 
-static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
-{
-   /* Configure display timings and output routing */
-   rcar_du_crtc_set_display_timing(rcrtc);
-   rcar_du_group_set_routing(rcrtc->group);
-
-   /* Enable the VSP compositor. */
-   if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
-   rcar_du_vsp_modeset(rcrtc);
-   rcar_du_vsp_enable(rcrtc);
-   }
-
-   /* Turn vertical blanking interrupt reporting on. */
-   drm_crtc_vblank_on(>crtc);
-}
-
 static int rcar_du_crtc_exit_standby(struct rcar_du_crtc *rcrtc)
 {
int ret;
@@ -575,24 +559,6 @@ static void rcar_du_crtc_enter_standby(struct rcar_du_crtc 
*rcrtc)
clk_disable_unprepare(rcrtc->clock);
 }
 
-static void rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
-{
-   /*
-* Guard against double-get, as the function is called from both the
-* .atomic_enable() and .atomic_begin() handlers.
-*/
-   if (rcrtc->initialized)
-   return;
-
-   rcar_du_crtc_setup(rcrtc);
-   rcrtc->initialized = true;
-}
-
-static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
-{
-   rcrtc->initialized = false;
-}
-
 static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
 {
bool interlaced;
@@ -768,6 +734,40 @@ int rcar_du_crtc_atomic_enter_standby(struct drm_device 
*dev,
return 0;
 }
 
+/*
+ * Configure the mode for all CRTCs that require it. For now we only handle 
mode
+ * set on the VSP, CRTC configuration will be handled later.
+ */
+int rcar_du_crtc_atomic_modeset(struct drm_device *dev,
+   struct drm_atomic_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   unsigned int i;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+   /*
+* Skip commits that don't change the mode. We manually skip
+* inactive CRTCs as disabling a CRTC is considered as a mode
+* set by drm_atomic_crtc_needs_modeset().
+*/
+   if (!drm_atomic_crtc_needs_modeset(crtc_state) ||
+   !crtc_state->active)
+   continue;
+
+   /* Configure display timings and output routing. */
+   rcar_du_crtc_set_display_timing(rcrtc);
+   rcar_du_group_set_routing(rcrtc->group);
+
+   if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
+   rcar_du_vsp_modeset(rcrtc);
+   }
+
+   return 0;
+}
+
 static void rcar_du_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
@@ -777,8 

[PATCH v4 08/10] drm: rcar-du: Create a group state object

[Kieran Bingham]

Create a new private state object for the DU groups, and move the
initialisation of a group object to a new function rcar_du_group_init().

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v3:
- Rebase to v5.11
- Fix pointer passing for drm_atomic_private_obj_init()
- Fix checkpatch.pl --strict warning about if (state == NULL)

Changes since v2:

- Call mutex_destroy() when cleaning up the group
- Include mutex.h and slab.h
- Squash "drm: rcar-du: Add rcar_du_get_{old,new}_group_state()"

 drivers/gpu/drm/rcar-du/rcar_du_group.c | 144 
 drivers/gpu/drm/rcar-du/rcar_du_group.h |  29 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  27 +
 3 files changed, 177 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 88a783ceb3e9..7c13def703b7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -25,6 +25,11 @@
 
 #include 
 #include 
+#include 
+
+#include 
+#include 
+#include 
 
 #include "rcar_du_drv.h"
 #include "rcar_du_group.h"
@@ -361,3 +366,142 @@ int rcar_du_group_set_routing(struct rcar_du_group *rgrp)
 
return rcar_du_set_dpad0_vsp1_routing(rgrp->dev);
 }
+
+/* 
-
+ * Group State Handling
+ */
+
+static struct drm_private_state *
+rcar_du_group_atomic_duplicate_state(struct drm_private_obj *obj)
+{
+   struct rcar_du_group_state *state;
+
+   if (WARN_ON(!obj->state))
+   return NULL;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
+
+   __drm_atomic_helper_private_obj_duplicate_state(obj, >state);
+
+   return >state;
+}
+
+static void rcar_du_group_atomic_destroy_state(struct drm_private_obj *obj,
+  struct drm_private_state *state)
+{
+   kfree(to_rcar_group_state(state));
+}
+
+static const struct drm_private_state_funcs rcar_du_group_state_funcs = {
+   .atomic_duplicate_state = rcar_du_group_atomic_duplicate_state,
+   .atomic_destroy_state = rcar_du_group_atomic_destroy_state,
+};
+
+/**
+ * rcar_du_get_old_group_state - get old group state, if it exists
+ * @state: global atomic state object
+ * @rgrp: group to grab
+ *
+ * This function returns the old group state for the given group, or
+ * NULL if the group is not part of the global atomic state.
+ */
+struct rcar_du_group_state *
+rcar_du_get_old_group_state(struct drm_atomic_state *state,
+   struct rcar_du_group *rgrp)
+{
+   struct drm_private_obj *obj = >private;
+   struct drm_private_state *pstate;
+   unsigned int i;
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   if (obj == state->private_objs[i].ptr) {
+   pstate = state->private_objs[i].old_state;
+   return to_rcar_group_state(pstate);
+   }
+   }
+
+   return NULL;
+}
+
+/**
+ * rcar_du_get_new_group_state - get new group state, if it exists
+ * @state: global atomic state object
+ * @rgrp: group to grab
+ *
+ * This function returns the new group state for the given group, or
+ * NULL if the group is not part of the global atomic state.
+ */
+struct rcar_du_group_state *
+rcar_du_get_new_group_state(struct drm_atomic_state *state,
+   struct rcar_du_group *rgrp)
+{
+   struct drm_private_obj *obj = >private;
+   struct drm_private_state *pstate;
+   unsigned int i;
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   if (obj == state->private_objs[i].ptr) {
+   pstate = state->private_objs[i].new_state;
+   return to_rcar_group_state(pstate);
+   }
+   }
+
+   return NULL;
+}
+
+/* 
-
+ * Init and Cleanup
+ */
+
+/*
+ * rcar_du_group_init - Initialise and reset a group object
+ *
+ * Return 0 in case of success or a negative error code otherwise.
+ */
+int rcar_du_group_init(struct rcar_du_device *rcdu, struct rcar_du_group *rgrp,
+  unsigned int index)
+{
+   static const unsigned int mmio_offsets[] = {
+   DU0_REG_OFFSET, DU2_REG_OFFSET
+   };
+
+   struct rcar_du_group_state *state;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return -ENOMEM;
+
+   drm_atomic_private_obj_init(>ddev, >private, >state,
+   _du_group_state_funcs);
+
+   mutex_init(>lock);
+
+   rgrp->dev = rcdu;
+   rgrp->mmio_offset = mmio_offsets[index];
+   rgrp->index = index;
+   /* Extract the channel mask for this group only. */
+   rgrp->channels_mask = (rcdu->info->channels_mask >> (2 * index))
+ 

[PATCH v4 02/10] media: vsp1: drm: Don't configure hardware when the pipeline is disabled

[Kieran Bingham]

From: Laurent Pinchart 

The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
to configure the hardware pipeline. The function is currently guaranteed
to be called with the pipeline enabled, but this will change by future
rework of the DU driver. Guard the hardware configuration to skip it
when the pipeline is disabled. The hardware will be configured the next
time the pipeline gets enabled.

Reviewed-by: Ulrich Hecht 
Reviewed-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 13 -
 drivers/media/platform/vsp1/vsp1_drm.h |  2 ++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 2bac80014bf4..fa79cac32e49 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -723,6 +723,8 @@ int vsp1_du_atomic_enable(struct device *dev, unsigned int 
pipe_index,
/* Configure all entities in the pipeline. */
vsp1_du_pipeline_configure(pipe);
 
+   drm_pipe->enabled = true;
+
 unlock:
mutex_unlock(>drm->lock);
 
@@ -799,6 +801,8 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned int 
pipe_index)
pipe->brx->pipe = NULL;
pipe->brx = NULL;
 
+   drm_pipe->enabled = false;
+
mutex_unlock(>drm->lock);
 
vsp1_dlm_reset(pipe->output->dlm);
@@ -991,7 +995,14 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index,
}
 
vsp1_du_pipeline_setup_inputs(vsp1, pipe);
-   vsp1_du_pipeline_configure(pipe);
+
+   /*
+* We may get called before the pipeline gets enabled, postpone
+* configuration in that case. vsp1_du_pipeline_configure() will be
+* called from vsp1_du_atomic_enable().
+*/
+   if (drm_pipe->enabled)
+   vsp1_du_pipeline_configure(pipe);
 
 done:
mutex_unlock(>drm->lock);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index e85ad4366fbb..d780dafc1324 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -20,6 +20,7 @@
 /**
  * vsp1_drm_pipeline - State for the API exposed to the DRM driver
  * @pipe: the VSP1 pipeline used for display
+ * @enabled: true if the pipeline is enabled
  * @width: output display width
  * @height: output display height
  * @force_brx_release: when set, release the BRx during the next 
reconfiguration
@@ -31,6 +32,7 @@
  */
 struct vsp1_drm_pipeline {
struct vsp1_pipeline pipe;
+   bool enabled;
 
unsigned int width;
unsigned int height;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 10/10] drm: rcar-du: Centralise routing configuration in commit tail handler

[Kieran Bingham]

From: Laurent Pinchart 

Routing configuration for the DU is complex. Depending on the SoC
generation various routing options are available:

- The VSP to DU routing is not available on Gen1, is configurable on
  Gen2 and is fixed on Gen3. When configurable, the routing affects both
  CRTC groups but is set in a register of the first CRTC group.
- The DU channel to DPAD output routing is explicitly configurable on
  some SoCs of the Gen2 and Gen3 family. When configurable, the DPAD
  outputs never offer routing options to CRTCs belonging to different
  groups.
- On all SoCs the routing of DU channels to DU pin controllers (internal
  output of the DU channels) can be swapped within a group. This feature
  is only used on Gen1 to control routing of the DPAD1 output.

Routing is thus handled at the group level, but for Gen2 hardware
requires configuration of the DPAD0 and VSPD1 routing in the first group
even when only the second group is enabled.

Routing at the group level is currently configured when applying CRTC
configuration. Global routing is configured at the same time, and is
additionally configured by the plane setup code to set VSPD1 routing.
This results in code paths that are difficult to follow.

Simplify the routing configuration by performing it all directly, based
on CRTC and CRTC group state. Group-level routing is moved to group
setup as it only depends on the group state and the state of the CRTCs
it contains. Global routing is moved to the commit tail handler, and
based on global DU state.

Reviewed-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Kieran Bingham 
---
Changes since v3:
- s/DPAD1/DPAD0/
- s/VSP1D/VSPD1/

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 156 
 drivers/gpu/drm/rcar-du/rcar_du_group.h |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  16 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  10 +-
 6 files changed, 116 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 020eb75732a7..b5f07fd9c4be 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -747,9 +747,8 @@ int rcar_du_crtc_atomic_modeset(struct drm_device *dev,
!crtc_state->active)
continue;
 
-   /* Configure display timings and output routing. */
+   /* Configure display timings. */
rcar_du_crtc_set_display_timing(rcrtc);
-   rcar_du_group_set_routing(rcrtc->group);
 
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_modeset(rcrtc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index e792ba7f5145..ed0b57722f37 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -95,7 +95,6 @@ struct rcar_du_device {
} props;
 
unsigned int dpad0_source;
-   unsigned int dpad1_source;
unsigned int vspd1_sink;
 };
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index fdd4a60f5f5e..368676507097 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -46,6 +46,10 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32 
reg, u32 data)
rcar_du_write(rgrp->dev, rgrp->mmio_offset + reg, data);
 }
 
+/* 
-
+ * Static Group Setup
+ */
+
 static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
 {
u32 defr6 = DEFR6_CODE;
@@ -59,37 +63,6 @@ static void rcar_du_group_setup_pins(struct rcar_du_group 
*rgrp)
rcar_du_group_write(rgrp, DEFR6, defr6);
 }
 
-static void rcar_du_group_setup_defr8(struct rcar_du_group *rgrp)
-{
-   struct rcar_du_device *rcdu = rgrp->dev;
-   u32 defr8 = DEFR8_CODE;
-
-   if (rcdu->info->gen < 3) {
-   defr8 |= DEFR8_DEFE8;
-
-   /*
-* On Gen2 the DEFR8 register for the first group also controls
-* RGB output routing to DPAD0 and VSPD1 routing to DU0/1/2 for
-* DU instances that support it.
-*/
-   if (rgrp->index == 0) {
-   defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
-   if (rgrp->dev->vspd1_sink == 2)
-   defr8 |= DEFR8_VSCS;
-   }
-   } else {
-   /*
-* On Gen3 VSPD routing can't be configured, and DPAD routing
-* is set in the group corresponding to the DPAD output (no Gen3
-* SoC has multiple DPAD sources belonging to separate groups).
-*/
-   if (rgrp->index == rcdu->dpad0_source / 2)
-   

[PATCH v4 09/10] drm: rcar-du: Perform group setup from the atomic tail handler

[Kieran Bingham]

Create rcar_du_group_atomic_check() and rcar_du_group_atomic_setup()
functions to track and apply group state through the DRM atomic state.
The use_count field is moved from the rcar_du_group structure to an
enabled field in the rcar_du_group_state structure.

This allows separating group setup from the configuration of the CRTCs
that are part of the group, simplifying the CRTC code and improving
overall readability. The existing rcar_du_group_{get,put}() functions
are now redundant and removed.

The groups share clocking with the CRTCs within the group, and so are
accessible only when one of its CRTCs has been powered through
rcar_du_crtc_atomic_exit_standby().

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v3:
- Shorted macro length, and added relevant documentation to its usage
  and function.

Changes since v2:

- Simplify error handling in rcar_du_crtc_enable()
- Rename rcar_du_group_atomic_pre_commit() to
  rcar_du_group_atomic_setup() and turn it into a void function
- Remove rcar_du_group_atomic_post_commit()
- Replace group state use_count field by enabled
- Rename group state variable from rstate to gstate

Changes since v1:

- All register sequences now maintained.
- Clock management is no longer handled by the group
  (_crtc_{exit,enter}_standby handles this for us)

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  18 +
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 102 
 drivers/gpu/drm/rcar-du/rcar_du_group.h |  12 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |   5 ++
 4 files changed, 87 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7ca721e6b9d7..020eb75732a7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -528,12 +528,10 @@ static int rcar_du_crtc_exit_standby(struct rcar_du_crtc 
*rcrtc)
return ret;
 
ret = clk_prepare_enable(rcrtc->extclock);
-   if (ret < 0)
-   goto error_clock;
-
-   ret = rcar_du_group_get(rcrtc->group);
-   if (ret < 0)
-   goto error_group;
+   if (ret < 0) {
+   clk_disable_unprepare(rcrtc->clock);
+   return ret;
+   }
 
/* Set display off and background to black. */
rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
@@ -543,18 +541,10 @@ static int rcar_du_crtc_exit_standby(struct rcar_du_crtc 
*rcrtc)
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
 
return 0;
-
-error_group:
-   clk_disable_unprepare(rcrtc->extclock);
-error_clock:
-   clk_disable_unprepare(rcrtc->clock);
-   return ret;
 }
 
 static void rcar_du_crtc_enter_standby(struct rcar_du_crtc *rcrtc)
 {
-   rcar_du_group_put(rcrtc->group);
-
clk_disable_unprepare(rcrtc->extclock);
clk_disable_unprepare(rcrtc->clock);
 }
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 7c13def703b7..fdd4a60f5f5e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -24,6 +24,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -183,38 +184,6 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
mutex_unlock(>lock);
 }
 
-/*
- * rcar_du_group_get - Acquire a reference to the DU channels group
- *
- * Acquiring the first reference setups core registers. A reference must be 
held
- * before accessing any hardware registers.
- *
- * This function must be called with the DRM mode_config lock held.
- *
- * Return 0 in case of success or a negative error code otherwise.
- */
-int rcar_du_group_get(struct rcar_du_group *rgrp)
-{
-   if (rgrp->use_count)
-   goto done;
-
-   rcar_du_group_setup(rgrp);
-
-done:
-   rgrp->use_count++;
-   return 0;
-}
-
-/*
- * rcar_du_group_put - Release a reference to the DU
- *
- * This function must be called with the DRM mode_config lock held.
- */
-void rcar_du_group_put(struct rcar_du_group *rgrp)
-{
-   --rgrp->use_count;
-}
-
 static void __rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
 {
struct rcar_du_device *rcdu = rgrp->dev;
@@ -399,6 +368,34 @@ static const struct drm_private_state_funcs 
rcar_du_group_state_funcs = {
.atomic_destroy_state = rcar_du_group_atomic_destroy_state,
 };
 
+/**
+ * for_each_oldnew_group_in_state - iterate over all groups in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @__obj:  drm_private_obj iteration cursor
+ * @__old:  drm_private_state iteration cursor for the old state
+ * @__new:  drm_private_state iteration cursor for the new state
+ * @__i: unsigned int iteration cursor, for macro-internal use
+ *
+ * Iterate over all private objects in an atomic update, processing only those
+ * which represent rcar_du_group_state, tracking both old and new state.
+ 

[PATCH v4 07/10] drm: rcar-du: Provide for_each_group helper

[Kieran Bingham]

Refactoring of the group control code will soon require more iteration
over the available groups. Simplify this process by introducing a group
iteration helper.

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Don't assign __group in the condition part of the for statement of the
  for_each_rcdu_group() macro

 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  5 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 02ca2d0e1b55..e792ba7f5145 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -104,6 +104,11 @@ static inline struct rcar_du_device 
*to_rcar_du_device(struct drm_device *dev)
return container_of(dev, struct rcar_du_device, ddev);
 }
 
+#define for_each_rcdu_group(__rcdu, __group, __i) \
+   for ((__i) = 0, (__group) = &(__rcdu)->groups[0]; \
+(__i) < DIV_ROUND_UP((__rcdu)->num_crtcs, 2); \
+__i++, __group++)
+
 static inline bool rcar_du_has(struct rcar_du_device *rcdu,
   unsigned int feature)
 {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3c10c329c81c..732aac342dab 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -771,9 +771,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
 
struct drm_device *dev = >ddev;
struct drm_encoder *encoder;
+   struct rcar_du_group *rgrp;
unsigned int dpad0_sources;
unsigned int num_encoders;
-   unsigned int num_groups;
unsigned int swindex;
unsigned int hwindex;
unsigned int i;
@@ -820,11 +820,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
return ret;
 
/* Initialize the groups. */
-   num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);
-
-   for (i = 0; i < num_groups; ++i) {
-   struct rcar_du_group *rgrp = >groups[i];
-
+   for_each_rcdu_group(rcdu, rgrp, i) {
mutex_init(>lock);
 
rgrp->dev = rcdu;
@@ -866,8 +862,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
 
/* Create the CRTCs. */
for (swindex = 0, hwindex = 0; swindex < rcdu->num_crtcs; ++hwindex) {
-   struct rcar_du_group *rgrp;
-
/* Skip unpopulated DU channels. */
if (!(rcdu->info->channels_mask & BIT(hwindex)))
continue;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 05/10] drm: rcar-du: Handle CRTC standby from commit tail handler

[Kieran Bingham]

Manage the power state, and initial configuration of the CRTC from the
commit tail handler. CRTCs which need to be activated are taken out of
standby, and any deactivated CRTCs are put into standby.

This aims at removing CRTC state tracking from the rcar_du_crtc
structure. The initial configuration of the CRTC background colours and
disabling of all planes is taken out of rcar_du_crtc_setup() and moved
inline into rcar_du_crtc_enable(). rcar_du_crtc_get() and
rcar_du_crtc_put() are kept as they are needed to configure the VSP at
the correct time, this will be addressed in a separate change.

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Add more documentation
- Keep rcar_du_crtc_get() and rcar_du_crtc_put()
- Renamed rcar_du_crtc_enable() to rcar_du_crtc_exit_standby() and
  rcar_du_crtc_disable() to rcar_du_crtc_enter_standby()
- Reword commit message

Changes since v1:

- Registers sequence confirmed unchanged
- Re-ordered in the series to handle before groups
- Do not merge rcar_du_crtc_setup() (now handled by _crtc_pre_commit)

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 90 --
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  5 ++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  4 ++
 3 files changed, 81 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 53838dde2f29..55c0e0259153 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -521,17 +521,10 @@ static void rcar_du_cmm_setup(struct drm_crtc *crtc)
 
 static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
 {
-   /* Set display off and background to black */
-   rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
-   rcar_du_crtc_write(rcrtc, BPOR, BPOR_RGB(0, 0, 0));
-
/* Configure display timings and output routing */
rcar_du_crtc_set_display_timing(rcrtc);
rcar_du_group_set_routing(rcrtc->group);
 
-   /* Start with all planes disabled. */
-   rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
-
/* Enable the VSP compositor. */
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
rcar_du_vsp_modeset(rcrtc);
@@ -542,17 +535,10 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
drm_crtc_vblank_on(>crtc);
 }
 
-static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
+static int rcar_du_crtc_exit_standby(struct rcar_du_crtc *rcrtc)
 {
int ret;
 
-   /*
-* Guard against double-get, as the function is called from both the
-* .atomic_enable() and .atomic_begin() handlers.
-*/
-   if (rcrtc->initialized)
-   return 0;
-
ret = clk_prepare_enable(rcrtc->clock);
if (ret < 0)
return ret;
@@ -565,8 +551,12 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
if (ret < 0)
goto error_group;
 
-   rcar_du_crtc_setup(rcrtc);
-   rcrtc->initialized = true;
+   /* Set display off and background to black. */
+   rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
+   rcar_du_crtc_write(rcrtc, BPOR, BPOR_RGB(0, 0, 0));
+
+   /* Start with all planes disabled. */
+   rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
 
return 0;
 
@@ -577,13 +567,29 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
return ret;
 }
 
-static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
+static void rcar_du_crtc_enter_standby(struct rcar_du_crtc *rcrtc)
 {
rcar_du_group_put(rcrtc->group);
 
clk_disable_unprepare(rcrtc->extclock);
clk_disable_unprepare(rcrtc->clock);
+}
+
+static void rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
+{
+   /*
+* Guard against double-get, as the function is called from both the
+* .atomic_enable() and .atomic_begin() handlers.
+*/
+   if (rcrtc->initialized)
+   return;
+
+   rcar_du_crtc_setup(rcrtc);
+   rcrtc->initialized = true;
+}
 
+static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
+{
rcrtc->initialized = false;
 }
 
@@ -714,6 +720,54 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
 }
 
+/*
+ * Take all CRTCs that are made active in this commit out of standby.
+ * CRTCs that are deactivated by the commit are untouched and will be
+ * put in standby by rcar_du_crtc_atomic_enter_standby().
+ */
+int rcar_du_crtc_atomic_exit_standby(struct drm_device *dev,
+struct drm_atomic_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   unsigned int i;
+   int ret;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+   if 

[PATCH v4 04/10] media: vsp1: drm: Remove vsp1_du_setup_lif()

[Kieran Bingham]

The vsp1_du_setup_lif() function is deprecated, and the users have been
removed. Remove the implementation and the associated configuration
structure.

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 46 --
 include/media/vsp1.h   | 22 
 2 files changed, 68 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index fa79cac32e49..46692460f8a6 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -814,52 +814,6 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned 
int pipe_index)
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_disable);
 
-/**
- * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
- * @dev: the VSP device
- * @pipe_index: the DRM pipeline index
- * @cfg: the LIF configuration
- *
- * Configure the output part of VSP DRM pipeline for the given frame @cfg.width
- * and @cfg.height. This sets up formats on the BRx source pad, the WPF sink 
and
- * source pads, and the LIF sink pad.
- *
- * The @pipe_index argument selects which DRM pipeline to setup. The number of
- * available pipelines depend on the VSP instance.
- *
- * As the media bus code on the blend unit source pad is conditioned by the
- * configuration of its sink 0 pad, we also set up the formats on all blend 
unit
- * sinks, even if the configuration will be overwritten later by
- * vsp1_du_setup_rpf(). This ensures that the blend unit configuration is set 
to
- * a well defined state.
- *
- * Return 0 on success or a negative error code on failure.
- */
-int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
- const struct vsp1_du_lif_config *cfg)
-{
-   struct vsp1_du_modeset_config modes;
-   struct vsp1_du_enable_config enable;
-   int ret;
-
-   if (!cfg)
-   return vsp1_du_atomic_disable(dev, pipe_index);
-
-   modes.width = cfg->width;
-   modes.height = cfg->height;
-   modes.interlaced = cfg->interlaced;
-
-   ret = vsp1_du_atomic_modeset(dev, pipe_index, );
-   if (ret)
-   return ret;
-
-   enable.callback = cfg->callback;
-   enable.callback_data = cfg->callback_data;
-
-   return vsp1_du_atomic_enable(dev, pipe_index, );
-}
-EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
-
 /**
  * vsp1_du_atomic_begin - Prepare for an atomic update
  * @dev: the VSP device
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 253db8029752..a4eda8c9d048 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -20,28 +20,6 @@ int vsp1_du_init(struct device *dev);
 #define VSP1_DU_STATUS_COMPLETEBIT(0)
 #define VSP1_DU_STATUS_WRITEBACK   BIT(1)
 
-/**
- * struct vsp1_du_lif_config - VSP LIF configuration - Deprecated
- * @width: output frame width
- * @height: output frame height
- * @interlaced: true for interlaced pipelines
- * @callback: frame completion callback function (optional). When a callback
- *   is provided, the VSP driver guarantees that it will be called once
- *   and only once for each vsp1_du_atomic_flush() call.
- * @callback_data: data to be passed to the frame completion callback
- */
-struct vsp1_du_lif_config {
-   unsigned int width;
-   unsigned int height;
-   bool interlaced;
-
-   void (*callback)(void *data, unsigned int status, u32 crc);
-   void *callback_data;
-};
-
-int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
- const struct vsp1_du_lif_config *cfg);
-
 /**
  * struct vsp1_du_modeset_config - VSP display mode configuration
  * @width: output frame width
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 03/10] drm: rcar-du: Convert to the new VSP atomic API

[Kieran Bingham]

The configuration API between the VSP and the DU has been updated to
provide finer grain control over modesetting, and enablement.

Split rcar_du_vsp_enable() into rcar_du_vsp_modeset() and
rcar_du_vsp_enable() accordingly, and update each function to use the
new VSP API.

There are no further users of the deprecated vsp1_du_setup_lif() which
can now be removed.

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Minor formatting changes

Changes since v3:
- Minor formatting for checkpatch.pl --strict

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 20 ++--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h  |  3 +++
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index ea7e39d03545..53838dde2f29 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -533,8 +533,10 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
 
/* Enable the VSP compositor. */
-   if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
+   if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
+   rcar_du_vsp_modeset(rcrtc);
rcar_du_vsp_enable(rcrtc);
+   }
 
/* Turn vertical blanking interrupt reporting on. */
drm_crtc_vblank_on(>crtc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 53221d8473c1..b9e6b8531c96 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -46,16 +46,14 @@ static void rcar_du_vsp_complete(void *private, unsigned 
int status, u32 crc)
drm_crtc_add_crc_entry(>crtc, false, 0, );
 }
 
-void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
+void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
struct rcar_du_device *rcdu = crtc->dev;
-   struct vsp1_du_lif_config cfg = {
+   struct vsp1_du_modeset_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
.interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE,
-   .callback = rcar_du_vsp_complete,
-   .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
@@ -92,12 +90,22 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 */
crtc->group->need_restart = true;
 
-   vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
+   vsp1_du_atomic_modeset(crtc->vsp->vsp, crtc->vsp_pipe, );
+}
+
+void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
+{
+   struct vsp1_du_enable_config cfg = {
+   .callback = rcar_du_vsp_complete,
+   .callback_data = crtc,
+   };
+
+   vsp1_du_atomic_enable(crtc->vsp->vsp, crtc->vsp_pipe, );
 }
 
 void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
+   vsp1_du_atomic_disable(crtc->vsp->vsp, crtc->vsp_pipe);
 }
 
 void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 9b4724159378..7c141523434d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -58,6 +58,7 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
 #ifdef CONFIG_DRM_RCAR_VSP
 int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
 unsigned int crtcs);
+void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
@@ -73,6 +74,8 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
 {
return -ENXIO;
 }
+
+static inlinc void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 00/10] drm: rcar-du: Rework CRTC and groups for atomic commits

[Kieran Bingham]

This patch series refactors atomic commit tail handling in the R-Car DU
driver to simplify the code flow, and open the door to further
optimisations. It rebases the series posted by Laurent "[PATCH v3 00/10]
drm: rcar-du: Rework CRTC and groups for atomic commits", which was
itself based upon work that I had started originally.

A few minor updates were required for the rebase, and review comments
from v3 were handled, along with minor updates based upon suggestions
from 'checkpatch.pl --strict'.


The R-Car DU is a bit of a strange beast, with support for up to four
CRTCs that share resources in groups of two CRTCs. Depending on the
generation, planes can be shared (on Gen 1 and Gen 2), and output
routing configuration is also handled at the group level to some extent.
Furthermore, many configuration parameters, especially those related to
routing or clock handling, require the whole group to be restarted to
take effect, even when the parameter itself affects a single CRTC only.

This hardware architecture is difficult to handle properly on the
software side, and has resulted in group usage being reference-counted
while CRTC usage only tracks the enabled state. Calls are then
unbalanced and difficult to trace, especially for the configuration of
output routing, and implementation of new shared resources is hindered.
This patch series aims at solving this problem.

The series starts with 4 patches that touch the API between the DU and
VSP drivers. It became apparent that we need to split the configuration
of the VSP to allow fine grain control of setting the mode configuration
and enabling/disabling of the pipeline. To support the cross-component
API, the new interface is added in patch 01/10, including an
implementation of vsp1_du_setup_lif() to support the transition. Patch
02/10 prepares for the new call flow that will call the atomic flush
handler before enabling the pipeline. The DRM usage is adapted in patch
03/10, before the call is removed entirely in patch 04/10.

The next two patches convert CRTC clock handling and initial setup,
potentially called from both the CRTC .atomic_begin() and
.atomic_enable() operations, to a simpler code flow controlled by the
commit tail handler. Patch 05/10 takes the CRTCs out of standby and put
them back in standby respectively at the beginning and end of the commit
tail handler, based on the CRTC atomic state instead of state
information stored in the custom rcar_du_crtc structure. Patch 06/10
then performs a similar change for the CRTC mode setting configuration.

Finally, the last four patches introduce a DRM private object for the
CRTC groups, along with an associated state. Patch 07/10 adds a helper
macro to easily iterate over CRTC groups, and patch 08/10 adds the group
private objects and empty states. Patches 09/10 and 10/10 respectively
move the group setup and routing configuration under control of the
commit tail handler, simplifying the configuration and moving state
information from driver structures to state structures.

More refactoring is expected, with plane assignment being moved to group
states, and group restart being optimised to avoid flickering. Better
configuration of pixel clocks could also be implemented on top of this
series.

The whole series has been tested on Salvator-XS with the DU test suite
(http://git.ideasonboard.com/renesas/kms-tests.git).  No failure or
change in behaviour has been noticed.

Kieran Bingham (8):
  media: vsp1: drm: Split vsp1_du_setup_lif()
  drm: rcar-du: Convert to the new VSP atomic API
  media: vsp1: drm: Remove vsp1_du_setup_lif()
  drm: rcar-du: Handle CRTC standby from commit tail handler
  drm: rcar-du: Handle CRTC configuration from commit tail handler
  drm: rcar-du: Provide for_each_group helper
  drm: rcar-du: Create a group state object
  drm: rcar-du: Perform group setup from the atomic tail handler

Laurent Pinchart (2):
  media: vsp1: drm: Don't configure hardware when the pipeline is
disabled
  drm: rcar-du: Centralise routing configuration in commit tail handler

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 160 ++
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 390 +++-
 drivers/gpu/drm/rcar-du/rcar_du_group.h |  44 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  63 ++--
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  10 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  20 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |   3 +
 drivers/media/platform/vsp1/vsp1_drm.c  | 188 
 drivers/media/platform/vsp1/vsp1_drm.h  |   2 +
 include/media/vsp1.h|  25 +-
 12 files changed, 644 insertions(+), 276 deletions(-)

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 01/10] media: vsp1: drm: Split vsp1_du_setup_lif()

[Kieran Bingham]

Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
API. The existing vsp1_du_setup_lif() API call is maintained as it is
still used from the DU.

Reviewed-by: Ulrich Hecht 
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v3:
- Minor formatting updates to fix checkpatch.pl --strict
- Spelling correction.

Changes since v2:

- Minor formatting changes
- Fix NULL pointer dereference in vsp1_du_setup_lif()

 drivers/media/platform/vsp1/vsp1_drm.c | 219 ++---
 include/media/vsp1.h   |  31 +++-
 2 files changed, 187 insertions(+), 63 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 86d5e3f4b1ff..2bac80014bf4 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -616,10 +616,10 @@ int vsp1_du_init(struct device *dev)
 EXPORT_SYMBOL_GPL(vsp1_du_init);
 
 /**
- * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
+ * vsp1_du_atomic_modeset - Configure the mode as part of an atomic update
  * @dev: the VSP device
  * @pipe_index: the DRM pipeline index
- * @cfg: the LIF configuration
+ * @cfg: the mode configuration
  *
  * Configure the output part of VSP DRM pipeline for the given frame @cfg.width
  * and @cfg.height. This sets up formats on the BRx source pad, the WPF sink 
and
@@ -636,14 +636,12 @@ EXPORT_SYMBOL_GPL(vsp1_du_init);
  *
  * Return 0 on success or a negative error code on failure.
  */
-int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
- const struct vsp1_du_lif_config *cfg)
+int vsp1_du_atomic_modeset(struct device *dev, unsigned int pipe_index,
+  const struct vsp1_du_modeset_config *cfg)
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe;
struct vsp1_pipeline *pipe;
-   unsigned long flags;
-   unsigned int i;
int ret;
 
if (pipe_index >= vsp1->info->lif_count)
@@ -652,60 +650,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe = >drm->pipe[pipe_index];
pipe = _pipe->pipe;
 
-   if (!cfg) {
-   struct vsp1_brx *brx;
-
-   mutex_lock(>drm->lock);
-
-   brx = to_brx(>brx->subdev);
-
-   /*
-* NULL configuration means the CRTC is being disabled, stop
-* the pipeline and turn the light off.
-*/
-   ret = vsp1_pipeline_stop(pipe);
-   if (ret == -ETIMEDOUT)
-   dev_err(vsp1->dev, "DRM pipeline stop timeout\n");
-
-   for (i = 0; i < ARRAY_SIZE(pipe->inputs); ++i) {
-   struct vsp1_rwpf *rpf = pipe->inputs[i];
-
-   if (!rpf)
-   continue;
-
-   /*
-* Remove the RPF from the pipe and the list of BRx
-* inputs.
-*/
-   WARN_ON(!rpf->entity.pipe);
-   rpf->entity.pipe = NULL;
-   list_del(>entity.list_pipe);
-   pipe->inputs[i] = NULL;
-
-   brx->inputs[rpf->brx_input].rpf = NULL;
-   }
-
-   drm_pipe->du_complete = NULL;
-   pipe->num_inputs = 0;
-
-   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
-   __func__, pipe->lif->index,
-   BRX_NAME(pipe->brx));
-
-   list_del(>brx->list_pipe);
-   pipe->brx->pipe = NULL;
-   pipe->brx = NULL;
-
-   mutex_unlock(>drm->lock);
-
-   vsp1_dlm_reset(pipe->output->dlm);
-   vsp1_device_put(vsp1);
-
-   dev_dbg(vsp1->dev, "%s: pipeline disabled\n", __func__);
-
-   return 0;
-   }
-
drm_pipe->width = cfg->width;
drm_pipe->height = cfg->height;
pipe->interlaced = cfg->interlaced;
@@ -722,8 +666,43 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
goto unlock;
 
ret = vsp1_du_pipeline_setup_output(vsp1, pipe);
-   if (ret < 0)
-   goto unlock;
+
+unlock:
+   mutex_unlock(>drm->lock);
+
+   return ret;
+}
+
+/**
+ * vsp1_du_atomic_enable - Enable and start a DU pipeline
+ * @dev: the VSP device
+ * @pipe_index: the DRM pipeline index
+ * @cfg: the enablement configuration
+ *
+ * The @pipe_index argument selects which DRM pipeline to enable. The number of
+ * available pipelines depends on the VSP instance.
+ *
+ * The configuration passes a callback function to register notification of
+ * frame completion events.
+ *
+ * Return 0 on success or a negative error code on failure.
+ */
+int vsp1_du_atomic_enable(struct device *dev, unsigned int pipe_index,
+ 

Re: fbcon: remove soft scrollback code (missing Doc. patch)

[Daniel Vetter]

On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven  wrote:
>
> Hi Daniel,
>
> CC linux-fbdev
>
> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter  wrote:
> > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> >  wrote:
> > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi  wrote:
> > > > > Could we pause this madness? Scrollback is still useful. I needed it
> > > > > today... it was too small, so command results I was looking for
> > > > > already scrolled away, but... life will be really painful with 0
> > > > > scrollback.
> > > >
> > > > > You'll need it, too... as soon as you get oops and will want to see
> > > > > errors just prior to that oops.
> > > >
> > > > > If it means I get to maintain it... I'm not happy about it but that's
> > > > > better than no scrollback.
> > > >
> > > > Amen!  What self respecting admin installs a gui on servers?  What do we
> > > > have to do to get this back in?  What was so buggy with this code that
> > > > it needed to be removed?  Why was it such a burden to just leave it be?
> > >
> > > It really was buggy, with security implications. And we have no 
> > > maintainers.
> > >
> > > So the scroll-back code can't come back until we have a maintainer and
> > > a cleaner and simpler implementation.
> > >
> > > And no, maintaining it really doesn't mean "just get it back to the
> > > old broken state".
> > >
> > > So far I haven't actually seen any patches, which means that it's not
> > > coming back.
> > >
> > > The good news? If you have an actual text VGA console, that should
> > > still work just fine.
>
> IIRC, all of this was written for systems lacking VGA text consoles
> in the first place...
>
> > Also on anything that is remotely modern (i.e. runs a drm kernel
> > modesetting driver undearneath the fbdev/fbcon stack) there's a pile
> > more issues on top of just the scrollback/fbcon code being a mess.
>
> Would it help to remove DRM_FBDEV_EMULATION (instead)?

It's a problem with the hardware. "Write some registers and done"
isn't how display blocks work nowadays. So your proposal amounts to
"no fbdev/fbcon for anything modern-ish".

Also I said "a pile more", most of the issues in fbcon/fbdev code
apply for all drivers.

> > Specifically the locking is somewhere between yolo and outright
> > deadlocks. This holds even more so if the use case here is "I want
> > scrollback for an oops". There's rough sketches for how it could be
> > solved, but it's all very tricky work.
>
> When an oops happens, all bets are off.  At that point, all information
> you can extract from the system is valuable, and additional locking
> issues are moot.

Except the first oops then scrolls aways because it's getting buried
under further fail. Your locking needs to be minimally good enough to
not make the situation worse.
-Daniel

> > Also adding dri-devel since defacto that's the only place where
> > display people hang out nowadays.
>
> Please keep on CCing linux-fbdev, especially for patches removing
> fbdev features.
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Christian König]

Am 14.01.21 um 16:40 schrieb Daniel Vetter:

[SNIP]

So I think we have to somehow solve this in the kernel or we will go in
circles all the time.


So from that pov I think the kernel should at most deal with an
hmm_fence for cross-process communication and maybe some standard wait
primitives (for userspace to use, not for the kernel).

The only use case this would forbid is using page faults for legacy
implicit/explicit dma_fence synced workloads, and I think that's
perfectly ok to not allow. Especially since the motivation here for
all this is compute, and compute doesn't pass around dma_fences
anyway.

As Alex said we will rather soon see this for gfx as well and we most
likely will see combinations of old dma_fence based integrated graphics
with new dedicated GPUs.

So I don't think we can say we reduce the problem to compute and don't
support anything else.

I'm not against pagefaults for gfx, just in pushing the magic into the
kernel. I don't think that works, because it means we add stall points
where usespace, especially vk userspace, really doesn't want it. So
same way like timeline syncobj, we need to push the compat work into
userspace.

There's going to be a few stall points:
- fully new stack, we wait for the userspace fence in the atomic
commit path (which we can, if we're really careful, since we pin all
buffers upfront and so there's no risk)
- userspace fencing gpu in the client, compositor protocol can pass
around userspace fences, but the compositor still uses dma_fence for
itself. There's some stalling in the compositor, which it does already
anyway when it's collecting new frames from clients
- userspace fencing gpu in the client, but no compositor protocol: We
wait in the swapchain, but in a separate thread so that nothing blocks
that shouldn't block

If we instead go with "magic waits in the kernel behind userspace's
back", like what your item 6 would imply, then we're not really
solving anything.

For actual implementation I think the best would be an extension of
drm_syncobj. Those already have at least conceptually future/infinite
fences, and we already have fd passing, so "just" need some protocol
to pass them around. Plus we could use the same uapi for timeline
syncobj using dma_fence as for hmm_fence, so also easier to transition
for userspace to the new world since don't need the new hw capability
to roll out the new uapi and protocols.

That's not that hard to roll out, and technically a lot better than
hacking up dma_resv and hoping we don't end up stalling in wrong
places, which sounds very "k" to me :-)


Yeah, that's what I totally agree upon :)

My idea was just the last resort since we are mixing userspace sync and 
memory management so creative here.


Stalling in userspace will probably get some push back as well, but 
maybe not as much as stalling in the kernel.


Ok if we can at least remove implicit sync from the picture then the 
question remains how do we integrate HMM into drm_syncobj then?


Regards,
Christian.



Cheers, Daniel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fbcon: remove soft scrollback code (missing Doc. patch)

[Geert Uytterhoeven]

Hi Daniel,

CC linux-fbdev

On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter  wrote:
> On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
>  wrote:
> > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi  wrote:
> > > > Could we pause this madness? Scrollback is still useful. I needed it
> > > > today... it was too small, so command results I was looking for
> > > > already scrolled away, but... life will be really painful with 0
> > > > scrollback.
> > >
> > > > You'll need it, too... as soon as you get oops and will want to see
> > > > errors just prior to that oops.
> > >
> > > > If it means I get to maintain it... I'm not happy about it but that's
> > > > better than no scrollback.
> > >
> > > Amen!  What self respecting admin installs a gui on servers?  What do we
> > > have to do to get this back in?  What was so buggy with this code that
> > > it needed to be removed?  Why was it such a burden to just leave it be?
> >
> > It really was buggy, with security implications. And we have no maintainers.
> >
> > So the scroll-back code can't come back until we have a maintainer and
> > a cleaner and simpler implementation.
> >
> > And no, maintaining it really doesn't mean "just get it back to the
> > old broken state".
> >
> > So far I haven't actually seen any patches, which means that it's not
> > coming back.
> >
> > The good news? If you have an actual text VGA console, that should
> > still work just fine.

IIRC, all of this was written for systems lacking VGA text consoles
in the first place...

> Also on anything that is remotely modern (i.e. runs a drm kernel
> modesetting driver undearneath the fbdev/fbcon stack) there's a pile
> more issues on top of just the scrollback/fbcon code being a mess.

Would it help to remove DRM_FBDEV_EMULATION (instead)?

> Specifically the locking is somewhere between yolo and outright
> deadlocks. This holds even more so if the use case here is "I want
> scrollback for an oops". There's rough sketches for how it could be
> solved, but it's all very tricky work.

When an oops happens, all bets are off.  At that point, all information
you can extract from the system is valuable, and additional locking
issues are moot.

> Also adding dri-devel since defacto that's the only place where
> display people hang out nowadays.

Please keep on CCing linux-fbdev, especially for patches removing
fbdev features.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/vmwgfx: Drop svga_lock

[Roland Scheidegger]

Hi,

looking at it, seems alright. Not sure why the lock was supposedly
needed, maybe it was at some point (it seems like all usage of this lock
was introduced way back in 2015, commit 153b3d5b037ee).

For the series: Reviewed-by: Roland Scheidegger 

Roland

Am 12.01.21 um 09:49 schrieb Daniel Vetter:
> Hi Roland,
> 
> Hopefully you had a nice start into the new year! Ping for some
> review/testing on this series.
> 
> Thanks, Daniel
> 
> On Fri, Dec 11, 2020 at 5:29 PM Daniel Vetter  wrote:
>>
>> This isn't actually protecting anything becuase:
>> - when running, ttm_resource_manager->use_type is protected through
>>   vmw_private->reservation_semaphore against concurrent execbuf or
>>   well anything else that might evict or reserve buffers
>> - during suspend/resume there's nothing else running, hence
>>   vmw_pm_freeze and vmw_pm_restore do not need to take the same lock.
>> - this also holds for the SVGA_REG_ENABLE register write
>>
>> Hence it is safe to just remove that spinlock.
>>
>> Signed-off-by: Daniel Vetter 
>> Cc: VMware Graphics 
>> Cc: Roland Scheidegger 
>> ---
>>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
>>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  1 -
>>  2 files changed, 1 insertion(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> index 0008be02d31c..204f7a1830f0 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> @@ -672,7 +672,6 @@ static int vmw_driver_load(struct drm_device *dev, 
>> unsigned long chipset)
>> spin_lock_init(_priv->hw_lock);
>> spin_lock_init(_priv->waiter_lock);
>> spin_lock_init(_priv->cap_lock);
>> -   spin_lock_init(_priv->svga_lock);
>> spin_lock_init(_priv->cursor_lock);
>>
>> for (i = vmw_res_context; i < vmw_res_max; ++i) {
>> @@ -1189,12 +1188,10 @@ static void __vmw_svga_enable(struct vmw_private 
>> *dev_priv)
>>  {
>> struct ttm_resource_manager *man = ttm_manager_type(_priv->bdev, 
>> TTM_PL_VRAM);
>>
>> -   spin_lock(_priv->svga_lock);
>> if (!ttm_resource_manager_used(man)) {
>> vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE);
>> ttm_resource_manager_set_used(man, true);
>> }
>> -   spin_unlock(_priv->svga_lock);
>>  }
>>
>>  /**
>> @@ -1220,14 +1217,12 @@ static void __vmw_svga_disable(struct vmw_private 
>> *dev_priv)
>>  {
>> struct ttm_resource_manager *man = ttm_manager_type(_priv->bdev, 
>> TTM_PL_VRAM);
>>
>> -   spin_lock(_priv->svga_lock);
>> if (ttm_resource_manager_used(man)) {
>> ttm_resource_manager_set_used(man, false);
>> vmw_write(dev_priv, SVGA_REG_ENABLE,
>>   SVGA_REG_ENABLE_HIDE |
>>   SVGA_REG_ENABLE_ENABLE);
>> }
>> -   spin_unlock(_priv->svga_lock);
>>  }
>>
>>  /**
>> @@ -1254,17 +1249,14 @@ void vmw_svga_disable(struct vmw_private *dev_priv)
>>  */
>> vmw_kms_lost_device(dev_priv->dev);
>> ttm_write_lock(_priv->reservation_sem, false);
>> -   spin_lock(_priv->svga_lock);
>> if (ttm_resource_manager_used(man)) {
>> ttm_resource_manager_set_used(man, false);
>> -   spin_unlock(_priv->svga_lock);
>> if (ttm_resource_manager_evict_all(_priv->bdev, man))
>> DRM_ERROR("Failed evicting VRAM buffers.\n");
>> vmw_write(dev_priv, SVGA_REG_ENABLE,
>>   SVGA_REG_ENABLE_HIDE |
>>   SVGA_REG_ENABLE_ENABLE);
>> -   } else
>> -   spin_unlock(_priv->svga_lock);
>> +   }
>> ttm_write_unlock(_priv->reservation_sem);
>>  }
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> index 5b9a28157dd3..715f2bfee08a 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> @@ -596,7 +596,6 @@ struct vmw_private {
>>
>> bool stealth;
>> bool enable_fb;
>> -   spinlock_t svga_lock;
>>
>> /**
>>  * PM management.
>> --
>> 2.29.2
>>
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Daniel Vetter]

On Thu, Jan 14, 2021 at 4:08 PM Christian König
 wrote:
> Am 14.01.21 um 15:23 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 3:13 PM Christian König
> >  wrote:
> >> Am 14.01.21 um 14:57 schrieb Daniel Vetter:
> >>> On Thu, Jan 14, 2021 at 2:37 PM Christian König
> >>>  wrote:
>  Am 14.01.21 um 12:52 schrieb Daniel Vetter:
> > [SNIP]
> >>> I had a new idea, i wanted to think more about it but have not yet,
> >>> anyway here it is. Adding a new callback to dma fence which ask the
> >>> question can it dead lock ? Any time a GPU driver has pending page
> >>> fault (ie something calling into the mm) it answer yes, otherwise
> >>> no. The GPU shrinker would ask the question before waiting on any
> >>> dma-fence and back of if it gets yes. Shrinker can still try many
> >>> dma buf object for which it does not get a yes on associated fence.
> >>>
> >>> This does not solve the mmu notifier case, for this you would just
> >>> invalidate the gem userptr object (with a flag but not releasing the
> >>> page refcount) but you would not wait for the GPU (ie no dma fence
> >>> wait in that code path anymore). The userptr API never really made
> >>> the contract that it will always be in sync with the mm view of the
> >>> world so if different page get remapped to same virtual address
> >>> while GPU is still working with the old pages it should not be an
> >>> issue (it would not be in our usage of userptr for compositor and
> >>> what not).
> >> The current working idea in my mind goes into a similar direction.
> >>
> >> But instead of a callback I'm adding a complete new class of HMM 
> >> fences.
> >>
> >> Waiting in the MMU notfier, scheduler, TTM etc etc is only allowed for
> >> the dma_fences and HMM fences are ignored in container objects.
> >>
> >> When you handle an implicit or explicit synchronization request from
> >> userspace you need to block for HMM fences to complete before taking 
> >> any
> >> resource locks.
> > Isnt' that what I call gang scheduling? I.e. you either run in HMM
> > mode, or in legacy fencing mode (whether implicit or explicit doesn't
> > really matter I think). By forcing that split we avoid the problem,
> > but it means occasionally full stalls on mixed workloads.
> >
> > But that's not what Jerome wants (afaiui at least), I think his idea
> > is to track the reverse dependencies of all the fences floating
> > around, and then skip evicting an object if you have to wait for any
> > fence that is problematic for the current calling context. And I don't
> > think that's very feasible in practice.
> >
> > So what kind of hmm fences do you have in mind here?
>  It's a bit more relaxed than your gang schedule.
> 
>  See the requirements are as follow:
> 
>  1. dma_fences never depend on hmm_fences.
>  2. hmm_fences can never preempt dma_fences.
>  3. dma_fences must be able to preempt hmm_fences or we always reserve
>  enough hardware resources (CUs) to guarantee forward progress of 
>  dma_fences.
> 
>  Critical sections are MMU notifiers, page faults, GPU schedulers and
>  dma_reservation object locks.
> 
>  4. It is valid to wait for a dma_fences in critical sections.
>  5. It is not valid to wait for hmm_fences in critical sections.
> 
>  Fence creation either happens during command submission or by adding
>  something like a barrier or signal command to your userspace queue.
> 
>  6. If we have an hmm_fence as implicit or explicit dependency for
>  creating a dma_fence we must wait for that before taking any locks or
>  reserving resources.
>  7. If we have a dma_fence as implicit or explicit dependency for
>  creating an hmm_fence we can wait later on. So busy waiting or special
>  WAIT hardware commands are valid.
> 
>  This prevents hard cuts, e.g. can mix hmm_fences and dma_fences at the
>  same time on the hardware.
> 
>  In other words we can have a high priority gfx queue running jobs based
>  on dma_fences and a low priority compute queue running jobs based on
>  hmm_fences.
> 
>  Only when we switch from hmm_fence to dma_fence we need to block the
>  submission until all the necessary resources (both memory as well as
>  CUs) are available.
> 
>  This is somewhat an extension to your gang submit idea.
> >>> Either I'm missing something, or this is just exactly what we
> >>> documented already with userspace fences in general, and how you can't
> >>> have a dma_fence depend upon a userspace (or hmm_fence).
> >>>
> >>> My gang scheduling idea is really just an alternative for what you
> >>> have listed as item 3 above. Instead of requiring preempt or requiring
> >>> guaranteed forward progress of some other sorts we flush out any
> >>> pending dma_fence 

Re: [PATCH 1/3] drm/vmwgfx: Drop svga_lock

[Zack Rusin]

Looks good. Thanks!

Reviewed-by: Zack Rusin 

> On Jan 12, 2021, at 03:49, Daniel Vetter  wrote:
> 
> Hi Roland,
> 
> Hopefully you had a nice start into the new year! Ping for some
> review/testing on this series.
> 
> Thanks, Daniel
> 
> On Fri, Dec 11, 2020 at 5:29 PM Daniel Vetter  wrote:
>> 
>> This isn't actually protecting anything becuase:
>> - when running, ttm_resource_manager->use_type is protected through
>>  vmw_private->reservation_semaphore against concurrent execbuf or
>>  well anything else that might evict or reserve buffers
>> - during suspend/resume there's nothing else running, hence
>>  vmw_pm_freeze and vmw_pm_restore do not need to take the same lock.
>> - this also holds for the SVGA_REG_ENABLE register write
>> 
>> Hence it is safe to just remove that spinlock.
>> 
>> Signed-off-by: Daniel Vetter 
>> Cc: VMware Graphics 
>> Cc: Roland Scheidegger 
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  1 -
>> 2 files changed, 1 insertion(+), 10 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> index 0008be02d31c..204f7a1830f0 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> @@ -672,7 +672,6 @@ static int vmw_driver_load(struct drm_device *dev, 
>> unsigned long chipset)
>>spin_lock_init(_priv->hw_lock);
>>spin_lock_init(_priv->waiter_lock);
>>spin_lock_init(_priv->cap_lock);
>> -   spin_lock_init(_priv->svga_lock);
>>spin_lock_init(_priv->cursor_lock);
>> 
>>for (i = vmw_res_context; i < vmw_res_max; ++i) {
>> @@ -1189,12 +1188,10 @@ static void __vmw_svga_enable(struct vmw_private 
>> *dev_priv)
>> {
>>struct ttm_resource_manager *man = ttm_manager_type(_priv->bdev, 
>> TTM_PL_VRAM);
>> 
>> -   spin_lock(_priv->svga_lock);
>>if (!ttm_resource_manager_used(man)) {
>>vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE);
>>ttm_resource_manager_set_used(man, true);
>>}
>> -   spin_unlock(_priv->svga_lock);
>> }
>> 
>> /**
>> @@ -1220,14 +1217,12 @@ static void __vmw_svga_disable(struct vmw_private 
>> *dev_priv)
>> {
>>struct ttm_resource_manager *man = ttm_manager_type(_priv->bdev, 
>> TTM_PL_VRAM);
>> 
>> -   spin_lock(_priv->svga_lock);
>>if (ttm_resource_manager_used(man)) {
>>ttm_resource_manager_set_used(man, false);
>>vmw_write(dev_priv, SVGA_REG_ENABLE,
>>  SVGA_REG_ENABLE_HIDE |
>>  SVGA_REG_ENABLE_ENABLE);
>>}
>> -   spin_unlock(_priv->svga_lock);
>> }
>> 
>> /**
>> @@ -1254,17 +1249,14 @@ void vmw_svga_disable(struct vmw_private *dev_priv)
>> */
>>vmw_kms_lost_device(dev_priv->dev);
>>ttm_write_lock(_priv->reservation_sem, false);
>> -   spin_lock(_priv->svga_lock);
>>if (ttm_resource_manager_used(man)) {
>>ttm_resource_manager_set_used(man, false);
>> -   spin_unlock(_priv->svga_lock);
>>if (ttm_resource_manager_evict_all(_priv->bdev, man))
>>DRM_ERROR("Failed evicting VRAM buffers.\n");
>>vmw_write(dev_priv, SVGA_REG_ENABLE,
>>  SVGA_REG_ENABLE_HIDE |
>>  SVGA_REG_ENABLE_ENABLE);
>> -   } else
>> -   spin_unlock(_priv->svga_lock);
>> +   }
>>ttm_write_unlock(_priv->reservation_sem);
>> }
>> 
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> index 5b9a28157dd3..715f2bfee08a 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> @@ -596,7 +596,6 @@ struct vmw_private {
>> 
>>bool stealth;
>>bool enable_fb;
>> -   spinlock_t svga_lock;
>> 
>>/**
>> * PM management.
>> --
>> 2.29.2
>> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2Fdata=04%7C01%7Czackr%40vmware.com%7C87dbfc543ea847f8e13808d8b6d6f273%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637460381607335152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TttOwJzt5g8Sk45jqfa9qFkVCQrslhOmdjDyKQJzkIk%3Dreserved=0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-gt-next

[Joonas Lahtinen]

Hi Dave & Daniel,

Here is the first PR for v5.12. There are quite a few patches
accumulated after the holidays as usual:

Most importantly there are fixes to the clear residual security
mitigations to avoid GPU hangs caused by them. Further there is
option to allow the user to decide to disable such mitigations
similar to CPU side (i915.mitigations=auto,!residuals), if they
are an expert user and wish to do so. Of course, usual caveats
apply to disabling any security mitigations!

For Tigerlake, a fix to reduce the likelihood of DMAR errors when
IOMMU is enabled (MTBF bump from 10 secs to hours) and correction
to detecting the device stepping. Addition of W/As for DG1 and TGL.

Tuning the RPS algorithm further to limit to RPe on parking an
engine. Plenty of refactoring, cleanups and optimizing code in
preparation of upcoming series. The usual amount of selftest and
documentation fixes.

Then there are 3 other fixes for user reported/visible bugs;
GPU hang due to wrong MOCS caching for index used by HW, false
error message for case where GuC firmware doesn't load on first
instance of the retry-loop and supplementing the GuC firmware
table for Cometlake SKUs.

Fixes for pre-emption on Gen8-era devices. Build and runtime
fixes for 32-bit machines.

Regards, Joonas

PS. After you merge this, I will proceed to backmerge drm-next so
that we can have a common topic branches for din and dign as
requested by Jani and Rodrigo.

***

drm-intel-gt-next-2021-01-14:

UAPI Changes:
- Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko)

  Avoid relying on last item ABI marker in i915_drm.h, add a
  comment to mark as deprecated.

Driver Changes:

- Restore clear residuals security mitigations for Ivybridge and
  Baytrail (Chris)
- Close #1858: Allow sysadmin to choose applied GPU security mitigations
  through i915.mitigations=... similar to CPU (Chris)
- Fix for #2024: GPU hangs on HSW GT1 (Chris)
- Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville)
- Fix for #2797: False positive GuC loading error message (Chris)
- Fix for #2859: Missing GuC firmware for older Cometlakes (Chris)
- Lessen probability of GPU hang due to DMAR faults [reason 7,
  next page table ptr is invalid] on Tigerlake (Chris)
- Fix REVID macros for TGL to fetch correct stepping (Aditya)
- Limit frequency drop to RPe on parking (Chris, Edward)
- Limit W/A 1406941453 to TGL, RKL and DG1 (Swathi)
- Make W/A 22010271021 permanent on DG1 (Lucas)
- Implement W/A 16011163337 to prevent a HS/DS hang on DG1 (Swathi)
- Only disable preemption on gen8 render engines (Chris)
- Disable arbitration around Braswell's PDP updates (Chris)
- Disable arbitration on no-preempt requests (Chris)
- Check for arbitration after writing start seqno before busywaiting (Chris)
- Retain default context state across shrinking (Venkata, CQ)
- Fix mismatch between misplaced vma check and vma insert for 32-bit
  addressing userspaces (Chris, CQ)
- Propagate error for vmap() failure instead kernel NULL deref (Chris)
- Propagate error from cancelled submit due to context closure
  immediately (Chris)
- Fix RCU race on HWSP tracking per request (Chris)
- Clear CMD parser shadow and GPU reloc batches (Matt A)

- Populate logical context during first pin (Maarten)
- Optimistically prune dma-resv from the shrinker (Chris)
- Fix for virtual engine ownership race (Chris)
- Remove timeslice suppression to restore fairness for virtual engines (Chris)
- Rearrange IVB/HSW workarounds properly between GT and engine (Chris)
- Taint the reset mutex with the shrinker (Chris)
- Replace direct submit with direct call to tasklet (Chris)
- Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris)
- Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko)
- Use raw clock for RC6 time estimation in PMU (Tvrtko)
- Differentiate OOM failures from invalid map types (Chris)
- Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris)
- Ignore repeated attempts to suspend request flow across reset (Chris)
- Remove livelock from "do_idle_maps" VT-d W/A (Chris)
- Cancel the preemption timeout early in case engine reset fails (Chris)
- Code flow optimization in the scheduling code (Chris)
- Clear the execlists timers upon reset (Chris)
- Drain the breadcrumbs just once (Chris, Matt A)
- Track the overall GT awake/busy time (Chris)
- Tweak submission tasklet flushing to avoid starvation (Chris)
- Track timelines created using the HWSP to restore on resume (Chris)
- Use cmpxchg64 for 32b compatilibity for active tracking (Chris)
- Prefer recycling an idle GGTT fence to avoid GPU wait (Chris)

- Restructure GT code organization for clearer split between GuC
  and execlists (Chris, Daniele, John, Matt A)
- Remove GuC code that will remain unused by new interfaces (Matt B)
- Restructure the CS timestamp clocks code to local to GT (Chris)
- Fix error return paths in perf code (Zhang)
- Replace idr_init() by idr_init_base() in perf (Deepak)
- Fix shmem_pin_map error 

Re: [PATCH 2/2] drm/cma-helper: Implement mmap as GEM CMA object functions

[Thomas Zimmermann]

Hi

Am 14.01.21 um 15:34 schrieb Kieran Bingham:

Hi Thomas,

On 14/01/2021 13:26, Thomas Zimmermann wrote:

Hi Kieran

Am 14.01.21 um 13:51 schrieb Kieran Bingham:

Hi Thomas,

On 23/11/2020 11:56, Thomas Zimmermann wrote:

The new GEM object function drm_gem_cma_mmap() sets the VMA flags
and offset as in the old implementation and immediately maps in the
buffer's memory pages.

Changing CMA helpers to use the GEM object function allows for the
removal of the special implementations for mmap and gem_prime_mmap
callbacks. The regular functions drm_gem_mmap() and drm_gem_prime_mmap()
are now used.


I've encountered a memory leak regression in our Renesas R-Car DU tests,
and git bisection has led me to this patch (as commit f5ca8eb6f9).

Running the tests sequentially, while grepping /proc/meminfo for Cma, it
is evident that CMA memory is not released, until exhausted and the
allocations fail (seen in [0]) shown by the error report:


  self.fbs.append(pykms.DumbFramebuffer(self.card, mode.hdisplay,
mode.vdisplay, "XR24"))
ValueError: DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory



Failing tests at f5ca8eb6f9 can be seen at [0], while the tests pass
successfully [1] on the commit previous to that (bc2532ab7c2):

Reverting f5ca8eb6f9 also produces a successful pass [2]

   [0] https://paste.ubuntu.com/p/VjPGPgswxR/ # Failed at f5ca8eb6f9
   [1] https://paste.ubuntu.com/p/78RRp2WpNR/ # Success at bc2532ab7c2
   [2] https://paste.ubuntu.com/p/qJKjZZN2pt/ # Success with revert


I don't believe we handle mmap specially in the RCar-DU driver, so I
wonder if this issue has hit anyone else as well?

Any ideas of a repair without a revert ? Or do we just need to submit a
revert?


I think we might not be setting the VMA ops and therefore not finalize
the BO correctly. Could you please apply the attched (quick-and-dirty)
patch and try again?


Thanks for the quick response.

I can confirm the quick-and-dirty patch resolves the issue:
   https://paste.ubuntu.com/p/sKDp3dNvwV/

You can add a
Tested-by: Kieran Bingham 


Great! If you don't mind, I'd also add you in the Reported-by tag.



if it stays like that, but I suspect there might be a better place to
initialise the ops rather than in the mmap call itself.


I think that's the fix, basically. We could put such a line as a 
fall-back somewhere into the DRM core code. But I don't know if this 
really works with all drivers. Maybe there's one that requires vm_ops to 
be NULL.


Thanks for reporting this issue and testing quickly.

Best regards
Thomas



Happy to do further testing as required.

--
Regards

Kieran



Best regards
Thomas



I've yet to fully understand the implications of the patch below.

Thanks
--
Regards

Kieran




Signed-off-by: Thomas Zimmermann 
---
   drivers/gpu/drm/drm_file.c   |   3 +-
   drivers/gpu/drm/drm_gem_cma_helper.c | 121 +--
   drivers/gpu/drm/pl111/pl111_drv.c    |   2 +-
   drivers/gpu/drm/vc4/vc4_bo.c |   2 +-
   include/drm/drm_gem_cma_helper.h |  10 +--
   5 files changed, 44 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b50380fa80ce..80886d50d0f1 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -113,8 +113,7 @@ bool drm_dev_needs_global_mutex(struct drm_device
*dev)
    * The memory mapping implementation will vary depending on how the
driver
    * manages memory. Legacy drivers will use the deprecated
drm_legacy_mmap()
    * function, modern drivers should use one of the provided
memory-manager
- * specific implementations. For GEM-based drivers this is
drm_gem_mmap(), and
- * for drivers which use the CMA GEM helpers it's drm_gem_cma_mmap().
+ * specific implementations. For GEM-based drivers this is
drm_gem_mmap().
    *
    * No other file operations are supported by the DRM userspace API.
Overall the
    * following is an example _operations structure::
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 6a4ef335ebc9..7942cf05cd93 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs
drm_gem_cma_default_funcs = {
   .print_info = drm_gem_cma_print_info,
   .get_sg_table = drm_gem_cma_get_sg_table,
   .vmap = drm_gem_cma_vmap,
+    .mmap = drm_gem_cma_mmap,
   .vm_ops = _gem_cma_vm_ops,
   };
   @@ -277,62 +278,6 @@ const struct vm_operations_struct
drm_gem_cma_vm_ops = {
   };
   EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
   -static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
-    struct vm_area_struct *vma)
-{
-    int ret;
-
-    /*
- * Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and
set the
- * vm_pgoff (used as a fake buffer offset by DRM) to 0 as we
want to map
- * the whole buffer.
- */
-    vma->vm_flags &= ~VM_PFNMAP;
-    vma->vm_pgoff = 0;
-
-    ret = 

Re: [PATCH v10 4/4] drm/panfrost: Add mt8183-mali compatible string

[Steven Price]

On 13/01/2021 06:07, Nicolas Boichat wrote:

Add support for MT8183's G72 Bifrost.

Signed-off-by: Nicolas Boichat 
Reviewed-by: Tomeu Vizoso 


LGTM

Reviewed-by: Steven Price 


---

(no changes since v7)

Changes in v7:
  - Fix GPU ID in commit message

Changes in v6:
  - Context conflicts, reflow the code.
  - Use ARRAY_SIZE for power domains too.

Changes in v5:
  - Change power domain name from 2d to core2.

Changes in v4:
  - Add power domain names.

Changes in v3:
  - Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.

  drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..ca07098a6141 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
.vendor_quirk = panfrost_gpu_amlogic_quirk,
  };
  
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };

+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" 
};
+static const struct panfrost_compatible mediatek_mt8183_data = {
+   .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+   .supply_names = mediatek_mt8183_supplies,
+   .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
+   .pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
  static const struct of_device_id dt_match[] = {
/* Set first to probe before the generic compatibles */
{ .compatible = "amlogic,meson-gxm-mali",
@@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = _data, },
{ .compatible = "arm,mali-t880", .data = _data, },
{ .compatible = "arm,mali-bifrost", .data = _data, },
+   { .compatible = "mediatek,mt8183-mali", .data = _mt8183_data },
{}
  };
  MODULE_DEVICE_TABLE(of, dt_match);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1

[Steven Price]

On 13/01/2021 06:07, Nicolas Boichat wrote:

GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling for devfreq, for 2 reasons:
  1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
 does not support multiple regulators, so we'll need custom
 handlers.
  2. Generally, platforms with 2 regulators have platform-specific
 constraints on how the voltages should be set (e.g.
 minimum/maximum voltage difference between them), so we
 should not just create generic handlers that simply
 change the voltages without taking care of those constraints.

Disable devfreq for now on those GPUs.

Signed-off-by: Nicolas Boichat 
Reviewed-by: Tomeu Vizoso 


Thanks for the clarification in the commit message.

Reviewed-by: Steven Price 


---

(no changes since v9)

Changes in v9:
  - Explain why devfreq needs to be disabled for GPUs with >1
regulators.

Changes in v8:
  - Use DRM_DEV_INFO instead of ERROR

Changes in v7:
  - Fix GPU ID in commit message

Changes in v6:
  - New change

  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index f44d28fad085..812cfecdee3b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -92,6 +92,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
  
+	if (pfdev->comp->num_supplies > 1) {

+   /*
+* GPUs with more than 1 supply require platform-specific 
handling:
+* continue without devfreq
+*/
+   DRM_DEV_INFO(dev, "More than 1 supply is not supported yet\n");
+   return 0;
+   }
+
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
  pfdev->comp->num_supplies);
if (IS_ERR(opp_table)) {



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HMM fence (was Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD)

[Christian König]

Am 14.01.21 um 15:23 schrieb Daniel Vetter:

On Thu, Jan 14, 2021 at 3:13 PM Christian König
 wrote:

Am 14.01.21 um 14:57 schrieb Daniel Vetter:

On Thu, Jan 14, 2021 at 2:37 PM Christian König
 wrote:

Am 14.01.21 um 12:52 schrieb Daniel Vetter:

[SNIP]

I had a new idea, i wanted to think more about it but have not yet,
anyway here it is. Adding a new callback to dma fence which ask the
question can it dead lock ? Any time a GPU driver has pending page
fault (ie something calling into the mm) it answer yes, otherwise
no. The GPU shrinker would ask the question before waiting on any
dma-fence and back of if it gets yes. Shrinker can still try many
dma buf object for which it does not get a yes on associated fence.

This does not solve the mmu notifier case, for this you would just
invalidate the gem userptr object (with a flag but not releasing the
page refcount) but you would not wait for the GPU (ie no dma fence
wait in that code path anymore). The userptr API never really made
the contract that it will always be in sync with the mm view of the
world so if different page get remapped to same virtual address
while GPU is still working with the old pages it should not be an
issue (it would not be in our usage of userptr for compositor and
what not).

The current working idea in my mind goes into a similar direction.

But instead of a callback I'm adding a complete new class of HMM fences.

Waiting in the MMU notfier, scheduler, TTM etc etc is only allowed for
the dma_fences and HMM fences are ignored in container objects.

When you handle an implicit or explicit synchronization request from
userspace you need to block for HMM fences to complete before taking any
resource locks.

Isnt' that what I call gang scheduling? I.e. you either run in HMM
mode, or in legacy fencing mode (whether implicit or explicit doesn't
really matter I think). By forcing that split we avoid the problem,
but it means occasionally full stalls on mixed workloads.

But that's not what Jerome wants (afaiui at least), I think his idea
is to track the reverse dependencies of all the fences floating
around, and then skip evicting an object if you have to wait for any
fence that is problematic for the current calling context. And I don't
think that's very feasible in practice.

So what kind of hmm fences do you have in mind here?

It's a bit more relaxed than your gang schedule.

See the requirements are as follow:

1. dma_fences never depend on hmm_fences.
2. hmm_fences can never preempt dma_fences.
3. dma_fences must be able to preempt hmm_fences or we always reserve
enough hardware resources (CUs) to guarantee forward progress of dma_fences.

Critical sections are MMU notifiers, page faults, GPU schedulers and
dma_reservation object locks.

4. It is valid to wait for a dma_fences in critical sections.
5. It is not valid to wait for hmm_fences in critical sections.

Fence creation either happens during command submission or by adding
something like a barrier or signal command to your userspace queue.

6. If we have an hmm_fence as implicit or explicit dependency for
creating a dma_fence we must wait for that before taking any locks or
reserving resources.
7. If we have a dma_fence as implicit or explicit dependency for
creating an hmm_fence we can wait later on. So busy waiting or special
WAIT hardware commands are valid.

This prevents hard cuts, e.g. can mix hmm_fences and dma_fences at the
same time on the hardware.

In other words we can have a high priority gfx queue running jobs based
on dma_fences and a low priority compute queue running jobs based on
hmm_fences.

Only when we switch from hmm_fence to dma_fence we need to block the
submission until all the necessary resources (both memory as well as
CUs) are available.

This is somewhat an extension to your gang submit idea.

Either I'm missing something, or this is just exactly what we
documented already with userspace fences in general, and how you can't
have a dma_fence depend upon a userspace (or hmm_fence).

My gang scheduling idea is really just an alternative for what you
have listed as item 3 above. Instead of requiring preempt or requiring
guaranteed forward progress of some other sorts we flush out any
pending dma_fence request. But _only_ those which would get stalled by
the job we're running, so high-priority sdma requests we need in the
kernel to shuffle buffers around are still all ok. This would be
needed if you're hw can't preempt, and you also have shared engines
between compute and gfx, so reserving CUs won't solve the problem
either.

What I don't mean with my gang scheduling is a completely exclusive
mode between hmm_fence and dma_fence, since that would prevent us from
using copy engines and dma_fence in the kernel to shuffle memory
around for hmm jobs. And that would suck, even on compute-only
workloads. Maybe I should rename "gang scheduling" to "engine flush"
or something like that.

Yeah, "engine flush" makes it much more clearer.

What I wanted to 

Re: [PATCH] drm/vblank: Fix typo in docs

[Daniel Vetter]

On Thu, Jan 14, 2021 at 07:52:45PM +0530, Sumera Priyadarsini wrote:
> Fix typo in intro chapter in drm_vblank.c.
> Change 'sacn' to 'scan'.
> 
> Signed-off-by: Sumera Priyadarsini 

Nice catch, applied.
-Daniel

> ---
>  drivers/gpu/drm/drm_vblank.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index d30e2f2b8f3c..30912d8f82a5 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -74,7 +74,7 @@
>   *||   updates the
>   *||   frame as it
>   *||   travels down
> - *||   ("sacn out")
> + *||   ("scan out")
>   *|   Old frame|
>   *||
>   *||
> -- 
> 2.25.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel