linux-kernel - Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <860cb3b3-5247-c6ad-c13a-619cde221208@189.cn>
Date:   Tue, 11 Apr 2023 18:21:37 +0800
From:   Sui Jingfeng <15330273260@....cn>
To:     Emil Velikov <emil.l.velikov@...il.com>
Cc:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Christian Koenig <christian.koenig@....com>,
        linaro-mm-sig@...ts.linaro.org, Li Yi <liyi@...ngson.cn>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        nathan@...nel.org, linux-media@...r.kernel.org,
        loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v10 2/2] drm: add kms driver for loongson display
 controller

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.