Re: [PATCH v2 0/8] RFC Support hot device unplug in amdgpu

[Andrey Grodzovsky]

I am fighting with Thunderbird to make limit a line to 80 chars but nothing 
helps. Any suggestions please.


Andrey

On 6/22/20 5:46 AM, Daniel Vetter wrote:

Also a nit: Please tell your mailer to break long lines, it looks funny
and inconsistent otherwise, at least in some of the mailers I use here :-/
-Daniel

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

Re: [PATCH v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug

[Andrey Grodzovsky]

On 6/22/20 3:40 PM, Christian König wrote:

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

entity->rq becomes null aftre device unplugged so just return early
in that case.


Mhm, do you have a backtrace for this?

This should only be called by an IOCTL and IOCTLs should already call 
drm_dev_enter()/exit() on their own...


Christian.



See bellow, it's not during IOCTL but during all GEM objects release when 
releasing the device. entity->rq becomes null because all the gpu schedulers are 
marked as not ready during the early pci remove stage and so the next time sdma 
job tries to pick a scheduler to run nothing is available and it's set to null.


Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382648] BUG: kernel NULL pointer 
dereference, address: 0038
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382651] #PF: supervisor read 
access in kernel mode
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382652] #PF: error_code(0x) 
- not-present page

Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382653] PGD 0 P4D 0
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382656] Oops:  [#1] SMP PTI
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382658] CPU: 6 PID: 2598 Comm: 
llvmpipe-6 Tainted: G   OE 5.6.0-dev+ #51
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382659] Hardware name: System 
manufacturer System Product Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382700] RIP: 
0010:amdgpu_vm_sdma_commit+0x6c/0x270 [amdgpu]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382702] Code: 01 00 00 48 89 ee 
48 c7 c7 ef d4 85 c0 e8 fc 5f e8 ff 48 8b 75 10 48 c7 c7 fd d4 85 c0 e8 ec 5f e8 
ff 48 8b 45 10 41 8b 55 08 <48> 8b 40 38 85 d2 48 8d b8 30 ff ff ff 0f 84 9b 01 
00 00 48 8b 80
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382704] RSP: 
0018:a88e40f57950 EFLAGS: 00010282
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382705] RAX:  
RBX: a88e40f579a8 RCX: 0001
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382707] RDX: 0014 
RSI: 94d4d62388e0 RDI: 94d4dbd98e30
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382708] RBP: 94d4d2ad3288 
R08:  R09: 0001
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382709] R10: 001f 
R11:  R12: a88e40f57a48
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382710] R13: 94d4d627a5e8 
R14: 94d4d424d978 R15: 000800100020
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382712] FS: 
7f30ae694700() GS:94d4dbd8() knlGS:
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382713] CS:  0010 DS:  ES: 
 CR0: 80050033
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382714] CR2: 0038 
CR3: 000121810006 CR4: 000606e0

Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382716] Call Trace:
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382755] 
amdgpu_vm_bo_update_mapping.constprop.30+0x16b/0x230 [amdgpu]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382795] 
amdgpu_vm_clear_freed+0xd7/0x210 [amdgpu]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382833] 
amdgpu_gem_object_close+0x200/0x2b0 [amdgpu]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382856]  ? 
drm_gem_object_handle_put_unlocked+0x90/0x90 [drm]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382864]  ? 
drm_gem_object_release_handle+0x2c/0x90 [drm]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382872] 
drm_gem_object_release_handle+0x2c/0x90 [drm]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382879]  ? 
drm_gem_object_handle_put_unlocked+0x90/0x90 [drm]

Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382882] idr_for_each+0x48/0xd0
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382885]  ? 
_raw_spin_unlock_irqrestore+0x2d/0x50
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382893] 
drm_gem_release+0x1c/0x30 [drm]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382901] 
drm_file_free+0x21d/0x270 [drm]

Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382908] drm_release+0x67/0xe0 
[drm]
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382912] __fput+0xc6/0x260
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382916] task_work_run+0x79/0xb0
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382919] do_exit+0x3d0/0xc40
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382921]  ? 
get_signal+0x13d/0xc30
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382924] do_group_exit+0x47/0xb0
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382926] get_signal+0x18b/0xc30
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382929] do_signal+0x36/0x6a0
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382931]  ? 
__set_task_comm+0x62/0x120
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382935]  ? 
__x64_sys_futex+0x88/0x180
Jun  8 11:14:56 ubuntu-1604-test kernel: [   44.382938] 
exit_to_usermode_loop+0x6f/0xc0

Jun  8 11:14:56 ubuntu-1604-test kernel: [   

Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space

[Andrey Grodzovsky]

On 6/22/20 5:45 AM, Daniel Vetter wrote:

On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:

Helper function to be used to invalidate all BOs CPU mappings
once device is removed.

Signed-off-by: Andrey Grodzovsky 

This seems to be missing the code to invalidate all the dma-buf mmaps?

Probably needs more testcases if you're not yet catching this. Or am I
missing something, and we're exchanging the the address space also for
dma-buf?
-Daniel



IMHO the device address space includes all user clients having a CPU view of the 
BO either from direct mapping though drm file or by  mapping through imported 
BO's FD.


Andrey





---
  drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
  include/drm/ttm/ttm_bo_driver.h | 7 +++
  2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c5b516f..926a365 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
ttm_bo_unmap_virtual_locked(bo);
ttm_mem_io_unlock(man);
  }
-
-
  EXPORT_SYMBOL(ttm_bo_unmap_virtual);
  
+void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)

+{
+   unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
+}
+EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
+
  int ttm_bo_wait(struct ttm_buffer_object *bo,
bool interruptible, bool no_wait)
  {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd0..39ea44f 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
  void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
  
  /**

+ * ttm_bo_unmap_virtual_address_space
+ *
+ * @bdev: tear down all the virtual mappings for this device
+ */
+void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
+
+/**
   * ttm_bo_unmap_virtual
   *
   * @bo: tear down the virtual mappings for this BO
--
2.7.4


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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Andrey Grodzovsky]

On 6/22/20 12:45 PM, Greg KH wrote:

On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:

On 6/22/20 7:21 AM, Greg KH wrote:

On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:

On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:

Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.

Huh?  That should not happen, do you have a backtrace of that crash?


2 examples in the attached trace.

Odd, how did you trigger these?



By manually triggering PCI remove from sysfs

cd /sys/bus/pci/devices/\:05\:00.0 && echo 1 > remove






[  925.738225 <0.188086>] BUG: kernel NULL pointer dereference, address: 
0090
[  925.738232 <0.07>] #PF: supervisor read access in kernel mode
[  925.738236 <0.04>] #PF: error_code(0x) - not-present page
[  925.738240 <0.04>] PGD 0 P4D 0
[  925.738245 <0.05>] Oops:  [#1] SMP PTI
[  925.738249 <0.04>] CPU: 7 PID: 2547 Comm: amdgpu_test Tainted: G 
   W  OE 5.5.0-rc7-dev-kfd+ #50
[  925.738256 <0.07>] Hardware name: System manufacturer System Product 
Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013
[  925.738266 <0.10>] RIP: 0010:kernfs_find_ns+0x18/0x110
[  925.738270 <0.04>] Code: a6 cf ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 
00 00 66 66 66 66 90 41 57 41 56 49 89 f6 41 55 41 54 49 89 fd 55 53 49 89 d4 <0f> b7 
af 90 00 00 00 8b 05 8f ee 6b 01 48 8b 5f 68 66 83 e5 20 41
[  925.738282 <0.12>] RSP: 0018:ad6d0118fb00 EFLAGS: 00010246
[  925.738287 <0.05>] RAX:  RBX:  RCX: 
2098a12076864b7e
[  925.738292 <0.05>] RDX:  RSI: b6606b31 RDI: 

[  925.738297 <0.05>] RBP: b6606b31 R08: b5379d10 R09: 

[  925.738302 <0.05>] R10: ad6d0118fb38 R11: 9a75f64820a8 R12: 

[  925.738307 <0.05>] R13:  R14: b6606b31 R15: 
9a7612b06130
[  925.738313 <0.06>] FS:  7f3eca4e8700() 
GS:9a763dbc() knlGS:
[  925.738319 <0.06>] CS:  0010 DS:  ES:  CR0: 80050033
[  925.738323 <0.04>] CR2: 0090 CR3: 35e5a005 CR4: 
000606e0
[  925.738329 <0.06>] Call Trace:
[  925.738334 <0.05>]  kernfs_find_and_get_ns+0x2e/0x50
[  925.738339 <0.05>]  sysfs_remove_group+0x25/0x80
[  925.738344 <0.05>]  sysfs_remove_groups+0x29/0x40
[  925.738350 <0.06>]  free_msi_irqs+0xf5/0x190
[  925.738354 <0.04>]  pci_disable_msi+0xe9/0x120

So the PCI core is trying to clean up attributes that it had registered,
which is fine.  But we can't seem to find the attributes?  Were they
already removed somewhere else?

that's odd.



Yes, as i pointed above i am emulating device remove from sysfs and this 
triggers pci device remove sequence and as part of that my specific device 
folder (05:00.0) is removed from the sysfs tree.






[  925.738406 <0.52>]  amdgpu_irq_fini+0xe3/0xf0 [amdgpu]
[  925.738453 <0.47>]  tonga_ih_sw_fini+0xe/0x30 [amdgpu]
[  925.738490 <0.37>]  amdgpu_device_fini_late+0x14b/0x440 [amdgpu]
[  925.738529 <0.39>]  amdgpu_driver_release_kms+0x16/0x40 [amdgpu]
[  925.738548 <0.19>]  drm_dev_put+0x5b/0x80 [drm]
[  925.738558 <0.10>]  drm_release+0xc6/0xd0 [drm]
[  925.738563 <0.05>]  __fput+0xc6/0x260
[  925.738568 <0.05>]  task_work_run+0x79/0xb0
[  925.738573 <0.05>]  do_exit+0x3d0/0xc60
[  925.738578 <0.05>]  do_group_exit+0x47/0xb0
[  925.738583 <0.05>]  get_signal+0x18b/0xc30
[  925.738589 <0.06>]  do_signal+0x36/0x6a0
[  925.738593 <0.04>]  ? force_sig_info_to_task+0xbc/0xd0
[  925.738597 <0.04>]  ? signal_wake_up_state+0x15/0x30
[  925.738603 <0.06>]  exit_to_usermode_loop+0x6f/0xc0
[  925.738608 <0.05>]  prepare_exit_to_usermode+0xc7/0x110
[  925.738613 <0.05>]  ret_from_intr+0x25/0x35
[  925.738617 <0.04>] RIP: 0033:0x417369
[  925.738621 <0.04>] Code: Bad RIP value.
[  925.738625 <0.04>] RSP: 002b:7ffdd6bf0900 EFLAGS: 00010246
[  925.738629 <0.04>] RAX: 7f3eca509000 RBX: 001e RCX: 
7f3ec95ba260
[  925.738634 <0.05>] RDX: 7f3ec9889790 RSI: 000a RDI: 

[  925.738639 <0.05>] RBP: 7ffdd6bf0990 R08: 7f3ec9889780 R09: 
7f3eca4e8700
[  925.738645 <0.06>] R10: 035c R11: 0246 R12: 
021c6170
[  925.738650 <0.05>] R13: 7ffdd6bf0c00 R14:  R15: 





[   40.880899 <0.04>] BUG: kernel NULL pointer dereference, address: 
0090
[   40.880906 <0.07>] 

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  7fb81e9d8073 ("drm/i915: Use drmm_add_final_kfree")

from Linus' tree and commit:

  8a25c4be583d ("drm/i915/params: switch to device specific parameters")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_drv.h
index adb9bf34cf97,2697960f15a9..
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -826,9 -827,9 +827,12 @@@ struct i915_selftest_stash 
  struct drm_i915_private {
struct drm_device drm;
  
+   /* i915 device parameters */
+   struct i915_params params;
+ 
 +  /* FIXME: Device release actions should all be moved to drmm_ */
 +  bool do_release;
 +
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
struct intel_driver_caps caps;


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

Re: [PATCH 1/2] drm/shmem: add support for per object dma api operations

[Gurchetan Singh]

On Mon, Jun 15, 2020 at 12:21 AM Gerd Hoffmann  wrote:
>
> On Fri, Jun 12, 2020 at 11:54:54AM -0700, Gurchetan Singh wrote:
>
> > Plus, I just realized the virtio dma ops and ops used by drm shmem are
> > different, so virtio would have to unconditionally have to skip the
> > shmem path.  Perhaps the best policy is to revert d323bb44e4d2?
>
> Reverting d323bb44e4d2 should work given that virtio-gpu doesn't support
> dma-buf imports, but when doing so please add a comment to the code
> explaining why virtio-gpu handles this different than everybody else.

Done -- sent out "drm/virtio: Revert "drm/virtio: Call the right shmem
helpers" ".

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

Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Deepak Rawat]

> 
> Just a buch of drive-by comments while browsing the code.
> In general code looks good, especialyl for a v1.
> 
> There is a few places that triggers warnings with checkpatch --strict
> Most looks like things that should be fixed.
> 
> 

Thanks Sam for the review. Will take care of the suggestions in next
iteration.

Response inlined below:


> > +struct pipe_msg_hdr {
> > +   u32 type;
> > +   u32 size; /* size of message after this field */
> > +} __packed;
> > +
> > +struct hvd_screen_info {
> > +   u16 width;
> > +   u16 height;
> > +} __packed;
> > +
> > +struct synthvid_msg_hdr {
> > +   u32 type;
> > +   u32 size;  /* size of this header + payload after this field*/
> Add space before closing "*/"
> 
> I wonder what is the difference between what is considered a message
> and
> what is considered payload in the above comments.
> Maybe that just because I do not know this stuff at all and the
> comment
> can be ignored.

message = struct pipe_msg_hdr + struct synthvid_msg_hdr + payload

Will try to make it more clear.

> 
> > +} __packed;
> > +
> > +struct synthvid_version_req {
> > +   u32 version;
> > +} __packed;
> > +
> > +struct synthvid_version_resp {
> > +   u32 version;
> > +   u8 is_accepted;
> > +   u8 max_video_outputs;
> > +} __packed;
> > +
> > +struct synthvid_vram_location {
> > +   u64 user_ctx;
> > +   u8 is_vram_gpa_specified;
> > +   u64 vram_gpa;
> > +} __packed;
> Not an alignmnet friendly layout - but I guess the layout is fixed.
> Same goes in otther places.

Yes nothing can be done for this.


> 
> > +static int synthvid_update_situation(struct hv_device *hdev, u8
> > active, u32 bpp,
> > +u32 w, u32 h, u32 pitch)
> > +{
> > +   struct synthvid_msg msg;
> 
> Sometimes synthvid_msg is hv->init_buf.
> Sometimes a local variable.
> I wonder why there is a difference.

When a reply is expected, hv->init_buf should be used, though I haven't
verified this. Just kept the same logic as in framebuffer driver.



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

Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Deepak Rawat]

On Mon, 2020-06-22 at 14:46 +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > +/* Should be done only once during init and resume */
> > +static int synthvid_update_vram_location(struct hv_device *hdev,
> > + phys_addr_t vram_pp)
> > +{
> > +   struct hyperv_device *hv = hv_get_drvdata(hdev);
> > +   struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> > +   unsigned long t;
> > +   int ret = 0;
> > +
> > +   memset(msg, 0, sizeof(struct synthvid_msg));
> > +   msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> > +   msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> > +   sizeof(struct synthvid_vram_location);
> > +   msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> > +   msg->vram.is_vram_gpa_specified = 1;
> > +   synthvid_send(hdev, msg);
> 
> That suggests it is possible to define multiple framebuffers in vram,
> then pageflip by setting vram.vram_gpa.  If that is the case I'm
> wondering whenever vram helpers are a better fit maybe?  You don't
> have
> to blit each and every display update then.

Thanks for the review. Unfortunately only the first vmbus message take
effect and subsequent calls are ignored. I originally implemented using
vram helpers but I figured out calling this vmbus message again won't
change the vram location.

> 
> FYI: cirrus goes the blit route because (a) the amount of vram is
> very
> small so trying to store multiple framebuffers there is out of
> question,
> and (b) cirrus converts formats on the fly to hide some hardware
> oddities.
> 
> take care,
>   Gerd
> 

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

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jerome Glisse]

On Mon, Jun 22, 2020 at 08:46:17AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote:
> > Not doable as page refcount can change for things unrelated to GUP, with
> > John changes we can identify GUP and we could potentialy copy GUPed page
> > instead of COW but this can potentialy slow down fork() and i am not sure
> > how acceptable this would be. Also this does not solve GUP against page
> > that are already in fork tree ie page P0 is in process A which forks,
> > we now have page P0 in process A and B. Now we have process A which forks
> > again and we have page P0 in A, B, and C. Here B and C are two branches
> > with root in A. B and/or C can keep forking and grow the fork tree.
> 
> For a long time now RDMA has broken COW pages when creating user DMA
> regions.
> 
> The problem has been that fork re-COW's regions that had their COW
> broken.
> 
> So, if you break the COW upon mapping and prevent fork (and others)
> from copying DMA pinned then you'd cover the cases.

I am not sure we want to prevent COW for pinned GUP pages, this would
change current semantic and potentialy break/slow down existing apps.

Anyway i think we focus too much on fork/COW, it is just an unfixable
broken corner cases, mmu notifier allows you to avoid it. Forcing real
copy on fork would likely be seen as regression by most people.


> > Semantic was change with 17839856fd588f4ab6b789f482ed3ffd7c403e1f to some
> > what "fix" that but GUP fast is still succeptible to this.
> 
> Ah, so everyone breaks the COW now, not just RDMA..
> 
> What do you mean 'GUP fast is still succeptible to this' ?

Not all GUP fast path are updated (intentionaly) __get_user_pages_fast()
for instance still keeps COW intact. People using GUP should really knows
what they are doing.

Cheers,
Jérôme

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

[RFC v5 10/10] drm/nouveau/kms/nvd9-: Add CRC support

[Lyude Paul]

This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:

https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt

We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" sources: outp-active/auto for a CRC of
the scanout region, outp-complete for a CRC of both the scanout and
blanking/sync region combined, and outp-inactive for a CRC of only the
blanking/sync region. For each source, nouveau selects the appropriate
tap point based on the output path in use. We also expose an "rg"
source, which allows for capturing CRCs of the scanout raster before
it's encoded into a video signal in the output path. This tap point is
referred to as the raster generator.

Note that while there's some other neat features that can be used with
CRC capture on nvidia hardware, like capturing from two CRC sources
simultaneously, I couldn't see any usecase for them and did not
implement them.

Nvidia only allows for accessing CRCs through a shared DMA region that
we program through the core EVO/NvDisplay channel which is referred to
as the notifier context. The notifier context is limited to either 255
(for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and
unfortunately the hardware simply drops CRCs and reports an overflow
once all available entries in the notifier context are filled.

Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit
on how many CRCs can be captured, we work around this in nouveau by
allocating two separate notifier contexts for each head instead of one.
We schedule a vblank worker ahead of time so that once we start getting
close to filling up all of the available entries in the notifier
context, we can swap the currently used notifier context out with
another pre-prepared notifier context in a manner similar to page
flipping.

Unfortunately, the hardware only allows us to this by flushing two
separate updates on the core channel: one to release the current
notifier context handle, and one to program the next notifier context's
handle. When the hardware processes the first update, the CRC for the
current frame is lost. However, the second update can be flushed
immediately without waiting for the first to complete so that CRC
generation resumes on the next frame. According to Nvidia's hardware
engineers, there isn't any cleaner way of flipping notifier contexts
that would avoid this.

Since using vblank workers to swap out the notifier context will ensure
we can usually flush both updates to hardware within the timespan of a
single frame, we can also ensure that there will only be exactly one
frame lost between the first and second update being executed by the
hardware. This gives us the guarantee that we're always correctly
matching each CRC entry with it's respective frame even after a context
flip. And since IGT will retrieve the CRC entry for a frame by waiting
until it receives a CRC for any subsequent frames, this doesn't cause an
issue with any tests and is much simpler than trying to change the
current DRM API to accommodate.

In order to facilitate testing of correct handling of this limitation,
we also expose a debugfs interface to manually control the threshold for
when we start trying to flip the notifier context. We will use this in
igt to trigger a context flip for testing purposes without needing to
wait for the notifier to completely fill up. This threshold is reset
to the default value set by nouveau after each capture, and is exposed
in a separate folder within each CRTC's debugfs directory labelled
"nv_crc".

Changes since v1:
* Forgot to finish saving crc.h before saving, whoops. This just adds
  some corrections to the empty function declarations that we use if
  CONFIG_DEBUG_FS isn't enabled.
Changes since v2:
* Don't check return code from debugfs_create_dir() or
  debugfs_create_file() - Greg K-H
Changes since v3:
  (no functional changes)
* Fix SPDX license identifiers (checkpatch)
* s/uint32_t/u32/ (checkpatch)
* Fix indenting in switch cases (checkpatch)
Changes since v4:
* Remove unneeded param changes with nv50_head_flush_clr/set
* Rebase

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |  25 +-
 drivers/gpu/drm/nouveau/dispnv50/Kbuild |   4 +
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  20 +
 drivers/gpu/drm/nouveau/dispnv50/core.h |   4 +
 drivers/gpu/drm/nouveau/dispnv50/core907d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/core917d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec37d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec57d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/crc.c  | 714 
 drivers/gpu/drm/nouveau/dispnv50/crc.h  | 125 
 drivers/gpu/drm/nouveau/dispnv50/crc907d.c  | 139 
 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c  | 153 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  17 +
 drivers/gpu/drm/nouveau/dispnv50/disp.h |  

[RFC v5 08/10] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h

[Lyude Paul]

In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.

So, expose the struct in disp.h.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 --
 drivers/gpu/drm/nouveau/dispnv50/disp.h | 14 ++
 2 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 368069a5b181a..090882794f7d6 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -57,24 +57,6 @@
 
 #include 
 
-/**
- * Atomic state
- */
-
-struct nv50_outp_atom {
-   struct list_head head;
-
-   struct drm_encoder *encoder;
-   bool flush_disable;
-
-   union nv50_outp_atom_mask {
-   struct {
-   bool ctrl:1;
-   };
-   u8 mask;
-   } set, clr;
-};
-
 /**
  * EVO channel
  */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h 
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 696e70a6b98b6..c7b72fa850995 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -71,6 +71,20 @@ struct nv50_dmac {
struct mutex lock;
 };
 
+struct nv50_outp_atom {
+   struct list_head head;
+
+   struct drm_encoder *encoder;
+   bool flush_disable;
+
+   union nv50_outp_atom_mask {
+   struct {
+   bool ctrl:1;
+   };
+   u8 mask;
+   } set, clr;
+};
+
 int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
 const s32 *oclass, u8 head, void *data, u32 size,
 u64 syncbuf, struct nv50_dmac *dmac);
-- 
2.26.2

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

[RFC v5 07/10] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom

[Lyude Paul]

While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason we'll need this is for CRC support.

See: on nvidia hardware, each CRC entry in the CRC notifier dma context
has a "tag". This tag corresponds to the nth update on a specific
EVO/NvDisplay channel, which itself is referred to as the "controlling
channel". For gf119+ this can be the core channel, ovly channel, or base
channel. Since we don't expose CRC entry tags to userspace, we simply
ignore this feature and always use the core channel as the controlling
channel. Simple.

Things get a little bit more complicated on gv100+ though. GV100+ only
lets us set the controlling channel to a specific wndw channel, and that
wndw must be owned by the head that we're grabbing CRCs when we enable
CRC generation. Thus, we always need to make sure that each atomic head
state has at least one wndw that is mapped to the head, which will be
used as the controlling channel.

Note that since we don't have flexible wndw mappings yet, we don't
expect to run into any scenarios yet where we'd have a head with no
mapped wndws. When we do add support for flexible wndw mappings however,
we'll need to make sure that we handle reprogramming CRC capture if our
controlling wndw is moved to another head (and potentially reject the
new head state entirely if we can't find another available wndw to
replace it).

