From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Remove static display data
Date: Fri, 26 Jul 2013 16:42:52 +0200 [thread overview]
Message-ID: <51F28AEC.3070909@denx.de> (raw)
In-Reply-To: <51F281E5.9010103@boundarydevices.com>
Hi Eric,
On 26/07/2013 16:04, Eric Nelson wrote:
>
> The real question we have regarding DT is the timing. We're shipping
> DT files on secondary storage (SATA/SD card), and want/need something
> local (i.e. env in SPI-NOR) to present a U/I if either no storage
> available or if something goes wrong.
ok, understood.
>
> A secondary need/desire is to have something simple for configuring
> a new display. The process of tuning some of the parameters (esp
> margins) can sometimes be iterative because the data sheets aren't
> always clear and clock options are often imprecise. Since this
> iteration and configuration is often done by EEs in a lab who
> don't have an easy way to recompile a DTS, our inclination is
> to do something locally.
ok, I understand the point. Maybe it should be even more simple for the
EEs if the would be such kind of special u-boot commands, able to set
the timing and reload the framebuffer.
Can be a solution using the u-boot's fdt library enough ? With "fdt get"
and "fdt set" it is possible to read and modify a DT in memory, and
then the modified DT can be stored back - avoiding to compile directly
the DTS.
>
> Is Tegra somehow using DT to configure U-Boot display?
> I'm not finding the code.
./board/compal/dts/tegra20-paz00.dts seems doing that, but I have no
experience with it ;(
My thoughts are more related by comparing what the kernel does and how
the timing is configured. There are several examples (I am seeing the
imx23-dts, but it is not the only one) where the complete timing for a
panel is done inside the DT.
As you have already checked, using a U-Boot variable has some
limitations, because it does not contain all parameters that are needed.
And I think it could be quite difficult to get it general for all SOCs
because some SOCs need some specialties (VRAM for OMAP could be an example).
> No matter how we end up doing this, passing U-Boot's display
> setup to the kernel via DT is the **right thing**, so that
> there aren't two bits to maintain.
Yes, I think we do not need to discuss how to pass to the kernel - but I
am checking if it is a suitable way to configure the u-boot display,too.
Anyway, I agree that using a U-Boot variable is much more simple to
implement..
Best regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2013-07-26 14:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 18:21 [U-Boot] [RFC] Remove static display data Robert Winkler
2013-07-26 7:50 ` Anatolij Gustschin
2013-07-26 8:43 ` Stefano Babic
2013-07-26 14:04 ` Eric Nelson
2013-07-26 14:42 ` Stefano Babic [this message]
2013-07-26 14:49 ` Stephen Warren
2013-07-26 19:41 ` Eric Nelson
2013-07-27 0:42 ` Eric Nelson
2013-07-27 1:34 ` Troy Kisky
2013-07-27 19:05 ` Simon Glass
2013-07-28 16:57 ` Eric Nelson
2013-07-28 18:09 ` Simon Glass
2013-07-28 19:22 ` Eric Nelson
2013-07-29 16:50 ` Simon Glass
2013-07-26 14:00 ` Eric Nelson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F28AEC.3070909@denx.de \
--to=sbabic@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.