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

2022-05-25 Thread Joel Selvaraj

Hi Linus Walleij

On 19/05/22 14:39, Linus Walleij wrote:

Nope. But add the rate limited error print please!


Will do.


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


Unfortunately, I don't have a datasheet and the power on sequence is
taken from downstream android dts. It works pretty well though. So I
don't think I can #define any of these magic.


If you know which display controller the display is using (usually
Novatek n, Ilitek  etc someting like that) there is often
a datasheet for the display controller available but the display per
se often obscures the display controller.


Well, I recently figured that the panel works perfectly without all the 
magic commands. So, no need for #defines of those magics/documentation 
for now.



  > Doesn't it work to combine them into one call for each
  > pair?
  >> +   dsi_dcs_write_seq(dsi, );
  >> +   dsi_generic_write_seq(dsi, 0xff, 0x87, 0x19);

By using a macro? We can... but I am not sure what (0x00, 0x80), (0x00,
0xa0),etc type of commands signify without the datasheet, so I am not
sure what to name them in the macro and make any sensible meaning out of it.


I meant just sending dsi_generic_write_seq() with everything in
it:

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

Instead of two writes. Doesn't this work?


I am not sure about whether it will work. Can multiple DCS commands can 
be combined into single write? Don't know much about this.


Anyways since the panel works without all these magic commands, these 
will be removed in the next version.



Yours,
Linus Walleij


Thanks and Regards
Joel Selvaraj


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

2022-05-19 Thread Linus Walleij
On Mon, May 16, 2022 at 2:56 PM Joel Selvaraj  wrote:
> On 13/05/22 03:21, Linus Walleij wrote:
> > On Fri, May 6, 2022 at 2:18 PM Joel Selvaraj  wrote:
> >> +#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 {}.
>
> The do {} while (0) in macro ensures there is a semicolon when it's
> used. With normal blocking, it would have issues with if conditions?
> I read about them here: https://stackoverflow.com/a/2381339

Hm that seems true, it enforces the semicolon ; at the end of the
statement which is nice. I suppose we should fix the other macro
as well.

Noralf added this ({}) form in 02dd95fe31693, so maybe he wants
to chip in.

> > Second look at mipi_dbi_command() in include/drm/drm_mipi_dbi.h
> > this is very similar.
>
> Does the ({..}) style blocking used in mipi_dbi_command help workaround
> the semicolon issue I mentioned above?

Nope. But add the rate limited error print please!

> > 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!
>
> They almost do the same thing except for the msg.type values? Mostly the
> msg.type value is used to just check whether it's a long or short write
> in the msm dsi_host code. However, in mipi_dsi_create_packet function,
> the msg->type value is used to calculate packet->header[0] as follows:
>
> packet->header[0] = ((msg->channel & 0x3) << 6) | (msg->type & 0x3f);
>
> Wouldn't the difference between the mipi_dsi_dcs_write_buffer's and
> mipi_dsi_generic_write's msg.type values cause issue here?
>
> I tried using mipi_dsi_dcs_write_buffer for all commands and the panel
> worked fine, but I am not sure if it's correct to do so?

I think it's fine? The only issue would be if there is a DSI host controller
that only supports short writes, and in that case it should emulate
long writes by breaking long messages apart. (My amateur view at least.)

> > Lots of magic numbers. You don't have a datasheet do you?
> > So you could #define some of the magic?
>
> Unfortunately, I don't have a datasheet and the power on sequence is
> taken from downstream android dts. It works pretty well though. So I
> don't think I can #define any of these magic.

If you know which display controller the display is using (usually
Novatek n, Ilitek  etc someting like that) there is often
a datasheet for the display controller available but the display per
se often obscures the display controller.

>  > Doesn't it work to combine them into one call for each
>  > pair?
>  >> +   dsi_dcs_write_seq(dsi, );
>  >> +   dsi_generic_write_seq(dsi, 0xff, 0x87, 0x19);
>
> By using a macro? We can... but I am not sure what (0x00, 0x80), (0x00,
> 0xa0),etc type of commands signify without the datasheet, so I am not
> sure what to name them in the macro and make any sensible meaning out of it.

I meant just sending dsi_generic_write_seq() with everything in
it:

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

Instead of two writes. Doesn't this work?

Yours,
Linus Walleij


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

2022-05-16 Thread Joel Selvaraj

Hi Linus Walleij,

On 13/05/22 03:21, Linus Walleij wrote:

On Fri, May 6, 2022 at 2:18 PM Joel Selvaraj  wrote:

+#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 {}.


The do {} while (0) in macro ensures there is a semicolon when it's 
used. With normal blocking, it would have issues with if conditions?

I read about them here: https://stackoverflow.com/a/2381339


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


Does the ({..}) style blocking used in mipi_dbi_command help workaround 
the semicolon issue I mentioned above?



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.)


I agree. Could be done in another 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!


They almost do the same thing except for the msg.type values? Mostly the 
msg.type value is used to just check whether it's a long or short write 
in the msm dsi_host code. However, in mipi_dsi_create_packet function, 
the msg->type value is used to calculate packet->header[0] as follows:


packet->header[0] = ((msg->channel & 0x3) << 6) | (msg->type & 0x3f);

Wouldn't the difference between the mipi_dsi_dcs_write_buffer's and 
mipi_dsi_generic_write's msg.type values cause issue here?


I tried using mipi_dsi_dcs_write_buffer for all commands and the panel 
worked fine, but I am not sure if it's correct to do so?



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


Unfortunately, I don't have a datasheet and the power on sequence is 
taken from downstream android dts. It works pretty well though. So I 
don't think I can #define any of these magic.


> 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);

By using a macro? We can... but I am not sure what (0x00, 0x80), (0x00, 
0xa0),etc type of commands signify without the datasheet, so I am not 
sure what to name them in the macro and make any sensible meaning out of it.





+   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.


ok. Will drop them in the next version.


The rest looks nice!


Thanks for your review!


Yours,
Linus Walleij


Best Regards,
Joel Selvaraj



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

2022-05-12 Thread Linus Walleij
On Fri, May 6, 2022 at 2:18 PM Joel Selvaraj  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 

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


[PATCH 3/3] drm/panel: introduce ebbg,ft8719 panel

2022-05-06 Thread Joel Selvaraj
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 
---
 MAINTAINERS   |   7 +
 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-ebbg-ft8719.c | 362 ++
 4 files changed, 381 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ebbg-ft8719.c

diff --git a/MAINTAINERS b/MAINTAINERS
index cd0f68d4a34a..dfd2c53aea00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6018,6 +6018,13 @@ S:   Maintained
 F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
 F: drivers/gpu/drm/bridge/chipone-icn6211.c
 
+DRM DRIVER FOR EBBG FT8719 PANEL
+M: Joel Selvaraj 
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
+F: drivers/gpu/drm/panel/panel-ebbg-ft8719.c
+
 DRM DRIVER FOR FARADAY TVE200 TV ENCODER
 M: Linus Walleij 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 9989a316fe88..77176df2e2ec 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -114,6 +114,17 @@ config DRM_PANEL_EDP
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_EBBG_FT8719
+   tristate "EBBG FT8719 panel driver"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for the EBBG FT8719
+ video mode panel. Mainly found on Xiaomi Poco F1 mobile phone.
+ The panel has a resolution of 1080x2246. It provides a MIPI DSI
+ interface to the host.
+
 config DRM_PANEL_ELIDA_KD35T133
tristate "Elida KD35T133 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d99fbbce49d1..47cc20c1a770 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_EDP) += panel-edp.o
+obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
 obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
 obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
 obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-ebbg-ft8719.c 
b/drivers/gpu/drm/panel/panel-ebbg-ft8719.c
new file mode 100644
index ..abd54c4b0c23
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ebbg-ft8719.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022 Joel Selvaraj 
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device 
tree:
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+static const char * const regulator_names[] = {
+   "vddio",
+   "vddpos",
+   "vddneg",
+};
+
+static const unsigned long regulator_enable_loads[] = {
+   62000,
+   10,
+   10
+};
+
+struct ebbg_ft8719 {
+   struct drm_panel panel;
+   struct mipi_dsi_device *dsi;
+
+   struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+   struct gpio_desc *reset_gpio;
+   bool prepared;
+};
+
+static inline
+struct ebbg_ft8719 *to_ebbg_ft8719(struct drm_panel *panel)
+{
+   return container_of(panel, struct ebbg_ft8719, panel);
+}
+
+#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)
+
+static void ebbg_ft8719_reset(struct ebbg_ft8719 *ctx)
+{
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   usleep_range(4000, 5000);
+