| 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
| ||
|
Message-ID: <CACRpkdai5+vDj0C053qfPkdM-FCC-74HDCVF4=SPtUb7LE=Srw@mail.gmail.com>
Date: Mon, 26 Jul 2021 09:34:11 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Iskren Chernev <iskren.chernev@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>, Sam Ravnborg <sam@...nborg.org>,
Thierry Reding <thierry.reding@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
phone-devel@...r.kernel.org,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
<devicetree@...r.kernel.org>, Hans de Goede <hdegoede@...hat.com>, Andy
Shevchenko <andy.shevchenko@...il.com>,"
<~postmarketos/upstreaming@...ts.sr.ht>
Subject: Re: [PATCH v3 2/2] drm/panel: Add panel for Samsung Galaxy S5
Hi Iskren,
thanks for your patch!
On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev <iskren.chernev@...il.com> wrote:
> The Samsung Galaxy S5 uses the samsung s6e3fa2 AMOLED cmd LCD panel.
>
> This driver was generated with [1], with the addition of
> mipi_dsi_dcs_set_display_on at the end of the on method.
>
> [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator
>
> Signed-off-by: Iskren Chernev <iskren.chernev@...il.com>
(...)
> +config DRM_PANEL_SAMSUNG_S6E3FA2
> + tristate "Samsung S6E3FA2 DSI cmd mode panel"
Spell it out "command mode" no need to abbreviate.
> +struct samsung_s6e3fa2 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> + bool prepared;
Why do you need to keep track of prepared?
The framework already does that and that is why it keeps
different callbacks for prepare and enable.
> +#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)
Maybe this is something we should add to
include/drm/drm_mipi_dsi.h?
It looks very generic and helpful.
> +static void samsung_s6e3fa2_reset(struct samsung_s6e3fa2 *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(5000, 6000);
There is really no need to do this, the next statement asserts
reset. It looks like a copy/paste thing from a less informed
framework.
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(5000, 6000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(7000, 8000);
These two look good.
> +static int samsung_s6e3fa2_on(struct samsung_s6e3fa2 *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + dsi_generic_write_seq(dsi, 0xf0, 0x5a, 0x5a);
> + dsi_generic_write_seq(dsi, 0xfc, 0x5a, 0x5a);
These are very similar to other Samsung panels so you can definately
add this to your driver:
#define S6E3FA2_LEVEL_2_KEY 0xf0
> + dsi_generic_write_seq(dsi, 0xf0, 0xa5, 0xa5);
> + dsi_generic_write_seq(dsi, 0xfc, 0xa5, 0xa5);
Add a comment that this locks level 2 control again.
> +static int samsung_s6e3fa2_prepare(struct drm_panel *panel)
> +{
> + struct samsung_s6e3fa2 *ctx = to_samsung_s6e3fa2(panel);
> + struct device *dev = &ctx->dsi->dev;
> + int ret;
> +
> + if (ctx->prepared)
> + return 0;
Looks unnecessary. The framework should keep track of this.
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
> + MIPI_DSI_CLOCK_NON_CONTINUOUS;
You are not setting dsi->hs_rate and dsi->lp_rate.
The panel definitely has these max timings so when you
don't set them the DSI host will just go with some defaults
(some of them don't even allow you to configure this).
For reusability it would be great if you know roughly what these
clocks are, sometimes board files in vendor trees give a hint.
Worst case drop a comment that HS and LP rates are unknown.
I also wonder if the panel can report an MTP ID?
If you add some code like this and call from prepare(), what
happens?
#define READ_ID1 0xda /* Read panel ID 1 */
#define READ_ID2 0xdb /* Read panel ID 2 */
#define READ_ID3 0xdc /* Read panel ID 3 */
static int s6e3fa2_read_id(struct samsung_s6e3fa2 *ctx)
{
struct mipi_dsi_device *dsi = ctx->dsi;
struct device *dev = &dsi->dev;
u8 id1, id2, id3;
int ret;
ret = mipi_dsi_dcs_read(dsi, READ_ID1, &id1, 1);
if (ret < 0) {
dev_err(dev, "could not read MTP ID1\n");
return ret;
}
ret = mipi_dsi_dcs_read(dsi, READ_ID2, &id2, 1);
if (ret < 0) {
dev_err(dev, "could not read MTP ID2\n");
return ret;
}
ret = mipi_dsi_dcs_read(dsi, READ_ID3, &id3, 1);
if (ret < 0) {
dev_err(dev, "could not read MTP ID3\n");
return ret;
}
dev_info(dev, "MTP ID manufacturer: %02x version: %02x driver:
%02x\n", id1, id2, id3);
return 0;
}
(Dry coded, but you get the idea.)
Yours,
Linus Walleij
Powered by blists - more mailing lists