linux-kernel - Re: [PATCH 3/3] drm/panel: introduce ebbg,ft8719 panel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdYhkP9RYj98Lu=zkt+6aefx172R=8JtvOFpvh2uJ4byKA@mail.gmail.com>
Date:   Thu, 12 May 2022 23:51:59 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Joel Selvaraj <jo@...amily.in>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Stanislav Jakubek <stano.jakubek@...il.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Corentin Labbe <clabbe@...libre.com>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Hao Fang <fanghao11@...wei.com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org
Subject: Re: [PATCH 3/3] drm/panel: introduce ebbg,ft8719 panel

On Fri, May 6, 2022 at 2:18 PM Joel Selvaraj <jo@...amily.in> wrote:

> Add DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI video mode
> panel, which can be found on some Xiaomi Poco F1 phones. The panel's
> backlight is managed through QCOM WLED driver.
>
> Signed-off-by: Joel Selvaraj <jo@...amily.in>

Cool!

> +#define dsi_generic_write_seq(dsi, seq...) do {                                \
> +               static const u8 d[] = { seq };                          \
> +               int ret;                                                \
> +               ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));    \
> +               if (ret < 0)                                            \
> +                       return ret;                                     \
> +       } while (0)
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do {                            \
> +               static const u8 d[] = { seq };                          \
> +               int ret;                                                \
> +               ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> +               if (ret < 0)                                            \
> +                       return ret;                                     \
> +       } while (0)

First I don't see what the do {} while (0) buys you, just use
a basic block {}.

Second look at mipi_dbi_command() in include/drm/drm_mipi_dbi.h
this is very similar.

So this utility macro should be in a generic file such as
include/drm/drm_mipi_dsi.h. (Can be added in a separate
patch.)

Third I think you need only one macro (see below).

> +static int ebbg_ft8719_on(struct ebbg_ft8719 *ctx)
> +{
> +       struct mipi_dsi_device *dsi = ctx->dsi;
> +       struct device *dev = &dsi->dev;
> +       int ret;
> +
> +       dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> +       dsi_dcs_write_seq(dsi, 0x00, 0x00);
> +       dsi_generic_write_seq(dsi, 0xff, 0x87, 0x19, 0x01);

It's dubious that you always have dsi_dcs_write_seq()
followed by dsi_generic_write_seq().

That means mipi_dsi_generic_write() followed by
mipi_dsi_dcs_write_buffer(). But if you look at these
commands in drivers/gpu/drm/drm_mipi_dsi.c
you see that they do the same thing!

Doesn't it work to combine them into one call for each
pair?

> +       dsi_dcs_write_seq(dsi, 0x00, 0x80);
> +       dsi_generic_write_seq(dsi, 0xff, 0x87, 0x19);

Lots of magic numbers. You don't have a datasheet do you?
So you could #define some of the magic?

> +       if (ctx->prepared)
> +               return 0;
(...)
> +       ctx->prepared = true;
> +       return 0;
(...)
> +       if (!ctx->prepared)
> +               return 0;
(...)
> +       ctx->prepared = false;
> +       return 0;

Drop this state variable it is a reimplementation of something
that the core will track for you.

The rest looks nice!

Yours,
Linus Walleij