linux-kernel - Re: [PATCH v6 1/3] drm/lsdc: add drm 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: <4dd6d32a-9818-1adf-cb3f-20c183ae2020@189.cn>
Date:   Fri, 4 Feb 2022 00:41:37 +0800
From:   Sui Jingfeng <15330273260@....cn>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Roland Scheidegger <sroland@...are.com>,
        Zack Rusin <zackr@...are.com>,
        Christian Gmeiner <christian.gmeiner@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Andrey Zhizhikin <andrey.zhizhikin@...ca-geosystems.com>,
        Sam Ravnborg <sam@...nborg.org>,
        suijingfeng <suijingfeng@...ngson.cn>,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display
 controller

>> +static int lsdc_primary_plane_atomic_check(struct drm_plane *plane,
>> +					   struct drm_atomic_state *state)
>> +{
>> +	struct drm_device *ddev = plane->dev;
>> +	struct lsdc_device *ldev = to_lsdc(ddev);
>> +	struct drm_plane_state *old_plane_state = drm_atomic_get_old_plane_state(state, plane);
>> +	struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state, plane);
>> +	struct drm_framebuffer *new_fb = new_plane_state->fb;
>> +	struct drm_framebuffer *old_fb = old_plane_state->fb;
>> +	struct drm_crtc *crtc = new_plane_state->crtc;
>> +	u32 new_format = new_fb->format->format;
>> +	struct drm_crtc_state *new_crtc_state;
>> +	struct lsdc_crtc_state *priv_crtc_state;
>> +	int ret;
>> +
>> +	if (!crtc)
>> +		return 0;
>> +
>> +	new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
>> +	if (WARN_ON(!new_crtc_state))
>> +		return -EINVAL;
>> +
>> +	priv_crtc_state = to_lsdc_crtc_state(new_crtc_state);
>> +
>> +	ret = drm_atomic_helper_check_plane_state(new_plane_state,
>> +						  new_crtc_state,
>> +						  DRM_PLANE_HELPER_NO_SCALING,
>> +						  DRM_PLANE_HELPER_NO_SCALING,
>> +						  false,
>> +						  true);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * Require full modeset if enabling or disabling a plane,
>> +	 * or changing its position, size, depth or format.
>> +	 */
>> +	if ((!new_fb || !old_fb ||
>> +	     old_plane_state->crtc_x != new_plane_state->crtc_x ||
>> +	     old_plane_state->crtc_y != new_plane_state->crtc_y ||
>> +	     old_plane_state->crtc_w != new_plane_state->crtc_w ||
>> +	     old_plane_state->crtc_h != new_plane_state->crtc_h ||
>> +	     old_fb->format->format != new_format))
>> +		new_crtc_state->mode_changed = true;
>> +
>> +
>> +	priv_crtc_state->pix_fmt = lsdc_primary_get_default_format(crtc);
> Storing the pixel format in the CRTC state is weird? What would happen
> if you have a primary plane and a cursor in different formats?
>
> Also, reading the default format from a register doesn't look right.
> atomic_check can occur at any time, including before a previous commit,
> or while the hardware is disabled. You should rely on either a constant
> or the previous state here.
>
Currently, private CRTC state(priv_crtc_state) is not get used by the cursor's
atomic_check() and atomic_update(). I means this is only for the primary plane.
And both and the primary and the cursor using  XRGB8888 format, what I really
want here is let the atomic_update to update the framebuffer's format, because
the firmware (pmon) of some board set the framebuffer's format as RGB565.
If the hardware's format is same with the plane state, then there is no need to
update the FB's format register, save a function call, right?

When the plane is disabled the drm core will call the atomic_disable() function, right?

I will reconsider this, thank for your advice and i will correct other problems
at the next version. Thanks for you take time review my patch again.