[Intel-gfx] ✓ Fi.CI.BAT: success for Simplify intel_setup_outputs
== Series Details == Series: Simplify intel_setup_outputs URL : https://patchwork.freedesktop.org/series/88988/ State : success == Summary == CI Bug Log - changes from CI_DRM_9962 -> Patchwork_19919 Summary --- **WARNING** Minor unknown changes coming with Patchwork_19919 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19919, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19919: ### IGT changes ### Warnings * igt@i915_selftest@live@gt_pm: - fi-tgl-y: [DMESG-FAIL][1] ([i915#1759]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/fi-tgl-y/igt@i915_selftest@live@gt_pm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-tgl-y/igt@i915_selftest@live@gt_pm.html Known issues Here are the changes found in Patchwork_19919 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#2283]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([i915#2782] / [i915#2940]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][8] ([i915#1436]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-bsw-nick/igt@run...@aborted.html Possible fixes * igt@kms_addfb_basic@basic-y-tiled-legacy: - fi-kbl-8809g: [SKIP][9] ([fdo#109271]) -> [PASS][10] +14 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/fi-kbl-8809g/igt@kms_addfb_ba...@basic-y-tiled-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-kbl-8809g/igt@kms_addfb_ba...@basic-y-tiled-legacy.html Warnings * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-8809g: [SKIP][11] ([fdo#109271]) -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-8809g: [SKIP][13] ([fdo#109271]) -> [SKIP][14] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (47 -> 41) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-bdw-samus Build changes - * Linux: CI_DRM_9962 -> Patchwork_19919 CI-20190529: 20190529 CI_DRM_9962: 2847b855cf291d61694ccfefa4f37d74d61f752b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6063: d3b7f74ce5df6fdea03e490b7c64f0c6bfe76f03 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19919: 085526fb72b5685ec5c45b7820978832d276ad7c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 085526fb72b5 drm/i915/display: remove strap checks f
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Extend GEN renames to the rest of the driver (rev3)
== Series Details == Series: drm/i915: Extend GEN renames to the rest of the driver (rev3) URL : https://patchwork.freedesktop.org/series/88825/ State : success == Summary == CI Bug Log - changes from CI_DRM_9962_full -> Patchwork_19918_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19918_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@flink: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] ([i915#2369]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-kbl2/igt@drm_import_exp...@flink.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-kbl2/igt@drm_import_exp...@flink.html * igt@gem_busy@close-race: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-skl5/igt@gem_b...@close-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-skl5/igt@gem_b...@close-race.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-snb6/igt@gem_ctx_persiste...@clone.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-kbl4/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-apl8/igt@gem_pr...@exhaustion.html * igt@gem_softpin@full: - shard-snb: NOTRUN -> [SKIP][16] ([fdo#109271]) +60 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-snb6/igt@gem_soft...@full.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-apl8/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-kbl: NOTRUN -> [DMESG-WARN][18] ([i915#3002]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-kbl7/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1699]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-apl8/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@gem_userptr_blits@process-exit-mmap@gtt: - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1699]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-kbl7/igt@gem_userptr_blits@process-exit-m...@gtt.html * igt@gem_userptr_blits@set-cache-level: - shard-iclb: NOTRUN -> [FAIL][21] ([i915#3324]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-iclb7/igt@gem_userptr_bl...@set-cache-level.html * igt@gen9_exec_parse@batch-zero-length: - shard-iclb: NOTRUN -> [SKIP][22] ([fdo#112306]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19918/shard-iclb7/igt@gen9_exec_pa...@batch-zero-length.html * igt@gen9_exec_
Re: [Intel-gfx] [PATCH 4/7] mm: Introduce verify_page_range()
On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +struct vpr_data {
> > + int (*fn)(pte_t pte, unsigned long addr, void *data);
> > + void *data;
> > +};
>
> Eeerg. This is likely to become an attack target itself. Stored function
> pointer with stored (3rd) argument.
>
> This doesn't seem needed: only DRM uses it, and that's for error
> reporting. I'd rather plumb back errors in a way to not have to add
> another place in the kernel where we do func+arg stored calling.
Is this any better? It does have the stored pointer, but not a stored
argument, assuming you don't count returns as arguments I suppose.
The alternative is refactoring apply_to_page_range() :-/
---
struct vpr_data {
bool (*fn)(pte_t pte, unsigned long addr);
unsigned long addr;
};
static int vpr_fn(pte_t *pte, unsigned long addr, void *data)
{
struct vpr_data *vpr = data;
if (!vpr->fn(*pte, addr)) {
vpr->addr = addr;
return -EINVAL;
}
return 0;
}
/**
* verify_page_range() - Scan (and fill) a range of virtual memory and validate
PTEs
* @mm: mm identifying the virtual memory map
* @addr: starting virtual address of the range
* @size: size of the range
* @fn: function that verifies the PTEs
*
* Scan a region of virtual memory, filling in page tables as necessary and
* calling a provided function on each leaf, providing a copy of the
* page-table-entry.
*
* Similar apply_to_page_range(), but does not provide direct access to the
* page-tables.
*
* NOTE! this function does not work correctly vs large pages.
*
* Return: the address that failed verification or 0 on success.
*/
unsigned long verify_page_range(struct mm_struct *mm,
unsigned long addr, unsigned long size,
bool (*fn)(pte_t pte, unsigned long addr))
{
struct vpr_data vpr = {
.fn = fn,
.addr = 0,
};
apply_to_page_range(mm, addr, size, vpr_fn, &vpr);
return vpr.addr;
}
EXPORT_SYMBOL_GPL(verify_page_range);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] Cross-driver ww transaction lock lists
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the LMEM/VRAM eviction we've ended up with
two static lists per transaction context; one typically unlocked at the
end of transaction and one initialized before and unlocked after each
buffer object validate. This enables us to do sleeping locking at
eviction and keep objects locked on the eviction list until we
eventually succeed allocating memory (modulo minor flaws of course).
It would be beneficial with the i915 TTM conversion to be able to
introduce a similar functionality that would work in ttm but also
cross-driver in, for example move_notify. It would also be beneficial
to be able to put any dma_resv ww mutex on the lists, and not require
it to be embedded in a particular object type.
I started scetching on some utilities for this. For TTM, for example,
the idea would be to pass a list head for the ww transaction lock list
in the ttm_operation_ctx. A function taking a ww_mutex could then
either attach a grabbed lock to the list for batch unlocking, or be
responsible for unlocking when the lock's scope is exited. It's also
possible to create sublists if so desired. I believe the below would be
sufficient to cover the i915 functionality.
Any comments and suggestions appreciated!
8<--
#ifndef _TRANSACTION_LOCKLIST_H_
#define _TRANSACTION_LOCKLIST_H_
struct trans_lockitem;
/**
* struct trans_locklist_ops - Ops structure for the ww locklist
functionality.
*
* Typically a const struct trans_locklist_ops is defined for each type
that
* embeds a struct trans_lockitem, or hav a struct trans_lockitem
pointing
* at it using the private pointer. It can be a buffer object,
reservation
* object, a single ww_mutex or even a sublist of trans_lockitems.
*/
struct trans_locklist_ops {
/**
* slow_lock: Slow lock to relax the transaction. Only used by
* a contending lock item.
* @item: The struct trans_lockitem to lock
* @intr: Whether to lock interruptible
*
* Return: -ERESTARTSYS: Hit a signal when relaxing,
* -EAGAIN, relaxing succesful, but the contending lock
* remains unlocked.
*/
int (*slow_lock) (struct trans_lockitem *item, bool intr);
/**
* unlock: Unlock.
* @item: The struct trans_lockitem to unlock.
*/
void (*unlock) (struct trans_lockitem *item);
/**
* unlock: Unlock.
* @item: The struct trans_lockitem to put. This function may
be NULL.
*/
void (*put) (struct trans_lockitem *item);
};
/**
* struct trans_lockitem
* @ops: Pointer to an Ops structure for this lockitem.
* @link: List link for the transaction locklist.
* @private: Private info.
* @relax_unlock: Unlock contending lock after relaxation since it is
* likely not needed after a transaction restart.
*
* A struct trans_lockitem typically represents a single lock, but is
* generic enough to represent a sublist of locks. It can either be
* embedded, or allocated on demand. A kmem_cache might be beneficial.
*/
struct trans_lockitem {
const struct trans_locklist_ops *ops;
struct list_head link;
u32 relax_unlock:1;
void *private;
};
/* unlock example */
static inline void trans_unlock_put_all(struct list_head *list)
{
struct trans_lockitem *lock, *next;
list_for_each_entry_safe(lock, next, typeof(*lock), link) {
lock->ops->unlock(lock);
list_del_init(&lock->link);
if (lock->ops_put)
lock->ops->put(lock);
}
}
/* Backoff example */
static inline int __must_check trans_backoff(struct list_head *list,
bool intr,
struct trans_lockitem
*contending)
{
int ret = 0;
trans_unlock_put_all(list);
if (contending) {
ret = contending->ops->slow_lock(contending, intr);
if (!ret && contending->relax_unlock)
contending->unlock(contending);
if (ret == -EAGAIN)
ret = 0;
contending->ops->put(contending);
}
return ret;
}
#endif _TRANSACTION_LOCKLIST_
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Cross-driver ww transaction lock lists
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the LMEM/VRAM eviction we've ended up with
two static lists per transaction context; one typically unlocked at the
end of transaction and one initialized before and unlocked after each
buffer object validate. This enables us to do sleeping locking at
eviction and keep objects locked on the eviction list until we
eventually succeed allocating memory (modulo minor flaws of course).
It would be beneficial with the i915 TTM conversion to be able to
introduce a similar functionality that would work in ttm but also
cross-driver in, for example move_notify. It would also be beneficial
to be able to put any dma_resv ww mutex on the lists, and not require
it to be embedded in a particular object type.
I started scetching on some utilities for this. For TTM, for example,
the idea would be to pass a list head for the ww transaction lock list
in the ttm_operation_ctx. A function taking a ww_mutex could then
either attach a grabbed lock to the list for batch unlocking, or be
responsible for unlocking when the lock's scope is exited. It's also
possible to create sublists if so desired. I believe the below would be
sufficient to cover the i915 functionality.
Any comments and suggestions appreciated!
ah yes Daniel and I haven been discussing something like this for years.
I also came up with rough implementation, but we always ran into
lifetime issues.
In other words the ww_mutexes which are on the list would need to be
kept alive until unlocked.
Because of this we kind of backed up and said we would need this on the
GEM level instead of working with dma_resv objects.
Regards,
Christian.
8<--
#ifndef _TRANSACTION_LOCKLIST_H_
#define _TRANSACTION_LOCKLIST_H_
struct trans_lockitem;
/**
* struct trans_locklist_ops - Ops structure for the ww locklist
functionality.
*
* Typically a const struct trans_locklist_ops is defined for each type
that
* embeds a struct trans_lockitem, or hav a struct trans_lockitem
pointing
* at it using the private pointer. It can be a buffer object,
reservation
* object, a single ww_mutex or even a sublist of trans_lockitems.
*/
struct trans_locklist_ops {
/**
* slow_lock: Slow lock to relax the transaction. Only used by
* a contending lock item.
* @item: The struct trans_lockitem to lock
* @intr: Whether to lock interruptible
*
* Return: -ERESTARTSYS: Hit a signal when relaxing,
* -EAGAIN, relaxing succesful, but the contending lock
* remains unlocked.
*/
int (*slow_lock) (struct trans_lockitem *item, bool intr);
/**
* unlock: Unlock.
* @item: The struct trans_lockitem to unlock.
*/
void (*unlock) (struct trans_lockitem *item);
/**
* unlock: Unlock.
* @item: The struct trans_lockitem to put. This function may
be NULL.
*/
void (*put) (struct trans_lockitem *item);
};
/**
* struct trans_lockitem
* @ops: Pointer to an Ops structure for this lockitem.
* @link: List link for the transaction locklist.
* @private: Private info.
* @relax_unlock: Unlock contending lock after relaxation since it is
* likely not needed after a transaction restart.
*
* A struct trans_lockitem typically represents a single lock, but is
* generic enough to represent a sublist of locks. It can either be
* embedded, or allocated on demand. A kmem_cache might be beneficial.
*/
struct trans_lockitem {
const struct trans_locklist_ops *ops;
struct list_head link;
u32 relax_unlock:1;
void *private;
};
/* unlock example */
static inline void trans_unlock_put_all(struct list_head *list)
{
struct trans_lockitem *lock, *next;
list_for_each_entry_safe(lock, next, typeof(*lock), link) {
lock->ops->unlock(lock);
list_del_init(&lock->link);
if (lock->ops_put)
lock->ops->put(lock);
}
}
/* Backoff example */
static inline int __must_check trans_backoff(struct list_head *list,
bool intr,
struct trans_lockitem
*contending)
{
int ret = 0;
trans_unlock_put_all(list);
if (contending) {
ret = contending->ops->slow_lock(contending, intr);
if (!ret && contending->relax_unlock)
contending->unlock(contending);
if (ret == -EAGAIN)
ret = 0;
contending->ops->put(contending);
}
return ret;
}
#endif _TRANSACTION_LOCKLIST_
Re: [Intel-gfx] [RFC] Cross-driver ww transaction lock lists
Hi,
On 4/13/21 9:57 AM, Christian König wrote:
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the LMEM/VRAM eviction we've ended up with
two static lists per transaction context; one typically unlocked at the
end of transaction and one initialized before and unlocked after each
buffer object validate. This enables us to do sleeping locking at
eviction and keep objects locked on the eviction list until we
eventually succeed allocating memory (modulo minor flaws of course).
It would be beneficial with the i915 TTM conversion to be able to
introduce a similar functionality that would work in ttm but also
cross-driver in, for example move_notify. It would also be beneficial
to be able to put any dma_resv ww mutex on the lists, and not require
it to be embedded in a particular object type.
I started scetching on some utilities for this. For TTM, for example,
the idea would be to pass a list head for the ww transaction lock list
in the ttm_operation_ctx. A function taking a ww_mutex could then
either attach a grabbed lock to the list for batch unlocking, or be
responsible for unlocking when the lock's scope is exited. It's also
possible to create sublists if so desired. I believe the below would be
sufficient to cover the i915 functionality.
Any comments and suggestions appreciated!
ah yes Daniel and I haven been discussing something like this for years.
I also came up with rough implementation, but we always ran into
lifetime issues.
In other words the ww_mutexes which are on the list would need to be
kept alive until unlocked.
Yes, the idea here is that the locker takes whatever reference needed to
put the lock on the list and keep it alive, and if that's not possible
for some reason, don't put the object on the list, but in the latter
case we need to solve the contended case. If needed I have a ww_mutex
api addition that does that...
Because of this we kind of backed up and said we would need this on
the GEM level instead of working with dma_resv objects.
And that's what the ops are for. The implementation doesn't care about
the underlying object. For TTM, we'd probably want to take a refcount on
the embedded GEM object.
/Thomas
Regards,
Christian.
8<--
#ifndef _TRANSACTION_LOCKLIST_H_
#define _TRANSACTION_LOCKLIST_H_
struct trans_lockitem;
/**
* struct trans_locklist_ops - Ops structure for the ww locklist
functionality.
*
* Typically a const struct trans_locklist_ops is defined for each type
that
* embeds a struct trans_lockitem, or hav a struct trans_lockitem
pointing
* at it using the private pointer. It can be a buffer object,
reservation
* object, a single ww_mutex or even a sublist of trans_lockitems.
*/
struct trans_locklist_ops {
/**
* slow_lock: Slow lock to relax the transaction. Only used by
* a contending lock item.
* @item: The struct trans_lockitem to lock
* @intr: Whether to lock interruptible
*
* Return: -ERESTARTSYS: Hit a signal when relaxing,
* -EAGAIN, relaxing succesful, but the contending lock
* remains unlocked.
*/
int (*slow_lock) (struct trans_lockitem *item, bool intr);
/**
* unlock: Unlock.
* @item: The struct trans_lockitem to unlock.
*/
void (*unlock) (struct trans_lockitem *item);
/**
* unlock: Unlock.
* @item: The struct trans_lockitem to put. This function may
be NULL.
*/
void (*put) (struct trans_lockitem *item);
};
/**
* struct trans_lockitem
* @ops: Pointer to an Ops structure for this lockitem.
* @link: List link for the transaction locklist.
* @private: Private info.
* @relax_unlock: Unlock contending lock after relaxation since it is
* likely not needed after a transaction restart.
*
* A struct trans_lockitem typically represents a single lock, but is
* generic enough to represent a sublist of locks. It can either be
* embedded, or allocated on demand. A kmem_cache might be beneficial.
*/
struct trans_lockitem {
const struct trans_locklist_ops *ops;
struct list_head link;
u32 relax_unlock:1;
void *private;
};
/* unlock example */
static inline void trans_unlock_put_all(struct list_head *list)
{
struct trans_lockitem *lock, *next;
list_for_each_entry_safe(lock, next, typeof(*lock), link) {
lock->ops->unlock(lock);
list_del_init(&lock->link);
if (lock->ops_put)
lock->ops->put(lock);
}
}
/* Backoff example */
static inline int __must_check trans_backoff(struct list_head *list,
bool intr,
struct trans_lockitem
*contending)
{
int ret = 0;
trans_unlock_put_all(list);
if (contending) {
ret = contending->
[Intel-gfx] ✗ Fi.CI.IGT: failure for Simplify intel_setup_outputs
== Series Details == Series: Simplify intel_setup_outputs URL : https://patchwork.freedesktop.org/series/88988/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9962_full -> Patchwork_19919_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19919_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19919_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19919_full: ### IGT changes ### Possible regressions * igt@kms_async_flips@async-flip-with-page-flip-events: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-skl4/igt@kms_async_fl...@async-flip-with-page-flip-events.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-skl6/igt@kms_async_fl...@async-flip-with-page-flip-events.html Known issues Here are the changes found in Patchwork_19919_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-kbl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][4] -> [DMESG-WARN][5] ([i915#180]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#146] / [i915#198]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-skl9/igt@gem_ctx_isolation@preservation...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-skl8/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-snb5/igt@gem_ctx_persiste...@clone.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271]) +259 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-snb5/igt@gem_ctx_sha...@q-in-order.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-apl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-tglb8/igt@gem_huc_c...@huc-copy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#2428]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9962/shard-iclb4/igt@gem_mmap_...@cpuset-medium-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19919/shard-iclb1/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_userptr_blits@process
[Intel-gfx] [PATCH] drm/i915/gvt: remove useless function
Fix the following clang warning:
drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function
'ppgtt_set_guest_root_entry' [-Wunused-function].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 897c007..a01ff44 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -587,12 +587,6 @@ static void _ppgtt_set_root_entry(struct intel_vgpu_mm *mm,
entry, index, false, 0, mm->vgpu);
}
-static inline void ppgtt_set_guest_root_entry(struct intel_vgpu_mm *mm,
- struct intel_gvt_gtt_entry *entry, unsigned long index)
-{
- _ppgtt_set_root_entry(mm, entry, index, true);
-}
-
static inline void ppgtt_set_shadow_root_entry(struct intel_vgpu_mm *mm,
struct intel_gvt_gtt_entry *entry, unsigned long index)
{
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: remove strap checks from gen 9
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Direction on gen9+ was to stop reading the straps and only rely on the
> VBT for marking the port presence. This happened while dealing with
> WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
> normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
> skl straps").
>
> For gen 10 it's hard to say if this will work or not since I can't test
> it, so leave it with the same behavior as before.
>
> For PCH_TGP we should still rely on the VBT to make ports E and F not
> available.
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: Anusha Srivatsa
I think I'd get an ack from Ville for this. He has a knack for this
stuff.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 36 ++--
> 1 file changed, 11 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d62ce9c87748..5a03cbba0280 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10883,34 +10883,25 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_ddi_init(dev_priv, PORT_B);
> intel_ddi_init(dev_priv, PORT_C);
> vlv_dsi_init(dev_priv);
> + } else if (DISPLAY_VER(dev_priv) == 9) {
> + intel_ddi_init(dev_priv, PORT_A);
> + intel_ddi_init(dev_priv, PORT_B);
> + intel_ddi_init(dev_priv, PORT_C);
> + intel_ddi_init(dev_priv, PORT_D);
> + intel_ddi_init(dev_priv, PORT_E);
> + intel_ddi_init(dev_priv, PORT_F);
> } else if (HAS_DDI(dev_priv)) {
> - int found;
> + u32 found;
>
> if (intel_ddi_crt_present(dev_priv))
> intel_crt_init(dev_priv);
>
> - /*
> - * Haswell uses DDI functions to detect digital outputs.
> - * On SKL pre-D0 the strap isn't connected. Later SKUs may or
> - * may not have it - it was supposed to be fixed by the same
> - * time we stopped using straps. Assume it's there.
> - */
> + /* Haswell uses DDI functions to detect digital outputs. */
> found = intel_de_read(dev_priv, DDI_BUF_CTL(PORT_A)) &
> DDI_INIT_DISPLAY_DETECTED;
> - /* WaIgnoreDDIAStrap: skl */
> - if (found || IS_DISPLAY_VER(dev_priv, 9))
> + if (found)
> intel_ddi_init(dev_priv, PORT_A);
>
> - /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
> - * register */
> - if (HAS_PCH_TGP(dev_priv)) {
> - /* W/A due to lack of STRAP config on TGP PCH*/
> - found = (SFUSE_STRAP_DDIB_DETECTED |
> - SFUSE_STRAP_DDIC_DETECTED |
> - SFUSE_STRAP_DDID_DETECTED);
> - } else {
> - found = intel_de_read(dev_priv, SFUSE_STRAP);
> - }
> -
> + found = intel_de_read(dev_priv, SFUSE_STRAP);
> if (found & SFUSE_STRAP_DDIB_DETECTED)
> intel_ddi_init(dev_priv, PORT_B);
> if (found & SFUSE_STRAP_DDIC_DETECTED)
> @@ -10919,11 +10910,6 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_ddi_init(dev_priv, PORT_D);
> if (found & SFUSE_STRAP_DDIF_DETECTED)
> intel_ddi_init(dev_priv, PORT_F);
> - /*
> - * On SKL we don't have a way to detect DDI-E so we rely on VBT.
> - */
> - if (IS_DISPLAY_VER(dev_priv, 9)
> - intel_ddi_init(dev_priv, PORT_E);
> } else if (HAS_PCH_SPLIT(dev_priv)) {
> int found;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915/display: use DISPLAY_VER() on remaining users
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")
> added INTEL_GEN() in the display code, where it should actually be using
> DISPLAY_VER(). Switch to the new macro.
>
> Cc: Kai Vehmanen
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 9671c8f6e892..9fe3a25710b8 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -1309,7 +1309,7 @@ static void i915_audio_component_init(struct
> drm_i915_private *dev_priv)
> if (DISPLAY_VER(dev_priv) >= 9) {
> aud_freq_init = intel_de_read(dev_priv, AUD_FREQ_CNTRL);
>
> - if (INTEL_GEN(dev_priv) >= 12)
> + if (DISPLAY_VER(dev_priv) >= 12)
> aud_freq = AUD_FREQ_GEN12;
> else
> aud_freq = aud_freq_init;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/12] drm/i915: rename display.version to display.ver
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> The macro we use to check is called DISPLAY_VER(). While using this
> macro and the new ones being added in following changes I made the
> mistake multiple times when mixing both "ver" and "version". Although
> it's usually better to prefer the complete name, the shorhand
> DISPLAY_VER() / GRAPHICS_VER / MEDIA_VER are clear and cause less
> visual polution.
>
> Another issue is when copying the variable to other places.
> "display.version" would be copied to a "display_version" variable which
> is long and would make people abbreviate as "version", or "display_ver".
> In the first case it's not always clear what version refers to, and in
> the second case it just hints it should be the name in the first place.
>
> So, in the same way use used "gen" rather than "generation", use "ver"
> instead of "version".
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: José Roberto de Souza
> Acked-by: Jani Nikula
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_pci.c | 4 ++--
> drivers/gpu/drm/i915/intel_device_info.h | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 69e43bf91a15..8c62bb2abd31 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1237,7 +1237,7 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> #define INTEL_GEN(dev_priv) (INTEL_INFO(dev_priv)->gen)
> #define INTEL_DEVID(dev_priv)(RUNTIME_INFO(dev_priv)->device_id)
>
> -#define DISPLAY_VER(i915)(INTEL_INFO(i915)->display.version)
> +#define DISPLAY_VER(i915)(INTEL_INFO(i915)->display.ver)
> #define IS_DISPLAY_RANGE(i915, from, until) \
> (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
> #define IS_DISPLAY_VER(i915, v) (DISPLAY_VER(i915) == (v))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 480553746794..ce5cbeaf036d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -36,7 +36,7 @@
> #include "i915_selftest.h"
>
> #define PLATFORM(x) .platform = (x)
> -#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.version = (x)
> +#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.ver = (x)
>
> #define I845_PIPE_OFFSETS \
> .pipe_offsets = { \
> @@ -723,7 +723,7 @@ static const struct intel_device_info bxt_info = {
> static const struct intel_device_info glk_info = {
> GEN9_LP_FEATURES,
> PLATFORM(INTEL_GEMINILAKE),
> - .display.version = 10,
> + .display.ver = 10,
> .ddb_size = 1024,
> GLK_COLORS,
> };
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 2f442d418a15..b16c75927a12 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -189,7 +189,7 @@ struct intel_device_info {
> #undef DEFINE_FLAG
>
> struct {
> - u8 version;
> + u8 ver;
>
> #define DEFINE_FLAG(name) u8 name:1
> DEV_INFO_DISPLAY_FOR_EACH_FLAG(DEFINE_FLAG);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/19] drm/i915/gtt: map the PD up front
On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote: > > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld > wrote: > > > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote: > > > > > > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Matthew Auld wrote: > > > > We need to general our accessor for the page directories and tables from > > > > using the simple kmap_atomic to support local memory, and this setup > > > > must be done on acquisition of the backing storage prior to entering > > > > fence execution contexts. Here we replace the kmap with the object > > > > maping code that for simple single page shmemfs object will return a > > > > plain kmap, that is then kept for the lifetime of the page directory. > > > > > > > > v2: (Thomas) Rebase on dma_resv and obj->mm.lock removal. > > > > > > > > Signed-off-by: Matthew Auld > > > > Signed-off-by: Chris Wilson > > > > > > So I wanted to understand what px stands for as an abbreviation, and dug > > > all the way down to this: > > > > > > commit 567047be2a7ede082d29f45524c287b87bd75e53 > > > Author: Mika Kuoppala > > > Date: Thu Jun 25 18:35:12 2015 +0300 > > > > > > drm/i915/gtt: Use macros to access dma mapped pages > > > > > > I still have no idea what it means, I guess px = page. But I also > > > committed this, so I guess can blame myself :-) > > > > > > But while digging I've stumbled over this here > > > > > > commit 6eebfe8a10a62139d681e2f1af1386252742278b > > > Author: Chris Wilson > > > Date: Fri Jul 12 08:58:18 2019 +0100 > > > > > > drm/i915/gtt: Use shallow dma pages for scratch > > > > > > > > > And that's some serious wtf. Yes we've done some compile-time type > > > casting automagic between i915_priv and dev in the past, and I think even > > > that was bad taste. But it was justified with that we have these > > > everywhere (especially in the mmio macros), and it would be a terrible > > > flag day. > > > > > > But I'm not seeing any need for auto-casting for these pages here, and I'm > > > not aware that we're doing this anywhere else in kernel code. There is > > > some macro-trickery in lockdep annotations, but that relies on the lockdep > > > map having the same struct member name in all lock types, and is not > > > exposed to drivers at all. > > > > > > Am I missing something, or why do we have this compile-time type casting > > > stuff going on in i915 page accessors? > > > > I think 'x' in the px family of macros/functions is meant in the > > variable/polymorphic sense, so it can potentially be a pt, pd, etc > > underneath. If you look at px_base() for example all it does is fish > > out the base GEM object from the structure, using the > > known-at-compile-time-type, which then lets us get at the dma address, > > vaddr etc. > > Yeah, but that's not how things landed. px predates the magic > polymorphism. I think the px just stands for page, or at least > originally only stood for page. I'm not sure honestly. It seems to be > just used for page directory type of things, but I haven't found that > written down anywhere. > > > It does seem pretty magical, but seems ok to me, if it means less typing? > > That's the worst justification. Code is generally write once, read > many times. Optimizing for writing at the cost of magic indirection is > generally not the right tradeoff in the kernel, where any indirection > could hide a major gotcha. In huge userspace applications fancy > abstraction and polymorphism is often the right thing to do, but there > you also have a real compiler with a real typesystem (generally at > least) helping you out. Or it's yolo duct-taping with lots of tests, > where the speed at which you can hack up something matters more than > being able to read it quickly. > > We're typing C here. It is generally rather verbose, with type casting > all done explicitly. Ok. So should we change this around for this patch? The px_ stuff is already quite prevalent it seems, and the px_vaddr() is just one part of it? Maybe just add pt_vaddr(), pd_vaddr() etc instead? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 04/12] drm/i915: add macros for graphics and media versions
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Like it was done in
> commit 01eb15c9165e ("drm/i915: Add DISPLAY_VER() and related macros")
> add the correspondent macros for graphics and media. Going forward we
> will prefer checking the versions for the specific IPs (graphics, media
> and display) rather than grouping everything under a "gen" version.
>
> For consistency and to make the maintenance easier, it'd be preferred
> not to mix the *GEN* macros with the new ones. For older platforms we
> can simply consider that the previous "gen" number will extend to all
> 3 IPs. Then we can start replacing its use in the driver. Right now this
> replacement is not done and only the infrastructure is put in place.
> We also leave gen and gen_mask inside struct intel_device_info while
> it's still being used throughout the code.
>
> v2: Repurpose IS_{GRAPHICS,MEDIA}_VER() macros to work with a range
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 15 ++-
> drivers/gpu/drm/i915/i915_pci.c | 7 ++-
> drivers/gpu/drm/i915/intel_device_info.h | 3 +++
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 907c66efb469..cb59eb0f6c5b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1234,9 +1234,22 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> #define RUNTIME_INFO(dev_priv) (&(dev_priv)->__runtime)
> #define DRIVER_CAPS(dev_priv)(&(dev_priv)->caps)
>
> -#define INTEL_GEN(dev_priv) (INTEL_INFO(dev_priv)->gen)
> #define INTEL_DEVID(dev_priv)(RUNTIME_INFO(dev_priv)->device_id)
>
> +/*
> + * Deprecated: this will be replaced by individual IP checks:
> + * GRAPHICS_VER(), MEDIA_VER and DISPLAY_VER()
Nitpick, MEDIA_VER() with braces.
Otherwise,
Reviewed-by: Jani Nikula
> + */
> +#define INTEL_GEN(dev_priv) (INTEL_INFO(dev_priv)->gen)
> +
> +#define GRAPHICS_VER(i915) (INTEL_INFO(i915)->graphics_ver)
> +#define IS_GRAPHICS_VER(i915, from, until) \
> + (GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
> +
> +#define MEDIA_VER(i915) (INTEL_INFO(i915)->media_ver)
> +#define IS_MEDIA_VER(i915, from, until) \
> + (MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
> +
> #define DISPLAY_VER(i915)(INTEL_INFO(i915)->display.ver)
> #define IS_DISPLAY_VER(i915, from, until) \
> (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ce5cbeaf036d..97ab73276334 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -36,7 +36,12 @@
> #include "i915_selftest.h"
>
> #define PLATFORM(x) .platform = (x)
> -#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.ver = (x)
> +#define GEN(x) \
> + .gen_mask = BIT((x) - 1), \
> + .gen = (x), \
> + .graphics_ver = (x), \
> + .media_ver = (x), \
> + .display.ver = (x)
>
> #define I845_PIPE_OFFSETS \
> .pipe_offsets = { \
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index b16c75927a12..405883a8cc84 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -162,6 +162,9 @@ enum intel_ppgtt_type {
> struct intel_device_info {
> u16 gen_mask;
>
> + u8 graphics_ver;
> + u8 media_ver;
> +
> u8 gen;
> u8 gt; /* GT number, 0 if undefined */
> intel_engine_mask_t platform_engine_mask; /* Engines supported by the
> HW */
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915/display: rename display version macros
On Mon, 12 Apr 2021, Lucas De Marchi wrote: > While converting the rest of the driver to use GRAPHICS_VER() and > MEDIA_VER(), following what was done for display, some discussions went > back on what we did for display: > > 1) Why is the == comparison special that deserves a separate > macro instead of just getting the version and comparing directly > like is done for >, >=, <=? > > 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for > brevity. If we remove the current users of IS_DISPLAY_VER(), we > could actually repurpose it for a range check > > With (1) there could be an advantage if we used gen_mask since multiple > conditionals be combined by the compiler in a single and instruction and > check the result. However a) INTEL_GEN() doesn't use the mask since it > would make the code bigger everywhere else and b) in the cases it made > sense, it also made sense to convert to the _RANGE() variant. > > So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range > like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() > users to use == and != operators. Aside from the definition changes, > this was done by the following semantic patch: > > @@ expression dev_priv, E1; @@ > - !IS_DISPLAY_VER(dev_priv, E1) > + DISPLAY_VER(dev_priv) != E1 > > @@ expression dev_priv, E1; @@ > - IS_DISPLAY_VER(dev_priv, E1) > + DISPLAY_VER(dev_priv) == E1 > > @@ expression dev_priv, from, until; @@ > - IS_DISPLAY_RANGE(dev_priv, from, until) > + IS_DISPLAY_VER(dev_priv, from, until) > Thanks for summing up the discussion in a delightfully clear commit message! I like the change. Reviewed-by: Jani Nikula > Cc: Jani Nikula > Cc: Matt Roper > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +- > drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- > drivers/gpu/drm/i915/display/intel_atomic.c | 2 +- > drivers/gpu/drm/i915/display/intel_audio.c| 2 +- > drivers/gpu/drm/i915/display/intel_bios.c | 4 +- > drivers/gpu/drm/i915/display/intel_bw.c | 8 +-- > drivers/gpu/drm/i915/display/intel_cdclk.c| 18 +++--- > drivers/gpu/drm/i915/display/intel_color.c| 6 +- > drivers/gpu/drm/i915/display/intel_crt.c | 6 +- > drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- > drivers/gpu/drm/i915/display/intel_csr.c | 2 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 26 - > .../drm/i915/display/intel_ddi_buf_trans.c| 8 +-- > drivers/gpu/drm/i915/display/intel_display.c | 56 +-- > .../drm/i915/display/intel_display_power.c| 26 - > drivers/gpu/drm/i915/display/intel_dp.c | 8 +-- > drivers/gpu/drm/i915/display/intel_dpll.c | 2 +- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- > drivers/gpu/drm/i915/display/intel_fb.c | 2 +- > drivers/gpu/drm/i915/display/intel_fbc.c | 20 +++ > .../drm/i915/display/intel_fifo_underrun.c| 4 +- > drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 4 +- > drivers/gpu/drm/i915/display/intel_lvds.c | 2 +- > drivers/gpu/drm/i915/display/intel_overlay.c | 10 ++-- > drivers/gpu/drm/i915/display/intel_panel.c| 8 +-- > drivers/gpu/drm/i915/display/intel_pipe_crc.c | 4 +- > drivers/gpu/drm/i915/display/intel_psr.c | 4 +- > drivers/gpu/drm/i915/display/intel_tc.c | 6 +- > drivers/gpu/drm/i915/display/intel_tv.c | 6 +- > .../drm/i915/display/skl_universal_plane.c| 8 +-- > drivers/gpu/drm/i915/i915_drv.h | 3 +- > drivers/gpu/drm/i915/i915_irq.c | 10 ++-- > drivers/gpu/drm/i915/intel_pm.c | 48 > 35 files changed, 165 insertions(+), 166 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c > b/drivers/gpu/drm/i915/display/i9xx_plane.c > index 456374ddf37a..80da0e3571a4 100644 > --- a/drivers/gpu/drm/i915/display/i9xx_plane.c > +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c > @@ -144,7 +144,7 @@ static bool i9xx_plane_has_windowing(struct intel_plane > *plane) > return i9xx_plane == PLANE_B; > else if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv)) > return false; > - else if (IS_DISPLAY_VER(dev_priv, 4)) > + else if (DISPLAY_VER(dev_priv) == 4) > return i9xx_plane == PLANE_C; > else > return i9xx_plane == PLANE_B || > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c > b/drivers/gpu/drm/i915/display/icl_dsi.c > index 9282978060b0..37e2d93d064c 100644 > --- a/drivers/gpu/drm/i915/display/icl_dsi.c > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c > @@ -592,7 +592,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder > *encoder, >* a value '0' inside TA_PARAM_REGISTERS otherwise >
Re: [Intel-gfx] [PATCH v2 05/12] drm/i915/gt: replace gen use in intel_engine_cs
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Start using the new fields graphics_version for the previous gen checks.
> Here we rename the "gen" field and replace the comparisons using it to
> start using the new GRAPHICS_VER(). Other uses of INTEL_GEN() were left
> as is for automatic conversion later.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 40 ++--
> drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 18 -
> 2 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index efe935f80c1a..6dbdbde00f14 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -45,9 +45,9 @@ struct engine_info {
> unsigned int hw_id;
> u8 class;
> u8 instance;
> - /* mmio bases table *must* be sorted in reverse gen order */
> + /* mmio bases table *must* be sorted in reverse graphics_ver order */
> struct engine_mmio_base {
> - u32 gen : 8;
> + u32 graphics_ver : 8;
> u32 base : 24;
> } mmio_bases[MAX_MMIO_BASES];
> };
> @@ -58,7 +58,7 @@ static const struct engine_info intel_engines[] = {
> .class = RENDER_CLASS,
> .instance = 0,
> .mmio_bases = {
> - { .gen = 1, .base = RENDER_RING_BASE }
> + { .graphics_ver = 1, .base = RENDER_RING_BASE }
> },
> },
> [BCS0] = {
> @@ -66,7 +66,7 @@ static const struct engine_info intel_engines[] = {
> .class = COPY_ENGINE_CLASS,
> .instance = 0,
> .mmio_bases = {
> - { .gen = 6, .base = BLT_RING_BASE }
> + { .graphics_ver = 6, .base = BLT_RING_BASE }
> },
> },
> [VCS0] = {
> @@ -74,9 +74,9 @@ static const struct engine_info intel_engines[] = {
> .class = VIDEO_DECODE_CLASS,
> .instance = 0,
> .mmio_bases = {
> - { .gen = 11, .base = GEN11_BSD_RING_BASE },
> - { .gen = 6, .base = GEN6_BSD_RING_BASE },
> - { .gen = 4, .base = BSD_RING_BASE }
> + { .graphics_ver = 11, .base = GEN11_BSD_RING_BASE },
> + { .graphics_ver = 6, .base = GEN6_BSD_RING_BASE },
> + { .graphics_ver = 4, .base = BSD_RING_BASE }
> },
> },
> [VCS1] = {
> @@ -84,8 +84,8 @@ static const struct engine_info intel_engines[] = {
> .class = VIDEO_DECODE_CLASS,
> .instance = 1,
> .mmio_bases = {
> - { .gen = 11, .base = GEN11_BSD2_RING_BASE },
> - { .gen = 8, .base = GEN8_BSD2_RING_BASE }
> + { .graphics_ver = 11, .base = GEN11_BSD2_RING_BASE },
> + { .graphics_ver = 8, .base = GEN8_BSD2_RING_BASE }
> },
> },
> [VCS2] = {
> @@ -93,7 +93,7 @@ static const struct engine_info intel_engines[] = {
> .class = VIDEO_DECODE_CLASS,
> .instance = 2,
> .mmio_bases = {
> - { .gen = 11, .base = GEN11_BSD3_RING_BASE }
> + { .graphics_ver = 11, .base = GEN11_BSD3_RING_BASE }
> },
> },
> [VCS3] = {
> @@ -101,7 +101,7 @@ static const struct engine_info intel_engines[] = {
> .class = VIDEO_DECODE_CLASS,
> .instance = 3,
> .mmio_bases = {
> - { .gen = 11, .base = GEN11_BSD4_RING_BASE }
> + { .graphics_ver = 11, .base = GEN11_BSD4_RING_BASE }
> },
> },
> [VECS0] = {
> @@ -109,8 +109,8 @@ static const struct engine_info intel_engines[] = {
> .class = VIDEO_ENHANCEMENT_CLASS,
> .instance = 0,
> .mmio_bases = {
> - { .gen = 11, .base = GEN11_VEBOX_RING_BASE },
> - { .gen = 7, .base = VEBOX_RING_BASE }
> + { .graphics_ver = 11, .base = GEN11_VEBOX_RING_BASE },
> + { .graphics_ver = 7, .base = VEBOX_RING_BASE }
> },
> },
> [VECS1] = {
> @@ -118,7 +118,7 @@ static const struct engine_info intel_engines[] = {
> .class = VIDEO_ENHANCEMENT_CLASS,
> .instance = 1,
> .mmio_bases = {
> - { .gen = 11, .base = GEN11_VEBOX2_RING_BASE }
> + { .graphics_ver = 11, .base = GEN11_VEBOX2_RING_BASE }
> },
> },
> };
> @@ -146,9 +146,9 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8
> class)
>
> switch (class) {
> case RENDER_CLASS:
> - switch (INTEL_GEN(gt->i915)) {
> + switch (GRAPHICS_VER(gt->i915
Re: [Intel-gfx] [PATCH v2 06/12] drm/i915/selftests: replace unused mask with simple version
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Since its introduction 2 years ago, we never used the mask to span more
> than one gen. Replace gen_mask a single number and start using the new
> GRAPHICS_VER().
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/selftest_workarounds.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> index 19850489a3fc..64937ec3f2dc 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> @@ -927,7 +927,7 @@ static int scrub_whitelisted_registers(struct
> intel_context *ce)
>
> struct regmask {
> i915_reg_t reg;
> - unsigned long gen_mask;
> + u8 graphics_ver;
> };
>
> static bool find_reg(struct drm_i915_private *i915,
> @@ -938,7 +938,7 @@ static bool find_reg(struct drm_i915_private *i915,
> u32 offset = i915_mmio_reg_offset(reg);
>
> while (count--) {
> - if (INTEL_INFO(i915)->gen_mask & tbl->gen_mask &&
> + if (GRAPHICS_VER(i915) == tbl->graphics_ver &&
> i915_mmio_reg_offset(tbl->reg) == offset)
> return true;
> tbl++;
> @@ -951,8 +951,8 @@ static bool pardon_reg(struct drm_i915_private *i915,
> i915_reg_t reg)
> {
> /* Alas, we must pardon some whitelists. Mistakes already made */
> static const struct regmask pardon[] = {
> - { GEN9_CTX_PREEMPT_REG, INTEL_GEN_MASK(9, 9) },
> - { GEN8_L3SQCREG4, INTEL_GEN_MASK(9, 9) },
> + { GEN9_CTX_PREEMPT_REG, 9 },
> + { GEN8_L3SQCREG4, 9 },
> };
>
> return find_reg(i915, reg, pardon, ARRAY_SIZE(pardon));
> @@ -974,7 +974,7 @@ static bool writeonly_reg(struct drm_i915_private *i915,
> i915_reg_t reg)
> {
> /* Some registers do not seem to behave and our writes unreadable */
> static const struct regmask wo[] = {
> - { GEN9_SLICE_COMMON_ECO_CHICKEN1, INTEL_GEN_MASK(9, 9) },
> + { GEN9_SLICE_COMMON_ECO_CHICKEN1, 9 },
> };
>
> return find_reg(i915, reg, wo, ARRAY_SIZE(wo));
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin
I met below error during boot with i915 builtin if pass
"i915.mitigations=off":
[0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
The reason is slab subsystem isn't ready at that time, so kstrdup()
returns NULL. Fix this issue by using stack var instead of kstrdup().
Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
mitigations")
Signed-off-by: Jisheng Zhang
---
drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
b/drivers/gpu/drm/i915/i915_mitigations.c
index 84f12598d145..7dadf41064e0 100644
--- a/drivers/gpu/drm/i915/i915_mitigations.c
+++ b/drivers/gpu/drm/i915/i915_mitigations.c
@@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
static int mitigations_set(const char *val, const struct kernel_param *kp)
{
unsigned long new = ~0UL;
- char *str, *sep, *tok;
+ char str[64], *sep, *tok;
bool first = true;
int err = 0;
BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
- str = kstrdup(val, GFP_KERNEL);
- if (!str)
- return -ENOMEM;
+ strncpy(str, val, sizeof(str) - 1);
for (sep = str; (tok = strsep(&sep, ","));) {
bool enable = true;
@@ -86,7 +84,6 @@ static int mitigations_set(const char *val, const struct
kernel_param *kp)
break;
}
}
- kfree(str);
if (err)
return err;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/12] drm/i915/selftests: eliminate use of gen_mask
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Remove the remaining uses of INTEL_GEN_MASK() and the correspondent
> gen_mask in struct intel_device_info. This will allow the removal of
> gen_mask later since it's incompatible with the new per-IP versioning
> scheme.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 8 +---
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 8 +---
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 661b50191f2b..ed5abe7be498 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2008,12 +2008,14 @@ void intel_uncore_fini_mmio(struct intel_uncore
> *uncore)
> static const struct reg_whitelist {
> i915_reg_t offset_ldw;
> i915_reg_t offset_udw;
> - u16 gen_mask;
> + u8 min_graphics_ver;
> + u8 max_graphics_ver;
> u8 size;
> } reg_read_whitelist[] = { {
> .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
> .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
> - .gen_mask = INTEL_GEN_MASK(4, 12),
> + .min_graphics_ver = 4,
> + .max_graphics_ver = 12,
> .size = 8
> } };
>
> @@ -2038,7 +2040,7 @@ int i915_reg_read_ioctl(struct drm_device *dev,
> GEM_BUG_ON(entry->size > 8);
> GEM_BUG_ON(entry_offset & (entry->size - 1));
>
> - if (INTEL_INFO(i915)->gen_mask & entry->gen_mask &&
> + if (IS_GRAPHICS_VER(i915, entry->min_graphics_ver,
> entry->max_graphics_ver) &&
> entry_offset == (reg->offset & -entry->size))
> break;
> entry++;
> diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c
> b/drivers/gpu/drm/i915/selftests/intel_uncore.c
> index 0e4e6be0101d..f76c9bcec735 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c
> @@ -125,17 +125,19 @@ static int live_forcewake_ops(void *arg)
> {
> static const struct reg {
> const char *name;
> + u8 min_graphics_ver;
> + u8 max_graphics_ver;
> unsigned long platforms;
> unsigned int offset;
> } registers[] = {
> {
> "RING_START",
> - INTEL_GEN_MASK(6, 7),
> + 6, 7,
> 0x38,
> },
> {
> "RING_MI_MODE",
> - INTEL_GEN_MASK(8, BITS_PER_LONG),
> + 8, U8_MAX,
Makes me wonder if we should add VER_MAX. Can be done later if needed.
Reviewed-by: Jani Nikula
> 0x9c,
> }
> };
> @@ -170,7 +172,7 @@ static int live_forcewake_ops(void *arg)
>
> /* We have to pick carefully to get the exact behaviour we need */
> for (r = registers; r->name; r++)
> - if (r->platforms & INTEL_INFO(gt->i915)->gen_mask)
> + if (IS_GRAPHICS_VER(gt->i915, r->min_graphics_ver,
> r->max_graphics_ver))
> break;
> if (!r->name) {
> pr_debug("Forcewaked register not known for %s; skipping\n",
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/12] drm/i915: finish removal of gen_mask
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Now that it's not used anywhere, remove it from struct
> intel_device_info. To allow a period in which code will be converted to
> the new macro, keep IS_GEN_RANGE() around, just redefining it to use
> the new fields. The size advantage from IS_GEN_RANGE() using a mask is
> not that big as it has pretty limited use througout the driver:
>
>textdata bss dec hex filename
> 2758497 959656496 2860958 2ba79e drivers/gpu/drm/i915/i915.ko.old
> 2758586 959536496 2861035 2ba7eb drivers/gpu/drm/i915/i915.ko.new
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 --
> drivers/gpu/drm/i915/i915_drv.h | 13 -
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.h | 2 --
> 4 files changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 305557e1942a..825b45cb3543 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -768,8 +768,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> memcpy(device_info, match_info, sizeof(*device_info));
> RUNTIME_INFO(i915)->device_id = pdev->device;
>
> - BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
> -
> return i915;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index cb59eb0f6c5b..b984a340b21f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1241,6 +1241,10 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> * GRAPHICS_VER(), MEDIA_VER and DISPLAY_VER()
> */
> #define INTEL_GEN(dev_priv) (INTEL_INFO(dev_priv)->gen)
> +/*
> + * Deprecated: use IS_GRAPHICS_VER()
> + */
Nitpick, I think this should also mention IS_MEDIA_VER() and
DISPLAY_VER() to not have people blindly use IS_GRAPHICS_VER().
Reviewed-by: Jani Nikula
> +#define IS_GEN_RANGE(dev_priv, s, e) IS_GRAPHICS_VER(dev_priv, (s), (e))
>
> #define GRAPHICS_VER(i915) (INTEL_INFO(i915)->graphics_ver)
> #define IS_GRAPHICS_VER(i915, from, until) \
> @@ -1257,15 +1261,6 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> #define REVID_FOREVER0xff
> #define INTEL_REVID(dev_priv)
> (to_pci_dev((dev_priv)->drm.dev)->revision)
>
> -#define INTEL_GEN_MASK(s, e) ( \
> - BUILD_BUG_ON_ZERO(!__builtin_constant_p(s)) + \
> - BUILD_BUG_ON_ZERO(!__builtin_constant_p(e)) + \
> - GENMASK((e) - 1, (s) - 1))
> -
> -/* Returns true if Gen is in inclusive range [Start, End] */
> -#define IS_GEN_RANGE(dev_priv, s, e) \
> - (!!(INTEL_INFO(dev_priv)->gen_mask & INTEL_GEN_MASK((s), (e
> -
> #define IS_GEN(dev_priv, n) \
> (BUILD_BUG_ON_ZERO(!__builtin_constant_p(n)) + \
>INTEL_INFO(dev_priv)->gen == (n))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 97ab73276334..3b9cd1af0f28 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -37,7 +37,6 @@
>
> #define PLATFORM(x) .platform = (x)
> #define GEN(x) \
> - .gen_mask = BIT((x) - 1), \
> .gen = (x), \
> .graphics_ver = (x), \
> .media_ver = (x), \
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 405883a8cc84..b8f7b996f140 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -160,8 +160,6 @@ enum intel_ppgtt_type {
> func(supports_tv);
>
> struct intel_device_info {
> - u16 gen_mask;
> -
> u8 graphics_ver;
> u8 media_ver;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915: eliminate remaining uses of intel_device_info->gen
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Replace gen with the new graphics_ver value and use GRAPHICS_VER()
> in those places.
>
> Signed-off-by: Lucas De Marchi
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 22 +--
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 5964e67c7d36..297143511f99 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -274,7 +274,7 @@ struct i915_execbuffer {
> struct drm_mm_node node; /** temporary GTT binding */
> unsigned long vaddr; /** Current kmap address */
> unsigned long page; /** Currently mapped page index */
> - unsigned int gen; /** Cached value of INTEL_GEN */
> + unsigned int graphics_ver; /** Cached value of GRAPHICS_VER */
Is this unsigned int for efficiency or what? *shrug*
> bool use_64bit_reloc : 1;
> bool has_llc : 1;
> bool has_fence : 1;
> @@ -1049,10 +1049,10 @@ static void reloc_cache_init(struct reloc_cache
> *cache,
> cache->page = -1;
> cache->vaddr = 0;
> /* Must be a variable in the struct to allow GCC to unroll. */
> - cache->gen = INTEL_GEN(i915);
> + cache->graphics_ver = GRAPHICS_VER(i915);
> cache->has_llc = HAS_LLC(i915);
> cache->use_64bit_reloc = HAS_64BIT_RELOC(i915);
> - cache->has_fence = cache->gen < 4;
> + cache->has_fence = cache->graphics_ver < 4;
> cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
> cache->node.flags = 0;
> reloc_cache_clear(cache);
> @@ -1402,7 +1402,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
>
> err = eb->engine->emit_bb_start(rq,
> batch->node.start, PAGE_SIZE,
> - cache->gen > 5 ? 0 :
> I915_DISPATCH_SECURE);
> + cache->graphics_ver > 5 ? 0 :
> I915_DISPATCH_SECURE);
> if (err)
> goto skip_request;
>
> @@ -1503,14 +1503,14 @@ static int __reloc_entry_gpu(struct i915_execbuffer
> *eb,
> u64 offset,
> u64 target_addr)
> {
> - const unsigned int gen = eb->reloc_cache.gen;
> + const unsigned int ver = eb->reloc_cache.graphics_ver;
Nitpick, I think I'd like to use the more specific name throughout, also
for local variables, i.e. graphics_ver, media_ver, or display_ver.
Does not need to be changed in this patch though.
Reviewed-by: Jani Nikula
> unsigned int len;
> u32 *batch;
> u64 addr;
>
> - if (gen >= 8)
> + if (ver >= 8)
> len = offset & 7 ? 8 : 5;
> - else if (gen >= 4)
> + else if (ver >= 4)
> len = 4;
> else
> len = 3;
> @@ -1522,7 +1522,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
> return false;
>
> addr = gen8_canonical_addr(vma->node.start + offset);
> - if (gen >= 8) {
> + if (ver >= 8) {
> if (offset & 7) {
> *batch++ = MI_STORE_DWORD_IMM_GEN4;
> *batch++ = lower_32_bits(addr);
> @@ -1542,7 +1542,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
> *batch++ = lower_32_bits(target_addr);
> *batch++ = upper_32_bits(target_addr);
> }
> - } else if (gen >= 6) {
> + } else if (ver >= 6) {
> *batch++ = MI_STORE_DWORD_IMM_GEN4;
> *batch++ = 0;
> *batch++ = addr;
> @@ -1552,12 +1552,12 @@ static int __reloc_entry_gpu(struct i915_execbuffer
> *eb,
> *batch++ = 0;
> *batch++ = vma_phys_addr(vma, offset);
> *batch++ = target_addr;
> - } else if (gen >= 4) {
> + } else if (ver >= 4) {
> *batch++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
> *batch++ = 0;
> *batch++ = addr;
> *batch++ = target_addr;
> - } else if (gen >= 3 &&
> + } else if (ver >= 3 &&
> !(IS_I915G(eb->i915) || IS_I915GM(eb->i915))) {
> *batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> *batch++ = addr;
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 825b45cb3543..e477d278ca73 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -794,7 +794,7 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return PTR_ERR(i915);
>
> /* Disable nuclear pageflip by default on pre-ILK */
> - if (!i915->params.nuclear_pagefli
Re: [Intel-gfx] [PATCH v2 10/12] drm/i915: finish removal of gen from intel_device_info
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Now that it's not being used anymore, finish its removal. Like for
> gen_mask, we replace INTEL_GEN() and IS_GEN() macros to use the new
> field.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 +-
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> 4 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b984a340b21f..549ce0ce5bde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1240,11 +1240,15 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> * Deprecated: this will be replaced by individual IP checks:
> * GRAPHICS_VER(), MEDIA_VER and DISPLAY_VER()
> */
> -#define INTEL_GEN(dev_priv) (INTEL_INFO(dev_priv)->gen)
> +#define INTEL_GEN(dev_priv) GRAPHICS_VER(dev_priv)
> /*
> * Deprecated: use IS_GRAPHICS_VER()
> */
> #define IS_GEN_RANGE(dev_priv, s, e) IS_GRAPHICS_VER(dev_priv, (s), (e))
> +/*
> + * Deprecated: use GRAPHICS_VER()
> + */
Nitpick, also mention media and display variants here.
Reviewed-by: Jani Nikula
> +#define IS_GEN(dev_priv, n) (GRAPHICS_VER(dev_priv) == (n))
>
> #define GRAPHICS_VER(i915) (INTEL_INFO(i915)->graphics_ver)
> #define IS_GRAPHICS_VER(i915, from, until) \
> @@ -1261,10 +1265,6 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> #define REVID_FOREVER0xff
> #define INTEL_REVID(dev_priv)
> (to_pci_dev((dev_priv)->drm.dev)->revision)
>
> -#define IS_GEN(dev_priv, n) \
> - (BUILD_BUG_ON_ZERO(!__builtin_constant_p(n)) + \
> - INTEL_INFO(dev_priv)->gen == (n))
> -
> #define HAS_DSB(dev_priv)(INTEL_INFO(dev_priv)->display.has_dsb)
>
> /*
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 3b9cd1af0f28..1453c1436f31 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -37,7 +37,6 @@
>
> #define PLATFORM(x) .platform = (x)
> #define GEN(x) \
> - .gen = (x), \
> .graphics_ver = (x), \
> .media_ver = (x), \
> .display.ver = (x)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index b8f7b996f140..8ab4fa6c7fdd 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -163,7 +163,6 @@ struct intel_device_info {
> u8 graphics_ver;
> u8 media_ver;
>
> - u8 gen;
> u8 gt; /* GT number, 0 if undefined */
> intel_engine_mask_t platform_engine_mask; /* Engines supported by the
> HW */
>
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index 0188f877cab2..2ffc763fe90d 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -162,7 +162,7 @@ struct drm_i915_private *mock_gem_device(void)
> /* Using the global GTT may ask questions about KMS users, so prepare */
> drm_mode_config_init(&i915->drm);
>
> - mkwrite_device_info(i915)->gen = -1;
> + mkwrite_device_info(i915)->graphics_ver = -1;
>
> mkwrite_device_info(i915)->page_sizes =
> I915_GTT_PAGE_SIZE_4K |
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/12] drm/i915: add media and display versions to device_info print
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Since we are now converting from a single gen version to graphics_ver,
> media_ver and display_ver, add the last 2 when printing the device info.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index b58bc7bff65e..6a351a709417 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -96,6 +96,8 @@ void intel_device_info_print_static(const struct
> intel_device_info *info,
> struct drm_printer *p)
> {
> drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
> + drm_printf(p, "media_ver: %u\n", info->media_ver);
> + drm_printf(p, "display_ver: %u\n", info->display.ver);
> drm_printf(p, "gt: %d\n", info->gt);
> drm_printf(p, "iommu: %s\n", iommu_name());
> drm_printf(p, "memory-regions: %x\n", info->memory_regions);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: split dgfx features from gen 12
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Make them independent so we can use DGFX_FEATURES more generically.
> For future platforms that do not use the GEN nomenclature we will define
> graphics, media and display separately, so we avoid setting graphics_ver
> with the GEN() macro.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_pci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 1453c1436f31..44e7b94db63d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -907,8 +907,7 @@ static const struct intel_device_info rkl_info = {
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0),
> };
>
> -#define GEN12_DGFX_FEATURES \
> - GEN12_FEATURES, \
> +#define DGFX_FEATURES \
> .memory_regions = REGION_SMEM | REGION_LMEM, \
> .has_master_unit_irq = 1, \
> .has_llc = 0, \
> @@ -916,7 +915,8 @@ static const struct intel_device_info rkl_info = {
> .is_dgfx = 1
>
> static const struct intel_device_info dg1_info __maybe_unused = {
> - GEN12_DGFX_FEATURES,
> + GEN12_FEATURES,
> + DGFX_FEATURES,
> PLATFORM(INTEL_DG1),
> .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
> .require_force_probe = 1,
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm/arm: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here for both komeda and malidp. Signed-off-by: Daniel Vetter Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov Cc: Brian Starkey --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 - drivers/gpu/drm/arm/malidp_drv.c| 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index aeda4e5ec4f4..ff45f23f3d56 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -247,7 +247,6 @@ static void komeda_kms_mode_config_init(struct komeda_kms_dev *kms, config->min_height = 0; config->max_width = 4096; config->max_height = 4096; - config->allow_fb_modifiers = true; config->funcs = &komeda_mode_config_funcs; config->helper_private = &komeda_mode_config_helpers; diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index d83c7366b348..de59f3302516 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -403,7 +403,6 @@ static int malidp_init(struct drm_device *drm) drm->mode_config.max_height = hwdev->max_line_size; drm->mode_config.funcs = &malidp_mode_config_funcs; drm->mode_config.helper_private = &malidp_mode_config_helpers; - drm->mode_config.allow_fb_modifiers = true; ret = malidp_crtc_init(drm); if (ret) -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/12] drm/arm/malidp: Always list modifiers
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: sta...@vger.kernel.org
Cc: Pekka Paalanen
Cc: Liviu Dudau
Cc: Brian Starkey
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index ddbba67f0283..8c2ab3d653b7 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs
malidp_de_plane_helper_funcs = {
.atomic_disable = malidp_de_plane_disable,
};
+static const uint64_t linear_only_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
int malidp_de_planes_init(struct drm_device *drm)
{
struct malidp_drm *malidp = drm->dev_private;
@@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
*/
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
&malidp_de_plane_funcs, formats, n,
- (id == DE_SMART) ? NULL : modifiers, plane_type,
- NULL);
+ (id == DE_SMART) ? linear_only_modifiers :
modifiers,
+ plane_type, NULL);
if (ret < 0)
goto cleanup;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/12] drm/i915: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Signed-off-by: Daniel Vetter Cc: "Ville Syrjälä" Cc: Manasi Navare Cc: Jani Nikula Cc: "José Roberto de Souza" Cc: Chris Wilson Cc: Imre Deak Cc: Dave Airlie Cc: Maarten Lankhorst Cc: Karthik B S Cc: Matt Roper --- drivers/gpu/drm/i915/display/intel_display.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index de8546a46872..2d1aa35adb0a 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -11732,8 +11732,6 @@ static void intel_mode_config_init(struct drm_i915_private *i915) mode_config->preferred_depth = 24; mode_config->prefer_shadow = 1; - mode_config->allow_fb_modifiers = true; - mode_config->funcs = &intel_mode_funcs; mode_config->async_page_flip = has_async_flips(i915); -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. This one actually set it twice on top of what drm_plane_init does, so double-redundant! Signed-off-by: Daniel Vetter Cc: Philipp Zabel Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-ker...@lists.infradead.org --- drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - drivers/gpu/drm/imx/imx-drm-core.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c index b549ce5e7607..37ae68a7fba5 100644 --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms) config->min_height = 1; config->max_width = 4096; config->max_height = 4096; - config->allow_fb_modifiers = true; config->normalize_zpos = true; config->funcs = &dcss_drm_mode_config_funcs; diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index 2ded8e4f32d0..8be4edaec958 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) drm->mode_config.max_height = 4096; drm->mode_config.funcs = &imx_drm_mode_config_funcs; drm->mode_config.helper_private = &imx_drm_mode_config_helpers; - drm->mode_config.allow_fb_modifiers = true; drm->mode_config.normalize_zpos = true; ret = drmm_mode_config_init(drm); -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] drm/msm/mdp4: Fix modifier support enabling
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: sta...@vger.kernel.org
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Jordan Crouse
Cc: Emil Velikov
Cc: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 3d729270bde1..4a5b518288b0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -88,8 +88,6 @@ static int mdp4_hw_init(struct msm_kms *kms)
if (mdp4_kms->rev > 1)
mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
- dev->mode_config.allow_fb_modifiers = true;
-
out:
pm_runtime_put_sync(dev->dev);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 9aecca919f24..49bdabea8ed5 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -349,6 +349,12 @@ enum mdp4_pipe mdp4_plane_pipe(struct drm_plane *plane)
return mdp4_plane->pipe;
}
+static const uint64_t supported_format_modifiers[] = {
+ DRM_FORMAT_MOD_SAMSUNG_64_32_TILE,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* initialize plane */
struct drm_plane *mdp4_plane_init(struct drm_device *dev,
enum mdp4_pipe pipe_id, bool private_plane)
@@ -377,7 +383,7 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs,
mdp4_plane->formats, mdp4_plane->nformats,
-NULL, type, NULL);
+supported_format_modifiers, type, NULL);
if (ret)
goto fail;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/12] drm/stm: Don't set allow_fb_modifiers explicitly
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter
Cc: Yannick Fertre
Cc: Philippe Cornu
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/12] drm/vc4: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Signed-off-by: Daniel Vetter Cc: Eric Anholt Cc: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_kms.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index bb5529a7a9c2..f29ac64a5aa5 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -899,7 +899,6 @@ int vc4_kms_load(struct drm_device *dev) dev->mode_config.helper_private = &vc4_mode_config_helpers; dev->mode_config.preferred_depth = 24; dev->mode_config.async_page_flip = true; - dev->mode_config.allow_fb_modifiers = true; ret = vc4_ctm_obj_init(vc4); if (ret) -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none of the planes registered supported
modifiers).
Now that this is all done consistently across all drivers, document
the rules and enforce it in the drm core.
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 16 +++-
include/drm/drm_mode_config.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0dd43882fe7c..16a7e3e57f7f 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -128,6 +128,11 @@
* pairs supported by this plane. The blob is a struct
* drm_format_modifier_blob. Without this property the plane doesn't
* support buffers with modifiers. Userspace cannot change this property.
+ *
+ * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
+ * capability for general modifier support. If this flag is set then every
+ * plane will have the IN_FORMATS property, even when it only supports
+ * DRM_FORMAT_MOD_LINEAR.
*/
static unsigned int drm_num_planes(struct drm_device *dev)
@@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
format_modifier_count++;
}
- if (format_modifier_count)
+ /* autoset the cap and check for consistency across all planes */
+ if (format_modifier_count) {
+ WARN_ON(!config->allow_fb_modifiers &&
+ !list_empty(&config->plane_list));
config->allow_fb_modifiers = true;
+ } else {
+ WARN_ON(config->allow_fb_modifiers);
+ }
plane->modifier_count = format_modifier_count;
plane->modifiers = kmalloc_array(format_modifier_count,
@@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
* drm_universal_plane_init() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.
*
+ * Drivers supporting modifiers must set @format_modifiers on all their planes,
+ * even those that only support DRM_FORMAT_MOD_LINEAR.
+ *
* Returns:
* Zero on success, error code on failure.
*/
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index ab424ddd7665..1ddf7783fdf7 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -909,6 +909,8 @@ struct drm_mode_config {
* @allow_fb_modifiers:
*
* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
+* Note that drivers should not set this directly, it is automatically
+* set in drm_universal_plane_init().
*
* IMPORTANT:
*
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/vgem: use shmem helpers
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking around with its refcount can upset drivers
real bad.
v2: Review from Thomas:
- sort #include
- drop more dead code that I didn't spot somehow
v3: select DRM_GEM_SHMEM_HELPER to make it build (intel-gfx-ci)
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 340 +---
2 files changed, 4 insertions(+), 337 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c16bd1afd87..4e41af50bc8c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -275,6 +275,7 @@ source "drivers/gpu/drm/kmb/Kconfig"
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index a0e75f1d5d01..b1b3a5ffc542 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,87 +51,11 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static const struct drm_gem_object_funcs vgem_gem_object_funcs;
-
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
} *vgem_device;
-static void vgem_gem_free_object(struct drm_gem_object *obj)
-{
- struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
-
- kvfree(vgem_obj->pages);
- mutex_destroy(&vgem_obj->pages_lock);
-
- if (obj->import_attach)
- drm_prime_gem_destroy(obj, vgem_obj->table);
-
- drm_gem_object_release(obj);
- kfree(vgem_obj);
-}
-
-static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct drm_vgem_gem_object *obj = vma->vm_private_data;
- /* We don't use vmf->pgoff since that has the fake offset */
- unsigned long vaddr = vmf->address;
- vm_fault_t ret = VM_FAULT_SIGBUS;
- loff_t num_pages;
- pgoff_t page_offset;
- page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
-
- num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
- if (page_offset >= num_pages)
- return VM_FAULT_SIGBUS;
-
- mutex_lock(&obj->pages_lock);
- if (obj->pages) {
- get_page(obj->pages[page_offset]);
- vmf->page = obj->pages[page_offset];
- ret = 0;
- }
- mutex_unlock(&obj->pages_lock);
- if (ret) {
- struct page *page;
-
- page = shmem_read_mapping_page(
- file_inode(obj->base.filp)->i_mapping,
- page_offset);
- if (!IS_ERR(page)) {
- vmf->page = page;
- ret = 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- ret = VM_FAULT_OOM;
- break;
- case -EBUSY:
- ret = VM_FAULT_RETRY;
- break;
- case -EFAULT:
- case -EINVAL:
- ret = VM_FAULT_SIGBUS;
- break;
- default:
- WARN_ON(PTR_ERR(page));
- ret = VM_FAULT_SIGBUS;
- break;
- }
-
- }
- return ret;
-}
-
-static const struct vm_operations_struct vgem_gem_vm_ops = {
- .fault = vgem_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static int vgem_open(struct drm_device *dev, struct drm_file *file)
{
struct vgem_file *vfile;
@@ -159,265 +84,12 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
- unsigned long size)
-{
- struct drm_vgem_gem_object *obj;
- int ret;
-
- obj = kzalloc(sizeof(*obj), GFP_KERNEL);
- if (!obj)
- return ERR_PTR(-ENOMEM);
-
- obj->base.funcs = &vgem_gem_object_funcs;
-
- ret = drm_gem_object_init(dev,
[Intel-gfx] [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Signed-off-by: Daniel Vetter Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Krzysztof Kozlowski Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org --- drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 64370b634cca..79fa3649185c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -177,7 +177,5 @@ void exynos_drm_mode_config_init(struct drm_device *dev) dev->mode_config.funcs = &exynos_drm_mode_config_funcs; dev->mode_config.helper_private = &exynos_drm_mode_config_helpers; - dev->mode_config.allow_fb_modifiers = true; - dev->mode_config.normalize_zpos = true; } -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/12] drm/nouveau: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Note that this fixes an inconsistency: We've set the cap everywhere, but only nv50+ supports modifiers. Hence cc stable, but not further back then the patch from Paul. Cc: sta...@vger.kernel.org # v5.1 + Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 14101bd2a0ff..929de41c281f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev) dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; - dev->mode_config.allow_fb_modifiers = true; if (drm->client.device.info.chipset < 0x11) dev->mode_config.async_page_flip = false; -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] drm/msm/dpu1: Don't set allow_fb_modifiers explicitly
Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Signed-off-by: Daniel Vetter Cc: Rob Clark Cc: Kalyan Thota Cc: Jordan Crouse Cc: Eric Anholt Cc: Tanmay Shah Cc: Rajendra Nayak Cc: Jeykumar Sankaran Cc: Qinglang Miao --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index 85f2c3564c96..074fb37ed49f 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -1020,11 +1020,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms) dpu_kms->catalog->caps->max_mixer_width * 2; dev->mode_config.max_height = 4096; - /* -* Support format modifiers for compression etc. -*/ - dev->mode_config.allow_fb_modifiers = true; - /* * _dpu_kms_drm_obj_init should create the DRM related objects * i.e. CRTCs, planes, encoders, connectors and so forth -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm/tegra: Don't set allow_fb_modifiers explicitly
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
It was slightly inconsistently though, since planes with only linear
modifier support haven't listed that explicitly. Fix that, and cc:
stable to allow userspace to rely on this. Again don't backport
further than where Paul's patch got added.
Cc: sta...@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/dc.c | 10 --
drivers/gpu/drm/tegra/drm.c | 2 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index c9385cfd0fc1..f9845a50f866 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -959,6 +959,11 @@ static const struct drm_plane_helper_funcs
tegra_cursor_plane_helper_funcs = {
.atomic_disable = tegra_cursor_atomic_disable,
};
+static const uint64_t linear_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
struct tegra_dc *dc)
{
@@ -987,7 +992,7 @@ static struct drm_plane
*tegra_dc_cursor_plane_create(struct drm_device *drm,
err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
&tegra_plane_funcs, formats,
- num_formats, NULL,
+ num_formats, linear_modifiers,
DRM_PLANE_TYPE_CURSOR, NULL);
if (err < 0) {
kfree(plane);
@@ -1106,7 +,8 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
&tegra_plane_funcs, formats,
- num_formats, NULL, type, NULL);
+ num_formats, linear_modifiers,
+ type, NULL);
if (err < 0) {
kfree(plane);
return ERR_PTR(err);
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 90709c38c993..136fe98f9459 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1125,8 +1125,6 @@ static int host1x_drm_probe(struct host1x_device *dev)
drm->mode_config.max_width = 4096;
drm->mode_config.max_height = 4096;
- drm->mode_config.allow_fb_modifiers = true;
-
drm->mode_config.normalize_zpos = true;
drm->mode_config.funcs = &tegra_drm_mode_config_funcs;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] dma-buf: Require VM_PFNMAP vma for mmap
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.
To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.
Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.
v2:
Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.
From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.
References:
https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/
Acked-by: Christian König
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..06cb1d2e9fdc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = {
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
+ int ret;
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/shmem-helper: Align to page size in dumb_create
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6d625cee7a6a..d5e6d4568f99 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -505,13 +505,13 @@ int drm_gem_shmem_dumb_create(struct drm_file *file,
struct drm_device *dev,
if (!args->pitch || !args->size) {
args->pitch = min_pitch;
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
} else {
/* ensure sane minimum values */
if (args->pitch < min_pitch)
args->pitch = min_pitch;
if (args->size < args->pitch * args->height)
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
}
shmem = drm_gem_shmem_create_with_handle(file, dev, args->size,
&args->handle);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/gvt: remove useless function
== Series Details == Series: drm/i915/gvt: remove useless function URL : https://patchwork.freedesktop.org/series/88996/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/12] drm/i915: Extend GEN renames to the rest of the driver
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Like was done for the display part that parted ways with INTEL_GEN(),
> replacing with DISPLAY_VER(), do a similar conversion for the rest of
> the driver.
>
> v1.1: Remove .ko that was incorrectly added as part of patch 11, making it
> very big and not going through the mailing list. Sorry for those in CC
> who received it.
>
> v2:
> - Add "drm/i915/display: rename display version macros" to rename
> macro and repurpose it: s/IS_DISPLAY_RANGE/IS_DISPLAY_VER/ and convert
> the current users of IS_DISPLAY_VER to use direct comparison
> - Group display patches to easily apply independently
I like the direction here. Even as the version checks diversify, we
manage to simplify and reduce the macros.
I think we're going to have to queueu this via a topic branch, and merge
that to both drm-intel-next and drm-intel-gt-next. The next time the
branches can sync up is just too far away at this point, and the
conflicts may be really nasty to solve later.
That does mean having to solve the conflict with 70bfb30743d5
("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") which is in din but not
dign. The topic branch would be based on:
$ git merge-base drm-intel/drm-intel-next drm-intel/drm-intel-gt-next
9c0fed84d5750e1eea6c664e073ffa2534a17743
There are two (crappy?) ideas to make that easier. 1) revert
70bfb30743d5 from din and add it to the topic branch instead, 2) don't
revert it but cherry-pick it to the topic branch also.
Cc: Joonas and Daniel for their input on this as well.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/19] drm/i915/gtt: map the PD up front
On Tue, Apr 13, 2021 at 11:29 AM Matthew Auld wrote: > > On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote: > > > > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld > > wrote: > > > > > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote: > > > > > > > > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Matthew Auld wrote: > > > > > We need to general our accessor for the page directories and tables > > > > > from > > > > > using the simple kmap_atomic to support local memory, and this setup > > > > > must be done on acquisition of the backing storage prior to entering > > > > > fence execution contexts. Here we replace the kmap with the object > > > > > maping code that for simple single page shmemfs object will return a > > > > > plain kmap, that is then kept for the lifetime of the page directory. > > > > > > > > > > v2: (Thomas) Rebase on dma_resv and obj->mm.lock removal. > > > > > > > > > > Signed-off-by: Matthew Auld > > > > > Signed-off-by: Chris Wilson > > > > > > > > So I wanted to understand what px stands for as an abbreviation, and dug > > > > all the way down to this: > > > > > > > > commit 567047be2a7ede082d29f45524c287b87bd75e53 > > > > Author: Mika Kuoppala > > > > Date: Thu Jun 25 18:35:12 2015 +0300 > > > > > > > > drm/i915/gtt: Use macros to access dma mapped pages > > > > > > > > I still have no idea what it means, I guess px = page. But I also > > > > committed this, so I guess can blame myself :-) > > > > > > > > But while digging I've stumbled over this here > > > > > > > > commit 6eebfe8a10a62139d681e2f1af1386252742278b > > > > Author: Chris Wilson > > > > Date: Fri Jul 12 08:58:18 2019 +0100 > > > > > > > > drm/i915/gtt: Use shallow dma pages for scratch > > > > > > > > > > > > And that's some serious wtf. Yes we've done some compile-time type > > > > casting automagic between i915_priv and dev in the past, and I think > > > > even > > > > that was bad taste. But it was justified with that we have these > > > > everywhere (especially in the mmio macros), and it would be a terrible > > > > flag day. > > > > > > > > But I'm not seeing any need for auto-casting for these pages here, and > > > > I'm > > > > not aware that we're doing this anywhere else in kernel code. There is > > > > some macro-trickery in lockdep annotations, but that relies on the > > > > lockdep > > > > map having the same struct member name in all lock types, and is not > > > > exposed to drivers at all. > > > > > > > > Am I missing something, or why do we have this compile-time type casting > > > > stuff going on in i915 page accessors? > > > > > > I think 'x' in the px family of macros/functions is meant in the > > > variable/polymorphic sense, so it can potentially be a pt, pd, etc > > > underneath. If you look at px_base() for example all it does is fish > > > out the base GEM object from the structure, using the > > > known-at-compile-time-type, which then lets us get at the dma address, > > > vaddr etc. > > > > Yeah, but that's not how things landed. px predates the magic > > polymorphism. I think the px just stands for page, or at least > > originally only stood for page. I'm not sure honestly. It seems to be > > just used for page directory type of things, but I haven't found that > > written down anywhere. > > > > > It does seem pretty magical, but seems ok to me, if it means less typing? > > > > That's the worst justification. Code is generally write once, read > > many times. Optimizing for writing at the cost of magic indirection is > > generally not the right tradeoff in the kernel, where any indirection > > could hide a major gotcha. In huge userspace applications fancy > > abstraction and polymorphism is often the right thing to do, but there > > you also have a real compiler with a real typesystem (generally at > > least) helping you out. Or it's yolo duct-taping with lots of tests, > > where the speed at which you can hack up something matters more than > > being able to read it quickly. > > > > We're typing C here. It is generally rather verbose, with type casting > > all done explicitly. > > Ok. So should we change this around for this patch? The px_ stuff is > already quite prevalent it seems, and the px_vaddr() is just one part > of it? Maybe just add pt_vaddr(), pd_vaddr() etc instead? Nah, that was just an orthogonal observation. The confusion with magic type-aware macros is preexisting and widespread, there's no point holding up dg1 code with that. But it is maybe something we should put on our cleanup list. Or at least have a better explanation for why exactly it is needed. Also note I'm not worried about the px stuff standing for pt/pd/whatever, it's the magic type casting property of these macros added with the 2nd patch I've mentioned above that looks rather questionable to me. Maybe as transition thing like we've done with i915_priv pointers, but not something that we should build on top for long term. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: remove useless function
== Series Details ==
Series: drm/i915/gvt: remove useless function
URL : https://patchwork.freedesktop.org/series/88996/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19920
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/index.html
Known issues
Here are the changes found in Patchwork_19920 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/fi-kbl-soraka/igt@amdgpu/amd_pr...@amd-to-i915.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: [DMESG-WARN][2] ([i915#1982] / [i915#262]) ->
[PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180
[i915#3278]: https://gitlab.freedesktop.org/drm/intel/issues/3278
Participating hosts (47 -> 42)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9963 -> Patchwork_19920
CI-20190529: 20190529
CI_DRM_9963: f71c7917b4b6d6c093f1e65e62acd3360d96e63a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6063: d3b7f74ce5df6fdea03e490b7c64f0c6bfe76f03 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19920: fb5616c78d3a64660d6fe01fcc23474b0aec6155 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fb5616c78d3a drm/i915/gvt: remove useless function
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/shmem-helper: Align to page size in dumb_create
Hi
Am 13.04.21 um 11:49 schrieb Daniel Vetter:
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
Drivers get it more wrong than right. I always felt that we should have
all this in generic code with a few parameters somewhere.
But makes sense.
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6d625cee7a6a..d5e6d4568f99 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -505,13 +505,13 @@ int drm_gem_shmem_dumb_create(struct drm_file *file,
struct drm_device *dev,
if (!args->pitch || !args->size) {
args->pitch = min_pitch;
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
} else {
/* ensure sane minimum values */
if (args->pitch < min_pitch)
args->pitch = min_pitch;
if (args->size < args->pitch * args->height)
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
}
shmem = drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] drm/i915: Fix glk display version regressions
On Mon, 12 Apr 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix a couple of regressions due to the glk display version 9->10
> change. I *think* all the ones that slipped through involved
> either DISPLAY_VER==9 or DISPLAY_VER<10 checks. These three
> regressions are the ones I found through a quick scan, but someone
> should probably go through the whole tree with a fine toothcomb
> in case we missed more cases.
>
> Also tossed in a couple of cleanups.
Ville, please hold on with merging this until we figure out how to merge
[1]. I don't want to create extra conflicts when they can be avoided.
BR,
Jani.
[1] http://lore.kernel.org/r/20210413051002.92589-1-lucas.demar...@intel.com
>
> Cc: Matt Roper
>
> Ville Syrjälä (5):
> drm/i915: Restore lost glk FBC 16bpp w/a
> drm/i915: Restore lost glk ccs w/a
> drm/i915: Disable LTTPR detection on GLK once again
> drm/i915: Don't use {skl,cnl}_hpd_pin() for bxt/glk
> drm/i915: Remove a few redundant glk checks
>
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/skl_universal_plane.c| 2 +-
> 5 files changed, 8 insertions(+), 7 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/tegra: Don't set allow_fb_modifiers explicitly
On Tue, Apr 13, 2021 at 11:49:01AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here.
>
> It was slightly inconsistently though, since planes with only linear
> modifier support haven't listed that explicitly. Fix that, and cc:
> stable to allow userspace to rely on this. Again don't backport
> further than where Paul's patch got added.
>
> Cc: sta...@vger.kernel.org # v5.1 +
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-te...@vger.kernel.org
> ---
> drivers/gpu/drm/tegra/dc.c | 10 --
> drivers/gpu/drm/tegra/drm.c | 2 --
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index c9385cfd0fc1..f9845a50f866 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -959,6 +959,11 @@ static const struct drm_plane_helper_funcs
> tegra_cursor_plane_helper_funcs = {
> .atomic_disable = tegra_cursor_atomic_disable,
> };
>
> +static const uint64_t linear_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> struct tegra_dc *dc)
> {
> @@ -987,7 +992,7 @@ static struct drm_plane
> *tegra_dc_cursor_plane_create(struct drm_device *drm,
>
> err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
> &tegra_plane_funcs, formats,
> -num_formats, NULL,
> +num_formats, linear_modifiers,
> DRM_PLANE_TYPE_CURSOR, NULL);
> if (err < 0) {
> kfree(plane);
> @@ -1106,7 +,8 @@ static struct drm_plane
> *tegra_dc_overlay_plane_create(struct drm_device *drm,
>
> err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
> &tegra_plane_funcs, formats,
> -num_formats, NULL, type, NULL);
> +num_formats, linear_modifiers,
> +type, NULL);
I think we can do better than linear_modifiers for overlay planes, but
given that this doesn't change existing behaviour, I'll do that in a
separate patch.
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Fix "mitigations" parsing if i915 is builtin
== Series Details == Series: drm/i915: Fix "mitigations" parsing if i915 is builtin URL : https://patchwork.freedesktop.org/series/88998/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH v2] drm/doc/rfc: i915 DG1 uAPI
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/rfc/i915_gem_lmem.h | 151
Documentation/gpu/rfc/i915_gem_lmem.rst | 119 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 274 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..6ae13209d7ef
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,151 @@
+/* The new query_id for struct drm_i915_query_item */
+#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
+
+/**
+ * enum drm_i915_gem_memory_class
+ */
+enum drm_i915_gem_memory_class {
+ /** @I915_MEMORY_CLASS_SYSTEM: system memory */
+ I915_MEMORY_CLASS_SYSTEM = 0,
+ /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
+ I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance
+ */
+struct drm_i915_gem_memory_class_instance {
+ /** @memory_class: see enum drm_i915_gem_memory_class */
+ __u16 memory_class;
+
+ /** @memory_instance: which instance */
+ __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info
+ *
+ * Describes one region as known to the driver.
+ */
+struct drm_i915_memory_region_info {
+ /** @region: class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @caps: MBZ */
+ __u64 caps;
+
+ /** @flags: MBZ */
+ __u64 flags;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+ __u64 unallocated_size;
+
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+};
+
+/**
+ * struct drm_i915_query_memory_regions
+ *
+ * Region info query enumerates all regions known to the driver by filling in
+ * an array of struct drm_i915_memory_region_info structures.
+ */
+struct drm_i915_query_memory_regions {
+ /** @num_regions: Number of supported regions */
+ __u32 num_regions;
+
+ /** @rsvd: MBZ */
+ __u32 rsvd[3];
+
+ /** @regions: Info about each supported region */
+ struct drm_i915_memory_region_info regions[];
+};
+
+#define DRM_I915_GEM_CREATE_EXT0xdeadbeaf
+#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext)
+
+/**
+ * struct drm_i915_gem_create_ext
+ */
+struct drm_i915_gem_create_ext {
+ /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*/
+ __u64 size;
+ /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+ __u32 handle;
+ /** @flags: MBZ */
+ __u32 flags;
+ /**
+* @extensions:
+* For I915_GEM_CREATE_EXT_SETPARAM extension usage see both:
+* struct drm_i915_gem_create_ext_setparam.
+* struct drm_i915_gem_object_param for the possible parameters.
+*/
+#define I915_GEM_CREATE_EXT_SETPARAM 0
+ __u64 extensions;
+};
+
+/**
+ * struct drm_i915_gem_object_param
+ */
+struct drm_i915_gem_object_param {
+ /** @handle: Object handle (0 for I915_GEM_CREATE_EXT_SETPARAM) */
+ __u32 handle;
+
+ /** @size: Data pointer size */
+ __u32 size;
+
+/*
+ * I915_OBJECT_PARAM:
+ *
+ * Select object namespace for the param.
+ */
+#define I915_OBJECT_PARAM (1ull<<32)
+
+/**
+ * @param: select the desired param.
+ *
+ * I915_OBJECT_PARAM_MEMORY_REGIONS:
+ *
+ * Set the data pointer with the desired set of placements in priority
+ * order(each entry must be unique and supported by the device), as an array of
+ * drm_i915_gem_memory_class_instance, or an equivalent layout of
class:instance
+ * pair encodings. See DRM_I915_QUERY_MEMORY_REGIONS for how to query the
+ * supported regions.
+ *
+ * In this case the data pointer size should be the number of
+ * drm_i915_gem_memory_class_instance elements in the placements array.
+ */
+#define I915_PARAM_MEMORY_REGIONS 0
+#define I915_OBJECT_PARAM_MEMORY_REGIONS (I915_OBJECT_PARAM | \
+ I915_PARAM_MEMORY_REGIONS)
+ __u64 param;
+
+ /** @data: Data value or pointer */
+ __u64 data;
+};
+
+/**
+ * struct drm_i915_gem_create_ext_setparam
+ */
+struct drm_i915_gem_create_ext_setparam {
+ /** @base: extension link */
+
Re: [Intel-gfx] [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done automatically as part of plane init, if drivers set the > modifier list correctly. Which is the case here. > > This one actually set it twice on top of what drm_plane_init does, so > double-redundant! That's not true. imx-dcss and imx-drm are two totally separate drivers. Maybe we should move imx-drm into its own ipuv3 directory one day to make this more clear. Change is still correct, though. Reviewed-by: Lucas Stach > Signed-off-by: Daniel Vetter > Cc: Philipp Zabel > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: linux-arm-ker...@lists.infradead.org > --- > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > index b549ce5e7607..37ae68a7fba5 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev > *kms) > config->min_height = 1; > config->max_width = 4096; > config->max_height = 4096; > - config->allow_fb_modifiers = true; > config->normalize_zpos = true; > > > > > config->funcs = &dcss_drm_mode_config_funcs; > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > b/drivers/gpu/drm/imx/imx-drm-core.c > index 2ded8e4f32d0..8be4edaec958 100644 > --- a/drivers/gpu/drm/imx/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > drm->mode_config.max_height = 4096; > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > - drm->mode_config.allow_fb_modifiers = true; > drm->mode_config.normalize_zpos = true; > > > > > ret = drmm_mode_config_init(drm); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
For a lot of the embedded display drivers that never had any out-of-
band tiling meta shared with the GPU part, the implied modifier is
actually DRM_FORMAT_MOD_LINEAR, so maybe that's where some of the
confusion about needing to specify the modifier list comes from.
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
This clarification looks good to me.
Reviewed-by: Lucas Stach
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 16 +++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..16a7e3e57f7f 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,11 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then
> every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR.
> */
>
>
>
>
>
>
>
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> format_modifier_count++;
> }
>
>
>
>
>
>
>
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
>
>
>
>
>
>
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their
> planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, 13 Apr 2021 11:49:03 +0200
Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 16 +++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..16a7e3e57f7f 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,11 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then
> every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR.
Ooh, that's even better. But isn't that changing the meaning of the
cap? Isn't the cap older than IN_FORMATS?
What about the opposite? Is it allowed to have even a single IN_FORMATS
if you don't have the cap?
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
What does this mean?
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their
> planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
Good.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
>* @allow_fb_modifiers:
>*
>* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
>*
>* IMPORTANT:
>*
Thanks,
pq
pgp7qUba0CMJp.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gvt: remove useless function
== Series Details == Series: drm/i915/gvt: remove useless function URL : https://patchwork.freedesktop.org/series/88996/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19920_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19920_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19920_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19920_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-suspend: - shard-apl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-apl2/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_19920_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-snb2/igt@gem_cre...@create-massive.html - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-kbl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][7] ([i915#3316]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-skl1/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] / [i915#3070]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb6/igt@gem_...@unwedge-stress.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-skl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-glk: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-glk9/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html - shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-p...@vecs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][20] -> [FAIL][21] ([i915#2849]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19920/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][22] ([i915#2389])
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix "mitigations" parsing if i915 is builtin
== Series Details ==
Series: drm/i915: Fix "mitigations" parsing if i915 is builtin
URL : https://patchwork.freedesktop.org/series/88998/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19921
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/index.html
Known issues
Here are the changes found in Patchwork_19921 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/fi-kbl-soraka/igt@amdgpu/amd_pr...@amd-to-i915.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: [DMESG-WARN][2] ([i915#1982] / [i915#262]) ->
[PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180
[i915#3278]: https://gitlab.freedesktop.org/drm/intel/issues/3278
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (47 -> 42)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9963 -> Patchwork_19921
CI-20190529: 20190529
CI_DRM_9963: f71c7917b4b6d6c093f1e65e62acd3360d96e63a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6063: d3b7f74ce5df6fdea03e490b7c64f0c6bfe76f03 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19921: 3966bf7f93e0943232055d56216b41318427066a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3966bf7f93e0 drm/i915: Fix "mitigations" parsing if i915 is builtin
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly
== Series Details ==
Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers
explicitly
URL : https://patchwork.freedesktop.org/series/88999/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
95d1b78648fe drm/arm: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:47: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
5a0febe6beff drm/arm/malidp: Always list modifiers
-:23: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
#23: FILE: drivers/gpu/drm/arm/malidp_planes.c:930:
+static const uint64_t linear_only_modifiers[] = {
-:41: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 1 checks, 21 lines checked
0e8191b69ca9 drm/exynos: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:37: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 7 lines checked
9e2aecf3367a drm/i915: Don't set allow_fb_modifiers explicitly
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#11:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:44: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
1bf4883a3d8f drm/imx: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:53: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
5136a63981d1 drm/msm/dpu1: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:42: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 11 lines checked
afa911ded79d drm/msm/mdp4: Fix modifier support enabling
-:41: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
#41: FILE: drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c:352:
+static const uint64_t supported_format_modifiers[] = {
-:58: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 1 checks, 28 lines checked
cdfd52445cfa drm/nouveau: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:38: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 7 lines checked
e2b8b541e594 drm/stm: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:38: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
d87b3d5a3254 drm/tegra: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 890880ddfdbe ("drm: Auto-set
allow_fb_modifiers when given modifiers at plane
[Intel-gfx] [PATCH v2 4/5] drm/connector: Add a helper to attach the colorspace property
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/drm_connector.c | 20 +++
.../gpu/drm/i915/display/intel_connector.c| 6 ++
include/drm/drm_connector.h | 1 +
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b13021b1b128..6a20b249e533 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2171,6 +2171,26 @@ int
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
}
EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+/**
+ * drm_connector_attach_colorspace_property - attach "Colorspace" property
+ * @connector: connector to attach the property on.
+ *
+ * This is used to allow the userspace to signal the output colorspace
+ * to the driver.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_colorspace_property(struct drm_connector *connector)
+{
+ struct drm_property *prop = connector->colorspace_property;
+
+ drm_object_attach_property(&connector->base, prop,
DRM_MODE_COLORIMETRY_DEFAULT);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
+
/**
* drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
* @old_state: old connector state to compare
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index d5ceb7bdc14b..9bed1ccecea0 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -282,14 +282,12 @@ void
intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
{
if (!drm_mode_create_hdmi_colorspace_property(connector))
- drm_object_attach_property(&connector->base,
- connector->colorspace_property, 0);
+ drm_connector_attach_colorspace_property(connector);
}
void
intel_attach_dp_colorspace_property(struct drm_connector *connector)
{
if (!drm_mode_create_dp_colorspace_property(connector))
- drm_object_attach_property(&connector->base,
- connector->colorspace_property, 0);
+ drm_connector_attach_colorspace_property(connector);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1f51d73ca715..714d1a01c065 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1671,6 +1671,7 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
u32 scaling_mode_mask);
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
+int drm_connector_attach_colorspace_property(struct drm_connector *connector);
int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
*connector);
bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state
*old_state,
struct drm_connector_state
*new_state);
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] drm/vc4: hdmi: Signal the proper colorimetry info in the infoframe
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a33fa1662588..a22e17788074 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -226,7 +226,8 @@ static int vc4_hdmi_connector_atomic_check(struct
drm_connector *connector,
if (!crtc)
return 0;
- if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
+ if (old_state->colorspace != new_state->colorspace ||
+ !drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
struct drm_crtc_state *crtc_state;
crtc_state = drm_atomic_get_crtc_state(state, crtc);
@@ -316,6 +317,11 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
if (ret)
return ret;
+ ret = drm_mode_create_hdmi_colorspace_property(connector);
+ if (ret)
+ return ret;
+
+ drm_connector_attach_colorspace_property(connector);
drm_connector_attach_tv_margin_properties(connector);
drm_connector_attach_max_bpc_property(connector, 8, 12);
@@ -424,7 +430,7 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
*encoder)
vc4_encoder->limited_rgb_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL);
-
+ drm_hdmi_avi_infoframe_colorspace(&frame.avi, cstate);
drm_hdmi_avi_infoframe_bars(&frame.avi, cstate);
vc4_hdmi_write_infoframe(encoder, &frame);
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/connector: Add helper to compare HDR metadata
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those drivers.
Reviewed-by: Harry Wentland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
- Added the tags
- Fix build breakage on amdgpu
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +--
drivers/gpu/drm/drm_connector.c | 28 +++
drivers/gpu/drm/i915/display/intel_atomic.c | 13 +
include/drm/drm_connector.h | 2 ++
5 files changed, 34 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1e22ce718010..ed1972fb531d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5967,25 +5967,6 @@ static int fill_hdr_info_packet(const struct
drm_connector_state *state,
return 0;
}
-static bool
-is_hdr_metadata_different(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
- struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
- struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
- if (old_blob != new_blob) {
- if (old_blob && new_blob &&
- old_blob->length == new_blob->length)
- return memcmp(old_blob->data, new_blob->data,
- old_blob->length);
-
- return true;
- }
-
- return false;
-}
-
static int
amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
struct drm_atomic_state *state)
@@ -6003,7 +5984,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
if (!crtc)
return 0;
- if (is_hdr_metadata_different(old_con_state, new_con_state)) {
+ if (!drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state)) {
struct dc_info_packet hdr_infopacket;
ret = fill_hdr_info_packet(new_con_state, &hdr_infopacket);
@@ -8357,7 +8338,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dm_old_crtc_state->abm_level;
hdr_changed =
- is_hdr_metadata_different(old_con_state, new_con_state);
+ !drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state);
if (!scaling_changed && !abm_changed && !hdr_changed)
continue;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f24bbb840dbf..f871e33c2fc9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2395,21 +2395,6 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
-static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
- struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
- struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
- if (!old_blob || !new_blob)
- return old_blob == new_blob;
-
- if (old_blob->length != new_blob->length)
- return false;
-
- return !memcmp(old_blob->data, new_blob->data, old_blob->length);
-}
-
static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
struct drm_atomic_state *state)
{
@@ -2423,7 +2408,7 @@ static int dw_hdmi_connector_atomic_check(struct
drm_connector *connector,
if (!crtc)
return 0;
- if (!hdr_metadata_equal(old_state, new_state)) {
+ if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a4aa2d87af35..b13021b1b128 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2171,6 +2171,34 @@ int
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
}
EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+/**
+ * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
+ * @old_state: old connector state to compare
+ * @new_state: new connector
[Intel-gfx] [PATCH v2 1/5] drm/connector: Create a helper to attach the hdr_output_metadata property
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Reviewed-by: Harry Wentland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
- Added the tags
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +--
drivers/gpu/drm/drm_connector.c | 21 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_connector.h | 1 +
5 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 55e39b462a5e..1e22ce718010 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7078,9 +7078,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
- drm_object_attach_property(
- &aconnector->base.base,
- dm->ddev->mode_config.hdr_output_metadata_property, 0);
+
drm_connector_attach_hdr_output_metadata_property(&aconnector->base);
if (!aconnector->mst_port)
drm_connector_attach_vrr_capable_property(&aconnector->base);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..f24bbb840dbf 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2492,8 +2492,7 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
drm_connector_attach_max_bpc_property(connector, 8, 16);
if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe)
- drm_object_attach_property(&connector->base,
-
connector->dev->mode_config.hdr_output_metadata_property, 0);
+ drm_connector_attach_hdr_output_metadata_property(connector);
drm_connector_attach_encoder(connector, hdmi->bridge.encoder);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..a4aa2d87af35 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2150,6 +2150,27 @@ int drm_connector_attach_max_bpc_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
+/**
+ * drm_connector_attach_hdr_output_metadata_property - attach
"HDR_OUTPUT_METADA" property
+ * @connector: connector to attach the property on.
+ *
+ * This is used to allow the userspace to send HDR Metadata to the
+ * driver.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
*connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop =
dev->mode_config.hdr_output_metadata_property;
+
+ drm_object_attach_property(&connector->base, prop, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+
/**
* drm_connector_set_vrr_capable_property - sets the variable refresh rate
* capable property for a connector
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 95919d325b0b..f2f1b025e6ba 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2965,8 +2965,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
drm_connector_attach_content_type_property(connector);
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
- drm_object_attach_property(&connector->base,
-
connector->dev->mode_config.hdr_output_metadata_property, 0);
+ drm_connector_attach_hdr_output_metadata_property(connector);
if (!HAS_GMCH(dev_priv))
drm_connector_attach_max_bpc_property(connector, 8, 12);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..32172dab8427 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1671,6 +1671,7 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
u32 scaling_mode_mask);
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
+int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
*connector);
int drm_mode_create_
[Intel-gfx] [PATCH v2 3/5] drm/vc4: Add HDR metadata property to the VC5 HDMI connectors
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 53 ++
drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1fda574579af..a33fa1662588 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -214,6 +214,31 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
+static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *old_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_connector_state *new_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ struct drm_crtc *crtc = new_state->crtc;
+
+ if (!crtc)
+ return 0;
+
+ if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ crtc_state->mode_changed = true;
+ }
+
+ return 0;
+}
+
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
struct vc4_hdmi_connector_state *old_state =
@@ -263,6 +288,7 @@ static const struct drm_connector_funcs
vc4_hdmi_connector_funcs = {
static const struct drm_connector_helper_funcs vc4_hdmi_connector_helper_funcs
= {
.get_modes = vc4_hdmi_connector_get_modes,
+ .atomic_check = vc4_hdmi_connector_atomic_check,
};
static int vc4_hdmi_connector_init(struct drm_device *dev,
@@ -299,6 +325,9 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
+ if (vc4_hdmi->variant->supports_hdr)
+ drm_connector_attach_hdr_output_metadata_property(connector);
+
drm_connector_attach_encoder(connector, encoder);
return 0;
@@ -432,6 +461,25 @@ static void vc4_hdmi_set_audio_infoframe(struct
drm_encoder *encoder)
vc4_hdmi_write_infoframe(encoder, &frame);
}
+static void vc4_hdmi_set_hdr_infoframe(struct drm_encoder *encoder)
+{
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_connector *connector = &vc4_hdmi->connector;
+ struct drm_connector_state *conn_state = connector->state;
+ union hdmi_infoframe frame;
+
+ if (!vc4_hdmi->variant->supports_hdr)
+ return;
+
+ if (!conn_state->hdr_output_metadata)
+ return;
+
+ if (drm_hdmi_infoframe_set_hdr_metadata(&frame.drm, conn_state))
+ return;
+
+ vc4_hdmi_write_infoframe(encoder, &frame);
+}
+
static void vc4_hdmi_set_infoframes(struct drm_encoder *encoder)
{
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
@@ -444,6 +492,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
*/
if (vc4_hdmi->audio.streaming)
vc4_hdmi_set_audio_infoframe(encoder);
+
+ vc4_hdmi_set_hdr_infoframe(encoder);
}
static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
@@ -2102,6 +2152,7 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
.phy_rng_enable = vc4_hdmi_phy_rng_enable,
.phy_rng_disable= vc4_hdmi_phy_rng_disable,
.channel_map= vc4_hdmi_channel_map,
+ .supports_hdr = false,
};
static const struct vc4_hdmi_variant bcm2711_hdmi0_variant = {
@@ -2129,6 +2180,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.phy_rng_enable = vc5_hdmi_phy_rng_enable,
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
+ .supports_hdr = true,
};
static const struct vc4_hdmi_variant bcm2711_hdmi1_variant = {
@@ -2156,6 +2208,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi1_variant = {
.phy_rng_enable = vc5_hdmi_phy_rng_enable,
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
+ .supports_hdr = true,
};
static const struct of_device_id vc4_hdmi_dt_match[] = {
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 3cebd1fd00fc..060bcaefbeb5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -99,6 +99,9 @@ struct vc4_hdmi_variant {
/* Callback to get channel map */
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly
== Series Details == Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly URL : https://patchwork.freedesktop.org/series/88999/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly
== Series Details == Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly URL : https://patchwork.freedesktop.org/series/88999/ State : success == Summary == CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19922 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/index.html Known issues Here are the changes found in Patchwork_19922 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/fi-kbl-soraka/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [PASS][2] -> [INCOMPLETE][3] ([i915#2782] / [i915#2940]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][4] -> [FAIL][5] ([i915#1372]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@runner@aborted: - fi-bsw-kefka: NOTRUN -> [FAIL][6] ([i915#1436] / [i915#2722]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/fi-bsw-kefka/igt@run...@aborted.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-kbl-soraka: [DMESG-WARN][7] ([i915#1982] / [i915#262]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 Participating hosts (47 -> 42) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9963 -> Patchwork_19922 CI-20190529: 20190529 CI_DRM_9963: f71c7917b4b6d6c093f1e65e62acd3360d96e63a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6063: d3b7f74ce5df6fdea03e490b7c64f0c6bfe76f03 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19922: 0fa454884dab0becb9ca4179dc809cf6952fb3cf @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0fa454884dab drm/modifiers: Enforce consistency between the cap an IN_FORMATS cd7d120c5b56 drm/vc4: Don't set allow_fb_modifiers explicitly d87b3d5a3254 drm/tegra: Don't set allow_fb_modifiers explicitly e2b8b541e594 drm/stm: Don't set allow_fb_modifiers explicitly cdfd52445cfa drm/nouveau: Don't set allow_fb_modifiers explicitly afa911ded79d drm/msm/mdp4: Fix modifier support enabling 5136a63981d1 drm/msm/dpu1: Don't set allow_fb_modifiers explicitly 1bf4883a3d8f drm/imx: Don't set allow_fb_modifiers explicitly 9e2aecf3367a drm/i915: Don't set allow_fb_modifiers explicitly 0e8191b69ca9 drm/exynos: Don't set allow_fb_modifiers explicitly 5a0febe6beff drm/arm/malidp: Always list modifiers 95d1b78648fe drm/arm: Don't set allow_fb_modifiers explicitly == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap
== Series Details == Series: series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap URL : https://patchwork.freedesktop.org/series/89003/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8ed494629919 dma-buf: Require VM_PFNMAP vma for mmap -:34: WARNING:TYPO_SPELLING: 'entires' may be misspelled - perhaps 'entries'? #34: >From auditing the various functions to insert pfn pte entires ^^^ -:39: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #39: References: https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/ -:97: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 3 warnings, 0 checks, 39 lines checked 5961f2709211 drm/vgem: use shmem helpers -:424: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 381 lines checked 1f0d8b68a894 drm/shmem-helper: Align to page size in dumb_create -:32: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 15 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap
== Series Details == Series: series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap URL : https://patchwork.freedesktop.org/series/89003/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap
== Series Details == Series: series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap URL : https://patchwork.freedesktop.org/series/89003/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19923 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19923 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19923, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19923: ### IGT changes ### Possible regressions * igt@prime_vgem@basic-fence-mmap: - fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bwr-2160/igt@prime_v...@basic-fence-mmap.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bwr-2160/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-fence-read: - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html - fi-ilk-650: [PASS][5] -> [INCOMPLETE][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-ilk-650/igt@prime_v...@basic-fence-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-ilk-650/igt@prime_v...@basic-fence-read.html - fi-elk-e7500: [PASS][7] -> [INCOMPLETE][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-elk-e7500/igt@prime_v...@basic-fence-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-elk-e7500/igt@prime_v...@basic-fence-read.html - fi-bsw-nick:[PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bsw-nick/igt@prime_v...@basic-fence-read.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bsw-nick/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - fi-ilk-650: [PASS][11] -> [FAIL][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-ilk-650/igt@prime_v...@basic-gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-ilk-650/igt@prime_v...@basic-gtt.html - fi-elk-e7500: [PASS][13] -> [FAIL][14] +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-elk-e7500/igt@prime_v...@basic-gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-elk-e7500/igt@prime_v...@basic-gtt.html * igt@prime_vgem@basic-read: - fi-bwr-2160:[PASS][15] -> [FAIL][16] +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bwr-2160/igt@prime_v...@basic-read.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bwr-2160/igt@prime_v...@basic-read.html - fi-bsw-nick:[PASS][17] -> [FAIL][18] +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bsw-nick/igt@prime_v...@basic-read.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bsw-nick/igt@prime_v...@basic-read.html - fi-bsw-kefka: [PASS][19] -> [FAIL][20] +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-bsw-kefka/igt@prime_v...@basic-read.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bsw-kefka/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-write: - fi-pnv-d510:[PASS][21] -> [FAIL][22] +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-pnv-d510/igt@prime_v...@basic-write.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-pnv-d510/igt@prime_v...@basic-write.html * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][23] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-ilk-650/igt@run...@aborted.html - fi-kbl-x1275: NOTRUN -> [FAIL][24] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-kbl-x1275/igt@run...@aborted.html - fi-bsw-kefka: NOTRUN -> [FAIL][25] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-bsw-kefka/igt@run...@aborted.html - fi-cfl-8700k: NOTRUN -> [FAIL][26] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/fi-cfl-8700k/igt@run...@aborted.html - fi-tgl-y: NOTRUN -> [FAIL][27] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19923/f
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/doc/rfc: i915 DG1 uAPI (rev2)
== Series Details == Series: drm/doc/rfc: i915 DG1 uAPI (rev2) URL : https://patchwork.freedesktop.org/series/88958/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8258e1583be6 drm/doc/rfc: i915 DG1 uAPI -:19: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #19: new file mode 100644 -:24: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #24: FILE: Documentation/gpu/rfc/i915_gem_lmem.h:1: +/* The new query_id for struct drm_i915_query_item */ -:94: WARNING:LONG_LINE: line length of 124 exceeds 100 columns #94: FILE: Documentation/gpu/rfc/i915_gem_lmem.h:71: +#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext) -:139: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #139: FILE: Documentation/gpu/rfc/i915_gem_lmem.h:116: +#define I915_OBJECT_PARAM (1ull<<32) ^ -:174: CHECK:LINE_SPACING: Please don't use multiple blank lines #174: FILE: Documentation/gpu/rfc/i915_gem_lmem.h:151: + + -:181: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #181: FILE: Documentation/gpu/rfc/i915_gem_lmem.rst:1: += total: 0 errors, 4 warnings, 2 checks, 277 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/doc/rfc: i915 DG1 uAPI (rev2)
== Series Details == Series: drm/doc/rfc: i915 DG1 uAPI (rev2) URL : https://patchwork.freedesktop.org/series/88958/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/5] drm/connector: Create a helper to attach the hdr_output_metadata property
== Series Details == Series: series starting with [v2,1/5] drm/connector: Create a helper to attach the hdr_output_metadata property URL : https://patchwork.freedesktop.org/series/89008/ State : failure == Summary == Applying: drm/connector: Create a helper to attach the hdr_output_metadata property Using index info to reconstruct a base tree... M drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c M drivers/gpu/drm/i915/display/intel_hdmi.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_hdmi.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_hdmi.c Auto-merging drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/connector: Create a helper to attach the hdr_output_metadata property When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc/rfc: i915 DG1 uAPI (rev2)
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/88958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19924
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/index.html
Known issues
Here are the changes found in Patchwork_19924 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/fi-kbl-soraka/igt@amdgpu/amd_pr...@amd-to-i915.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: [DMESG-WARN][2] ([i915#1982] / [i915#262]) ->
[PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
Participating hosts (47 -> 41)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-icl-y
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9963 -> Patchwork_19924
CI-20190529: 20190529
CI_DRM_9963: f71c7917b4b6d6c093f1e65e62acd3360d96e63a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6063: d3b7f74ce5df6fdea03e490b7c64f0c6bfe76f03 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19924: 8258e1583be677eeca9d4ba20748df2f63f0c0a1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8258e1583be6 drm/doc/rfc: i915 DG1 uAPI
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix "mitigations" parsing if i915 is builtin
== Series Details == Series: drm/i915: Fix "mitigations" parsing if i915 is builtin URL : https://patchwork.freedesktop.org/series/88998/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19921_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19921_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19921_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19921_full: ### IGT changes ### Possible regressions * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-skl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html Known issues Here are the changes found in Patchwork_19921_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-snb2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@hostile: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-snb2/igt@gem_ctx_persiste...@hostile.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][5] ([i915#3316]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-skl9/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] / [i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb6/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-iclb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_big@single: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-skl8/igt@gem_exec_...@single.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-skl7/igt@gem_exec_...@single.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-skl9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-glk: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-glk7/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-p...@vecs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19921/shard-iclb6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#2849]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [22]: https://intel-gf
Re: [Intel-gfx] [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > Since > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > Author: Paul Kocialkowski > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > > > this is done automatically as part of plane init, if drivers set the > > modifier list correctly. Which is the case here. > > > > This one actually set it twice on top of what drm_plane_init does, so > > double-redundant! > > That's not true. imx-dcss and imx-drm are two totally separate drivers. > Maybe we should move imx-drm into its own ipuv3 directory one day to > make this more clear. Change is still correct, though. Hm I greeped for drm_universal_plane_init and didn't find anythinf for the imx main driver ... where are planes set up for that? Need to review that they have the modifiers listed in all cases. -Daniel > > Reviewed-by: Lucas Stach > > > Signed-off-by: Daniel Vetter > > Cc: Philipp Zabel > > Cc: Shawn Guo > > Cc: Sascha Hauer > > Cc: Pengutronix Kernel Team > > Cc: Fabio Estevam > > Cc: NXP Linux Team > > Cc: linux-arm-ker...@lists.infradead.org > > --- > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > > 2 files changed, 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > index b549ce5e7607..37ae68a7fba5 100644 > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev > > *kms) > > config->min_height = 1; > > config->max_width = 4096; > > config->max_height = 4096; > > - config->allow_fb_modifiers = true; > > config->normalize_zpos = true; > > > > > > > > > > config->funcs = &dcss_drm_mode_config_funcs; > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > b/drivers/gpu/drm/imx/imx-drm-core.c > > index 2ded8e4f32d0..8be4edaec958 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > > drm->mode_config.max_height = 4096; > > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > > - drm->mode_config.allow_fb_modifiers = true; > > drm->mode_config.normalize_zpos = true; > > > > > > > > > > ret = drmm_mode_config_init(drm); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> On Tue, 13 Apr 2021 11:49:03 +0200
> Daniel Vetter wrote:
>
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when they meant to say that only linear modifier is
> > allowed, but some also meant that only implied modifiers are
> > acceptable (because actually none of the planes registered supported
> > modifiers).
> >
> > Now that this is all done consistently across all drivers, document
> > the rules and enforce it in the drm core.
> >
> > Cc: Pekka Paalanen
> > Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_plane.c | 16 +++-
> > include/drm/drm_mode_config.h | 2 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 0dd43882fe7c..16a7e3e57f7f 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -128,6 +128,11 @@
> > * pairs supported by this plane. The blob is a struct
> > * drm_format_modifier_blob. Without this property the plane doesn't
> > * support buffers with modifiers. Userspace cannot change this
> > property.
> > + *
> > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > + * capability for general modifier support. If this flag is set then
> > every
> > + * plane will have the IN_FORMATS property, even when it only supports
> > + * DRM_FORMAT_MOD_LINEAR.
>
> Ooh, that's even better. But isn't that changing the meaning of the
> cap? Isn't the cap older than IN_FORMATS?
Hm indeed. But also how exactly are you going to user modifiers without
IN_FORMATS ... it's a bit hard. I think this is all because we've enabled
modifiers piece-by-piece and never across the entire thing (e.g. with
compositor and protocols), so the missing pieces only became apparent
later on.
I'm not sure whether compositors really want to support this, I guess
worst case we could disable the cap on these old kernels.
> What about the opposite? Is it allowed to have even a single IN_FORMATS
> if you don't have the cap?
That direction is enforced since 5.1, because some drivers screwed it up
and confusion in userspace ensued.
Should I add a bug that on kernels older than 5.1 the situation is more
murky and there's lots of bugs?
>
> > */
> >
> > static unsigned int drm_num_planes(struct drm_device *dev)
> > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > drm_device *dev,
> > format_modifier_count++;
> > }
> >
> > - if (format_modifier_count)
> > + /* autoset the cap and check for consistency across all planes */
> > + if (format_modifier_count) {
> > + WARN_ON(!config->allow_fb_modifiers &&
> > + !list_empty(&config->plane_list));
>
> What does this mean?
If allow_fb_modifiers isn't set yet (we do that in the line below) and we
are _not_ the first plane that gets added to the driver (that's done
towards the end of the function) then that means there's already a plane
registered without modifiers and hence IN_FORMAT. Which we then warn
about.
>
> > config->allow_fb_modifiers = true;
> > + } else {
> > + WARN_ON(config->allow_fb_modifiers);
This warning here checks the other case of an earlier plane with
modifiers, but the one we're adding now doesn't have them.
-Daniel
> > + }
> >
> > plane->modifier_count = format_modifier_count;
> > plane->modifiers = kmalloc_array(format_modifier_count,
> > @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> > *dev,
> > * drm_universal_plane_init() to let the DRM managed resource
> > infrastructure
> > * take care of cleanup and deallocation.
> > *
> > + * Drivers supporting modifiers must set @format_modifiers on all their
> > planes,
> > + * even those that only support DRM_FORMAT_MOD_LINEAR.
>
> Good.
>
> > + *
> > * Returns:
> > * Zero on success, error code on failure.
> > */
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index ab424ddd7665..1ddf7783fdf7 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > * @allow_fb_modifiers:
> > *
> > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > +* Note that drivers should not set this directly, it is automatically
> > +* set in drm_universal_plane_init().
> > *
> > * IMPORTANT:
> > *
>
> Thanks,
> pq
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freed
Re: [Intel-gfx] [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter: > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > > Since > > > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > > Author: Paul Kocialkowski > > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > > > > > this is done automatically as part of plane init, if drivers set the > > > modifier list correctly. Which is the case here. > > > > > > This one actually set it twice on top of what drm_plane_init does, so > > > double-redundant! > > > > That's not true. imx-dcss and imx-drm are two totally separate drivers. > > Maybe we should move imx-drm into its own ipuv3 directory one day to > > make this more clear. Change is still correct, though. > > Hm I greeped for drm_universal_plane_init and didn't find anythinf for the > imx main driver ... where are planes set up for that? Need to review that > they have the modifiers listed in all cases. That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always set on plane init. Regards, Lucas > > > > > Reviewed-by: Lucas Stach > > > > > Signed-off-by: Daniel Vetter > > > Cc: Philipp Zabel > > > Cc: Shawn Guo > > > Cc: Sascha Hauer > > > Cc: Pengutronix Kernel Team > > > Cc: Fabio Estevam > > > Cc: NXP Linux Team > > > Cc: linux-arm-ker...@lists.infradead.org > > > --- > > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > > > 2 files changed, 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > index b549ce5e7607..37ae68a7fba5 100644 > > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct > > > dcss_kms_dev *kms) > > > config->min_height = 1; > > > config->max_width = 4096; > > > config->max_height = 4096; > > > - config->allow_fb_modifiers = true; > > > config->normalize_zpos = true; > > > > > > > > > > > > > > > config->funcs = &dcss_drm_mode_config_funcs; > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > b/drivers/gpu/drm/imx/imx-drm-core.c > > > index 2ded8e4f32d0..8be4edaec958 100644 > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > > > drm->mode_config.max_height = 4096; > > > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > > > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > > > - drm->mode_config.allow_fb_modifiers = true; > > > drm->mode_config.normalize_zpos = true; > > > > > > > > > > > > > > > ret = drmm_mode_config_init(drm); > > > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 01:54:00PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when they meant to say that only linear modifier is
> > allowed, but some also meant that only implied modifiers are
> > acceptable (because actually none of the planes registered supported
> > modifiers).
>
> For a lot of the embedded display drivers that never had any out-of-
> band tiling meta shared with the GPU part, the implied modifier is
> actually DRM_FORMAT_MOD_LINEAR, so maybe that's where some of the
> confusion about needing to specify the modifier list comes from.
Yeah that entire discussion last few days is why I wanted to audit all the
drivers and make sure that going forward we're more explicit&consistent
with all this. There's huge confusion around implied modifier vs "no
IN_FORMATS blob property" and what that exactly means.
-Daniel
> > Now that this is all done consistently across all drivers, document
> > the rules and enforce it in the drm core.
>
> This clarification looks good to me.
>
> Reviewed-by: Lucas Stach
>
> > Cc: Pekka Paalanen
> > Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_plane.c | 16 +++-
> > include/drm/drm_mode_config.h | 2 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 0dd43882fe7c..16a7e3e57f7f 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -128,6 +128,11 @@
> > * pairs supported by this plane. The blob is a struct
> > * drm_format_modifier_blob. Without this property the plane doesn't
> > * support buffers with modifiers. Userspace cannot change this
> > property.
> > + *
> > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > + * capability for general modifier support. If this flag is set then
> > every
> > + * plane will have the IN_FORMATS property, even when it only supports
> > + * DRM_FORMAT_MOD_LINEAR.
> > */
> >
> >
> >
> >
> >
> >
> >
> >
> > static unsigned int drm_num_planes(struct drm_device *dev)
> > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > drm_device *dev,
> > format_modifier_count++;
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > - if (format_modifier_count)
> > + /* autoset the cap and check for consistency across all planes */
> > + if (format_modifier_count) {
> > + WARN_ON(!config->allow_fb_modifiers &&
> > + !list_empty(&config->plane_list));
> > config->allow_fb_modifiers = true;
> > + } else {
> > + WARN_ON(config->allow_fb_modifiers);
> > + }
> >
> >
> >
> >
> >
> >
> >
> >
> > plane->modifier_count = format_modifier_count;
> > plane->modifiers = kmalloc_array(format_modifier_count,
> > @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct drm_device
> > *dev,
> > * drm_universal_plane_init() to let the DRM managed resource
> > infrastructure
> > * take care of cleanup and deallocation.
> > *
> > + * Drivers supporting modifiers must set @format_modifiers on all their
> > planes,
> > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> > + *
> > * Returns:
> > * Zero on success, error code on failure.
> > */
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index ab424ddd7665..1ddf7783fdf7 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > * @allow_fb_modifiers:
> > *
> > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > +* Note that drivers should not set this directly, it is automatically
> > +* set in drm_universal_plane_init().
> > *
> > * IMPORTANT:
> > *
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with inconsistencies
> > > here, and some drivers screwed this up a bit. Most just ommitted the
> > > format list when they meant to say that only linear modifier is
> > > allowed, but some also meant that only implied modifiers are
> > > acceptable (because actually none of the planes registered supported
> > > modifiers).
> > >
> > > Now that this is all done consistently across all drivers, document
> > > the rules and enforce it in the drm core.
> > >
> > > Cc: Pekka Paalanen
> > > Signed-off-by: Daniel Vetter
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Thomas Zimmermann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_plane.c | 16 +++-
> > > include/drm/drm_mode_config.h | 2 ++
> > > 2 files changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index 0dd43882fe7c..16a7e3e57f7f 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -128,6 +128,11 @@
> > > * pairs supported by this plane. The blob is a struct
> > > * drm_format_modifier_blob. Without this property the plane doesn't
> > > * support buffers with modifiers. Userspace cannot change this
> > > property.
> > > + *
> > > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > > + * capability for general modifier support. If this flag is set then
> > > every
> > > + * plane will have the IN_FORMATS property, even when it only
> > > supports
> > > + * DRM_FORMAT_MOD_LINEAR.
> >
> > Ooh, that's even better. But isn't that changing the meaning of the
> > cap? Isn't the cap older than IN_FORMATS?
>
> Hm indeed. But also how exactly are you going to user modifiers without
> IN_FORMATS ... it's a bit hard. I think this is all because we've enabled
> modifiers piece-by-piece and never across the entire thing (e.g. with
> compositor and protocols), so the missing pieces only became apparent
> later on.
Ok I worked git log -Gallow_fb_modifiers and there's 3 drivers which
enabled modifiers before IN_FORMATS was merged:
- i915
- msm/mdp4 (for the tiled NV12 format thing)
- tegra
> I'm not sure whether compositors really want to support this, I guess
> worst case we could disable the cap on these old kernels.
>
> > What about the opposite? Is it allowed to have even a single IN_FORMATS
> > if you don't have the cap?
>
> That direction is enforced since 5.1, because some drivers screwed it up
> and confusion in userspace ensued.
>
> Should I add a bug that on kernels older than 5.1 the situation is more
> murky and there's lots of bugs?
I guess we should recommend to userspace that if they spot an
inconsistency between IN_FORMATS across planes and the cap then maybe they
want to disable modifier support because it might be all kinds of broken?
-Daniel
>
> >
> > > */
> > >
> > > static unsigned int drm_num_planes(struct drm_device *dev)
> > > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > > drm_device *dev,
> > > format_modifier_count++;
> > > }
> > >
> > > - if (format_modifier_count)
> > > + /* autoset the cap and check for consistency across all planes */
> > > + if (format_modifier_count) {
> > > + WARN_ON(!config->allow_fb_modifiers &&
> > > + !list_empty(&config->plane_list));
> >
> > What does this mean?
>
> If allow_fb_modifiers isn't set yet (we do that in the line below) and we
> are _not_ the first plane that gets added to the driver (that's done
> towards the end of the function) then that means there's already a plane
> registered without modifiers and hence IN_FORMAT. Which we then warn
> about.
>
> >
> > > config->allow_fb_modifiers = true;
> > > + } else {
> > > + WARN_ON(config->allow_fb_modifiers);
>
> This warning here checks the other case of an earlier plane with
> modifiers, but the one we're adding now doesn't have them.
> -Daniel
>
> > > + }
> > >
> > > plane->modifier_count = format_modifier_count;
> > > plane->modifiers = kmalloc_array(format_modifier_count,
> > > @@ -360,6 +371,9 @@ static int __drm_universal_plane_init(struct
> > > drm_device *dev,
> > > * drm_universal_plane_init() to let the DRM managed resource
> > > infrastructure
> > > * take care of cleanup and deallocation.
> > > *
> > > + * Drivers supporting modifiers must set @format_modifiers on all their
> > > planes,
> > > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> >
> > Good.
> >
> > > + *
> > > * Returns:
> > > * Zero on success, error code on failure.
> > > */
> > > diff --git a/include/drm/drm_mode_config.h b/include/drm
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly
== Series Details == Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers explicitly URL : https://patchwork.freedesktop.org/series/88999/ State : success == Summary == CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19922_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19922_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-snb5/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][3] ([i915#3316]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-skl7/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][4] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-skl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html - shard-glk: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-glk8/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-glk9/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-p...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-iclb6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-skl: NOTRUN -> [FAIL][15] ([i915#2389]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-skl8/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-skl: [PASS][16] -> [FAIL][17] ([i915#307]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-skl4/igt@gem_mmap_...@cpuset-medium-copy-xy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-skl5/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-snb2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271]) +45 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-kbl1/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-tglb: NOTRUN -> [SKIP][20] ([i915#3297]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-tglb2/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([i915#1436] / [i915#716]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-skl7/igt@gen9_exec_pa...@allowed-single.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19922/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@batch-invalid-length: - shard-snb: NOTRUN -> [SKIP][23]
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/doc/rfc: i915 DG1 uAPI (rev2)
== Series Details == Series: drm/doc/rfc: i915 DG1 uAPI (rev2) URL : https://patchwork.freedesktop.org/series/88958/ State : success == Summary == CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19924_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19924_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-kbl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][3] ([i915#3316]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-skl6/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#2481] / [i915#3070]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb6/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-iclb5/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][6] ([i915#3354]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-skl6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-glk: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-glk6/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-p...@vecs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-iclb5/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][19] ([i915#2389]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-apl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html - shard-skl: NOTRUN -> [FAIL][20] ([i915#2389]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-skl4/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#198]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-skl10/igt@gem_exec_susp...@basic-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-skl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][23] -> [SKIP][24] ([i915#2190]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb3/igt@gem_huc_c...@huc-copy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19924/shard-tglb6/igt@gem_huc_c...@huc-copy
Re: [Intel-gfx] [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter wrote: > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver Prepend an ampersand like so and a hyperlink will be rendered: Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: remove strap checks from gen 9
On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
> Direction on gen9+ was to stop reading the straps and only rely on the
> VBT for marking the port presence. This happened while dealing with
> WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
> normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
> skl straps").
>
> For gen 10 it's hard to say if this will work or not since I can't test
> it, so leave it with the same behavior as before.
>
> For PCH_TGP we should still rely on the VBT to make ports E and F not
> available.
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 36 ++--
> 1 file changed, 11 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d62ce9c87748..5a03cbba0280 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10883,34 +10883,25 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_ddi_init(dev_priv, PORT_B);
> intel_ddi_init(dev_priv, PORT_C);
> vlv_dsi_init(dev_priv);
> + } else if (DISPLAY_VER(dev_priv) == 9) {
Should be >=10 I presume? Or did we want ot handle cnl along with
icl perhaps? Doesn't really matter I suppose, but it's surely
going to consfuse the me the next time I read this.
> + intel_ddi_init(dev_priv, PORT_A);
> + intel_ddi_init(dev_priv, PORT_B);
> + intel_ddi_init(dev_priv, PORT_C);
> + intel_ddi_init(dev_priv, PORT_D);
> + intel_ddi_init(dev_priv, PORT_E);
> + intel_ddi_init(dev_priv, PORT_F);
DDI F isn't a thing on skl/derivatives, so I'd probably skip it on
those. Could just use IS_CNL_WITH_PORT_F() to match the looks of
the icl stuff.
> } else if (HAS_DDI(dev_priv)) {
> - int found;
> + u32 found;
>
> if (intel_ddi_crt_present(dev_priv))
> intel_crt_init(dev_priv);
>
> - /*
> - * Haswell uses DDI functions to detect digital outputs.
> - * On SKL pre-D0 the strap isn't connected. Later SKUs may or
> - * may not have it - it was supposed to be fixed by the same
> - * time we stopped using straps. Assume it's there.
> - */
> + /* Haswell uses DDI functions to detect digital outputs. */
> found = intel_de_read(dev_priv, DDI_BUF_CTL(PORT_A)) &
> DDI_INIT_DISPLAY_DETECTED;
> - /* WaIgnoreDDIAStrap: skl */
> - if (found || IS_DISPLAY_VER(dev_priv, 9))
> + if (found)
> intel_ddi_init(dev_priv, PORT_A);
>
> - /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
> - * register */
> - if (HAS_PCH_TGP(dev_priv)) {
> - /* W/A due to lack of STRAP config on TGP PCH*/
> - found = (SFUSE_STRAP_DDIB_DETECTED |
> - SFUSE_STRAP_DDIC_DETECTED |
> - SFUSE_STRAP_DDID_DETECTED);
> - } else {
> - found = intel_de_read(dev_priv, SFUSE_STRAP);
> - }
> -
> + found = intel_de_read(dev_priv, SFUSE_STRAP);
> if (found & SFUSE_STRAP_DDIB_DETECTED)
> intel_ddi_init(dev_priv, PORT_B);
> if (found & SFUSE_STRAP_DDIC_DETECTED)
> @@ -10919,11 +10910,6 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_ddi_init(dev_priv, PORT_D);
> if (found & SFUSE_STRAP_DDIF_DETECTED)
> intel_ddi_init(dev_priv, PORT_F);
> - /*
> - * On SKL we don't have a way to detect DDI-E so we rely on VBT.
> - */
> - if (IS_DISPLAY_VER(dev_priv, 9)
> - intel_ddi_init(dev_priv, PORT_E);
> } else if (HAS_PCH_SPLIT(dev_priv)) {
> int found;
>
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin
On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> I met below error during boot with i915 builtin if pass
> "i915.mitigations=off":
> [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
>
> The reason is slab subsystem isn't ready at that time, so kstrdup()
> returns NULL. Fix this issue by using stack var instead of kstrdup().
>
> Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
> mitigations")
> Signed-off-by: Jisheng Zhang
> ---
> drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> b/drivers/gpu/drm/i915/i915_mitigations.c
> index 84f12598d145..7dadf41064e0 100644
> --- a/drivers/gpu/drm/i915/i915_mitigations.c
> +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> @@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
> static int mitigations_set(const char *val, const struct kernel_param *kp)
> {
> unsigned long new = ~0UL;
> - char *str, *sep, *tok;
> + char str[64], *sep, *tok;
> bool first = true;
> int err = 0;
>
> BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
>
> - str = kstrdup(val, GFP_KERNEL);
> - if (!str)
> - return -ENOMEM;
> + strncpy(str, val, sizeof(str) - 1);
I don't think strncpy() guarantees that the string is properly
terminated.
Also commit b1b6bed3b503 ("usb: core: fix quirks_param_set() writing to
a const pointer") looks broken as well given your findings, and
arch/um/drivers/virtio_uml.c seems to suffer from this as well.
kernel/params.c itself seems to have some slab_is_available() magic
around kmalloc().
I used the following cocci snippet to find these:
@find@
identifier O, F;
position PS;
@@
struct kernel_param_ops O = {
...,
.set = F@PS
,...
};
@alloc@
identifier ALLOC =~ "^k.*(alloc|dup)";
identifier find.F;
position PA;
@@
F(...) {
<+...
ALLOC@PA(...)
...+>
}
@script:python depends on alloc@
ps << find.PS;
pa << alloc.PA;
@@
coccilib.report.print_report(ps[0], "struct")
coccilib.report.print_report(pa[0], "alloc")
That could of course miss a bunch more if they allocate
via some other function I didn't consider.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix modesetting in case of unexpected AUX timeouts
On Tue, Apr 13, 2021 at 02:24:12AM +0300, Imre Deak wrote:
> In case AUX failures happen unexpectedly during a modeset, the driver
> should still complete the modeset. In particular the driver should
> perform the link training sequence steps even in case of an AUX failure,
> as this sequence also includes port initialization steps. Not doing that
> can leave the port/pipe in a broken state and lead for instance to a
> flip done timeout.
>
> Fix this by continuing with link training (in a no-LTTPR mode) if the
> DPRX DPCD readout failed for some reason at the beginning of link
> training. After a successful connector detection we already have the
> DPCD read out and cached, so the failed repeated read for it should not
> cause a problem. Note that a partial AUX read could in theory partly
> overwrite the cached DPCD (and return error) but this overwrite should
> not happen if the returned values are corrupted (due to a timeout or
> some other IO error).
>
> Kudos to Ville to root cause the problem.
>
> Fixes: 7dffbdedb96a ("drm/i915: Disable LTTPR support when the DPCD rev <
> 1.4")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308
> Cc: sta...@vger.kernel.org # 5.11
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 5e9c3c74310ca..cbcfb0c4c3708 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -882,7 +882,8 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
> int lttpr_count = intel_dp_init_lttpr_and_dprx_caps(intel_dp);
>
> if (lttpr_count < 0)
> - return;
> + /* Still continue with enabling the port and link training. */
> + lttpr_count = 0;
>
> if (!intel_dp_link_train_all_phys(intel_dp, crtc_state, lttpr_count))
> intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
> --
> 2.27.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop redundant address-of op before lttpr_common_caps array
On Tue, Apr 13, 2021 at 02:24:13AM +0300, Imre Deak wrote:
> The addres-of op in front of an array is just an alias to using the
> array on its own, so drop the op.
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index cbcfb0c4c3708..7f684d33314f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -37,7 +37,7 @@ intel_dp_dump_link_status(struct drm_device *drm,
>
> static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
> {
> - memset(&intel_dp->lttpr_common_caps, 0,
> sizeof(intel_dp->lttpr_common_caps));
> + memset(intel_dp->lttpr_common_caps, 0,
> sizeof(intel_dp->lttpr_common_caps));
> }
>
> static void intel_dp_reset_lttpr_count(struct intel_dp *intel_dp)
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: remove strap checks from gen 9
On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrjälä wrote:
On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
Direction on gen9+ was to stop reading the straps and only rely on the
VBT for marking the port presence. This happened while dealing with
WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
skl straps").
For gen 10 it's hard to say if this will work or not since I can't test
it, so leave it with the same behavior as before.
For PCH_TGP we should still rely on the VBT to make ports E and F not
available.
Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_display.c | 36 ++--
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d62ce9c87748..5a03cbba0280 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10883,34 +10883,25 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
intel_ddi_init(dev_priv, PORT_B);
intel_ddi_init(dev_priv, PORT_C);
vlv_dsi_init(dev_priv);
+ } else if (DISPLAY_VER(dev_priv) == 9) {
Should be >=10 I presume? Or did we want ot handle cnl along with
why >= 10? The only DISPLAY_VER() == 10 platforms out there are handled
in the branch above. I can make it >= 9, but not >= 10. Intention was to
handle skl/kbl here.
icl perhaps? Doesn't really matter I suppose, but it's surely
going to consfuse the me the next time I read this.
+ intel_ddi_init(dev_priv, PORT_A);
+ intel_ddi_init(dev_priv, PORT_B);
+ intel_ddi_init(dev_priv, PORT_C);
+ intel_ddi_init(dev_priv, PORT_D);
+ intel_ddi_init(dev_priv, PORT_E);
+ intel_ddi_init(dev_priv, PORT_F);
DDI F isn't a thing on skl/derivatives, so I'd probably skip it on
those. Could just use IS_CNL_WITH_PORT_F() to match the looks of
the icl stuff.
I was actually looking at ICL and thinking "shouldn't this hack for
broken VBT be hidden in intel_bios.c?" I think we should trust what we
parse from VBT everywhere except of course in intel_bios.c where we
fixup when the VBT is wrong. Thoughts?
Thanks
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
This fixes the following build error with GCC 11:
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3109:3,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7695:3:
drivers/gpu/drm/i915/intel_pm.c:3058:9: error: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Werror=stringop-overread]
3058 | intel_print_wm_latency(dev_priv, "Primary",
dev_priv->wm.pri_latency);
|
^
drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
drivers/gpu/drm/i915/intel_pm.c:3058:9: note: referencing argument 3 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2995:13: note: in a call to function
‘intel_print_wm_latency’
2995 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
As far as I can tell, we don't actually need 8 elements except on SKL
and that uses dev_priv->wm.skl_latency which has enough.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3f6d8b502a619..59498794ac4ea 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2994,7 +2994,7 @@ int ilk_wm_max_level(const struct drm_i915_private
*dev_priv)
static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
const char *name,
- const u16 wm[8])
+ const u16 *wm)
{
int level, max_level = ilk_wm_max_level(dev_priv);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: remove strap checks from gen 9
On Tue, Apr 13, 2021 at 10:22:24AM -0700, Lucas De Marchi wrote:
> On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrjälä wrote:
> >On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
> >> Direction on gen9+ was to stop reading the straps and only rely on the
> >> VBT for marking the port presence. This happened while dealing with
> >> WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
> >> normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
> >> skl straps").
> >>
> >> For gen 10 it's hard to say if this will work or not since I can't test
> >> it, so leave it with the same behavior as before.
> >>
> >> For PCH_TGP we should still rely on the VBT to make ports E and F not
> >> available.
> >>
> >> Signed-off-by: Lucas De Marchi
> >> Reviewed-by: Anusha Srivatsa
> >> ---
> >> drivers/gpu/drm/i915/display/intel_display.c | 36 ++--
> >> 1 file changed, 11 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index d62ce9c87748..5a03cbba0280 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -10883,34 +10883,25 @@ static void intel_setup_outputs(struct
> >> drm_i915_private *dev_priv)
> >>intel_ddi_init(dev_priv, PORT_B);
> >>intel_ddi_init(dev_priv, PORT_C);
> >>vlv_dsi_init(dev_priv);
> >> + } else if (DISPLAY_VER(dev_priv) == 9) {
> >
> >Should be >=10 I presume? Or did we want ot handle cnl along with
>
> why >= 10? The only DISPLAY_VER() == 10 platforms out there are handled
> in the branch above. I can make it >= 9, but not >= 10. Intention was to
> handle skl/kbl here.
Yeah, meant to write >=9. Cnl not really a thing, but I would get
confused if we started skipping it in some places while still
handling it in others. I guess we may want to consider just nuking
cnl totally everywhere, but until that time I think we should keep
things consistent.
>
>
> >icl perhaps? Doesn't really matter I suppose, but it's surely
> >going to consfuse the me the next time I read this.
> >
> >> + intel_ddi_init(dev_priv, PORT_A);
> >> + intel_ddi_init(dev_priv, PORT_B);
> >> + intel_ddi_init(dev_priv, PORT_C);
> >> + intel_ddi_init(dev_priv, PORT_D);
> >> + intel_ddi_init(dev_priv, PORT_E);
> >> + intel_ddi_init(dev_priv, PORT_F);
> >
> >DDI F isn't a thing on skl/derivatives, so I'd probably skip it on
> >those. Could just use IS_CNL_WITH_PORT_F() to match the looks of
> >the icl stuff.
>
> I was actually looking at ICL and thinking "shouldn't this hack for
> broken VBT be hidden in intel_bios.c?" I think we should trust what we
> parse from VBT everywhere except of course in intel_bios.c where we
> fixup when the VBT is wrong. Thoughts?
I guess we could stuff it all in there somehow. Not sure.
Maybe Jani has thoughts on this?
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
== Series Details == Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer URL : https://patchwork.freedesktop.org/series/89022/ State : warning == Summary == $ dim checkpatch origin/drm-tip 03e2f5a6dc70 drm/i915/pm: Make the wm parameter of print_wm_latency a pointer -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: inlined from ‘ilk_setup_wm_latency’ at drivers/gpu/drm/i915/intel_pm.c:3109:3, total: 0 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
== Series Details == Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer URL : https://patchwork.freedesktop.org/series/89022/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: remove strap checks from gen 9
On Tue, Apr 13, 2021 at 08:39:07PM +0300, Ville Syrjälä wrote:
On Tue, Apr 13, 2021 at 10:22:24AM -0700, Lucas De Marchi wrote:
On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrjälä wrote:
>On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
>> Direction on gen9+ was to stop reading the straps and only rely on the
>> VBT for marking the port presence. This happened while dealing with
>> WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
>> normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
>> skl straps").
>>
>> For gen 10 it's hard to say if this will work or not since I can't test
>> it, so leave it with the same behavior as before.
>>
>> For PCH_TGP we should still rely on the VBT to make ports E and F not
>> available.
>>
>> Signed-off-by: Lucas De Marchi
>> Reviewed-by: Anusha Srivatsa
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 36 ++--
>> 1 file changed, 11 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
>> index d62ce9c87748..5a03cbba0280 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -10883,34 +10883,25 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
>>intel_ddi_init(dev_priv, PORT_B);
>>intel_ddi_init(dev_priv, PORT_C);
>>vlv_dsi_init(dev_priv);
>> + } else if (DISPLAY_VER(dev_priv) == 9) {
>
>Should be >=10 I presume? Or did we want ot handle cnl along with
why >= 10? The only DISPLAY_VER() == 10 platforms out there are handled
in the branch above. I can make it >= 9, but not >= 10. Intention was to
handle skl/kbl here.
Yeah, meant to write >=9. Cnl not really a thing, but I would get
confused if we started skipping it in some places while still
handling it in others. I guess we may want to consider just nuking
cnl totally everywhere, but until that time I think we should keep
things consistent.
considering mesa already did that, then yes. And agreed about being
consistent while that doesn't happen.
thanks
Lucas De Marchi
>icl perhaps? Doesn't really matter I suppose, but it's surely
>going to consfuse the me the next time I read this.
>
>> + intel_ddi_init(dev_priv, PORT_A);
>> + intel_ddi_init(dev_priv, PORT_B);
>> + intel_ddi_init(dev_priv, PORT_C);
>> + intel_ddi_init(dev_priv, PORT_D);
>> + intel_ddi_init(dev_priv, PORT_E);
>> + intel_ddi_init(dev_priv, PORT_F);
>
>DDI F isn't a thing on skl/derivatives, so I'd probably skip it on
>those. Could just use IS_CNL_WITH_PORT_F() to match the looks of
>the icl stuff.
I was actually looking at ICL and thinking "shouldn't this hack for
broken VBT be hidden in intel_bios.c?" I think we should trust what we
parse from VBT everywhere except of course in intel_bios.c where we
fixup when the VBT is wrong. Thoughts?
I guess we could stuff it all in there somehow. Not sure.
Maybe Jani has thoughts on this?
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
== Series Details == Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer URL : https://patchwork.freedesktop.org/series/89022/ State : success == Summary == CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19926 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/index.html Changes --- No changes found Participating hosts (47 -> 41) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9963 -> Patchwork_19926 CI-20190529: 20190529 CI_DRM_9963: f71c7917b4b6d6c093f1e65e62acd3360d96e63a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6063: d3b7f74ce5df6fdea03e490b7c64f0c6bfe76f03 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19926: 03e2f5a6dc7041008b197fd371d6949b4a3e9977 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 03e2f5a6dc70 drm/i915/pm: Make the wm parameter of print_wm_latency a pointer == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
== Series Details == Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer URL : https://patchwork.freedesktop.org/series/89022/ State : success == Summary == CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19926_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19926_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-snb6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-hang: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hang.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][3] ([i915#3316]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-skl7/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_eio@in-flight-contexts-10ms: - shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#3070]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb2/igt@gem_...@in-flight-contexts-10ms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-iclb1/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] / [i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb6/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][8] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-skl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb1/igt@gem_exec_fair@basic-p...@vecs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-iclb4/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271]) +128 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][19] ([i915#2389]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html - shard-skl: NOTRUN -> [FAIL][20] ([i915#2389]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-skl8/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#307]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-glk1/igt@gem_mmap_...@cpuset-big-copy-odd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19926/shard-glk8/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#2428]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9963/shard-iclb2/igt@gem_mmap_...@cpuset-big-
Re: [Intel-gfx] [PATCH] drm/i915/display/psr: Configure and Program IO buffer Wake and Fast Wake
On Thu, 2021-04-01 at 20:05 +0300, Gwan-gyeong Mun wrote:
> As per b.spec 49274, the IO buffer Wake lines and Fast Wake lines can be
> calculated based on the following formula.
>
> IO buffer wake lines = ROUNDUP(PSR2 IO wake time / total line time in
> microseconds)
> Fast wake lines = ROUNDUP(PSR2 aux transaction time / total line time in
> microseconds)
> For both fields limit the minimum to 7 lines and maximum to 12 lines
> PSR2 IO wake time = 50us, PSR2 aux transaction time = 32us.
>
> It calculates IO buffer Wake and Fast Wake based on b.spec 49274 and
> programs it.
>
> v2: Address Jose's review comment.
> - Do not overwrite the values.
> - Move calulating and validating of io_buffer_wake/fast_wake to
> intel_psr2_config_valid() from intel_psr_compute_config()
> - Add macros for hardcoded values.
> - Simplify and reuse the validating the io_buffer_wake/fast_wake.
>
> v3: Rebased
>
> Cc: José Roberto de Souza
> Cc: Lee Shawn C
> Signed-off-by: Gwan-gyeong Mun
> ---
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_psr.c | 65 +++
> drivers/gpu/drm/i915/i915_reg.h | 8 +++
> 3 files changed, 63 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index e2e707c4dff5..79df8da9b89e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1496,6 +1496,8 @@ struct intel_psr {
> u16 su_x_granularity;
> bool dc3co_enabled;
> u32 dc3co_exit_delay;
> + u32 io_buffer_wake;
> + u32 fast_wake;
> struct delayed_work dc3co_work;
> struct drm_dp_vsc_sdp vsc;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 54ad5c378355..a1fff724fb67 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -531,19 +531,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> val |= intel_psr2_get_tp_time(intel_dp);
>
>
>
>
>
>
>
>
> if (DISPLAY_VER(dev_priv) >= 12) {
> - /*
> - * TODO: 7 lines of IO_BUFFER_WAKE and FAST_WAKE are default
> - * values from BSpec. In order to setting an optimal power
> - * consumption, lower than 4k resoluition mode needs to decrese
> - * IO_BUFFER_WAKE and FAST_WAKE. And higher than 4K resolution
> - * mode needs to increase IO_BUFFER_WAKE and FAST_WAKE.
> - */
> - val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_2;
> - val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(7);
> - val |= TGL_EDP_PSR2_FAST_WAKE(7);
> + if (intel_dp->psr.io_buffer_wake < 9 || intel_dp->psr.fast_wake
> < 9)
> + val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_2;
> + else
> + val |= TGL_EDP_PSR2_BLOCK_COUNT_NUM_3;
> + val |=
> TGL_EDP_PSR2_IO_BUFFER_WAKE(intel_dp->psr.io_buffer_wake);
> + val |= TGL_EDP_PSR2_FAST_WAKE(intel_dp->psr.fast_wake);
> } else if (DISPLAY_VER(dev_priv) >= 9) {
> - val |= EDP_PSR2_IO_BUFFER_WAKE(7);
> - val |= EDP_PSR2_FAST_WAKE(7);
> + val |= EDP_PSR2_IO_BUFFER_WAKE(intel_dp->psr.io_buffer_wake);
> + val |= EDP_PSR2_FAST_WAKE(intel_dp->psr.fast_wake);
> }
>
>
>
>
>
>
>
>
> if (intel_dp->psr.psr2_sel_fetch_enabled) {
> @@ -724,7 +720,9 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> + u32 io_buffer_wake, io_buffer_wake_max, io_buffer_wake_min;
> int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;
> + u32 fast_wake, fast_wake_max, fast_wake_min;
>
>
>
>
>
>
>
>
> if (!intel_dp->psr.sink_psr2_support)
> return false;
> @@ -768,14 +766,26 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> psr_max_h = 5120;
> psr_max_v = 3200;
> max_bpp = 30;
> + io_buffer_wake_max = TGL_EDP_PSR2_IO_BUFFER_WAKE_MAX_LINES;
> + io_buffer_wake_min = TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES;
> + fast_wake_max = TGL_EDP_PSR2_FAST_WAKE_MAX_LINES;
> + fast_wake_min = TGL_EDP_PSR2_FAST_WAKE_MIN_LINES;
> } else if (DISPLAY_VER(dev_priv) >= 10) {
> psr_max_h = 4096;
> psr_max_v = 2304;
> max_bpp = 24;
> + io_buffer_wake_max = EDP_PSR2_IO_BUFFER_WAKE_MAX_LINES;
> + io_buffer_wake_min = EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES;
> + fast_wake_max = EDP_PSR2_FAST_WAKE_MAX_LINES;
> +
[Intel-gfx] [PATCH v2 1/1] drm/i915/dg1: Add HWMON power sensor support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
- power1_max
Some non-standard HWMON power information is also provided, such as
enable bits and intervals.
Signed-off-by: Dale B Stimson
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 9 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_hwmon.c | 788 ++
drivers/gpu/drm/i915/i915_hwmon.h | 41 ++
drivers/gpu/drm/i915/i915_reg.h | 53 ++
7 files changed, 896 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca77..ec8d5a0d7ea96 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -14,6 +14,7 @@ config DRM_I915
select DRM_MIPI_DSI
select RELAY
select IRQ_WORK
+ select HWMON
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137bc..e213e2b129e20 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -37,6 +37,7 @@ i915-y += i915_drv.o \
i915_config.o \
i915_irq.o \
i915_getparam.o \
+ i915_hwmon.o \
i915_mitigations.o \
i915_params.o \
i915_pci.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 305557e1942aa..84c7de3b34c7d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -69,6 +69,7 @@
#include "i915_debugfs.h"
#include "i915_drv.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_irq.h"
#include "i915_memcpy.h"
@@ -675,6 +676,10 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
+ /* Register with hwmon */
+ if (i915_hwmon_init(&dev_priv->drm))
+ drm_err(&dev_priv->drm, "Failed to register driver hwmon!\n");
+
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
@@ -709,9 +714,13 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
intel_gt_driver_unregister(&dev_priv->gt);
i915_perf_unregister(dev_priv);
+
+ i915_hwmon_fini(&dev_priv->drm);
+
i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
+
drm_dev_unplug(&dev_priv->drm);
i915_gem_driver_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69e43bf91a153..7e9b452c77e2b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -61,6 +61,7 @@
#include
#include
+#include "i915_hwmon.h"
#include "i915_params.h"
#include "i915_reg.h"
#include "i915_utils.h"
@@ -1109,6 +1110,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index 0..ab8f32f7ed1de
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,788 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+/*
+ * Power-related hwmon entries.
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "i915_hwmon.h"
+
+/*
+ * SF_* - scale factors for particular quantities.
+ * The hwmon standard says that quantities of the given types are specified
+ * in the given units:
+ * - time - milliseconds
+ * - power - microwatts
+ * - energy - microjoules
+ */
+
+#define SF_TIME 1000
+#define SF_POWER 100
+#define SF_ENERGY 100
+
+static void
+_locked_with_pm_intel_uncore_rmw(struct intel_uncore *uncore,
+i915_reg_t reg, u32 clear, u32 set)
+{
+ struct drm_i915_private *i915 = uncore->i915;
+ struct i915_hwmon *hwmon = &i915->hwmon;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * _field_read_and_scale()
+ * Return type of u64 allows for the case where the scaling might cause a
+ * result
[Intel-gfx] [PATCH v1 0/1] drm/i915/dg1: Add HWMON power sensor support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
- power1_max
Some non-standard HWMON power information is also provided, such as
enable bits and intervals.
-
V2 Rename local function parameter field_mask to field_msk in order to avoid
shadowing the name of function field_mask() from include/linux/bitfield.h.
V2 Change a comment introduction from "/**" to "/*", as it is not intended
to match a pattern that triggers documentation.
Reported-by: kernel test robot
V2 Slight movement of calls:
- i915_hwmon_init slightly later, after call to i915_setup_sysfs()
- i915_hwmon_fini slightly earlier, before i915_teardown_sysfs()
V2 Fixed some strong typing issues with le32 functions.
Detected by sparse in a run by kernel test robot:
Reported-by: kernel test robot
Dale B Stimson (1):
drm/i915/dg1: Add HWMON power sensor support
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 9 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_hwmon.c | 788 ++
drivers/gpu/drm/i915/i915_hwmon.h | 41 ++
drivers/gpu/drm/i915/i915_reg.h | 53 ++
7 files changed, 896 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
Range-diff against v1:
1: 34631511e00c1 ! 1: 25117970961b4 drm/i915/dg1: Add HWMON power sensor
support
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+
+#include
+#include
++#include
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+ */
+static __always_inline u64
+_field_read_and_scale(struct intel_uncore *uncore, i915_reg_t rgadr,
-+u32 field_mask, int nshift, unsigned int scale_factor)
++u32 field_msk, int nshift, unsigned int scale_factor)
+{
+ intel_wakeref_t wakeref;
+ u32 reg_value;
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
-+ reg_value = le32_get_bits(reg_value, field_mask);
++ reg_value = le32_get_bits(cpu_to_le32(reg_value), field_msk);
+ scaled_val = mul_u32_u32(scale_factor, reg_value);
+
+ /* Shift, rounding to nearest */
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+ */
+static __always_inline u64
+_field_read64_and_scale(struct intel_uncore *uncore, i915_reg_t rgadr,
-+ u64 field_mask, int nshift, unsigned int scale_factor)
++ u64 field_msk, int nshift, unsigned int scale_factor)
+{
+ intel_wakeref_t wakeref;
+ u64 reg_value;
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read64(uncore, rgadr);
+
-+ reg_value = le64_get_bits(reg_value, field_mask);
++ reg_value = le64_get_bits(cpu_to_le64(reg_value), field_msk);
+ scaled_val = scale_factor * reg_value;
+
+ /* Shift, rounding to nearest */
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+static __always_inline void
+_field_scale_and_write(struct intel_uncore *uncore,
+ i915_reg_t rgadr,
-+ u32 field_mask, int nshift,
++ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
-+ bits_to_clear = field_mask;
-+ bits_to_set = le32_encode_bits(nval, field_mask);
++ bits_to_clear = field_msk;
++ bits_to_set = le32_to_cpu(le32_encode_bits(nval, field_msk));
+
+ _locked_with_pm_intel_uncore_rmw(uncore, rgadr,
+ bits_to_clear, bits_to_set);
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+ struct intel_uncore *uncore = &i915->uncore;
+ intel_wakeref_t wakeref;
+ u32 val_sku_unit;
++ __le32 le_sku_unit;
+
+ if (IS_DG1(i915)) {
+ hwmon->rg.pkg_power_sku_unit = PCU_PACKAGE_POWER_SKU_UNIT;
@@ drivers/gpu/drm/i915/i915_hwmon.c (new)
+
+ intel_runtime_pm_put(uncore->rpm, wakeref);
+
-+ hwmon->scl_shift_power = le32_get_bits(val_sku_unit, PKG_PWR_UNIT);
-+ hwmon->scl_shift_energy = le32_get_bits(val_sku_unit, PKG_ENERGY_UNIT);
-+ hwmon->scl_shift_time = le32_get_bits(val_sku_unit, PKG_TIME_UNIT)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg1: Add HWMON power sensor support (rev2)
== Series Details == Series: drm/i915/dg1: Add HWMON power sensor support (rev2) URL : https://patchwork.freedesktop.org/series/88459/ State : warning == Summary == $ dim checkpatch origin/drm-tip fd48aa4fd9a8 drm/i915/dg1: Add HWMON power sensor support -:104: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #104: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 947 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/dg1: Add HWMON power sensor support (rev2)
== Series Details == Series: drm/i915/dg1: Add HWMON power sensor support (rev2) URL : https://patchwork.freedesktop.org/series/88459/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg1: Add HWMON power sensor support (rev2)
== Series Details == Series: drm/i915/dg1: Add HWMON power sensor support (rev2) URL : https://patchwork.freedesktop.org/series/88459/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9964 -> Patchwork_19927 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19927 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19927, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19927: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9964/fi-bsw-nick/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/fi-bsw-nick/igt@core_hotunp...@unbind-rebind.html Known issues Here are the changes found in Patchwork_19927 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#2283]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][5] -> [FAIL][6] ([i915#1888]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9964/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 Participating hosts (47 -> 39) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-skl-guc fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka fi-bdw-samus Build changes - * Linux: CI_DRM_9964 -> Patchwork_19927 CI-20190529: 20190529 CI_DRM_9964: be153d28e33003a54242e87c0902a65378b7c562 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6064: 48d89e2c65c54883b0776930a884e6d3bcefb45b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19927: fd48aa4fd9a8b56648e1518e7303a8cd0338ebf2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fd48aa4fd9a8 drm/i915/dg1: Add HWMON power sensor support == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19927/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Add frontbuffer tracking tracepoints
From: Ville Syrjälä
Add some tracpoints for frontbuffer tracking so we can
try to figure out what's going on.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_frontbuffer.c | 5 +++
drivers/gpu/drm/i915/i915_trace.h | 38 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 6fc6965b6133..8161d49e78ba 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -58,6 +58,7 @@
#include "display/intel_dp.h"
#include "i915_drv.h"
+#include "i915_trace.h"
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
@@ -87,6 +88,8 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
if (!frontbuffer_bits)
return;
+ trace_intel_frontbuffer_flush(frontbuffer_bits, origin);
+
might_sleep();
intel_edp_drrs_flush(i915, frontbuffer_bits);
intel_psr_flush(i915, frontbuffer_bits, origin);
@@ -173,6 +176,8 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,
spin_unlock(&i915->fb_tracking.lock);
}
+ trace_intel_frontbuffer_invalidate(frontbuffer_bits, origin);
+
might_sleep();
intel_psr_invalidate(i915, frontbuffer_bits, origin);
intel_edp_drrs_invalidate(i915, frontbuffer_bits);
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index a4addcc64978..81f5e1721180 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -474,6 +474,44 @@ TRACE_EVENT(intel_pipe_update_end,
__entry->scanline)
);
+/* frontbuffer tracking */
+
+TRACE_EVENT(intel_frontbuffer_invalidate,
+ TP_PROTO(unsigned int frontbuffer_bits, unsigned int origin),
+ TP_ARGS(frontbuffer_bits, origin),
+
+ TP_STRUCT__entry(
+__field(unsigned int, frontbuffer_bits)
+__field(unsigned int, origin)
+),
+
+ TP_fast_assign(
+ __entry->frontbuffer_bits = frontbuffer_bits;
+ __entry->origin = origin;
+ ),
+
+ TP_printk("frontbuffer_bits=0x%08x, origin=%u",
+ __entry->frontbuffer_bits, __entry->origin)
+);
+
+TRACE_EVENT(intel_frontbuffer_flush,
+ TP_PROTO(unsigned int frontbuffer_bits, unsigned int origin),
+ TP_ARGS(frontbuffer_bits, origin),
+
+ TP_STRUCT__entry(
+__field(unsigned int, frontbuffer_bits)
+__field(unsigned int, origin)
+),
+
+ TP_fast_assign(
+ __entry->frontbuffer_bits = frontbuffer_bits;
+ __entry->origin = origin;
+ ),
+
+ TP_printk("frontbuffer_bits=0x%08x, origin=%u",
+ __entry->frontbuffer_bits, __entry->origin)
+);
+
/* object tracking */
TRACE_EVENT(i915_gem_object_create,
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915: FBC cleanups
From: Ville Syrjälä The FBC code is a bit of mess. Start cleaning it up a bit. The main thing here is throwing out tons of redundant state from the fbc_state_cache and just checkng that stuff ahead of time from the plane/crtc states. Ville Syrjälä (8): drm/i915: Add frontbuffer tracking tracepoints drm/i915: Rewrite the FBC tiling check a bit drm/i915: Extract intel_fbc_update() drm/i915: Clear no_fbc_reason on activate drm/i915: Move the "recompress on activate" to a central place drm/i915: Nuke lots of crap from intel_fbc_state_cache drm/i915: No FBC+double wide pipe drm/i915: Pimp the FBC debugfs output drivers/gpu/drm/i915/display/intel_display.c | 10 +- .../drm/i915/display/intel_display_debugfs.c | 50 ++- .../drm/i915/display/intel_display_types.h| 2 +- drivers/gpu/drm/i915/display/intel_fbc.c | 424 +- drivers/gpu/drm/i915/display/intel_fbc.h | 5 +- .../gpu/drm/i915/display/intel_frontbuffer.c | 5 + drivers/gpu/drm/i915/i915_drv.h | 21 +- drivers/gpu/drm/i915/i915_trace.h | 38 ++ 8 files changed, 305 insertions(+), 250 deletions(-) -- 2.26.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: Rewrite the FBC tiling check a bit
From: Ville Syrjälä
Write the tiling check in a nicer form.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 04d9c7d22b04..178243a6d3a2 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -681,11 +681,9 @@ static bool tiling_is_valid(struct drm_i915_private
*dev_priv,
{
switch (modifier) {
case DRM_FORMAT_MOD_LINEAR:
- if (DISPLAY_VER(dev_priv) >= 9)
- return true;
- return false;
- case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
+ return DISPLAY_VER(dev_priv) >= 9;
+ case I915_FORMAT_MOD_X_TILED:
return true;
default:
return false;
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: Extract intel_fbc_update()
From: Ville Syrjälä
Pull the fbc enable vs. disable stuff into a small helper so
we don't have to have it pollute the higher level modeset code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +---
drivers/gpu/drm/i915/display/intel_fbc.c | 26 ++--
drivers/gpu/drm/i915/display/intel_fbc.h | 2 +-
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 411b46c012f8..a4b8fb5c20f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9799,10 +9799,7 @@ static void intel_update_crtc(struct intel_atomic_state
*state,
intel_encoders_update_pipe(state, crtc);
}
- if (new_crtc_state->update_pipe && !new_crtc_state->enable_fbc)
- intel_fbc_disable(crtc);
- else
- intel_fbc_enable(state, crtc);
+ intel_fbc_update(state, crtc);
/* Perform vblank evasion around commit operation */
intel_pipe_update_start(new_crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 178243a6d3a2..4968e79a6235 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1250,8 +1250,8 @@ void intel_fbc_choose_crtc(struct drm_i915_private
*dev_priv,
* intel_fbc_enable multiple times for the same pipe without an
* intel_fbc_disable in the middle, as long as it is deactivated.
*/
-void intel_fbc_enable(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+static void intel_fbc_enable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_plane *plane = to_intel_plane(crtc->base.primary);
@@ -1324,6 +1324,28 @@ void intel_fbc_disable(struct intel_crtc *crtc)
mutex_unlock(&fbc->lock);
}
+/**
+ * intel_fbc_update: enable/disable FBC on the CRTC
+ * @state: atomic state
+ * @crtc: the CRTC
+ *
+ * This function checks if the given CRTC was chosen for FBC, then enables it
if
+ * possible. Notice that it doesn't activate FBC. It is valid to call
+ * intel_fbc_update multiple times for the same pipe without an
+ * intel_fbc_disable in the middle.
+ */
+void intel_fbc_update(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+
+ if (crtc_state->update_pipe && !crtc_state->enable_fbc)
+ intel_fbc_disable(crtc);
+ else
+ intel_fbc_enable(state, crtc);
+}
+
/**
* intel_fbc_global_disable - globally disable FBC
* @dev_priv: i915 device instance
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h
b/drivers/gpu/drm/i915/display/intel_fbc.h
index 6dc1edefe81b..b97d908738e6 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -24,7 +24,7 @@ bool intel_fbc_pre_update(struct intel_atomic_state *state,
void intel_fbc_post_update(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void intel_fbc_init(struct drm_i915_private *dev_priv);
-void intel_fbc_enable(struct intel_atomic_state *state,
+void intel_fbc_update(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void intel_fbc_disable(struct intel_crtc *crtc);
void intel_fbc_global_disable(struct drm_i915_private *dev_priv);
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: Clear no_fbc_reason on activate
From: Ville Syrjälä
We try to set no_fbc_reason when FBC is not possible, let's
consistently clear when activating FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 4968e79a6235..fb8c0872a2b7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -411,6 +411,17 @@ bool intel_fbc_is_active(struct drm_i915_private *dev_priv)
return dev_priv->fbc.active;
}
+static void intel_fbc_activate(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ drm_WARN_ON(&dev_priv->drm, !mutex_is_locked(&fbc->lock));
+
+ intel_fbc_hw_activate(dev_priv);
+
+ fbc->no_fbc_reason = NULL;
+}
+
static void intel_fbc_deactivate(struct drm_i915_private *dev_priv,
const char *reason)
{
@@ -1094,7 +1105,7 @@ static void __intel_fbc_post_update(struct intel_crtc
*crtc)
return;
if (!fbc->busy_bits)
- intel_fbc_hw_activate(dev_priv);
+ intel_fbc_activate(dev_priv);
else
intel_fbc_deactivate(dev_priv, "frontbuffer write");
}
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Move the "recompress on activate" to a central place
From: Ville Syrjälä
On ILK+ we current do a nuke right after activating FBC. If my
memory isn't playing tricks on me this is actially required if
FBC didn't stay disabled for a full frame. In that case the
deactivate+reactivate may not invalidate the cfb. I'd have to
double chekc to be sure though.
So let's keep the nuke, and just extend it backwards to cover
all the platforms by doing it a bit higher up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index fb8c0872a2b7..8165bdb6f921 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -212,16 +212,16 @@ static void i965_fbc_recompress(struct drm_i915_private
*dev_priv)
/* This function forces a CFB recompression through the nuke operation. */
static void snb_fbc_recompress(struct drm_i915_private *dev_priv)
{
- struct intel_fbc *fbc = &dev_priv->fbc;
-
- trace_intel_fbc_nuke(fbc->crtc);
-
intel_de_write(dev_priv, MSG_FBC_REND_STATE, FBC_REND_NUKE);
intel_de_posting_read(dev_priv, MSG_FBC_REND_STATE);
}
static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
{
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ trace_intel_fbc_nuke(fbc->crtc);
+
if (DISPLAY_VER(dev_priv) >= 6)
snb_fbc_recompress(dev_priv);
else if (DISPLAY_VER(dev_priv) >= 4)
@@ -274,8 +274,6 @@ static void ilk_fbc_activate(struct drm_i915_private
*dev_priv)
params->fence_y_offset);
/* enable it... */
intel_de_write(dev_priv, ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
-
- intel_fbc_recompress(dev_priv);
}
static void ilk_fbc_deactivate(struct drm_i915_private *dev_priv)
@@ -348,8 +346,6 @@ static void gen7_fbc_activate(struct drm_i915_private
*dev_priv)
dpfc_ctl |= FBC_CTL_FALSE_COLOR;
intel_de_write(dev_priv, ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
-
- intel_fbc_recompress(dev_priv);
}
static bool intel_fbc_hw_is_active(struct drm_i915_private *dev_priv)
@@ -418,6 +414,7 @@ static void intel_fbc_activate(struct drm_i915_private
*dev_priv)
drm_WARN_ON(&dev_priv->drm, !mutex_is_locked(&fbc->lock));
intel_fbc_hw_activate(dev_priv);
+ intel_fbc_recompress(dev_priv);
fbc->no_fbc_reason = NULL;
}
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
