On Tue, 30 Dec 2014 11:26:51 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 30-12-14 11:18, Siarhei Siamashka wrote:
On Thu, 25 Dec 2014 11:59:55 +0100 Hans de Goede hdegoede@redhat.com wrote:
Ah yes, I used the slightly different timings from the olimex 7" lcd panel for olinuxino boards, and since those worked fine on my a23 tablet I never adjusted things. Here is a translation table:
CONFIG_VIDEO_LCD_MODE fex value(s)
x lcd_x y lcd_y depth:18 lcd_frm = 1 pclk_khz lcd_dclk_freq * 1000 hs lcd_hv_hspw (with a minimum of 1) vs lcd_hv_vspw (with a minimum of 1) le lcd_hbp - hs ri lcd_ht - lcd_x - lcd_hbp up lcd_vbp - vs
On sun4i/sun5i/sun7i: lo (lcd_vt / 2) - lcd_y - lcd_vbp On sun8i: lo lcd_vt - lcd_y - lcd_vbp
sync 0 mode 0
I notice that the Ippo_q8h_v5 fex uses 0 for lcd_hv_hspw and lcd_hv_vspw, which is not a valid value as the register value contains hspw - 1, so the minimum is 1, and looking at a register dump under android with my A23 tablet the value indeed should be 1.
That's interesting. What would be the correct general formula for the hs/vs values then? "max(lcd_hv_hspw, 1)" or maybe "lcd_hv_hspw + 1"?
Looking at the register values set by android vs the fex file, the correct formula is "max(lcd_hv_hspw, 1)".
How can this be verified? Which hardware register needs to be read?
I can use Android to test this on Primo73 tablet, where the hs/vs values are originally non-zero in fex.
BTW, I have done a preliminary automatic conversion for all FEX files from sunxi-boards, which enable lcd0 in fex. The results are now available at the all the same http://linux-sunxi.org/LCD wiki page.
Cool, thanks for doing this!
If "hs = lcd_hv_hspw + 1" is a better choice, then the whole table probably needs to be re-generated.
Also additional explanations about GPIO related options (what would be the exact rules to interpret FEX?) and more details about "lcd_frm" and "lcd_if" would help a lot to get a better understanding about what still needs to be done to get LCD displays supported on all devices.
Currently basically only lcd_if = 0 and lcd_frm = 1 are supported, it should be possible to add support for other lcd_frm = x values easily, so if you encounter those let me know, lcd_if != 0 is going to be much harder to support and currently is not on my schedule.
It's all in the orange part of the table at the bottom. The lcd_frm = 0 seems to be relatively common. The links to FEX files for each device are also there in the table and can be used to confirm the details.
The http://linux-sunxi.org/Wexler_TAB_7200 tablet with its fex file https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a20/wexle... is one of the examples.
If I understand it correctly, the kernel sources from the Allwinner SDK contain the relevant code for handling the information from FEX, and this code is the best reference. And it's more reliable to refer to A23 SDK for interpreting the FEX files originally snatched from A23 devices, and likewise A31 SDK for A31 devices. For example, it is not uncommon to see both 'lcd_pwm_used' and 'lcd_pwm_not_used' variables defined in FEX. And sometimes the values of these variables even contradict each other. So the fine details about the relative priorities of these variables and other similar things might need to be discovered for perfectly correct conversion.
All I can say here is that I agree with the above, I'm afraid I'm not familiar enough with the (quite large) sunxi display code in the SDK kernels to provide answers here.
I'm not familiar with that code either. I have just started looking at these sources, searching for some answers. For example, that's where I found the information about the 'pwm0_para' section and some other things. SDK is not useful for anything other than the FEX interpretation details. For implementing the actual code we do have the hardware documentation.
Just right now it's a good idea to figure out some basic FEX conversion rules and probably document them in the wiki. If you can share the rest of the information that you know about this LCD code, it would be surely a great help for this documentation and conversion code.
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?