linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jakob Viketoft <jakob.viketoft@bitsim.se>
To: Jon Loeliger <jdl@freescale.com>
Cc: Jon Masters <jonathan@jonmasters.org>,
	Sylvain Munaut <tnt@246tNt.com>,
	Andrei Konovalov <akonovalov@ru.mvista.com>,
	Linux PPC Embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
Date: Mon, 04 Apr 2005 09:20:47 +0200	[thread overview]
Message-ID: <4250EACF.1040403@bitsim.se> (raw)
In-Reply-To: <1112284541.23088.77.camel@cashmere.sps.mot.com>

Hi!

You don't happen to have a patch of your current work against one of the 
trees (83xx and 85xx)? It would be much easier to do work in parallell, 
and I'd be happy to do it on the "Xilinx" tree (and help out where I 
can, of course).

Jon Masters and Andrei: Does Jon Loeliger's implementation plan sound 
alright to you? Since you seem quite full-handed on your end anyway, 
Jon, I'll be happy to do the work needed unless anyone has any objections...

Cheers!

	/Jakob

Jon Loeliger wrote:
> On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
> 
>>Kumar Gala wrote:
>>
>>|> My intention was to give a device tree structure to the kernel at boot
>>|> time via a (pseudo?) pointer in bd_info or similar. 
> 
> 
>>This got resurrected recently. 
> 
> 
> Hi!
> 
> 
>>| I think this is reasonable.  The best device tree would be a flattened
>>| OF tree since we are trying to move the world in that direction.  Jon
>>| Masters around?
>>
>>Yes, but I've been tied up with worky and magazine stuff again. If
>>someone wants to work with me then this might actually happen.
> 
> 
> Hi Jon,
> 
> I'm here and actively(!) working on it now.   Here is the very
> rough plan as Kumar and I have discussed it.  Please feel free
> to comment on it or offer suggestions.  Ben has suggested that
> I start with the "second step" below.  I'd like to do a round
> of cleanup first.
> 
> So far, I have taken the first step of isolating the references
> to the global __res[] variable into one file and replacing all
> references to the data in the bd_t structure with a thin, shim
> layer of function calls that are nominally into an OF-like
> interface.  I have done this for all the 85xx and 83xx boards
> in my development tree, and am working on the others now.
> This step effectively isolates the __res[] references to one
> file where a well defined interface can be created to pose as
> an OF Device Tree layer (briefly).
> 
> As a follow-up second step, I plan on introducing essentially
> the same code currently in ppc64 to handle the flat device tree
> and provide an interface to that data in exactly the same manner
> as the ppc64 currently has.  I understand the desire to have the
> flat-tree handling be "outside the kernel".
> 
> As a third step, the shim layer will be rewritten/augmented to
> use the actual OF device tree data where it currently fronts
> for the bd_t data.
> 
> Finally, as time permits and maintainers allow (read: prod),
> the other (not 85xx, not 83xx) boards can have their setup code
> converted to use the "real" OF device tree function calls.
> 
> When all of that is done, the shim layer can be removed, as needed.
> 
> 
> Oh, yeah.  Um, also on my plate will be to construct the
> original flat-tree blob in U-Boot to be handed to the kernel.
> (I'll start with 85xx and 83xx, naturlich.)
> 
> We have not yet decided on the layout of that tree to determine
> where all the attributes and devices really belong.  I will
> also discuss with Wolfgang and crew how to generate that tree
> over in U-Boot land.
> 
> Right?
>  
> Thanks,
> jdl
> 

  reply	other threads:[~2005-04-04  7:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-30  8:00 Platform bus/ppc sys model Jakob Viketoft
2005-03-30  9:54 ` Sylvain Munaut
2005-03-30 13:52   ` Andrei Konovalov
2005-03-30 15:06     ` Kumar Gala
2005-03-30 16:12       ` Jakob Viketoft
2005-03-30 17:26         ` Kumar Gala
2005-03-31 12:33           ` Jon Masters
2005-03-31 15:55             ` Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...] Jon Loeliger
2005-04-04  7:20               ` Jakob Viketoft [this message]
2005-04-04  7:31                 ` Jon Masters
2005-04-04 10:56                 ` Andrei Konovalov
2005-04-04 11:01                   ` Jon Masters
2005-04-04 11:08                   ` Jakob Viketoft
2005-04-04 16:45                   ` Wolfgang Denk
2005-04-04 16:58                     ` Andrei Konovalov
2005-04-04 16:56                       ` Jon Masters
2005-04-07 17:20                   ` Tom Rini
2005-04-07 17:35                     ` Jon Loeliger
2005-04-07 17:49                       ` Tom Rini
2005-04-11 15:58                         ` Jon Loeliger
2005-04-14  9:54                           ` Jakob Viketoft
2005-04-15 14:22                             ` Jon Loeliger
2005-04-22 17:33                             ` Andrei Konovalov

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=4250EACF.1040403@bitsim.se \
    --to=jakob.viketoft@bitsim.se \
    --cc=akonovalov@ru.mvista.com \
    --cc=jdl@freescale.com \
    --cc=jonathan@jonmasters.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=tnt@246tNt.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 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).