[Nouveau] [PATCH v4 8/8] nouveau/svm: Implement atomic SVM access
Some NVIDIA GPUs do not support direct atomic access to system memory
via PCIe. Instead this must be emulated by granting the GPU exclusive
access to the memory. This is achieved by replacing CPU page table
entries with special swap entries that fault on userspace access.
The driver then grants the GPU permission to update the page undergoing
atomic access via the GPU page tables. When CPU access to the page is
required a CPU fault is raised which calls into the device driver via
MMU notifiers to revoke the atomic access. The original page table
entries are then restored allowing CPU access to proceed.
Signed-off-by: Alistair Popple
---
v4:
* Check that page table entries haven't changed before mapping on the
device
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 107 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 +
4 files changed, 107 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index d6dd40f21eed..9c7ff56831c5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -77,6 +77,7 @@ struct nvif_vmm_pfnmap_v0 {
#define NVIF_VMM_PFNMAP_V0_APER 0x00f0ULL
#define NVIF_VMM_PFNMAP_V0_HOST 0xULL
#define NVIF_VMM_PFNMAP_V0_VRAM 0x0010ULL
+#define NVIF_VMM_PFNMAP_V0_A 0x0004ULL
#define NVIF_VMM_PFNMAP_V0_W 0x0002ULL
#define NVIF_VMM_PFNMAP_V0_V 0x0001ULL
#define NVIF_VMM_PFNMAP_V0_NONE 0xULL
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index cd7b47c946cf..6d24424770e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
struct nouveau_svm {
struct nouveau_drm *drm;
@@ -421,9 +422,9 @@ nouveau_svm_fault_cmp(const void *a, const void *b)
return ret;
if ((ret = (s64)fa->addr - fb->addr))
return ret;
- /*XXX: atomic? */
- return (fa->access == 0 || fa->access == 3) -
- (fb->access == 0 || fb->access == 3);
+ /* Atomic access (2) has highest priority */
+ return (-1*(fa->access == 2) + (fa->access == 0 || fa->access == 3)) -
+ (-1*(fb->access == 2) + (fb->access == 0 || fb->access == 3));
}
static void
@@ -555,6 +556,84 @@ static void nouveau_hmm_convert_pfn(struct nouveau_drm
*drm,
args->p.phys[0] |= NVIF_VMM_PFNMAP_V0_W;
}
+static int nouveau_atomic_range_fault(struct nouveau_svmm *svmm,
+ struct nouveau_drm *drm,
+ struct nouveau_pfnmap_args *args, u32 size,
+ struct svm_notifier *notifier)
+{
+ unsigned long timeout =
+ jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
+ struct mm_struct *mm = svmm->notifier.mm;
+ struct page *page;
+ unsigned long start = args->p.addr;
+ unsigned long notifier_seq;
+ int ret = 0;
+
+ ret = mmu_interval_notifier_insert(¬ifier->notifier, mm,
+ args->p.addr, args->p.size,
+ &nouveau_svm_mni_ops);
+ if (ret)
+ return ret;
+
+ mmap_read_lock(mm);
+ make_device_exclusive_range(mm, start, start + PAGE_SIZE, &page);
+ mmap_read_unlock(mm);
+ if (!page) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ while (true) {
+ if (time_after(jiffies, timeout)) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ notifier_seq = mmu_interval_read_begin(¬ifier->notifier);
+ if (!check_device_exclusive_range(mm, start, start + PAGE_SIZE,
+ &page)) {
+ mmap_read_lock(mm);
+ make_device_exclusive_range(mm, start,
+ start + PAGE_SIZE, &page);
+ mmap_read_unlock(mm);
+ if (!page) {
+ ret = -EINVAL;
+ goto out;
+ }
+ continue;
+ }
+ mutex_lock(&svmm->mutex);
+ if (mmu_interval_read_retry(¬ifier->notifier,
+ notifier_seq)) {
+ mutex_unlock(&svmm->mutex);
+ continue;
+
[Nouveau] [PATCH v4 7/8] nouveau/svm: Refactor nouveau_range_fault
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 34 ---
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index f18bd53da052..cd7b47c946cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -567,18 +567,27 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
unsigned long hmm_pfns[1];
struct hmm_range range = {
.notifier = ¬ifier->notifier,
- .start = notifier->notifier.interval_tree.start,
- .end = notifier->notifier.interval_tree.last + 1,
.default_flags = hmm_flags,
.hmm_pfns = hmm_pfns,
.dev_private_owner = drm->dev,
};
- struct mm_struct *mm = notifier->notifier.mm;
+ struct mm_struct *mm = svmm->notifier.mm;
int ret;
+ ret = mmu_interval_notifier_insert(¬ifier->notifier, mm,
+ args->p.addr, args->p.size,
+ &nouveau_svm_mni_ops);
+ if (ret)
+ return ret;
+
+ range.start = notifier->notifier.interval_tree.start;
+ range.end = notifier->notifier.interval_tree.last + 1;
+
while (true) {
- if (time_after(jiffies, timeout))
- return -EBUSY;
+ if (time_after(jiffies, timeout)) {
+ ret = -EBUSY;
+ goto out;
+ }
range.notifier_seq = mmu_interval_read_begin(range.notifier);
mmap_read_lock(mm);
@@ -587,7 +596,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
if (ret) {
if (ret == -EBUSY)
continue;
- return ret;
+ goto out;
}
mutex_lock(&svmm->mutex);
@@ -606,6 +615,9 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(&svmm->mutex);
+out:
+ mmu_interval_notifier_remove(¬ifier->notifier);
+
return ret;
}
@@ -727,14 +739,8 @@ nouveau_svm_fault(struct nvif_notify *notify)
}
notifier.svmm = svmm;
- ret = mmu_interval_notifier_insert(¬ifier.notifier, mm,
- args.i.p.addr, args.i.p.size,
- &nouveau_svm_mni_ops);
- if (!ret) {
- ret = nouveau_range_fault(svmm, svm->drm, &args.i,
- sizeof(args), hmm_flags, ¬ifier);
- mmu_interval_notifier_remove(¬ifier.notifier);
- }
+ ret = nouveau_range_fault(svmm, svm->drm, &args.i,
+ sizeof(args), hmm_flags, ¬ifier);
mmput(mm);
limit = args.i.p.addr + args.i.p.size;
--
2.20.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 6/8] mm: Selftests for exclusive device memory
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 219 +
3 files changed, 345 insertions(+)
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 80a78877bd93..7dc3bc286934 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "test_hmm_uapi.h"
@@ -46,6 +47,7 @@ struct dmirror_bounce {
unsigned long cpages;
};
+#define DPT_XA_TAG_ATOMIC 1UL
#define DPT_XA_TAG_WRITE 3UL
/*
@@ -619,6 +621,54 @@ static void dmirror_migrate_alloc_and_copy(struct
migrate_vma *args,
}
}
+static int dmirror_check_atomic(struct dmirror *dmirror, unsigned long start,
+unsigned long end)
+{
+ unsigned long pfn;
+
+ for (pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT); pfn++) {
+ void *entry;
+ struct page *page;
+
+ entry = xa_load(&dmirror->pt, pfn);
+ page = xa_untag_pointer(entry);
+ if (xa_pointer_tag(entry) == DPT_XA_TAG_ATOMIC)
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+static int dmirror_atomic_map(unsigned long start, unsigned long end,
+ struct page **pages, struct dmirror *dmirror)
+{
+ unsigned long pfn, mapped = 0;
+ int i;
+
+ /* Map the migrated pages into the device's page tables. */
+ mutex_lock(&dmirror->mutex);
+
+ for (i = 0, pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT);
pfn++, i++) {
+ void *entry;
+
+ if (!pages[i])
+ continue;
+
+ entry = pages[i];
+ entry = xa_tag_pointer(entry, DPT_XA_TAG_ATOMIC);
+ entry = xa_store(&dmirror->pt, pfn, entry, GFP_ATOMIC);
+ if (xa_is_err(entry)) {
+ mutex_unlock(&dmirror->mutex);
+ return xa_err(entry);
+ }
+
+ mapped++;
+ }
+
+ mutex_unlock(&dmirror->mutex);
+ return mapped;
+}
+
static int dmirror_migrate_finalize_and_map(struct migrate_vma *args,
struct dmirror *dmirror)
{
@@ -661,6 +711,71 @@ static int dmirror_migrate_finalize_and_map(struct
migrate_vma *args,
return 0;
}
+static int dmirror_exclusive(struct dmirror *dmirror,
+struct hmm_dmirror_cmd *cmd)
+{
+ unsigned long start, end, addr;
+ unsigned long size = cmd->npages << PAGE_SHIFT;
+ struct mm_struct *mm = dmirror->notifier.mm;
+ struct page *pages[64];
+ struct dmirror_bounce bounce;
+ unsigned long next;
+ int ret;
+
+ start = cmd->addr;
+ end = start + size;
+ if (end < start)
+ return -EINVAL;
+
+ /* Since the mm is for the mirrored process, get a reference first. */
+ if (!mmget_not_zero(mm))
+ return -EINVAL;
+
+ mmap_read_lock(mm);
+ for (addr = start; addr < end; addr = next) {
+ int i, mapped;
+
+ if (end < addr + (ARRAY_SIZE(pages) << PAGE_SHIFT))
+ next = end;
+ else
+ next = addr + (ARRAY_SIZE(pages) << PAGE_SHIFT);
+
+ ret = make_device_exclusive_range(mm, addr, next, pages);
+ mapped = dmirror_atomic_map(addr, next, pages, dmirror);
+ for (i = 0; i < ret; i++) {
+ if (pages[i]) {
+ unlock_page(pages[i]);
+ put_page(pages[i]);
+ }
+ }
+
+ if (addr + (mapped << PAGE_SHIFT) < next) {
+ mmap_read_unlock(mm);
+ mmput(mm);
+ return -EBUSY;
+ }
+ }
+ mmap_read_unlock(mm);
+ mmput(mm);
+
+ /* Return the migrated data for verification. */
+ ret = dmirror_bounce_init(&bounce, start, size);
+ if (ret)
+ return ret;
+ mutex_lock(&dmirror->mutex);
+ ret = dmirror_do_read(dmirror, start, end, &bounce);
+ mutex_unlock(&dmirror->mutex);
+ if (ret == 0) {
+ if (copy_to_user(u64_to_user_ptr(cmd->ptr), bounce.ptr,
+bounce.size))
+ ret = -EFAULT;
+ }
+
+ cmd->cpages = bounce.cpages;
+ dmirror_bounce_fini(&bounce);
+ return ret;
+}
+
static int dmirror_migrate(struct dmirror *dmirror,
struct hmm_dmirror_cmd *cmd)
{
@@ -949,6 +1064,15 @@ static long dmirror_fops_unlocked_ioctl(struct file *filp,
[Nouveau] [PATCH v4 5/8] mm: Device exclusive memory access
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for
exclusive access by a device all page table mappings for the particular
range are replaced with device exclusive swap entries. This causes any
CPU access to the page to result in a fault.
Faults are resovled by replacing the faulting entry with the original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
v4:
* Add function to check that mappings are still valid and exclusive.
* s/long/unsigned long/ in make_device_exclusive_entry().
---
Documentation/vm/hmm.rst | 15 +++
include/linux/rmap.h | 5 +
include/linux/swap.h | 4 +-
include/linux/swapops.h | 44 +++-
mm/hmm.c | 5 +
mm/memory.c | 107 +-
mm/mprotect.c| 8 ++
mm/page_vma_mapped.c | 9 +-
mm/rmap.c| 230 +++
9 files changed, 420 insertions(+), 7 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..f526ac4d8798 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -405,6 +405,21 @@ between device driver specific code and shared common code:
The lock can now be released.
+Exclusive access memory
+===
+
+Not all devices support atomic access to system memory. To support atomic
+operations to a shared virtual memory page such a device needs access to that
+page which is exclusive of any userspace access from the CPU. The
+``make_device_exclusive_range()`` function can be used to make a memory range
+inaccessible from userspace.
+
+This replaces all mappings for pages in the given range with special swap
+entries. Any attempt to access the swap entry results in a fault which is
+resovled by replacing the entry with the original mapping. A driver gets
+notified that the mapping has been changed by MMU notifiers, after which point
+it will no longer have exclusive access to the page.
+
Memory cgroup (memcg) and rss accounting
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 77fa17de51d7..93cbb88f7253 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -193,6 +193,11 @@ int page_referenced(struct page *, int is_locked,
bool try_to_migrate(struct page *page, enum ttu_flags flags);
bool try_to_unmap(struct page *, enum ttu_flags flags);
+int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
+ unsigned long end, struct page **pages);
+bool check_device_exclusive_range(struct mm_struct *mm, unsigned long start,
+ unsigned long end, struct page **pages);
+
/* Avoid racy checks */
#define PVMW_SYNC (1 << 0)
/* Look for migarion entries rather than present PTEs */
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 57a7690966a4..2d8b8e7fb4c2 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -63,9 +63,11 @@ static inline int current_is_kswapd(void)
* to a special SWP_DEVICE_* entry.
*/
#ifdef CONFIG_DEVICE_PRIVATE
-#define SWP_DEVICE_NUM 2
+#define SWP_DEVICE_NUM 4
#define SWP_DEVICE_WRITE (MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM)
#define SWP_DEVICE_READ (MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+1)
+#define SWP_DEVICE_EXCLUSIVE_WRITE
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+2)
+#define SWP_DEVICE_EXCLUSIVE_READ
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+3)
#else
#define SWP_DEVICE_NUM 0
#endif
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 81008b0179cc..20b726e27f37 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -120,6 +120,27 @@ static inline bool
is_writable_device_private_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
}
+
+static inline swp_entry_t make_readable_device_exclusive_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_DEVICE_EXCLUSIVE_READ, offset);
+}
+
+static inline swp_entry_t make_writable_device_exclusive_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_DEVICE_EXCLUSIVE_WRITE, offset);
+}
+
+static inline bool is_device_exclusive_entry(swp_entry_t entry)
+{
+ return swp_type(entry) == SWP_DEVICE_EXCLUSIVE_READ ||
+ swp_type(entry) == SWP_DEVICE_EXCLUSIVE_WRITE;
+}
+
+static inline bool is_writable_device_exclusive_entry(swp_entry_t entry)
+{
+ return unlikely(swp_type(entry) == SWP_DEVICE_EXCLUSIVE_WRIT
[Nouveau] [PATCH v4 4/8] mm/rmap: Split migration into its own function
Migration is currently implemented as a mode of operation for
try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
However it does not have much in common with the rest of the unmap
functionality of try_to_unmap_one() and thus splitting it into a
separate function reduces the complexity of try_to_unmap_one() making it
more readable.
Several simplifications can also be made in try_to_migrate_one() based
on the following observations:
- All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK.
- No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON.
- No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH.
TTU_SPLIT_FREEZE is a special case of migration used when splitting an
anonymous page. This is most easily dealt with by calling the correct
function from unmap_page() in mm/huge_memory.c - either
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 10 +-
mm/migrate.c | 9 +-
mm/rmap.c| 352 +++
4 files changed, 269 insertions(+), 106 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 7f1ee411bd7b..77fa17de51d7 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -86,8 +86,6 @@ struct anon_vma_chain {
};
enum ttu_flags {
- TTU_MIGRATION = 0x1, /* migration mode */
-
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
TTU_IGNORE_HWPOISON = 0x20, /* corrupted page is recoverable */
@@ -96,7 +94,6 @@ enum ttu_flags {
* do a final flush if necessary */
TTU_RMAP_LOCKED = 0x80, /* do not grab rmap lock:
* caller holds it */
- TTU_SPLIT_FREEZE= 0x100,/* freeze pte under
splitting thp */
};
#ifdef CONFIG_MMU
@@ -193,6 +190,7 @@ static inline void page_dup_rmap(struct page *page, bool
compound)
int page_referenced(struct page *, int is_locked,
struct mem_cgroup *memcg, unsigned long *vm_flags);
+bool try_to_migrate(struct page *page, enum ttu_flags flags);
bool try_to_unmap(struct page *, enum ttu_flags flags);
/* Avoid racy checks */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index cb3bc9d3ed3a..4589b483c99e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2351,16 +2351,16 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma,
static void unmap_page(struct page *page)
{
- enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
- TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
+ enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
bool unmap_success;
VM_BUG_ON_PAGE(!PageHead(page), page);
if (PageAnon(page))
- ttu_flags |= TTU_SPLIT_FREEZE;
-
- unmap_success = try_to_unmap(page, ttu_flags);
+ unmap_success = try_to_migrate(page, ttu_flags);
+ else
+ unmap_success = try_to_unmap(page, ttu_flags |
+ TTU_IGNORE_MLOCK);
VM_BUG_ON_PAGE(!unmap_success, page);
}
diff --git a/mm/migrate.c b/mm/migrate.c
index 30c18e7c6089..bea67789a5b2 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1124,7 +1124,7 @@ static int __unmap_and_move(struct page *page, struct
page *newpage,
/* Establish migration ptes */
VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && !anon_vma,
page);
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK);
+ try_to_migrate(page, 0);
page_was_mapped = 1;
}
@@ -1326,7 +1326,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
if (page_mapped(hpage)) {
bool mapping_locked = false;
- enum ttu_flags ttu = TTU_MIGRATION|TTU_IGNORE_MLOCK;
+ enum ttu_flags ttu = 0;
if (!PageAnon(hpage)) {
/*
@@ -1343,7 +1343,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
ttu |= TTU_RMAP_LOCKED;
}
- try_to_unmap(hpage, ttu);
+ try_to_migrate(hpage, ttu);
page_was_mapped = 1;
if (mapping_locked)
@@ -2750,7 +2750,6 @@ static void migrate_vma_prepare(struct migrate_vma
*migrate)
*/
static void migrate_vma_unmap(struct migrate_vma *migrate)
{
- int flags = TTU_MIGRATION | TTU_IGNORE_MLOCK;
const unsigned long npages = migrate->npages;
const unsigned long start = migrate->start;
unsigned long addr, i, restore = 0;
@@ -2762,7 +2761,7 @@ static void migrate_vma_unmap(struct migrate_vma *migrate)
[Nouveau] [PATCH v4 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
The behaviour of try_to_unmap_one() is difficult to follow because it
performs different operations based on a fairly large set of flags used
in different combinations.
TTU_MUNLOCK is one such flag. However it is exclusively used by
try_to_munlock() which specifies no other flags. Therefore rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
---
Christoph - I didn't add your Reviewed-by because removal of the extra
VM_LOCKED check changed things slightly. Let me know if you're still ok
for me to add it. Thanks.
v4:
* Removed redundant check for VM_LOCKED
---
include/linux/rmap.h | 1 -
mm/rmap.c| 40
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 70085ca1a3fc..7f1ee411bd7b 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -87,7 +87,6 @@ struct anon_vma_chain {
enum ttu_flags {
TTU_MIGRATION = 0x1, /* migration mode */
- TTU_MUNLOCK = 0x2, /* munlock mode */
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
diff --git a/mm/rmap.c b/mm/rmap.c
index ef9ef2694c58..c8a637abffb3 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1391,10 +1391,6 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
struct mmu_notifier_range range;
enum ttu_flags flags = (enum ttu_flags)(long)arg;
- /* munlock has nothing to gain from examining un-locked vmas */
- if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
- return true;
-
if (IS_ENABLED(CONFIG_MIGRATION) && (flags & TTU_MIGRATION) &&
is_zone_device_page(page) && !is_device_private_page(page))
return true;
@@ -1455,8 +1451,6 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
page_vma_mapped_walk_done(&pvmw);
break;
}
- if (flags & TTU_MUNLOCK)
- continue;
}
/* Unexpected PMD-mapped THP? */
@@ -1775,6 +1769,37 @@ static int page_not_mapped(struct page *page)
return !page_mapped(page);
};
+static bool try_to_munlock_one(struct page *page, struct vm_area_struct *vma,
+unsigned long address, void *arg)
+{
+ struct page_vma_mapped_walk pvmw = {
+ .page = page,
+ .vma = vma,
+ .address = address,
+ };
+
+ /* munlock has nothing to gain from examining un-locked vmas */
+ if (!(vma->vm_flags & VM_LOCKED))
+ return true;
+
+ while (page_vma_mapped_walk(&pvmw)) {
+ /* PTE-mapped THP are never mlocked */
+ if (!PageTransCompound(page)) {
+ /*
+* Holding pte lock, we do *not* need
+* mmap_lock here
+*/
+ mlock_vma_page(page);
+ }
+ page_vma_mapped_walk_done(&pvmw);
+
+ /* found a mlocked page, no point continuing munlock check */
+ return false;
+ }
+
+ return true;
+}
+
/**
* try_to_munlock - try to munlock a page
* @page: the page to be munlocked
@@ -1787,8 +1812,7 @@ static int page_not_mapped(struct page *page)
void try_to_munlock(struct page *page)
{
struct rmap_walk_control rwc = {
- .rmap_one = try_to_unmap_one,
- .arg = (void *)TTU_MUNLOCK,
+ .rmap_one = try_to_munlock_one,
.done = page_not_mapped,
.anon_lock = page_lock_anon_vma_read,
--
2.20.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 2/8] mm/swapops: Rework swap entry manipulation code
Both migration and device private pages use special swap entries that
are manipluated by a range of inline functions. The arguments to these
are somewhat inconsitent so rework them to remove flag type arguments
and to make the arguments similar for both read and write entry
creation.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c| 10 +---
mm/memory.c | 10 +---
mm/migrate.c| 26 ++-
mm/mprotect.c | 10 +---
mm/rmap.c | 10 +---
9 files changed, 100 insertions(+), 62 deletions(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 3fd88081107c..81008b0179cc 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -100,35 +100,35 @@ static inline void *swp_to_radix_entry(swp_entry_t entry)
}
#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
- return swp_entry(write ? SWP_DEVICE_WRITE : SWP_DEVICE_READ,
-page_to_pfn(page));
+ return swp_entry(SWP_DEVICE_READ, offset);
}
-static inline bool is_device_private_entry(swp_entry_t entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
- int type = swp_type(entry);
- return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
+ return swp_entry(SWP_DEVICE_WRITE, offset);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline bool is_device_private_entry(swp_entry_t entry)
{
- *entry = swp_entry(SWP_DEVICE_READ, swp_offset(*entry));
+ int type = swp_type(entry);
+ return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
}
#else /* CONFIG_DEVICE_PRIVATE */
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
return swp_entry(0, 0);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
+ return swp_entry(0, 0);
}
static inline bool is_device_private_entry(swp_entry_t entry)
@@ -136,35 +136,32 @@ static inline bool is_device_private_entry(swp_entry_t
entry)
return false;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return false;
}
#endif /* CONFIG_DEVICE_PRIVATE */
#ifdef CONFIG_MIGRATION
-static inline swp_entry_t make_migration_entry(struct page *page, int write)
-{
- BUG_ON(!PageLocked(compound_head(page)));
-
- return swp_entry(write ? SWP_MIGRATION_WRITE : SWP_MIGRATION_READ,
- page_to_pfn(page));
-}
-
static inline int is_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_READ ||
swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline int is_write_migration_entry(swp_entry_t entry)
+static inline int is_writable_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline void make_migration_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
{
- *entry = swp_entry(SWP_MIGRATION_READ, swp_offset(*entry));
+ return swp_entry(SWP_MIGRATION_READ, offset);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_MIGRATION_WRITE, offset);
}
extern void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
@@ -174,21 +171,28 @@ extern void migration_entry_wait(struct mm_struct *mm,
pmd_t *pmd,
extern void migration_entry_wait_huge(struct vm_area_struct *vma,
struct mm_struct *mm, pte_t *pte);
#else
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
-#define make_migration_entry(page, write) swp_entry(0, 0)
static inline int is_migration_entry(swp_entry_t swp)
{
return 0;
}
-static inline void make_migration_entry_read(swp_entry_t *entryp) { }
static inline void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
[Nouveau] [PATCH v4 1/8] mm: Remove special swap entry functions
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
---
v4:
* Added pfn_swap_entry_to_page()
* Reinstated check that migration entries point to locked pages
* Removed #define swapcache_prepare which isn't needed for CONFIG_SWAP=0
builds
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23 +-
include/linux/swap.h| 4 +--
include/linux/swapops.h | 69 ++---
mm/hmm.c| 5 ++-
mm/huge_memory.c| 4 +--
mm/memcontrol.c | 2 +-
mm/memory.c | 10 +++---
mm/migrate.c| 6 ++--
mm/page_vma_mapped.c| 6 ++--
10 files changed, 50 insertions(+), 81 deletions(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 18205f851c24..aae001096c46 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -691,7 +691,7 @@ static void ptep_zap_swap_entry(struct mm_struct *mm,
swp_entry_t entry)
if (!non_swap_entry(entry))
dec_mm_counter(mm, MM_SWAPENTS);
else if (is_migration_entry(entry)) {
- struct page *page = migration_entry_to_page(entry);
+ struct page *page = pfn_swap_entry_to_page(entry));
dec_mm_counter(mm, mm_counter(page));
}
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 602e3a52884d..7c75af0fc423 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -514,10 +514,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
} else {
mss->swap_pss += (u64)PAGE_SIZE << PSS_SHIFT;
}
- } else if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ } else if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
} else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
&& pte_none(*pte))) {
page = xa_load(&vma->vm_file->f_mapping->i_pages,
@@ -549,7 +547,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
swp_entry_t entry = pmd_to_swp_entry(*pmd);
if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
if (IS_ERR_OR_NULL(page))
return;
@@ -691,10 +689,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long
hmask,
} else if (is_swap_pte(*pte)) {
swp_entry_t swpent = pte_to_swp_entry(*pte);
- if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
}
if (page) {
int mapcount = page_mapcount(page);
@@ -1382,11 +1378,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct
pagemapread *pm,
frame = swp_type(entry) |
(swp_offset(entry) << MAX_SWAPFILES_SHIFT);
flags |= PM_SWAP;
- if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
-
- if (is_device_private_entry(entry))
- page = device_private_entry_to_page(entry);
+ if (is_pfn_swap_entry(entry))
+ page = pfn_swap_entry_to_page(entry);
}
if (page && !PageAnon(page))
@@ -1443,7 +1436,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long
addr, unsigned long end,
if (pmd_swp_soft_dirty(pmd))
flags |= PM_SOFT_DIRTY;
VM_BUG_ON(!is_pmd_migration_entry(pmd));
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
#endif
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 596bc2f4d9b0..57a7690966a4 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -519,8 +519,8 @@ static inline void show_swap_cache_info(void)
{
}
-#define free_swap_and_cache(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
-#define swapcache_prepare(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
+/* used to sanity check ptes in zap_pte_range when CONFIG_SWAP=0 */
+#define free_swap_and_cache(e) is_pfn_swap_entry(e)
[Nouveau] [PATCH v4 0/8] Add support for SVM atomics in Nouveau
This is the forth version of a series to add support to Nouveau for atomic memory operations on OpenCL shared virtual memory (SVM) regions. This is achieved using the atomic PTE bits on the GPU to only permit atomic operations to system memory when a page is not mapped in userspace on the CPU. The previous version of this series used an unmap and pin page migration, however this resulted in problems with ZONE_MOVABLE and other issues so this series uses a different approach. Instead exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches 1 & 2 refactor existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). These should not change any functionality, but any help testing would be much appreciated as I have not been able to test every usage of try_to_unmap_one(). Patch 5 contains the bulk of the implementation for device exclusive memory. Patch 6 contains some additions to the HMM selftests to ensure everything works as expected and has not changed significantly since v3. Patch 7 was posted previously and has not changed. Patch 8 was posted for v3 and has been updated to safely program the GPU page tables. This has been tested using the latest upstream Mesa userspace with a simple OpenCL test program which checks the results of atomic GPU operations on a SVM buffer whilst also writing to the same buffer from the CPU. v4: * Added pfn_swap_entry_to_page() and reinstated the migration entry page lock check. * Added check_device_exclusive_range() for use during mmu range notifier read side critical section when programming device page tables. v3: * Refactored some existing functionality. * Switched to using get_user_pages_remote() instead of open-coding it. * Moved code out of hmm. v2: * Changed implementation to use special swap entries instead of device private pages. Alistair Popple (8): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 15 + arch/s390/mm/pgtable.c| 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 135 +++- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 + fs/proc/task_mmu.c| 23 +- include/linux/rmap.h | 10 +- include/linux/swap.h | 8 +- include/linux/swapops.h | 123 ++-- lib/test_hmm.c| 124 lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 40 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 127 +++- mm/migrate.c | 41 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 618 +++--- tools/testing/selftests/vm/hmm-tests.c| 219 +++ 23 files changed, 1310 insertions(+), 254 deletions(-) -- 2.20.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/8] mm: Device exclusive memory access
On Tuesday, 2 March 2021 11:41:52 PM AEDT Jason Gunthorpe wrote: > > However try_to_protect() scans the PTEs again under the PTL so checking the > > mapping of interest actually gets replaced during the rmap walk seems like a > > reasonable solution. Thanks for the comments. > > It does seem cleaner if you can manage it, the notifier will still be > needd to program the HW though Checking during the rmap walk wasn't hard but ultimately pointless. As you say a range notifier and lock is required to program the hardware, which requires checking the mappings with a mmu notifier sequence anyway. - Alistair ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
On Tuesday, 2 March 2021 3:10:49 AM AEDT Jason Gunthorpe wrote:
> > + while (page_vma_mapped_walk(&pvmw)) {
> > + /*
> > +* If the page is mlock()d, we cannot swap it out.
> > +* If it's recently referenced (perhaps page_referenced
> > +* skipped over this mm) then we should reactivate it.
> > +*/
> > + if (vma->vm_flags & VM_LOCKED) {
>
> And since we write the data without holding the PTLs this looks
> pointless, unless there is some other VM_LOCKED manipulation
>
Thanks. I couldn't find any other manipulation of VM_LOCKED whilst holding the
PTL so I'll remove this redundant check.
- Alistair
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Request for information and/or assistance
Greetings Running debian testing, 2 nvidia gpus (GP107 and GF110) and 5 monitors (1 - 3840x2160 and 2 1920x1080 on the GP107 and 2 - 1920x1080 on the GF110) using one screen (7680x3000). I would still like to modify some things but can't find any docs on how to do that and my attempts have only made things worse and I can function, even though some things are right awkward, on the system. What I've run into is that my graphics system either refuses to come out of hibernation or decides to come back on but in a locked state. I then log into this machine from another on the network and do a reboot for a 'graceful' restart (rather than use the kill button - - - the hard shut off). This event, graphics shutdown, is happening in direct relationship to how much I have happening on the desktops of which I have lots. In searching it seems that nouveau support for the GP107 is not yet complete - - - - or that's what it seems like. Is there someone out there who has some idea what the problem is? (There are quite a number of different individuals mentioning this issue in one of the bug reports.) I would be happen to revise the nouveau pages on xrandr updating the information from 1.3 to 1.5 and possibly some of the other pages as well. I have no programming skills but I do have reasonable writing skills - - - - would rather trade than to continue taking that 1/2 hour it takes to set my system up after each reboot - - - - taking an hour or even 1.5 hours a day doing this is a huge drain on my resources and would rather change this. Please advise! Regards Aj ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
On Wed, 2021-03-03 at 18:02 +0100, Uwe Sauter wrote: > Am 03.03.21 um 14:33 schrieb Ilia Mirkin: > > On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter wrote: > > > > > > Am 03.03.21 um 14:12 schrieb Ilia Mirkin: > > > > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen > > > > wrote: > > > > > > > > > > Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: > > > > > > Can you try Alex's patch to modetest and confirm that you see issues > > > > > > with modetest? If so, can you (and maybe Alex as well) try an older > > > > > > kernel (I'm on 5.6) and see if modetest behaves well there. [The > > > > > > patch > > > > > > in question was to expose 256x256 as the 'preferred' size, but > > > > > > support > > > > > > for the larger cursors has been around for a while.] Alex - if you > > > > > > have time, same question to you. > > > > > > > > > > Sorry that it took so long. I retestet with the same kernel as Uwe did > > > > > (5.4.101) and my results are the same: modetest with 64 and 128 > > > > > cursors looks > > > > > good, 256 broken. Didn't test with X this time (this being my main > > > > > office > > > > > machine), but can do later if required. > > > > > > > > Thanks for confirming! No need to test X - that will work fine, since > > > > we were reporting the smaller cursors on that kernel. > > > > > > > > So I think we have definitive evidence that at least all Kepler > > > > doesn't do 256x256 (and it's not just some bug in the display macro > > > > rework that got introduced). And unless I'm blind and don't see the > > > > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. > > > > Unless someone has immediate plans to test on those, I'd recommend > > > > bumping the minimum for 256x256 being reported to Pascal, and doing > > > > 128x128 for Kepler / Maxwell. > > > > > > The only older model I have access to would be a 6600GT (NV43). Don't know > > > if this would have any > > > significance… > > > > Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell > > 1, and GTX 9xx for Maxwell 2. (GM10x and GM20x). > > I managed to get access to two much newer cards, RTK 1070 and the like. > > Should I test these or is it not necessary? Nah, everything volta+ is a completely different ballgame. Anyway, I don't think we need more testing here anyhow, I just need to try what James Jones suggested and if that doesn't work, write up a patch to limit the cursor size until we figure out a proper solution for this. > > Regards, > > Uwe > > > > Cheers, > > > > -ilia > > > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
On 3/3/21 8:51 AM, Lyude Paul wrote: On Wed, 2021-03-03 at 08:12 -0500, Ilia Mirkin wrote: On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen wrote: Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: Can you try Alex's patch to modetest and confirm that you see issues with modetest? If so, can you (and maybe Alex as well) try an older kernel (I'm on 5.6) and see if modetest behaves well there. [The patch in question was to expose 256x256 as the 'preferred' size, but support for the larger cursors has been around for a while.] Alex - if you have time, same question to you. Sorry that it took so long. I retestet with the same kernel as Uwe did (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks good, 256 broken. Didn't test with X this time (this being my main office machine), but can do later if required. Thanks for confirming! No need to test X - that will work fine, since we were reporting the smaller cursors on that kernel. So I think we have definitive evidence that at least all Kepler doesn't do 256x256 (and it's not just some bug in the display macro rework that got introduced). And unless I'm blind and don't see the corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. Unless someone has immediate plans to test on those, I'd recommend bumping the minimum for 256x256 being reported to Pascal, and doing 128x128 for Kepler / Maxwell. I'm fairly sure this will actually work fine on maxwell, I think Kepler is the only one I'm aware of so far that has issues with this. I've got one of each gen from kepler 1 up to ampere, so I'll try to find some today to test the cards I've got and see where the support cutoff for this is and then submit a patch for the time being. It's also really strange to me that this would be present in the display classes yet not be supported on the GPU, since there definitely aren't any capabilities for this. I'll also send an email to Andy and see if he might know what's going on here. FWIW, it's not my area, but I've been following, and forwarded this thread around internally. We discussed a bit, and Kepler definitely supports 256x256 cursors. One suggestion was if you aren't already, try using 4k pages. The rest was a bit beyond me, so I'll let Andy and Lyude discuss further if needed. Thanks, -James Simon, Lyude -- thoughts? Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
Am 03.03.21 um 14:33 schrieb Ilia Mirkin: > On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter wrote: >> >> Am 03.03.21 um 14:12 schrieb Ilia Mirkin: >>> On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen >>> wrote: Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: > Can you try Alex's patch to modetest and confirm that you see issues > with modetest? If so, can you (and maybe Alex as well) try an older > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch > in question was to expose 256x256 as the 'preferred' size, but support > for the larger cursors has been around for a while.] Alex - if you > have time, same question to you. Sorry that it took so long. I retestet with the same kernel as Uwe did (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks good, 256 broken. Didn't test with X this time (this being my main office machine), but can do later if required. >>> >>> Thanks for confirming! No need to test X - that will work fine, since >>> we were reporting the smaller cursors on that kernel. >>> >>> So I think we have definitive evidence that at least all Kepler >>> doesn't do 256x256 (and it's not just some bug in the display macro >>> rework that got introduced). And unless I'm blind and don't see the >>> corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. >>> Unless someone has immediate plans to test on those, I'd recommend >>> bumping the minimum for 256x256 being reported to Pascal, and doing >>> 128x128 for Kepler / Maxwell. >> >> The only older model I have access to would be a 6600GT (NV43). Don't know >> if this would have any >> significance… > > Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell > 1, and GTX 9xx for Maxwell 2. (GM10x and GM20x). I managed to get access to two much newer cards, RTK 1070 and the like. Should I test these or is it not necessary? Regards, Uwe > Cheers, > > -ilia > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 17/53] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static
Reviewed-by: Lyude Paul
Thanks!
On Wed, 2021-03-03 at 13:42 +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Lyude Paul
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> index fd51527b56b83..bdcfd240d61c8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> @@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size,
> void __iomem *mem)
> writew(readw(mem - 4), mem + 4);
> }
>
> -bool
> +static bool
> headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
> {
> if (size != 0 && size != 256 && size != 1024)
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
On Wed, 2021-03-03 at 08:12 -0500, Ilia Mirkin wrote: > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen > wrote: > > > > Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: > > > Can you try Alex's patch to modetest and confirm that you see issues > > > with modetest? If so, can you (and maybe Alex as well) try an older > > > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch > > > in question was to expose 256x256 as the 'preferred' size, but support > > > for the larger cursors has been around for a while.] Alex - if you > > > have time, same question to you. > > > > Sorry that it took so long. I retestet with the same kernel as Uwe did > > (5.4.101) and my results are the same: modetest with 64 and 128 cursors > > looks > > good, 256 broken. Didn't test with X this time (this being my main office > > machine), but can do later if required. > > Thanks for confirming! No need to test X - that will work fine, since > we were reporting the smaller cursors on that kernel. > > So I think we have definitive evidence that at least all Kepler > doesn't do 256x256 (and it's not just some bug in the display macro > rework that got introduced). And unless I'm blind and don't see the > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. > Unless someone has immediate plans to test on those, I'd recommend > bumping the minimum for 256x256 being reported to Pascal, and doing > 128x128 for Kepler / Maxwell. I'm fairly sure this will actually work fine on maxwell, I think Kepler is the only one I'm aware of so far that has issues with this. I've got one of each gen from kepler 1 up to ampere, so I'll try to find some today to test the cards I've got and see where the support cutoff for this is and then submit a patch for the time being. It's also really strange to me that this would be present in the display classes yet not be supported on the GPU, since there definitely aren't any capabilities for this. I'll also send an email to Andy and see if he might know what's going on here. > > Simon, Lyude -- thoughts? > > Cheers, > > -ilia > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] How to reverse engineer a PCI-Express driver under Linux ?
On 3 Mar 2021, at 14:09, Ilia Mirkin wrote: > On Wed, Mar 3, 2021 at 5:30 AM Karol Herbst wrote: >> >> >> Usually drivers map PCIe bars into the VM and read/write at certain offsets >> to do.. stuff. In the linux kernel we have the mmiotrace tracer in order to >> capture what a driver does with the hardware. You still need to interpret >> the trace file, but at least this should give you the raw data on what's >> going on. Hope that helps. > > Here's a good guide on how to use mmiotrace. It's nvidia-focused, but > the same steps would apply to any driver: > https://wiki.ubuntu.com/X/MMIOTracing > > Basically, start mmiotrace, load target driver, do some stuff, stop > mmiotrace, analyze the resulting trace. > > We have some tooling to help with that -- envytools/rnn/demmio will > parse the mmiotrace against a given rnndb (also in envytools). You > won't be able to reuse our rnndb, but you'd be able to build up your > own. You also wouldn't be able to use demmio directly, but you could > see how it works and modify it to your hw's needs. (e.g. it waits for > a read of the "0" mmio reg to determine which chip is being traced, > and loads up the appropriate rnndb settings - that won't work with > your hw out of the box.) > Thank you to both of you for the very useful tips and the link to this tutorial. This was exactly what I was looking for. >>> Also, the long term goal of this project would be to have this driver >>> merged into mainline, so what is allowed or not while doing this to avoid >>> problematic legal ramifications ? > > This isn't legal advice (for that, consult a lawyer), however a few > things that are definitely going to get you into trouble: > > - stealing (or using stolen) documentation > - de-compiling target driver and copying its implementation (as that > would be subject to copyright) Yes, I’m not using anything stolen (all the resources I have are publicly available on the card producer’s website). I’ve also contacted local open-source NGOs about the legal questions, I live in France and the law here is quite different to the US for those kind of things. Regards. Tomek ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 18/53] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions
Fixes the following build error: drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for ‘nv50_display_fini’ In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71: drivers/gpu/drm/nouveau/nv50_display.h:36:6: note: previous declaration of ‘nv50_display_fini’ was her In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71: drivers/gpu/drm/nouveau/nv50_display.h:35:6: note: previous declaration of ‘nv50_display_init’ was here drivers/gpu/drm/nouveau/dispnv50/disp.c:2581:1: error: static declaration of ‘nv50_display_destroy’ follows non-static declaration In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71: drivers/gpu/drm/nouveau/nv50_display.h:34:6: note: previous declaration of ‘nv50_display_destroy’ was here Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nv50_display.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.h b/drivers/gpu/drm/nouveau/nv50_display.h index fbd3b15583bc8..2421401d12636 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.h +++ b/drivers/gpu/drm/nouveau/nv50_display.h @@ -31,7 +31,4 @@ #include "nouveau_reg.h" int nv50_display_create(struct drm_device *); -void nv50_display_destroy(struct drm_device *); -int nv50_display_init(struct drm_device *); -void nv50_display_fini(struct drm_device *); #endif /* __NV50_DISPLAY_H__ */ -- 2.27.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 14/53] drm/nouveau/nouveau_display: Remove set but unused variable 'width'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_display.c: In function
‘nouveau_framebuffer_new’:
drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable ‘width’
set but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 17831ee897ea4..0849f367631a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -306,7 +306,7 @@ nouveau_framebuffer_new(struct drm_device *dev,
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct drm_framebuffer *fb;
const struct drm_format_info *info;
- unsigned int width, height, i;
+ unsigned int height, i;
uint32_t tile_mode;
uint8_t kind;
int ret;
@@ -346,9 +346,9 @@ nouveau_framebuffer_new(struct drm_device *dev,
info = drm_get_format_info(dev, mode_cmd);
for (i = 0; i < info->num_planes; i++) {
- width = drm_format_info_plane_width(info,
- mode_cmd->width,
- i);
+ drm_format_info_plane_width(info,
+ mode_cmd->width,
+ i);
height = drm_format_info_plane_height(info,
mode_cmd->height,
i);
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 16/53] drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c51efca82ac78..828f48d5bdd4e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1386,12 +1386,11 @@ nv50_mstm_cleanup(struct nv50_mstm *mstm)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm cleanup\n", mstm->outp->base.base.name);
- ret = drm_dp_check_act_status(&mstm->mgr);
+ drm_dp_check_act_status(&mstm->mgr);
- ret = drm_dp_update_payload_part2(&mstm->mgr);
+ drm_dp_update_payload_part2(&mstm->mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 20/53] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file mga_ioc32.c Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c b/drivers/gpu/drm/nouveau/nouveau_ioc32.c index adf01ca9e035d..8ddf9b2325a42 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c @@ -1,4 +1,4 @@ -/** +/* * \file mga_ioc32.c * * 32-bit ioctl compatibility routines for the MGA DRM. -- 2.27.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 22/53] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or member 'filp' not described in 'nouveau_compat_ioctl' drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or member 'cmd' not described in 'nouveau_compat_ioctl' drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or member 'arg' not described in 'nouveau_compat_ioctl' Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c b/drivers/gpu/drm/nouveau/nouveau_ioc32.c index 8ddf9b2325a42..2af3615c5205c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c @@ -38,7 +38,7 @@ #include "nouveau_ioctl.h" -/** +/* * Called whenever a 32-bit process running under a 64-bit kernel * performs an ioctl on /dev/dri/card. * -- 2.27.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 13/53] drm/nouveau/nouveau_bo: Remove unused variables 'dev'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_unpopulate’:
drivers/gpu/drm/nouveau/nouveau_bo.c:1252:17: warning: variable ‘dev’ set but
not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Jeremy Kolb
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2375711877cf3..0b94f8ae77291 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1251,7 +1251,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
{
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (ttm_tt_is_populated(ttm))
@@ -1264,7 +1263,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
}
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_alloc(&drm->ttm.bdev.pool, ttm, ctx);
}
@@ -1274,14 +1272,12 @@ nouveau_ttm_tt_unpopulate(struct ttm_bo_device *bdev,
struct ttm_tt *ttm)
{
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (slave)
return;
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_free(&drm->ttm.bdev.pool, ttm);
}
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 17/53] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lyude Paul
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index fd51527b56b83..bdcfd240d61c8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size, void
__iomem *mem)
writew(readw(mem - 4), mem + 4);
}
-bool
+static bool
headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
{
if (size != 0 && size != 256 && size != 1024)
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 15/53] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or member 'crtc' not described in 'nv_crtc_mode_set_regs' drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or member 'mode' not described in 'nv_crtc_mode_set_regs' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'crtc' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'mode' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'adjusted_mode' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'x' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'y' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'old_fb' not described in 'nv_crtc_mode_set' Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index f9e962fd94d0d..f9a276ea5a9e0 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct drm_display_mode *mode) regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00; } -/** +/* * Sets up registers for the given mode/adjusted_mode pair. * * The clocks, CRTCs and outputs attached to this CRTC must be off. @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct drm_framebuffer *old_fb) return ret; } -/** +/* * Sets up registers for the given mode/adjusted_mode pair. * * The clocks, CRTCs and outputs attached to this CRTC must be off. -- 2.27.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 21/53] drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 1c3f890377d2c..26af6ee915368 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -811,7 +811,6 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
unsigned long addr, u64 *pfns, unsigned long npages)
{
struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
- int ret;
args->p.addr = addr;
args->p.size = npages << PAGE_SHIFT;
@@ -819,8 +818,8 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
mutex_lock(&svmm->mutex);
svmm->vmm->vmm.object.client->super = true;
- ret = nvif_object_ioctl(&svmm->vmm->vmm.object, args, sizeof(*args) +
- npages * sizeof(args->p.phys[0]), NULL);
+ nvif_object_ioctl(&svmm->vmm->vmm.object, args, sizeof(*args) +
+ npages * sizeof(args->p.phys[0]), NULL);
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(&svmm->mutex);
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 19/53] drm/nouveau/dispnv50/disp: Include header containing our prototypes
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous prototype for ‘nv50_display_create’ [-Wmissing-prototypes] Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 828f48d5bdd4e..cd16431422198 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -68,6 +68,8 @@ #include +#include "nv50_display.h" + /** * EVO channel */ -- 2.27.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 02/53] drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 196612addfd61..c51efca82ac78 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1410,10 +1410,9 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm prepare\n", mstm->outp->base.base.name);
- ret = drm_dp_update_payload_part1(&mstm->mgr);
+ drm_dp_update_payload_part1(&mstm->mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 12/53] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function parameter or member 'gr' not described in 'gf100_gr_wait_idle' Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c index 397ff4fe9df89..69e6008f99196 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c @@ -982,7 +982,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr) } } -/** +/* * Wait until GR goes idle. GR is considered idle if it is disabled by the * MC (0x200) register, or GR is not busy and a context switch is not in * progress. -- 2.27.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 06/53] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 'coef' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 'temp' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 't_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 'coef' not described in 'gk20a_volt_get_cvb_t_voltage'
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
index 8c2faa9645111..ccac88da88648 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
@@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
/* 852 */ { 1608418, -21643, -269, 0,763, -48},
};
-/**
+/*
* cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
*/
static inline int
@@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const
struct cvb_coef *coef)
return mv;
}
-/**
+/*
* cvb_t_mv =
* ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
* ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [RESEND 00/53] Rid GPU from W=1 warnings
This is a resend. All of these patches have been sent before.
The vmwgfx ones were even applied, but were dropped for some reason.
Lee Jones (53):
drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
drm/msm/dp/dp_display: Remove unused variable 'hpd'
drm/amd/display/dc/bios/command_table: Remove unused variable
include: drm: drm_atomic: Make use of 'new_plane_state'
drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc
headers
drm/amd/display/dc/bios/command_table: Remove unused variable and
associated comment
drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the
stack to the heap
drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from
the stack
drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field
overwritten' issue
drm/amd/display/dc/dce80/dce80_resource: Make local functions static
drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc
header
drm/nouveau/nouveau_bo: Remove unused variables 'dev'
drm/nouveau/nouveau_display: Remove set but unused variable 'width'
drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers
drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function
returning void
drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut'
static
drm/nouveau/nv50_display: Remove superfluous prototype for local
static functions
drm/nouveau/dispnv50/disp: Include header containing our prototypes
drm/nouveau/nouveau_ioc32: File headers are not good candidates for
kernel-doc
drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void
function
drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment
block
drm/vmwgfx/vmwgfx_execbuf: Fix some kernel-doc related issues
drm/vmwgfx/vmwgfx_kms: Remove unused variable 'ret' from
'vmw_du_primary_plane_atomic_check()'
drm/vmwgfx/vmwgfx_kms: Mark vmw_{cursor,primary}_plane_formats as
__maybe_unused
drm/vmwgfx/vmwgfx_drv: Fix some kernel-doc misdemeanours
drm/vmwgfx/vmwgfx_ioctl: Provide missing '@' sign required by
kernel-doc
drm/vmwgfx/vmwgfx_resource: Fix worthy function headers demote some
others
drm/vmwgfx/vmwgfx_ttm_buffer: Supply some missing parameter
descriptions
drm/vmwgfx/vmwgfx_fifo: Demote non-conformant kernel-doc header
drm/vmwgfx/vmwgfx_ldu: Supply descriptions for 'state' function
parameter
drm/vmwgfx/vmwgfx_kms: Update worthy function headers and demote
others
drm/vmwgfx/vmwgfx_overlay: Demote kernel-doc abuses to standard
comment blocks
drm/vmwgfx/vmwgfx_fence: Add, remove and demote various documentation
params/headers
drm/vmwgfx/vmwgfx_bo: Remove superfluous param description and supply
another
drm/vmwgfx/vmwgfx_context: Demote kernel-doc abuses
drm/vmwgfx/vmwgfx_scrn: Demote unworthy kernel-doc headers and update
others
drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues
drm/vmwgfx/vmwgfx_cmdbuf_res: Rename param description and remove
another
drm/vmwgfx/vmwgfx_shader: Demote kernel-doc abuses and fix-up worthy
headers
drm/vmwgfx/vmwgfx_cmdbuf: Fix a bunch of missing or incorrectly
formatted/named params
drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret'
drm/vmwgfx/vmwgfx_stdu: Add some missing param/member descriptions
drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should be plural
drm/vmwgfx/vmwgfx_cotable: Fix a couple of simple documentation
problems
drm/vmwgfx/vmwgfx_so: Add description for 'vmw_view's 'rcu' member
drm/vmwgfx/vmwgfx_binding: Provide some missing param descriptions and
remove others
drm/vmwgfx/vmwgfx_msg: Fix misspelling of 'msg'
drm/vmwgfx/vmwgfx_blit: Add description for 'vmw_bo_cpu_blit's 'diff'
param
drm/vmwgfx/vmwgfx_validation: Add some missing struct member/function
param descriptions
drm/vmwgfx/ttm_object: Demote half-assed headers and fix-up another
drm/vmwgfx/vmwgfx_thp: Add description for 'vmw_thp_manager's member
'manager'
drm/vmwgfx/ttm_object: Reorder header to immediately precede its
struct
.../drm/amd/display/dc/bios/command_table.c | 16 +-
.../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 1151 +
drivers/gpu/drm/amd/display/dc/dce/dce_aux.h |1 -
.../drm/amd/display/dc/dce80/dce80_resource.c | 16 +-
drivers/gpu/drm/msm/dp/dp_display.c |3 -
drivers/gpu/drm/nouveau/dispnv04/crtc.c |4 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 10 +-
drivers/gpu/drm/nouveau/dispnv50/headc57d.c |2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |4 -
drivers/gpu/drm/nouveau/nouveau_display.c |8 +-
drivers/gpu/drm/nouveau/nouveau_ioc32.c |4 +-
drivers/gpu/drm/nouveau/nouveau_svm.c |5 +-
drivers/gpu/drm/nouveau/nv50_display.h|3 -
.../gpu/drm/nouveau/nvkm/e
[Nouveau] [PATCH 01/53] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
parameter or member 'init' not described in 'init_reserved'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function
parameter or member 'init' not described in 'init_done'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function
parameter or member 'init' not described in 'init_io_restrict_prog'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function
parameter or member 'init' not described in 'init_repeat'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function
parameter or member 'init' not described in 'init_io_restrict_pll'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function
parameter or member 'init' not described in 'init_end_repeat'
NB: Trimmed for brevity (lots of these!)
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 204 ++
1 file changed, 68 insertions(+), 136 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2a..5a91dc4e5c8ec 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -575,9 +575,8 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
* init opcode handlers
*/
-/**
+/*
* init_reserved - stub for various unknown/unused single-byte opcodes
- *
*/
static void
init_reserved(struct nvbios_init *init)
@@ -602,9 +601,8 @@ init_reserved(struct nvbios_init *init)
init->offset += length;
}
-/**
+/*
* INIT_DONE - opcode 0x71
- *
*/
static void
init_done(struct nvbios_init *init)
@@ -613,9 +611,8 @@ init_done(struct nvbios_init *init)
init->offset = 0x;
}
-/**
+/*
* INIT_IO_RESTRICT_PROG - opcode 0x32
- *
*/
static void
init_io_restrict_prog(struct nvbios_init *init)
@@ -650,9 +647,8 @@ init_io_restrict_prog(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_REPEAT - opcode 0x33
- *
*/
static void
init_repeat(struct nvbios_init *init)
@@ -676,9 +672,8 @@ init_repeat(struct nvbios_init *init)
init->repeat = repeat;
}
-/**
+/*
* INIT_IO_RESTRICT_PLL - opcode 0x34
- *
*/
static void
init_io_restrict_pll(struct nvbios_init *init)
@@ -716,9 +711,8 @@ init_io_restrict_pll(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_END_REPEAT - opcode 0x36
- *
*/
static void
init_end_repeat(struct nvbios_init *init)
@@ -732,9 +726,8 @@ init_end_repeat(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_COPY - opcode 0x37
- *
*/
static void
init_copy(struct nvbios_init *init)
@@ -759,9 +752,8 @@ init_copy(struct nvbios_init *init)
init_wrvgai(init, port, index, data);
}
-/**
+/*
* INIT_NOT - opcode 0x38
- *
*/
static void
init_not(struct nvbios_init *init)
@@ -771,9 +763,8 @@ init_not(struct nvbios_init *init)
init_exec_inv(init);
}
-/**
+/*
* INIT_IO_FLAG_CONDITION - opcode 0x39
- *
*/
static void
init_io_flag_condition(struct nvbios_init *init)
@@ -788,9 +779,8 @@ init_io_flag_condition(struct nvbios_init *init)
init_exec_set(init, false);
}
-/**
+/*
* INIT_GENERIC_CONDITION - opcode 0x3a
- *
*/
static void
init_generic_condition(struct nvbios_init *init)
@@ -840,9 +830,8 @@ init_generic_condition(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_MASK_OR - opcode 0x3b
- *
*/
static void
init_io_mask_or(struct nvbios_init *init)
@@ -859,9 +848,8 @@ init_io_mask_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
}
-/**
+/*
* INIT_IO_OR - opcode 0x3c
- *
*/
static void
init_io_or(struct nvbios_init *init)
@@ -878,9 +866,8 @@ init_io_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data | (1 << or));
}
-/**
+/*
* INIT_ANDN_REG - opcode 0x47
- *
*/
static void
init_andn_reg(struct nvbios_init *init)
@@ -895,9 +882,8 @@ init_andn_reg(struct nvbios_init *init)
init_mask(init, reg, mask, 0);
}
-/**
+/*
* INIT_OR_REG - opcode 0x48
- *
*/
static void
init_or_reg(struct nvbios_init *init)
@@ -912,9 +898,8 @@ init_or_reg(struct nvbios_init *init)
init_mask(init, reg, 0, mask);
}
-/**
+/*
* INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
- *
*/
static void
init_idx_addr_latched(struct nvbios_init *init)
@@ -942,9 +927,8 @@ init_idx_addr_latched(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_RESTRICT_PLL2 - opcode 0x4a
- *
*/
static void
init_io_restrict_pll2(struct nvbios_init *init)
@@ -977,9 +961,8 @@ init_io_restrict_pll2(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_PL
[Nouveau] [PATCH] drm/nouveau/pmu: Use %p4cc printk modifier to print FourCC codes
Now that we can print FourCC codes directly using printk, make use of the feature in nouveau. Signed-off-by: Tian Tao --- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gt215.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gt215.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gt215.c index 88b9099..711a8fe 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gt215.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gt215.c @@ -127,11 +127,8 @@ gt215_pmu_recv(struct nvkm_pmu *pmu) /* right now there's no other expected responses from the engine, * so assume that any unexpected message is an error. */ - nvkm_warn(subdev, "%c%c%c%c %08x %08x %08x %08x\n", - (char)((process & 0x00ff) >> 0), - (char)((process & 0xff00) >> 8), - (char)((process & 0x00ff) >> 16), - (char)((process & 0xff00) >> 24), + nvkm_warn(subdev, "%p4cc %08x %08x %08x %08x\n", + &process, process, message, data0, data1); } -- 2.7.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter wrote: > > Am 03.03.21 um 14:12 schrieb Ilia Mirkin: > > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen > > wrote: > >> > >> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: > >>> Can you try Alex's patch to modetest and confirm that you see issues > >>> with modetest? If so, can you (and maybe Alex as well) try an older > >>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch > >>> in question was to expose 256x256 as the 'preferred' size, but support > >>> for the larger cursors has been around for a while.] Alex - if you > >>> have time, same question to you. > >> > >> Sorry that it took so long. I retestet with the same kernel as Uwe did > >> (5.4.101) and my results are the same: modetest with 64 and 128 cursors > >> looks > >> good, 256 broken. Didn't test with X this time (this being my main office > >> machine), but can do later if required. > > > > Thanks for confirming! No need to test X - that will work fine, since > > we were reporting the smaller cursors on that kernel. > > > > So I think we have definitive evidence that at least all Kepler > > doesn't do 256x256 (and it's not just some bug in the display macro > > rework that got introduced). And unless I'm blind and don't see the > > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. > > Unless someone has immediate plans to test on those, I'd recommend > > bumping the minimum for 256x256 being reported to Pascal, and doing > > 128x128 for Kepler / Maxwell. > > The only older model I have access to would be a 6600GT (NV43). Don't know if > this would have any > significance… Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell 1, and GTX 9xx for Maxwell 2. (GM10x and GM20x). Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
Am 03.03.21 um 14:12 schrieb Ilia Mirkin: > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen > wrote: >> >> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: >>> Can you try Alex's patch to modetest and confirm that you see issues >>> with modetest? If so, can you (and maybe Alex as well) try an older >>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch >>> in question was to expose 256x256 as the 'preferred' size, but support >>> for the larger cursors has been around for a while.] Alex - if you >>> have time, same question to you. >> >> Sorry that it took so long. I retestet with the same kernel as Uwe did >> (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks >> good, 256 broken. Didn't test with X this time (this being my main office >> machine), but can do later if required. > > Thanks for confirming! No need to test X - that will work fine, since > we were reporting the smaller cursors on that kernel. > > So I think we have definitive evidence that at least all Kepler > doesn't do 256x256 (and it's not just some bug in the display macro > rework that got introduced). And unless I'm blind and don't see the > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. > Unless someone has immediate plans to test on those, I'd recommend > bumping the minimum for 256x256 being reported to Pascal, and doing > 128x128 for Kepler / Maxwell. The only older model I have access to would be a 6600GT (NV43). Don't know if this would have any significance… Uwe > Simon, Lyude -- thoughts? > > Cheers, > > -ilia > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen wrote: > > Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: > > Can you try Alex's patch to modetest and confirm that you see issues > > with modetest? If so, can you (and maybe Alex as well) try an older > > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch > > in question was to expose 256x256 as the 'preferred' size, but support > > for the larger cursors has been around for a while.] Alex - if you > > have time, same question to you. > > Sorry that it took so long. I retestet with the same kernel as Uwe did > (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks > good, 256 broken. Didn't test with X this time (this being my main office > machine), but can do later if required. Thanks for confirming! No need to test X - that will work fine, since we were reporting the smaller cursors on that kernel. So I think we have definitive evidence that at least all Kepler doesn't do 256x256 (and it's not just some bug in the display macro rework that got introduced). And unless I'm blind and don't see the corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs. Unless someone has immediate plans to test on those, I'd recommend bumping the minimum for 256x256 being reported to Pascal, and doing 128x128 for Kepler / Maxwell. Simon, Lyude -- thoughts? Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] How to reverse engineer a PCI-Express driver under Linux ?
On Wed, Mar 3, 2021 at 5:30 AM Karol Herbst wrote: > > > > On Wed, Mar 3, 2021 at 11:07 AM Tomek LECOCQ wrote: >> >> Hello, >> >> I’ve already asked this on the Kernel Newbies mail list, but as developing >> nouveau seems to be kind of similar to what I want to achieve, I thought it >> would be a good idea to ask it here as well. >> >> I have a PCI-Express video capture card that has a proprietary driver for >> Linux. >> I have some experience with programming in C, and so I would like to start a >> hobby project to develop a free/libre driver for this device for Linux. >> Of course I don’t have access to any documentation about how to communicate >> with this device (I’ve tried to contact the company making these, but my >> hopes are not high), so I think I will need to reverse-engineer the way the >> existing driver communicates with the hardware. How could I achieve this ? >> > > Usually drivers map PCIe bars into the VM and read/write at certain offsets > to do.. stuff. In the linux kernel we have the mmiotrace tracer in order to > capture what a driver does with the hardware. You still need to interpret the > trace file, but at least this should give you the raw data on what's going > on. Hope that helps. Here's a good guide on how to use mmiotrace. It's nvidia-focused, but the same steps would apply to any driver: https://wiki.ubuntu.com/X/MMIOTracing Basically, start mmiotrace, load target driver, do some stuff, stop mmiotrace, analyze the resulting trace. We have some tooling to help with that -- envytools/rnn/demmio will parse the mmiotrace against a given rnndb (also in envytools). You won't be able to reuse our rnndb, but you'd be able to build up your own. You also wouldn't be able to use demmio directly, but you could see how it works and modify it to your hw's needs. (e.g. it waits for a read of the "0" mmio reg to determine which chip is being traced, and loads up the appropriate rnndb settings - that won't work with your hw out of the box.) >> Also, the long term goal of this project would be to have this driver merged >> into mainline, so what is allowed or not while doing this to avoid >> problematic legal ramifications ? This isn't legal advice (for that, consult a lawyer), however a few things that are definitely going to get you into trouble: - stealing (or using stolen) documentation - de-compiling target driver and copying its implementation (as that would be subject to copyright) A semi-common technique is to use a so-called "chinese firewall", e.g. one person/team de-compiles, writes documentation, and then a second person/team uses that documentation to implement a driver. That way no copying of copyright-able content occurs, and no one can claim that the implementer had access to the copyrighted materials and thus could copy without even trying to. But it all depends on the target company (and jurisdictions in question) -- if they're particularly litigious, they could sue you for breathing air -- doesn't matter that their case has no merit, you'd still be stuck defending yourself. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100: > Can you try Alex's patch to modetest and confirm that you see issues > with modetest? If so, can you (and maybe Alex as well) try an older > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch > in question was to expose 256x256 as the 'preferred' size, but support > for the larger cursors has been around for a while.] Alex - if you > have time, same question to you. Sorry that it took so long. I retestet with the same kernel as Uwe did (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks good, 256 broken. Didn't test with X this time (this being my main office machine), but can do later if required. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] How to reverse engineer a PCI-Express driver under Linux ?
On Wed, Mar 3, 2021 at 11:07 AM Tomek LECOCQ wrote: > Hello, > > I’ve already asked this on the Kernel Newbies mail list, but as developing > nouveau seems to be kind of similar to what I want to achieve, I thought it > would be a good idea to ask it here as well. > > I have a PCI-Express video capture card that has a proprietary driver for > Linux. > I have some experience with programming in C, and so I would like to start > a hobby project to develop a free/libre driver for this device for Linux. > Of course I don’t have access to any documentation about how to > communicate with this device (I’ve tried to contact the company making > these, but my hopes are not high), so I think I will need to > reverse-engineer the way the existing driver communicates with the > hardware. How could I achieve this ? > > Usually drivers map PCIe bars into the VM and read/write at certain offsets to do.. stuff. In the linux kernel we have the mmiotrace tracer in order to capture what a driver does with the hardware. You still need to interpret the trace file, but at least this should give you the raw data on what's going on. Hope that helps. > Also, the long term goal of this project would be to have this driver > merged into mainline, so what is allowed or not while doing this to avoid > problematic legal ramifications ? > Thank you for your help. > Best regards. > Tomek Lecocq > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] How to reverse engineer a PCI-Express driver under Linux ?
Hello, I’ve already asked this on the Kernel Newbies mail list, but as developing nouveau seems to be kind of similar to what I want to achieve, I thought it would be a good idea to ask it here as well. I have a PCI-Express video capture card that has a proprietary driver for Linux. I have some experience with programming in C, and so I would like to start a hobby project to develop a free/libre driver for this device for Linux. Of course I don’t have access to any documentation about how to communicate with this device (I’ve tried to contact the company making these, but my hopes are not high), so I think I will need to reverse-engineer the way the existing driver communicates with the hardware. How could I achieve this ? Also, the long term goal of this project would be to have this driver merged into mainline, so what is allowed or not while doing this to avoid problematic legal ramifications ? Thank you for your help. Best regards. Tomek Lecocq ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
