[U-Boot] [PATCH 0/8] video: Add support for SSD2828 (parallel LCD to MIPI bridge)

Hello,
This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet.
The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far.
The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet.
This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository.
And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg
Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
board/sunxi/Kconfig | 60 +++++ board/sunxi/board.c | 1 + configs/MSI_Primo81_defconfig | 9 + drivers/power/Kconfig | 10 + drivers/power/axp221.c | 51 ++++ drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 575 ++++++++++++++++++++++++++++++++++++++++ drivers/video/ssd2828.h | 128 +++++++++ drivers/video/sunxi_display.c | 3 + drivers/video/sunxi_lcd_panel.c | 37 +++ drivers/video/sunxi_lcd_panel.h | 3 + include/axp221.h | 9 + include/mipi_display.h | 130 +++++++++ 13 files changed, 1017 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h create mode 100644 include/mipi_display.h

And also add Kconfig option for selecting ELDO3 voltage. The reason for having this option is that the Android kernel sets ELDO3 to 1.2V when powering up LCD in the case if 'lcd_if' configuration variable is set to 6 (LCD_IF_EXT_DSI) in the FEX file. Most likely to supply power for a SSD2828 chip.
However on the MSI Primo81 tablet, which is using this particular 'lcd_if = 6' setup for LCD, setting the ELDO3 voltage appears to be unnecessary and it works regardless. Having no schematics of this tablet, I can only guess that 1.2V is supplied to SSD2828 in some other way.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- board/sunxi/board.c | 1 + drivers/power/Kconfig | 10 ++++++++++ drivers/power/axp221.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/axp221.h | 9 +++++++++ 4 files changed, 71 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 7d6d075..12a2e77 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -189,6 +189,7 @@ void sunxi_board_init(void) power_failed |= axp221_set_aldo1(CONFIG_AXP221_ALDO1_VOLT); power_failed |= axp221_set_aldo2(CONFIG_AXP221_ALDO2_VOLT); power_failed |= axp221_set_aldo3(CONFIG_AXP221_ALDO3_VOLT); + power_failed |= axp221_set_eldo3(CONFIG_AXP221_ELDO3_VOLT); #endif
printf("DRAM:"); diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index ef0c093..cf42e63 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -63,3 +63,13 @@ config AXP221_ALDO3_VOLT Set the voltage (mV) to program the axp221 aldo3 at, set to 0 to disable aldo3. This is typically connected to VCC-PLL and AVCC and must be set to 3V. + +config AXP221_ELDO3_VOLT + int "axp221 eldo3 voltage" + depends on AXP221_POWER + default 0 + ---help--- + Set the voltage (mV) to program the axp221 eldo3 at, set to 0 to + disable eldo3. On some A31(s) tablets it might be used to supply + 1.2V for the SSD2828 chip (convertor of parallel LCD interface + into MIPI DSI). diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c index 1fda19a..d041b30 100644 --- a/drivers/power/axp221.c +++ b/drivers/power/axp221.c @@ -302,6 +302,57 @@ int axp221_set_aldo3(unsigned int mvolt) AXP221_OUTPUT_CTRL3_ALDO3_EN); }
+int axp221_set_eldo1(unsigned int mvolt) +{ + int ret; + u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100); + + if (mvolt == 0) + return axp221_clrbits(AXP221_OUTPUT_CTRL2, + AXP221_OUTPUT_CTRL2_ELDO1_EN); + + ret = pmic_bus_write(AXP221_ELDO1_CTRL, cfg); + if (ret) + return ret; + + return axp221_setbits(AXP221_OUTPUT_CTRL2, + AXP221_OUTPUT_CTRL2_ELDO1_EN); +} + +int axp221_set_eldo2(unsigned int mvolt) +{ + int ret; + u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100); + + if (mvolt == 0) + return axp221_clrbits(AXP221_OUTPUT_CTRL2, + AXP221_OUTPUT_CTRL2_ELDO2_EN); + + ret = pmic_bus_write(AXP221_ELDO2_CTRL, cfg); + if (ret) + return ret; + + return axp221_setbits(AXP221_OUTPUT_CTRL2, + AXP221_OUTPUT_CTRL2_ELDO2_EN); +} + +int axp221_set_eldo3(unsigned int mvolt) +{ + int ret; + u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100); + + if (mvolt == 0) + return axp221_clrbits(AXP221_OUTPUT_CTRL2, + AXP221_OUTPUT_CTRL2_ELDO3_EN); + + ret = pmic_bus_write(AXP221_ELDO3_CTRL, cfg); + if (ret) + return ret; + + return axp221_setbits(AXP221_OUTPUT_CTRL2, + AXP221_OUTPUT_CTRL2_ELDO3_EN); +} + int axp221_init(void) { u8 axp_chip_id; diff --git a/include/axp221.h b/include/axp221.h index e9552f6..da63891 100644 --- a/include/axp221.h +++ b/include/axp221.h @@ -26,6 +26,9 @@ #define AXP221_OUTPUT_CTRL1_ALDO1_EN (1 << 6) #define AXP221_OUTPUT_CTRL1_ALDO2_EN (1 << 7) #define AXP221_OUTPUT_CTRL2 0x12 +#define AXP221_OUTPUT_CTRL2_ELDO1_EN (1 << 0) +#define AXP221_OUTPUT_CTRL2_ELDO2_EN (1 << 1) +#define AXP221_OUTPUT_CTRL2_ELDO3_EN (1 << 2) #define AXP221_OUTPUT_CTRL2_DLDO1_EN (1 << 3) #define AXP221_OUTPUT_CTRL2_DLDO2_EN (1 << 4) #define AXP221_OUTPUT_CTRL2_DLDO3_EN (1 << 5) @@ -37,6 +40,9 @@ #define AXP221_DLDO2_CTRL 0x16 #define AXP221_DLDO3_CTRL 0x17 #define AXP221_DLDO4_CTRL 0x18 +#define AXP221_ELDO1_CTRL 0x19 +#define AXP221_ELDO2_CTRL 0x1a +#define AXP221_ELDO3_CTRL 0x1b #define AXP221_DCDC1_CTRL 0x21 #define AXP221_DCDC2_CTRL 0x22 #define AXP221_DCDC3_CTRL 0x23 @@ -62,5 +68,8 @@ int axp221_set_dldo4(unsigned int mvolt); int axp221_set_aldo1(unsigned int mvolt); int axp221_set_aldo2(unsigned int mvolt); int axp221_set_aldo3(unsigned int mvolt); +int axp221_set_eldo1(unsigned int mvolt); +int axp221_set_eldo2(unsigned int mvolt); +int axp221_set_eldo3(unsigned int mvolt); int axp221_init(void); int axp221_get_sid(unsigned int *sid);

On Fri, 9 Jan 2015 12:01:09 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote: ...
+int axp221_set_eldo2(unsigned int mvolt) +{
- int ret;
- u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
- if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO2_EN);
- ret = pmic_bus_write(AXP221_ELDO2_CTRL, cfg);
- if (ret)
return ret;
- return axp221_setbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO2_EN);
+}
+int axp221_set_eldo3(unsigned int mvolt) +{
- int ret;
- u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
- if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO3_EN);
- ret = pmic_bus_write(AXP221_ELDO3_CTRL, cfg);
- if (ret)
return ret;
- return axp221_setbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO3_EN);
+}
Can we avoid code duplication here? I.e. only one function should be sufficient here:
int axp221_set_eldo(int eldo_num, unsigned int mvolt) { int ret; u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100); u8 addr, bits;
switch (eldo_num) { case 3: addr = AXP221_ELDO3_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO3_EN; break; case 2: addr = AXP221_ELDO2_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO2_EN; break; case 1: default: addr = AXP221_ELDO1_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO1_EN; break; }
if (mvolt == 0) return axp221_clrbits(AXP221_OUTPUT_CTRL2, bits);
ret = pmic_bus_write(addr, cfg); if (ret) return ret;
return axp221_setbits(AXP221_OUTPUT_CTRL2, bits); }
Thanks, Anatolij

On Fri, 9 Jan 2015 18:05:35 +0100 Anatolij Gustschin agust@denx.de wrote:
On Fri, 9 Jan 2015 12:01:09 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote: ...
+int axp221_set_eldo2(unsigned int mvolt) +{
- int ret;
- u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
- if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO2_EN);
- ret = pmic_bus_write(AXP221_ELDO2_CTRL, cfg);
- if (ret)
return ret;
- return axp221_setbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO2_EN);
+}
+int axp221_set_eldo3(unsigned int mvolt) +{
- int ret;
- u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
- if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO3_EN);
- ret = pmic_bus_write(AXP221_ELDO3_CTRL, cfg);
- if (ret)
return ret;
- return axp221_setbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO3_EN);
+}
Can we avoid code duplication here? I.e. only one function should be sufficient here:
int axp221_set_eldo(int eldo_num, unsigned int mvolt) { int ret; u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100); u8 addr, bits;
switch (eldo_num) { case 3: addr = AXP221_ELDO3_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO3_EN; break; case 2: addr = AXP221_ELDO2_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO2_EN; break; case 1: default: addr = AXP221_ELDO1_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO1_EN; break; } if (mvolt == 0) return axp221_clrbits(AXP221_OUTPUT_CTRL2, bits); ret = pmic_bus_write(addr, cfg); if (ret) return ret; return axp221_setbits(AXP221_OUTPUT_CTRL2, bits);
}
Thanks for the review.
Yes, I am not very happy about this code duplication either. But I just made it so that it follows the same pattern as the rest of the code in the axp221 source file for the other voltage regulators. Does it mean that we want to change it all to have a consistent style?
This is a purely sunxi code and not directly related to video. And I would like to know what sunxi custodians think about it.

