[U-Boot] [PATCH] sunxi: display: Make lcd display clk phase configurable

[Simon Glass]

Hi Hans,

On 19 January 2015 at 13:10, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 19-01-15 20:46, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> On 19 January 2015 at 12:06, Hans de Goede <hdegoede at redhat.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 18-01-15 04:12, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Hans,
>>>>
>>>> On 13 January 2015 at 04:33, Hans de Goede <hdegoede at redhat.com> wrote:
>>>>>
>>>>>
>>>>> While running some tests with an Olinuxino-A13-Micro + a 7" Olimex LCD
>>>>> module
>>>>> I noticed that the screen flickered. This is caused by the lcd display
>>>>> clk
>>>>> phase reg value being set to 0, where it should be 1 in this setup.
>>>>>
>>>>> This commit adds a Kconfig option for the lcd display clk phase, so
>>>>> that
>>>>> we
>>>>> can set it per board. This defaults to 1, because looking at all the
>>>>> fex
>>>>> files in sunxi-boards, that is by far the most used value.
>>>>>
>>>>> This commit updated the Ippo and MSI Primo73 tablet defconfigs to
>>>>> override the
>>>>> default of 1 with 0, as that is the correct value for those tablets,
>>>>> this
>>>>> keeps the register settings the same as before this commit.
>>>>>
>>>>> The Olinuxino-A13 defconfigs are not updated, changing the register
>>>>> setting
>>>>> for these boards from 0 to 1, this is intentional.
>>>>>
>>>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>>> ---
>>>>>    arch/arm/include/asm/arch-sunxi/display.h | 4 +---
>>>>>    board/sunxi/Kconfig                       | 7 +++++++
>>>>>    configs/Ippo_q8h_v1_2_defconfig           | 1 +
>>>>>    configs/Ippo_q8h_v5_defconfig             | 1 +
>>>>>    configs/MSI_Primo73_defconfig             | 1 +
>>>>>    drivers/video/sunxi_display.c             | 7 +------
>>>>>    6 files changed, 12 insertions(+), 9 deletions(-)
>>>>
>>>>
>>>>
>>>> Are you planning to move this to device tree at some point?
>>>
>>>
>>>
>>> Yes, one of the free-electrons guys is working on a kms driver, once
>>> we've
>>> that
>>> and thus stable devicetree bindings for the display blocks I want to move
>>> all
>>> this over to devicetree.
>>
>>
>> OK thanks. More generally for sunxi I am wondering how common the
>> board code can be. Already you have managed to support all sun7i
>> boards in essentially a single config, for example. I wonder if we
>> might support all sun7i boards with just different device trees? Not
>> sure about other variants?
>
>
> My long term vision is along the lines of having one u-boot binary
> each for sun4i, sun5i, sun6i, etc. and then be able to append a dtb
> to that u-boot binary, combine it with the right spl, and presto we've
> u-boot ready for the specific board as described by the dtb.

Sounds good.

>
> The tricky bit is making the spl board agnostic, as we only have 32k
> sram to work with, some of which is used by the BROM. We can overwrite
> it when booting from mmc, but not when FEL booting (sunxi BROM usb
> gadget mode boot), and we also need to put the initial stack there,
> so dtb parsing is sort of out of the question since the dtb itself
> would likely already be larger then the space we've. So the spl side
> will likely end up using some linker magic to put a struct with
> config parameters (like dram parameters) at a fixed offset and
> then use some utility to extract those from a dtb and patch them into
> the spl or some such.

I did write an fdtgrep tool to cut down a device tree to only selected
nodes, etc. So it might be possible, and the simplest option. If you
do the linker magic idea, we should try to unify it across all SoCs.
Exynos already has a binary table - in Chrome OS we have a tool which
converts the device tree to the binary table. It's best avoided
though.

>
> Note this is where I would like to be, currently thinks like supporting
> newer sunxi SoCs has higher priority though, but if you want to help
> us getting there that would be great :)

I think it would make sense to support newer devices with driver model
and device tree, at least. I have already helped a little, I have my
hands full for quite a while on various things at present.

Regards,
Simon