mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-29 15:43:59 +08:00
5978118c39
The current code only runs when we do an I915_WRITE operation. It
checks if the unclaimed register flag is set before we do the
operation, and then it checks it again after we do the operation. This
double check allows us to find out if the I915_WRITE operation in
question is the bad one, or if some previous code is the bad one. When
it finds a problem, our code uses DRM_ERROR to signal it.
The good thing about the current code is that it detects the problem,
so at least we can know we did something wrong. The problem is that
even though we find the problem, we don't really have much information
to actually debug it. So whenever I see one of these DRM_ERROR
messages on my systems, the first thing I do is apply a patch to
change the DRM_ERROR to a WARN and also check for unclaimed registers
on I915_READ operations. This local patch makes things even slower,
but it usually helps a lot in finding the bad code.
The first point here is that since the current code is only useful to
detect whether we have a problem or not, but it is not really good to
find the cause of the problem, I don't think we should be checking
both before and after every I915_WRITE operation: just doing the check
once should be enough for us to quickly detect problems. With this
change, the code that runs by default for every single user will only
do 1 read operation for every single I915_WRITE, instead of 2. This
patch does this change.
The second point is that the local patch I have should be upstream,
but since it makes things slower it should be disabled by default. So
I added the i915.mmio_debug option to enable it.
So after this patch, this is what will happen:
- By default, we will try to detect unclaimed registers once after
every I915_WRITE operation. Previously we tried twice for every
I915_WRITE.
- When we find an unclaimed register we will still print a DRM_ERROR
message, but we will now tell the user to try again with
i915.mmio_debug=1.
- When we use i915.mmio_debug=1 we will try to find unclaimed
registers both before and after every I915_READ and I915_WRITE
operation, and we will print stack traces in case we find them.
This should really help locating the exact point of the bad code
(or at least finding out that i915.ko is not the problem).
This commit also opens space for really-slow register debugging
operations on other platforms. In theory we can now add lots and lots
of debug code behind i915.mmio_debug, enable this option on our tests,
and catch more problems.
v2: - Remove not-so-useful comments (Daniel)
- Fix the param definition macros (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
||
|---|---|---|
| .. | ||
| armada | ||
| ast | ||
| bochs | ||
| bridge | ||
| cirrus | ||
| exynos | ||
| gma500 | ||
| i2c | ||
| i810 | ||
| i915 | ||
| mga | ||
| mgag200 | ||
| msm | ||
| nouveau | ||
| omapdrm | ||
| panel | ||
| qxl | ||
| r128 | ||
| radeon | ||
| rcar-du | ||
| savage | ||
| shmobile | ||
| sis | ||
| tdfx | ||
| tegra | ||
| tilcdc | ||
| ttm | ||
| udl | ||
| via | ||
| vmwgfx | ||
| ati_pcigart.c | ||
| drm_agpsupport.c | ||
| drm_auth.c | ||
| drm_buffer.c | ||
| drm_bufs.c | ||
| drm_cache.c | ||
| drm_context.c | ||
| drm_crtc_helper.c | ||
| drm_crtc_internal.h | ||
| drm_crtc.c | ||
| drm_debugfs.c | ||
| drm_dma.c | ||
| drm_dp_helper.c | ||
| drm_drv.c | ||
| drm_edid_load.c | ||
| drm_edid.c | ||
| drm_encoder_slave.c | ||
| drm_fb_cma_helper.c | ||
| drm_fb_helper.c | ||
| drm_flip_work.c | ||
| drm_fops.c | ||
| drm_gem_cma_helper.c | ||
| drm_gem.c | ||
| drm_global.c | ||
| drm_hashtab.c | ||
| drm_info.c | ||
| drm_ioc32.c | ||
| drm_ioctl.c | ||
| drm_irq.c | ||
| drm_lock.c | ||
| drm_memory.c | ||
| drm_mipi_dsi.c | ||
| drm_mm.c | ||
| drm_modes.c | ||
| drm_modeset_lock.c | ||
| drm_panel.c | ||
| drm_pci.c | ||
| drm_plane_helper.c | ||
| drm_platform.c | ||
| drm_prime.c | ||
| drm_probe_helper.c | ||
| drm_rect.c | ||
| drm_scatter.c | ||
| drm_stub.c | ||
| drm_sysfs.c | ||
| drm_trace_points.c | ||
| drm_trace.h | ||
| drm_usb.c | ||
| drm_vm.c | ||
| drm_vma_manager.c | ||
| Kconfig | ||
| Makefile | ||
| README.drm | ||
************************************************************
* For the very latest on DRI development, please see: *
* http://dri.freedesktop.org/ *
************************************************************
The Direct Rendering Manager (drm) is a device-independent kernel-level
device driver that provides support for the XFree86 Direct Rendering
Infrastructure (DRI).
The DRM supports the Direct Rendering Infrastructure (DRI) in four major
ways:
1. The DRM provides synchronized access to the graphics hardware via
the use of an optimized two-tiered lock.
2. The DRM enforces the DRI security policy for access to the graphics
hardware by only allowing authenticated X11 clients access to
restricted regions of memory.
3. The DRM provides a generic DMA engine, complete with multiple
queues and the ability to detect the need for an OpenGL context
switch.
4. The DRM is extensible via the use of small device-specific modules
that rely extensively on the API exported by the DRM module.
Documentation on the DRI is available from:
http://dri.freedesktop.org/wiki/Documentation
http://sourceforge.net/project/showfiles.php?group_id=387
http://dri.sourceforge.net/doc/
For specific information about kernel-level support, see:
The Direct Rendering Manager, Kernel Support for the Direct Rendering
Infrastructure
http://dri.sourceforge.net/doc/drm_low_level.html
Hardware Locking for the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
A Security Analysis of the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/security_low_level.html