From: Maxime Ripard <maxime@cerno.tech>
To: Sui Jingfeng <15330273260@189.cn>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
Lucas Stach <l.stach@pengutronix.de>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Roland Scheidegger <sroland@vmware.com>,
Zack Rusin <zackr@vmware.com>,
Christian Gmeiner <christian.gmeiner@gmail.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Rob Herring <robh+dt@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Krzysztof Kozlowski <krzk@kernel.org>,
Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>,
Sam Ravnborg <sam@ravnborg.org>,
suijingfeng <suijingfeng@loongson.cn>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
Date: Wed, 9 Feb 2022 09:36:33 +0100 [thread overview]
Message-ID: <20220209083633.mlfbiydi7cbpgexa@houat> (raw)
In-Reply-To: <4dd6d32a-9818-1adf-cb3f-20c183ae2020@189.cn>
[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]
On Fri, Feb 04, 2022 at 12:41:37AM +0800, Sui Jingfeng wrote:
> > > +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.
atomic_update will be called each time the plane state is changed, so it
won't be an issue: when the first state will be committed, your
atomic_update function will be called and thus you'll overwrite what was
left of the firmware setup.
> 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?
My point was more about the fact that you're using the wrong abstraction
there. The format is a property of the plane, not from the CRTC. In KMS
(and in most drivers), you can have multiple planes with different
formats all attached to the same CRTC just fine.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-02-09 9:42 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-03 8:25 [PATCH v6 0/3] drm/lsdc: add drm driver for loongson display controller Sui Jingfeng
2022-02-03 8:25 ` [PATCH v6 1/3] " Sui Jingfeng
2022-02-03 8:53 ` Krzysztof Kozlowski
2022-02-03 11:07 ` Dan Carpenter
2022-02-03 11:29 ` Krzysztof Kozlowski
2022-02-03 13:34 ` Dan Carpenter
2022-02-03 8:58 ` Maxime Ripard
2022-02-03 15:47 ` Sui Jingfeng
2022-02-09 8:52 ` Maxime Ripard
2022-02-09 11:56 ` Jiaxun Yang
2022-02-09 14:04 ` Maxime Ripard
2022-02-09 14:14 ` Jiaxun Yang
2023-02-03 3:25 ` suijingfeng
2022-02-03 16:04 ` Sui Jingfeng
2022-02-09 8:49 ` Maxime Ripard
2022-02-09 14:38 ` Sui Jingfeng
2022-02-09 16:16 ` Maxime Ripard
2022-02-12 18:11 ` Sui Jingfeng
2022-02-16 14:08 ` Maxime Ripard
2022-02-12 20:52 ` Ilia Mirkin
2022-02-16 13:34 ` Sui Jingfeng
2022-02-16 14:11 ` Maxime Ripard
2022-02-03 16:29 ` Sui Jingfeng
2022-02-09 8:43 ` Maxime Ripard
2022-02-09 15:41 ` Sui Jingfeng
2022-02-09 16:19 ` Maxime Ripard
2022-02-16 13:46 ` Daniel Stone
2022-02-16 14:13 ` Sui Jingfeng
2022-02-16 14:43 ` Daniel Stone
2022-02-03 16:41 ` Sui Jingfeng
2022-02-09 8:36 ` Maxime Ripard [this message]
2023-02-02 2:58 ` suijingfeng
2022-02-03 8:25 ` [PATCH v6 2/3] dt-bindings: ls2k1000: add the display controller device node Sui Jingfeng
2022-02-03 8:50 ` Krzysztof Kozlowski
2022-02-16 14:01 ` Sui Jingfeng
2022-02-17 8:38 ` Krzysztof Kozlowski
2022-02-03 8:25 ` [PATCH v6 3/3] dt-bindings: mips: loongson: introduce board specific dts Sui Jingfeng
2022-02-03 8:49 ` Krzysztof Kozlowski
2022-02-09 12:00 ` [PATCH v6 0/3] drm/lsdc: add drm driver for loongson display controller Jiaxun Yang
2022-02-10 4:04 ` Sui Jingfeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220209083633.mlfbiydi7cbpgexa@houat \
--to=maxime@cerno.tech \
--cc=15330273260@189.cn \
--cc=airlied@linux.ie \
--cc=andrey.zhizhikin@leica-geosystems.com \
--cc=christian.gmeiner@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=krzk@kernel.org \
--cc=l.stach@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=sroland@vmware.com \
--cc=suijingfeng@loongson.cn \
--cc=tsbogend@alpha.franken.de \
--cc=zackr@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox