From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Mon, 19 Jan 2015 21:10:36 +0100 Subject: [U-Boot] [PATCH] sunxi: display: Make lcd display clk phase configurable In-Reply-To: References: <1421152412-4091-1-git-send-email-hdegoede@redhat.com> <54BD55B6.6090807@redhat.com> Message-ID: <54BD64BC.80007@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 19-01-15 20:46, Simon Glass wrote: > Hi Hans, > > On 19 January 2015 at 12:06, Hans de Goede wrote: >> Hi, >> >> >> On 18-01-15 04:12, Simon Glass wrote: >>> >>> Hi Hans, >>> >>> On 13 January 2015 at 04:33, Hans de Goede 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 >>>> --- >>>> 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. 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. 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 :) Regards, Hans