Driver Changes: - Fix for #7306: [Arc A380] white flickering when using arc as a secondary gpu (Matt A) - Add Wa_18017747507 for DG2 (Wayne) - Avoid spurious WARN on DG1 due to incorrect cache_dirty flag (Niranjana, Matt A) - Corrections to CS timestamp support for Gen5 and earlier (Ville) - Fix a build error used with clang compiler on hwmon (GG) - Improvements to LMEM handling with RPM (Anshuman, Matt A) - Cleanups in dmabuf code (Mike) - Selftest improvements (Matt A) Signed-off-by: Dave Airlie <airlied@redhat.com>
Showing the changes to include/uapi (1 of 150 files). Show all
Unified · Split
| @@ -645,6 +645,22 @@ typedef struct drm_i915_irq_wait { · 644 unmodified lines | |||
| 645 | */ | 645 | */ |
| 646 | #define I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP (1ul << 5) | 646 | #define I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP (1ul << 5) |
| 647 | 647 | ||
| 648 | /* | ||
| 649 | * Query the status of HuC load. | ||
| 650 | * | ||
| 651 | * The query can fail in the following scenarios with the listed error codes: | ||
| 652 | * -ENODEV if HuC is not present on this platform, | ||
| 653 | * -EOPNOTSUPP if HuC firmware usage is disabled, | ||
| 654 | * -ENOPKG if HuC firmware fetch failed, | ||
| 655 | * -ENOEXEC if HuC firmware is invalid or mismatched, | ||
| 656 | * -ENOMEM if i915 failed to prepare the FW objects for transfer to the uC, | ||
| 657 | * -EIO if the FW transfer or the FW authentication failed. | ||
| 658 | * | ||
| 659 | * If the IOCTL is successful, the returned parameter will be set to one of the | ||
| 660 | * following values: | ||
| 661 | * * 0 if HuC firmware load is not complete, | ||
| 662 | * * 1 if HuC firmware is authenticated and running. | ||
| 663 | */ | ||
| 648 | #define I915_PARAM_HUC_STATUS 42 | 664 | #define I915_PARAM_HUC_STATUS 42 |
| 649 | 665 | ||
| 650 | /* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of | 666 | /* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of |
| @@ -749,6 +765,12 @@ typedef struct drm_i915_irq_wait { · 98 unmodified lines | |||
| 749 | /* Query if the kernel supports the I915_USERPTR_PROBE flag. */ | 765 | /* Query if the kernel supports the I915_USERPTR_PROBE flag. */ |
| 750 | #define I915_PARAM_HAS_USERPTR_PROBE 56 | 766 | #define I915_PARAM_HAS_USERPTR_PROBE 56 |
| 751 | 767 | ||
| 768 | /* | ||
| 769 | * Frequency of the timestamps in OA reports. This used to be the same as the CS | ||
| 770 | * timestamp frequency, but differs on some platforms. | ||
| 771 | */ | ||
| 772 | #define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57 | ||
| 773 | |||
| 752 | /* Must be kept compact -- no holes and well documented */ | 774 | /* Must be kept compact -- no holes and well documented */ |
| 753 | 775 | ||
| 754 | /** | 776 | /** |
| @@ -2650,6 +2672,10 @@ enum drm_i915_oa_format { · 1895 unmodified lines | |||
| 2650 | I915_OA_FORMAT_A12_B8_C8, | 2672 | I915_OA_FORMAT_A12_B8_C8, |
| 2651 | I915_OA_FORMAT_A32u40_A4u32_B8_C8, | 2673 | I915_OA_FORMAT_A32u40_A4u32_B8_C8, |
| 2652 | 2674 | ||
| 2675 | /* DG2 */ | ||
| 2676 | I915_OAR_FORMAT_A32u40_A4u32_B8_C8, | ||
| 2677 | I915_OA_FORMAT_A24u40_A14u32_B8_C8, | ||
| 2678 | |||
| 2653 | I915_OA_FORMAT_MAX /* non-ABI */ | 2679 | I915_OA_FORMAT_MAX /* non-ABI */ |
| 2654 | }; | 2680 | }; |
| 2655 | 2681 | ||
| @@ -3493,27 +3519,13 @@ struct drm_i915_gem_create_ext { · 837 unmodified lines | |||
| 3493 | * | 3519 | * |
| 3494 | * The (page-aligned) allocated size for the object will be returned. | 3520 | * The (page-aligned) allocated size for the object will be returned. |
| 3495 | * | 3521 | * |
| 3496 | * DG2 64K min page size implications: | 3522 | * On platforms like DG2/ATS the kernel will always use 64K or larger |
| 3497 | * | 3523 | * pages for I915_MEMORY_CLASS_DEVICE. The kernel also requires a |
| 3498 | * On discrete platforms, starting from DG2, we have to contend with GTT | 3524 | * minimum of 64K GTT alignment for such objects. |
| 3499 | * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE | ||
| 3500 | * objects. Specifically the hardware only supports 64K or larger GTT | ||
| 3501 | * page sizes for such memory. The kernel will already ensure that all | ||
| 3502 | * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page | ||
| 3503 | * sizes underneath. | ||
| 3504 | * | ||
| 3505 | * Note that the returned size here will always reflect any required | ||
| 3506 | * rounding up done by the kernel, i.e 4K will now become 64K on devices | ||
| 3507 | * such as DG2. The kernel will always select the largest minimum | ||
| 3508 | * page-size for the set of possible placements as the value to use when | ||
| 3509 | * rounding up the @size. | ||
| 3510 | * | ||
| 3511 | * Special DG2 GTT address alignment requirement: | ||
| 3512 | * | ||
| 3513 | * The GTT alignment will also need to be at least 2M for such objects. | ||
| 3514 | * | 3525 | * |
| 3515 | * Note that due to how the hardware implements 64K GTT page support, we | 3526 | * NOTE: Previously the ABI here required a minimum GTT alignment of 2M |
| 3516 | * have some further complications: | 3527 | * on DG2/ATS, due to how the hardware implemented 64K GTT page support, |
| 3528 | * where we had the following complications: | ||
| 3517 | * | 3529 | * |
| 3518 | * 1) The entire PDE (which covers a 2MB virtual address range), must | 3530 | * 1) The entire PDE (which covers a 2MB virtual address range), must |
| 3519 | * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same | 3531 | * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same |
| @@ -3522,12 +3534,10 @@ struct drm_i915_gem_create_ext { · 2 unmodified lines | |||
| 3522 | * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM | 3534 | * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM |
| 3523 | * objects. | 3535 | * objects. |
| 3524 | * | 3536 | * |
| 3525 | * To keep things simple for userland, we mandate that any GTT mappings | 3537 | * However on actual production HW this was completely changed to now |
| 3526 | * must be aligned to and rounded up to 2MB. The kernel will internally | 3538 | * allow setting a TLB hint at the PTE level (see PS64), which is a lot |
| 3527 | * pad them out to the next 2MB boundary. As this only wastes virtual | 3539 | * more flexible than the above. With this the 2M restriction was |
| 3528 | * address space and avoids userland having to copy any needlessly | 3540 | * dropped where we now only require 64K. |
| 3529 | * complicated PDE sharing scheme (coloring) and only affects DG2, this | ||
| 3530 | * is deemed to be a good compromise. | ||
| 3531 | */ | 3541 | */ |
| 3532 | __u64 size; | 3542 | __u64 size; |
| 3533 | 3543 | ||