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.
