devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: Pinmux with device tree
Date: Thu, 19 May 2011 16:31:00 -1000	[thread overview]
Message-ID: <4DD5D264.90205@firmworks.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1105192217350.14430-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>

On 5/19/2011 4:23 PM, Nicolas Pitre wrote:
> On Thu, 19 May 2011, Mitch Bradley wrote:
>
>> On 5/19/2011 10:36 AM, Nicolas Pitre wrote:
>>> On Thu, 19 May 2011, Mitch Bradley wrote:
>>>
>>>> So, in my world, space is always an issue.
>>>
>>> I'm guessing that in such a scenario you have the kernel stored
>>> somewhere else, right?  You therefore simply have to store the FDT data
>>> along with the kernel in that other location, and have your boot
>>> firmware load an additional and relatively small file.
>>
>> There is no stored FDT.  The firmware generates the device tree dynamically
>> from a combination of static information and dynamic probing.
>>
>>>
>>> It is very important that the DT data be updateable independently from
>>> the firmware, just like the kernel is.  Ideally, the DT would indeed be
>>> exported by the firmware, but that works only in theory.  In practice it
>>> _will_ contain bugs that might be visible only after kernel development
>>> has progressed, and therefore it is primordial to be able to update it
>>> easily.  Hence in practice it is best if it is not exported/generated by
>>> the firmware directly.
>>
>>
>> In our world it works in practice.  We control the hardware, firmware, and OS
>> releases.  In many cases, a firmware update is less expensive than an OS
>> release by several orders of magnitude.
>
> I don't think this can be said for ARM in general though.
> This is where all the recent surge of activity around DT comes from.


Agreed, but I was pointing out that not everybody has space to burn, so 
I hope that the ultimate solution doesn't treat space as free.

>
>
> Nicolas
>

  parent reply	other threads:[~2011-05-20  2:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 16:34 Pinmux with device tree Simon Glass
     [not found] ` <BANLkTin5wBtR4zkgsQ6dw1jQP8yQGCDS2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-18 19:33   ` Mitch Bradley
     [not found]     ` <4DD41F02.4050108-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-05-19 11:30       ` Haojian Zhuang
     [not found]         ` <BANLkTim94SKgWvUF6_PWb9O5YsuNk120Bw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-19 17:10           ` Grant Likely
     [not found]             ` <20110519171029.GH3085-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-05-19 17:24               ` Stephen Warren
     [not found]                 ` <74CDBE0F657A3D45AFBB94109FB122FF0498A47BFF-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-05-19 17:42                   ` Grant Likely
2011-05-19 19:59               ` Mitch Bradley
     [not found]                 ` <4DD576BD.7090307-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-05-19 20:36                   ` Nicolas Pitre
     [not found]                     ` <alpine.LFD.2.00.1105191625050.14430-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2011-05-19 20:54                       ` Mitch Bradley
     [not found]                         ` <4DD5839C.2020809-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2011-05-20  2:23                           ` Nicolas Pitre
     [not found]                             ` <alpine.LFD.2.00.1105192217350.14430-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2011-05-20  2:31                               ` Mitch Bradley [this message]
2011-05-26  3:43               ` 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=4DD5D264.90205@firmworks.com \
    --to=wmb-d5eqfidgl7eakbo8gow8eq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org \
    /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;
as well as URLs for NNTP newsgroup(s).