Searched hist:60027 (Results 1 - 3 of 3) sorted by relevance
| /linux-master/drivers/gpu/drm/xe/ | ||
| H A D | xe_mmio.h | diff 486b2ef2 Tue Aug 22 18:33:14 MDT 2023 Matt Roper <matthew.d.roper@intel.com> drm/xe: Drop xe_mmio_write64() The only possible 64-bit register writes in the driver come from the highly questionable MMIO ioctl. That ioctl's register write support only operates for userspace running as root and cannot be used by any real userspace; it exists solely to support the "xe_reg" debug tool in IGT. Since the spec indicates that hardware does not officially support 64-bit register accesses, there's no reason to allow such 64-bit writes, even for debugging. Bspec: 60027 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> diff 07431945 Tue Aug 22 18:33:13 MDT 2023 Matt Roper <matthew.d.roper@intel.com> drm/xe: Avoid 64-bit register reads Intel hardware officially only supports GTTMMADR register accesses of 32-bits or less (although 64-bit accesses to device memory and PTEs in the GSM are fine). Even though we do usually seem to get back reasonable values when performing readq() operations on registers in BAR0, we shouldn't rely on this violation of the spec working consistently. It's likely that even when we do get proper register values back the hardware is internally satisfying the request via a non-atomic sequence of two 32-bit reads, which can be problematic for timestamps and counters if rollover of the lower bits is not considered. Replace xe_mmio_read64() with xe_mmio_read64_2x32() that implements 64-bit register reads as two 32-bit reads and attempts to ensure that the upper dword has stabilized to avoid problematic rollovers for counter and timestamp registers. v2: - Move function from xe_mmio.h to xe_mmio.c. (Lucas) - Convert comment to kerneldoc and note that it shouldn't be used on registers where reads may trigger side effects. (Lucas) Bspec: 60027 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> |
| H A D | xe_ttm_stolen_mgr.c | diff 07431945 Tue Aug 22 18:33:13 MDT 2023 Matt Roper <matthew.d.roper@intel.com> drm/xe: Avoid 64-bit register reads Intel hardware officially only supports GTTMMADR register accesses of 32-bits or less (although 64-bit accesses to device memory and PTEs in the GSM are fine). Even though we do usually seem to get back reasonable values when performing readq() operations on registers in BAR0, we shouldn't rely on this violation of the spec working consistently. It's likely that even when we do get proper register values back the hardware is internally satisfying the request via a non-atomic sequence of two 32-bit reads, which can be problematic for timestamps and counters if rollover of the lower bits is not considered. Replace xe_mmio_read64() with xe_mmio_read64_2x32() that implements 64-bit register reads as two 32-bit reads and attempts to ensure that the upper dword has stabilized to avoid problematic rollovers for counter and timestamp registers. v2: - Move function from xe_mmio.h to xe_mmio.c. (Lucas) - Convert comment to kerneldoc and note that it shouldn't be used on registers where reads may trigger side effects. (Lucas) Bspec: 60027 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> |
| H A D | xe_mmio.c | diff 486b2ef2 Tue Aug 22 18:33:14 MDT 2023 Matt Roper <matthew.d.roper@intel.com> drm/xe: Drop xe_mmio_write64() The only possible 64-bit register writes in the driver come from the highly questionable MMIO ioctl. That ioctl's register write support only operates for userspace running as root and cannot be used by any real userspace; it exists solely to support the "xe_reg" debug tool in IGT. Since the spec indicates that hardware does not officially support 64-bit register accesses, there's no reason to allow such 64-bit writes, even for debugging. Bspec: 60027 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> diff 07431945 Tue Aug 22 18:33:13 MDT 2023 Matt Roper <matthew.d.roper@intel.com> drm/xe: Avoid 64-bit register reads Intel hardware officially only supports GTTMMADR register accesses of 32-bits or less (although 64-bit accesses to device memory and PTEs in the GSM are fine). Even though we do usually seem to get back reasonable values when performing readq() operations on registers in BAR0, we shouldn't rely on this violation of the spec working consistently. It's likely that even when we do get proper register values back the hardware is internally satisfying the request via a non-atomic sequence of two 32-bit reads, which can be problematic for timestamps and counters if rollover of the lower bits is not considered. Replace xe_mmio_read64() with xe_mmio_read64_2x32() that implements 64-bit register reads as two 32-bit reads and attempts to ensure that the upper dword has stabilized to avoid problematic rollovers for counter and timestamp registers. v2: - Move function from xe_mmio.h to xe_mmio.c. (Lucas) - Convert comment to kerneldoc and note that it shouldn't be used on registers where reads may trigger side effects. (Lucas) Bspec: 60027 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> |
Completed in 271 milliseconds