Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
+static enum drm_mode_status +lsdc_mode_config_mode_valid(struct drm_device *ddev,
const struct drm_display_mode *mode)+{
struct lsdc_device *ldev = to_lsdc(ddev);const struct drm_format_info *info = drm_format_info(DRM_FORMAT_XRGB8888);Short-term hard coding a format is fine, but there should be a comment describing why.
Because our driver only support DRM_FORMAT_XRGB8888 frame buffer currently.
After carry out the IGT test, I found this function may not sufficient anymore.
u64 min_pitch = drm_format_info_min_pitch(info, 0, mode->hdisplay);u64 fb_size = min_pitch * mode->vdisplay;if (fb_size * 3 > ldev->vram_size) {Why are we using 3 here? Please add an inline comment.
Originally lsdc_mode_config_mode_valid() is copy from drm_gem_vram_helper.c
with the observation that there no need for the compute of the number of pages in
the terms of PAGE_SIZE.
The '3' here is a experience number, it intend to restrict single allocation overlarge.
In my opinion, it stand for one frame buffer plus another two dumb buffer allocation
when running the running pageflip test(from the libdrm modetest).
Therefore, the kernel space drm driver should guarantee at least 3 times frame buffer
allocation to the user-space. Otherwise, the pageflip test can not even being able to run.
While when testing this driver with IGT, I found the dumb_buffer test of IGT will try to
create a very large dumb buffer, as large as 256MB in my case.
Currently our driver could not satisfy such a large allocation,
I test it with drm/radeon driver on LoongArch and X86-64, redeon can not even passing it.
The restriction put in here is not effective anymore, because it is too late.
I'm think we should put the restriction in the lsdc_dumb_create() function.
We will revise our driver at next version.
Great thanks for your valuable reviews.