From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bilbo.ozlabs.org (bilbo.ozlabs.org [203.10.76.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bilbo.ozlabs.org", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 51B42DDDF9 for ; Tue, 28 Apr 2009 15:00:56 +1000 (EST) Date: Tue, 28 Apr 2009 14:21:05 +1000 From: David Gibson To: Timur Tabi Subject: Re: removing get_immrbase()?? Message-ID: <20090428042105.GD11265@yookeroo.seuss> References: <49EF7B11.2000006@freescale.com> <49EF7B1C.2080105@freescale.com> <282847E1-AE1A-44EF-9D18-AF2884105FA5@kernel.crashing.org> <49EF8E3A.4060304@freescale.com> <5D0145E3-0A98-429E-8D53-1A8DF4216462@kernel.crashing.org> <20090423022610.GA19376@yookeroo.seuss> <49F066DC.402@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <49F066DC.402@freescale.com> Cc: Scott Wood , Linuxppc-dev Development List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote: > David Gibson wrote: > > > It's not so much point of view as situation. Putting the device tree > > in the firmware and putting the device tree in the kernel are both > > valid choices, with their own distinct advantages and drawbacks. > > I was under the impression that the reason we put the device trees in > the kernel is because we didn't have a better place to put them. > Keeping them in the kernel repository was just convenient. > > So I personally don't consider the *location* of the DTS files to be a > basis for deciding what they really mean. I'm not talking abou where the DTS files sit, I'm talking about where the compiled blob sits. There are a number of options here: * built into the firmware * loaded by the firmware, say from a separate flash partition (e.g. modern uboot) * generated at runtime by the firmware * built into the kernel's bootwrapper (e.g. cuboot). * generated by the bootwrapper at runtime from firmware information in another format (e.g. paul's proposed res2dt approach for PReP) Which method is appropriate depends on the needs of the platform, including what legacy stuff we need to deal with for the platform. Then in turn, how hard we should work to make the kernel backwards compatible with old device tree formats depends on what choice we made here (for platform specific devices, obviously). -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson