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@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
