Hi Iskren,
thanks for your patch!
On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev iskren.chernev@gmail.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@gmail.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