From: Paul Kocialkowski <paulk@sys-base.io>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: dri-devel@lists.freedesktop.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, "Marek Vasut" <marex@denx.de>,
"Stefan Agner" <stefan@agner.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>, "Frank Li" <Frank.Li@nxp.com>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"Krzysztof Hałasa" <khalasa@piap.pl>,
"Marco Felsch" <m.felsch@pengutronix.de>,
"Liu Ying" <victor.liu@nxp.com>
Subject: Re: [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
Date: Thu, 2 Apr 2026 18:08:56 +0200 [thread overview]
Message-ID: <ac6UmHl86ax5eSVv@shepard> (raw)
In-Reply-To: <3b221a4997c367df716bf107a7e98ce10cd6860b.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
Hi Lucas,
On Tue 31 Mar 26, 18:04, Lucas Stach wrote:
> Am Dienstag, dem 31.03.2026 um 17:17 +0200 schrieb Paul Kocialkowski:
> > Le Tue 31 Mar 26, 11:09, Lucas Stach a écrit :
> > > Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> > > > The lcdif v3 hardware comes with dedicated registers to set and clear
> > > > polarity bits in the CTRL register. It is unclear if there is a
> > > > difference with writing to the CTRL register directly.
> > > >
> > > > Follow the NXP BSP reference by using these registers, in case there is
> > > > a subtle difference caused by using them.
> > > >
> > > I don't really like that patch, as it blows up what is currently a
> > > single register access to three separate ones. If there is no clear
> > > benefit (as in it has been shown to fix any issue), I would prefer this
> > > code to stay as-is.
> >
> > Well I guess the cost of a few writes vs a single one is rather
> > negligible.
> >
> Yea, a few writes don't really hurt. But I don't think there is a very
> good reason to set this register this way, see below.
>
> > I'm rather worried that there might be an undocumented
> > reason why these registers exist in the first place and why they are
> > used in the BSP.
> >
> > But yes this is only speculation and I could not witness any actual
> > issue. My setup (lcdif3 with hdmi) uses all positive polarities which is
> > the default state, so not a good way to check.
> >
> > It would be great if somebody from NXP could confirm whether this is
> > needed or not. In the meantime I guess we can drop the patch. It'll stay
> > on the list in case someone has polarity issues later :)
>
> The separate clr/set registers are a rather common design feat found on
> Freescale/NXP IP blocks from the MXS era. On some of those IP blocks
> _all_ registers are presented as a base/clr/set triplet in the
> registers space.
Ah yes I vaguely remember seeing this with units used in the imx6.
> As far as I can tell they are mostly useful when you
> want to set/clear individual bits from a register without having to
> remember or executing a readback of the current state.
>
> In cases like the one changed in this patch, where the full register
> state is set in one go, directly writing to the base register is the
> right thing to do.
Okay then if you're confident these registers are just here for
convenience purposes we can continue writing the full register value.
I'll drop this patch in the next iteration.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-04-02 16:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 22:46 [PATCH 0/3] drm: lcdif: FIFO underrun/solid color bug fix Paul Kocialkowski
2026-03-30 22:46 ` [PATCH 1/3] drm: lcdif: Set undocumented bit to clear FIFO at vsync Paul Kocialkowski
2026-03-31 9:07 ` Lucas Stach
2026-03-30 22:46 ` [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge Paul Kocialkowski
2026-03-31 9:09 ` Lucas Stach
2026-03-31 15:17 ` Paul Kocialkowski
2026-03-31 16:04 ` Lucas Stach
2026-04-02 16:08 ` Paul Kocialkowski [this message]
2026-03-30 22:46 ` [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA Paul Kocialkowski
2026-03-31 9:14 ` Lucas Stach
2026-04-02 18:29 ` Paul Kocialkowski
2026-03-31 10:11 ` Krzysztof Hałasa
2026-04-02 16:50 ` Paul Kocialkowski
2026-04-03 4:36 ` Krzysztof Hałasa
2026-04-03 4:43 ` Krzysztof Hałasa
2026-04-04 19:29 ` Paul Kocialkowski
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=ac6UmHl86ax5eSVv@shepard \
--to=paulk@sys-base.io \
--cc=Frank.Li@nxp.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=khalasa@piap.pl \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.felsch@pengutronix.de \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marex@denx.de \
--cc=mripard@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=simona@ffwll.ch \
--cc=stefan@agner.ch \
--cc=tzimmermann@suse.de \
--cc=victor.liu@nxp.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