powerpc/85xx: Add support for the "socrates" board (MPC8544)

Grant Likely grant.likely at secretlab.ca
Wed Apr 1 03:02:06 EST 2009


On Tue, Mar 31, 2009 at 9:54 AM, Anton Vorontsov
<avorontsov at ru.mvista.com> wrote:
> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
> [...]
>> >>>>> +       soc8544 at 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. ;-)

I'm totally fine with fsl,soc *providing* that it is documented as to
exactly what it describes, what properties are expected, and how they
are used.  Since fsl,soc is not tied to a specific piece of silicon I
want to guard against the definition of "fsl,soc" drifting over time.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.



More information about the Linuxppc-dev mailing list