mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Olivier Louvignes <olivier@mgcrea.io>,
	Maarten Lankhorst	 <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	 Thomas Zimmermann <tzimmermann@suse.de>,
	Neil Armstrong <neil.armstrong@linaro.org>
Cc: David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	 Jessica Zhang <jesszhan0024@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	"H . Nikolaus Schaller" <hns@goldelico.com>,
	Thomas Petazzoni	 <thomas.petazzoni@bootlin.com>,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-mips@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/5] drm/ingenic: Add a driver for the X1600 display controller
Date: Fri, 06 Nov 2026 16:06:50 +0100	[thread overview]
Message-ID: <71aa432f71144f446dba2037ab5664eea3569fdc.camel@crapouillou.net> (raw)
In-Reply-To: <20261106143827.15926-1-olivier@mgcrea.io>

Le vendredi 06 novembre 2026 à 15:38 +0100, Olivier Louvignes a écrit :
> Hi Paul,
> 
> On Fri, Nov 06, 2026 at 02:34:08PM +0100, Paul Cercueil wrote:
> > > +	struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> > 
> > This bothers me a bit, shouldn't it be using 'crtc_state'?
> 
> Yes. v4 takes the mode from crtc_state.
> 
> > > +	writel(readl(lcd->base + X1600_LCD_ST), lcd->base +
> > > X1600_LCD_CLR_ST);
> > 
> > Not fond of the writel(readl()) nesting here.
> 
> OK, a local in v4, here and in probe.
> 
> > > +	writel(val, lcd->base + X1600_LCD_DISP_COM);
> > 
> > This whole block above looks like out of place. Why not do it in
> > x1600_lcd_encoder_atomic_mode_set()?
> > 
> > Bonus point, you wouldn't need the 'bus_flags' and 'color_order' variables.
> 
> The controller only takes register writes while its clock runs, and the
> clock is off when atomic_mode_set() is called: on a full modeset the
> CRTC's atomic_disable() has stopped it, and atomic_enable() starts it
> again afterwards. I checked it on the R1: with the clock gated (CLKGR0
> bit 23), every register reads 0x80, and a write to TFT_HSYNC is lost,
> the register still holds the old value once the clock is back.
> 
> So moving the block means starting the clock in atomic_mode_set() too,
> or leaving it running while the CRTC is off. I'd rather keep the writes
> in atomic_enable(), next to clk_prepare_enable(), and look the bus
> format up in the new connector state there, so the two fields go
> anyway. Would that work for you?

Is there really a point in enabling the clock on-demand? Why not keep it enabled
always? It makes the driver more complex and I don't see a real benefit.

> 
> > > +	if (pixels > X1600_LCD_MAX_PIXELS)
> > > +		return MODE_MEM;
> > 
> > The max resolution is 1280x720 so you should check mode->hdisplay / mode-
> > > vdisplay individually. Otherwise bogus resolutions like 1920x480 would be
> > accepted.
> 
> Right for 1920x480, but 720 per side would refuse the R1's own panel,
> which is 480x800 in portrait. The manual only says "frame size up to
> 720p". v4 can bound each side by 1280 and keep the 1280x720 pixel count,
> would that do?

Ok. Then I guess keep the current check.

> > > +		spin_lock(&lcd->drm.event_lock);
> > 
> > spin_lock() can sleep with CONFIG_PREEMPT_RT so it looks wrong in an IRQ
> > handler. I *think* you don't need to lock it here anyway, as the spinlock is
> > locked in other places using spin_lock_irq().
> 
> On PREEMPT_RT the handler doesn't run in hard IRQ context:
> force_irqthreads() is always true there, and the IRQ is requested
> without IRQF_NO_THREAD, so the handler runs in a thread, where a
> spinlock_t is fine (Documentation/locking/locktypes.rst).
> 
> And it needs the lock: drm_crtc_send_vblank_event() wants the caller to
> hold event_lock, and lcd->event is shared with queue_event() and
> atomic_disable(). Their spin_lock_irq() only keeps the handler off the
> CPU they run on. armada, omapdrm and malidp take event_lock the same way
> in their handlers. So I'd keep it.

Ok.

> > You enable it later in the probe, so you could just use
> > devm_clk_get_enabled()
> > here.
> 
> Probe only enables it to stop what the boot loader left running, and
> disables it again before drm_dev_register(). From then on atomic_enable()
> and atomic_disable() gate it. devm_clk_get_enabled() would keep it
> running for as long as the driver is bound, display off included.

Yeah, I forgot that the devm action would cause a clk_disable_unprepare() to be
called on unprobe, which wouldn't work here. So ignore that.

As for the clock running for as long as the driver is bound, I don't think
that's much of a problem.

> > I saw a patch from Maxime replacing these - you should be calling
> > drm_mode_config_create_initial_state(drm) here (and handle the error).
> 
> Will do, it's in drm-misc-next already.
> 
> I'll leave v3 a few more days for the drm-misc side before sending v4.

Great.

Cheers,
-Paul

  reply	other threads:[~2026-11-06 15:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 11:19 [PATCH v3 0/5] drm/ingenic: Add the X1600 display controller and the HiBy R1 panel Olivier Louvignes
2026-11-06 11:19 ` [PATCH v3 1/5] dt-bindings: vendor-prefixes: Add HiBy Olivier Louvignes
2026-11-06 11:19 ` [PATCH v3 2/5] dt-bindings: display: Add the Ingenic X1600 display controller Olivier Louvignes
2026-11-06 11:19 ` [PATCH v3 3/5] drm/ingenic: Add a driver for the " Olivier Louvignes
2026-11-06 13:34   ` Paul Cercueil
2026-11-06 14:38     ` Olivier Louvignes
2026-11-06 15:06       ` Paul Cercueil [this message]
2026-11-06 19:13         ` Olivier Louvignes
2026-11-06 11:19 ` [PATCH v3 4/5] dt-bindings: display: panel: Add the HiBy LG35583 Olivier Louvignes
2026-11-06 11:20 ` [PATCH v3 5/5] drm/panel: " Olivier Louvignes

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=71aa432f71144f446dba2037ab5664eea3569fdc.camel@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=airlied@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hns@goldelico.com \
    --cc=jesszhan0024@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olivier@mgcrea.io \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tzimmermann@suse.de \
    /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

all inboxes | Powered by JetHome®