Hi,
On 11-01-15 13:05, Siarhei Siamashka wrote:
On Fri, 9 Jan 2015 18:05:35 +0100 Anatolij Gustschin agust@denx.de wrote:
On Fri, 9 Jan 2015 12:01:09 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote: ...
+int axp221_set_eldo2(unsigned int mvolt) +{
- int ret;
- u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
- if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO2_EN);
- ret = pmic_bus_write(AXP221_ELDO2_CTRL, cfg);
- if (ret)
return ret;
- return axp221_setbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO2_EN);
+}
+int axp221_set_eldo3(unsigned int mvolt) +{
- int ret;
- u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
- if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO3_EN);
- ret = pmic_bus_write(AXP221_ELDO3_CTRL, cfg);
- if (ret)
return ret;
- return axp221_setbits(AXP221_OUTPUT_CTRL2,
AXP221_OUTPUT_CTRL2_ELDO3_EN);
+}
Can we avoid code duplication here? I.e. only one function should be sufficient here:
int axp221_set_eldo(int eldo_num, unsigned int mvolt) { int ret; u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100); u8 addr, bits;
switch (eldo_num) { case 3: addr = AXP221_ELDO3_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO3_EN; break; case 2: addr = AXP221_ELDO2_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO2_EN; break; case 1: default: addr = AXP221_ELDO1_CTRL; bits = AXP221_OUTPUT_CTRL2_ELDO1_EN; break; } if (mvolt == 0) return axp221_clrbits(AXP221_OUTPUT_CTRL2, bits); ret = pmic_bus_write(addr, cfg); if (ret) return ret; return axp221_setbits(AXP221_OUTPUT_CTRL2, bits);
}
Thanks for the review.
Yes, I am not very happy about this code duplication either. But I just made it so that it follows the same pattern as the rest of the code in the axp221 source file for the other voltage regulators. Does it mean that we want to change it all to have a consistent style?
This is a purely sunxi code and not directly related to video. And I would like to know what sunxi custodians think about it.
I think that Anatolij's suggestion is a good one, you're right that it introduces some inconsistency wrt the existing code, but I think it would be better to eventually also move the existing code over to the model suggested by Anatolij. So lets make the eldo support follow this from day one.
Then one day someone should do a follow up patch separate from this patch-set to make the rest also follow the eldo model, with one function per type of regulator, so we end up with axp221_set_dcdc axp221_set_dldo and axp221_set_eldo.
Regards,
Hans

It provides some constants for DCS commands, which are needed to implement support for SSD2828.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- include/mipi_display.h | 130 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 include/mipi_display.h
diff --git a/include/mipi_display.h b/include/mipi_display.h new file mode 100644 index 0000000..ddcc8ca --- /dev/null +++ b/include/mipi_display.h @@ -0,0 +1,130 @@ +/* + * Defines for Mobile Industry Processor Interface (MIPI(R)) + * Display Working Group standards: DSI, DCS, DBI, DPI + * + * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovetski@gmx.de + * Copyright (C) 2006 Nokia Corporation + * Author: Imre Deak imre.deak@nokia.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef MIPI_DISPLAY_H +#define MIPI_DISPLAY_H + +/* MIPI DSI Processor-to-Peripheral transaction types */ +enum { + MIPI_DSI_V_SYNC_START = 0x01, + MIPI_DSI_V_SYNC_END = 0x11, + MIPI_DSI_H_SYNC_START = 0x21, + MIPI_DSI_H_SYNC_END = 0x31, + + MIPI_DSI_COLOR_MODE_OFF = 0x02, + MIPI_DSI_COLOR_MODE_ON = 0x12, + MIPI_DSI_SHUTDOWN_PERIPHERAL = 0x22, + MIPI_DSI_TURN_ON_PERIPHERAL = 0x32, + + MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM = 0x03, + MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM = 0x13, + MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM = 0x23, + + MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04, + MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14, + MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24, + + MIPI_DSI_DCS_SHORT_WRITE = 0x05, + MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15, + + MIPI_DSI_DCS_READ = 0x06, + + MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37, + + MIPI_DSI_END_OF_TRANSMISSION = 0x08, + + MIPI_DSI_NULL_PACKET = 0x09, + MIPI_DSI_BLANKING_PACKET = 0x19, + MIPI_DSI_GENERIC_LONG_WRITE = 0x29, + MIPI_DSI_DCS_LONG_WRITE = 0x39, + + MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20 = 0x0c, + MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24 = 0x1c, + MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16 = 0x2c, + + MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d, + MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d, + MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12 = 0x3d, + + MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e, + MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e, + MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e, + MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e, +}; + +/* MIPI DSI Peripheral-to-Processor transaction types */ +enum { + MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT = 0x02, + MIPI_DSI_RX_END_OF_TRANSMISSION = 0x08, + MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE = 0x11, + MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE = 0x12, + MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE = 0x1a, + MIPI_DSI_RX_DCS_LONG_READ_RESPONSE = 0x1c, + MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE = 0x21, + MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE = 0x22, +}; + +/* MIPI DCS commands */ +enum { + MIPI_DCS_NOP = 0x00, + MIPI_DCS_SOFT_RESET = 0x01, + MIPI_DCS_GET_DISPLAY_ID = 0x04, + MIPI_DCS_GET_RED_CHANNEL = 0x06, + MIPI_DCS_GET_GREEN_CHANNEL = 0x07, + MIPI_DCS_GET_BLUE_CHANNEL = 0x08, + MIPI_DCS_GET_DISPLAY_STATUS = 0x09, + MIPI_DCS_GET_POWER_MODE = 0x0A, + MIPI_DCS_GET_ADDRESS_MODE = 0x0B, + MIPI_DCS_GET_PIXEL_FORMAT = 0x0C, + MIPI_DCS_GET_DISPLAY_MODE = 0x0D, + MIPI_DCS_GET_SIGNAL_MODE = 0x0E, + MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F, + MIPI_DCS_ENTER_SLEEP_MODE = 0x10, + MIPI_DCS_EXIT_SLEEP_MODE = 0x11, + MIPI_DCS_ENTER_PARTIAL_MODE = 0x12, + MIPI_DCS_ENTER_NORMAL_MODE = 0x13, + MIPI_DCS_EXIT_INVERT_MODE = 0x20, + MIPI_DCS_ENTER_INVERT_MODE = 0x21, + MIPI_DCS_SET_GAMMA_CURVE = 0x26, + MIPI_DCS_SET_DISPLAY_OFF = 0x28, + MIPI_DCS_SET_DISPLAY_ON = 0x29, + MIPI_DCS_SET_COLUMN_ADDRESS = 0x2A, + MIPI_DCS_SET_PAGE_ADDRESS = 0x2B, + MIPI_DCS_WRITE_MEMORY_START = 0x2C, + MIPI_DCS_WRITE_LUT = 0x2D, + MIPI_DCS_READ_MEMORY_START = 0x2E, + MIPI_DCS_SET_PARTIAL_AREA = 0x30, + MIPI_DCS_SET_SCROLL_AREA = 0x33, + MIPI_DCS_SET_TEAR_OFF = 0x34, + MIPI_DCS_SET_TEAR_ON = 0x35, + MIPI_DCS_SET_ADDRESS_MODE = 0x36, + MIPI_DCS_SET_SCROLL_START = 0x37, + MIPI_DCS_EXIT_IDLE_MODE = 0x38, + MIPI_DCS_ENTER_IDLE_MODE = 0x39, + MIPI_DCS_SET_PIXEL_FORMAT = 0x3A, + MIPI_DCS_WRITE_MEMORY_CONTINUE = 0x3C, + MIPI_DCS_READ_MEMORY_CONTINUE = 0x3E, + MIPI_DCS_SET_TEAR_SCANLINE = 0x44, + MIPI_DCS_GET_SCANLINE = 0x45, + MIPI_DCS_READ_DDB_START = 0xA1, + MIPI_DCS_READ_DDB_CONTINUE = 0xA8, +}; + +/* MIPI DCS pixel formats */ +#define MIPI_DCS_PIXEL_FMT_24BIT 7 +#define MIPI_DCS_PIXEL_FMT_18BIT 6 +#define MIPI_DCS_PIXEL_FMT_16BIT 5 +#define MIPI_DCS_PIXEL_FMT_12BIT 3 +#define MIPI_DCS_PIXEL_FMT_8BIT 2 +#define MIPI_DCS_PIXEL_FMT_3BIT 1 + +#endif

On Fri, 9 Jan 2015 12:01:10 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
It provides some constants for DCS commands, which are needed to implement support for SSD2828.
we usually ask for mentioning the exact kernel version (i.e. the commit ID of the kernel tree the file is taken from) in the commit message when code from Linux kernel is imported into U-Boot. Please add this information here. Thanks!
Anatolij

On Fri, 9 Jan 2015 18:15:44 +0100 Anatolij Gustschin agust@denx.de wrote:
On Fri, 9 Jan 2015 12:01:10 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
It provides some constants for DCS commands, which are needed to implement support for SSD2828.
we usually ask for mentioning the exact kernel version (i.e. the commit ID of the kernel tree the file is taken from) in the commit message when code from Linux kernel is imported into U-Boot. Please add this information here. Thanks!
OK, thanks. I'll add this information in the v2 patch.

SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the flight into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported.
The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 421 ++++++++++++++++++++++++++++++++++++++++++++++++ drivers/video/ssd2828.h | 123 ++++++++++++++ 3 files changed, 545 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h
diff --git a/drivers/video/Makefile b/drivers/video/Makefile index d4fe1aa..e29dc4f 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot_fb.o obj-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o obj-$(CONFIG_VIDEO_IMX25LCDC) += imx25lcdc.o videomodes.o +obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o obj-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c new file mode 100644 index 0000000..566ec19 --- /dev/null +++ b/drivers/video/ssd2828.c @@ -0,0 +1,421 @@ +/* + * (C) 2015 Siarhei Siamashka siarhei.siamashka@gmail.com + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +/* + * Support for the SSD2828 bridge chip, which can take pixel data coming + * from a parallel LCD interface and translate it on the flight into MIPI DSI + * interface for driving a MIPI compatible TFT display. + */ + +#include <common.h> +#include <mipi_display.h> +#include <asm/arch/gpio.h> +#include <asm/gpio.h> + +#include "videomodes.h" +#include "ssd2828.h" + +#define SSD2828_DIR 0xB0 +#define SSD2828_VICR1 0xB1 +#define SSD2828_VICR2 0xB2 +#define SSD2828_VICR3 0xB3 +#define SSD2828_VICR4 0xB4 +#define SSD2828_VICR5 0xB5 +#define SSD2828_VICR6 0xB6 +#define SSD2828_CFGR 0xB7 +#define SSD2828_VCR 0xB8 +#define SSD2828_PCR 0xB9 +#define SSD2828_PLCR 0xBA +#define SSD2828_CCR 0xBB +#define SSD2828_PSCR1 0xBC +#define SSD2828_PSCR2 0xBD +#define SSD2828_PSCR3 0xBE +#define SSD2828_PDR 0xBF +#define SSD2828_OCR 0xC0 +#define SSD2828_MRSR 0xC1 +#define SSD2828_RDCR 0xC2 +#define SSD2828_ARSR 0xC3 +#define SSD2828_LCR 0xC4 +#define SSD2828_ICR 0xC5 +#define SSD2828_ISR 0xC6 +#define SSD2828_ESR 0xC7 +#define SSD2828_DAR1 0xC9 +#define SSD2828_DAR2 0xCA +#define SSD2828_DAR3 0xCB +#define SSD2828_DAR4 0xCC +#define SSD2828_DAR5 0xCD +#define SSD2828_DAR6 0xCE +#define SSD2828_HTTR1 0xCF +#define SSD2828_HTTR2 0xD0 +#define SSD2828_LRTR1 0xD1 +#define SSD2828_LRTR2 0xD2 +#define SSD2828_TSR 0xD3 +#define SSD2828_LRR 0xD4 +#define SSD2828_PLLR 0xD5 +#define SSD2828_TR 0xD6 +#define SSD2828_TECR 0xD7 +#define SSD2828_ACR1 0xD8 +#define SSD2828_ACR2 0xD9 +#define SSD2828_ACR3 0xDA +#define SSD2828_ACR4 0xDB +#define SSD2828_IOCR 0xDC +#define SSD2828_VICR7 0xDD +#define SSD2828_LCFR 0xDE +#define SSD2828_DAR7 0xDF +#define SSD2828_PUCR1 0xE0 +#define SSD2828_PUCR2 0xE1 +#define SSD2828_PUCR3 0xE2 +#define SSD2828_CBCR1 0xE9 +#define SSD2828_CBCR2 0xEA +#define SSD2828_CBSR 0xEB +#define SSD2828_ECR 0xEC +#define SSD2828_VSDR 0xED +#define SSD2828_TMR 0xEE +#define SSD2828_GPIO1 0xEF +#define SSD2828_GPIO2 0xF0 +#define SSD2828_DLYA01 0xF1 +#define SSD2828_DLYA23 0xF2 +#define SSD2828_DLYB01 0xF3 +#define SSD2828_DLYB23 0xF4 +#define SSD2828_DLYC01 0xF5 +#define SSD2828_DLYC23 0xF6 +#define SSD2828_ACR5 0xF7 +#define SSD2828_RR 0xFF + +#define SSD2828_CFGR_HS (1 << 0) +#define SSD2828_CFGR_CKE (1 << 1) +#define SSD2828_CFGR_SLP (1 << 2) +#define SSD2828_CFGR_VEN (1 << 3) +#define SSD2828_CFGR_HCLK (1 << 4) +#define SSD2828_CFGR_CSS (1 << 5) +#define SSD2828_CFGR_DCS (1 << 6) +#define SSD2828_CFGR_REN (1 << 7) +#define SSD2828_CFGR_ECD (1 << 8) +#define SSD2828_CFGR_EOT (1 << 9) +#define SSD2828_CFGR_LPE (1 << 10) +#define SSD2828_CFGR_TXD (1 << 11) + +#define SSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_PULSES (0 << 2) +#define SSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS (1 << 2) +#define SSD2828_VIDEO_MODE_BURST (2 << 2) + +#define SSD2828_VIDEO_PIXEL_FORMAT_16BPP 0 +#define SSD2828_VIDEO_PIXEL_FORMAT_18BPP_PACKED 1 +#define SSD2828_VIDEO_PIXEL_FORMAT_18BPP_LOOSELY_PACKED 2 +#define SSD2828_VIDEO_PIXEL_FORMAT_24BPP 3 + +#define SSD2828_LP_CLOCK_DIVIDER(n) (((n) - 1) & 0x3F) + +/* + * SPI transfer, using the "24-bit 3 wire" mode (that's how it is called in + * the SSD2828 documentation). The 'dout' input parameter specifies 24-bits + * of data to be written to SSD2828. Returns the lowest 16-bits of data, + * that is received back. + */ +static u32 soft_spi_xfer_24bit_3wire(const struct ssd2828_config *drv, u32 dout) +{ + int j, bitlen = 24; + u32 tmpdin = 0; + /* + * According to the "24 Bit 3 Wire SPI Interface Timing Characteristics" + * and "TX_CLK Timing Characteristics" tables in the SSD2828 datasheet, + * the lowest possible 'tx_clk' clock frequency is 8MHz, and SPI runs + * at 1/8 of that after reset. So using 1 microsecond delays is safe in + * the main loop. But the delays around chip select pin manipulations + * need to be longer (up to 16 'tx_clk' cycles, or 2 microseconds in + * the worst case). + */ + const int spi_delay_us = 1; + const int spi_cs_delay_us = 2; + + gpio_set_value(drv->csx_pin, 0); + udelay(spi_cs_delay_us); + for (j = bitlen - 1; j >= 0; j--) { + gpio_set_value(drv->sck_pin, 0); + gpio_set_value(drv->sdi_pin, (dout & (1 << j)) != 0); + udelay(spi_delay_us); + if (drv->sdo_pin != -1) + tmpdin = (tmpdin << 1) | gpio_get_value(drv->sdo_pin); + gpio_set_value(drv->sck_pin, 1); + udelay(spi_delay_us); + } + udelay(spi_cs_delay_us); + gpio_set_value(drv->csx_pin, 1); + udelay(spi_cs_delay_us); + return tmpdin & 0xFFFF; +} + +/* + * Read from a SSD2828 hardware register (regnum >= 0xB0) + */ +static u32 read_hw_register(const struct ssd2828_config *cfg, u8 regnum) +{ + soft_spi_xfer_24bit_3wire(cfg, 0x700000 | regnum); + return soft_spi_xfer_24bit_3wire(cfg, 0x730000); +} + +/* + * Write to a SSD2828 hardware register (regnum >= 0xB0) + */ +static void write_hw_register(const struct ssd2828_config *cfg, u8 regnum, + u16 val) +{ + soft_spi_xfer_24bit_3wire(cfg, 0x700000 | regnum); + soft_spi_xfer_24bit_3wire(cfg, 0x720000 | val); +} + +/* + * Send MIPI command to the LCD panel (cmdnum < 0xB0) + */ +static void send_mipi_dcs_command(const struct ssd2828_config *cfg, u8 cmdnum) +{ + /* Set packet size to 1 (a single command with no parameters) */ + write_hw_register(cfg, SSD2828_PSCR1, 1); + /* Send the command */ + write_hw_register(cfg, SSD2828_PDR, cmdnum); +} + +/* + * Reset SSD2828 + */ +static void ssd2828_reset(const struct ssd2828_config *cfg) +{ + /* RESET needs 10 milliseconds according to the datasheet */ + gpio_set_value(cfg->reset_pin, 0); + mdelay(10); + gpio_set_value(cfg->reset_pin, 1); + mdelay(10); +} + +static int ssd2828_enable_gpio(const struct ssd2828_config *cfg) +{ + if (gpio_request(cfg->csx_pin, "ssd2828_csx")) { + printf("SSD2828: request for 'ssd2828_csx' pin failed\n"); + return 1; + } + if (gpio_request(cfg->sck_pin, "ssd2828_sck")) { + gpio_free(cfg->csx_pin); + printf("SSD2828: request for 'ssd2828_sck' pin failed\n"); + return 1; + } + if (gpio_request(cfg->sdi_pin, "ssd2828_sdi")) { + gpio_free(cfg->csx_pin); + gpio_free(cfg->sck_pin); + printf("SSD2828: request for 'ssd2828_sdi' pin failed\n"); + return 1; + } + if (gpio_request(cfg->reset_pin, "ssd2828_reset")) { + gpio_free(cfg->csx_pin); + gpio_free(cfg->sck_pin); + gpio_free(cfg->sdi_pin); + printf("SSD2828: request for 'ssd2828_reset' pin failed\n"); + return 1; + } + if (cfg->sdo_pin != -1 && gpio_request(cfg->sdo_pin, "ssd2828_sdo")) { + gpio_free(cfg->csx_pin); + gpio_free(cfg->sck_pin); + gpio_free(cfg->sdi_pin); + gpio_free(cfg->reset_pin); + printf("SSD2828: request for 'ssd2828_sdo' pin failed\n"); + return 1; + } + gpio_direction_output(cfg->reset_pin, 0); + gpio_direction_output(cfg->csx_pin, 1); + gpio_direction_output(cfg->sck_pin, 1); + gpio_direction_output(cfg->sdi_pin, 1); + if (cfg->sdo_pin != -1) + gpio_direction_input(cfg->sdo_pin); + + return 0; +} + +static int ssd2828_free_gpio(const struct ssd2828_config *cfg) +{ + gpio_free(cfg->csx_pin); + gpio_free(cfg->sck_pin); + gpio_free(cfg->sdi_pin); + gpio_free(cfg->reset_pin); + if (cfg->sdo_pin != -1) + gpio_free(cfg->sdo_pin); + return 1; +} + +/* + * PLL configuration register settings. + * + * See the "PLL Configuration Register Description" in the SSD2828 datasheet. + */ +u32 construct_pll_config(u32 desired_pll_freq_kbps, u32 reference_freq_khz) +{ + u32 div_factor = 1, mul_factor, fr = 0; + u32 output_freq_kbps; + + /* The intermediate clock after division can't be less than 5MHz */ + while (reference_freq_khz / (div_factor + 1) >= 5000) + div_factor++; + if (div_factor > 31) + div_factor = 31; + + mul_factor = DIV_ROUND_UP(desired_pll_freq_kbps * div_factor, + reference_freq_khz); + + output_freq_kbps = reference_freq_khz * mul_factor / div_factor; + + if (output_freq_kbps >= 501000) + fr = 3; + else if (output_freq_kbps >= 251000) + fr = 2; + else if (output_freq_kbps >= 126000) + fr = 1; + + return (fr << 14) | (div_factor << 8) | mul_factor; +} + +static u32 decode_pll_config(u32 pll_config, u32 reference_freq_khz) +{ + u32 mul_factor = pll_config & 0xFF; + u32 div_factor = (pll_config >> 8) & 0x1F; + if (mul_factor == 0) + mul_factor = 1; + if (div_factor == 0) + div_factor = 1; + return reference_freq_khz * mul_factor / div_factor; +} + +static int ssd2828_configure_video_interface(const struct ssd2828_config *cfg, + const struct ctfb_res_modes *mode) +{ + u32 val; + + /* RGB Interface Control Register 1 */ + write_hw_register(cfg, SSD2828_VICR1, (mode->vsync_len << 8) | + (mode->hsync_len)); + + /* RGB Interface Control Register 2 */ + u32 vbp = mode->vsync_len + mode->upper_margin; + u32 hbp = mode->hsync_len + mode->left_margin; + write_hw_register(cfg, SSD2828_VICR2, (vbp << 8) | hbp); + + /* RGB Interface Control Register 3 */ + write_hw_register(cfg, SSD2828_VICR3, (mode->lower_margin << 8) | + (mode->right_margin)); + + /* RGB Interface Control Register 4 */ + write_hw_register(cfg, SSD2828_VICR4, mode->xres); + + /* RGB Interface Control Register 5 */ + write_hw_register(cfg, SSD2828_VICR5, mode->yres); + + /* RGB Interface Control Register 6 */ + val = SSD2828_VIDEO_MODE_BURST; + switch (cfg->ssd2828_color_depth) { + case 16: + val |= SSD2828_VIDEO_PIXEL_FORMAT_16BPP; + break; + case 18: + val |= cfg->mipi_dsi_loosely_packed_pixel_format ? + SSD2828_VIDEO_PIXEL_FORMAT_18BPP_PACKED : + SSD2828_VIDEO_PIXEL_FORMAT_18BPP_LOOSELY_PACKED; + break; + case 24: + val |= SSD2828_VIDEO_PIXEL_FORMAT_24BPP; + break; + default: + printf("SSD2828: unsupported color depth\n"); + return 1; + } + write_hw_register(cfg, SSD2828_VICR6, val); + + /* Lane Configuration Register */ + write_hw_register(cfg, SSD2828_LCFR, + cfg->mipi_dsi_number_of_data_lanes - 1); + + return 0; +} + +int ssd2828_init(const struct ssd2828_config *cfg, + const struct ctfb_res_modes *mode) +{ + u32 lp_div, pll_freq_kbps, pll_config; + /* The LP clock speed is limited by 10MHz */ + const u32 mipi_dsi_low_power_clk_khz = 10000; + /* + * This is just the reset default value of CFGR register (0x301). + * Because we are not always able to read back from SPI, have + * it initialized here. + */ + u32 cfgr_reg = SSD2828_CFGR_EOT | /* EOT Packet Enable */ + SSD2828_CFGR_ECD | /* Disable ECC and CRC */ + SSD2828_CFGR_HS; /* Data lanes are in HS mode */ + + /* Initialize the pins */ + if (ssd2828_enable_gpio(cfg) != 0) + return 1; + + /* Reset the chip */ + ssd2828_reset(cfg); + + /* + * If there is a pin to read data back from SPI, then we are lucky. Try + * to check if SPI is configured correctly and SSD2828 is actually able + * to talk back. + */ + if (cfg->sdo_pin != -1) { + if (read_hw_register(cfg, SSD2828_DIR) != 0x2828 || + read_hw_register(cfg, SSD2828_CFGR) != cfgr_reg) { + printf("SSD2828: SPI communication failed.\n"); + ssd2828_free_gpio(cfg); + return 1; + } + } + + /* + * Setup the parallel LCD timings in the appropriate registers. + */ + if (ssd2828_configure_video_interface(cfg, mode) != 0) { + ssd2828_free_gpio(cfg); + return 1; + } + + /* Configuration Register */ + cfgr_reg &= ~SSD2828_CFGR_HS; /* Data lanes are in LP mode */ + cfgr_reg |= SSD2828_CFGR_CKE; /* Clock lane is in HS mode */ + cfgr_reg |= SSD2828_CFGR_DCS; /* Only use DCS packets */ + write_hw_register(cfg, SSD2828_CFGR, cfgr_reg); + + /* PLL Configuration Register */ + pll_config = construct_pll_config( + cfg->mipi_dsi_bitrate_per_data_lane_mbps * 1000, + cfg->ssd2828_tx_clk_khz); + write_hw_register(cfg, SSD2828_PLCR, pll_config); + + pll_freq_kbps = decode_pll_config(pll_config, cfg->ssd2828_tx_clk_khz); + lp_div = DIV_ROUND_UP(pll_freq_kbps, mipi_dsi_low_power_clk_khz * 8); + + /* VC Control Register */ + write_hw_register(cfg, SSD2828_VCR, 0); + + /* Clock Control Register */ + write_hw_register(cfg, SSD2828_CCR, SSD2828_LP_CLOCK_DIVIDER(lp_div)); + + /* PLL Control Register */ + write_hw_register(cfg, SSD2828_PCR, 1); /* Enable PLL */ + + /* Wait for PLL lock */ + udelay(500); + + send_mipi_dcs_command(cfg, MIPI_DCS_EXIT_SLEEP_MODE); + mdelay(cfg->mipi_dsi_delay_after_exit_sleep_mode_ms); + + send_mipi_dcs_command(cfg, MIPI_DCS_SET_DISPLAY_ON); + mdelay(cfg->mipi_dsi_delay_after_set_display_on_ms); + + cfgr_reg |= SSD2828_CFGR_HS; /* Enable HS mode for data lanes */ + cfgr_reg |= SSD2828_CFGR_VEN; /* Enable video pipeline */ + write_hw_register(cfg, SSD2828_CFGR, cfgr_reg); + + return 0; +} diff --git a/drivers/video/ssd2828.h b/drivers/video/ssd2828.h new file mode 100644 index 0000000..14b96c5 --- /dev/null +++ b/drivers/video/ssd2828.h @@ -0,0 +1,123 @@ +/* + * (C) 2015 Siarhei Siamashka siarhei.siamashka@gmail.com + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +/* + * Support for the SSD2828 bridge chip, which can take pixel data coming + * from a parallel LCD interface and translate it on the flight into MIPI DSI + * interface for driving a MIPI compatible TFT display. + * + * Implemented as a utility function. To be used from display drivers, which are + * responsible for driving parallel LCD hardware in front of the video pipeline. + */ + +#ifndef _SSD2828_H +#define _SSD2828_H + +struct ctfb_res_modes; + +struct ssd2828_config { + /*********************************************************************/ + /* SSD2828 configuration */ + /*********************************************************************/ + + /* + * The pins, which are used for SPI communication. This is only used + * for configuring SSD2828, so the performance is irrelevant (only + * around a hundred of bytes is moved). Also these can be any arbitrary + * GPIO pins (not necessarily the pins having hardware SPI function). + * Moreover, the 'sdo' pin may be even not wired up in some devices. + * + * These configuration variables need to be set as pin numbers for + * the standard u-boot GPIO interface (gpio_get_value/gpio_set_value + * functions). Note that -1 value can be used for the pins, which are + * not really wired up. + */ + int csx_pin; + int sck_pin; + int sdi_pin; + int sdo_pin; + /* SSD2828 reset pin (shared with LCD panel reset) */ + int reset_pin; + + /* + * The SSD2828 has its own dedicated clock source 'tx_clk' (connected + * to TX_CLK_XIO/TX_CLK_XIN pins), which is necessary at least for + * clocking SPI after reset. The exact clock speed is not strictly, + * defined, but the datasheet says that it must be somewhere in the + * 8MHz - 30MHz range (see "TX_CLK Timing" section). It is used as + * a reference clock for PLL and must be set correctly. + */ + int ssd2828_tx_clk_khz; + + /* + * This is not a property of the used LCD panel, but more like a + * property of the SSD2828 wiring. See the "SSD2828QN4 RGB data + * arrangement" table in the datasheet. The SSD2828 pins are arranged + * in such a way that 18bpp and 24bpp configurations are completely + * incompatible with each other. + * + * Depending on the color depth, this must be set to 16, 18 or 24. + */ + int ssd2828_color_depth; + + /*********************************************************************/ + /* LCD panel configuration */ + /*********************************************************************/ + + /* + * The number of lanes in the MIPI DSI interface. May vary from 1 to 4. + * + * This information can be found in the LCD panel datasheet. + */ + int mipi_dsi_number_of_data_lanes; + + /* + * Data transfer bit rate per lane. Please note that it is expected + * to be higher than the pixel clock rate of the used video mode when + * multiplied by the number of lanes. This is perfectly normal because + * MIPI DSI handles data transfers in periodic bursts, and uses the + * idle time between bursts for sending configuration information and + * commands. Or just for saving power. + * + * The necessary Mbps/lane information can be found in the LCD panel + * datasheet. Note that the transfer rate can't be always set precisely + * and it may be rounded *up* (introducing no more than 10Mbps error). + */ + int mipi_dsi_bitrate_per_data_lane_mbps; + + /* + * Setting this to 1 enforces packing of 18bpp pixel data in 24bpp + * envelope when sending it over the MIPI DSI link. + * + * If unsure, set to 0. + */ + int mipi_dsi_loosely_packed_pixel_format; + + /* + * According to the "Example for system sleep in and out" section in + * the SSD2828 datasheet, some LCD panel specific delays are necessary + * after MIPI DCS commands EXIT_SLEEP_MODE and SET_DISPLAY_ON. + * + * For example, Allwinner uses 100 milliseconds delay after + * EXIT_SLEEP_MODE and 200 milliseconds delay after SET_DISPLAY_ON. + */ + int mipi_dsi_delay_after_exit_sleep_mode_ms; + int mipi_dsi_delay_after_set_display_on_ms; +}; + +/* + * Initialize the SSD2828 chip. It needs the 'ssd2828_config' structure + * and also the video mode timings. + * + * The right place to insert this function call is after the parallel LCD + * interface is initialized and before turning on the backlight. This is + * advised in the "Example for system sleep in and out" section of the + * SSD2828 datasheet. + */ +int ssd2828_init(const struct ssd2828_config *cfg, + const struct ctfb_res_modes *mode); + +#endif

On Fri, 9 Jan 2015 12:01:11 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the flight into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported.
The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
Acked-by: Anatolij Gustschin agust@denx.de

Expose the necessary configuration parameters in Kconfig. Add SSD2828 initialization between enabling the parallel LCD interface and turning on the backlight.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- board/sunxi/Kconfig | 60 +++++++++++++++++++++++++++++++++++++++++ drivers/video/sunxi_display.c | 3 +++ drivers/video/sunxi_lcd_panel.c | 38 ++++++++++++++++++++++++++ drivers/video/sunxi_lcd_panel.h | 3 +++ 4 files changed, 104 insertions(+)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index adee5ed..92dbce7 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -345,6 +345,60 @@ config VIDEO_LCD_BL_PWM Set the backlight pwm pin for the LCD panel. This takes a string in the format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+config VIDEO_LCD_SPI_CS + string "SPI CS pin for LCD related config job" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_SCLK + string "SPI SCLK pin for LCD related config job" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_MOSI + string "SPI MOSI pin for LCD related config job" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SPI_MISO + string "SPI MISO pin for LCD related config job (optional)" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. If wired up, this pin may provide additional + useful functionality. Such as bi-directional communication with the + hardware and LCD panel id retrieval (if the panel can report it). The + option takes a string in the format understood by sunxi_name_to_gpio, + e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SSD2828_RESET + string "RESET pin of SSD2828" + depends on VIDEO_LCD_SSD2828 + default "" + ---help--- + The reset pin of SSD2828 chip. This takes a string in the format + understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H. + +config VIDEO_LCD_SSD2828 + bool + select VIDEO_LCD_IF_PARALLEL
# Note only one of these may be selected at a time! But hidden choices are # not supported by Kconfig @@ -373,6 +427,12 @@ config VIDEO_LCD_PANEL_HITACHI_TX18D42VM bool "Hitachi tx18d42vm LCD panel" select VIDEO_LCD_IF_LVDS
+config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828 + bool "MIPI 4-lane, 513Mbps LCD panel via SSD2828 bridge chip" + select VIDEO_LCD_SSD2828 + ---help--- + 7.85" 768x1024 LCD panels, such as LG LP079X01 or AUO B079XAN01.0 + endchoice
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c index c3fc732..f11b241 100644 --- a/drivers/video/sunxi_display.c +++ b/drivers/video/sunxi_display.c @@ -850,6 +850,9 @@ static void sunxi_mode_set(const struct ctfb_res_modes *mode, sunxi_lcdc_tcon0_mode_set(mode); sunxi_composer_enable(); sunxi_lcdc_enable(); +#ifdef CONFIG_VIDEO_LCD_SSD2828 + sunxi_ssd2828_init(mode); +#endif sunxi_lcdc_backlight_enable(); break; case sunxi_monitor_vga: diff --git a/drivers/video/sunxi_lcd_panel.c b/drivers/video/sunxi_lcd_panel.c index 9ebaff2..cdde639 100644 --- a/drivers/video/sunxi_lcd_panel.c +++ b/drivers/video/sunxi_lcd_panel.c @@ -11,6 +11,8 @@ #include <asm/arch/gpio.h> #include <asm/gpio.h> #include <asm/io.h> +#include "sunxi_lcd_panel.h" +#include "ssd2828.h"
#ifdef CONFIG_VIDEO_LCD_PANEL_HITACHI_TX18D42VM
@@ -66,3 +68,39 @@ void sunxi_lcd_panel_hitachi_tx18d42vm_init(void) }
#endif + +#ifdef CONFIG_VIDEO_LCD_SSD2828 + +int sunxi_ssd2828_init(const struct ctfb_res_modes *mode) +{ + struct ssd2828_config cfg = { + .csx_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_CS), + .sck_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_SCLK), + .sdi_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_MOSI), + .sdo_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_MISO), + .reset_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SSD2828_RESET), + .ssd2828_tx_clk_khz = 27000, + .ssd2828_color_depth = 24, +#ifdef CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828 + .mipi_dsi_number_of_data_lanes = 4, + .mipi_dsi_bitrate_per_data_lane_mbps = 513, + .mipi_dsi_delay_after_exit_sleep_mode_ms = 100, + .mipi_dsi_delay_after_set_display_on_ms = 200 +#else +#error MIPI LCD panel needs configuration parameters +#endif + }; + + if (cfg.csx_pin == -1 || cfg.sck_pin == -1 || cfg.sdi_pin == -1) { + printf("SSD2828: SPI pins are not properly configured\n"); + return 1; + } + if (cfg.reset_pin == -1) { + printf("SSD2828: Reset pin is not properly configured\n"); + return 1; + } + + return ssd2828_init(&cfg, mode); +} + +#endif diff --git a/drivers/video/sunxi_lcd_panel.h b/drivers/video/sunxi_lcd_panel.h index 1fb9f1e..8b1bc14 100644 --- a/drivers/video/sunxi_lcd_panel.h +++ b/drivers/video/sunxi_lcd_panel.h @@ -6,4 +6,7 @@ * SPDX-License-Identifier: GPL-2.0+ */
+struct ctfb_res_modes; + void sunxi_lcd_panel_hitachi_tx18d42vm_init(void); +int sunxi_ssd2828_init(const struct ctfb_res_modes *mode);

On Fri, 9 Jan 2015 12:01:12 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote: ...
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index adee5ed..92dbce7 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -345,6 +345,60 @@ config VIDEO_LCD_BL_PWM Set the backlight pwm pin for the LCD panel. This takes a string in the format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+config VIDEO_LCD_SPI_CS
- string "SPI CS pin for LCD related config job"
- depends on VIDEO_LCD_SSD2828
- default ""
- ---help---
- This is one of the SPI communication pins, involved in setting up a
- working LCD configuration. The exact role of SPI may differ for
- different hardware setups. The option takes a string in the format
- understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
please address comments from Hans regarding the Kconfig changes.
Thanks,
Anatolij

The MSI Primo81 tablet has B079XAN01/LP079X01 7.85" 768x1024 IPS MIPI display, connected to the parallel LCD interface via SSD2828 bridge chip. The panel has 18-bit color depth and needs dithering, in spite of having RGB data delivered from A31s to SSD2828 using 24-bit arrangement.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- configs/MSI_Primo81_defconfig | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/configs/MSI_Primo81_defconfig b/configs/MSI_Primo81_defconfig index b4b0f6d..1be6016 100644 --- a/configs/MSI_Primo81_defconfig +++ b/configs/MSI_Primo81_defconfig @@ -1,6 +1,15 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="" CONFIG_FDTFILE="sun6i-a31s-primo81.dtb" +CONFIG_VIDEO_LCD_MODE="x:768,y:1024,depth:18,pclk_khz:66000,le:56,ri:60,up:30,lo:36,hs:64,vs:50,sync:3,vmode:0" +CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828=y +CONFIG_VIDEO_LCD_SSD2828_RESET="PA26" +CONFIG_VIDEO_LCD_SPI_CS="PH9" +CONFIG_VIDEO_LCD_SPI_SCLK="PH10" +CONFIG_VIDEO_LCD_SPI_MOSI="PH11" +CONFIG_VIDEO_LCD_SPI_MISO="PH12" +CONFIG_VIDEO_LCD_BL_EN="PA25" +CONFIG_VIDEO_LCD_BL_PWM="PH13" CONFIG_USB_KEYBOARD=n +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y

On Fri, 9 Jan 2015 12:01:13 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
The MSI Primo81 tablet has B079XAN01/LP079X01 7.85" 768x1024 IPS MIPI display, connected to the parallel LCD interface via SSD2828 bridge chip. The panel has 18-bit color depth and needs dithering, in spite of having RGB data delivered from A31s to SSD2828 using 24-bit arrangement.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
Acked-by: Anatolij Gustschin agust@denx.de

Instead of using the internal 'tx_clk' clock source, it is also possible to use the pixel clock signal from the parallel LCD interface ('pclk') as the reference clock for PLL.
The 'tx_clk' clock speed may be different on different boards/devices (the allowed range is 8MHz - 30MHz). Which is not very convenient, especially considering the need to know the exact 'tx_clk' clock speed. Which may be difficult to identify without having device schematics and/or accurate documentation/sources every time.
Using 'pclk' is free from all these problems.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- drivers/video/ssd2828.c | 20 +++++++++++++++++--- drivers/video/ssd2828.h | 11 ++++++++--- 2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c index 566ec19..702afd9 100644 --- a/drivers/video/ssd2828.c +++ b/drivers/video/ssd2828.c @@ -339,7 +339,7 @@ static int ssd2828_configure_video_interface(const struct ssd2828_config *cfg, int ssd2828_init(const struct ssd2828_config *cfg, const struct ctfb_res_modes *mode) { - u32 lp_div, pll_freq_kbps, pll_config; + u32 lp_div, pll_freq_kbps, reference_freq_khz, pll_config; /* The LP clock speed is limited by 10MHz */ const u32 mipi_dsi_low_power_clk_khz = 10000; /* @@ -373,6 +373,20 @@ int ssd2828_init(const struct ssd2828_config *cfg, }
/* + * Pick the reference clock for PLL. If we know the exact 'tx_clk' + * clock speed, then everything is good. If not, then we can fallback + * to 'pclk' (pixel clock from the parallel LCD interface). In the + * case of using this fallback, it is necessary to have parallel LCD + * already initialized and running at this point. + */ + reference_freq_khz = cfg->ssd2828_tx_clk_khz; + if (reference_freq_khz == 0) { + reference_freq_khz = mode->pixclock_khz; + /* Use 'pclk' as the reference clock for PLL */ + cfgr_reg |= SSD2828_CFGR_CSS; + } + + /* * Setup the parallel LCD timings in the appropriate registers. */ if (ssd2828_configure_video_interface(cfg, mode) != 0) { @@ -389,10 +403,10 @@ int ssd2828_init(const struct ssd2828_config *cfg, /* PLL Configuration Register */ pll_config = construct_pll_config( cfg->mipi_dsi_bitrate_per_data_lane_mbps * 1000, - cfg->ssd2828_tx_clk_khz); + reference_freq_khz); write_hw_register(cfg, SSD2828_PLCR, pll_config);
- pll_freq_kbps = decode_pll_config(pll_config, cfg->ssd2828_tx_clk_khz); + pll_freq_kbps = decode_pll_config(pll_config, reference_freq_khz); lp_div = DIV_ROUND_UP(pll_freq_kbps, mipi_dsi_low_power_clk_khz * 8);
/* VC Control Register */ diff --git a/drivers/video/ssd2828.h b/drivers/video/ssd2828.h index 14b96c5..1af6fa4 100644 --- a/drivers/video/ssd2828.h +++ b/drivers/video/ssd2828.h @@ -47,8 +47,12 @@ struct ssd2828_config { * to TX_CLK_XIO/TX_CLK_XIN pins), which is necessary at least for * clocking SPI after reset. The exact clock speed is not strictly, * defined, but the datasheet says that it must be somewhere in the - * 8MHz - 30MHz range (see "TX_CLK Timing" section). It is used as - * a reference clock for PLL and must be set correctly. + * 8MHz - 30MHz range (see "TX_CLK Timing" section). It can be also + * used as a reference clock for PLL. If the exact clock frequency + * is known, then it can be specified here. If it is unknown, or the + * information is not trustworthy, then it can be set to 0. + * + * If unsure, set to 0. */ int ssd2828_tx_clk_khz;
@@ -115,7 +119,8 @@ struct ssd2828_config { * The right place to insert this function call is after the parallel LCD * interface is initialized and before turning on the backlight. This is * advised in the "Example for system sleep in and out" section of the - * SSD2828 datasheet. + * SSD2828 datasheet. And also SS2828 may use 'pclk' as the clock source + * for PLL, which means that the input signal must be already there. */ int ssd2828_init(const struct ssd2828_config *cfg, const struct ctfb_res_modes *mode);

On Fri, 9 Jan 2015 12:01:14 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
Instead of using the internal 'tx_clk' clock source, it is also possible to use the pixel clock signal from the parallel LCD interface ('pclk') as the reference clock for PLL.
The 'tx_clk' clock speed may be different on different boards/devices (the allowed range is 8MHz - 30MHz). Which is not very convenient, especially considering the need to know the exact 'tx_clk' clock speed. Which may be difficult to identify without having device schematics and/or accurate documentation/sources every time.
Using 'pclk' is free from all these problems.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
Acked-by: Anatolij Gustschin agust@denx.de

So that we don't need to keep it as a hardcoded magic number in the code or the hassle exposing it as a Kconfig option.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- drivers/video/sunxi_lcd_panel.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/drivers/video/sunxi_lcd_panel.c b/drivers/video/sunxi_lcd_panel.c index cdde639..ebc0ca5 100644 --- a/drivers/video/sunxi_lcd_panel.c +++ b/drivers/video/sunxi_lcd_panel.c @@ -79,7 +79,6 @@ int sunxi_ssd2828_init(const struct ctfb_res_modes *mode) .sdi_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_MOSI), .sdo_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_MISO), .reset_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SSD2828_RESET), - .ssd2828_tx_clk_khz = 27000, .ssd2828_color_depth = 24, #ifdef CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828 .mipi_dsi_number_of_data_lanes = 4,

On Fri, 9 Jan 2015 12:01:15 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
So that we don't need to keep it as a hardcoded magic number in the code or the hassle exposing it as a Kconfig option.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
Acked-by: Anatolij Gustschin agust@denx.de

Or at least try to do this. With the possibility of bi-directional communication, it seems natural to expect that MIPI displays should be able to handle automatic configuration for the screen resolution and timings nicely. But the reality is not so pretty.
It appears that the manufacturers of MIPI LCD panels are not very disciplined and do not follow any kind of standard guidelines when it comes to providing the panel identification information. MIPI DSI even has two alternative standard DCS commands for potentially reading the vendor/panel id: MIPI_DCS_GET_DISPLAY_ID and MIPI_DCS_READ_DDB_START. But these commands do not seem to be widely implemented in real hardware. Moreover, the vendors seem to sometimes invent their own custom new commands, while ignoring the standard ones.
This particular patch just probes both of the standard DCS commands and also a few non-standard ones. With the hope to actually extract anything unique and/or meaningful from the LCD panel. This information is then printed to the u-boot console.
We don't know what the future brings. Maybe the manufacturers are going to start acting responsibly some day. And will implement proper panel identification.
Regarding what we have right now. The information retrieval DCS commands still work if reducing the clock speed to the very minimum and enabling only one lane on my MSI Primo81 tablet. Potentially it means that one could perhaps swap two different MIPI LCD panels (if they have a compatible connector) and still have the software handling this fine by doing runtime selection of the right settings (based on checking the panel id).
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com --- drivers/video/ssd2828.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 140 insertions(+)
diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c index 702afd9..cfebedd 100644 --- a/drivers/video/ssd2828.c +++ b/drivers/video/ssd2828.c @@ -98,6 +98,9 @@ #define SSD2828_CFGR_LPE (1 << 10) #define SSD2828_CFGR_TXD (1 << 11)
+#define SSD2828_ISR_READ_DATA_READY (1 << 0) +#define SSD2828_ISR_BTA_RESPONSE (1 << 2) + #define SSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_PULSES (0 << 2) #define SSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS (1 << 2) #define SSD2828_VIDEO_MODE_BURST (2 << 2) @@ -167,6 +170,30 @@ static void write_hw_register(const struct ssd2828_config *cfg, u8 regnum, soft_spi_xfer_24bit_3wire(cfg, 0x720000 | val); }
+static int await_completion(const struct ssd2828_config *cfg, + u8 reg, u32 mask, u32 val) +{ + unsigned long tmo = timer_get_us() + 100000; + + while ((read_hw_register(cfg, reg) & mask) != val) { + if (timer_get_us() > tmo) + return 1; + } + return 0; +} + +static int await_bits_set(const struct ssd2828_config *cfg, + u8 reg, u32 val) +{ + return await_completion(cfg, reg, val, val); +} + +static int await_bits_clear(const struct ssd2828_config *cfg, + u8 reg, u32 val) +{ + return await_completion(cfg, reg, val, 0); +} + /* * Send MIPI command to the LCD panel (cmdnum < 0xB0) */ @@ -179,6 +206,79 @@ static void send_mipi_dcs_command(const struct ssd2828_config *cfg, u8 cmdnum) }
/* + * Sends a MIPI DCS command to retrieve information from the LCD panel. + */ +static int send_mipi_dcs_read_command(const struct ssd2828_config *cfg, + u8 cmdnum, + u8 *result_buf, + int bufsize) +{ + int size, i, result = 0; + /* Save CFGR register */ + u32 old_cfgr = read_hw_register(cfg, SSD2828_CFGR); + + /* Set the read enable bit */ + write_hw_register(cfg, SSD2828_CFGR, old_cfgr | SSD2828_CFGR_REN); + /* Clear buffers and bring the state machine to its initial state */ + write_hw_register(cfg, SSD2828_OCR, 1); + if (await_bits_clear(cfg, SSD2828_OCR, 1) != 0) + goto err; + /* Clear the RW1C bits in the ISR register */ + write_hw_register(cfg, SSD2828_ISR, read_hw_register(cfg, SSD2828_ISR)); + + /* Set the payload size (only the DCS command itself) */ + write_hw_register(cfg, SSD2828_PSCR1, 1); + /* Set maximum return size */ + write_hw_register(cfg, SSD2828_MRSR, bufsize); + /* Write the command */ + write_hw_register(cfg, SSD2828_PDR, cmdnum); + + /* Wait for the response */ + if (await_bits_set(cfg, SSD2828_ISR, SSD2828_ISR_BTA_RESPONSE) != 0) + goto err; /* Timeout */ + + /* Check if there is anything in the read buffer */ + if (!(read_hw_register(cfg, SSD2828_ISR) & SSD2828_ISR_READ_DATA_READY)) + goto err; /* There is no data to read */ + + /* The size of the response packet */ + size = read_hw_register(cfg, SSD2828_RDCR); + if (size > bufsize) { + debug("SSD2828: Suspicious packet size.\n"); + size = bufsize; + } + result = size; + + /* + * This is somewhat special and does not seem to be well documented: + * 1) In order to properly read the data, all the buffer must be read + * in one go without any interruptions. For example, using individual + * reads done by the "read_hw_register" function only result in + * repeatedly getting all the same first 16-bits of data without + * advancing. + * 2) In order to empty the buffer, it is necessary to read as much + * data as was initially configured in the MRSR register. The real + * size of the packet in the RDCR register just indicates how much + * of it is actually valid. + */ + soft_spi_xfer_24bit_3wire(cfg, 0x700000 | SSD2828_RR); + for (i = 0; i < (bufsize + 1) / 2; i++) { + u16 data = soft_spi_xfer_24bit_3wire(cfg, 0x730000); + if (size-- > 0) + *result_buf++ = data & 0xFF; + if (size-- > 0) + *result_buf++ = (data >> 8) & 0xFF; + } + + if (read_hw_register(cfg, SSD2828_ISR) & SSD2828_ISR_READ_DATA_READY) + debug("SSD2828: There is still some bogus unread data.\n"); +err: + /* Restore CFGR register */ + write_hw_register(cfg, SSD2828_CFGR, old_cfgr); + return result; +} + +/* * Reset SSD2828 */ static void ssd2828_reset(const struct ssd2828_config *cfg) @@ -336,6 +436,42 @@ static int ssd2828_configure_video_interface(const struct ssd2828_config *cfg, return 0; }
+static void ssd2828_report_dcs_read_result(const struct ssd2828_config *cfg, + u8 cmd) +{ + u8 buf[64]; + int size, i; + size = send_mipi_dcs_read_command(cfg, cmd, buf, sizeof(buf)); + if (size > 0) { + printf("DCS command 0x%02X returned %2d bytes:", cmd, size); + for (i = 0; i < size; i++) + printf(" %02X", buf[i]); + printf("\n"); + } +} + +/* + * Try to use different DCS commands to identify the panel id and + * report it in the log. + */ +static void ssd2828_report_panel_id(const struct ssd2828_config *cfg) +{ + printf("Trying standard MIPI DSI commands to identify LCD panel:\n"); + + ssd2828_report_dcs_read_result(cfg, MIPI_DCS_GET_DISPLAY_ID); + ssd2828_report_dcs_read_result(cfg, MIPI_DCS_READ_DDB_START); + + printf("Trying nonstandard MIPI DSI commands to identify LCD panel:\n"); + + /* Used by some LG panels (for example, LH350WS1-SD02.pdf) */ + ssd2828_report_dcs_read_result(cfg, 0xB1); + + /* Used by many LCD panels (for example, DA8620.pdf) */ + ssd2828_report_dcs_read_result(cfg, 0xDA); + ssd2828_report_dcs_read_result(cfg, 0xDB); + ssd2828_report_dcs_read_result(cfg, 0xDC); +} + int ssd2828_init(const struct ssd2828_config *cfg, const struct ctfb_res_modes *mode) { @@ -424,6 +560,10 @@ int ssd2828_init(const struct ssd2828_config *cfg, send_mipi_dcs_command(cfg, MIPI_DCS_EXIT_SLEEP_MODE); mdelay(cfg->mipi_dsi_delay_after_exit_sleep_mode_ms);
+ /* If it is possible to read back, then try to retrieve the panel id */ + if (cfg->sdo_pin != -1) + ssd2828_report_panel_id(cfg); + send_mipi_dcs_command(cfg, MIPI_DCS_SET_DISPLAY_ON); mdelay(cfg->mipi_dsi_delay_after_set_display_on_ms);

On Fri, 9 Jan 2015 12:01:08 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
Hello,
This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet.
The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far.
The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet.
This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository.
And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg
Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
board/sunxi/Kconfig | 60 +++++ board/sunxi/board.c | 1 + configs/MSI_Primo81_defconfig | 9 + drivers/power/Kconfig | 10 + drivers/power/axp221.c | 51 ++++ drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 575 ++++++++++++++++++++++++++++++++++++++++ drivers/video/ssd2828.h | 128 +++++++++ drivers/video/sunxi_display.c | 3 + drivers/video/sunxi_lcd_panel.c | 37 +++ drivers/video/sunxi_lcd_panel.h | 3 + include/axp221.h | 9 + include/mipi_display.h | 130 +++++++++ 13 files changed, 1017 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h create mode 100644 include/mipi_display.h
Also a short recap of the events from the last days, which led to this patch set: 1. Trying to see what needs to be done to support LCD on the MSI Primo81 tablet, I had a look into the Allwinner android kernel code from the A31 SDK. That code was pushing a small semi-magic blob through SPI, interleaved with a few magic delays. In fact the Allwinner code supports two different LCD panels in this way (768x1024 and another one 1280x800), each panel having its own blob.
2. The most useful part of the Allwinner code was a reference to "ssd2828_rst", which gave away the name of the chip. Having the documentation for the hardware is great, because it allows to at least convert the magic numbers into proper named constants.
3. Also it turned out that the MISO pin is actually wired up in the MSI Primo81 tablet, even though the Allwinner android code never uses it and there are no references to this pin in the FEX file. So the SSD2828 hardware can actually talk back, and it was really easy to confirm that the hardware was indeed SSD2828.
4. If the SSD2828 chip can talk back, then maybe the LCD panel can talk back too? The B079XAN01.0 LCD panel datasheet had a teaser notice in the "Power ON/OFF Sequence" section: "HS clock enable to vendor ID reading".
5. Now the question is: how to do this vendor ID reading? In fact MIPI specifies some standard commands exactly for this. So everything is supposedly very easy. Except that trying to use the standard panel id retrieval commands resulted in the panel just responding with a single zero byte. This (mis)led me to believe that there might have been something wrong with the clock speed setting, PHY tuning delays or other things, which could cause some sort of transmission failures in the reverse direction. Especially considering the hints that tLPX(MASTER) and tLPX(SLAVE) must be accurately matched.
6. Been reading a mountain of various MIPI related information about the communication protocol on both the PHY and higher level...
7. As nothing seemed to be obviously wrong, tried to search for the MIPI vendor ID reading methods again. Found hints that the vendors tend to be (ab)using the DCS commands and inventing something of their own. Such as http://e2e.ti.com/support/embedded/linux/f/354/t/59206 http://www.allshore.com/pdf/DA8620.pdf LH350WS1-SD02.pdf
8. Tried to scan all the space of possible DCS commands and see what they may possibly return: DCS command 0xB1 returned 15 bytes: A1 95 19 19 00 00 00 00 00 00 00 00 37 10 00 DCS command 0xBD returned 2 bytes: 20 0E DCS command 0xC4 returned 2 bytes: 15 00 This is actually somewhat dangerious, because there is a risk to encounter some sort of a "self destruct" command. Still the question is open about how to interpret this information. It does not look like anything matching the vendor id codes from http://mid.mipi.org/
9. Stopped experiments and just sent the patches :-)

Hi,
On 09-01-15 11:01, Siarhei Siamashka wrote:
Hello,
This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet.
The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far.
The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet.
This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository.
And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg
Cool :)
Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
Thanks for working on this!
Overall this looks good. Looks like you did a better job then I did with the Hitachi tx18d42vm LCD panel support, esp. wrt making things generic rather then sunxi specific.
So assuming the Ian will ack v2 of my lvds patch I suggest that we merge my lvds patch, then your patches (pending an ack from Anatolij) and then I respin my "Hitachi tx18d42vm LCD panel" patch following your patches as an example.
I've also reviewed all of your patches. I've one change request, can you please move all of the board/sunxi/Kconfig changes except for the last hunk to drivers/video/Kconfig, if we go the generic route we should also make the Kconfig stuff generic. This also means dropping the "select VIDEO_LCD_IF_PARALLEL" from "config VIDEO_LCD_SSD2828" and adding it to "config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828", as that option is the only one which will stay in board/sunxi/Kconfig and VIDEO_LCD_IF_PARALLEL is sunxi specific.
The changes to drivers/video/Kconfig should then become part of the "video: Add support for SSD2828 (parallel LCD to MIPI bridge)" commit.
With that changed patches 1-7 are:
Acked-by: Hans de Goede hdegoede@redhat.com
I'm not 100% sure about patch 8, I can see this being useful for debugging but not for normal use, and as you said it may (theoretically) be unsafe with some panels. Maybe keep the patch, but #ifdef DEBUG the entire code block it adds ?
Regards,
Hans

Hi,
On 09-01-15 16:35, Hans de Goede wrote:
Hi,
On 09-01-15 11:01, Siarhei Siamashka wrote:
Hello,
This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet.
The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far.
The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet.
This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository.
And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg
Cool :)
I've just pushed v2 of my lvds-patch to u-boot-sunxi/next with Anatolij's ack, and I see that Anatolij has also reviewed this series, when you do a v2 please base it on top of u-boot-sunxi/next.
Thanks,
Hans

On Fri, 2015-01-09 at 16:35 +0100, Hans de Goede wrote:
So assuming the Ian will ack v2 of my lvds patch
Just done, assuming those were the patches you meant...
With that changed patches 1-7 are:
Acked-by: Hans de Goede hdegoede@redhat.com
Hence I wasn't planning on looking into this series further, please let me know if my opinion is wanted...
Ian.

On Fri, 09 Jan 2015 16:35:09 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 09-01-15 11:01, Siarhei Siamashka wrote:
Hello,
This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet.
The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far.
The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet.
This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository.
And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg
Cool :)
Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
Thanks for working on this!
Overall this looks good. Looks like you did a better job then I did with the Hitachi tx18d42vm LCD panel support, esp. wrt making things generic rather then sunxi specific.
So assuming the Ian will ack v2 of my lvds patch I suggest that we merge my lvds patch, then your patches (pending an ack from Anatolij) and then I respin my "Hitachi tx18d42vm LCD panel" patch following your patches as an example.
I've also reviewed all of your patches. I've one change request, can you please move all of the board/sunxi/Kconfig changes except for the last hunk to drivers/video/Kconfig, if we go the generic route we should also make the Kconfig stuff generic. This also means dropping the "select VIDEO_LCD_IF_PARALLEL" from "config VIDEO_LCD_SSD2828" and adding it to "config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828", as that option is the only one which will stay in board/sunxi/Kconfig and VIDEO_LCD_IF_PARALLEL is sunxi specific.
The changes to drivers/video/Kconfig should then become part of the "video: Add support for SSD2828 (parallel LCD to MIPI bridge)" commit.
Thanks. This sounds like a good plan. Will do it.
With that changed patches 1-7 are:
Acked-by: Hans de Goede hdegoede@redhat.com
I'm not 100% sure about patch 8, I can see this being useful for debugging but not for normal use, and as you said it may (theoretically) be unsafe with some panels. Maybe keep the patch, but #ifdef DEBUG the entire code block it adds ?
I'm also somewhat disappointed by the panel id reading functionality provided by MIPI. I surely had better expectations. But the standard MIPI_DCS_GET_DISPLAY_ID and MIPI_DCS_READ_DDB_START commands still could be safely used, even though they do not happen to return anything interesting on MSI Primo81.
The non-standard commands are indeed potentially unsafe and could be probably hidden under a Kconfig option (are we adding too many of them?) or under #ifdef DEBUG.
After posting the patch series, I have also noticed that the http://linux-sunxi.org/ICOU_Fatty_I tablet is also using SSD2828. Appears that 'lcd_if=4' in the A20 FEX dialect means the same as 'lcd_if=6' in the A31 FEX dialect. This Fatty tablet is using 6 gpio pins for LCD configuration (compared to just 4 pins in Primo81). One is an extra reset pin (ssd2828 reset and lcd panel reset are handled separately). One more pin is set as output and driven low (maybe something related to enabling ssd2828 power on A20?). I have contacted the tablet owner to ask about this tablet whereabouts and would really like to get test results from this Fatty tablet before landing the ssd2828 patches. Hopefully it's a matter of a few days at most.
Additionally, the Allwinner reference A20 tablet schematics ("a20_pad_std_v1_1.pdf" on the Internet) has a page dedicated to the use of SSD2828QN4, which is very insightful. I wish I had discovered this earlier.
participants (4)
-
Anatolij Gustschin
-
Hans de Goede
-
Ian Campbell
-
Siarhei Siamashka