On 01/18/2016 07:08 PM, Simon Glass wrote:
Hi Stephen,
On 18 January 2016 at 12:43, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 01/14/2016 01:26 PM, Simon Glass wrote:
We have standard drivers for panels and backlights which can do most of
the
work for us. Move the tegra20 LCD driver over to use those instead of
custom
code.
This patch includes device tree changes for the nvidia boards. I have only
been able to test seaboard. If this patch is applied, these boards will
also need to be synced with the kernel, and updated to use
display-timings:
- colibri
- medcom-wide
- paz00
- tec
diff --git a/arch/arm/dts/tegra20-harmony.dts
b/arch/arm/dts/tegra20-harmony.dts
This file has huge changes unrelated to panel, video, and backlight. Perhaps
patch 1/4 was meant to sync the DTs for Harmony and Ventana too rather than
just Seaboard, leaving this commit to make roughly identical DT changes for
all 3 boards?
Yes I think that would be better. I started on seaboard since that's
the only one I have. But then I thought I could do the other two since
you or Tom should be able to test it.
diff --git a/arch/arm/dts/tegra20-seaboard.dts
b/arch/arm/dts/tegra20-seaboard.dts
+
+ display-timings {
+ timing@0 {
+ /* Seaboard has 1366x768
*/
+ clock-frequency =
<70600000>;
+ hactive = <1366>;
+ vactive = <768>;
+ hback-porch = <58>;
+ hfront-porch = <58>;
+ hsync-len = <58>;
+ vback-porch = <4>;
+ vfront-porch = <4>;
+ vsync-len = <4>;
+ hsync-active = <1>;
+ };
+ };
It seems very strange to go to the effort of creating patch 1 to sync the
U-Boot and Linux DT files (such that I assume they're 100% identical?) yet
immediately have patch 2 diverge the two DTs again.
This lends more weight to my argument that the U-Boot DTs should contain
only nodes that U-Boot actively uses. I can see the argument for copying
over the entire DT from Linux into U-Boot in order to keep them 100%
identical, and in turn that means importing a bunch of DT content that
U-Boot doesn't use. However, that argument completely breaks down if the DTs
are just going to diverge still.
At least the display-timings node is a standard binding, even if it isn't
one that the Linux Tegra DTs make use of.
How about adding this to the Linux Tegra DT? It's a hardware
description so shouldn't ruffle too many feathres.
diff --git a/configs/harmony_defconfig b/configs/harmony_defconfig
index 14125b4..0de56a9 100644
--- a/configs/harmony_defconfig
+++ b/configs/harmony_defconfig
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Harmony) # "
CONFIG_CMD_GPIO=y
# CONFIG_CMD_SETEXPR is not set
# CONFIG_CMD_NFS is not set
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
CONFIG_DM_PMIC=y
CONFIG_DM_REGULATOR=y
-CONFIG_DM_PWM=y
+CONFIG_DM_REGULATOR_FIXED=y
CONFIG_PWM_TEGRA=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y
CONFIG_DM_VIDEO=y
CONFIG_VIDEO_TEGRA20=y
CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_ERRNO_STR=y
I assume those are all needed by the modified Tegra video/LCD driver. If so,
wouldn't it make sense for that driver to select those Kconfig options
rather than requiring every board defconfig to be modified to enable the
features?
Do you mean 'depends on' in the Kconfig? This is a discussion that
goes back and forth...I don't really mind. It would mean that you
would have to play detective in menuconfig to turn the display on for
a board: find all the options it depends on, turn them on one by one
and then the display option appears.
I was thinking of "select" in Kconfig, so that if someone enables Tegra
LCD/display support then regulators etc. get automatically enabled too.
But "depends" would work too.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