With that being said, nouveau currently tracks wndw visibility on heads.
It does not keep track of the actual ownership mappings, which are
(currently) statically programmed. To fix this, we introduce another
bitmask into nv50_head_atom.wndw to keep track of ownership separately
from visibility. We then introduce a nv50_head callback to handle
populating the wndw ownership map, and call it during the atomic check
phase when core->assign_windows is set to true.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  1 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 16 
 drivers/gpu/drm/nouveau/dispnv50/head.h |  2 ++
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 10 ++
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c |  2 ++
 5 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 24f7700768dab..62faaf60f47a5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -18,6 +18,7 @@ struct nv50_head_atom {
 
struct {
u32 mask;
+   u32 owned;
u32 olut;
} wndw;
 
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index d472942102f50..368069a5b181a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2287,12 +2287,28 @@ static int
 nv50_disp_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
 {
struct nv50_atom *atom = nv50_atom(state);
+   struct nv50_core *core = nv50_disp(dev)->core;
struct drm_connector_state *old_connector_state, *new_connector_state;
struct drm_connector *connector;
struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
+   struct nv50_head *head;
+   struct nv50_head_atom *asyh;
int ret, i;
 
+   if (core->assign_windows && core->func->head->static_wndw_map) {
+   drm_for_each_crtc(crtc, dev) {
+   new_crtc_state = drm_atomic_get_crtc_state(state,
+  crtc);
+   if (IS_ERR(new_crtc_state))
+   return PTR_ERR(new_crtc_state);
+
+   head = nv50_head(crtc);
+   asyh = nv50_head_atom(new_crtc_state);
+   core->func->head->static_wndw_map(head, asyh);
+   }
+   }
+
/* We need to handle colour management on a per-plane basis. */
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->color_mgmt_changed) {
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.h 
b/drivers/gpu/drm/nouveau/dispnv50/head.h
index c32b27cdaefc9..c05bbba9e247c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.h
@@ -40,6 +40,7 @@ struct nv50_head_func {
void (*dither)(struct nv50_head *, struct nv50_head_atom *);
void (*procamp)(struct nv50_head *, struct nv50_head_atom *);
void (*or)(struct nv50_head *, struct nv50_head_atom *);
+   void (*static_wndw_map)(struct nv50_head *, struct nv50_head_atom *);
 };
 
 extern const struct nv50_head_func head507d;
@@ -86,6 +87,7 @@ int 

[RFC v5 09/10] drm/nouveau/kms/nv50-: Move hard-coded object handles into header

[Lyude Paul]

While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just go ahead and move any hard-coded
handles into a single header. This is just to keep things slightly
organized, and to make it a little bit easier if we need to add more
handles in the future.

This patch should contain no functional changes.

Changes since v3:
* Correct SPDX license identifier (checkpatch)

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c|  7 +--
 drivers/gpu/drm/nouveau/dispnv50/handles.h | 15 +++
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|  3 ++-
 3 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 090882794f7d6..bf7ba1e1c0f74 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -26,6 +26,7 @@
 #include "core.h"
 #include "head.h"
 #include "wndw.h"
+#include "handles.h"
 
 #include 
 #include 
@@ -154,7 +155,8 @@ nv50_dmac_create(struct nvif_device *device, struct 
nvif_object *disp,
if (!syncbuf)
return 0;
 
-   ret = nvif_object_init(>base.user, 0xf000, NV_DMA_IN_MEMORY,
+   ret = nvif_object_init(>base.user, NV50_DISP_HANDLE_SYNCBUF,
+  NV_DMA_IN_MEMORY,
   &(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
@@ -165,7 +167,8 @@ nv50_dmac_create(struct nvif_device *device, struct 
nvif_object *disp,
if (ret)
return ret;
 
-   ret = nvif_object_init(>base.user, 0xf001, NV_DMA_IN_MEMORY,
+   ret = nvif_object_init(>base.user, NV50_DISP_HANDLE_VRAM,
+  NV_DMA_IN_MEMORY,
   &(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/handles.h 
b/drivers/gpu/drm/nouveau/dispnv50/handles.h
new file mode 100644
index 0..d1beeb9a444db
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/dispnv50/handles.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: MIT
+#ifndef __NV50_KMS_HANDLES_H__
+#define __NV50_KMS_HANDLES_H__
+
+/*
+ * Various hard-coded object handles that nouveau uses. These are made-up by
+ * nouveau developers, not Nvidia. The only significance of the handles chosen
+ * is that they must all be unique.
+ */
+#define NV50_DISP_HANDLE_SYNCBUF
0xf000
+#define NV50_DISP_HANDLE_VRAM   
0xf001
+
+#define NV50_DISP_HANDLE_WNDW_CTX(kind)(0xfb00 | 
kind)
+
+#endif /* !__NV50_KMS_HANDLES_H__ */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c 
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index cfee61f14aa49..9d963ecdd34e8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -21,6 +21,7 @@
  */
 #include "wndw.h"
 #include "wimm.h"
+#include "handles.h"
 
 #include 
 #include 
@@ -59,7 +60,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct 
drm_framebuffer *fb)
int ret;
 
nouveau_framebuffer_get_layout(fb, , );
-   handle = 0xfb00 | kind;
+   handle = NV50_DISP_HANDLE_WNDW_CTX(kind);
 
list_for_each_entry(ctxdma, >ctxdma.list, head) {
if (ctxdma->object.handle == handle)
-- 
2.26.2

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

[RFC v5 00/10] drm/nouveau: Introduce CRC support for gf119+

[Lyude Paul]

Nvidia released some documentation on how CRC support works on their
GPUs, hooray!

So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests (already on the ML).

First - we add some new functionality to kthread_work in the kernel, and
then use this to add a new feature to DRM that Ville Syrjälä came up
with: vblank workers. Basically, this is just a generic DRM interface
that allows for scheduling high-priority workers that start on a given
vblank interrupt. Note that while we're currently only using this in
nouveau, Intel has plans to use this for i915 as well (hence why they
came up with it!).

And finally: in order to implement the last feature, we expose some new
functions in the kernel's kthread_worker infrastructure so that we can
de-complicate our implementation of this.

Anyway-welcome to the future! :)

Major changes since v4:
* Remove the interfaces we tried adding to kthread_worker and use a wait
  queue + seqcount in order to implement flushing vblank workers.
* Rebase
Major changes since v3:
* Style fixes on nouveau patches from checkpatch, no functional changes
* Don't integrate so tightly with kthread_work (and use our own lock),
  instead introduce some new functions for doing simple async flushing
  and cancelling. I think this interface looks a lot more acceptable
  then what I was previously trying.
* Apply some changes requested by danvet
Major changes since v2:
* Use kthread_worker instead of kthreadd for vblank workers
* Don't check debugfs return values

Lyude Paul (10):
  drm/vblank: Register drmm cleanup action once per drm_vblank_crtc
  drm/vblank: Add vblank works
  drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create()
  drm/nouveau/kms/nv140-: Don't modify depth in state during atomic
commit
  drm/nouveau/kms/nv50-: Fix disabling dithering
  drm/nouveau/kms/nv50-: s/harm/armh/g
  drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
  drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h
  drm/nouveau/kms/nv50-: Move hard-coded object handles into header
  drm/nouveau/kms/nvd9-: Add CRC support

 drivers/gpu/drm/drm_vblank.c| 287 +++-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |  25 +-
 drivers/gpu/drm/nouveau/dispnv50/Kbuild |   4 +
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  21 +
 drivers/gpu/drm/nouveau/dispnv50/core.h |   4 +
 drivers/gpu/drm/nouveau/dispnv50/core907d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/core917d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec37d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/corec57d.c |   3 +
 drivers/gpu/drm/nouveau/dispnv50/crc.c  | 714 
 drivers/gpu/drm/nouveau/dispnv50/crc.h  | 125 
 drivers/gpu/drm/nouveau/dispnv50/crc907d.c  | 139 
 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c  | 153 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  58 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.h |  24 +
 drivers/gpu/drm/nouveau/dispnv50/handles.h  |  16 +
 drivers/gpu/drm/nouveau/dispnv50/head.c | 134 +++-
 drivers/gpu/drm/nouveau/dispnv50/head.h |  12 +-
 drivers/gpu/drm/nouveau/dispnv50/head907d.c |  14 +-
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c |  27 +-
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c |  20 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c |  15 +-
 drivers/gpu/drm/nouveau/nouveau_display.c   |  60 +-
 include/drm/drm_vblank.h|  49 ++
 24 files changed, 1775 insertions(+), 138 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.h
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc907d.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c
 create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h

-- 
2.26.2

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

[RFC v5 03/10] drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create()

[Lyude Paul]

We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 8f6455697ba72..e29ea40e7c334 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -507,20 +507,28 @@ nv50_head_create(struct drm_device *dev, int index)
 
if (disp->disp->object.oclass < GV100_DISP) {
ret = nv50_base_new(drm, head->base.index, );
+   if (ret)
+   goto fail_free;
+
ret = nv50_ovly_new(drm, head->base.index, );
+   if (ret)
+   goto fail_free;
} else {
ret = nv50_wndw_new(drm, DRM_PLANE_TYPE_PRIMARY,
head->base.index * 2 + 0, );
+   if (ret)
+   goto fail_free;
+
ret = nv50_wndw_new(drm, DRM_PLANE_TYPE_OVERLAY,
head->base.index * 2 + 1, );
-   }
-   if (ret == 0)
-   ret = nv50_curs_new(drm, head->base.index, );
-   if (ret) {
-   kfree(head);
-   return ERR_PTR(ret);
+   if (ret)
+   goto fail_free;
}
 
+   ret = nv50_curs_new(drm, head->base.index, );
+   if (ret)
+   goto fail_free;
+
crtc = >base.base;
drm_crtc_init_with_planes(dev, crtc, >plane, >plane,
  _head_func, "head-%d", head->base.index);
@@ -533,11 +541,16 @@ nv50_head_create(struct drm_device *dev, int index)
 
if (head->func->olut_set) {
ret = nv50_lut_init(disp, >client.mmu, >olut);
-   if (ret) {
-   nv50_head_destroy(crtc);
-   return ERR_PTR(ret);
-   }
+   if (ret)
+   goto fail_crtc_cleanup;
}
 
return head;
+
+fail_crtc_cleanup:
+   drm_crtc_cleanup(crtc);
+fail_free:
+   kfree(head);
+
+   return ERR_PTR(ret);
 }
-- 
2.26.2

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

[RFC v5 04/10] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit

[Lyude Paul]

Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's depth in the atomic state hasn't been modified.

Normally this wouldn't matter, since we don't modify OR state outside of
modesets, but since the CRC capture region is implemented as part of the
OR state in hardware we'll want to make sure all commits modifying OR
state are idempotent so as to avoid changing the depth unexpectedly.

So, fix this by simply not writing the reduced depth value we come up
with to the atomic state.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 11 +++
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c 
b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 4a9a32b89f746..9ef3c603fc43e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -27,17 +27,20 @@ static void
 headc37d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
 {
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
+   u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
 * improved later for deep colour etc.
 */
switch (asyh->or.depth) {
-   case 6: asyh->or.depth = 5; break;
-   case 5: asyh->or.depth = 4; break;
-   case 2: asyh->or.depth = 1; break;
-   case 0: asyh->or.depth = 4; break;
+   case 6: depth = 5; break;
+   case 5: depth = 4; break;
+   case 2: depth = 1; break;
+   case 0: depth = 4; break;
default:
+   depth = asyh->or.depth;
WARN_ON(1);
break;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c 
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 859131a8bc3c8..97141eb8e75ab 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -27,17 +27,20 @@ static void
 headc57d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
 {
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
+   u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
 * improved later for deep colour etc.
 */
switch (asyh->or.depth) {
-   case 6: asyh->or.depth = 5; break;
-   case 5: asyh->or.depth = 4; break;
-   case 2: asyh->or.depth = 1; break;
-   case 0: asyh->or.depth = 4; break;
+   case 6: depth = 5; break;
+   case 5: depth = 4; break;
+   case 2: depth = 1; break;
+   case 0: depth = 4; break;
default:
+   depth = asyh->or.depth;
WARN_ON(1);
break;
}
-- 
2.26.2

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

[RFC v5 05/10] drm/nouveau/kms/nv50-: Fix disabling dithering

[Lyude Paul]

While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.

So, fix it by never enabling dithering when it's disabled.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/head.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index e29ea40e7c334..72bc3bce396a7 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -84,18 +84,20 @@ nv50_head_atomic_check_dither(struct nv50_head_atom *armh,
 {
u32 mode = 0x00;
 
-   if (asyc->dither.mode == DITHERING_MODE_AUTO) {
-   if (asyh->base.depth > asyh->or.bpc * 3)
-   mode = DITHERING_MODE_DYNAMIC2X2;
-   } else {
-   mode = asyc->dither.mode;
-   }
+   if (asyc->dither.mode) {
+   if (asyc->dither.mode == DITHERING_MODE_AUTO) {
+   if (asyh->base.depth > asyh->or.bpc * 3)
+   mode = DITHERING_MODE_DYNAMIC2X2;
+   } else {
+   mode = asyc->dither.mode;
+   }
 
-   if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
-   if (asyh->or.bpc >= 8)
-   mode |= DITHERING_DEPTH_8BPC;
-   } else {
-   mode |= asyc->dither.depth;
+   if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
+   if (asyh->or.bpc >= 8)
+   mode |= DITHERING_DEPTH_8BPC;
+   } else {
+   mode |= asyc->dither.depth;
+   }
}
 
asyh->dither.enable = mode;
-- 
2.26.2

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

[RFC v5 02/10] drm/vblank: Add vblank works

[Lyude Paul]

Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that flushing waits for both the vblank sequence and job
execution to complete, or for the work to get cancelled - whichever
comes first.

Whatever hardware programming we do in the work must be fast (must at
least complete during the vblank or scanout period, sometimes during the
first few scanlines of the vblank). As such we use a high-priority
per-CRTC thread to accomplish this.

[based off patches from Ville Syrjälä ,
change below to signoff later]

Changes since v4:
* Get rid of kthread interfaces we tried adding and move all of the
  locking into drm_vblank.c. For implementing drm_vblank_work_flush(),
  we now use a wait_queue and sequence counters in order to
  differentiate between multiple work item executions.
* Get rid of drm_vblank_work_cancel() - this would have been pretty
  difficult to actually reimplement and it occurred to me that neither
  nouveau or i915 are even planning to use this function. Since there's
  also no async cancel function for most of the work interfaces in the
  kernel, it seems a bit unnecessary anyway.
* Get rid of to_drm_vblank_work() since we now are also able to just
  pass the struct drm_vblank_work to work item callbacks anyway
Changes since v3:
* Use our own spinlocks, don't integrate so tightly with kthread_works
Changes since v2:
* Use kthread_workers instead of reinventing the wheel.

Cc: Daniel Vetter 
Cc: Tejun Heo 
Cc: Ville Syrjälä 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_vblank.c | 266 +++
 include/drm/drm_vblank.h |  49 +++
 2 files changed, 315 insertions(+)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index ce5c1e1d29963..4d76eb2fed5e9 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -25,7 +25,9 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
@@ -155,6 +157,8 @@
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
  ktime_t *tvblank, bool in_vblank_irq);
+static int drm_vblank_get(struct drm_device *dev, unsigned int pipe);
+static void drm_vblank_put(struct drm_device *dev, unsigned int pipe);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -490,6 +494,35 @@ static void vblank_disable_fn(struct timer_list *t)
spin_unlock_irqrestore(>vbl_lock, irqflags);
 }
 
+static void drm_vblank_work_release(struct drm_vblank_crtc *vblank)
+{
+   struct kthread_worker *worker = vblank->worker;
+   struct drm_vblank_work *work, *tmp;
+   bool wake = false;
+
+   if (!worker)
+   return;
+
+   spin_lock_irq(>work_lock);
+   vblank->worker = NULL;
+
+   list_for_each_entry_safe(work, tmp, >pending_work, node) {
+   drm_vblank_put(vblank->dev, vblank->pipe);
+   list_del(>node);
+
+   if (!--work->pending) {
+   write_seqcount_invalidate(>seqcount);
+   wake = true;
+   }
+   }
+
+   spin_unlock_irq(>work_lock);
+
+   if (wake)
+   wake_up_all(>work_wait_queue);
+   kthread_destroy_worker(worker);
+}
+
 static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
 {
struct drm_vblank_crtc *vblank = ptr;
@@ -497,9 +530,66 @@ static void drm_vblank_init_release(struct drm_device 
*dev, void *ptr)
drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
drm_core_check_feature(dev, DRIVER_MODESET));
 
+   drm_vblank_work_release(vblank);
del_timer_sync(>disable_timer);
 }
 
+static void vblank_work_fn(struct kthread_work *base)
+{
+   struct drm_vblank_work *work =
+   container_of(base, struct drm_vblank_work, base);
+   struct drm_vblank_crtc *vblank = work->vblank;
+
+   work->func(work);
+
+   spin_lock_irq(>work_lock);
+   work->pending--;
+
+   write_seqcount_invalidate(>seqcount);
+   wake_up_all(>work_wait_queue);
+   spin_unlock_irq(>work_lock);
+}
+
+/**
+ * drm_vblank_work_init - initialize a vblank work item
+ * @work: vblank work item
+ * @crtc: CRTC whose vblank will trigger the work execution
+ * @func: work function to be executed
+ *
+ * Initialize a vblank work item for a specific crtc.
+ */
+void drm_vblank_work_init(struct drm_vblank_work *work, struct drm_crtc *crtc,
+ void (*func)(struct drm_vblank_work *work))
+{
+   kthread_init_work(>base, vblank_work_fn);
+   work->func = func;
+   INIT_LIST_HEAD(>node);
+   seqcount_init(>seqcount);
+   work->vblank = 

[RFC v5 06/10] drm/nouveau/kms/nv50-: s/harm/armh/g

[Lyude Paul]

We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.

This patch contains no functional changes.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c 
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 99b9b681736da..cfee61f14aa49 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -408,7 +408,7 @@ nv50_wndw_atomic_check(struct drm_plane *plane, struct 
drm_plane_state *state)
struct nv50_wndw *wndw = nv50_wndw(plane);
struct nv50_wndw_atom *armw = nv50_wndw_atom(wndw->plane.state);
struct nv50_wndw_atom *asyw = nv50_wndw_atom(state);
-   struct nv50_head_atom *harm = NULL, *asyh = NULL;
+   struct nv50_head_atom *armh = NULL, *asyh = NULL;
bool modeset = false;
int ret;
 
@@ -429,9 +429,9 @@ nv50_wndw_atomic_check(struct drm_plane *plane, struct 
drm_plane_state *state)
 
/* Fetch assembly state for the head the window used to belong to. */
if (armw->state.crtc) {
-   harm = nv50_head_atom_get(asyw->state.state, armw->state.crtc);
-   if (IS_ERR(harm))
-   return PTR_ERR(harm);
+   armh = nv50_head_atom_get(asyw->state.state, armw->state.crtc);
+   if (IS_ERR(armh))
+   return PTR_ERR(armh);
}
 
/* LUT configuration can potentially cause the window to be disabled. */
@@ -455,8 +455,8 @@ nv50_wndw_atomic_check(struct drm_plane *plane, struct 
drm_plane_state *state)
asyh->wndw.mask |= BIT(wndw->id);
} else
if (armw->visible) {
-   nv50_wndw_atomic_check_release(wndw, asyw, harm);
-   harm->wndw.mask &= ~BIT(wndw->id);
+   nv50_wndw_atomic_check_release(wndw, asyw, armh);
+   armh->wndw.mask &= ~BIT(wndw->id);
} else {
return 0;
}
-- 
2.26.2

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

[RFC v5 01/10] drm/vblank: Register drmm cleanup action once per drm_vblank_crtc

[Lyude Paul]

Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to initialize one of them.

Changes since v3:
* Use drmm_add_action_or_reset() - Daniel Vetter

Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_vblank.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 85e5f2db16085..ce5c1e1d29963 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -492,16 +492,12 @@ static void vblank_disable_fn(struct timer_list *t)
 
 static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
 {
-   unsigned int pipe;
-
-   for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = ptr;
 
-   drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
-   drm_core_check_feature(dev, DRIVER_MODESET));
+   drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
+   drm_core_check_feature(dev, DRIVER_MODESET));
 
-   del_timer_sync(>disable_timer);
-   }
+   del_timer_sync(>disable_timer);
 }
 
 /**
@@ -511,7 +507,7 @@ static void drm_vblank_init_release(struct drm_device *dev, 
void *ptr)
  *
  * This function initializes vblank support for @num_crtcs display pipelines.
  * Cleanup is handled automatically through a cleanup function added with
- * drmm_add_action().
+ * drmm_add_action_or_reset().
  *
  * Returns:
  * Zero on success or a negative error code on failure.
@@ -530,10 +526,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
num_crtcs)
 
dev->num_crtcs = num_crtcs;
 
-   ret = drmm_add_action(dev, drm_vblank_init_release, NULL);
-   if (ret)
-   return ret;
-
for (i = 0; i < num_crtcs; i++) {
struct drm_vblank_crtc *vblank = >vblank[i];
 
@@ -542,6 +534,11 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
num_crtcs)
init_waitqueue_head(>queue);
timer_setup(>disable_timer, vblank_disable_fn, 0);
seqlock_init(>seqlock);
+
+   ret = drmm_add_action_or_reset(dev, drm_vblank_init_release,
+  vblank);
+   if (ret)
+   return ret;
}
 
return 0;
-- 
2.26.2

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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #20 from rtmasura+ker...@hotmail.com ---
I have XFCE4 installed as well, I'll give it a test and let you know in 24
hours; a GPF should have happened by then

-- 
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 v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.

[Alex Deucher]

On Mon, Jun 22, 2020 at 3:38 PM Christian König
 wrote:
>
> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> > Use the new TTM interface to invalidate all exsisting BO CPU mappings
> > form all user proccesses.
> >
> > Signed-off-by: Andrey Grodzovsky 
>
> Reviewed-by: Christian König 
>
> I think those two patches could already land in amd-staging-drm-next
> since they are a good idea independent of how else we fix the other issues.

Please make sure they land in drm-misc as well.

Alex

>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 43592dc..6932d75 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
> >   struct drm_device *dev = pci_get_drvdata(pdev);
> >
> >   drm_dev_unplug(dev);
> > + ttm_bo_unmap_virtual_address_space(>mman.bdev);
> >   amdgpu_driver_unload_kms(dev);
> >
> >   pci_disable_device(pdev);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space

[Alex Deucher]

On Sun, Jun 21, 2020 at 2:05 AM Andrey Grodzovsky
 wrote:
>
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
>
> Signed-off-by: Andrey Grodzovsky 

Typo in the subject:
unampping -> unmapping

Alex


> ---
>  drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
>  include/drm/ttm/ttm_bo_driver.h | 7 +++
>  2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index c5b516f..926a365 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object 
> *bo)
> ttm_bo_unmap_virtual_locked(bo);
> ttm_mem_io_unlock(man);
>  }
> -
> -
>  EXPORT_SYMBOL(ttm_bo_unmap_virtual);
>
> +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)
> +{
> +   unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
> +}
> +EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
> +
>  int ttm_bo_wait(struct ttm_buffer_object *bo,
> bool interruptible, bool no_wait)
>  {
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index c9e0fd0..39ea44f 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>  void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
>
>  /**
> + * ttm_bo_unmap_virtual_address_space
> + *
> + * @bdev: tear down all the virtual mappings for this device
> + */
> +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
> +
> +/**
>   * ttm_bo_unmap_virtual
>   *
>   * @bo: tear down the virtual mappings for this BO
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

entity->rq becomes null aftre device unplugged so just return early
in that case.


Mhm, do you have a backtrace for this?

This should only be called by an IOCTL and IOCTLs should already call 
drm_dev_enter()/exit() on their own...


Christian.



Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 21 -
  1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
index 8d9c6fe..d252427 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
@@ -24,6 +24,7 @@
  #include "amdgpu_job.h"
  #include "amdgpu_object.h"
  #include "amdgpu_trace.h"
+#include 
  
  #define AMDGPU_VM_SDMA_MIN_NUM_DW	256u

  #define AMDGPU_VM_SDMA_MAX_NUM_DW (16u * 1024u)
@@ -94,7 +95,12 @@ static int amdgpu_vm_sdma_commit(struct 
amdgpu_vm_update_params *p,
struct drm_sched_entity *entity;
struct amdgpu_ring *ring;
struct dma_fence *f;
-   int r;
+   int r, idx;
+
+   if (!drm_dev_enter(p->adev->ddev, )) {
+   r = -ENODEV;
+   goto nodev;
+   }
  
  	entity = p->immediate ? >vm->immediate : >vm->delayed;

ring = container_of(entity->rq->sched, struct amdgpu_ring, sched);
@@ -104,7 +110,7 @@ static int amdgpu_vm_sdma_commit(struct 
amdgpu_vm_update_params *p,
WARN_ON(ib->length_dw > p->num_dw_left);
r = amdgpu_job_submit(p->job, entity, AMDGPU_FENCE_OWNER_VM, );
if (r)
-   goto error;
+   goto job_fail;
  
  	if (p->unlocked) {

struct dma_fence *tmp = dma_fence_get(f);
@@ -118,10 +124,15 @@ static int amdgpu_vm_sdma_commit(struct 
amdgpu_vm_update_params *p,
if (fence && !p->immediate)
swap(*fence, f);
dma_fence_put(f);
-   return 0;
  
-error:

-   amdgpu_job_free(p->job);
+   r = 0;
+
+job_fail:
+   drm_dev_exit(idx);
+nodev:
+   if (r)
+   amdgpu_job_free(p->job);
+
return r;
  }
  


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

Re: [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Use the new TTM interface to invalidate all exsisting BO CPU mappings
form all user proccesses.

Signed-off-by: Andrey Grodzovsky 


Reviewed-by: Christian König 

I think those two patches could already land in amd-staging-drm-next 
since they are a good idea independent of how else we fix the other issues.



---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 43592dc..6932d75 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
  
  	drm_dev_unplug(dev);

+   ttm_bo_unmap_virtual_address_space(>mman.bdev);
amdgpu_driver_unload_kms(dev);
  
  	pci_disable_device(pdev);


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

Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Helper function to be used to invalidate all BOs CPU mappings
once device is removed.

Signed-off-by: Andrey Grodzovsky 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
  include/drm/ttm/ttm_bo_driver.h | 7 +++
  2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c5b516f..926a365 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
ttm_bo_unmap_virtual_locked(bo);
ttm_mem_io_unlock(man);
  }
-
-
  EXPORT_SYMBOL(ttm_bo_unmap_virtual);
  
+void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)

+{
+   unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
+}
+EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
+
  int ttm_bo_wait(struct ttm_buffer_object *bo,
bool interruptible, bool no_wait)
  {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd0..39ea44f 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
  void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
  
  /**

+ * ttm_bo_unmap_virtual_address_space
+ *
+ * @bdev: tear down all the virtual mappings for this device
+ */
+void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
+
+/**
   * ttm_bo_unmap_virtual
   *
   * @bo: tear down the virtual mappings for this BO


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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #19 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to rtmasura+kernel from comment #18)
> 09:00.0 VGA compatible controller: NVIDIA Corporation GP104GL [Quadro P4000]
> (rev a1)

> 0e:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c3)

> A few notes on that: The AMD Vega56 is used for this PC, the Quadro P4000 is
> disabled on my system and passed through to VMs. 

So newer graphics, Vega56/gcn5 compared to my gcn4.

No VMs at all here so that can be excluded as a factor (unless it's a minor
trigger similar to my zooming or video play).

> I haven't found any way to trigger it. Seems completely random. Sat down
> this morning to update a VM (not the one with the nvidia passthrough) and it
> froze, wasn't any real graphical things going on other than normal KDE
> stuff. 

KDE/Plasma here too.  I think kwin exercises the opengl a bit more than some
WMs, in part because it's a compositor as well.  The bug most often hits here
when playing video or using kwin's zoom effect, which exercise the graphics a
bit.

So mostly kde/kwin triggers could lower the population hitting it and could be
a factor, based on both of us running it.

> Model name:  AMD Phenom(tm) II X6 1090T Processor

Newer graphics, gcn5 to gcn4, older cpu, phenom ii to fx, than here.

So we know gcn4 and gcn5 are affected, and pcie2 bus with pcie3 cards and
kde/kwin are common-factor possible triggers so far.

> I would be happy to help with any testing, just let me know what information
> you need.

If you happen to run anything besides KDE/Plasma on X, duplicating (or failing
to duplicate) the bug on non-kde and/or on wayland would be useful info.  I
only run KDE Plasma on X here.  Well, that and CLI (on amdgpu-drm-framebuffer)
more than some but not enough that I'd have expected to see it there, which I
haven't.

-- 
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 v2 2/8] drm/ttm: Remap all page faults to per process dummy page.

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

On device removal reroute all CPU mappings to dummy page per drm_file
instance or imported GEM object.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 -
  1 file changed, 57 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b..2f8bf5e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -35,6 +35,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -328,19 +330,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
pgprot_t prot;
struct ttm_buffer_object *bo = vma->vm_private_data;
vm_fault_t ret;
+   int idx;
+   struct drm_device *ddev = bo->base.dev;
  
-	ret = ttm_bo_vm_reserve(bo, vmf);

-   if (ret)
-   return ret;
+   if (drm_dev_enter(ddev, )) {


Better do this like if (!drm_dev_enter(...)) return ttm_bo_vm_dummy(..);

This way you can move all the dummy fault handling into a separate 
function without cluttering this one here to much.


Christian.


+   ret = ttm_bo_vm_reserve(bo, vmf);
+   if (ret)
+   goto exit;
+
+   prot = vma->vm_page_prot;
  
-	prot = vma->vm_page_prot;

-   ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
-   if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+   ret = ttm_bo_vm_fault_reserved(vmf, prot, 
TTM_BO_VM_NUM_PREFAULT);
+   if (ret == VM_FAULT_RETRY && !(vmf->flags & 
FAULT_FLAG_RETRY_NOWAIT))
+   goto exit;
+
+   dma_resv_unlock(bo->base.resv);
+
+exit:
+   drm_dev_exit(idx);
return ret;
+   } else {
  
-	dma_resv_unlock(bo->base.resv);

+   struct drm_file *file = NULL;
+   struct page *dummy_page = NULL;
+   int handle;
  
-	return ret;

+   /* We are faulting on imported BO from dma_buf */
+   if (bo->base.dma_buf && bo->base.import_attach) {
+   dummy_page = bo->base.dummy_page;
+   /* We are faulting on non imported BO, find drm_file owning the 
BO*/
+   } else {
+   struct drm_gem_object *gobj;
+
+   mutex_lock(>filelist_mutex);
+   list_for_each_entry(file, >filelist, lhead) {
+   spin_lock(>table_lock);
+   idr_for_each_entry(>object_idr, gobj, 
handle) {
+   if (gobj == >base) {
+   dummy_page = file->dummy_page;
+   break;
+   }
+   }
+   spin_unlock(>table_lock);
+   }
+   mutex_unlock(>filelist_mutex);
+   }
+
+   if (dummy_page) {
+   /*
+* Let do_fault complete the PTE install e.t.c using 
vmf->page
+*
+* TODO - should i call free_page somewhere ?
+*/
+   get_page(dummy_page);
+   vmf->page = dummy_page;
+   return 0;
+   } else {
+   return VM_FAULT_SIGSEGV;
+   }
+   }
  }
  EXPORT_SYMBOL(ttm_bo_vm_fault);
  


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

Re: [v9 2/3] drm/debug: Expose connector VRR monitor range via debugfs

[Manasi Navare]

On Mon, Jun 22, 2020 at 07:55:18PM +0530, Bhanuprakash Modem wrote:
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
> 
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector, "vrr_range".
> 
> Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> 
> v2:
> * Fix the typo in max_vfreq (Manasi)
> * Change the name of node to i915_vrr_info so we can add
> other vrr info for more debug info (Manasi)
> * Change the VRR capable to display Yes or No (Manasi)
> * Fix indentation checkpatch errors (Manasi)
> v3:
> * Remove the unnecessary debug print (Manasi)
> v4:
> * Rebase
> v5:
> * Rename to vrr_range to match AMD debugfs
> v6:
> * Rebase (manasi)
> v7:
> * Fix cmpilation due to rebase
> v8:
> * Move debugfs node creation logic to DRM (Emil)
> * Remove AMD specific logic (Emil)
> v9:
> * Seperate patch for removal of AMD specific logic (Manasi)
> 
> Signed-off-by: Bhanuprakash Modem 
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> CC: Emil Velikov 

Looks good to me,

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/drm_debugfs.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index bfe4602f206b..3d7182001004 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -376,6 +376,24 @@ static ssize_t edid_write(struct file *file, const char 
> __user *ubuf,
>   return (ret) ? ret : len;
>  }
>  
> +/*
> + * Returns the min and max vrr vfreq through the connector's debugfs file.
> + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> + */
> +static int vrr_range_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> +
> + if (connector->status != connector_status_connected)
> + return -ENODEV;
> +
> + seq_printf(m, "Min: %u\n", 
> (u8)connector->display_info.monitor_range.min_vfreq);
> + seq_printf(m, "Max: %u\n", 
> (u8)connector->display_info.monitor_range.max_vfreq);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(vrr_range);
> +
>  static const struct file_operations drm_edid_fops = {
>   .owner = THIS_MODULE,
>   .open = edid_open,
> @@ -413,6 +431,10 @@ void drm_debugfs_connector_add(struct drm_connector 
> *connector)
>   /* edid */
>   debugfs_create_file("edid_override", S_IRUGO | S_IWUSR, root, connector,
>   _edid_fops);
> +
> + /* vrr range */
> + debugfs_create_file("vrr_range", S_IRUGO, root, connector,
> + _range_fops);
>  }
>  
>  void drm_debugfs_connector_remove(struct drm_connector *connector)
> -- 
> 2.20.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: [Intel-gfx] [v1 3/3] Revert "drm/amd/display: Expose connector VRR range via debugfs"

[Manasi Navare]

On Mon, Jun 22, 2020 at 10:57:02AM -0400, Kazlauskas, Nicholas wrote:
> On 2020-06-22 10:25 a.m., Bhanuprakash Modem wrote:
> >As both VRR min and max are already part of drm_display_info,
> >drm can expose this VRR range for each connector.
> >
> >Hence this logic should move to core DRM.
> >
> >This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.
> >
> >Signed-off-by: Bhanuprakash Modem 
> >Cc: Nicholas Kazlauskas 
> >Cc: Harry Wentland 
> >Cc: Alex Deucher 
> >Cc: Manasi Navare 
> >Cc: AMD gfx 
> 
> 
> Looks good to me with Patch 2 part of the series.
> 
> Reviewed-by: Nicholas Kazlauskas 
> 

Thanks for your review, do we have your r-b on patch 2/3 also?
In that case, how do you think we should merge the patches?
Patch 2/3 will be merged through drm-misc, how about this one?

Manasi

> Thanks,
> Nicholas Kazlauskas
> 
> >---
> >  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 20 ---
> >  1 file changed, 20 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
> >b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> >index 076af267b488..71387d2af2ed 100644
> >--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> >+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> >@@ -820,24 +820,6 @@ static int output_bpc_show(struct seq_file *m, void 
> >*data)
> > return res;
> >  }
> >-/*
> >- * Returns the min and max vrr vfreq through the connector's debugfs file.
> >- * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> >- */
> >-static int vrr_range_show(struct seq_file *m, void *data)
> >-{
> >-struct drm_connector *connector = m->private;
> >-struct amdgpu_dm_connector *aconnector = 
> >to_amdgpu_dm_connector(connector);
> >-
> >-if (connector->status != connector_status_connected)
> >-return -ENODEV;
> >-
> >-seq_printf(m, "Min: %u\n", (unsigned int)aconnector->min_vfreq);
> >-seq_printf(m, "Max: %u\n", (unsigned int)aconnector->max_vfreq);
> >-
> >-return 0;
> >-}
> >-
> >  #ifdef CONFIG_DRM_AMD_DC_HDCP
> >  /*
> >   * Returns the HDCP capability of the Display (1.4 for now).
> >@@ -1001,7 +983,6 @@ static ssize_t dp_dpcd_data_read(struct file *f, char 
> >__user *buf,
> >  DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
> >  DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
> >  DEFINE_SHOW_ATTRIBUTE(output_bpc);
> >-DEFINE_SHOW_ATTRIBUTE(vrr_range);
> >  #ifdef CONFIG_DRM_AMD_DC_HDCP
> >  DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
> >  #endif
> >@@ -1059,7 +1040,6 @@ static const struct {
> > {"phy_settings", _phy_settings_debugfs_fop},
> > {"test_pattern", _phy_test_pattern_fops},
> > {"output_bpc", _bpc_fops},
> >-{"vrr_range", _range_fops},
> >  #ifdef CONFIG_DRM_AMD_DC_HDCP
> > {"hdcp_sink_capability", _sink_capability_fops},
> >  #endif
> >
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #18 from rtmasura+ker...@hotmail.com ---
lspci:
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890 Northbridge
only single slot PCI-e GFX Hydra part (rev 02)
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory
Management Unit (IOMMU)
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980
PCI to PCI bridge (PCI Express GFX port 0)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980
PCI to PCI bridge (PCI Express GPP Port 0)
00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980
PCI to PCI bridge (PCI Express GPP Port 3)
00:0b.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD990 PCI to
PCI bridge (PCI Express GFX2 port 0)
00:0d.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980
PCI to PCI bridge (PCI Express GPP2 Port 0)
00:11.0 RAID bus controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 SATA Controller [RAID5 mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller
(rev 42)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia
(Intel HDA) (rev 40)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0
LPC host controller (rev 40)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI
Bridge (rev 40)
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor
HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor
Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor
Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor
Link Control
02:00.0 PCI bridge: PLX Technology, Inc. PEX 8624 24-lane, 6-Port PCI Express
Gen 2 (5.0 GT/s) Switch [ExpressLane] (rev bb)
03:04.0 PCI bridge: PLX Technology, Inc. PEX 8624 24-lane, 6-Port PCI Express
Gen 2 (5.0 GT/s) Switch [ExpressLane] (rev bb)
03:05.0 PCI bridge: PLX Technology, Inc. PEX 8624 24-lane, 6-Port PCI Express
Gen 2 (5.0 GT/s) Switch [ExpressLane] (rev bb)
03:06.0 PCI bridge: PLX Technology, Inc. PEX 8624 24-lane, 6-Port PCI Express
Gen 2 (5.0 GT/s) Switch [ExpressLane] (rev bb)
03:08.0 PCI bridge: PLX Technology, Inc. PEX 8624 24-lane, 6-Port PCI Express
Gen 2 (5.0 GT/s) Switch [ExpressLane] (rev bb)
03:09.0 PCI bridge: PLX Technology, Inc. PEX 8624 24-lane, 6-Port PCI Express
Gen 2 (5.0 GT/s) Switch [ExpressLane] (rev bb)
04:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
06:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
07:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
07:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
09:00.0 VGA compatible controller: NVIDIA Corporation GP104GL [Quadro P4000]
(rev a1)
09:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller
(rev a1)
0a:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev
03)
0b:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller
(rev 03)
0b:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev
03)
0c:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1470 (rev c3)
0d:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1471
0e:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega
10 XL/XT [Radeon RX Vega 56/64] (rev c3)
0e:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 HDMI Audio
[Radeon Vega 56/64]

A few notes on that: The AMD Vega56 is used for this PC, the Quadro P4000 is
disabled on my system and passed through to VMs. 

I haven't found any way to trigger it. Seems completely random. Sat down this
morning to update a VM (not the one with the nvidia passthrough) and it froze,
wasn't any 

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Daniel Vetter]

On Mon, Jun 22, 2020 at 7:45 PM Christian König
 wrote:
>
> Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:
> >
> > On 6/22/20 9:18 AM, Christian König wrote:
> >> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> >>> Will be used to reroute CPU mapped BO's page faults once
> >>> device is removed.
> >>>
> >>> Signed-off-by: Andrey Grodzovsky 
> >>> ---
> >>>   drivers/gpu/drm/drm_file.c  |  8 
> >>>   drivers/gpu/drm/drm_prime.c | 10 ++
> >>>   include/drm/drm_file.h  |  2 ++
> >>>   include/drm/drm_gem.h   |  2 ++
> >>>   4 files changed, 22 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >>> index c4c704e..67c0770 100644
> >>> --- a/drivers/gpu/drm/drm_file.c
> >>> +++ b/drivers/gpu/drm/drm_file.c
> >>> @@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct
> >>> drm_minor *minor)
> >>>   goto out_prime_destroy;
> >>>   }
> >>>   +file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> >>> +if (!file->dummy_page) {
> >>> +ret = -ENOMEM;
> >>> +goto out_prime_destroy;
> >>> +}
> >>> +
> >>>   return file;
> >>> out_prime_destroy:
> >>> @@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
> >>>   if (dev->driver->postclose)
> >>>   dev->driver->postclose(dev, file);
> >>>   +__free_page(file->dummy_page);
> >>> +
> >>>   drm_prime_destroy_file_private(>prime);
> >>> WARN_ON(!list_empty(>event_list));
> >>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >>> index 1de2cde..c482e9c 100644
> >>> --- a/drivers/gpu/drm/drm_prime.c
> >>> +++ b/drivers/gpu/drm/drm_prime.c
> >>> @@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct
> >>> drm_device *dev,
> >>> ret = drm_prime_add_buf_handle(_priv->prime,
> >>>   dma_buf, *handle);
> >>> +
> >>> +if (!ret) {
> >>> +obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> >>> +if (!obj->dummy_page)
> >>> +ret = -ENOMEM;
> >>> +}
> >>> +
> >>
> >> While the per file case still looks acceptable this is a clear NAK
> >> since it will massively increase the memory needed for a prime
> >> exported object.
> >>
> >> I think that this is quite overkill in the first place and for the
> >> hot unplug case we can just use the global dummy page as well.
> >>
> >> Christian.
> >
> >
> > Global dummy page is good for read access, what do you do on write
> > access ? My first approach was indeed to map at first global dummy
> > page as read only and mark the vma->vm_flags as !VM_SHARED assuming
> > that this would trigger Copy On Write flow in core mm
> > (https://elixir.bootlin.com/linux/v5.7-rc7/source/mm/memory.c#L3977)
> > on the next page fault to same address triggered by a write access but
> > then i realized a new COW page will be allocated for each such mapping
> > and this is much more wasteful then having a dedicated page per GEM
> > object.
>
> Yeah, but this is only for a very very small corner cases. What we need
> to prevent is increasing the memory usage during normal operation to much.
>
> Using memory during the unplug is completely unproblematic because we
> just released quite a bunch of it by releasing all those system memory
> buffers.
>
> And I'm pretty sure that COWed pages are correctly accounted towards the
> used memory of a process.
>
> So I think if that approach works as intended and the COW pages are
> released again on unmapping it would be the perfect solution to the problem.
>
> Daniel what do you think?

If COW works, sure sounds reasonable. And if we can make sure we
managed to drop all the system allocations (otherwise suddenly 2x
memory usage, worst case). But I have no idea whether we can
retroshoehorn that into an established vma, you might have fun stuff
like a mkwrite handler there (which I thought is the COW handler
thing, but really no idea).

If we need to massively change stuff then I think rw dummy page,
allocated on first fault after hotunplug (maybe just make it one per
object, that's simplest) seems like the much safer option. Much less
code that can go wrong.
-Daniel

> Regards,
> Christian.
>
> > We can indeed optimize by allocating this dummy page on the first page
> > fault after device disconnect instead on GEM object creation.
> >
> > Andrey
> >
> >
> >>
> >>> mutex_unlock(_priv->prime.lock);
> >>>   if (ret)
> >>>   goto fail;
> >>> @@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct
> >>> drm_gem_object *obj, struct sg_table *sg)
> >>>   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> >>>   dma_buf = attach->dmabuf;
> >>>   dma_buf_detach(attach->dmabuf, attach);
> >>> +
> >>> +__free_page(obj->dummy_page);
> >>> +
> >>>   /* remove the reference */
> >>>   dma_buf_put(dma_buf);
> >>>   }
> >>> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> >>> index 19df802..349a658 100644
> >>> --- 

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Christian König]

Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:


On 6/22/20 9:18 AM, Christian König wrote:

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Will be used to reroute CPU mapped BO's page faults once
device is removed.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_file.c  |  8 
  drivers/gpu/drm/drm_prime.c | 10 ++
  include/drm/drm_file.h  |  2 ++
  include/drm/drm_gem.h   |  2 ++
  4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c4c704e..67c0770 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct 
drm_minor *minor)

  goto out_prime_destroy;
  }
  +    file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+    if (!file->dummy_page) {
+    ret = -ENOMEM;
+    goto out_prime_destroy;
+    }
+
  return file;
    out_prime_destroy:
@@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
  if (dev->driver->postclose)
  dev->driver->postclose(dev, file);
  +    __free_page(file->dummy_page);
+
  drm_prime_destroy_file_private(>prime);
    WARN_ON(!list_empty(>event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1de2cde..c482e9c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct 
drm_device *dev,

    ret = drm_prime_add_buf_handle(_priv->prime,
  dma_buf, *handle);
+
+    if (!ret) {
+    obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+    if (!obj->dummy_page)
+    ret = -ENOMEM;
+    }
+


While the per file case still looks acceptable this is a clear NAK 
since it will massively increase the memory needed for a prime 
exported object.


I think that this is quite overkill in the first place and for the 
hot unplug case we can just use the global dummy page as well.


Christian.



Global dummy page is good for read access, what do you do on write 
access ? My first approach was indeed to map at first global dummy 
page as read only and mark the vma->vm_flags as !VM_SHARED assuming 
that this would trigger Copy On Write flow in core mm 
(https://elixir.bootlin.com/linux/v5.7-rc7/source/mm/memory.c#L3977) 
on the next page fault to same address triggered by a write access but 
then i realized a new COW page will be allocated for each such mapping 
and this is much more wasteful then having a dedicated page per GEM 
object. 


Yeah, but this is only for a very very small corner cases. What we need 
to prevent is increasing the memory usage during normal operation to much.


Using memory during the unplug is completely unproblematic because we 
just released quite a bunch of it by releasing all those system memory 
buffers.


And I'm pretty sure that COWed pages are correctly accounted towards the 
used memory of a process.


So I think if that approach works as intended and the COW pages are 
released again on unmapping it would be the perfect solution to the problem.


Daniel what do you think?

Regards,
Christian.

We can indeed optimize by allocating this dummy page on the first page 
fault after device disconnect instead on GEM object creation.


Andrey





mutex_unlock(_priv->prime.lock);
  if (ret)
  goto fail;
@@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct 
drm_gem_object *obj, struct sg_table *sg)

  dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
  dma_buf = attach->dmabuf;
  dma_buf_detach(attach->dmabuf, attach);
+
+    __free_page(obj->dummy_page);
+
  /* remove the reference */
  dma_buf_put(dma_buf);
  }
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 19df802..349a658 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -335,6 +335,8 @@ struct drm_file {
   */
  struct drm_prime_file_private prime;
  +    struct page *dummy_page;
+
  /* private: */
  #if IS_ENABLED(CONFIG_DRM_LEGACY)
  unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b37506..47460d1 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -310,6 +310,8 @@ struct drm_gem_object {
   *
   */
  const struct drm_gem_object_funcs *funcs;
+
+    struct page *dummy_page;
  };
    /**




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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #17 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to rtmasura+kernel from comment #16)
> Reporting I've had the same issue with kernel 5.7.2 and 5.7.4:

Thanks!

> Jun 22 07:10:24 abiggun kernel: Hardware name: System manufacturer System
> Product Name/Crosshair IV Formula, BIOS 110208/24/2010

So socket AM3 from 2010, slightly older than my AM3+ from 2012.  Both are
PCIe-2.0.

What's your CPU and GPU?

As above my GPU is Polaris11 (AMD Radeon RX 460, arctic-islands/gcn4 series,
pcie-3),  AMD fx6100 CPU.

Guessing the bug is gpu-series code specific or there'd be more people howling,
so what you're running for gpu is significant.  It's /possible/ it may be
specific to people running pcie mismatch, as well (note my pcie-3 gpu card on a
pcie-2 mobo).

> Jun 22 07:10:24 abiggun kernel: Workqueue: events_unbound commit_work
> [drm_kms_helper]
> 0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu]

That's the bit of the dump I understand, similar to mine...

If you can find a quicker/more-reliable way to trigger the crash, it'd sure be
helpful for bisecting.  Also, if you're running a bad kernel enough to tell
(not just back to 5.6 after finding 5.7 bad), does it reliably dump-log before
the reboot for you?  I'm back to a veerrry--sloowww second bisect attempt, with
for instance my current kernel having crashed three times now so it's obviously
bugged, but nothing dumped in the log on the way down yet so I can't guarantee
it's the _same_ bug (the bisect is in pre-rc1 code so chances of a different
bug are definitely non-zero), and given the bad results on the first bisect I'm
trying to confirm each bisect-bad with a log-dump and each bisect-good with at
least 3-4 days no crash.  But this one's in between right now, frequent
crashing but no log-dump to confirm it's the same bug.

-- 
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 1/1] drm/mm/selftests: fix wrong return type casting

[Christian König]

Am 22.06.20 um 15:45 schrieb Nirmoy Das:

Function prepare_igt_frag() and get_insert_time() were casting
signed value to unsigned value before returning error.
So error check in igt_frag() would not work with unsigned
return value from get_insert_time() compared against negative
value.

Addresses-Coverity: ("Unsigned compared against 0, no effect")
Signed-off-by: Nirmoy Das 
Reported-by: Colin Ian King 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/selftests/test-drm_mm.c | 21 +++--
  1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 3846b0f5bae3..3306d8bd0544 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1041,13 +1041,12 @@ static int prepare_igt_frag(struct drm_mm *mm,
  {
unsigned int size = 4096;
unsigned int i;
-   u64 ret = -EINVAL;

for (i = 0; i < num_insert; i++) {
if (!expect_insert(mm, [i], size, 0, i,
   mode) != 0) {
pr_err("%s insert failed\n", mode->name);
-   goto out;
+   return -EINVAL;
}
}

@@ -1057,8 +1056,7 @@ static int prepare_igt_frag(struct drm_mm *mm,
drm_mm_remove_node([i]);
}

-out:
-   return ret;
+   return 0;

  }

@@ -1070,21 +1068,16 @@ static u64 get_insert_time(struct drm_mm *mm,
unsigned int size = 8192;
ktime_t start;
unsigned int i;
-   u64 ret = -EINVAL;

start = ktime_get();
for (i = 0; i < num_insert; i++) {
if (!expect_insert(mm, [i], size, 0, i, mode) != 0) {
pr_err("%s insert failed\n", mode->name);
-   goto out;
+   return 0;
}
}

-   ret = ktime_to_ns(ktime_sub(ktime_get(), start));
-
-out:
-   return ret;
-
+   return ktime_to_ns(ktime_sub(ktime_get(), start));
  }

  static int igt_frag(void *ignored)
@@ -1119,17 +1112,17 @@ static int igt_frag(void *ignored)
continue;

ret = prepare_igt_frag(, nodes, insert_size, mode);
-   if (!ret)
+   if (ret)
goto err;

insert_time1 = get_insert_time(, insert_size,
   nodes + insert_size, mode);
-   if (insert_time1 < 0)
+   if (insert_time1 == 0)
goto err;

insert_time2 = get_insert_time(, (insert_size * 2),
   nodes + insert_size * 2, mode);
-   if (insert_time2 < 0)
+   if (insert_time2 == 0)
goto err;

pr_info("%s fragmented insert of %u and %u insertions took %llu and 
%llu nsecs\n",
--
2.27.0



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

Re: drivers/gpu/drm/panel/panel-samsung-ld9040.c:240:12: warning: stack frame size of 8312 bytes in function 'ld9040_prepare'

[Sam Ravnborg]

Hi Vladimir

> I really don't get what's the problem here. The listing of
> ld9040_prepare at the given commit and with the given .config is:

The culprint is likely ld9040_brightness_set() that is inlined.

I think we have troubles with

static u8 const ld9040_gammas[25][22]

I did not look closely but if you can reproduce this is where I think you
should look.

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

Re: [PATCH v1 03/11] soc: mediatek: cmdq: add write_s function

[Matthias Brugger]

On 22/06/2020 18:12, Dennis-YC Hsieh wrote:
> Hi Matthias,
> 
> On Mon, 2020-06-22 at 17:54 +0200, Matthias Brugger wrote:
>>
>> On 22/06/2020 17:36, Dennis-YC Hsieh wrote:
>>> Hi Matthias,
>>>
>>> thanks for your comment.
>>>
>>> On Mon, 2020-06-22 at 13:07 +0200, Matthias Brugger wrote:

 On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
>
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   19 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|   19 +++
>  3 files changed, 39 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index bf32e3b2ca6c..817a5a97dbe5 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
>   union {
>   u32 value;
>   u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
>   };
>   union {
>   u16 offset;
> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 
> subsys,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_mask);
>  
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +  u16 addr_low, u16 src_reg_idx)
> +{

 Do I understand correctly that we use CMDQ_ADDR_HIGH(addr) and
 CMDQ_ADDR_LOW(addr) to calculate in the client high_addr_reg_idx and 
 addr_low
 respectively?

 In that case I think a better interface would be to pass the address and 
 do the
 high/low calculation in the cmdq_pkt_write_s
>>>
>>> Not exactly. The high_addr_reg_idx parameter is index of internal
>>> register (which store address bit[47:16]), not result of
>>> CMDQ_ADDR_HIGH(addr). 
>>>
>>> The CMDQ_ADDR_HIGH macro use in patch 02/11 cmdq_pkt_assign() api. This
>>> api helps assign address bit[47:16] into one of internal register by
>>> index. And same index could be use in cmdq_pkt_write_s(). The gce
>>> combine bit[47:16] in internal register and bit[15:0] in addr_low
>>> parameter to final address. So it is better to keep interface in this
>>> way.
>>>
>>
>> Got it, but then why don't we call cmdq_pkt_assign() in cmdq_pkt_write_s()? 
>> This
>> way we would get a clean API for what we want to do.
>> Do we expect other users of cmdq_pkt_assign()? Otherwise we could keep it
>> private the this file and don't export it.
> 
> Considering this case: write 2 register 0xaabb00c0 0xaabb00d0.
> 
> If we call assign inside write_s api it will be:
> assign aabb to internal reg 0
> write reg 0 + 0x00c0
> assign aabb to internal reg 0
> write reg 0 + 0x00d0
> 
> 
> But if we let client decide timing to call assign, it will be like:
> assign aabb to internal reg 0
> write reg 0 + 0x00c0
> write reg 0 + 0x00d0
> 

Ok, thanks for clarification. Is this something you exepect to see in the gce
consumer driver?

> 
> The first way uses 4 command and second one uses only 3 command.
> Thus it is better to let client call assign explicitly.
> 
>>
>> By the way, why do you postfix the _s, I understand that it reflects the 
>> large
>> DMA access but I wonder why you choose '_s'.
>>
> 
> The name of this command is "write_s" which is hardware spec.
> I'm just following it since it is a common language between gce sw/hw
> designers.
> 

Ok, I will probably have to look that up every time have a look at the driver,
but that's OK.

Regards,
Matthias

> 
> Regards,
> Dennis
> 
>> Regards,
>> Matthias
>>
>>>
>>> Regards,
>>> Dennis
>>>

 Regards,
 Matthias

> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_WRITE_S;
> + inst.src_t = CMDQ_REG_TYPE;
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
>  int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>  {
>   struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..ee67dd3b86f5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
>   CMDQ_CODE_LOGIC = 0xa0,
>  };
>  
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 

Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema

[Daniel Thompson]

On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml 
> > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > new file mode 100644
> > index ..7e1f109a38a4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > @@ -0,0 +1,98 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: pwm-backlight bindings
> > +
> > +maintainers:
> > +  - Lee Jones 
> > +  - Daniel Thompson 
> > +  - Jingoo Han 
> > +
> > +properties:
> > +  compatible:
> > +const: pwm-backlight
> > +
> > +  pwms:
> > +maxItems: 1
> > +
> > +  pwm-names: true
> > +
> > +  power-supply:
> > +description: regulator for supply voltage
> > +
> > +  enable-gpios:
> > +description: Contains a single GPIO specifier for the GPIO which 
> > enables
> > +  and disables the backlight
> > +maxItems: 1
> > +
> > +  post-pwm-on-delay-ms:
> > +description: Delay in ms between setting an initial (non-zero) PWM and
> > +  enabling the backlight using GPIO.
> > +
> > +  pwm-off-delay-ms:
> > +description: Delay in ms between disabling the backlight using GPIO
> > +  and setting PWM value to 0.
> > +
> > +  brightness-levels:
> > +description: Array of distinct brightness levels. Typically these are
> > +  in the range from 0 to 255, but any range starting at 0 will do. The
> > +  actual brightness level (PWM duty cycle) will be interpolated from
> > +  these values. 0 means a 0% duty cycle (darkest/off), while the last
> > +  value in the array represents a 100% duty cycle (brightest).
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  default-brightness-level:
> > +description: The default brightness level (index into the array defined
> > +  by the "brightness-levels" property).
> > +$ref: /schemas/types.yaml#/definitions/uint32
> Same comment as before...

Sorry the "ditto" meant I didn't thing about PWM as much as I should
have.

The situation for PWM is a little different to LED. That's mostly
because we decided not to clutter the LED code with
"num-interpolated-steps".

The PWM code implements the default-brightness-level as an index into
the brightness array *after* it has been expanded using interpolation.
In other words today Linux treats the default-brightness-level more
like[1].

description: The default brightness level. When
  num-interpolated-steps is not set this is simply an index into
  the array defined by the "brightness-levels" property. If
  num-interpolated-steps is set the brightness array will be
  expanded by interpolation before we index to get a default
  level.

This is the best I have come up with so far... but I concede it still
lacks elegance.


Daniel.


[1] I don't know my way round the BSD code bases to be sure what they
do... I did a couple of web searches but didn't pull up anything
definitive.


> 
> > +
> > +  num-interpolated-steps:
> > +description: Number of interpolated steps between each value of 
> > brightness-levels
> > +  table. This way a high resolution pwm duty cycle can be used without
> > +  having to list out every possible value in the brightness-level 
> > array.
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +dependencies:
> > +  default-brightness-level: [brightness-levels]
> > +  num-interpolated-steps: [brightness-levels]
> > +
> > +required:
> > +  - compatible
> > +  - pwms
> > +  - power-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +backlight {
> > +compatible = "pwm-backlight";
> > +pwms = < 0 500>;
> > +
> > +brightness-levels = <0 4 8 16 32 64 128 255>;
> > +default-brightness-level = <6>;
> > +
> > +power-supply = <_bl_reg>;
> > +enable-gpios = < 58 0>;
> > +post-pwm-on-delay-ms = <10>;
> > +pwm-off-delay-ms = <10>;
> > +};
> > +
> > +  - |
> > +// Example using num-interpolation-steps:
> > +backlight {
> > +compatible = "pwm-backlight";
> > +pwms = < 0 500>;
> > +
> > +brightness-levels = <0 2048 4096 8192 16384 65535>;
> > +num-interpolated-steps = <2048>;
> > +default-brightness-level = <4096>;
> > +
> > +power-supply = <_bl_reg>;
> > +enable-gpios = < 58 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

Re: [PATCH v4] drm/doc: device hot-unplug for userspace

[Alex Deucher]

On Mon, Jun 22, 2020 at 10:06 AM Pekka Paalanen  wrote:
>
> From: Pekka Paalanen 
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC 
> and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
>
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
>
> Signed-off-by: Pekka Paalanen 
> Reviewed-by: Daniel Vetter 
> Cc: Andrey Grodzovsky 
> Cc: Dave Airlie 
> Cc: Sean Paul 
> Cc: Simon Ser 
> Cc: Noralf Trønnes 
> Cc: Ben Skeggs 
> Cc: Christian König 
> Cc: Harry Wentland 
> Cc: Karol Herbst 
>
> ---
>
> Harry and Christian, could one of you ack this on behalf of AMD
> drivers?
>
> Ben or Karol, could you ack on behalf of Nouveau?
>
> Noralf, would this work for the tiny drivers etc.?
>
> This is only about laying out plans for the future, not about what
> drivers do today. We'd just like to be sure the goals are reasonable and
> everyone is aware of the idea.
>
> Thanks,
> pq
>
> v4:
> - two typo fixes (Daniel)
>
> v3:
> - update ENODEV doc (Daniel)
> - clarify existing vs. new mmaps (Andrey)
> - split into KMS and render/cross sections (Andrey, Daniel)
> - open() returns ENXIO (open(2) man page)
> - ioctls may return ENODEV (Andrey, Daniel)
> - new wayland-protocols MR
>
> v2:
> - mmap reads/writes undefined (Daniel)
> - make render ioctl behaviour driver-specific (Daniel)
> - restructure the mmap paragraphs (Daniel)
> - chardev minor notes (Simon)
> - open behaviour (Daniel)
> - DRM leasing behaviour (Daniel)
> - added links
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 114 -
>  1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..b2585ea6a83e 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>  ===
>  Userland interfaces
>  ===
> @@ -162,6 +164,116 @@ other hand, a driver requires shared state between 
> clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>
> +Device Hot-Unplug
> +=
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop continue to
> +run, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent, ioctls returning ENODEV
> +(or driver-specific ioctls returning driver-specific things), or open()
> +returning ENXIO.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
> +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> +new DRM device always picks the next free minor number compared to the
> +previous one allocated, and wraps around when minor numbers are
> +exhausted.
> +
> +The goal raises at least the following requirements for the kernel and
> +drivers.
> +
> +Requirements for KMS UAPI
> +-
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips, and atomic commits, both real and
> +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> +  success.
> +
> +- Pending non-blocking KMS operations deliver the DRM 

[PATCH] drm/msm: Fix up the rest of the messed up address sizes

[Jordan Crouse]

msm_gem_address_space_create() changed to take a start/length instead
of a start/end for the iova space but all of the callers were just
cut and pasted from the old usage. Most of the mistakes have been fixed
up so just catch up the rest.

Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c| 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 60f6472a3e58..6021f8d9efd1 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -408,7 +408,7 @@ a2xx_create_address_space(struct msm_gpu *gpu, struct 
platform_device *pdev)
struct msm_gem_address_space *aspace;
 
aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
-   SZ_16M + 0xfff * SZ_64K);
+   0xfff * SZ_64K);
 
if (IS_ERR(aspace) && !IS_ERR(mmu))
mmu->funcs->destroy(mmu);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 096be97ce9f9..21e77d67151f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1121,7 +1121,7 @@ static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
return -ENODEV;
 
mmu = msm_iommu_new(gmu->dev, domain);
-   gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x7fff);
+   gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x8000);
if (IS_ERR(gmu->aspace)) {
iommu_domain_free(domain);
return PTR_ERR(gmu->aspace);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index b8615d4fe8a3..680527e28d09 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -780,7 +780,7 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
 
mmu = msm_iommu_new(dpu_kms->dev->dev, domain);
aspace = msm_gem_address_space_create(mmu, "dpu1",
-   0x1000, 0xfff);
+   0x1000, 0x1 - 0x1000);
 
if (IS_ERR(aspace)) {
mmu->funcs->destroy(mmu);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 08897184b1d9..fc6a3f8134c7 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -514,7 +514,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
config->iommu);
 
aspace  = msm_gem_address_space_create(mmu,
-   "mdp4", 0x1000, 0x);
+   "mdp4", 0x1000, 0x1 - 0x1000);
 
if (IS_ERR(aspace)) {
if (!IS_ERR(mmu))
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 54631fbd9389..8586d2cf1d94 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -641,7 +641,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
mmu = msm_iommu_new(iommu_dev, config->platform.iommu);
 
aspace = msm_gem_address_space_create(mmu, "mdp5",
-   0x1000, 0x);
+   0x1000, 0x1 - 0x1000);
 
if (IS_ERR(aspace)) {
if (!IS_ERR(mmu))
-- 
2.17.1

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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Greg KH]

On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
> 
> On 6/22/20 7:21 AM, Greg KH wrote:
> > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > > > Track sysfs files in a list so they all can be removed during pci remove
> > > > since otherwise their removal after that causes crash because parent
> > > > folder was already removed during pci remove.
> > Huh?  That should not happen, do you have a backtrace of that crash?
> 
> 
> 2 examples in the attached trace.

Odd, how did you trigger these?


> [  925.738225 <0.188086>] BUG: kernel NULL pointer dereference, address: 
> 0090
> [  925.738232 <0.07>] #PF: supervisor read access in kernel mode
> [  925.738236 <0.04>] #PF: error_code(0x) - not-present page
> [  925.738240 <0.04>] PGD 0 P4D 0 
> [  925.738245 <0.05>] Oops:  [#1] SMP PTI
> [  925.738249 <0.04>] CPU: 7 PID: 2547 Comm: amdgpu_test Tainted: G   
>  W  OE 5.5.0-rc7-dev-kfd+ #50
> [  925.738256 <0.07>] Hardware name: System manufacturer System 
> Product Name/RAMPAGE IV FORMULA, BIOS 4804 12/30/2013
> [  925.738266 <0.10>] RIP: 0010:kernfs_find_ns+0x18/0x110
> [  925.738270 <0.04>] Code: a6 cf ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 
> 00 00 00 00 66 66 66 66 90 41 57 41 56 49 89 f6 41 55 41 54 49 89 fd 55 53 49 
> 89 d4 <0f> b7 af 90 00 00 00 8b 05 8f ee 6b 01 48 8b 5f 68 66 83 e5 20 41
> [  925.738282 <0.12>] RSP: 0018:ad6d0118fb00 EFLAGS: 00010246
> [  925.738287 <0.05>] RAX:  RBX:  
> RCX: 2098a12076864b7e
> [  925.738292 <0.05>] RDX:  RSI: b6606b31 
> RDI: 
> [  925.738297 <0.05>] RBP: b6606b31 R08: b5379d10 
> R09: 
> [  925.738302 <0.05>] R10: ad6d0118fb38 R11: 9a75f64820a8 
> R12: 
> [  925.738307 <0.05>] R13:  R14: b6606b31 
> R15: 9a7612b06130
> [  925.738313 <0.06>] FS:  7f3eca4e8700() 
> GS:9a763dbc() knlGS:
> [  925.738319 <0.06>] CS:  0010 DS:  ES:  CR0: 
> 80050033
> [  925.738323 <0.04>] CR2: 0090 CR3: 35e5a005 
> CR4: 000606e0
> [  925.738329 <0.06>] Call Trace:
> [  925.738334 <0.05>]  kernfs_find_and_get_ns+0x2e/0x50
> [  925.738339 <0.05>]  sysfs_remove_group+0x25/0x80
> [  925.738344 <0.05>]  sysfs_remove_groups+0x29/0x40
> [  925.738350 <0.06>]  free_msi_irqs+0xf5/0x190
> [  925.738354 <0.04>]  pci_disable_msi+0xe9/0x120

So the PCI core is trying to clean up attributes that it had registered,
which is fine.  But we can't seem to find the attributes?  Were they
already removed somewhere else?

that's odd.

> [  925.738406 <0.52>]  amdgpu_irq_fini+0xe3/0xf0 [amdgpu]
> [  925.738453 <0.47>]  tonga_ih_sw_fini+0xe/0x30 [amdgpu]
> [  925.738490 <0.37>]  amdgpu_device_fini_late+0x14b/0x440 [amdgpu]
> [  925.738529 <0.39>]  amdgpu_driver_release_kms+0x16/0x40 [amdgpu]
> [  925.738548 <0.19>]  drm_dev_put+0x5b/0x80 [drm]
> [  925.738558 <0.10>]  drm_release+0xc6/0xd0 [drm]
> [  925.738563 <0.05>]  __fput+0xc6/0x260
> [  925.738568 <0.05>]  task_work_run+0x79/0xb0
> [  925.738573 <0.05>]  do_exit+0x3d0/0xc60
> [  925.738578 <0.05>]  do_group_exit+0x47/0xb0
> [  925.738583 <0.05>]  get_signal+0x18b/0xc30
> [  925.738589 <0.06>]  do_signal+0x36/0x6a0
> [  925.738593 <0.04>]  ? force_sig_info_to_task+0xbc/0xd0
> [  925.738597 <0.04>]  ? signal_wake_up_state+0x15/0x30
> [  925.738603 <0.06>]  exit_to_usermode_loop+0x6f/0xc0
> [  925.738608 <0.05>]  prepare_exit_to_usermode+0xc7/0x110
> [  925.738613 <0.05>]  ret_from_intr+0x25/0x35
> [  925.738617 <0.04>] RIP: 0033:0x417369
> [  925.738621 <0.04>] Code: Bad RIP value.
> [  925.738625 <0.04>] RSP: 002b:7ffdd6bf0900 EFLAGS: 00010246
> [  925.738629 <0.04>] RAX: 7f3eca509000 RBX: 001e 
> RCX: 7f3ec95ba260
> [  925.738634 <0.05>] RDX: 7f3ec9889790 RSI: 000a 
> RDI: 
> [  925.738639 <0.05>] RBP: 7ffdd6bf0990 R08: 7f3ec9889780 
> R09: 7f3eca4e8700
> [  925.738645 <0.06>] R10: 035c R11: 0246 
> R12: 021c6170
> [  925.738650 <0.05>] R13: 7ffdd6bf0c00 R14:  
> R15: 
> 
> 
> 
> 
> [   40.880899 <0.04>] BUG: kernel NULL pointer dereference, address: 
> 0090
> [   40.880906 <0.07>] #PF: supervisor read access in kernel mode
> [   40.880910 <0.04>] #PF: error_code(0x) - not-present page
> [   40.880915 <0.05>] PGD 0 P4D 0 
> 

Re: [PATCH 1/2] drm/msm: Fix address space size after refactor.

[Jordan Crouse]

On Wed, Jun 17, 2020 at 07:39:08PM -0700, Rob Clark wrote:
> On Wed, Jun 17, 2020 at 1:53 PM Eric Anholt  wrote:
> >
> > Previously the address space went from 16M to ~0u, but with the
> > refactor one of the 'f's was dropped, limiting us to 256MB.
> > Additionally, the new interface takes a start and size, not start and
> > end, so we can't just copy and paste.
> >
> > Fixes regressions in dEQP-VK.memory.allocation.random.*
> >
> > Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
> > Signed-off-by: Eric Anholt 
> 
> 
> rebased on https://patchwork.freedesktop.org/series/78281/ (which
> fixed half of the problem) and pushed this and 2/2 to msm-next so it
> should show up in linux-next shortly..
> 
> planning to wait a short time more to see if we find any other issues
> and then send a -fixes PR

I'll fix up the rest of the flubbed addresses sizes.

Jordan

> BR,
> -R
> 
> 
> > ---
> >  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 89673c7ed473..5db06b590943 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -194,7 +194,7 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> > struct msm_gem_address_space *aspace;
> >
> > aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> > -   0xfff);
> > +   0x - SZ_16M);
> >
> > if (IS_ERR(aspace) && !IS_ERR(mmu))
> > mmu->funcs->destroy(mmu);
> > --
> > 2.26.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 v2 5/8] drm/amdgpu: Refactor sysfs removal

[Andrey Grodzovsky]

On 6/22/20 7:21 AM, Greg KH wrote:

On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:

On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:

Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.

Huh?  That should not happen, do you have a backtrace of that crash?



2 examples in the attached trace.

Andrey





Signed-off-by: Andrey Grodzovsky 

Uh I thought sysfs just gets yanked completely. Please check with Greg KH
whether hand-rolling all this really is the right solution here ... Feels
very wrong. I thought this was all supposed to work by adding attributes
before publishing the sysfs node, and then letting sysfs clean up
everything. Not by cleaning up manually yourself.

Yes, that is supposed to be the correct thing to do.


Adding Greg for an authoritative answer.
-Daniel


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
  8 files changed, 99 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 604a681..ba3775f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -726,6 +726,15 @@ struct amd_powerplay {
  
  #define AMDGPU_RESET_MAGIC_NUM 64

  #define AMDGPU_MAX_DF_PERFMONS 4
+
+struct amdgpu_sysfs_list_node {
+   struct list_head head;
+   struct device_attribute *attr;
+};

You know we have lists of attributes already, called attribute groups,
if you really wanted to do something like this.  But, I don't think so.

Either way, don't hand-roll your own stuff that the driver core has
provided for you for a decade or more, that's just foolish :)


+
+#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
+   struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
_attr_##_attr}
+
  struct amdgpu_device {
struct device   *dev;
struct drm_device   *ddev;
@@ -992,6 +1001,10 @@ struct amdgpu_device {
charproduct_number[16];
charproduct_name[32];
charserial[16];
+
+   struct list_head sysfs_files_list;
+   struct mutex sysfs_files_list_lock;
+
  };
  
  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index fdd52d8..c1549ee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1950,8 +1950,10 @@ static ssize_t amdgpu_atombios_get_vbios_version(struct 
device *dev,
return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
  }
  
+

  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
   NULL);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
  
  /**

   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
@@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
adev->mode_info.atom_context = NULL;
kfree(adev->mode_info.atom_card_info);
adev->mode_info.atom_card_info = NULL;
-   device_remove_file(adev->dev, _attr_vbios_version);
  }
  
  /**

@@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
return ret;
}
  
+	mutex_lock(>sysfs_files_list_lock);

+   list_add_tail(_attr_handle_vbios_version.head, 
>sysfs_files_list);
+   mutex_unlock(>sysfs_files_list_lock);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index e7b9065..3173046 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2928,6 +2928,12 @@ static const struct attribute *amdgpu_dev_attributes[] = 
{
NULL
  };
  
+static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);

+static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
+
+
  /**
   * amdgpu_device_init - initialize the driver
   *
@@ -3029,6 +3035,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
INIT_LIST_HEAD(>shadow_list);
mutex_init(>shadow_list_lock);
  
+	INIT_LIST_HEAD(>sysfs_files_list);

+   mutex_init(>sysfs_files_list_lock);
+
  

Re: [PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)

[Rafael J. Wysocki]

On Sat, Jun 20, 2020 at 2:18 PM Hans de Goede  wrote:
>
> The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
> controller gets turned off from the _PS3 method of the graphics-card dev:
>
> Method (_PS3, 0, Serialized)  // _PS3: Power State 3
> {
> ...
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> ...
> }
>
> Where PSAT is the power-status register of the PWM controller.
>
> Since the i915 driver will do a pwm_get on the pwm device as it uses it to
> control the LCD panel backlight, there is a device-link marking the i915
> device as a consumer of the pwm device. So that the PWM controller will
> always be suspended after the i915 driver suspends (which is the right
> thing to do). This causes the above GFX0 PS3 AML code to run before
> acpi_lpss.c calls acpi_lpss_save_ctx().
>
> So on these devices the PWM controller will already be off when
> acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0x)
> as ctx register values.
>
> When these bogus values get restored on resume the PWM controller actually
> keeps working, since most bits are reserved, but this does set bit 3 of
> the LPSS General purpose register, which for the PWM controller has the
> following function: "This bit is re-used to support 32kHz slow mode.
> Default is 19.2MHz as PWM source clock".
>
> This causes the clock of the PWM controller to switch from 19.2MHz to
> 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far
> there have been few bug reports about this. This is likely because the
> i915 driver was hardcoding the PWM frequency to 46 KHz, which divided
> by 600 would result in a PWM frequency of approx. 78 Hz, which mostly
> still works fine. There are some bug reports about the LCD backlight
> flickering after suspend/resume which are likely caused by this issue.
>
> But with the upcoming patch-series to finally switch the i915 drivers
> code for external PWM controllers to use the atomic API and to honor
> the PWM frequency specified in the video BIOS (VBT), this becomes a much
> bigger problem. On most cases the VBT specifies either 200 Hz or 20
> KHz as PWM frequency, which with the mentioned issue ends up being either
> 1/3 Hz, where the backlight actually visible blinks on and off every 3s,
> or in 33 Hz and horrible flickering of the backlight.
>
> There are a number of possible solutions to this problem:
>
> 1. Make acpi_lpss_save_ctx() run before GFX0._PS3
>  Pro: Clean solution from pov of not medling with save/restore ctx code
>  Con: As mentioned the current ordering is the right thing to do
>  Con: Requires assymmetry in at what suspend/resume phase we do the save vs
>   restore, requiring more suspend/resume ordering hacks in already
>   convoluted acpi_lpss.c suspend/resume code.
> 2. Do some sort of save once mode for the LPSS ctx
>  Pro: Reasonably clean
>  Con: Needs a new LPSS flag + code changes to handle the flag
> 3. Detect we have failed to save the ctx registers and do not restore them
>  Pro: Not PWM specific, might help with issues on other LPSS devices too
>  Con: If we can get away with not restoring the ctx why bother with it at
>   all?
> 4. Do not save the ctx for CHT PWM controllers
>  Pro: Clean, as simple as dropping a flag?
>  Con: Not so simple as dropping a flag, needs a new flag to ensure that
>   we still do lpss_deassert_reset() on device activation.
> 5. Make the pwm-lpss code fixup the LPSS-context registers
>  Pro: Keeps acpi_lpss.c code clean
>  Con: Moves knowledge of LPSS-context into the pwm-lpss.c code
>
> 1 and 5 both do not seem to be a desirable way forward.
>
> 3 and 4 seem ok, but they both assume that restoring the LPSS-context
> registers is not necessary. I have done a couple of test and those do
> show that restoring the LPSS-context indeed does not seem to be necessary
> on devices using s2idle suspend (and successfully reaching S0i3). But I
> have no hardware to test deep / S3 suspend. So I'm not sure that not
> restoring the context is safe.
>
> That leaves solution 2, which is about as simple / clean as 3 and 4,
> so this commit fixes the described problem by implementing a new
> LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.
>
> Signed-off-by: Hans de Goede 

Acked-by: Rafael J. Wysocki 

> ---
> Changes in v2:
> - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
> ---
>  drivers/acpi/acpi_lpss.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 446e666b3466..7e6db0f1d9ee 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -67,7 +67,15 @@ ACPI_MODULE_NAME("acpi_lpss");
>  #define LPSS_CLK_DIVIDER   BIT(2)
> 

Re: [PATCH v3 01/15] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase

[Rafael J. Wysocki]

On Sat, Jun 20, 2020 at 2:18 PM Hans de Goede  wrote:
>
> The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
> controller gets poked from the _PS0 method of the graphics-card device:
>
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> If (((Local0 & 0x03) == 0x03))
> {
> PSAT &= 0xFFFC
> Local1 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> RSTA = Zero
> RSTF = Zero
> RSTA = One
> RSTF = One
> PWMB |= 0xC000
> PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
> }
>
> Where PSAT is the power-status register of the PWM controller, so if it
> is in D3 when the GFX0 device's PS0 method runs then it will turn it on
> and restore the PWM ctrl register value it saved from its PS3 handler.
> Note not only does it restore it, it ors it with 0xC000 turning it
> on at a time where we may not want it to get turned on at all.
>
> The pwm_get call which the i915 driver does to get a reference to the
> PWM controller, already adds a device-link making the GFX0 device a
> consumer of the PWM device. So it should already have been resumed when
> the above AML runs and the AML should thus not do its undesirable poking
> of the PWM controller register.
>
> But the PCI core powers on PCI devices in the no-irq resume phase and
> thus calls the troublesome PS0 method in the no-irq resume phase.
> Where as LPSS devices by default are resumed in the early resume phase.
>
> This commit sets the resume_from_noirq flag in the bsw_pwm_dev_desc
> struct, so that Cherry Trail PWM controllers will be resumed in the
> no-irq phase. Together with the device-link added by the pwm-get this
> ensures that the PWM controller will be on when the troublesome PS0
> method runs, which stops it from poking the PWM controller.
>
> Signed-off-by: Hans de Goede 

Acked-by: Rafael J. Wysocki 

> ---
>  drivers/acpi/acpi_lpss.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index c5a5a179f49d..446e666b3466 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -257,6 +257,7 @@ static const struct lpss_device_desc bsw_pwm_dev_desc = {
> .flags = LPSS_SAVE_CTX | LPSS_NO_D3_DELAY,
> .prv_offset = 0x800,
> .setup = bsw_pwm_setup,
> +   .resume_from_noirq = true,
>  };
>
>  static const struct lpss_device_desc byt_uart_dev_desc = {
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 03/11] soc: mediatek: cmdq: add write_s function

[Matthias Brugger]

On 22/06/2020 17:36, Dennis-YC Hsieh wrote:
> Hi Matthias,
> 
> thanks for your comment.
> 
> On Mon, 2020-06-22 at 13:07 +0200, Matthias Brugger wrote:
>>
>> On 21/06/2020 16:18, Dennis YC Hsieh wrote:
>>> add write_s function in cmdq helper functions which
>>> writes value contains in internal register to address
>>> with large dma access support.
>>>
>>> Signed-off-by: Dennis YC Hsieh 
>>> ---
>>>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   19 +++
>>>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>>>  include/linux/soc/mediatek/mtk-cmdq.h|   19 +++
>>>  3 files changed, 39 insertions(+)
>>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
>>> b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index bf32e3b2ca6c..817a5a97dbe5 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -18,6 +18,10 @@ struct cmdq_instruction {
>>> union {
>>> u32 value;
>>> u32 mask;
>>> +   struct {
>>> +   u16 arg_c;
>>> +   u16 src_reg;
>>> +   };
>>> };
>>> union {
>>> u16 offset;
>>> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 
>>> subsys,
>>>  }
>>>  EXPORT_SYMBOL(cmdq_pkt_write_mask);
>>>  
>>> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>> +u16 addr_low, u16 src_reg_idx)
>>> +{
>>
>> Do I understand correctly that we use CMDQ_ADDR_HIGH(addr) and
>> CMDQ_ADDR_LOW(addr) to calculate in the client high_addr_reg_idx and addr_low
>> respectively?
>>
>> In that case I think a better interface would be to pass the address and do 
>> the
>> high/low calculation in the cmdq_pkt_write_s
> 
> Not exactly. The high_addr_reg_idx parameter is index of internal
> register (which store address bit[47:16]), not result of
> CMDQ_ADDR_HIGH(addr). 
> 
> The CMDQ_ADDR_HIGH macro use in patch 02/11 cmdq_pkt_assign() api. This
> api helps assign address bit[47:16] into one of internal register by
> index. And same index could be use in cmdq_pkt_write_s(). The gce
> combine bit[47:16] in internal register and bit[15:0] in addr_low
> parameter to final address. So it is better to keep interface in this
> way.
> 

Got it, but then why don't we call cmdq_pkt_assign() in cmdq_pkt_write_s()? This
way we would get a clean API for what we want to do.
Do we expect other users of cmdq_pkt_assign()? Otherwise we could keep it
private the this file and don't export it.

By the way, why do you postfix the _s, I understand that it reflects the large
DMA access but I wonder why you choose '_s'.

Regards,
Matthias

> 
> Regards,
> Dennis
> 
>>
>> Regards,
>> Matthias
>>
>>> +   struct cmdq_instruction inst = {};
>>> +
>>> +   inst.op = CMDQ_CODE_WRITE_S;
>>> +   inst.src_t = CMDQ_REG_TYPE;
>>> +   inst.sop = high_addr_reg_idx;
>>> +   inst.offset = addr_low;
>>> +   inst.src_reg = src_reg_idx;
>>> +
>>> +   return cmdq_pkt_append_command(pkt, inst);
>>> +}
>>> +EXPORT_SYMBOL(cmdq_pkt_write_s);
>>> +
>>>  int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>>>  {
>>> struct cmdq_instruction inst = { {0} };
>>> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
>>> b/include/linux/mailbox/mtk-cmdq-mailbox.h
>>> index 121c3bb6d3de..ee67dd3b86f5 100644
>>> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
>>> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
>>> @@ -59,6 +59,7 @@ enum cmdq_code {
>>> CMDQ_CODE_JUMP = 0x10,
>>> CMDQ_CODE_WFE = 0x20,
>>> CMDQ_CODE_EOC = 0x40,
>>> +   CMDQ_CODE_WRITE_S = 0x90,
>>> CMDQ_CODE_LOGIC = 0xa0,
>>>  };
>>>  
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
>>> b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index 83340211e1d3..e1c5a7549b4f 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -12,6 +12,8 @@
>>>  #include 
>>>  
>>>  #define CMDQ_NO_TIMEOUT0xu
>>> +#define CMDQ_ADDR_HIGH(addr)   ((u32)(((addr) >> 16) & GENMASK(31, 0)))
>>> +#define CMDQ_ADDR_LOW(addr)((u16)(addr) | BIT(1))
>>>  
>>>  struct cmdq_pkt;
>>>  
>>> @@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 
>>> subsys,
>>> u16 offset, u32 value, u32 mask);
>>>  
>>>  /**
>>> + * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
>>> + * @pkt:   the CMDQ packet
>>> + * @high_addr_reg_idx: internal register ID which contains high 
>>> address of pa
>>> + * @addr_low:  low address of pa
>>> + * @src_reg_idx:   the CMDQ internal register ID which cache source value
>>> + *
>>> + * Return: 0 for success; else the error code is returned
>>> + *
>>> + * Support write value to physical address without subsys. Use 
>>> CMDQ_ADDR_HIGH()
>>> + * to get high address and call cmdq_pkt_assign() to assign value into 
>>> internal
>>> + * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter 
>>> when
>>> + * call to this 

Re: [PATCH][next] drm/vmwgfx: Use struct_size() helper

[Roland Scheidegger]

I've commited this to our next branch, thanks!
(I'm actually kind of impressed this can be found automatically...)

Roland

Am 17.06.20 um 23:51 schrieb Gustavo A. R. Silva:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 126f93c0b0b8..3914bfee0533 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1969,7 +1969,7 @@ static int vmw_surface_dirty_alloc(struct vmw_resource 
> *res)
>   num_mip = 1;
>  
>   num_subres = num_layers * num_mip;
> - dirty_size = sizeof(*dirty) + num_subres * sizeof(dirty->boxes[0]);
> + dirty_size = struct_size(dirty, boxes, num_subres);
>   acc_size = ttm_round_pot(dirty_size);
>   ret = ttm_mem_global_alloc(vmw_mem_glob(res->dev_priv),
>  acc_size, );
> 

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

Re: [PATCH v3] drm/mediatek: check plane visibility in atomic_update

[Tomasz Figa]

On Mon, Jun 22, 2020 at 11:31:06PM +0800, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
> 
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Chun-Kuang Hu 
> Change-Id: Id5341d60ddfffc88a38d9db0caa089b2d6a1d29c
> ---
> v3: Address comment
> v2: Add fixes tag
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 25 ++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 

+/- the Change-Id pointed out by Matthias:

Reviewed-by: Tomasz Figa 

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

Re: [PATCH v3] drm/mediatek: check plane visibility in atomic_update

[Matthias Brugger]

On 22/06/2020 17:31, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
> 
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Chun-Kuang Hu 
> Change-Id: Id5341d60ddfffc88a38d9db0caa089b2d6a1d29c

Seems like the Change-Id slipped in now.

Regards,
Matthias

> ---
> v3: Address comment
> v2: Add fixes tag
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 25 ++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c2bd683a87c8..92141a19681b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -164,6 +164,16 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>  true, true);
>  }
>  
> +static void mtk_plane_atomic_disable(struct drm_plane *plane,
> +  struct drm_plane_state *old_state)
> +{
> + struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> +
> + state->pending.enable = false;
> + wmb(); /* Make sure the above parameter is set before update */
> + state->pending.dirty = true;
> +}
> +
>  static void mtk_plane_atomic_update(struct drm_plane *plane,
>   struct drm_plane_state *old_state)
>  {
> @@ -178,6 +188,11 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
>   if (!crtc || WARN_ON(!fb))
>   return;
>  
> + if (!plane->state->visible) {
> + mtk_plane_atomic_disable(plane, old_state);
> + return;
> + }
> +
>   gem = fb->obj[0];
>   mtk_gem = to_mtk_gem_obj(gem);
>   addr = mtk_gem->dma_addr;
> @@ -200,16 +215,6 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
>   state->pending.dirty = true;
>  }
>  
> -static void mtk_plane_atomic_disable(struct drm_plane *plane,
> -  struct drm_plane_state *old_state)
> -{
> - struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> -
> - state->pending.enable = false;
> - wmb(); /* Make sure the above parameter is set before update */
> - state->pending.dirty = true;
> -}
> -
>  static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
>   .prepare_fb = drm_gem_fb_prepare_fb,
>   .atomic_check = mtk_plane_atomic_check,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH libdrm] intel: sync i915_pciids.h with kernel

[Jani Nikula]

On Tue, 16 Jun 2020, ramadevi.ga...@intel.com wrote:
> From: Gandi Ramadevi 
>
> Add DG1 PCI ID

There are no DG1 PCI IDs in kernel. So please don't add them here
either.

BR,
Jani.


>
> Signed-off-by: Gandi Ramadevi 
> ---
>  intel/i915_pciids.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> index 662d8351..724e68a0 100644
> --- a/intel/i915_pciids.h
> +++ b/intel/i915_pciids.h
> @@ -605,4 +605,9 @@
>   INTEL_VGA_DEVICE(0x9AD9, info), \
>   INTEL_VGA_DEVICE(0x9AF8, info)
>  
> +/* DG1 */
> +#define INTEL_DG1_IDS(info) \
> +INTEL_VGA_DEVICE(0x4905, info), \
> +INTEL_VGA_DEVICE(0x4906, info)
> +
>  #endif /* _I915_PCIIDS_H */

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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

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

rtmasura+ker...@hotmail.com changed:

   What|Removed |Added

 CC||rtmasura+ker...@hotmail.com

--- Comment #16 from rtmasura+ker...@hotmail.com ---
Reporting I've had the same issue with kernel 5.7.2 and 5.7.4:

Jun 22 07:10:24 abiggun kernel: general protection fault, probably for
non-canonical address 0xd3d74027d6d8fad4:  [#1] PREEMPT SMP NOPTI
Jun 22 07:10:24 abiggun kernel: CPU: 0 PID: 32680 Comm: kworker/u12:9 Not
tainted 5.7.4-arch1-1 #1
Jun 22 07:10:24 abiggun kernel: Hardware name: System manufacturer System
Product Name/Crosshair IV Formula, BIOS 110208/24/2010
Jun 22 07:10:24 abiggun kernel: Workqueue: events_unbound commit_work
[drm_kms_helper]
Jun 22 07:10:24 abiggun kernel: RIP:
0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu]
Jun 22 07:10:24 abiggun kernel: Code: 4f 08 8b 81 e0 02 00 00 41 83 c5 01 44 39
e8 0f 87 46 ff ff ff 48 83 bd f0 fc ff ff 00 0f 84 03 01 00 00 48 8b bd f0 f>
Jun 22 07:10:24 abiggun kernel: RSP: 0018:b0cc421abaf8 EFLAGS: 00010286
Jun 22 07:10:24 abiggun kernel: RAX: 0006 RBX: a21b8e16c400
RCX: a21cab9c8800
Jun 22 07:10:24 abiggun kernel: RDX: a21ca7326200 RSI: c10de1a0
RDI: d3d74027d6d8fad4
Jun 22 07:10:24 abiggun kernel: RBP: b0cc421abe60 R08: 0001
R09: 0001
Jun 22 07:10:24 abiggun kernel: R10: 02be R11: 001c57a1
R12: 
Jun 22 07:10:24 abiggun kernel: R13: 0006 R14: a218e4959800
R15: a219e5b12780
Jun 22 07:10:24 abiggun kernel: FS:  ()
GS:a21cbfc0() knlGS:
Jun 22 07:10:24 abiggun kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jun 22 07:10:24 abiggun kernel: CR2: 7fec2b573008 CR3: 000344bd8000
CR4: 06f0
Jun 22 07:10:24 abiggun kernel: Call Trace:
Jun 22 07:10:24 abiggun kernel:  ? cpumask_next_and+0x19/0x20
Jun 22 07:10:24 abiggun kernel:  ? update_sd_lb_stats.constprop.0+0x115/0x8f0
Jun 22 07:10:24 abiggun kernel:  ? __update_load_avg_cfs_rq+0x277/0x2f0
Jun 22 07:10:24 abiggun kernel:  ? update_load_avg+0x58f/0x660
Jun 22 07:10:24 abiggun kernel:  ? update_curr+0x108/0x1f0
Jun 22 07:10:24 abiggun kernel:  ? __switch_to_asm+0x34/0x70
Jun 22 07:10:24 abiggun kernel:  ? __switch_to_asm+0x40/0x70
Jun 22 07:10:24 abiggun kernel:  ? __switch_to_asm+0x34/0x70
Jun 22 07:10:24 abiggun kernel:  ? __switch_to_asm+0x40/0x70
Jun 22 07:10:24 abiggun kernel:  ? rescuer_thread+0x3f0/0x3f0
Jun 22 07:10:24 abiggun kernel:  commit_tail+0x94/0x130 [drm_kms_helper]
Jun 22 07:10:24 abiggun kernel:  process_one_work+0x1da/0x3d0
Jun 22 07:10:24 abiggun kernel:  ? rescuer_thread+0x3f0/0x3f0
Jun 22 07:10:24 abiggun kernel:  worker_thread+0x4d/0x3e0
Jun 22 07:10:24 abiggun kernel:  ? rescuer_thread+0x3f0/0x3f0
Jun 22 07:10:24 abiggun kernel:  kthread+0x13e/0x160
Jun 22 07:10:24 abiggun kernel:  ? __kthread_bind_mask+0x60/0x60
Jun 22 07:10:24 abiggun kernel:  ret_from_fork+0x22/0x40
Jun 22 07:10:24 abiggun kernel: Modules linked in: snd_usb_audio
snd_usbmidi_lib snd_rawmidi hid_plantronics mc vhost_net vhost tap vhost_iotlb
snd_seq_dumm>
Jun 22 07:10:24 abiggun kernel:  crypto_simd cryptd glue_helper xts dm_crypt
hid_generic usbhid hid raid456 libcrc32c crc32c_generic async_raid6_recov
async>
Jun 22 07:10:24 abiggun kernel: ---[ end trace 536cfe34e3c36293 ]---
Jun 22 07:10:24 abiggun kernel: RIP:
0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu]
Jun 22 07:10:24 abiggun kernel: Code: 4f 08 8b 81 e0 02 00 00 41 83 c5 01 44 39
e8 0f 87 46 ff ff ff 48 83 bd f0 fc ff ff 00 0f 84 03 01 00 00 48 8b bd f0 f>
Jun 22 07:10:25 abiggun kernel: RSP: 0018:b0cc421abaf8 EFLAGS: 00010286
Jun 22 07:10:25 abiggun kernel: RAX: 0006 RBX: a21b8e16c400
RCX: a21cab9c8800
Jun 22 07:10:25 abiggun kernel: RDX: a21ca7326200 RSI: c10de1a0
RDI: d3d74027d6d8fad4
Jun 22 07:10:25 abiggun kernel: RBP: b0cc421abe60 R08: 0001
R09: 0001
Jun 22 07:10:25 abiggun kernel: R10: 02be R11: 001c57a1
R12: 
Jun 22 07:10:25 abiggun kernel: R13: 0006 R14: a218e4959800
R15: a219e5b12780
Jun 22 07:10:25 abiggun kernel: FS:  ()
GS:a21cbfc0() knlGS:
Jun 22 07:10:25 abiggun kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jun 22 07:10:25 abiggun kernel: CR2: 7fec2b573008 CR3: 000344bd8000
CR4: 06f0

-- 
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 v2] drm/mediatek: check plane visibility in atomic_update

[Tomasz Figa]

Hi Hsin-Yi,

On Mon, Jun 22, 2020 at 11:01:09PM +0800, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
> 
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Chun-Kuang Hu 
> ---
> v2: Add fixes tag
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 

Thank you for the patch. Please see my comments inline.

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c2bd683a87c8..74dc71c7f3b6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -164,6 +164,16 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>  true, true);
>  }
>  
> +static void mtk_plane_atomic_disable(struct drm_plane *plane,
> +  struct drm_plane_state *old_state)
> +{
> + struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> +
> + state->pending.enable = false;
> + wmb(); /* Make sure the above parameter is set before update */
> + state->pending.dirty = true;
> +}
> +
>  static void mtk_plane_atomic_update(struct drm_plane *plane,
>   struct drm_plane_state *old_state)
>  {
> @@ -178,6 +188,9 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
>   if (!crtc || WARN_ON(!fb))
>   return;
>  
> + if (!plane->state->visible)
> + return mtk_plane_atomic_disable(plane, old_state);

nit: Both this function and mtk_plane_atomic_disable() have the void return
type. Perhaps we should rather move the return, without a value, to a
separate statement?

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

Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Sam Ravnborg]

Hi Deepak

On Mon, Jun 22, 2020 at 04:06:22AM -0700, Deepak Rawat wrote:
> DRM driver for hyperv synthetic video device, based on hyperv_fb
> framebuffer driver. Also added config option "DRM_HYPERV" to enabled
> this driver.

Just a buch of drive-by comments while browsing the code.
In general code looks good, especialyl for a v1.

There is a few places that triggers warnings with checkpatch --strict
Most looks like things that should be fixed.


Sam

> 
> Signed-off-by: Deepak Rawat 
> ---
>  drivers/gpu/drm/tiny/Kconfig  |9 +
>  drivers/gpu/drm/tiny/Makefile |1 +
>  drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
>  3 files changed, 1017 insertions(+)
>  create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c
> 
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 2b6414f0fa75..e6d53e60a9c2 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -28,6 +28,15 @@ config DRM_GM12U320
>This is a KMS driver for projectors which use the GM12U320 chipset
>for video transfer over USB2/3, such as the Acer C120 mini projector.
>  
> +config DRM_HYPERV
> + tristate "DRM Support for hyperv synthetic video device"
> + depends on DRM && PCI && MMU && HYPERV
> + select DRM_KMS_HELPER
> + select DRM_GEM_SHMEM_HELPER
> + help
> +  This is a KMS driver for for hyperv synthetic video device.
> +  If M is selected the module will be called hyperv_drm.
> +
>  config TINYDRM_HX8357D
>   tristate "DRM support for HX8357D display panels"
>   depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
> index 6ae4e9e5a35f..837cb2c2637e 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -2,6 +2,7 @@
>  
>  obj-$(CONFIG_DRM_CIRRUS_QEMU)+= cirrus.o
>  obj-$(CONFIG_DRM_GM12U320)   += gm12u320.o
> +obj-$(CONFIG_DRM_HYPERV) += hyperv_drm.o
>  obj-$(CONFIG_TINYDRM_HX8357D)+= hx8357d.o
>  obj-$(CONFIG_TINYDRM_ILI9225)+= ili9225.o
>  obj-$(CONFIG_TINYDRM_ILI9341)+= ili9341.o
> diff --git a/drivers/gpu/drm/tiny/hyperv_drm.c 
> b/drivers/gpu/drm/tiny/hyperv_drm.c
> new file mode 100644
> index ..3d020586056e
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/hyperv_drm.c
> @@ -0,0 +1,1007 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2012-2020 Microsoft
> + *
> + * Authors:
> + * Deepak Rawat 
> + *
> + * Portions of this code is derived from hyperv_fb.c
> + * drivers/video/fbdev/hyperv_fb.c - framebuffer driver for hyperv synthetic
> + * video device.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
Alphabetic order.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Needed?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

> +
> +#define DRIVER_NAME "hyperv_drm"
> +#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
> +#define DRIVER_DATE "2020"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +#define VMBUS_MAX_PACKET_SIZE 0x4000
> +#define VMBUS_RING_BUFSIZE (256 * 1024)
> +#define VMBUS_VSP_TIMEOUT (10 * HZ)
> +
> +#define PCI_VENDOR_ID_MICROSOFT 0x1414
> +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> +
> +struct hyperv_device {

This is much more than a device - maybe just name it "struct hv"?

> + /* drm */
> + struct drm_device dev;
> + struct drm_simple_display_pipe pipe;
> + struct drm_connector connector;
> +
> + /* mode */
> + u32 screen_width_max;
> + u32 screen_height_max;
> + u32 preferred_width;
> + u32 preferred_height;
> + u32 screen_depth;
> +
> + /* hw */
> + void __iomem *vram;
> + unsigned long fb_base;
> + unsigned long fb_size;
> + struct completion wait;
> + u32 synthvid_version;
> + u32 mmio_megabytes;
> + bool init_done;
> +
> + u8 init_buf[VMBUS_MAX_PACKET_SIZE];
> + u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
> +
> + struct hv_device *hdev;
> +};
> +
> +#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev)
> +
> +/* -- */
> +/* Hyper-V Synthetic Video Protocol   */
> +
> +#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
> +#define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x)
> +#define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0x) >> 16)
> +#define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
> +#define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
> +#define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
> +
> +#define SYNTHVID_DEPTH_WIN7 16
> +#define SYNTHVID_DEPTH_WIN8 32
> +#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
> +#define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
> +#define SYNTHVID_WIDTH_MAX_WIN7 1600
> 

Re: [PATCH] drm/mgag200: Enable caching for SHMEM pages

[Thomas Zimmermann]

Hi

Am 22.06.20 um 17:00 schrieb Rong Chen:
> Hi Thomas,
> 
> I tested the patch based on commit 24b806b0a1dd3, the regression

Thanks!

> of phoronix-test-suite.glmark2.1024x768.score still exists:

I expected that the test is related to drawing onto the screen. Do you
know what exactly it is testing?

Best regards
Thomas

> 
> 1f58fcaf27cb7 drm/mgag200: Enable caching for SHMEM pages 
>2 2 2
> 24b806b0a1dd3 drm-tip: 2020y-06m-22d-07h-52m-06s UTC integration manifest 
>2 2 2 2 2
> 913ec479bb5cc drm/mgag200: Replace VRAM helpers with SHMEM helpers
>2 2 2 2 2
> 88fabb75ea9ed drm/mgag200: Convert to simple KMS helper   
>165 168 167 165 164
> 
> Best Regards,
> Rong Chen
> 
> On Thu, Jun 18, 2020 at 03:34:35PM +0200, Thomas Zimmermann wrote:
>> We've had reports about performance regressions after switching
>> mgag200 from VRAM helpers to SHMEM helpers. SHMEM pages use
>> writecombine caching by default, but can also use the platform's
>> default page caching. Doing so improves the performance of I/O
>> on the framebuffer.
>>
>> Mgag200's hardware does not access framebuffer pages directly (i.e.,
>> via DMA), so enabling caching does not have an effect on consistency
>> of the framebuffer memory or the displayed data.
>>
>> Signed-off-by: Thomas Zimmermann 
>> Fixes: 913ec479bb5c ("drm/mgag200: Replace VRAM helpers with SHMEM helpers")
>> Cc: Thomas Zimmermann 
>> Cc: Emil Velikov 
>> Cc: Dave Airlie 
>> Cc: Daniel Vetter 
>> Cc: Krzysztof Kozlowski 
>> Cc: Gerd Hoffmann 
>> Cc: Sam Ravnborg 
>> Cc: Rong Chen 
>> Cc: John Donnelly 
>> Link: https://lore.kernel.org/dri-devel/20200617092252.GA5279@shao2-debian/
>> ---
>>  drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
>> b/drivers/gpu/drm/mgag200/mgag200_drv.c
>> index e19660f4a637..7189c7745baf 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
>> @@ -36,6 +36,7 @@ static struct drm_driver mgag200_driver = {
>>  .major = DRIVER_MAJOR,
>>  .minor = DRIVER_MINOR,
>>  .patchlevel = DRIVER_PATCHLEVEL,
>> +.gem_create_object = drm_gem_shmem_create_object_cached,
>>  DRM_GEM_SHMEM_DRIVER_OPS,
>>  };
>>  
>> -- 
>> 2.27.0
>>

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



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

Re: [PATCH] drm/mgag200: Enable caching for SHMEM pages

[Rong Chen]

Hi Thomas,

I tested the patch based on commit 24b806b0a1dd3, the regression
of phoronix-test-suite.glmark2.1024x768.score still exists:

1f58fcaf27cb7 drm/mgag200: Enable caching for SHMEM pages   
 2 2 2
24b806b0a1dd3 drm-tip: 2020y-06m-22d-07h-52m-06s UTC integration manifest   
 2 2 2 2 2
913ec479bb5cc drm/mgag200: Replace VRAM helpers with SHMEM helpers  
 2 2 2 2 2
88fabb75ea9ed drm/mgag200: Convert to simple KMS helper 
 165 168 167 165 164

Best Regards,
Rong Chen

On Thu, Jun 18, 2020 at 03:34:35PM +0200, Thomas Zimmermann wrote:
> We've had reports about performance regressions after switching
> mgag200 from VRAM helpers to SHMEM helpers. SHMEM pages use
> writecombine caching by default, but can also use the platform's
> default page caching. Doing so improves the performance of I/O
> on the framebuffer.
> 
> Mgag200's hardware does not access framebuffer pages directly (i.e.,
> via DMA), so enabling caching does not have an effect on consistency
> of the framebuffer memory or the displayed data.
> 
> Signed-off-by: Thomas Zimmermann 
> Fixes: 913ec479bb5c ("drm/mgag200: Replace VRAM helpers with SHMEM helpers")
> Cc: Thomas Zimmermann 
> Cc: Emil Velikov 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Krzysztof Kozlowski 
> Cc: Gerd Hoffmann 
> Cc: Sam Ravnborg 
> Cc: Rong Chen 
> Cc: John Donnelly 
> Link: https://lore.kernel.org/dri-devel/20200617092252.GA5279@shao2-debian/
> ---
>  drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> index e19660f4a637..7189c7745baf 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -36,6 +36,7 @@ static struct drm_driver mgag200_driver = {
>   .major = DRIVER_MAJOR,
>   .minor = DRIVER_MINOR,
>   .patchlevel = DRIVER_PATCHLEVEL,
> + .gem_create_object = drm_gem_shmem_create_object_cached,
>   DRM_GEM_SHMEM_DRIVER_OPS,
>  };
>  
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v1 3/3] Revert "drm/amd/display: Expose connector VRR range via debugfs"

[Kazlauskas, Nicholas]

On 2020-06-22 10:25 a.m., Bhanuprakash Modem wrote:

As both VRR min and max are already part of drm_display_info,
drm can expose this VRR range for each connector.

Hence this logic should move to core DRM.

This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.

Signed-off-by: Bhanuprakash Modem 
Cc: Nicholas Kazlauskas 
Cc: Harry Wentland 
Cc: Alex Deucher 
Cc: Manasi Navare 
Cc: AMD gfx 



Looks good to me with Patch 2 part of the series.

Reviewed-by: Nicholas Kazlauskas 

Thanks,
Nicholas Kazlauskas


---
  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 20 ---
  1 file changed, 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 076af267b488..71387d2af2ed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -820,24 +820,6 @@ static int output_bpc_show(struct seq_file *m, void *data)
return res;
  }
  
-/*

- * Returns the min and max vrr vfreq through the connector's debugfs file.
- * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
- */
-static int vrr_range_show(struct seq_file *m, void *data)
-{
-   struct drm_connector *connector = m->private;
-   struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
-
-   if (connector->status != connector_status_connected)
-   return -ENODEV;
-
-   seq_printf(m, "Min: %u\n", (unsigned int)aconnector->min_vfreq);
-   seq_printf(m, "Max: %u\n", (unsigned int)aconnector->max_vfreq);
-
-   return 0;
-}
-
  #ifdef CONFIG_DRM_AMD_DC_HDCP
  /*
   * Returns the HDCP capability of the Display (1.4 for now).
@@ -1001,7 +983,6 @@ static ssize_t dp_dpcd_data_read(struct file *f, char 
__user *buf,
  DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
  DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
  DEFINE_SHOW_ATTRIBUTE(output_bpc);
-DEFINE_SHOW_ATTRIBUTE(vrr_range);
  #ifdef CONFIG_DRM_AMD_DC_HDCP
  DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
  #endif
@@ -1059,7 +1040,6 @@ static const struct {
{"phy_settings", _phy_settings_debugfs_fop},
{"test_pattern", _phy_test_pattern_fops},
{"output_bpc", _bpc_fops},
-   {"vrr_range", _range_fops},
  #ifdef CONFIG_DRM_AMD_DC_HDCP
{"hdcp_sink_capability", _sink_capability_fops},
  #endif



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

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Andrey Grodzovsky]

On 6/22/20 9:18 AM, Christian König wrote:

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Will be used to reroute CPU mapped BO's page faults once
device is removed.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_file.c  |  8 
  drivers/gpu/drm/drm_prime.c | 10 ++
  include/drm/drm_file.h  |  2 ++
  include/drm/drm_gem.h   |  2 ++
  4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c4c704e..67c0770 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct drm_minor 
*minor)

  goto out_prime_destroy;
  }
  +    file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+    if (!file->dummy_page) {
+    ret = -ENOMEM;
+    goto out_prime_destroy;
+    }
+
  return file;
    out_prime_destroy:
@@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
  if (dev->driver->postclose)
  dev->driver->postclose(dev, file);
  +    __free_page(file->dummy_page);
+
  drm_prime_destroy_file_private(>prime);
    WARN_ON(!list_empty(>event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1de2cde..c482e9c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device 
*dev,

    ret = drm_prime_add_buf_handle(_priv->prime,
  dma_buf, *handle);
+
+    if (!ret) {
+    obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+    if (!obj->dummy_page)
+    ret = -ENOMEM;
+    }
+


While the per file case still looks acceptable this is a clear NAK 
since it will massively increase the memory needed for a prime 
exported object.


I think that this is quite overkill in the first place and for the hot 
unplug case we can just use the global dummy page as well.


Christian.



Global dummy page is good for read access, what do you do on write 
access ? My first approach was indeed to map at first global dummy page 
as read only and mark the vma->vm_flags as !VM_SHARED assuming that this 
would trigger Copy On Write flow in core mm 
(https://elixir.bootlin.com/linux/v5.7-rc7/source/mm/memory.c#L3977) on 
the next page fault to same address triggered by a write access but then 
i realized a new COW page will be allocated for each such mapping and 
this is much more wasteful then having a dedicated page per GEM object. 
We can indeed optimize by allocating this dummy page on the first page 
fault after device disconnect instead on GEM object creation.


Andrey





mutex_unlock(_priv->prime.lock);
  if (ret)
  goto fail;
@@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct 
drm_gem_object *obj, struct sg_table *sg)

  dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
  dma_buf = attach->dmabuf;
  dma_buf_detach(attach->dmabuf, attach);
+
+    __free_page(obj->dummy_page);
+
  /* remove the reference */
  dma_buf_put(dma_buf);
  }
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 19df802..349a658 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -335,6 +335,8 @@ struct drm_file {
   */
  struct drm_prime_file_private prime;
  +    struct page *dummy_page;
+
  /* private: */
  #if IS_ENABLED(CONFIG_DRM_LEGACY)
  unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b37506..47460d1 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -310,6 +310,8 @@ struct drm_gem_object {
   *
   */
  const struct drm_gem_object_funcs *funcs;
+
+    struct page *dummy_page;
  };
    /**



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

Re: [PATCH] drm/vmwgfx: Use __drm_atomic_helper_crtc_reset

[Roland Scheidegger]

Looks great to me.
Reviewed-by: Roland Scheidegger 

Am 12.06.20 um 22:49 schrieb Daniel Vetter:
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
> 
> v2: Compile fix. Oops.
> 
> Signed-off-by: Daniel Vetter 
> Cc: VMware Graphics 
> Cc: Roland Scheidegger 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 3c97654b5a43..bbce45d142aa 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -629,8 +629,7 @@ void vmw_du_crtc_reset(struct drm_crtc *crtc)
>   return;
>   }
>  
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> + __drm_atomic_helper_crtc_reset(crtc, >base);
>  }
>  
>  
> 

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

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Pekka Paalanen]

On Mon, 22 Jun 2020 16:24:38 +0200
Daniel Vetter  wrote:

> On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen  wrote:
> >
> > On Mon, 22 Jun 2020 11:35:01 +0200
> > Daniel Vetter  wrote:
> >  
> > > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:  
> > > > Will be used to reroute CPU mapped BO's page faults once
> > > > device is removed.
> > > >
> > > > Signed-off-by: Andrey Grodzovsky 
> > > > ---
> > > >  drivers/gpu/drm/drm_file.c  |  8 
> > > >  drivers/gpu/drm/drm_prime.c | 10 ++
> > > >  include/drm/drm_file.h  |  2 ++
> > > >  include/drm/drm_gem.h   |  2 ++
> > > >  4 files changed, 22 insertions(+)  
> >
> > ...
> >  
> > > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > > index 0b37506..47460d1 100644
> > > > --- a/include/drm/drm_gem.h
> > > > +++ b/include/drm/drm_gem.h
> > > > @@ -310,6 +310,8 @@ struct drm_gem_object {
> > > >  *
> > > >  */
> > > > const struct drm_gem_object_funcs *funcs;
> > > > +
> > > > +   struct page *dummy_page;
> > > >  };  
> > >
> > > I think amdgpu doesn't care, but everyone else still might care somewhat
> > > about flink. That also shares buffers, so also needs to allocate the
> > > per-bo dummy page.  
> >
> > Do you really care about making flink not explode on device
> > hot-unplug? Why not just leave flink users die in a fire?
> > It's not a regression.  
> 
> It's not about exploding, they won't. With flink you can pass a buffer
> from one address space to the other, so imo we should avoid false
> sharing. E.g. if you happen to write something $secret into a private
> buffer, but only $non-secret stuff into shared buffers. Then if you
> unplug, your well-kept $secret might suddenly be visible by lots of
> other processes you never intended to share it with.
> 
> Just feels safer to plug that hole completely.

Ah! Ok, I clearly didn't understand the consequences.


Thanks,
pq


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

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Daniel Vetter]

On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen  wrote:
>
> On Mon, 22 Jun 2020 11:35:01 +0200
> Daniel Vetter  wrote:
>
> > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > > Will be used to reroute CPU mapped BO's page faults once
> > > device is removed.
> > >
> > > Signed-off-by: Andrey Grodzovsky 
> > > ---
> > >  drivers/gpu/drm/drm_file.c  |  8 
> > >  drivers/gpu/drm/drm_prime.c | 10 ++
> > >  include/drm/drm_file.h  |  2 ++
> > >  include/drm/drm_gem.h   |  2 ++
> > >  4 files changed, 22 insertions(+)
>
> ...
>
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 0b37506..47460d1 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -310,6 +310,8 @@ struct drm_gem_object {
> > >  *
> > >  */
> > > const struct drm_gem_object_funcs *funcs;
> > > +
> > > +   struct page *dummy_page;
> > >  };
> >
> > I think amdgpu doesn't care, but everyone else still might care somewhat
> > about flink. That also shares buffers, so also needs to allocate the
> > per-bo dummy page.
>
> Do you really care about making flink not explode on device
> hot-unplug? Why not just leave flink users die in a fire?
> It's not a regression.

It's not about exploding, they won't. With flink you can pass a buffer
from one address space to the other, so imo we should avoid false
sharing. E.g. if you happen to write something $secret into a private
buffer, but only $non-secret stuff into shared buffers. Then if you
unplug, your well-kept $secret might suddenly be visible by lots of
other processes you never intended to share it with.

Just feels safer to plug that hole completely.
-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 v2 1/8] drm: Add dummy page per device or GEM object

[Daniel Vetter]

On Mon, Jun 22, 2020 at 3:18 PM Christian König
 wrote:
>
> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> > Will be used to reroute CPU mapped BO's page faults once
> > device is removed.
> >
> > Signed-off-by: Andrey Grodzovsky 
> > ---
> >   drivers/gpu/drm/drm_file.c  |  8 
> >   drivers/gpu/drm/drm_prime.c | 10 ++
> >   include/drm/drm_file.h  |  2 ++
> >   include/drm/drm_gem.h   |  2 ++
> >   4 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index c4c704e..67c0770 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct drm_minor 
> > *minor)
> >   goto out_prime_destroy;
> >   }
> >
> > + file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > + if (!file->dummy_page) {
> > + ret = -ENOMEM;
> > + goto out_prime_destroy;
> > + }
> > +
> >   return file;
> >
> >   out_prime_destroy:
> > @@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
> >   if (dev->driver->postclose)
> >   dev->driver->postclose(dev, file);
> >
> > + __free_page(file->dummy_page);
> > +
> >   drm_prime_destroy_file_private(>prime);
> >
> >   WARN_ON(!list_empty(>event_list));
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 1de2cde..c482e9c 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> >
> >   ret = drm_prime_add_buf_handle(_priv->prime,
> >   dma_buf, *handle);
> > +
> > + if (!ret) {
> > + obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > + if (!obj->dummy_page)
> > + ret = -ENOMEM;
> > + }
> > +
>
> While the per file case still looks acceptable this is a clear NAK since
> it will massively increase the memory needed for a prime exported object.
>
> I think that this is quite overkill in the first place and for the hot
> unplug case we can just use the global dummy page as well.

Imo we either don't bother with per-file dummy page, or we need this.
Half-way doesn't make much sense, since for anything you dma-buf
exported you have no idea whether it left a sandbox or not.

E.g. anything that's shared between client/compositor has a different
security context, so picking the dummy page of either is the wrong
thing.

If you're worried about the overhead we can also allocate the dummy
page on demand, and SIGBUS if we can't allocate the right one. Then we
just need to track whether a buffer has ever been exported.
-Daniel

>
> Christian.
>
> >   mutex_unlock(_priv->prime.lock);
> >   if (ret)
> >   goto fail;
> > @@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct drm_gem_object 
> > *obj, struct sg_table *sg)
> >   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> >   dma_buf = attach->dmabuf;
> >   dma_buf_detach(attach->dmabuf, attach);
> > +
> > + __free_page(obj->dummy_page);
> > +
> >   /* remove the reference */
> >   dma_buf_put(dma_buf);
> >   }
> > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> > index 19df802..349a658 100644
> > --- a/include/drm/drm_file.h
> > +++ b/include/drm/drm_file.h
> > @@ -335,6 +335,8 @@ struct drm_file {
> >*/
> >   struct drm_prime_file_private prime;
> >
> > + struct page *dummy_page;
> > +
> >   /* private: */
> >   #if IS_ENABLED(CONFIG_DRM_LEGACY)
> >   unsigned long lock_count; /* DRI1 legacy lock count */
> > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > index 0b37506..47460d1 100644
> > --- a/include/drm/drm_gem.h
> > +++ b/include/drm/drm_gem.h
> > @@ -310,6 +310,8 @@ struct drm_gem_object {
> >*
> >*/
> >   const struct drm_gem_object_funcs *funcs;
> > +
> > + struct page *dummy_page;
> >   };
> >
> >   /**
>


-- 
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] dt-bindings: backlight: Convert common backlight bindings to DT schema

[Daniel Thompson]

On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote:
> Convert the common GPIO, LED, and PWM backlight bindings to DT schema
> format.
> 
> Given there's only 2 common properties and the descriptions are slightly
> different, I opted to not create a common backlight schema.
> 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Signed-off-by: Rob Herring 

...


> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> new file mode 100644
> index ..ae50945d2798
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/led-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: led-backlight bindings
> +
> +maintainers:
> +  - Lee Jones 
> +  - Daniel Thompson 
> +  - Jingoo Han 
> +
> +description:
> +  This binding is used to describe a basic backlight device made of LEDs. It
> +  can also be used to describe a backlight device controlled by the output of
> +  a LED driver.
> +
> +properties:
> +  compatible:
> +const: led-backlight
> +
> +  leds:
> +description: A list of LED nodes
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  brightness-levels:
> +description: Array of distinct brightness levels. The levels must be
> +  in the range accepted by the underlying LED devices. This is used
> +  to translate a backlight brightness level into a LED brightness level.
> +  If it is not provided, the identity mapping is used.
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  default-brightness-level:
> +description: The default brightness level (index into the array defined
> +  by the "brightness-levels" property).
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> +dependencies:
> +  default-brightness-level: [brightness-levels]

I don't think there is a dependency here. default-brightness-level still
makes sense with there is no mapping table present.

Based on Sam's feedback perhaps adding ("if one is provided") to the
parenthetic text.


> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> new file mode 100644
> index ..7e1f109a38a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> @@ -0,0 +1,98 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: pwm-backlight bindings
> +
> +maintainers:
> +  - Lee Jones 
> +  - Daniel Thompson 
> +  - Jingoo Han 
> +
> +properties:
> +  compatible:
> +const: pwm-backlight
> +
> +  pwms:
> +maxItems: 1
> +
> +  pwm-names: true
> +
> +  power-supply:
> +description: regulator for supply voltage
> +
> +  enable-gpios:
> +description: Contains a single GPIO specifier for the GPIO which enables
> +  and disables the backlight
> +maxItems: 1
> +
> +  post-pwm-on-delay-ms:
> +description: Delay in ms between setting an initial (non-zero) PWM and
> +  enabling the backlight using GPIO.
> +
> +  pwm-off-delay-ms:
> +description: Delay in ms between disabling the backlight using GPIO
> +  and setting PWM value to 0.
> +
> +  brightness-levels:
> +description: Array of distinct brightness levels. Typically these are
> +  in the range from 0 to 255, but any range starting at 0 will do. The
> +  actual brightness level (PWM duty cycle) will be interpolated from
> +  these values. 0 means a 0% duty cycle (darkest/off), while the last
> +  value in the array represents a 100% duty cycle (brightest).
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  default-brightness-level:
> +description: The default brightness level (index into the array defined
> +  by the "brightness-levels" property).
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> +  num-interpolated-steps:
> +description: Number of interpolated steps between each value of 
> brightness-levels
> +  table. This way a high resolution pwm duty cycle can be used without
> +  having to list out every possible value in the brightness-level array.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> +dependencies:
> +  default-brightness-level: [brightness-levels]
> +  num-interpolated-steps: [brightness-levels]

Just for the record, these dependencies are OK. Iit isn't really a good
idea to map 1:1 to a PWM since we end up with a gazillion
indistinguishable levels so the bindings (and the driver) to not allow
such a mode.


Daniel.
___
dri-devel mailing list

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Pekka Paalanen]

On Mon, 22 Jun 2020 11:35:01 +0200
Daniel Vetter  wrote:

> On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > Will be used to reroute CPU mapped BO's page faults once
> > device is removed.
> > 
> > Signed-off-by: Andrey Grodzovsky 
> > ---
> >  drivers/gpu/drm/drm_file.c  |  8 
> >  drivers/gpu/drm/drm_prime.c | 10 ++
> >  include/drm/drm_file.h  |  2 ++
> >  include/drm/drm_gem.h   |  2 ++
> >  4 files changed, 22 insertions(+)

...

> > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > index 0b37506..47460d1 100644
> > --- a/include/drm/drm_gem.h
> > +++ b/include/drm/drm_gem.h
> > @@ -310,6 +310,8 @@ struct drm_gem_object {
> >  *
> >  */
> > const struct drm_gem_object_funcs *funcs;
> > +
> > +   struct page *dummy_page;
> >  };  
> 
> I think amdgpu doesn't care, but everyone else still might care somewhat
> about flink. That also shares buffers, so also needs to allocate the
> per-bo dummy page.

