Hi Kumar,
Kumar Gala wrote:
>
> 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
>>> <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?
>
> 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.
Socrates is a new board and it has no problem using an up-to-date
version of U-Boot. The socrates.dts file in your "next" tree already has
the "device_type = "soc" removed. We need to add "fsl,soc" to the
"compatible" property and update fsl_get_sys_freq(), etc. to search for
it as well. And U-Boot should use the same name to fixup the
frequencies. Are you already working on that issue? Should I provide
patches?
Wolfgang.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
