[U-Boot] [PATCH 15/17] sunxi: Ippo_q8h defconfigs: Enable the LCD panel found on these tablets.

[Hans de Goede]

Hi,

On 02-01-15 12:02, Siarhei Siamashka wrote:

<snip>

> Now I also got LCD display in my MSI Primo81 tablet working. Because
> Allwinner A31s does not have a native MIPI DSI interface, it uses
> an extra SSD2828 bridge chip, which converts parallel LCD interface
> into MIPI DSI.

Cool!

> MIPI DSI interface is needed for the B079XAN01/LP079X01
> 7.85" IPS LCD display. Supposedly SSD2828 chip needs 1.2V on ELDO3 for
> power (based on checking the kernel sources in A31 SDK), but everything
> seems to work even without it. And the fex file also specifies
> "lcd_power" as "port:power2<1><0><default><1>" similar to A23,
> however everything power-related just happens to magically work fine
> without doing anything special. This feels very suspicious and
> abnormal :-)
>
>> Ok.
>>
>>>> As for the lcd_gpio_# entries in the fex, looking at the linux-sunxi code,
>>>> it seems that they are initialized to the value specified in the fex once,
>>>> which for the Ippo_q8h_v1_2 means setting the gpio to output high once,
>>>> which we do effectively be assigning PH7 to CONFIG_VIDEO_LCD_POWER (and
>>>> I need to test if this is really necessary).
>>>
>>> PH7 in the reference design drives LCD_RST. I guess leaving it floating
>>> doesn't assert reset in the LCD driver. IMO, LCD_RESET would be a better
>>> name. It's what schematics use.
>>
>> Ok, note that the current defconfig for the q8h is driving it, but is using
>> CONFIG_VIDEO_LCD_POWER to drive it, which certainly seems the wrong name for
>> it.
>>
>>>> I agree that this is confusing, and that we should probably add something
>>>> akin to lcd_gpio_0 to u-boot so that we've a 1:1 translation.
>>>>
>>>> A quick grep:
>>>>
>>>> [hans at shalem u-boot]$ grep -R -h lcd_gpio_0 ../sunxi-boards/sys_config |
>>>> sort | uniq
>>>> ;lcd_gpio_0          = port:PA23<0><0><default><default>
>>>> ;lcd_gpio_0          = port:PH10<1><0><2><1>
>>>> Binary file ../sunxi-boards/sys_config/a20/script.bin matches
>>>> lcd_gpio_0      =
>>>> lcd_gpio_0          =
>>>> lcd_gpio_0 =
>>>> lcd_gpio_0 = ""
>>>> lcd_gpio_0 = port:PA06<1><0><default><1>
>>>> lcd_gpio_0 = port:PH07<1><0><default><1>
>>>> lcd_gpio_0 = port:PH10<1><0><2><1>
>>>>
>>>> Shows that the port is always put in output high mode, grepping for gpio_1
>>>> returns
>>>> 2 boards which use gpio_1 (and higher):
>>>>
>>>> sys_config/a20/icou_fatty_i.fex
>>>> sys_config/a31s/msi_primo81.fex
>>>>
>>>> Both of which have a non supported cpu_if setting of 4 resp 6.
>>>>
>>>> So it seems for now we can simply add a CONFIG_VIDEO_LCD_GPIO0 and always
>>>> drive the pin specified there (if any) high, and then we're good to go.
>>>
>>> See the previous paragraph about the name.
>>
>> Although I think that it is great that you've schematics for the q8h, we do not
>> have schematics for the majority of the boards we want to support, so I think it
>> is best to stick with the CONFIG_VIDEO_LCD_GPIO# name, and add a commment to the
>> defconfig what it really is in the cases where we know what it is used for.
>
> BTW, the MSI Primo81 tablet (lcd_if=6) uses a set of four pins in the
> 'lcd_gpio_*' fex config. Three of them are used for SPI communication
> to configure the SSD2828 chip (write only). And one more pin is reset.
> The reset pin is not "lcd_gpio_0", but "lcd_gpio_2". So yes, the exact
> pin naming may depend on the "lcd_if" config variable and also maybe
> even change between different Allwinner SDK versions.

Ah interesting, I had some trouble getting the theoretically easy addition
of lvds going on my A10 tablet because the hitachi lcd used in it has a
lcd controller which needs some poking over SPI for it to power up.

> I'll submit the lcd_if=6 (LCD_IF_EXT_DSI) support code soon, but the
> original Allwinner's SPI bit-banging code needs to be reworked to get
> rid of magic constants. Given that the SSD2828 datasheet exists, this
> should be doable.

Sounds good, my own support for the hitachi lcd needed some cleanup,
which I've just completed. I've just posted the series to the mailinglist,
and it is available in my sunxi-wip branch. As you can see I've taken into
account that we also need support for the SSD2828 and made the VIDEO_LCD_PANEL
Kconfig option a choice, so adding one more special panel should be easy,
just slot it in in the Kconfig and add it to drivers/video/sunxi_lcd_panel.c

I've found a few other boards using the same hitachi panel, but they all use
the same gpios for the spi bit-banging, which seems to be a different set
from what is being used in the primo for the SSD2828, I think it is easiest to
just hardcode the gpio-s needed for the spi inside drivers/video/sunxi_lcd_panel.c
for now, based on the lcd panel type, if we ever need to make things more
flexible because some new board comes along which uses an already supported
lcd panel / conversion chip, but with a different set of gpio-s then we can
easily make things more flexible then.

> Do we really want to keep the magic CONFIG_VIDEO_LCD_GPIO# names?

Given that in your case they are being (ab)used to code spi pins, no. I'll
do a patch one of the coming days to introduce a CONFIG_VIDEO_LCD_RESET Kconfig
option, I think it would be be safe for your fex conversion script to fill that
with gpio0 for boards which only set gpio0, and just complain in case there is
more then one gpio and not do anything with the gpio-s.

Talking about your script, lcd_if = 3 is supported with my LVDS patches, this
should select CONFIG_VIDEO_LCD_PANEL_LVDS, lcd_lvds_ch, lcd_lvds_mode and
lcd_lvds_io_cross should all be 0, otherwise we're dealing with an unsupported
config. lcd_lvds_bitwidth = 0 means depth:24, lcd_lvds_bitwidth = 1 means depth:18,
for lvds this takes precedence over whatever lcd_frm sets. Note some lvds using
fex files set lcd_lvds_bitwidth = 1 without enabling dithering through lcd_frm,
this makes no sense, and the SDK kernel code even complains about it, so I've
no intention of supporting 18 bits over lvds without dithering.

Regards,

Hans