Hi,
On 01-01-15 03:35, Chen-Yu Tsai wrote:
Hi Hans,
On Wed, Dec 31, 2014 at 7:22 PM, Hans de Goede <hdego...@redhat.com> wrote:
<snip>
I also compared the config settings from your patches with the
automatically generated records and noticed some inconsistencies.
For example, Ippo_q8h_v1_2_defconfig :
=== A part of your patch:
+CONFIG_VIDEO_LCD_POWER="PH7"
+CONFIG_VIDEO_LCD_BL_EN="PH6"
+CONFIG_VIDEO_LCD_BL_PWM="PH0"
=== My script:
# warning: could not decode 'lcd_power' (port:power2<1><0><default><1>)
CONFIG_VIDEO_LCD_BL_EN="PH6"
# warning: 'lcd_pwm' gpio extracted from 'pwm0_para' section
CONFIG_VIDEO_LCD_BL_PWM="PH0"
# warning: 'lcd_gpio_0' = 'port:PH07<1><0><default><1>'
===
In both cases we have references to PH0/PH6/PH7 pins, however my
script would pick "AXP0-2" for CONFIG_VIDEO_LCD_POWER (taking your
advise), while the role of 'lcd_gpio_0' is not quite clear.
And this is Allwinner A23, which does not use even use AXP209 PMIC.
What is actually going on with the AXP GPIO and power routing? Is AXP
GPIO really doing what we expect it to be doing?
What is likely going on here is that we do not need PH7 at all, when I
first wrote the LCD support for the Ippo_q8h_v1_2 I did not have any
axp-gpio support at all, so I decided to just ignore the axp gpio listed
in the fex and see if things would work without it, and they did, so it
seems that either the LCD does not have a power/enable pin for the lcd
itself, or at least it is ok to leave the pin floating (which is the axp
gpio default).
On the A23 reference design, LCD power is only controlled by enabling
the AXP LDO output. Downstream just uses the LDO voltage level, rather
than a GPIO, to enable the discrete regulators. Since the AXP is already
software controllable, it makes sense. But it's possible on some boards
we may need it, when the LCD power is derived from a common 5V or 3.3V
source.
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.
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
