Re: removing get_immrbase()??

From: David Gibson <david@gibson.dropbear.id.au>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>,
	Linuxppc-dev Development <linuxppc-dev@ozlabs.org>,
	Timur Tabi <timur@freescale.com>
Subject: Re: removing get_immrbase()??
Date: Thu, 23 Apr 2009 14:06:42 +1000	[thread overview]
Message-ID: <20090423040642.GG19376@yookeroo.seuss> (raw)
In-Reply-To: <80CA86D4-3DA5-4C28-AE7A-C03CE5758774@kernel.crashing.org>

On Wed, Apr 22, 2009 at 10:36:36PM -0500, Kumar Gala wrote:
>
> On Apr 22, 2009, at 9:26 PM, David Gibson wrote:
>
>> On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
>>>
>>> On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
>>>
>>>> Kumar Gala wrote:
>>>>> I disagree.  If you update your kernel you should update your  
>>>>> device
>>>>> tree (thus we have .dts in the kernel tree and not somewhere else).
>>>>
>>>> No.  The device tree is a means to pass information from the  
>>>> firmware
>>>> to the kernel.  It is part of the firmware.  That the repository of
>>>> trees is in the Linux kernel for any boards which are not  
>>>> including the
>>>> tree inside a bootwrapper is a historical accident.
>>>
>>> I think its a point of view argument.  I don't agree its part of the
>>> firmware, at least not part of the firmware we use (u-boot).
>>
>> 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.  With
>> OF it's clearly in the firmware, with cuboot it's clearly in the
>> kernel.  With modern u-boot, it's a bit fuzzier.  But if the dts is
>> flashed into the device in the same way as the bootloader, then it's
>> fair to avoid having to change it, in the same way we usually provide
>> workarounds to work with old firmware versions.
>
> I think this all sounds great in theory but in reality the vast majority 
> (I'd say over 80-90%) we are talking about embedded reference boards.  
> They are subject to change as we evolve support over time.  Our firmware 
> isn't well defined and stable like a x86 PC system or true OF platform.  
> I will also say we have made mistakes as learned from them and one we 
> keep repeating is NOT ensuring at a minimum that all parts of the SOC 
> memory map are actually described in the device tree to start with.

Well, yes, I guess I agree.  How immutable you consider the device
tree blob to be is a judgement call based on the specific details of
platform/board in question.  If it is indeed a reference platform, in
the early stages of development where it's reasonably easy to change
the dtb, then it's probably best to change the dtb in sync with the
kernel to reduce long-term cruft build-up.  But once the board is
sufficiently widely deployed, you want to stop doing that and include
backwards compatibility workarounds in the kernel to cope with the
widely deployed broken trees.

-- 
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