From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gx0-f157.google.com (mail-gx0-f157.google.com [209.85.217.157]) by ozlabs.org (Postfix) with ESMTP id 196F7DDEFE for ; Wed, 1 Apr 2009 03:02:08 +1100 (EST) Received: by gxk1 with SMTP id 1so9380683gxk.9 for ; Tue, 31 Mar 2009 09:02:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090331155443.GA28242@oksana.dev.rtsoft.ru> References: <49C26434.30302@grandegger.com> <49D1E3E5.3080607@grandegger.com> <49D21C75.7060307@grandegger.com> <20090331155443.GA28242@oksana.dev.rtsoft.ru> Date: Tue, 31 Mar 2009 10:02:06 -0600 Message-ID: Subject: Re: powerpc/85xx: Add support for the "socrates" board (MPC8544) From: Grant Likely To: avorontsov@ru.mvista.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Scott Wood , linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Mar 31, 2009 at 9:54 AM, Anton Vorontsov wrote: > On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote: > [...] >> >>>>> + =A0 =A0 =A0 soc8544@e0000000 { >> >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>; >> >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>; >> >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "soc"; >> >>>> Drop device_type here too. >> >>> Grrr, I just realized that removing the devices type "soc" has broke= n >> >>> 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 co= mmon >> >>> 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 =3D "fsl,mpc8544-immr"; =A0(immr =3D=3D 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 =3D "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. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.