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 62A67DDE1F for ; Wed, 1 Apr 2009 23:40:16 +1100 (EST) Received: by gxk1 with SMTP id 1so53275gxk.9 for ; Wed, 01 Apr 2009 05:40:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49D3197C.7000806@grandegger.com> References: <49C26434.30302@grandegger.com> <49D1E3E5.3080607@grandegger.com> <49D21C75.7060307@grandegger.com> <20090331155443.GA28242@oksana.dev.rtsoft.ru> <49D3197C.7000806@grandegger.com> Date: Wed, 1 Apr 2009 06:40:14 -0600 Message-ID: Subject: Re: powerpc/85xx: Add support for the "socrates" board (MPC8544) From: Grant Likely To: Wolfgang Grandegger 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 Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger wro= te: > 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. ;-) > > 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. g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.