Do you really care about making flink not explode on device
hot-unplug? Why not just leave flink users die in a fire?
It's not a regression.


Thanks,
pq


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

RE: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem

[Venkateshwar Rao Gannavarapu]

Hi Laurent,

Thanks for the comment.

>-Original Message-
>From: Laurent Pinchart 
>Sent: Wednesday, June 17, 2020 3:18 AM
>To: Venkateshwar Rao Gannavarapu 
>Cc: Hyun Kwon ; dri-devel@lists.freedesktop.org;
>airl...@linux.ie; dan...@ffwll.ch; linux-ker...@vger.kernel.org; Sandip Kothari
>; Vishal Sagar 
>Subject: Re: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem
>
>Hi GVRao,
>
>Sorry for the delayed reply.
>
>On Tue, Jun 09, 2020 at 02:48:25AM +, Venkateshwar Rao Gannavarapu
>wrote:
>> Hi Laurent,
>>
>> Thanks for the review.
>> Please see my comments about D-PHY and bridge driver implementation.
>>
>> On Sunday, June 7, 2020 7:55 AM, Laurent Pinchart wrote:
>> > On Sun, May 31, 2020 at 05:41:50PM +, Venkateshwar Rao
>Gannavarapu wrote:
>> >> On Sunday, May 24, 2020 8:38 AM, Laurent Pinchart wrote:
>> >>> On Mon, May 04, 2020 at 11:43:48AM -0700, Hyun Kwon wrote:
>>  On Mon, 2020-04-20 at 14:20:56 -0700, Venkateshwar Rao Gannavarapu
>wrote:
>> > The Xilinx MIPI DSI Tx Subsystem soft IP is used to display
>> > video data from AXI-4 stream interface.
>> >
>> > It supports upto 4 lanes, optional register interface for the
>> > DPHY,
>> 
>>  I don't see the register interface for dphy support.
>> >>>
>> >>> I think the D-PHY should be supported through a PHY driver, as it
>> >>> seems to be shared between different subsystems.
>> >>
>> >> IP has the provision to read DPHY register for debug purpose only.
>> >> No programming of DPHY is required in subsystem.
>> >
>> > Do you know if this is the same D-PHY as used in the CSI2-RX subsystem ?
>>
>> Same D-PHY core has been used in MIPI CSI2 RXSS, but with different
>configuration.
>>
>> > multiple RGB color formats, command mode and video mode.
>> > This is a MIPI-DSI host driver and provides DSI bus for panels.
>> > This driver also helps to communicate with its panel using panel
>> > framework.
>> >
>> > Signed-off-by: Venkateshwar Rao Gannavarapu
>> > 
>> > ---
>> >  drivers/gpu/drm/xlnx/Kconfig|  11 +
>> >  drivers/gpu/drm/xlnx/Makefile   |   2 +
>> >  drivers/gpu/drm/xlnx/xlnx_dsi.c | 755
>> > 
>> >>>
>> >>> Daniel Vetter has recently expressed his opiion that bridge
>> >>> drivers should go to drivers/gpu/drm/bridge/. It would then be
>> >>> drivers/gpu/drm/bridge/xlnx/. I don't have a strong opinion myself.
>>
>> The DSI-TX subsystem IP block is not a bridge driver.
>> The DSI-TX subsystem IP block itself contains all the drm
>> encoder/connector functionality and it’s the last node in display pipe line.
>
>The DSI-TX subsystem IP block is indeed an encoder from a hardware point of
>view, but it's not necessarily the last block in the display pipeline. While 
>the
>output of the IP core goes of the the SoC, tt would be entirely feasible to
>connect it to a DP to HDMI bridge on the board, such as the ANX7737 ([1]) for
>instance. This is why we're pushing for all encoder (from a hardware point of
>view) drivers to be implemented as DRM bridge, in order to make them usable
>in different display pipelines, without hardcoding the assumption they will be
>the last encoder in the pipeline.

Thanks for the details.
I can understand it as SoC requirement where crtc is fixed, but as a FPGA 
product
encoder driver should work with any of crtc driver.  And I still not see bridge 
implementation as hard requirement.
Could you please explain what problem we face, if implemented as encoder driver.
>
>> I didn't see any hard
>> requirement to implement it into bridge driver and I see many DSI
>> drivers are implemented as encoder drivers.
>> Xilinx PL DRM encoder drivers are implemented in modular approach so
>> that they can work with any CRTC driver which handles the DMA calls.
>> So, at this stage we want to upstream as encoder driver only.
>>
>> >  3 files changed, 768 insertions(+)  create mode 100644
>> > drivers/gpu/drm/xlnx/xlnx_dsi.c
>
>[1] https://www.analogix.com/en/products/convertersbridges/anx7737
>
>--
>Regards,
>
>Laurent Pinchart

Regards,
GVRao
 

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

Re: [PATCH] drm/mediatek: check plane visibility in atomic_update

[Chun-Kuang Hu]

Hi, Hsin-Yi:

Hsin-Yi Wang  於 2020年6月22日 週一 下午1:32寫道：
>
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.

Except the Fixes tag,

Reviewed-by: Chun-Kuang Hu 

>
> Signed-off-by: Hsin-Yi Wang 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c2bd683a87c8..74dc71c7f3b6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -164,6 +164,16 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>true, true);
>  }
>
> +static void mtk_plane_atomic_disable(struct drm_plane *plane,
> +struct drm_plane_state *old_state)
> +{
> +   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> +
> +   state->pending.enable = false;
> +   wmb(); /* Make sure the above parameter is set before update */
> +   state->pending.dirty = true;
> +}
> +
>  static void mtk_plane_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
>  {
> @@ -178,6 +188,9 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
> if (!crtc || WARN_ON(!fb))
> return;
>
> +   if (!plane->state->visible)
> +   return mtk_plane_atomic_disable(plane, old_state);
> +
> gem = fb->obj[0];
> mtk_gem = to_mtk_gem_obj(gem);
> addr = mtk_gem->dma_addr;
> @@ -200,16 +213,6 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
> state->pending.dirty = true;
>  }
>
> -static void mtk_plane_atomic_disable(struct drm_plane *plane,
> -struct drm_plane_state *old_state)
> -{
> -   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> -
> -   state->pending.enable = false;
> -   wmb(); /* Make sure the above parameter is set before update */
> -   state->pending.dirty = true;
> -}
> -
>  static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
> .prepare_fb = drm_gem_fb_prepare_fb,
> .atomic_check = mtk_plane_atomic_check,
> --
> 2.27.0.111.gc72c7da667-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

--- Comment #4 from phileimer (p...@jpmr.org) ---
I modified my kernel configuration to use the new amdgpu driver for this SI
chip, instead of the legacy radeon.
The same problem occurs: to avoid frequent kernel crashes, I must apply a patch
to lower the maximum temperature allowed.

-- 
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

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

--- Comment #3 from phileimer (p...@jpmr.org) ---
Created attachment 289807
  --> https://bugzilla.kernel.org/attachment.cgi?id=289807=edit
amdgpu: lower the temperature limit to avoid kernel crash

-- 
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

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

phileimer (p...@jpmr.org) changed:

   What|Removed |Added

 Kernel Version|5.6.x and previous  |5.6.x, 5.7.x

-- 
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

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

phileimer (p...@jpmr.org) changed:

   What|Removed |Added

Summary|radeon: crash due to over   |amdgpu/radeon: crash due to
   |temperature |over temperature

-- 
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

[PATCH v4] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen 

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

A related Wayland protocol change proposal is at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35

Signed-off-by: Pekka Paalanen 
Reviewed-by: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Dave Airlie 
Cc: Sean Paul 
Cc: Simon Ser 
Cc: Noralf Trønnes 
Cc: Ben Skeggs 
Cc: Christian König 
Cc: Harry Wentland 
Cc: Karol Herbst 

---

Harry and Christian, could one of you ack this on behalf of AMD
drivers?

Ben or Karol, could you ack on behalf of Nouveau?

Noralf, would this work for the tiny drivers etc.?

This is only about laying out plans for the future, not about what
drivers do today. We'd just like to be sure the goals are reasonable and
everyone is aware of the idea.

Thanks,
pq

v4:
- two typo fixes (Daniel)

v3:
- update ENODEV doc (Daniel)
- clarify existing vs. new mmaps (Andrey)
- split into KMS and render/cross sections (Andrey, Daniel)
- open() returns ENXIO (open(2) man page)
- ioctls may return ENODEV (Andrey, Daniel)
- new wayland-protocols MR

v2:
- mmap reads/writes undefined (Daniel)
- make render ioctl behaviour driver-specific (Daniel)
- restructure the mmap paragraphs (Daniel)
- chardev minor notes (Simon)
- open behaviour (Daniel)
- DRM leasing behaviour (Daniel)
- added links

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 114 -
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..b2585ea6a83e 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===
 Userland interfaces
 ===
@@ -162,6 +164,116 @@ other hand, a driver requires shared state between 
clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop continue to
+run, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent, ioctls returning ENODEV
+(or driver-specific ioctls returning driver-specific things), or open()
+returning ENXIO.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
+Similar to PIDs, chardev minor numbers are not recycled immediately. A
+new DRM device always picks the next free minor number compared to the
+previous one allocated, and wraps around when minor numbers are
+exhausted.
+
+The goal raises at least the following requirements for the kernel and
+drivers.
+
+Requirements for KMS UAPI
+-
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips, and atomic commits, both real and
+  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
+  success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting. This applies also to ioctls that faked success.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+- Attempting to create a DRM lease on a disappeared DRM device will
+  fail with ENODEV. Existing DRM leases remain and work as listed

Re: [PATCH v7 04/36] drm: amdgpu: fix common struct sg_table related issues

[Christian König]

Am 19.06.20 um 12:36 schrieb Marek Szyprowski:

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().

struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).

It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.

To avoid such issues, lets use a common dma-mapping wrappers operating
directly on the struct sg_table objects and use scatterlist page
iterators where possible. This, almost always, hides references to the
nents and orig_nents entries, making the code robust, easier to follow
and copy/paste safe.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Christian König 


Any objection that we pick this one and the radeon up into our branches 
for upstreaming?


That should about clashes with other driver changes.

Thanks,
Christian.


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 6 +++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 9 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 
  3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 43d8ed7dbd00..519ce4427fce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -307,8 +307,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
if (IS_ERR(sgt))
return sgt;
  
-		if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,

- DMA_ATTR_SKIP_CPU_SYNC))
+   if (dma_map_sgtable(attach->dev, sgt, dir,
+   DMA_ATTR_SKIP_CPU_SYNC))
goto error_free;
break;
  
@@ -349,7 +349,7 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment *attach,

struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
  
  	if (sgt->sgl->page_link) {

-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sgtable(attach->dev, sgt, dir, 0);
sg_free_table(sgt);
kfree(sgt);
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 5129a996e941..97fb73e5a6ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1025,7 +1025,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
  {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   unsigned nents;
int r;
  
  	int write = !(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY);

@@ -1040,9 +1039,8 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
goto release_sg;
  
  	/* Map SG to device */

-   r = -ENOMEM;
-   nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   r = dma_map_sgtable(adev->dev, ttm->sg, direction, 0);
+   if (r)
goto release_sg;
  
  	/* convert SG to linear array of pages and dma addresses */

@@ -1073,8 +1071,7 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt 
*ttm)
return;
  
  	/* unmap the pages mapped to the device */

-   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-
+   dma_unmap_sgtable(adev->dev, ttm->sg, direction, 0);
sg_free_table(ttm->sg);
  
  #if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index d399e5893170..c281aa13f5ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -477,11 +477,11 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
if (r)
goto error_free;
  
-	for_each_sg((*sgt)->sgl, sg, num_entries, i)

+   for_each_sgtable_sg((*sgt), sg, i)
sg->length = 0;
  
  	node = mem->mm_node;

-   for_each_sg((*sgt)->sgl, sg, num_entries, i) {
+   for_each_sgtable_sg((*sgt), sg, i) {
phys_addr_t phys = (node->start << PAGE_SHIFT) +
adev->gmc.aper_base;
size_t size = node->size << PAGE_SHIFT;
@@ -501,7 +501,7 @@ int 

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.


That looks extremely fishy to me.

It sounds like we just don't remove stuff in the right order.

Christian.



Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
  8 files changed, 99 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 604a681..ba3775f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -726,6 +726,15 @@ struct amd_powerplay {
  
  #define AMDGPU_RESET_MAGIC_NUM 64

  #define AMDGPU_MAX_DF_PERFMONS 4
+
+struct amdgpu_sysfs_list_node {
+   struct list_head head;
+   struct device_attribute *attr;
+};
+
+#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
+   struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
_attr_##_attr}
+
  struct amdgpu_device {
struct device   *dev;
struct drm_device   *ddev;
@@ -992,6 +1001,10 @@ struct amdgpu_device {
charproduct_number[16];
charproduct_name[32];
charserial[16];
+
+   struct list_head sysfs_files_list;
+   struct mutex sysfs_files_list_lock;
+
  };
  
  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index fdd52d8..c1549ee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1950,8 +1950,10 @@ static ssize_t amdgpu_atombios_get_vbios_version(struct 
device *dev,
return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
  }
  
+

  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
   NULL);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
  
  /**

   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
@@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
adev->mode_info.atom_context = NULL;
kfree(adev->mode_info.atom_card_info);
adev->mode_info.atom_card_info = NULL;
-   device_remove_file(adev->dev, _attr_vbios_version);
  }
  
  /**

@@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
return ret;
}
  
+	mutex_lock(>sysfs_files_list_lock);

+   list_add_tail(_attr_handle_vbios_version.head, 
>sysfs_files_list);
+   mutex_unlock(>sysfs_files_list_lock);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index e7b9065..3173046 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2928,6 +2928,12 @@ static const struct attribute *amdgpu_dev_attributes[] = 
{
NULL
  };
  
+static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);

+static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
+
+
  /**
   * amdgpu_device_init - initialize the driver
   *
@@ -3029,6 +3035,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
INIT_LIST_HEAD(>shadow_list);
mutex_init(>shadow_list_lock);
  
+	INIT_LIST_HEAD(>sysfs_files_list);

+   mutex_init(>sysfs_files_list_lock);
+
INIT_DELAYED_WORK(>delayed_init_work,
  amdgpu_device_delayed_init_work_handler);
INIT_DELAYED_WORK(>gfx.gfx_off_delay_work,
@@ -3281,6 +3290,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r) {
dev_err(adev->dev, "Could not create amdgpu device attr\n");
return r;
+   } else {
+   mutex_lock(>sysfs_files_list_lock);
+   list_add_tail(_attr_handle_product_name.head, 
>sysfs_files_list);
+   list_add_tail(_attr_handle_product_number.head, 
>sysfs_files_list);
+   list_add_tail(_attr_handle_serial_number.head, 
>sysfs_files_list);
+   list_add_tail(_attr_handle_pcie_replay_count.head, 
>sysfs_files_list);
+   mutex_unlock(>sysfs_files_list_lock);
}
  
  	if 

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Will be used to reroute CPU mapped BO's page faults once
device is removed.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_file.c  |  8 
  drivers/gpu/drm/drm_prime.c | 10 ++
  include/drm/drm_file.h  |  2 ++
  include/drm/drm_gem.h   |  2 ++
  4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c4c704e..67c0770 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
  
+	file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);

+   if (!file->dummy_page) {
+   ret = -ENOMEM;
+   goto out_prime_destroy;
+   }
+
return file;
  
  out_prime_destroy:

@@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
  
+	__free_page(file->dummy_page);

+
drm_prime_destroy_file_private(>prime);
  
  	WARN_ON(!list_empty(>event_list));

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1de2cde..c482e9c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
  
  	ret = drm_prime_add_buf_handle(_priv->prime,

dma_buf, *handle);
+
+   if (!ret) {
+   obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+   if (!obj->dummy_page)
+   ret = -ENOMEM;
+   }
+


While the per file case still looks acceptable this is a clear NAK since 
it will massively increase the memory needed for a prime exported object.


I think that this is quite overkill in the first place and for the hot 
unplug case we can just use the global dummy page as well.


Christian.


mutex_unlock(_priv->prime.lock);
if (ret)
goto fail;
@@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, 
struct sg_table *sg)
dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
+
+   __free_page(obj->dummy_page);
+
/* remove the reference */
dma_buf_put(dma_buf);
  }
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 19df802..349a658 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -335,6 +335,8 @@ struct drm_file {
 */
struct drm_prime_file_private prime;
  
+	struct page *dummy_page;

+
/* private: */
  #if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b37506..47460d1 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -310,6 +310,8 @@ struct drm_gem_object {
 *
 */
const struct drm_gem_object_funcs *funcs;
+
+   struct page *dummy_page;
  };
  
  /**


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

Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Gerd Hoffmann]

  Hi,

> +/* Should be done only once during init and resume */
> +static int synthvid_update_vram_location(struct hv_device *hdev,
> +   phys_addr_t vram_pp)
> +{
> + struct hyperv_device *hv = hv_get_drvdata(hdev);
> + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> + unsigned long t;
> + int ret = 0;
> +
> + memset(msg, 0, sizeof(struct synthvid_msg));
> + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> + sizeof(struct synthvid_vram_location);
> + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> + msg->vram.is_vram_gpa_specified = 1;
> + synthvid_send(hdev, msg);

That suggests it is possible to define multiple framebuffers in vram,
then pageflip by setting vram.vram_gpa.  If that is the case I'm
wondering whenever vram helpers are a better fit maybe?  You don't have
to blit each and every display update then.

FYI: cirrus goes the blit route because (a) the amount of vram is very
small so trying to store multiple framebuffers there is out of question,
and (b) cirrus converts formats on the fly to hide some hardware
oddities.

take care,
  Gerd

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

RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name

[Ruhl, Michael J]

>-Original Message-
>From: charante=codeaurora@mg.codeaurora.org
> On Behalf Of Charan Teja
>Kalla
>Sent: Monday, June 22, 2020 5:26 AM
>To: Ruhl, Michael J ; Sumit Semwal
>; david.lai...@aculab.com; open list:DMA
>BUFFER SHARING FRAMEWORK ; DRI mailing
>list 
>Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org>
>Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>
>Hello Mike,
>
>On 6/19/2020 7:11 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: charante=codeaurora@mg.codeaurora.org
>>>  On Behalf Of Charan
>Teja
>>> Kalla
>>> Sent: Friday, June 19, 2020 7:57 AM
>>> To: Sumit Semwal ; Ruhl, Michael J
>>> ; david.lai...@aculab.com; open list:DMA
>>> BUFFER SHARING FRAMEWORK ; DRI
>mailing
>>> list 
>>> Cc: Linaro MM SIG ; LKML >> ker...@vger.kernel.org>
>>> Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>>>
>>> There exists a sleep-while-atomic bug while accessing the dmabuf->name
>>> under mutex in the dmabuffs_dname(). This is caused from the SELinux
>>> permissions checks on a process where it tries to validate the inherited
>>> files from fork() by traversing them through iterate_fd() (which
>>> traverse files under spin_lock) and call
>>> match_file(security/selinux/hooks.c) where the permission checks
>happen.
>>> This audit information is logged using dump_common_audit_data() where
>it
>>> calls d_path() to get the file path name. If the file check happen on
>>> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
>>> access dmabuf->name. The flow will be like below:
>>> flush_unauthorized_files()
>>>  iterate_fd()
>>>spin_lock() --> Start of the atomic section.
>>>  match_file()
>>>file_has_perm()
>>>  avc_has_perm()
>>>avc_audit()
>>>  slow_avc_audit()
>>> common_lsm_audit()
>>>   dump_common_audit_data()
>>> audit_log_d_path()
>>>   d_path()
>>>dmabuffs_dname()
>>>  mutex_lock()--> Sleep while atomic.
>>>
>>> Call trace captured (on 4.19 kernels) is below:
>>> ___might_sleep+0x204/0x208
>>> __might_sleep+0x50/0x88
>>> __mutex_lock_common+0x5c/0x1068
>>> __mutex_lock_common+0x5c/0x1068
>>> mutex_lock_nested+0x40/0x50
>>> dmabuffs_dname+0xa0/0x170
>>> d_path+0x84/0x290
>>> audit_log_d_path+0x74/0x130
>>> common_lsm_audit+0x334/0x6e8
>>> slow_avc_audit+0xb8/0xf8
>>> avc_has_perm+0x154/0x218
>>> file_has_perm+0x70/0x180
>>> match_file+0x60/0x78
>>> iterate_fd+0x128/0x168
>>> selinux_bprm_committing_creds+0x178/0x248
>>> security_bprm_committing_creds+0x30/0x48
>>> install_exec_creds+0x1c/0x68
>>> load_elf_binary+0x3a4/0x14e0
>>> search_binary_handler+0xb0/0x1e0
>>>
>>> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
>>>
>>> Cc:  [5.3+]
>>> Signed-off-by: Charan Teja Reddy 
>>> ---
>>>
>>> Changes in V2: Addressed review comments from Ruhl, Michael J
>>>
>>> Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/
>>>
>>> drivers/dma-buf/dma-buf.c | 11 +++
>>> include/linux/dma-buf.h   |  1 +
>>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 01ce125..d81d298 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry
>*dentry,
>>> char *buffer, int buflen)
>>> size_t ret = 0;
>>>
>>> dmabuf = dentry->d_fsdata;
>>> -   dma_resv_lock(dmabuf->resv, NULL);
>>> +   spin_lock(>name_lock);
>>> if (dmabuf->name)
>>> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
>>> -   dma_resv_unlock(dmabuf->resv);
>>> +   spin_unlock(>name_lock);
>>>
>>> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
>>>  dentry->d_name.name, ret > 0 ? name : "");
>>> @@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf
>>> *dmabuf, const char __user *buf)
>>> kfree(name);
>>> goto out_unlock;
>>> }
>>> +   spin_lock(>name_lock);
>>> kfree(dmabuf->name);
>>> dmabuf->name = name;
>>> +   spin_unlock(>name_lock);
>>
>> While this code path is ok, I would have separated the protection of the
>> attachment list and the name manipulation.
>>
>> dma_resv_lock(resv)
>> if (!list_empty(attachment)
>>  ret = -EBUSY
>> dma_resv_unlock(resv)
>>
>> if (ret) {
>>  kfree(name)
>>  return ret;
>> }
>
>Is it that the name should be visible before importer attaches to the
>dmabuf,(using dma_buf_attach()), thus _buf_set_name() is under the
>_resv_lock() as well?

That is the name that was being freed in the error path of the lock block.
Alternatively:

dma_resv_lock(resv)
if (!list_empty(attachment) {
ret = -EBUSY
kfree(name)
}
dma_resv_unlock(resv)

if (ret)
return ret;

I was limiting what was happening in the lock block.

You have two distinct locks, that protect two 

Re: [PATCH v1 11/11] soc: mediatek: cmdq: add set event function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add set event function in cmdq helper functions to set specific event.
> 
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   15 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|9 +
>  3 files changed, 25 insertions(+)
> 

Applied to v5.8-next/soc

Thanks!

> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 13f78c9b5901..e6133a42d229 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -346,6 +346,21 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_clear_event);
>  
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event)
> +{
> + struct cmdq_instruction inst = {};
> +
> + if (event >= CMDQ_MAX_EVENT)
> + return -EINVAL;
> +
> + inst.op = CMDQ_CODE_WFE;
> + inst.value = CMDQ_WFE_UPDATE | CMDQ_WFE_UPDATE_VALUE;
> + inst.event = event;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_set_event);
> +
>  int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value)
>  {
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 42d2a30e6a70..ba2d811183a9 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -17,6 +17,7 @@
>  #define CMDQ_JUMP_PASS   CMDQ_INST_SIZE
>  
>  #define CMDQ_WFE_UPDATE  BIT(31)
> +#define CMDQ_WFE_UPDATE_VALUEBIT(16)
>  #define CMDQ_WFE_WAITBIT(15)
>  #define CMDQ_WFE_WAIT_VALUE  0x1
>  
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 4b5f5d154bad..960704d75994 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -199,6 +199,15 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 
> high_addr_reg_idx,
>  int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>  
>  /**
> + * cmdq_pkt_set_event() - append set event command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @event:   the desired event to be set
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event);
> +
> +/**
>   * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
>   *execute an instruction that wait for a specified
>   *hardware register to check for the value w/o mask.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Greg KH]

On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > Track sysfs files in a list so they all can be removed during pci remove
> > since otherwise their removal after that causes crash because parent
> > folder was already removed during pci remove.

Huh?  That should not happen, do you have a backtrace of that crash?

> > Signed-off-by: Andrey Grodzovsky 
> 
> Uh I thought sysfs just gets yanked completely. Please check with Greg KH
> whether hand-rolling all this really is the right solution here ... Feels
> very wrong. I thought this was all supposed to work by adding attributes
> before publishing the sysfs node, and then letting sysfs clean up
> everything. Not by cleaning up manually yourself.

Yes, that is supposed to be the correct thing to do.

> 
> Adding Greg for an authoritative answer.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
> >  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
> >  8 files changed, 99 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 604a681..ba3775f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -726,6 +726,15 @@ struct amd_powerplay {
> >  
> >  #define AMDGPU_RESET_MAGIC_NUM 64
> >  #define AMDGPU_MAX_DF_PERFMONS 4
> > +
> > +struct amdgpu_sysfs_list_node {
> > +   struct list_head head;
> > +   struct device_attribute *attr;
> > +};

You know we have lists of attributes already, called attribute groups,
if you really wanted to do something like this.  But, I don't think so.

Either way, don't hand-roll your own stuff that the driver core has
provided for you for a decade or more, that's just foolish :)

> > +
> > +#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
> > +   struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
> > _attr_##_attr}
> > +
> >  struct amdgpu_device {
> > struct device   *dev;
> > struct drm_device   *ddev;
> > @@ -992,6 +1001,10 @@ struct amdgpu_device {
> > charproduct_number[16];
> > charproduct_name[32];
> > charserial[16];
> > +
> > +   struct list_head sysfs_files_list;
> > +   struct mutex sysfs_files_list_lock;
> > +
> >  };
> >  
> >  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> > *bdev)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> > index fdd52d8..c1549ee 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> > @@ -1950,8 +1950,10 @@ static ssize_t 
> > amdgpu_atombios_get_vbios_version(struct device *dev,
> > return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
> >  }
> >  
> > +
> >  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
> >NULL);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
> >  
> >  /**
> >   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
> > @@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
> > adev->mode_info.atom_context = NULL;
> > kfree(adev->mode_info.atom_card_info);
> > adev->mode_info.atom_card_info = NULL;
> > -   device_remove_file(adev->dev, _attr_vbios_version);
> >  }
> >  
> >  /**
> > @@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
> > return ret;
> > }
> >  
> > +   mutex_lock(>sysfs_files_list_lock);
> > +   list_add_tail(_attr_handle_vbios_version.head, 
> > >sysfs_files_list);
> > +   mutex_unlock(>sysfs_files_list_lock);
> > +
> > return 0;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index e7b9065..3173046 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2928,6 +2928,12 @@ static const struct attribute 
> > *amdgpu_dev_attributes[] = {
> > NULL
> >  };
> >  
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
> > +
> > +
> >  /**
> >   * amdgpu_device_init - initialize the driver
> >   *
> > @@ 

Re: [PATCH v1 10/11] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.
> 
> Signed-off-by: Dennis YC Hsieh 
> Reviewed-by: CK Hu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |2 +-
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |5 +++--
>  include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
>  include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
>  4 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 7daaabc26eb1..a065b3a412cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
> *mtk_crtc)
>   if (mtk_crtc->cmdq_client) {
>   cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
>   cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> - cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> + cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);

This does not set CMDQ_WFE_UPDATE while the old code did. Is this a bug fix or a
bug in the code?
If it's a fix, please provide a fixes tag.

Thanks,
Matthias

>   mtk_crtc_ddp_config(crtc, cmdq_handle);
>   cmdq_pkt_finalize(cmdq_handle);
>   cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 009f86ae72c6..13f78c9b5901 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -315,15 +315,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, 
> u8 high_addr_reg_idx,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
>  
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
>  {
>   struct cmdq_instruction inst = { {0} };
> + u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
>  
>   if (event >= CMDQ_MAX_EVENT)
>   return -EINVAL;
>  
>   inst.op = CMDQ_CODE_WFE;
> - inst.value = CMDQ_WFE_OPTION;
> + inst.value = CMDQ_WFE_OPTION | clear_option;
>   inst.event = event;
>  
>   return cmdq_pkt_append_command(pkt, inst);
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 3f6bc0dfd5da..42d2a30e6a70 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -27,8 +27,7 @@
>   * bit 16-27: update value
>   * bit 31: 1 - update, 0 - no update
>   */
> -#define CMDQ_WFE_OPTION  (CMDQ_WFE_UPDATE | 
> CMDQ_WFE_WAIT | \
> - CMDQ_WFE_WAIT_VALUE)
> +#define CMDQ_WFE_OPTION  (CMDQ_WFE_WAIT | 
> CMDQ_WFE_WAIT_VALUE)
>  
>  /** cmdq event maximum */
>  #define CMDQ_MAX_EVENT   0x3ff
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 18364d81e8f7..4b5f5d154bad 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, 
> u8 high_addr_reg_idx,
>  /**
>   * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>   * @pkt: the CMDQ packet
> - * @event:   the desired event type to "wait and CLEAR"
> + * @event:   the desired event type to wait
> + * @clear:   clear event or not after event arrive
>   *
>   * Return: 0 for success; else the error code is returned
>   */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
>  
>  /**
>   * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 08/11] soc: mediatek: cmdq: export finalize function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Export finalize function to client which helps append eoc and jump
> command to pkt. Let client decide call finalize or not.
> 
> Signed-off-by: Dennis YC Hsieh 
> Reviewed-by: CK Hu 
> Acked-by: Chun-Kuang Hu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |1 +
>  drivers/soc/mediatek/mtk-cmdq-helper.c  |7 ++-
>  include/linux/soc/mediatek/mtk-cmdq.h   |8 
>  3 files changed, 11 insertions(+), 5 deletions(-)
> 


Applied to v5.8-next/soc

Thanks!

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0dfcd1787e65..7daaabc26eb1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
> *mtk_crtc)
>   cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
>   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
>   mtk_crtc_ddp_config(crtc, cmdq_handle);
> + cmdq_pkt_finalize(cmdq_handle);
>   cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>   }
>  #endif
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index e372ae065240..248945108a36 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -391,7 +391,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, 
> u32 value)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_assign);
>  
> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
>   struct cmdq_instruction inst = { {0} };
>   int err;
> @@ -411,6 +411,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  
>   return err;
>  }
> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>  
>  static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
>  {
> @@ -445,10 +446,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, 
> cmdq_async_flush_cb cb,
>   unsigned long flags = 0;
>   struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>  
> - err = cmdq_pkt_finalize(pkt);
> - if (err < 0)
> - return err;
> -
>   pkt->cb.cb = cb;
>   pkt->cb.data = data;
>   pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 6e8caacedc80..eac1405e4872 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -244,6 +244,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>  int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>  
>  /**
> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> + * @pkt: the CMDQ packet
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> +
> +/**
>   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>   *  packet and call back at the end of done packet
>   * @pkt: the CMDQ packet
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Deepak Rawat]

DRM driver for hyperv synthetic video device, based on hyperv_fb
framebuffer driver. Also added config option "DRM_HYPERV" to enabled
this driver.

Signed-off-by: Deepak Rawat 
---
 drivers/gpu/drm/tiny/Kconfig  |9 +
 drivers/gpu/drm/tiny/Makefile |1 +
 drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
 3 files changed, 1017 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c

diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa75..e6d53e60a9c2 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -28,6 +28,15 @@ config DRM_GM12U320
 This is a KMS driver for projectors which use the GM12U320 chipset
 for video transfer over USB2/3, such as the Acer C120 mini projector.
 
+config DRM_HYPERV
+   tristate "DRM Support for hyperv synthetic video device"
+   depends on DRM && PCI && MMU && HYPERV
+   select DRM_KMS_HELPER
+   select DRM_GEM_SHMEM_HELPER
+   help
+This is a KMS driver for for hyperv synthetic video device.
+If M is selected the module will be called hyperv_drm.
+
 config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35f..837cb2c2637e 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -2,6 +2,7 @@
 
 obj-$(CONFIG_DRM_CIRRUS_QEMU)  += cirrus.o
 obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_HYPERV)   += hyperv_drm.o
 obj-$(CONFIG_TINYDRM_HX8357D)  += hx8357d.o
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
diff --git a/drivers/gpu/drm/tiny/hyperv_drm.c 
b/drivers/gpu/drm/tiny/hyperv_drm.c
new file mode 100644
index ..3d020586056e
--- /dev/null
+++ b/drivers/gpu/drm/tiny/hyperv_drm.c
@@ -0,0 +1,1007 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2012-2020 Microsoft
+ *
+ * Authors:
+ * Deepak Rawat 
+ *
+ * Portions of this code is derived from hyperv_fb.c
+ * drivers/video/fbdev/hyperv_fb.c - framebuffer driver for hyperv synthetic
+ * video device.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "hyperv_drm"
+#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
+#define DRIVER_DATE "2020"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+#define VMBUS_MAX_PACKET_SIZE 0x4000
+#define VMBUS_RING_BUFSIZE (256 * 1024)
+#define VMBUS_VSP_TIMEOUT (10 * HZ)
+
+#define PCI_VENDOR_ID_MICROSOFT 0x1414
+#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
+
+struct hyperv_device {
+   /* drm */
+   struct drm_device dev;
+   struct drm_simple_display_pipe pipe;
+   struct drm_connector connector;
+
+   /* mode */
+   u32 screen_width_max;
+   u32 screen_height_max;
+   u32 preferred_width;
+   u32 preferred_height;
+   u32 screen_depth;
+
+   /* hw */
+   void __iomem *vram;
+   unsigned long fb_base;
+   unsigned long fb_size;
+   struct completion wait;
+   u32 synthvid_version;
+   u32 mmio_megabytes;
+   bool init_done;
+
+   u8 init_buf[VMBUS_MAX_PACKET_SIZE];
+   u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
+
+   struct hv_device *hdev;
+};
+
+#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev)
+
+/* -- */
+/* Hyper-V Synthetic Video Protocol   */
+
+#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
+#define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x)
+#define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0x) >> 16)
+#define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
+#define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
+#define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
+
+#define SYNTHVID_DEPTH_WIN7 16
+#define SYNTHVID_DEPTH_WIN8 32
+#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
+#define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
+#define SYNTHVID_WIDTH_MAX_WIN7 1600
+#define SYNTHVID_HEIGHT_MAX_WIN7 1200
+
+enum pipe_msg_type {
+   PIPE_MSG_INVALID,
+   PIPE_MSG_DATA,
+   PIPE_MSG_MAX
+};
+
+enum synthvid_msg_type {
+   SYNTHVID_ERROR  = 0,
+   SYNTHVID_VERSION_REQUEST= 1,
+   SYNTHVID_VERSION_RESPONSE   = 2,
+   SYNTHVID_VRAM_LOCATION  = 3,
+   SYNTHVID_VRAM_LOCATION_ACK  = 4,
+   SYNTHVID_SITUATION_UPDATE   = 5,
+   SYNTHVID_SITUATION_UPDATE_ACK   = 6,
+   SYNTHVID_POINTER_POSITION   = 7,
+   SYNTHVID_POINTER_SHAPE  = 8,
+   SYNTHVID_FEATURE_CHANGE = 9,
+   SYNTHVID_DIRT   

Re: [PATCH v1 03/11] soc: mediatek: cmdq: add write_s function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
> 
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   19 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|   19 +++
>  3 files changed, 39 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index bf32e3b2ca6c..817a5a97dbe5 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
>   union {
>   u32 value;
>   u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
>   };
>   union {
>   u16 offset;
> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_mask);
>  
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +  u16 addr_low, u16 src_reg_idx)
> +{

Do I understand correctly that we use CMDQ_ADDR_HIGH(addr) and
CMDQ_ADDR_LOW(addr) to calculate in the client high_addr_reg_idx and addr_low
respectively?

In that case I think a better interface would be to pass the address and do the
high/low calculation in the cmdq_pkt_write_s

Regards,
Matthias

> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_WRITE_S;
> + inst.src_t = CMDQ_REG_TYPE;
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
>  int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>  {
>   struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..ee67dd3b86f5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
>   CMDQ_CODE_LOGIC = 0xa0,
>  };
>  
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 83340211e1d3..e1c5a7549b4f 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -12,6 +12,8 @@
>  #include 
>  
>  #define CMDQ_NO_TIMEOUT  0xu
> +#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
> +#define CMDQ_ADDR_LOW(addr)  ((u16)(addr) | BIT(1))
>  
>  struct cmdq_pkt;
>  
> @@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
>   u16 offset, u32 value, u32 mask);
>  
>  /**
> + * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @high_addr_reg_idx:   internal register ID which contains high 
> address of pa
> + * @addr_low:low address of pa
> + * @src_reg_idx: the CMDQ internal register ID which cache source value
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Support write value to physical address without subsys. Use 
> CMDQ_ADDR_HIGH()
> + * to get high address and call cmdq_pkt_assign() to assign value into 
> internal
> + * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter 
> when
> + * call to this function.
> + */
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +  u16 addr_low, u16 src_reg_idx);
> +
> +/**
>   * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>   * @pkt: the CMDQ packet
>   * @event:   the desired event type to "wait and CLEAR"
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 2/2] MAINTAINERS: Add maintainer for hyperv video device

[Deepak Rawat]

Maintainer for hyperv synthetic video device.

Signed-off-by: Deepak Rawat 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f437f42b73ad..102f734b99bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5316,6 +5316,14 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
 F: drivers/gpu/drm/tiny/hx8357d.c
 
+DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
+M: Deepak Rawat 
+L: linux-hyp...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/tiny/hyperv_drm.c
+
 DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
-- 
2.27.0

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

[RFC PATCH 0/2] DRM driver for hyper-v synthetic video device

[Deepak Rawat]

Hi All,

First draft of DRM driver for hyper-v synthetic video device. This synthetic
device is already supported by hyper-v and a corresponding framebuffer driver
exist at drivers/video/fbdev/hyperv_fb.c. With this patch, just reworked the
framebuffer driver into DRM, in doing so got mode-setting support. The code is
similar to cirrus DRM driver, using simple display pipe and shmem backed
GEM objects.

The device support more features like hardware cursor, EDID, multiple dirty
regions, etc, which were not supported with framebuffer driver. The plan is to
add support for those in future iteration. Wanted to get initial feedback and
discuss cursor support with simple kms helper. Is there any value to add cursor
support to drm_simple_kms_helper.c so that others can use it, or should I just
add cursor plane as device private? I believe we can still keep this driver
in drm/tiny?

For testing, ran GNOME and Weston with current changes in a Linux VM on
Windows 10 with hyper-v enabled.

Thanks,
Deepak

Deepak Rawat (2):
  drm/hyperv: Add DRM driver for hyperv synthetic video device
  MAINTAINERS: Add maintainer for hyperv video device

 MAINTAINERS   |8 +
 drivers/gpu/drm/tiny/Kconfig  |9 +
 drivers/gpu/drm/tiny/Makefile |1 +
 drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
 4 files changed, 1025 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c

-- 
2.27.0

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

Re: [PATCH v1 02/11] soc: mediatek: cmdq: add assign function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add assign function in cmdq helper which assign constant value into
> internal register by index.
> 
> Signed-off-by: Dennis YC Hsieh 

Applied to v5.8-next/soc

Thanks

> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   24 +++-
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|   14 ++
>  3 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 98f23ba3ba47..bf32e3b2ca6c 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -12,6 +12,7 @@
>  #define CMDQ_WRITE_ENABLE_MASK   BIT(0)
>  #define CMDQ_POLL_ENABLE_MASKBIT(0)
>  #define CMDQ_EOC_IRQ_EN  BIT(0)
> +#define CMDQ_REG_TYPE1
>  
>  struct cmdq_instruction {
>   union {
> @@ -21,8 +22,17 @@ struct cmdq_instruction {
>   union {
>   u16 offset;
>   u16 event;
> + u16 reg_dst;
> + };
> + union {
> + u8 subsys;
> + struct {
> + u8 sop:5;
> + u8 arg_c_t:1;
> + u8 src_t:1;
> + u8 dst_t:1;
> + };
>   };
> - u8 subsys;
>   u8 op;
>  };
>  
> @@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_poll_mask);
>  
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> +{
> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_LOGIC;
> + inst.dst_t = CMDQ_REG_TYPE;
> + inst.reg_dst = reg_idx;
> + inst.value = value;
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_assign);
> +
>  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
>   struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index dfe5b2eb85cc..121c3bb6d3de 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_LOGIC = 0xa0,
>  };
>  
>  enum cmdq_cb_status {
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a74c1d5acdf3..83340211e1d3 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
>   */
>  int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>  u16 offset, u32 value, u32 mask);
> +
> +/**
> + * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask 
> GCE
> + *  to execute an instruction that set a constant value into
> + *  internal register and use as value, mask or address in
> + *  read/write instruction.
> + * @pkt: the CMDQ packet
> + * @reg_idx: the CMDQ internal register ID
> + * @value:   the specified value
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> +
>  /**
>   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>   *  packet and call back at the end of done packet
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema

[Daniel Thompson]

On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> Good to have these converted. A few comments in the following. One
> comment is for the backlight people as you copied the original text.

... and I've sliced out everything except that in this reply.

> On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote:
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml 
> > b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > new file mode 100644
> > index ..ae50945d2798
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > @@ -0,0 +1,58 @@
> > ...
> > +
> > +  default-brightness-level:
> > +description: The default brightness level (index into the array defined
> > +  by the "brightness-levels" property).
>
> This description does not match my understading.
> The description says "index into", but in reality this is a value that
> matches somewhere in the range specified by brightness-levels.
> So it is not an index.
> 
> Maybe I just read it wrong and the description is fine. But when I read
> index the when it says 6 I would look for brightness-levels[6] equals
> 128 in the example below.

When the brightness-levels array is not present then backlight
brightness and led brightness have a 1:1 mapping. In this case the
meaning of "default brightness level" is (hopefully) obvious and the
parenthetic text does not apply.

When the array is present then we have two different scales of
brightness and it is important to describe which scale we use for the
default brightness. The language about "index into" was adopted to avoid
having to introduce extra terminology whilst making it clear that
setting the default brightness-level to 128 is invalid (because it is
not an acceptable index) and that a value of 6 will result in the LED
brightness being set to 128.


> And this is not how it is coded.

That had me worried for a moment but I think the code and bindings are
in agreement.

There is some code to map the LED scale (128) to the backlight scale (6)
but this used to ensure we supply the correct brightness level to user
space when an active backlight is handed over from bootloader to kernel.

If a default-brightness-level is provided then the above logic is
overridden and the value read from the DT gets placed directly into
props.brightness where it will act as in index into the brightness
table.


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

Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements

[Brian Starkey]

On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > Hi Simon,
> > 
> > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch alignment, address alignement,
> > > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > > constraints into modifiers. Last time this was brought up it seemed
> > > like the consensus was to not allow this. Document this in drm_fourcc.h.
> > > 
> > > There are several reasons for this.
> > > 
> > > - Encoding all of these constraints in the modifiers would explode the
> > >   search space pretty quickly (we only have 64 bits to work with).
> > > - Modifiers need to be unambiguous: a buffer can only have a single
> > >   modifier.
> > > - Modifier users aren't expected to parse modifiers (except drivers).
> > > 
> > > v2: add paragraph about aliases (Daniel)
> > > 
> > > v3: fix unrelated changes sent with the patch
> > > 
> > > v4: disambiguate users between driver and higher-level programs (Brian,
> > > Daniel)
> > > 
> > > Signed-off-by: Simon Ser 
> > > Reviewed-by: Daniel Vetter 
> > > Cc: Daniel Stone 
> > > Cc: Bas Nieuwenhuizen 
> > > Cc: Dave Airlie 
> > > Cc: Marek Olšák 
> > > Cc: Alex Deucher 
> > > Cc: Neil Armstrong 
> > > Cc: Michel Dänzer 
> > > Cc: Brian Starkey 
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 22 ++
> > >  1 file changed, 22 insertions(+)
> > > 
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index 490143500a50..4d3f819dca0b 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -58,6 +58,28 @@ extern "C" {
> > >   * may preserve meaning - such as number of planes - from the fourcc 
> > > code,
> > >   * whereas others may not.
> > >   *
> > > + * Modifiers must uniquely encode buffer layout. In other words, a 
> > > buffer must
> > > + * match only a single modifier. A modifier must not be a subset of 
> > > layouts of
> > > + * another modifier. For instance, it's incorrect to encode pitch 
> > > alignment in
> > > + * a modifier: a buffer may match a 64-pixel aligned modifier and a 
> > > 32-pixel
> > > + * aligned modifier. That said, modifiers can have implicit minimal
> > > + * requirements.
> > > + *
> > > + * For modifiers where the combination of fourcc code and modifier can 
> > > alias,
> > > + * a canonical pair needs to be defined and used by all drivers. An 
> > > example
> > > + * is AFBC, where both ARGB and ABGR have the exact same compressed 
> > > layout.
> > 
> > I still don't agree with this sentence. ARGB and ABGR have different
> > compressed layouts in AFBC.
> 
> Hm then maybe I got confused for the exact reason why afbc has defined
> canonical fourcc codes in Documentation/gpu/afbc.rst? They all use the
> BGR versions, no RGB anywhere to be found.
> 
> What's the reason then behind the "Formats which are not listed should be
> avoided." in that doc? That's the case I wanted to refer to here.

Basically there's hardware which supports only BGR, hardware which
"ignores" swizzle (treats all as BGR), and hardware which supports
both BGR and RGB. Even amongst first-party implementations it's
inconsistent.

This leads to a potentially confusing situation where someone with
hardware which "ignores" swizzle assumes that's always the case.

To avoid that, we wanted to be explicit that ordering is important:

 | The assignment of input/output color channels must be consistent
 | between the encoder and the decoder for correct operation, otherwise
 | the consumer will interpret the decoded data incorrectly.
 | ...
 | The component ordering is communicated via the fourcc code in the
 | fourcc:modifier pair. In general, component '0' is considered to
 | reside in the least-significant bits of the corresponding linear
 | format. For example, COMP(bits):

And, to try and ensure best cross compatibility, we want BGR to be
used most often. We expect that to be supported by the most hardware:

 | For maximum compatibility across devices, the table below defines
 | canonical formats for use between AFBC-enabled devices. Formats which
 | are listed here must be used exactly as specified when using the AFBC
 | modifiers. Formats which are not listed should be avoided.

Cheers,
-Brian

> -Daniel
> 
> > 
> > Thanks,
> > -Brian
> > 
> > > + *
> > > + * There are two kinds of modifier users:
> > > + *
> > > + * - Kernel and user-space drivers: for drivers it's important that 
> > > modifiers
> > > + *   don't alias, otherwise two drivers might support the same format 
> > > but use
> > > + *   different aliases, preventing them from sharing buffers in an 
> > > efficient
> > > + *   format.
> > > + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: 
> > > these users
> > > + *   see modifiers as opaque tokens they can check for equality and 
> > > intersect.
> > > + *   These users musn't 

Re: [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:06AM -0400, Andrey Grodzovsky wrote:
> Use the new TTM interface to invalidate all exsisting BO CPU mappings
> form all user proccesses.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 43592dc..6932d75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>   struct drm_device *dev = pci_get_drvdata(pdev);
>  
>   drm_dev_unplug(dev);
> + ttm_bo_unmap_virtual_address_space(>mman.bdev);
>   amdgpu_driver_unload_kms(dev);

Hm a ttm, or maybe even vram helper function which wraps drm_dev_unplug +
ttm unmapping into one would be nice I think? I suspect there's going to
be more in the future here.
-Daniel

>  
>   pci_disable_device(pdev);
> -- 
> 2.7.4
> 

-- 
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 v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:07AM -0400, Andrey Grodzovsky wrote:
> entity->rq becomes null aftre device unplugged so just return early
> in that case.
> 
> Signed-off-by: Andrey Grodzovsky 

That looks very deep in amdgpu internals ... how do you even get in here
after the device is fully unplugged on the sw side?

Is this amdkfd doing something stupid because entirely unaware of what
amdgpu has done? Something else? Just feels like this is just duct-taping
over a more fundamental problem, after hotunplug no one should be able to
even submit anything new, or do bo moves, or well anything really.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> index 8d9c6fe..d252427 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> @@ -24,6 +24,7 @@
>  #include "amdgpu_job.h"
>  #include "amdgpu_object.h"
>  #include "amdgpu_trace.h"
> +#include 
>  
>  #define AMDGPU_VM_SDMA_MIN_NUM_DW256u
>  #define AMDGPU_VM_SDMA_MAX_NUM_DW(16u * 1024u)
> @@ -94,7 +95,12 @@ static int amdgpu_vm_sdma_commit(struct 
> amdgpu_vm_update_params *p,
>   struct drm_sched_entity *entity;
>   struct amdgpu_ring *ring;
>   struct dma_fence *f;
> - int r;
> + int r, idx;
> +
> + if (!drm_dev_enter(p->adev->ddev, )) {
> + r = -ENODEV;
> + goto nodev;
> + }
>  
>   entity = p->immediate ? >vm->immediate : >vm->delayed;
>   ring = container_of(entity->rq->sched, struct amdgpu_ring, sched);
> @@ -104,7 +110,7 @@ static int amdgpu_vm_sdma_commit(struct 
> amdgpu_vm_update_params *p,
>   WARN_ON(ib->length_dw > p->num_dw_left);
>   r = amdgpu_job_submit(p->job, entity, AMDGPU_FENCE_OWNER_VM, );
>   if (r)
> - goto error;
> + goto job_fail;
>  
>   if (p->unlocked) {
>   struct dma_fence *tmp = dma_fence_get(f);
> @@ -118,10 +124,15 @@ static int amdgpu_vm_sdma_commit(struct 
> amdgpu_vm_update_params *p,
>   if (fence && !p->immediate)
>   swap(*fence, f);
>   dma_fence_put(f);
> - return 0;
>  
> -error:
> - amdgpu_job_free(p->job);
> + r = 0;
> +
> +job_fail:
> + drm_dev_exit(idx);
> +nodev:
> + if (r)
> + amdgpu_job_free(p->job);
> +
>   return r;
>  }
>  
> -- 
> 2.7.4
> 

-- 
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 v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> No point to try recovery if device is gone, just messes up things.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  8 
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6932d75..5d6d3d9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>   return ret;
>  }
>  
> +static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
> +{
> + int i;
> +
> + for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> + struct amdgpu_ring *ring = adev->rings[i];
> +
> + if (!ring || !ring->sched.thread)
> + continue;
> +
> + cancel_delayed_work_sync(>sched.work_tdr);
> + }
> +}

I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or your
split in one of the earlier patches not done quite right.
-Daniel

> +
>  static void
>  amdgpu_pci_remove(struct pci_dev *pdev)
>  {
>   struct drm_device *dev = pci_get_drvdata(pdev);
> + struct amdgpu_device *adev = dev->dev_private;
>  
>   drm_dev_unplug(dev);
> + amdgpu_cancel_all_tdr(adev);
>   ttm_bo_unmap_virtual_address_space(>mman.bdev);
>   amdgpu_driver_unload_kms(dev);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index 4720718..87ff0c0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -28,6 +28,8 @@
>  #include "amdgpu.h"
>  #include "amdgpu_trace.h"
>  
> +#include 
> +
>  static void amdgpu_job_timedout(struct drm_sched_job *s_job)
>  {
>   struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
> @@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct drm_sched_job 
> *s_job)
>  
>   memset(, 0, sizeof(struct amdgpu_task_info));
>  
> + if (drm_dev_is_unplugged(adev->ddev)) {
> + DRM_INFO("ring %s timeout, but device unplugged, skipping.\n",
> +   s_job->sched->name);
> + return;
> + }
> +
>   if (amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent)) 
> {
>   DRM_ERROR("ring %s timeout, but soft recovered\n",
> s_job->sched->name);
> -- 
> 2.7.4
> 

-- 
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 v2 5/8] drm/amdgpu: Refactor sysfs removal

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> Track sysfs files in a list so they all can be removed during pci remove
> since otherwise their removal after that causes crash because parent
> folder was already removed during pci remove.
> 
> Signed-off-by: Andrey Grodzovsky 

Uh I thought sysfs just gets yanked completely. Please check with Greg KH
whether hand-rolling all this really is the right solution here ... Feels
very wrong. I thought this was all supposed to work by adding attributes
before publishing the sysfs node, and then letting sysfs clean up
everything. Not by cleaning up manually yourself.

Adding Greg for an authoritative answer.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
>  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
>  8 files changed, 99 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 604a681..ba3775f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -726,6 +726,15 @@ struct amd_powerplay {
>  
>  #define AMDGPU_RESET_MAGIC_NUM 64
>  #define AMDGPU_MAX_DF_PERFMONS 4
> +
> +struct amdgpu_sysfs_list_node {
> + struct list_head head;
> + struct device_attribute *attr;
> +};
> +
> +#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
> + struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
> _attr_##_attr}
> +
>  struct amdgpu_device {
>   struct device   *dev;
>   struct drm_device   *ddev;
> @@ -992,6 +1001,10 @@ struct amdgpu_device {
>   charproduct_number[16];
>   charproduct_name[32];
>   charserial[16];
> +
> + struct list_head sysfs_files_list;
> + struct mutex sysfs_files_list_lock;
> +
>  };
>  
>  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> *bdev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> index fdd52d8..c1549ee 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> @@ -1950,8 +1950,10 @@ static ssize_t 
> amdgpu_atombios_get_vbios_version(struct device *dev,
>   return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
>  }
>  
> +
>  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
>  NULL);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
>  
>  /**
>   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
> @@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
>   adev->mode_info.atom_context = NULL;
>   kfree(adev->mode_info.atom_card_info);
>   adev->mode_info.atom_card_info = NULL;
> - device_remove_file(adev->dev, _attr_vbios_version);
>  }
>  
>  /**
> @@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
>   return ret;
>   }
>  
> + mutex_lock(>sysfs_files_list_lock);
> + list_add_tail(_attr_handle_vbios_version.head, 
> >sysfs_files_list);
> + mutex_unlock(>sysfs_files_list_lock);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index e7b9065..3173046 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2928,6 +2928,12 @@ static const struct attribute *amdgpu_dev_attributes[] 
> = {
>   NULL
>  };
>  
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
> +
> +
>  /**
>   * amdgpu_device_init - initialize the driver
>   *
> @@ -3029,6 +3035,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   INIT_LIST_HEAD(>shadow_list);
>   mutex_init(>shadow_list_lock);
>  
> + INIT_LIST_HEAD(>sysfs_files_list);
> + mutex_init(>sysfs_files_list_lock);
> +
>   INIT_DELAYED_WORK(>delayed_init_work,
> amdgpu_device_delayed_init_work_handler);
>   INIT_DELAYED_WORK(>gfx.gfx_off_delay_work,
> @@ -3281,6 +3290,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   if (r) {
>   dev_err(adev->dev, "Could not create amdgpu device attr\n");
>   return r;
> + } else {
> + 

Re: [PATCH v2 4/8] drm/amdgpu: Split amdgpu_device_fini into early and late

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:04AM -0400, Andrey Grodzovsky wrote:
> Some of the stuff in amdgpu_device_fini such as HW interrupts
> disable and pending fences finilization must be done right away on
> pci_remove while most of the stuff which relates to finilizing and releasing
> driver data structures can be kept until drm_driver.release hook is called, 
> i.e.
> when the last device reference is dropped.
> 
> Signed-off-by: Andrey Grodzovsky 

Long term I think best if as much of this code is converted over to devm
(for hw stuff) and drmm (for sw stuff and allocations). Doing this all
manually is very error prone.

I've started various such patches and others followed, but thus far only
very simple drivers tackled. But it should be doable step by step at
least, so you should have incremental benefits in code complexity right
away I hope.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 24 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 23 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  3 +++
>  7 files changed, 54 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2a806cb..604a681 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1003,7 +1003,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>  struct drm_device *ddev,
>  struct pci_dev *pdev,
>  uint32_t flags);
> -void amdgpu_device_fini(struct amdgpu_device *adev);
> +void amdgpu_device_fini_early(struct amdgpu_device *adev);
> +void amdgpu_device_fini_late(struct amdgpu_device *adev);
> +
>  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
>  
>  void amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
> @@ -1188,6 +1190,8 @@ void amdgpu_driver_lastclose_kms(struct drm_device 
> *dev);
>  int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file 
> *file_priv);
>  void amdgpu_driver_postclose_kms(struct drm_device *dev,
>struct drm_file *file_priv);
> +void amdgpu_driver_release_kms(struct drm_device *dev);
> +
>  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
>  int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
>  int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index cc41e8f..e7b9065 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2309,6 +2309,8 @@ static int amdgpu_device_ip_fini(struct amdgpu_device 
> *adev)
>  {
>   int i, r;
>  
> + //DRM_ERROR("adev 0x%llx", (long long unsigned int)adev);
> +
>   amdgpu_ras_pre_fini(adev);
>  
>   if (adev->gmc.xgmi.num_physical_nodes > 1)
> @@ -3304,10 +3306,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   * Tear down the driver info (all asics).
>   * Called at driver shutdown.
>   */
> -void amdgpu_device_fini(struct amdgpu_device *adev)
> +void amdgpu_device_fini_early(struct amdgpu_device *adev)
>  {
> - int r;
> -
>   DRM_INFO("amdgpu: finishing device.\n");
>   flush_delayed_work(>delayed_init_work);
>   adev->shutdown = true;
> @@ -3330,7 +3330,13 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   if (adev->pm_sysfs_en)
>   amdgpu_pm_sysfs_fini(adev);
>   amdgpu_fbdev_fini(adev);
> - r = amdgpu_device_ip_fini(adev);
> +
> + amdgpu_irq_fini_early(adev);
> +}
> +
> +void amdgpu_device_fini_late(struct amdgpu_device *adev)
> +{
> + amdgpu_device_ip_fini(adev);
>   if (adev->firmware.gpu_info_fw) {
>   release_firmware(adev->firmware.gpu_info_fw);
>   adev->firmware.gpu_info_fw = NULL;
> @@ -3368,6 +3374,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   amdgpu_pmu_fini(adev);
>   if (amdgpu_discovery && adev->asic_type >= CHIP_NAVI10)
>   amdgpu_discovery_fini(adev);
> +
>  }
>  
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 9e5afa5..43592dc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1134,12 +1134,9 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>  {
>   struct drm_device *dev = pci_get_drvdata(pdev);
>  
> -#ifdef MODULE
> - if (THIS_MODULE->state != MODULE_STATE_GOING)
> -#endif
> - DRM_ERROR("Hotplug removal is not supported\n");
>   drm_dev_unplug(dev);
>   amdgpu_driver_unload_kms(dev);
> +
>   pci_disable_device(pdev);
>   

Re: [PATCH v2 0/8] RFC Support hot device unplug in amdgpu

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:00AM -0400, Andrey Grodzovsky wrote:
> This RFC is more of a proof of concept then a fully working solution as there 
> are a few unresolved issues we are hoping to get advise on from people on the 
> mailing list.
> Until now extracting a card either by physical extraction (e.g. eGPU with 
> thunderbolt connection or by emulation through syfs -> 
> /sys/bus/pci/devices/device_id/remove)
> would cause random crashes in user apps. The random crashes in apps were 
> mostly due to the app having mapped a device backed BO into its address space 
> was still
> trying to access the BO while the backing device was gone.
> To answer this first problem Christian suggested to fix the handling of 
> mapped memory in the clients when the device goes away by forcibly unmap all 
> buffers
> the user processes has by clearing their respective VMAs mapping the device 
> BOs. Then when the VMAs try to fill in the page tables again we check in the 
> fault handler
> if the device is removed and if so, return an error. This will generate a 
> SIGBUS to the application which can then cleanly terminate.
> This indeed was done but this in turn created a problem of kernel OOPs were 
> the OOPSes were due to the fact that while the app was terminating because of 
> the SIGBUS
> it would trigger use after free in the driver by calling to accesses device 
> structures that were already released from the pci remove sequence.
> This was handled by introducing a 'flush' sequence during device removal were 
> we wait for drm file reference to drop to 0 meaning all user clients directly 
> using this device terminated.
> With this I was able to cleanly emulate device unplug with X and glxgears 
> running and later emulate device plug back and restart of X and glxgears.
> 
> v2:
> Based on discussions in the mailing list with Daniel and Pekka [1] and based 
> on the document produced by Pekka from those discussions [2] the whole 
> approach with returning SIGBUS
> and waiting for all user clients having CPU mapping of device BOs to die was 
> dropped. Instead as per the document suggestion the device structures are 
> kept alive until the last
> reference to the device is dropped by user client and in the meanwhile all 
> existing and new CPU mappings of the BOs belonging to the device directly or 
> by dma-buf import are rerouted
> to per user process dummy rw page.
> Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am 
> trying to get the minimal set of requiremnts that still give useful solution 
> to work and this is the
> 'Requirements for Render and Cross-Device UAPI' section and so my test case 
> is removing a secondary device, which is render only and is not involved in 
> KMS.
>  
> This iteration is still more of a draft as I am still facing a few unsolved 
> issues such as a crash in user client when trying to CPU map imported BO if 
> the map happens after device was
> removed and HW failure to plug back a removed device. Also since i don't have 
> real life setup with external GPU connected through TB I am using sysfs to 
> emulate pci remove and i
> expect to encounter more issues once i try this on real life case. I am also 
> expecting some help on this from a user who volunteered to test in the 
> related gitlab ticket.
> So basically this is more of a  way to get feedback if I am moving in the 
> right direction.
> 
> [1] - Discussions during v1 of the patchset 
> https://lists.freedesktop.org/archives/dri-devel/2020-May/265386.html
> [2] - drm/doc: device hot-unplug for userspace 
> https://www.spinics.net/lists/dri-devel/msg259755.html
> [3] - Related gitlab ticket 
> https://gitlab.freedesktop.org/drm/amd/-/issues/1081

A few high-level commments on the generic parts, I didn't really look at
the amdgpu side yet.

Also a nit: Please tell your mailer to break long lines, it looks funny
and inconsistent otherwise, at least in some of the mailers I use here :-/
-Daniel
>  
> 
> Andrey Grodzovsky (8):
>   drm: Add dummy page per device or GEM object
>   drm/ttm: Remap all page faults to per process dummy page.
>   drm/ttm: Add unampping of the entire device address space
>   drm/amdgpu: Split amdgpu_device_fini into early and late
>   drm/amdgpu: Refactor sysfs removal
>   drm/amdgpu: Unmap entire device address space on device remove.
>   drm/amdgpu: Fix sdma code crash post device unplug
>   drm/amdgpu: Prevent any job recoveries after device is unplugged.
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 19 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 50 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 23 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c  | 24 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h  |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  8 
>  

Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
> 
> Signed-off-by: Andrey Grodzovsky 

This seems to be missing the code to invalidate all the dma-buf mmaps?

Probably needs more testcases if you're not yet catching this. Or am I
missing something, and we're exchanging the the address space also for
dma-buf?
-Daniel

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
>  include/drm/ttm/ttm_bo_driver.h | 7 +++
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index c5b516f..926a365 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object 
> *bo)
>   ttm_bo_unmap_virtual_locked(bo);
>   ttm_mem_io_unlock(man);
>  }
> -
> -
>  EXPORT_SYMBOL(ttm_bo_unmap_virtual);
>  
> +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)
> +{
> + unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
> +}
> +EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
> +
>  int ttm_bo_wait(struct ttm_buffer_object *bo,
>   bool interruptible, bool no_wait)
>  {
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index c9e0fd0..39ea44f 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>  void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
>  
>  /**
> + * ttm_bo_unmap_virtual_address_space
> + *
> + * @bdev: tear down all the virtual mappings for this device
> + */
> +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
> +
> +/**
>   * ttm_bo_unmap_virtual
>   *
>   * @bo: tear down the virtual mappings for this BO
> -- 
> 2.7.4
> 

-- 
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 v2 2/8] drm/ttm: Remap all page faults to per process dummy page.

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page per drm_file
> instance or imported GEM object.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 
> -
>  1 file changed, 57 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 389128b..2f8bf5e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -35,6 +35,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -328,19 +330,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)

Hm I think diff and code flow look a bit bad now. What about renaming the
current function to __ttm_bo_vm_fault and then having something like the
below:

ttm_bo_vm_fault(args) {

if (drm_dev_enter()) {
__ttm_bo_vm_fault(args);
drm_dev_exit();
} else  {
drm_gem_insert_dummy_pfn();
}
}

I think drm_gem_insert_dummy_pfn(); should be portable across drivers, so
another nice point to try to unifiy drivers as much as possible.
-Daniel

>   pgprot_t prot;
>   struct ttm_buffer_object *bo = vma->vm_private_data;
>   vm_fault_t ret;
> + int idx;
> + struct drm_device *ddev = bo->base.dev;
>  
> - ret = ttm_bo_vm_reserve(bo, vmf);
> - if (ret)
> - return ret;
> + if (drm_dev_enter(ddev, )) {
> + ret = ttm_bo_vm_reserve(bo, vmf);
> + if (ret)
> + goto exit;
> +
> + prot = vma->vm_page_prot;
>  
> - prot = vma->vm_page_prot;
> - ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> - if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> + ret = ttm_bo_vm_fault_reserved(vmf, prot, 
> TTM_BO_VM_NUM_PREFAULT);
> + if (ret == VM_FAULT_RETRY && !(vmf->flags & 
> FAULT_FLAG_RETRY_NOWAIT))
> + goto exit;
> +
> + dma_resv_unlock(bo->base.resv);
> +
> +exit:
> + drm_dev_exit(idx);
>   return ret;
> + } else {
>  
> - dma_resv_unlock(bo->base.resv);
> + struct drm_file *file = NULL;
> + struct page *dummy_page = NULL;
> + int handle;
>  
> - return ret;
> + /* We are faulting on imported BO from dma_buf */
> + if (bo->base.dma_buf && bo->base.import_attach) {
> + dummy_page = bo->base.dummy_page;
> + /* We are faulting on non imported BO, find drm_file owning the 
> BO*/

Uh, we can't fish that out of the vma->vm_file pointer somehow? Or is that
one all wrong? Doing this kind of list walk looks pretty horrible.

If the vma doesn't have the right pointer I guess next option is that we
store the drm_file page in gem_bo->dummy_page, and replace it on first
export. But that's going to be tricky to track ...

> + } else {
> + struct drm_gem_object *gobj;
> +
> + mutex_lock(>filelist_mutex);
> + list_for_each_entry(file, >filelist, lhead) {
> + spin_lock(>table_lock);
> + idr_for_each_entry(>object_idr, gobj, 
> handle) {
> + if (gobj == >base) {
> + dummy_page = file->dummy_page;
> + break;
> + }
> + }
> + spin_unlock(>table_lock);
> + }
> + mutex_unlock(>filelist_mutex);
> + }
> +
> + if (dummy_page) {
> + /*
> +  * Let do_fault complete the PTE install e.t.c using 
> vmf->page
> +  *
> +  * TODO - should i call free_page somewhere ?

Nah, instead don't call get_page. The page will be around as long as
there's a reference for the drm_file or gem_bo, which is longer than any
mmap. Otherwise yes this would like really badly.

> +  */
> + get_page(dummy_page);
> + vmf->page = dummy_page;
> + return 0;
> + } else {
> + return VM_FAULT_SIGSEGV;

Hm that would be a kernel bug, wouldn't it? WARN_ON() required here imo.
-Daniel

> + }
> + }
>  }
>  EXPORT_SYMBOL(ttm_bo_vm_fault);
>  
> -- 
> 2.7.4
> 

