Grant Likely wrote:
> On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger <w...@grandegger.com>
> wrote:
>> Anton Vorontsov wrote:
>>> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
>>> [...]
>>>>>>>>> + soc8...@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?
Wolfgang.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
