From: Thierry Reding <thierry.reding@avionic-design.de>
To: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@nvidia.com>,
Devicetree Discuss <devicetree-discuss@lists.ozlabs.org>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Jerry Van Baren <vanbaren@cideas.com>,
Tom Warren <twarren@nvidia.com>
Subject: Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
Date: Wed, 11 Jul 2012 07:48:43 +0200 [thread overview]
Message-ID: <20120711054842.GB10344@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <CAPnjgZ2MUpjGS-BwQ6yASahFiu2OTWx4RUrJ7bkSkq72QmX++Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3832 bytes --]
On Wed, Jul 11, 2012 at 06:44:10AM +0200, Simon Glass wrote:
> Hi Stephen,
>
> On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
>
> > On 06/13/2012 10:19 AM, Simon Glass wrote:
> > > Add LCD definitions and also a proposed binding for LCD displays.
> > >
> > > The PWFM is in progress on the device-tree-discuss list, so only a
> > > very basic binding is offered here.
> >
> > I believe we have settled on a final representation, it just hasn't been
> > added into linux-next yet. See:
> >
> >
> > http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04
>
>
> Thanks for the pointer. I suppose this doesn't address clocks as yet, but
> that's fine.
I was waiting for the common clock framework and DT bindings to get
ready. This should happen RSN for Tegra so I will probably look at
adding support for it in.
By the way, the PWM tree has now been in linux-next for a couple of
weeks and I plan to submit it for inclusion in 3.6.
> > > I am not sure if it is better to have the lcd within the display
> > > controller as with i2c/spi, or a separate node. From a hardware point
> > > of view the LCD is certainly connected to the display controller, so
> > > perhaps this version makes most sense. We could have a stand-alone
> > > top-level lcd node with a phandle pointing to the display controller,
> > > but these doesn't seem to be an obvious advantage to that approach.
> >
> > Equally, there's been extensive discussion re: how to represent the
> > NVIDIA display controller in DT. I strongly believe that U-Boot
> > shouldn't go ahead in isolation with a binding that's completely
> > unrelated to what's happening in the kernel. Please can you take what
> > Thierry is working on for the kernel, and/or contribute to that binding
> > etc., so we don't end up with multiple ways of doing the same thing.
> > Part of the whole point of DT is to have a single way of representing HW
> > that multiple OSs (or perhaps bootloaders) cna use. If everyone just
> > goes and does their own thing, we've lost.
> >
>
> I can see the email here.
>
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021223.html
>
> I posted this series originally in January. That email is from April, and I
> don't see activity in the last 2 months. As previously discussed it is not
> productive to chase a moving target.
I had hoped I could get this finished much faster, but then things
happened. However there has been quite some progress in the meantime.
I actually based that very first version on what you had in the earlier
Tegra LCD series with a couple of additions to support DRM
specificities. However the proposal was shot down pretty early mainly
because the display timing description was very Tegra specific. One
proposal was to include an EDID blob directly into the DT and pass it on
to DRM, which is what the current code does.
Lately there's been some work on adding a generic description for
display timings:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
I haven't tested that code yet, but it might turn out to be an
interesting replacement for the EDID blob.
> Thierry, have you settled on a binding yet? If not do you have something
> sort-of close that I could use in U-Boot?
The currently accepted form (as in "Stephen said it looks reasonable")
is here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024899.html
It currently only defines the bindings for the RGB and HDMI outputs, but
that should be fine since from what I can tell your U-Boot driver
supports RGB only anyway. It is probably also way more than you really
need in U-Boot because it has DT nodes for all the graphics-related
modules.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 134 bytes --]
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@avionic-design.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
Date: Wed, 11 Jul 2012 07:48:43 +0200 [thread overview]
Message-ID: <20120711054842.GB10344@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <CAPnjgZ2MUpjGS-BwQ6yASahFiu2OTWx4RUrJ7bkSkq72QmX++Q@mail.gmail.com>
On Wed, Jul 11, 2012 at 06:44:10AM +0200, Simon Glass wrote:
> Hi Stephen,
>
> On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
>
> > On 06/13/2012 10:19 AM, Simon Glass wrote:
> > > Add LCD definitions and also a proposed binding for LCD displays.
> > >
> > > The PWFM is in progress on the device-tree-discuss list, so only a
> > > very basic binding is offered here.
> >
> > I believe we have settled on a final representation, it just hasn't been
> > added into linux-next yet. See:
> >
> >
> > http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04
>
>
> Thanks for the pointer. I suppose this doesn't address clocks as yet, but
> that's fine.
I was waiting for the common clock framework and DT bindings to get
ready. This should happen RSN for Tegra so I will probably look at
adding support for it in.
By the way, the PWM tree has now been in linux-next for a couple of
weeks and I plan to submit it for inclusion in 3.6.
> > > I am not sure if it is better to have the lcd within the display
> > > controller as with i2c/spi, or a separate node. From a hardware point
> > > of view the LCD is certainly connected to the display controller, so
> > > perhaps this version makes most sense. We could have a stand-alone
> > > top-level lcd node with a phandle pointing to the display controller,
> > > but these doesn't seem to be an obvious advantage to that approach.
> >
> > Equally, there's been extensive discussion re: how to represent the
> > NVIDIA display controller in DT. I strongly believe that U-Boot
> > shouldn't go ahead in isolation with a binding that's completely
> > unrelated to what's happening in the kernel. Please can you take what
> > Thierry is working on for the kernel, and/or contribute to that binding
> > etc., so we don't end up with multiple ways of doing the same thing.
> > Part of the whole point of DT is to have a single way of representing HW
> > that multiple OSs (or perhaps bootloaders) cna use. If everyone just
> > goes and does their own thing, we've lost.
> >
>
> I can see the email here.
>
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021223.html
>
> I posted this series originally in January. That email is from April, and I
> don't see activity in the last 2 months. As previously discussed it is not
> productive to chase a moving target.
I had hoped I could get this finished much faster, but then things
happened. However there has been quite some progress in the meantime.
I actually based that very first version on what you had in the earlier
Tegra LCD series with a couple of additions to support DRM
specificities. However the proposal was shot down pretty early mainly
because the display timing description was very Tegra specific. One
proposal was to include an EDID blob directly into the DT and pass it on
to DRM, which is what the current code does.
Lately there's been some work on adding a generic description for
display timings:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
I haven't tested that code yet, but it might turn out to be an
interesting replacement for the EDID blob.
> Thierry, have you settled on a binding yet? If not do you have something
> sort-of close that I could use in U-Boot?
The currently accepted form (as in "Stephen said it looks reasonable")
is here:
http://lists.freedesktop.org/archives/dri-devel/2012-July/024899.html
It currently only defines the bindings for the RGB and HDMI outputs, but
that should be fine since from what I can tell your U-Boot driver
supports RGB only anyway. It is probably also way more than you really
need in U-Boot because it has DT nodes for all the graphics-related
modules.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120711/62660cca/attachment.pgp>
next prev parent reply other threads:[~2012-07-11 5:48 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header Simon Glass
2012-09-21 19:30 ` Anatolij Gustschin
2012-09-27 20:58 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux Simon Glass
2012-06-14 23:24 ` Stephen Warren
2012-07-11 3:48 ` Simon Glass
2012-06-13 16:19 ` [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra Simon Glass
2012-06-13 16:19 ` [U-Boot] " Simon Glass
2012-06-14 23:32 ` Stephen Warren
2012-06-14 23:32 ` [U-Boot] " Stephen Warren
2012-07-11 4:44 ` Simon Glass
2012-07-11 4:44 ` [U-Boot] " Simon Glass
2012-07-11 5:48 ` Thierry Reding [this message]
2012-07-11 5:48 ` Thierry Reding
2012-07-12 8:21 ` Simon Glass
2012-07-12 8:21 ` [U-Boot] " Simon Glass
2012-07-12 8:40 ` Thierry Reding
2012-07-12 8:40 ` [U-Boot] " Thierry Reding
2012-07-12 9:22 ` Alex Courbot
2012-07-12 9:22 ` [U-Boot] " Alex Courbot
2012-06-13 16:19 ` [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM Simon Glass
2012-06-14 23:35 ` Stephen Warren
2012-07-11 4:45 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd Simon Glass
2012-06-14 23:39 ` Stephen Warren
[not found] ` <CAPnjgZ2bqPx+dHD9m+NuFrAbBeP1PQxHokLMwvD1-3OnC6ZHtg@mail.gmail.com>
2012-07-11 5:12 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver Simon Glass
2012-06-14 23:45 ` Stephen Warren
2012-07-11 4:56 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards Simon Glass
2012-06-14 23:47 ` Stephen Warren
2012-07-11 4:58 ` Simon Glass
2012-07-23 20:25 ` Stephen Warren
2012-09-27 19:15 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions Simon Glass
2012-06-14 23:49 ` Stephen Warren
2012-07-11 5:01 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 13/19] lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update Simon Glass
2012-06-14 23:51 ` Stephen Warren
2012-07-11 5:06 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 15/19] tegra: Align LCD frame buffer to section boundary Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 16/19] tegra: Support control of cache settings for LCD Simon Glass
[not found] ` <1339604395-6621-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-06-13 16:19 ` [PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr() Simon Glass
2012-06-13 16:19 ` [U-Boot] " Simon Glass
2012-09-21 19:39 ` Anatolij Gustschin
2012-09-21 19:56 ` Anatolij Gustschin
2012-06-13 16:19 ` [PATCH v2 03/19] fdt: Add function to look up a phandle's register address Simon Glass
2012-06-13 16:19 ` [U-Boot] " Simon Glass
2012-06-14 23:17 ` Stephen Warren
2012-06-14 23:17 ` [U-Boot] " Stephen Warren
2012-07-11 5:10 ` Simon Glass
2012-07-11 5:10 ` [U-Boot] " Simon Glass
2012-06-13 16:19 ` [PATCH v2 04/19] fdt: Add header guard to fdtdec.h Simon Glass
2012-06-13 16:19 ` [U-Boot] " Simon Glass
2012-06-13 16:19 ` [PATCH v2 17/19] tegra: fdt: Add LCD definitions for Seaboard Simon Glass
2012-06-13 16:19 ` [U-Boot] " Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 18/19] lcd: Add CONSOLE_SCROLL_LINES option to speed console Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 19/19] tegra: Enable display/lcd support on Seaboard Simon Glass
2012-06-13 22:57 ` [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Stephen Warren
2012-06-13 23:03 ` Stephen Warren
2012-06-13 23:09 ` Stephen Warren
2012-06-25 21:03 ` Tom Warren
2012-06-27 5:11 ` Simon Glass
2012-07-11 10:04 ` 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=20120711054842.GB10344@avionic-0098.mockup.avionic-design.de \
--to=thierry.reding@avionic-design.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=twarren@nvidia.com \
--cc=u-boot@lists.denx.de \
--cc=vanbaren@cideas.com \
/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.