Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Andy Shevchenko <hidden>
Date: 2026-06-29 06:19:57
Also in:
dri-devel, linux-devicetree, linux-staging, lkml
On Sun, Jun 28, 2026 at 06:43:12PM +0300, Amit Barzilai wrote:
On Tue, 23 Jun 2026 12:37:31 +0300, Andy Shevchenko wrote:
...
quoted
quoted
+ const u8 cmds[] = {Why not static?This array can't be made static. It is initialised with runtime values (ssd130x->width - 1 and ssd130x->height - 1), so it is not a compile-time constant and a static/file-scope definition wouldn't compile. The other ssd13xx_init() functions are non-static for exactly the same reason.
Ah, I see. Thanks for pointing out.
quoted
quoted
+ 4, SSD135X_SET_CONTRAST, 0xc8, 0x80, 0xc8, + 2, SSD135X_SET_CONTRAST_MASTER, 0x0f, + 2, SSD135X_SET_PRECHARGE2, 0x01, + 1, SSD135X_SET_DISPLAY_NORMAL, + 2, SSD13XX_SET_SEG_REMAP, remap,quoted
+ 0,No trailing comma for the terminator entry.Removing it in v3. The other init arrays in drm-misc-next still carry the terminator comma, but that's pre-existing code outside this series -- I've left it alone to avoid unrelated churn. Happy to send a separate cleanup if you'd prefer.
You can issue a separate cleanup patch for those.
quoted
quoted
+ };
...
quoted
quoted
+ /* + * ssd130x_power_on() issues a short reset pulse, but the SSD1351 is not + * ready to accept commands immediately afterwards. Give the controller + * time to settle before sending the init sequence. + */Any reference to the datasheet?It's not a datasheet figure. fb_ssd1351 doesn't do it in init_display() either; it inherits it from the shared fbtft_reset() helper, which deasserts reset and then does msleep(120) before any command is sent. The 120 ms is a generic fbtft blanket value, not an SSD1351 number -- the SSD1351 datasheet's reset timing is microsecond-scale. I removed the msleep() and retested this on the hardware. The panel still initialises reliably. I'll drop the msleep() in v3.
Yeah, I truly believe that this long delay is for the parallel type of IO, where data and control signals are usually connected to a quite low speed GPIOs. But I suggest to leave some comment in the code. -- With Best Regards, Andy Shevchenko