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

[Siarhei Siamashka]

On Fri,  9 Jan 2015 12:01:08 +0200
Siarhei Siamashka <siarhei.siamashka at 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 :-)

-- 
Best regards,
Siarhei Siamashka