Dear DRM development community,
We'd like to introduce the implementation of the new crtc properties.
First of all, please let me introduce the problem we try to address. With the
popularity of electric vehicles, the car vendors have increasing requirement
for ensuring the integrity of the critical content on the display. For example,
tell-tales are icons to indicate malfunction or operation on a car system. For
safty concern, car vendors always want to make sure these icons are not
tampered and can be correctly displayed on the instrument cluster.
To address this problem, since modern display control hardware is able to
calculate the CRC checksum of the display content, we are thinking of a feature
to let userspace specify a region on display, and we can utilize the hardware
to calculate the CRC checksum as frames scanned out, and finally, provide the
checksum for userspace for validation purpose.
In this case, since the icons themselves are often fixed over static
backgrounds, the CRC of the pixels in the region can be known in advance. So
one of the usage of the region and corresponding CRC result is that as users
know the CRC checksum of the tell-tales in advance, at runtime they can
retrieve the CRC value from kernel for validation as frames are scanned out.
We implement this feature and call it checksum region. To let userspace set a
region and retrieve the corresponding CRC value, we provide 2 new properties,
CHECKSUM_REGION and CHECKSUM_CRC. Both of them are blob properties under CRTC,
and the detailed struct of the two properties are listed below. One for
userspace to set the region to kernel, and the other for userspace to retrieve
CRC values from kernel. Upon userspace submitting the 4 coordinate values with
checksum_region_enable true, kernel instructs DC hardware to calculate the CRC
value accordingly as frames scanned out. The result CRC value of RGB colors are
then stored in CHECKSUM_CRC property, with a reference frame count for
userspace to know which frame the CRCs are calculated at.
/**
* struct drm_checksum_region - The enablement and region of checksum_region
* @x_start: Horizontal starting coordinate of the region.
* @y_start: Vertical starting coordinate of the region.
* @x_end: Horizontal ending coordinate of the region.
* @y_end: Vertical ending coordinate of the region.
* @checksum_region_enable: To enable or disable checksum_region.
*
* Userspace uses this structure to configure the region and enablement for
* checksum_region. Userspace should not submit a region out of the displayable
* region because there is nothing to display and need protection.
*/
struct drm_checksum_region {
__u32 x_start;
__u32 y_start;
__u32 x_end;
__u32 y_end;
__u8 checksum_region_enable;
__u8 pad[7];
};
/**
* struct drm_checksum_crc - The CRC value of the corresponding checksum region.
* @crc_r: CRC value of red color.
* @crc_g: CRC value of green color.
* @crc_b: CRC value of blue color.
* @frame_count: a referenced frame count to indicate which frame the CRC values
* are generated at.
*
* Userspace uses this structure to retrieve the CRC values of the current
* checksum region. @frame_count will be reset once a new region is updated or
* it reaches a maximum value. Currently these CRC values are designed to
* be validated with pre-saved CRC values, so userspace doesn't need to concern
* about the algorithm used to compute the CRC.
*/
struct drm_checksum_crc {
__u32 crc_r;
__u32 crc_g;
__u32 crc_b;
__u32 frame_count;
};
To better introduce the usage of this feature, we also have a paired Weston
application as an reference app to use secure display via the properties.
Please check the Weston application and see how the application set the region
and validate the content from the CRC here:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1236
This application can draw patterns on the display, and allow users to set the
region and submit it to kernel via properties. With kernel keeping calculating
the CRC, this example application takes the first CRC as source CRC, and keeps
retrieving the new CRCs at each frame later. By comparing source CRC with the
following CRC value, the application can validate if the display content got
changed down the road.
Finally, let me briefly introduce the patches. There are 3 patches in this
patch series. The first patch is the main patch that contains change to drm,
including the new CRTC properties, the property creation function and a
update_checksum_region_crc() CRTC callback.
1. drm: Introduce CRTC checksum region and CRC properties
The remaining 2 patches are only related to the processing of region and CRC
data in our driver, also listed here for your reference.
2. drm/amd/display: Create checksum_region properties and handle new
region update
3. drm/amd/display: Implement the retrieval of checksum_region's CRC
data
Thanks for the reading and hope to get your feedback soon!
v2:
- Change the name of secure display to checksum region.
- Move the new properties, their creation function and their state to drm layer.
- Improve comments on the new properties's usage and limitation.
- Add a new CRTC callback update_checksum_region_crc() for updating the CRC
checksum to the crc blob.
- Squash patches from 7 to 3.
Alan Liu (3):
drm: Introduce CRTC checksum region and CRC properties
drm/amd/display: Create checksum_region properties and handle new
region update
drm/amd/display: Implement the retrieval of checksum_region's CRC data
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 44 +++++++
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 112 ++++++++++++++++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 14 +++
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 52 ++++++++
drivers/gpu/drm/drm_atomic_state_helper.c | 7 ++
drivers/gpu/drm/drm_atomic_uapi.c | 21 +++-
drivers/gpu/drm/drm_crtc.c | 44 +++++++
include/drm/drm_crtc.h | 43 +++++++
include/uapi/drm/drm_mode.h | 42 +++++++
9 files changed, 368 insertions(+), 11 deletions(-)
--
2.34.1