-- 
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 v2 1/8] drm: Add dummy page per device or GEM object

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> Will be used to reroute CPU mapped BO's page faults once
> device is removed.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_file.c  |  8 
>  drivers/gpu/drm/drm_prime.c | 10 ++
>  include/drm/drm_file.h  |  2 ++
>  include/drm/drm_gem.h   |  2 ++
>  4 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index c4c704e..67c0770 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
>   goto out_prime_destroy;
>   }
>  
> + file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + if (!file->dummy_page) {
> + ret = -ENOMEM;
> + goto out_prime_destroy;
> + }
> +
>   return file;
>  
>  out_prime_destroy:
> @@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
>   if (dev->driver->postclose)
>   dev->driver->postclose(dev, file);
>  
> + __free_page(file->dummy_page);
> +
>   drm_prime_destroy_file_private(>prime);
>  
>   WARN_ON(!list_empty(>event_list));
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 1de2cde..c482e9c 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
>  
>   ret = drm_prime_add_buf_handle(_priv->prime,
>   dma_buf, *handle);
> +
> + if (!ret) {
> + obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + if (!obj->dummy_page)
> + ret = -ENOMEM;
> + }
> +
>   mutex_unlock(_priv->prime.lock);
>   if (ret)
>   goto fail;
> @@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, 
> struct sg_table *sg)
>   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
>   dma_buf = attach->dmabuf;
>   dma_buf_detach(attach->dmabuf, attach);
> +
> + __free_page(obj->dummy_page);
> +
>   /* remove the reference */
>   dma_buf_put(dma_buf);
>  }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 19df802..349a658 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -335,6 +335,8 @@ struct drm_file {
>*/
>   struct drm_prime_file_private prime;
>  

Kerneldoc for these please, including why we need them and when. E.g. the
one in gem_bo should say it's only for exported buffers, so that we're not
colliding security spaces.

> + struct page *dummy_page;
> +
>   /* private: */
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
>   unsigned long lock_count; /* DRI1 legacy lock count */
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 0b37506..47460d1 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -310,6 +310,8 @@ struct drm_gem_object {
>*
>*/
>   const struct drm_gem_object_funcs *funcs;
> +
> + struct page *dummy_page;
>  };

I think amdgpu doesn't care, but everyone else still might care somewhat
about flink. That also shares buffers, so also needs to allocate the
per-bo dummy page.

I also wonder whether we shouldn't have a helper to look up the dummy
page, just to encode in core code how it's supposedo to cascade.
-Daniel

>  
>  /**
> -- 
> 2.7.4
> 

-- 
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/3] drm: uapi: Use SPDX in DRM drivers uAPI headers

[Daniel Vetter]

On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
> Am 21.06.20 um 04:07 schrieb Laurent Pinchart:
> > Most of the DRM drivers uAPI headers are licensed under the MIT license,
> > and carry copies of the license with slight variations. Replace them
> > with SPDX headers.
> 
> My personal opinion is that this is a really good idea, but my professional
> is that we need the acknowledgment from our legal department for this.

I think official ack from amd on first patch, especially the .rst snippet,
would be really good indeed.

> Please separate that change into one for each driver/company/maintainer.
> Amdgpu, radeon, r128 can be one for example.

You can leave all the other legacy drivers in one patch (mga, savage, sis,
via), since there's likely no one around anymore and will just boil down
to drm maintainer ack from Dave
-Daniel

> 
> Thanks,
> Christian.
> 
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >   include/uapi/drm/amdgpu_drm.h  | 19 +--
> >   include/uapi/drm/i915_drm.h| 22 +-
> >   include/uapi/drm/mga_drm.h | 20 +---
> >   include/uapi/drm/msm_drm.h | 20 +---
> >   include/uapi/drm/nouveau_drm.h | 20 +---
> >   include/uapi/drm/qxl_drm.h | 20 +---
> >   include/uapi/drm/r128_drm.h| 20 +---
> >   include/uapi/drm/radeon_drm.h  | 20 +---
> >   include/uapi/drm/savage_drm.h  | 20 +---
> >   include/uapi/drm/sis_drm.h | 21 +
> >   include/uapi/drm/tegra_drm.h   | 19 +--
> >   include/uapi/drm/v3d_drm.h | 20 +---
> >   include/uapi/drm/vc4_drm.h | 20 +---
> >   include/uapi/drm/vgem_drm.h| 22 +-
> >   include/uapi/drm/via_drm.h | 20 +---
> >   include/uapi/drm/virtgpu_drm.h | 20 +---
> >   include/uapi/drm/vmwgfx_drm.h  | 21 +
> >   17 files changed, 17 insertions(+), 327 deletions(-)
> > 
> > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> > index 4e873dcbe68f..c6adda72bec7 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> > +++ b/include/uapi/drm/amdgpu_drm.h
> > @@ -1,3 +1,4 @@
> > +/* SPDX-License-Identifier: MIT */
> >   /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*-
> >*
> >* Copyright 2000 Precision Insight, Inc., Cedar Park, Texas.
> > @@ -5,24 +6,6 @@
> >* Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas.
> >* Copyright 2014 Advanced Micro Devices, Inc.
> >*
> > - * Permission is hereby granted, free of charge, to any person obtaining a
> > - * copy of this software and associated documentation files (the 
> > "Software"),
> > - * to deal in the Software without restriction, including without 
> > limitation
> > - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > - * and/or sell copies of the Software, and to permit persons to whom the
> > - * Software is furnished to do so, subject to the following conditions:
> > - *
> > - * The above copyright notice and this permission notice shall be included 
> > in
> > - * all copies or substantial portions of the Software.
> > - *
> > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > - * OTHER DEALINGS IN THE SOFTWARE.
> > - *
> >* Authors:
> >*Kevin E. Martin 
> >*Gareth Hughes 
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 14b67cd6b54b..c29e3acb3026 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1,27 +1,7 @@
> > +/* SPDX-License-Identifier: MIT */
> >   /*
> >* Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
> >* All Rights Reserved.
> > - *
> > - * Permission is hereby granted, free of charge, to any person obtaining a
> > - * copy of this software and associated documentation files (the
> > - * "Software"), to deal in the Software without restriction, including
> > - * without limitation the rights to use, copy, modify, merge, publish,
> > - * distribute, sub license, and/or sell copies of the Software, and to
> > - * permit persons to whom the Software is furnished to do so, subject to
> > - * the following conditions:
> > - *
> > - * The above copyright notice and this permission notice (including the
> > - * next paragraph) shall be included in all copies or substantial portions
> > - * of the Software.
> > - *
> > - * THE SOFTWARE IS 

Re: [kbuild-all] Re: [PATCH 4/4] drm: pl111: Update documentation

[Rong Chen]

On 6/12/20 8:40 PM, Philip Li wrote:

On Fri, Jun 12, 2020 at 01:04:02PM +0200, Linus Walleij wrote:

On Wed, Jun 10, 2020 at 9:38 AM kernel test robot  wrote:


I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next 
tegra-drm/drm/tegra/for-next linus/master v5.7 next-20200609]
[cannot apply to drm-tip/drm-tip drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Linus-Walleij/drm-pl111-Credit-where-credit-is-due/20200610-041025
base:   https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next
reproduce: make htmldocs

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

What on earth was that. The robot reports on a patch only adding a few lines
of comments as breaking the whole universe, and none of these systems
even use the PL111.

Thanks for feedback, this is supposed to check make htmldocs. We will double
check this to fix issue. Sorry for noise.


Hi Linus,

We won't show unrelated htmldocs warnings in the future,
but the warning (with prefix '>>') was found in this patch,
could you take a look?


drivers/gpu/drm/pl111/pl111_drv.c:1: warning: 'ARM PrimeCell PL111 CLCD Driver' 
not found



Best Regards,
Rong Chen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: uapi: Remove copies of GPL license text from headers

[Daniel Vetter]

On Sun, Jun 21, 2020 at 05:07:03AM +0300, Laurent Pinchart wrote:
> Several DRM drivers uAPI headers that are licensed under the GPL carry
> both an SPDX header and a copy of the license text. Drop the latter.
> 
> Signed-off-by: Laurent Pinchart 

I do kinda wonder how much lolz these gpl-only headers are. With or
without syscall exception, the ioctls in here are imo very far away from a
standardized syscall of any form.

But also not my problem :-)

Reviewed-by: Daniel Vetter 

> ---
>  include/uapi/drm/armada_drm.h  |  4 
>  include/uapi/drm/etnaviv_drm.h | 12 
>  include/uapi/drm/exynos_drm.h  |  5 -
>  include/uapi/drm/omap_drm.h| 12 
>  4 files changed, 33 deletions(-)
> 
> diff --git a/include/uapi/drm/armada_drm.h b/include/uapi/drm/armada_drm.h
> index af1c14c837c5..f711e63a9758 100644
> --- a/include/uapi/drm/armada_drm.h
> +++ b/include/uapi/drm/armada_drm.h
> @@ -2,10 +2,6 @@
>  /*
>   * Copyright (C) 2012 Russell King
>   *  With inspiration from the i915 driver
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>  #ifndef DRM_ARMADA_IOCTL_H
>  #define DRM_ARMADA_IOCTL_H
> diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
> index 09d0df8b71c5..e23e0f885655 100644
> --- a/include/uapi/drm/etnaviv_drm.h
> +++ b/include/uapi/drm/etnaviv_drm.h
> @@ -1,18 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>  /*
>   * Copyright (C) 2015 Etnaviv Project
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
>   */
>  
>  #ifndef __ETNAVIV_DRM_H__
> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
> index a51aa1c618c1..a96fa566433c 100644
> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h
> @@ -6,11 +6,6 @@
>   *   Inki Dae 
>   *   Joonyoung Shim 
>   *   Seung-Woo Kim 
> - *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
>   */
>  
>  #ifndef _UAPI_EXYNOS_DRM_H_
> diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
> index 5a142fad473c..b51dad32122d 100644
> --- a/include/uapi/drm/omap_drm.h
> +++ b/include/uapi/drm/omap_drm.h
> @@ -4,18 +4,6 @@
>   *
>   * Copyright (C) 2011 Texas Instruments
>   * Author: Rob Clark 
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
>   */
>  
>  #ifndef __OMAP_DRM_H__
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
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 1/3] drm: uapi: Use SPDX in DRM core uAPI headers

[Daniel Vetter]

On Sun, Jun 21, 2020 at 05:07:01AM +0300, Laurent Pinchart wrote:
> The DRM core uAPI headers are licensed under the MIT license, and carry
> copies of the license with slight variations. Replace them with SPDX
> headers.
> 
> Following a discussion with Daniel Vetter on this topic, add a
> clarification in the drm-uapi.rst file that independent closed-source
> userspace implementations of software using the DRM uAPI are accepted,
> as allowed by the MIT license.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: Thomas Gleixner 

Reviewed-by: Daniel Vetter 

> ---
>  Documentation/gpu/drm-uapi.rst |  4 
>  include/uapi/drm/drm.h | 20 +---
>  include/uapi/drm/drm_fourcc.h  | 20 +---
>  include/uapi/drm/drm_mode.h| 19 +--
>  include/uapi/drm/drm_sarea.h   | 20 +---
>  5 files changed, 8 insertions(+), 75 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..de2ecc76dd6c 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -107,6 +107,10 @@ is already rather painful for the DRM subsystem, with 
> multiple different uAPIs
>  for the same thing co-existing. If we add a few more complete mistakes into 
> the
>  mix every year it would be entirely unmanageable.
>  
> +The DRM subsystem has however no concern with independent closed-source
> +userspace implementations. To officialize that position, the DRM uAPI headers
> +are covered by the MIT license.
> +
>  .. _drm_render_node:
>  
>  Render nodes
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 808b48a93330..14d57361e580 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: MIT */
>  /**
>   * \file drm.h
>   * Header for the Direct Rendering Manager
> @@ -12,25 +13,6 @@
>   * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
>   * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
>   * All rights reserved.
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifndef _DRM_H_
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..d2c4a597620f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1,24 +1,6 @@
> +/* SPDX-License-Identifier: MIT */
>  /*
>   * Copyright 2011 Intel Corporation
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifndef DRM_FOURCC_H
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 735c8cfdaaa1..c34a544fdf29 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ 

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Daniel Vetter]

On Fri, Jun 19, 2020 at 3:12 PM Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2020-06-19 10:43:09)
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson 
> > > >  wrote:
> > > > > Forcing a generic primitive to always be part of the same global map 
> > > > > is
> > > > > horrible.
> > > >
> > > > And  no concrete example or reason for why that's not possible.
> > > > Because frankly it's not horrible, this is what upstream is all about:
> > > > Shared concepts, shared contracts, shared code.
> > > >
> > > > The proposed patches might very well encode the wrong contract, that's
> > > > all up for discussion. But fundamentally questioning that we need one
> > > > is missing what upstream is all about.
> > >
> > > Then I have not clearly communicated, as my opinion is not that
> > > validation is worthless, but that the implementation is enshrining a
> > > global property on a low level primitive that prevents it from being
> > > used elsewhere. And I want to replace completion [chains] with fences, and
> > > bio with fences, and closures with fences, and what other equivalencies
> > > there are in the kernel. The fence is as central a locking construct as
> > > struct completion and deserves to be a foundational primitive provided
> > > by kernel/ used throughout all drivers for discrete problem domains.
> > >
> > > This is narrowing dma_fence whereby adding
> > >   struct lockdep_map *dma_fence::wait_map
> > > and annotating linkage, allows you to continue to specify that all
> > > dma_fence used for a particular purpose must follow common rules,
> > > without restricting the primitive for uses outside of this scope.
> >
> > Somewhere else in this thread I had discussions with Jason Gunthorpe about
> > this topic. It might maybe change somewhat depending upon exact rules, but
> > his take is very much "I don't want dma_fence in rdma". Or pretty close to
> > that at least.
> >
> > Similar discussions with habanalabs, they're using dma_fence internally
> > without any of the uapi. Discussion there has also now concluded that it's
> > best if they remove them, and simply switch over to a wait_queue or
> > completion like every other driver does.
> >
> > The next round of the patches already have a paragraph to at least
> > somewhat limit how non-gpu drivers use dma_fence. And I guess actual
> > consensus might be pointing even more strongly at dma_fence being solely
> > something for gpus and closely related subsystem (maybe media) for syncing
> > dma-buf access.
> >
> > So dma_fence as general replacement for completion chains I think just
> > wont happen.
>
> That is sad. I cannot comprehend going back to pure completions after a
> taste of fence scheduling. And we are not even close to fully utilising
> them, as not all the async cpu [allocation!] tasks are fully tracked by
> fences yet and are still stuck in a FIFO workqueue.
>
> > What might make sense is if e.g. the lockdep annotations could be reused,
> > at least in design, for wait_queue or completion or anything else
> > really. I do think that has a fair chance compared to the automagic
> > cross-release annotations approach, which relied way too heavily on
> > guessing where barriers are. My experience from just a bit of playing
> > around with these patches here and discussing them with other driver
> > maintainers is that accurately deciding where critical sections start and
> > end is a job for humans only. And if you get it wrong, you will have a
> > false positive.
> >
> > And you're indeed correct that if we'd do annotations for completions and
> > wait queues, then that would need to have a class per semantically
> > equivalent user, like we have lockdep classes for mutexes, not just one
> > overall.
> >
> > But dma_fence otoh is something very specific, which comes with very
> > specific rules attached - it's not a generic wait_queue at all. Originally
> > it did start out as one even, but it is a very specialized wait_queue.
> >
> > So there's imo two cases:
> >
> > - Your completion is entirely orthogonal of dma_fences, and can never ever
> >   block a dma_fence. Don't use dma_fence for this, and no problem. It's
> >   just another wait_queue somewhere.
> >
> > - Your completion can eventually, maybe through lots of convolutions and
> >   depdencies, block a dma_fence. In that case full dma_fence rules apply,
> >   and the only thing you can do with a custom annotation is make the rules
> >   even stricter. E.g. if a sub-timeline in the scheduler isn't allowed to
> >   take certain scheduler locks. But the userspace visible/published fence
> >   do take them, maybe as part of command submission or retirement.
> >   Entirely hypotethical, no idea any driver actually needs this.
>
> I think we are faced with this very real problem.
>
> The papering we have today over userptr is so very thin, and if you
> squint you can