Re: removing get_immrbase()??

[Kumar Gala <galak@kernel.crashing.org>]

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.

If I look at the MPC8572 SoC from FSL I will see that the following  
items aren't described today:

* Local access windows
* ECM
* GPIO - we have a binding and its possible the board doesn't use them
* PME
* TLU
* perf mon
* watchpoint debug

We also don't describe the following interrupt sources:
* ECM
* perf mon
* GPIO
* PME
* TLU
* IEEE 1588

Until we meet the most basic level of properly describing 95% of the  
HW I don't see the value you guys prescribe to FW compatibility.   
Additionally I believe for embedded developers its perfectly  
reasonable to expect them (if they are using u-boot) to possibly have  
to update their .dts/dtb if they want to update their kernel.

- k