Louise;
the KMS drm driver is important in two ways :
1. As you say, it provides the "hook" into all 3D engine use, both from the OpenGL driver (the obvious user of the 3D engine) and the X driver (which uses the 3D engine for EXA and Xv as well). It also provides access to display / modesetting info in the same driver, ie it brings all of the required information together in one place.
2. Some of the registers which control GPIO and I2C lines for reading and writing fan/temp controllers and voltage control are also used by modesetting for reading EDID information, so modesetting and power management need to be in the same driver. Unfortunately that needs to be the drm driver, since changing clocks on the fly requires that the driver also block any use of drawing engines, which can only be done in the drm driver (since direct rendered 3D doesn't go through the userspace X driver).
DoDoENT;
The problem with doing dynamic PM in the userspace driver is that the userspace driver can't block drawing calls from 3D. Bad things can happen if the drawing engine is running at the same time you are reprogramming the clock generator for the engine. Doing dynamic PM in the drm means that drawing operations can be temporarily stopped and the drawing engine quiesced before changing the clock.
the KMS drm driver is important in two ways :
1. As you say, it provides the "hook" into all 3D engine use, both from the OpenGL driver (the obvious user of the 3D engine) and the X driver (which uses the 3D engine for EXA and Xv as well). It also provides access to display / modesetting info in the same driver, ie it brings all of the required information together in one place.
2. Some of the registers which control GPIO and I2C lines for reading and writing fan/temp controllers and voltage control are also used by modesetting for reading EDID information, so modesetting and power management need to be in the same driver. Unfortunately that needs to be the drm driver, since changing clocks on the fly requires that the driver also block any use of drawing engines, which can only be done in the drm driver (since direct rendered 3D doesn't go through the userspace X driver).
DoDoENT;
The problem with doing dynamic PM in the userspace driver is that the userspace driver can't block drawing calls from 3D. Bad things can happen if the drawing engine is running at the same time you are reprogramming the clock generator for the engine. Doing dynamic PM in the drm means that drawing operations can be temporarily stopped and the drawing engine quiesced before changing the clock.
Comment