public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Eric Nelson <eric.nelson@boundarydevices.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Remove static display data
Date: Fri, 26 Jul 2013 07:04:21 -0700	[thread overview]
Message-ID: <51F281E5.9010103@boundarydevices.com> (raw)
In-Reply-To: <51F236CB.3060906@denx.de>

Hi Stefano,

On 07/26/2013 01:43 AM, Stefano Babic wrote:
> Hi Robert, Anatolji,
>
> On 26/07/2013 09:50, Anatolij Gustschin wrote:
>
>>>
>>> I realize that there's already the FDT and CONFIG_OF_CONTROL functionality
>>> and device trees sort of cover the passing to Linux part so maybe before
>>> handing it off, converting the relevant data into a device tree that Linux
>>> can already use/parse would work.
>>
>> Devicetree bindings for describing display timings info exist in recent
>> Linux kernel versions (since v3.9 I think) and are documented under
>> Documentation/devicetree/bindings/video/display-timing.txt. In Linux
>> there are also DT helpers to parse display timings nodes and read the
>> timing values into fb_videomode structure (of_get_display_timings,
>> of_get_fb_videomode). Code for adding such display timings nodes to
>> the device tree under U-Boot doesn't exist yet.
>
> IMHO adopting DT looks very interesting, as it can really simplify
> sharing configuration between u-boot and kernel. On i.MX6 we have not
> yet started to use DT to configure u-boot as it is already done on other
> SOCs (Tegra), but it seems to me the right way to do.
>

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.

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.

Is Tegra somehow using DT to configure U-Boot display?
I'm not finding the code.

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.

Please advise,


Eric

  reply	other threads:[~2013-07-26 14:04 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 [this message]
2013-07-26 14:42       ` Stefano Babic
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=51F281E5.9010103@boundarydevices.com \
    --to=eric.nelson@boundarydevices.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox