From: Grant Likely <grant.likely@secretlab•ca>
To: Kumar Gala <galak@kernel•crashing.org>
Cc: Scott Wood <scottwood@freescale•com>, linuxppc-dev@ozlabs•org
Subject: Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
Date: Wed, 1 Apr 2009 07:49:21 -0600 [thread overview]
Message-ID: <fa686aa40904010649t36cde982wc19fc05de42b340c@mail.gmail.com> (raw)
In-Reply-To: <D7365D0C-57B0-479C-9335-265620B8E5AE@kernel.crashing.org>
On Wed, Apr 1, 2009 at 7:27 AM, Kumar Gala <galak@kernel•crashing.org> wrot=
e:
>
> 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 <wg@grandegger•com>
>>> wrote:
>>>>
>>>> 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
>>>>>>>>> broken
>>>>>>>>> fsl_get_sys_freq(). See:
>>>>>>>>>
>>>>>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L=
80
>>>>>>>>>
>>>>>>>>> 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 =3D "fsl,mpc8544-immr"; =A0(immr =3D=3D Internally Memo=
ry Mapped
>>>>>>>> Registers)
>>>>>>>>
>>>>>>>> Many other boards already do this.
>>>>>>>
>>>>>>> Yes, it does, but searching for the SOC node is not straight-forwar=
d
>>>>>>> because there is no common compatibility string but many CPU-specif=
ic
>>>>>>> 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. =A0I'm not asking you to fix all the other boards, bu=
t
>>> 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
>> =A0"fsl,soc" instead of the device type "soc" (or both for backward
>> =A0compatibility).
>>
>> - fix U-Boot to find the SOC node by looking for "fsl,soc" to insert the
>> =A0proper 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 =3D "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 ma=
ke
> it so new .dts don't require device_type =3D soc in them if using new ker=
nels.
Exactly.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2009-04-01 13:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 15:26 powerpc/85xx: Add support for the "socrates" board (MPC8544) Wolfgang Grandegger
2009-03-20 4:10 ` David Gibson
2009-03-20 20:12 ` Wolfgang Grandegger
2009-03-20 22:02 ` Wolfgang Grandegger
2009-03-20 4:26 ` Kumar Gala
2009-03-20 20:16 ` Wolfgang Grandegger
2009-03-20 5:05 ` Grant Likely
2009-03-20 11:57 ` Wolfgang Grandegger
2009-03-31 9:35 ` Wolfgang Grandegger
2009-03-31 13:23 ` Grant Likely
2009-03-31 13:36 ` Wolfgang Grandegger
2009-03-31 15:05 ` Grant Likely
2009-03-31 15:54 ` Anton Vorontsov
2009-03-31 16:02 ` Grant Likely
2009-04-01 7:36 ` Wolfgang Grandegger
2009-04-01 12:40 ` Grant Likely
2009-04-01 13:10 ` Wolfgang Grandegger
2009-04-01 13:27 ` Kumar Gala
2009-04-01 13:49 ` Grant Likely [this message]
2009-04-02 6:38 ` Wolfgang Grandegger
2009-04-02 13:47 ` Kumar Gala
2009-04-02 18:50 ` Wolfgang Grandegger
2009-04-02 19:52 ` Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa686aa40904010649t36cde982wc19fc05de42b340c@mail.gmail.com \
--to=grant.likely@secretlab$(echo .)ca \
--cc=galak@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=scottwood@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox