video: Add support for SSD2828 (parallel LCD to MIPI bridge)
Subsystems (3)
cover 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
Signature · 1 line
2.0.5
PATCH 1/8 sunxi: axp221: Add ELDO[1-3] support
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.
--- board/sunxi/board.c | 1 + drivers/power/Kconfig | 10 ++++++++++ drivers/power/axp221.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/axp221.h | 9 +++++++++ 4 files changed, 71 insertions(+)
board/sunxi/board.c +1 -0
@@ -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:" );
drivers/power/Kconfig +10 -0
@@ -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).
drivers/power/axp221.c +51 -0
57 lines not on this page · raw message
include/axp221.h +9 -0
@@ -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);
Signature · 1 line
2.0.5
PATCH 1/8 sunxi: axp221: Add ELDO[1-3] support
On Fri, 9 Jan 2015 12:01:09 +0200
Siarhei Siamashka <[email protected]> wrote:
...
Quoted 23 lines
drivers/power/axp221.c +23
-0+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 )
drivers/power/axp221.c int axp221_set_aldo3(unsigned int mvolt) · line 354
Quoted 10 lines
drivers/power/axp221.c +10
-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
PATCH 1/8 sunxi: axp221: Add ELDO[1-3] support
Quoted 63 lines · On Fri, 9 Jan 2015 18:05:35 +0100 Anatolij Gustschin <[email protected]> wrote:
On Fri, 9 Jan 2015 12:01:09 +0200
Siarhei Siamashka <[email protected]> wrote:
...Quoted 23 lines
drivers/power/axp221.c +23
-0+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 )drivers/power/axp221.c int axp221_set_aldo3(unsigned int mvolt) · line 354
Quoted 10 lines
drivers/power/axp221.c +10
-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)
Quoted 8 lines
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.
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH 1/8 sunxi: axp221: Add ELDO[1-3] support
Hi,
Quoted 77 lines · Siarhei Siamashka
Quoted 63 lines · On Fri, 9 Jan 2015 18:05:35 +0100 Anatolij Gustschin <[email protected]> wrote:
On Fri, 9 Jan 2015 12:01:09 +0200
Siarhei Siamashka <[email protected]> wrote:
...Quoted 23 lines
drivers/power/axp221.c +23
-0+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 )drivers/power/axp221.c int axp221_set_aldo3(unsigned int mvolt) · line 354
Quoted 10 lines
drivers/power/axp221.c +10
-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)Quoted 8 lines
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.
Quoted 7 lines
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
PATCH 2/8 include: Add header file with MIPI DSI constants from the Linux kernel
In reply to Siarhei SiamashkaIt provides some constants for DCS commands, which are needed to implement support for SSD2828.
--- include/mipi_display.h | 130 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 include/mipi_display.h
include/mipi_display.h new file +130 -0
@@ -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 <[email protected]> +* Copyright (C) 2006 Nokia Corporation +* Author: Imre Deak <[email protected]> +* +* 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
Signature · 1 line
2.0.5
PATCH 2/8 include: Add header file with MIPI DSI constants from the Linux kernel
Quoted 2 lines · On Fri, 9 Jan 2015 12:01:10 +0200 Siarhei Siamashka…
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
PATCH 2/8 include: Add header file with MIPI DSI constants from the Linux kernel
Quoted 10 lines · On Fri, 9 Jan 2015 18:15:44 +0100 Anatolij Gustschin <[email protected]> wrote:
Quoted 2 lines · On Fri, 9 Jan 2015 12:01:10 +0200 Siarhei Siamashka…
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.
Signature · 2 lines
Best regards, Siarhei Siamashka
PATCH 3/8 video: Add support for SSD2828 (parallel LCD to MIPI bridge)
In reply to Siarhei SiamashkaSSD2828 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.
--- 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
drivers/video/Makefile +1 -0
@@ -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
drivers/video/ssd2828.c new file +421 -0
421 lines not on this page · raw message
drivers/video/ssd2828.h new file +123 -0
123 lines not on this page · raw message
Signature · 1 line
2.0.5
PATCH 3/8 video: Add support for SSD2828 (parallel LCD to MIPI bridge)
Quoted 7 lines · On Fri, 9 Jan 2015 12:01:11 +0200 Siarhei Siamashka…
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.
Quoted 7 lines
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 <[email protected]>
PATCH 4/8 video: sunxi: Hook up SSD2828 with the sunxi video driver
In reply to Siarhei SiamashkaExpose the necessary configuration parameters in Kconfig. Add SSD2828 initialization between enabling the parallel LCD interface and turning on the backlight.
--- 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(+)
board/sunxi/Kconfig +60 -0
@@ -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
drivers/video/sunxi_display.c +3 -0
@@ -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:
drivers/video/sunxi_lcd_panel.c +38 -0
@@ -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
drivers/video/sunxi_lcd_panel.h +3 -0
@@ -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);
Signature · 1 line
2.0.5
PATCH 4/8 video: sunxi: Hook up SSD2828 with the sunxi video driver
On Fri, 9 Jan 2015 12:01:12 +0200
Siarhei Siamashka <[email protected]> wrote:
...
Quoted 7 lines
board/sunxi/Kconfig +0
-0@@ -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.
board/sunxi/Kconfig config VIDEO_LCD_BL_PWM · line 356
Quoted 10 lines
board/sunxi/Kconfig +9
-0+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
PATCH 5/8 sun6i: Add LCD display support for MSI Primo81 tablet
In reply to Siarhei SiamashkaThe 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.
--- configs/MSI_Primo81_defconfig | 9 +++++++++ 1 file changed, 9 insertions(+)
configs/MSI_Primo81_defconfig +9 -0
@@ -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
Signature · 1 line
2.0.5
PATCH 5/8 sun6i: Add LCD display support for MSI Primo81 tablet
Quoted 7 lines · On Fri, 9 Jan 2015 12:01:13 +0200 Siarhei Siamashka…
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 <[email protected]>
PATCH 6/8 video: ssd2828: Allow using 'pclk' as the PLL clock source
In reply to Siarhei SiamashkaInstead 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.
--- drivers/video/ssd2828.c | 20 +++++++++++++++++--- drivers/video/ssd2828.h | 11 ++++++++--- 2 files changed, 25 insertions(+), 6 deletions(-)
drivers/video/ssd2828.c +17 -3
@@ -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 */
drivers/video/ssd2828.h +8 -3
@@ -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);
Signature · 1 line
2.0.5
PATCH 6/8 video: ssd2828: Allow using 'pclk' as the PLL clock source
Quoted 10 lines · On Fri, 9 Jan 2015 12:01:14 +0200 Siarhei Siamashka…
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.
Quoted 3 lines
Using 'pclk' is free from all these problems.
Signed-off-by Siarhei Siamashka <[email protected]>
PATCH 7/8 video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828
In reply to Siarhei SiamashkaSo 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.
--- drivers/video/sunxi_lcd_panel.c | 1 - 1 file changed, 1 deletion(-)
drivers/video/sunxi_lcd_panel.c +0 -1
@@ -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,
Signature · 1 line
2.0.5
PATCH 7/8 video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828
Quoted 4 lines · On Fri, 9 Jan 2015 12:01:15 +0200 Siarhei Siamashka…
So that we don't need to keep it as a hardcoded magic number in the code or the hassle exposing it as a
Kconfigoption.Signed-off-by Siarhei Siamashka <[email protected]>
PATCH 8/8 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
In reply to Siarhei SiamashkaOr 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).
--- drivers/video/ssd2828.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 140 insertions(+)
drivers/video/ssd2828.c +140 -0
@@ -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);
Signature · 1 line
2.0.5
cover video: Add support for SSD2828 (parallel LCD to MIPI bridge)
In reply to Siarhei SiamashkaQuoted 47 lines · On Fri, 9 Jan 2015 12:01:08 +0200 Siarhei Siamashka…
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.jpgSiarhei 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 idboard/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 +
Quoted 8 lines
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 00This 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 :-)
Signature · 2 lines
Best regards, Siarhei Siamashka
cover video: Add support for SSD2828 (parallel LCD to MIPI bridge)
In reply to Siarhei SiamashkaHi,
Quoted 19 lines · Siarhei Siamashka
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.
Quoted 7 lines
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 :)
Quoted 9 lines
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:
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
cover video: Add support for SSD2828 (parallel LCD to MIPI bridge)
Hi,
Quoted 27 lines · Hans de Goede
Hi,
Quoted 24 lines · Siarhei Siamashka
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.
Quoted 4 lines
Quoted 2 lines
And here is a bonus picture :-)
http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpgCool :)
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
cover video: Add support for SSD2828 (parallel LCD to MIPI bridge)
In reply to Hans de GoedeQuoted 1 line · Hans de Goede
So assuming the Ian will ack v2 of my lvds patch
Just done, assuming those were the patches you meant...
Quoted 3 lines
With that changed patches 1-7 are:
Acked-by Hans de Goede <[email protected]>
Hence I wasn't planning on looking into this series further, please let me know if my opinion is wanted...
Ian.
cover video: Add support for SSD2828 (parallel LCD to MIPI bridge)
In reply to Hans de GoedeQuoted 64 lines · On Fri, 09 Jan 2015 16:35:09 +0100 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 19 lines · Siarhei Siamashka
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.
Quoted 7 lines
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.jpgCool :)
Quoted 9 lines
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 idThanks 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 theKconfigstuff generic.
This also means dropping the
"selectVIDEO_LCD_IF_PARALLEL" from "configVIDEO_LCD_SSD2828" and adding it to "configVIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828", as that option is the only one which will stay in board/sunxi/Kconfig andVIDEO_LCD_IF_PARALLELis sunxi specific.
Quoted 2 lines
The changes to
drivers/video/Kconfigshould 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.
Quoted 8 lines
With that changed patches 1-7 are:
Acked-by Hans de Goede <[email protected]>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.
Signature · 2 lines
Best regards, Siarhei Siamashka