From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] lcd: add functions to setup up simplefb device tree
Date: Fri, 10 May 2013 22:35:30 -0600 [thread overview]
Message-ID: <518DCA92.7020807@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ0-1m_15VNxE=GcNdLjKQTXhfeywF6Hg58BdGpV6JmjaA@mail.gmail.com>
On 05/08/2013 09:33 PM, Simon Glass wrote:
> Hi Stephen,
>
> On Tue, May 7, 2013 at 10:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> simple-framebuffer is a new device tree binding that describes a pre-
>> configured frame-buffer memory region and its format. The Linux kernel
>> contains a driver that supports this binding. Implement functions to
>> create a DT node (or fill in an existing node) with parameters that
>> describe the framebuffer format that U-Boot is using.
>>
>> This will be immediately used by the Raspberry Pi board in U-Boot, and
>> likely will be used by the Samsung ARM ChromeBook support soon too. It
>> could well be used by many other boards (e.g. Tegra boards with built-in
>> LCD panels, which aren't yet supported by the Linux kernel).
> This looks OK - is a better place for it than the common lcd code? I
> presume it is here because it accesses panel_info?
I believe it really is common code; the DT content this code generates
is defined by a generic binding and isn't SoC-/board-specific. Perhaps a
common DT-related file would be OK too, although as you mention I'm not
sure if any other file would have access to the required LCD variables.
> Also is there a binding file we can bring in?
Yes, there's a simple-framebuffer.txt I could copy from the kernel.
>> +int lcd_dt_simplefb_add_node(void *blob)
>
> Can we not automatically find the node and update it?
Some DTs might have the node already exist and want to edit it, whereas
others might not contain it at all and need it added. This is rather up
to the author of individual boards' DTs. I wanted to make the code
explicitly select between those two options so that the U-Boot board
author always thought about exactly which behaviour they wanted.
>> +int lcd_dt_simplefb_enable_existing_node(void *blob)
>> +{
>> + int off;
>> +
>> + off = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
>
> Do we ever need to support more than one node, iwc perhaps we want to
> pass in the offset? If not, then see above question re searching.
I don't think U-Boot supports multiple panels does it? If the DT
contained multiple nodes to start with, I think they'd have to all be
initially disabled since some firmware would be required to fill in the
fields before they were useful.
As such, finding and editing the first node in all cases seems to make
sense for now. If this ever becomes false, we can add an index parameter
quite easily without significant impact.
>> diff --git a/include/lcd.h b/include/lcd.h
>> +#if defined(CONFIG_LCD_DT_SIMPLEFB)
>
> Probably don't need this #ifdef? It will complicate things if we use
> the autoconf series.
What's the autoconf series? I did this in order to get compile errors
rather than link errors if the functions were used without being
enabled, but I guess most linkers generate useful error messages so
perhaps this isn't needed.
next prev parent reply other threads:[~2013-05-11 4:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 4:21 [U-Boot] [PATCH 1/2] lcd: add functions to setup up simplefb device tree Stephen Warren
2013-05-08 4:21 ` [U-Boot] [PATCH 2/2] ARM: bcm2835: add simplefb DT node during bootz/m Stephen Warren
2013-05-09 3:30 ` Simon Glass
2013-05-09 3:33 ` [U-Boot] [PATCH 1/2] lcd: add functions to setup up simplefb device tree Simon Glass
2013-05-11 4:35 ` Stephen Warren [this message]
2013-05-15 13:28 ` Simon Glass
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=518DCA92.7020807@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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