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