LinuxPPC-Dev Archive on lore.kernel.org

* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Kumar Gala @ 2009-04-01 13:27 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <49D367C7.5010802@grandegger.com>

On Apr 1, 2009, at 8:10 AM, Wolfgang Grandegger wrote:

> Grant Likely wrote:
>> On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger <wg@grandegger.com 
>> > wrote:
>>> Anton Vorontsov wrote:
>>>> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
>>>> [...]
>>>>>>>>>> +       soc8544@e0000000 {
>>>>>>>>>> +               #address-cells = <1>;
>>>>>>>>>> +               #size-cells = <1>;
>>>>>>>>>> +               device_type = "soc";
>>>>>>>>> Drop device_type here too.
>>>>>>>> Grrr, I just realized that removing the devices type "soc"  
>>>>>>>> has broken
>>>>>>>> fsl_get_sys_freq(). See:
>>>>>>>>
>>>>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>>>>
>>>>>>>> We need a quick fix and we could take the occasion to  
>>>>>>>> establish a common
>>>>>>>> function for the MPC52xx as well, but it's not obvious to me  
>>>>>>>> how to find
>>>>>>>> the SOC node without the device type property.
>>>>>>> SoC node should have a compatible property, just like  
>>>>>>> everything else.
>>>>>>>
>>>>>>> compatible = "fsl,mpc8544-immr";  (immr == Internally Memory  
>>>>>>> Mapped Registers)
>>>>>>>
>>>>>>> Many other boards already do this.
>>>>>> Yes, it does, but searching for the SOC node is not straight- 
>>>>>> forward
>>>>>> because there is no common compatibility string but many CPU- 
>>>>>> specific
>>>>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I  
>>>>>> missed
>>>>>> something?
>>>>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly  
>>>>> what it
>>>>> means, and add add it to the end of the compatible list.
>>>> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
>>>> parts. There it's called CCSR.
>>>>
>>>> See this thread:
>>>>
>>>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>>>>
>>>> I still think that
>>>> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
>>>> and
>>>> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>>>>
>>>> would be OK, at least to start with. We can always deprecate  
>>>> "fsl,soc"
>>>> compatible in favour of something more elegant, but "fsl,soc"  
>>>> should be
>>>> just fine to replace device_type = "soc".
>>>>
>>>> Also, there is another good thing about "fsl,soc" -- U-Boot already
>>>> finds it for 83xx CPUs. ;-)
>>> Ugh! I just realize the full impact of removing device type "soc".  
>>> It
>>> will break compatibility with U-Boot for many boards. Is it worth  
>>> it?
>>
>> Yes, I know this.  I'm not asking you to fix all the other boards,  
>> but
>> make sure that it is not required for the new board.
>
> Hm, I'm confused, if we want to fix this issue we need first to
>
> - fix all functions in fsl_soc.c searching for the compatible string
>  "fsl,soc" instead of the device type "soc" (or both for backward
>  compatibility).
>
> - fix U-Boot to find the SOC node by looking for "fsl,soc" to insert  
> the
>  proper bus-frequency, at least.
>
> That affects *all* boards using CONFIG_FSL_SOC and requires an
> up-to-date version of U-Boot for new kernels :-(. If that is fixed, I
> can remove the "device_type = "soc";" from socrates.dts (and may  
> more),
> but not right now. Or have I missed something?

I presume the intent is not to break old u-boots w/new kernels, but to  
make it so new .dts don't require device_type = soc in them if using  
new kernels.

- k

^ permalink raw reply