Re: powerpc/85xx: Add support for the socrates board (MPC8544)
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...@e000 {
+ #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
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Apr 2, 2009, at 1:38 AM, Wolfgang Grandegger wrote: 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? I'm not working on it at all. I'm also guessing at this point the Socrates support is in Linus tree :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Kumar Gala wrote:
On Apr 2, 2009, at 1:38 AM, Wolfgang Grandegger wrote:
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?
I'm not working on it at all. I'm also guessing at this point the
Socrates support is in Linus tree :)
Yes, I know, but it does not work properly because the device_type =
soc is missing :-(. I did not realize that immediately, sorry. Could
you please apply the fix below re-adding the 'device_type = soc;' line
for the time being.
Thanks.
Wolfgang.
[PATCH] powerpc/85xx: Re-add the device_type soc to socrates.dts
The device_type soc is still required for MPC85xx boards.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
arch/powerpc/boot/dts/socrates.dts |1 +
1 file changed, 1 insertion(+)
Index: powerpc/arch/powerpc/boot/dts/socrates.dts
===
--- powerpc.orig/arch/powerpc/boot/dts/socrates.dts 2009-04-01
15:26:09.0 +0200
+++ powerpc/arch/powerpc/boot/dts/socrates.dts 2009-04-02
16:37:09.838719521 +0200
@@ -52,6 +52,7 @@
soc8...@e000 {
#address-cells = 1;
#size-cells = 1;
+ device_type = soc;
ranges = 0x 0xe000 0x0010;
reg = 0xe000 0x1000; // CCSRBAR 1M
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Apr 2, 2009, at 1:50 PM, Wolfgang Grandegger wrote: [PATCH] powerpc/85xx: Re-add the device_type soc to socrates.dts The device_type soc is still required for MPC85xx boards. Signed-off-by: Wolfgang Grandegger w...@grandegger.com --- arch/powerpc/boot/dts/socrates.dts |1 + 1 file changed, 1 insertion(+) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Anton Vorontsov wrote:
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #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?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
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...@e000 {
+ #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.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
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...@e000 {
+ #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?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
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...@e000 {
+ #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.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Grant Likely wrote:
I agree 100% with David's comments, and I have some additional ones below.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
+ soc8...@e000 {
+ #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.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Tue, Mar 31, 2009 at 3:35 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Grant Likely wrote:
I agree 100% with David's comments, and I have some additional ones below.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
+ soc8...@e000 {
+ #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.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Grant Likely wrote:
On Tue, Mar 31, 2009 at 3:35 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Grant Likely wrote:
I agree 100% with David's comments, and I have some additional ones below.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
+ soc8...@e000 {
+ #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?
Unfortunately, other 85xx functions search for the device type soc as
well. Therefore I think we must keep the devices type soc for the time
being. Kumar?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Tue, Mar 31, 2009 at 7:36 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Grant Likely wrote:
On Tue, Mar 31, 2009 at 3:35 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
Grant Likely wrote:
I agree 100% with David's comments, and I have some additional ones below.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
+ soc8...@e000 {
+ #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.
Unfortunately, other 85xx functions search for the device type soc as
well. Therefore I think we must keep the devices type soc for the time
being. Kumar?
Fix them! :-)
Most troublesome places are where of_find_node_by_type() is used (I
see two cases in fsl_soc.c). I added the of_find_matching_node()
function specifically to rework code that was only matching on a
single compatible or type value. See usage of mpc52xx_bus_ids in
arch/powerpc/platforms/52xx/mpc52xx_common.c for an example.
It is a pain, but I think it is important to be reducing device_type
usage as we hit against them.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #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. ;-)
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Tue, Mar 31, 2009 at 9:54 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
[...]
+ soc8...@e000 {
+ #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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Grant Likely wrote:
I agree 100% with David's comments, and I have some additional ones below.
OK.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Drop device_type here too.
+
+ ranges = 0x 0xe000 0x0010;
+ reg = 0xe000 0x1000; // CCSRBAR 1M
+ bus-frequency = 0;// Filled in by U-Boot
+ compatible = fsl,socrates-immr, simple-bus;
As David said, fix this to be SoC specific, not board specific.
+ localbus {
+ compatible = fsl,socrates-localbus,
+fsl,mpc85xx-localbus,
+fsl,pq3-localbus;
1st entry shouldn't be there.
2nd entry should specify exact chip
3rd entry I don't like much, but others may debate me on it
Also, add simple-bus to this list. (important for a later comment)
OK.
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xe0005000 0x40;
+
+ ranges = 0 0 0xfc00 0x0400
+ 2 0 0xc800 0x0400
+ 3 0 0xc000 0x0010
+ ; /* Overwritten by U-Boot */
Just curious, why is U-Boot overwriting the ranges property?
Because there are boards without FPGA or graphic controller on the local
bus.
+ fpga_pic: fpga-...@3,10 {
+ compatible = abb,socrates-fpga-pic;
Is 'abb' the companies' stock ticker symbol? If not, then use the
real name and not an abbreviation.
Yes.
Index: linux-2.6/arch/powerpc/boot/wrapper
===
--- linux-2.6.orig/arch/powerpc/boot/wrapper
+++ linux-2.6/arch/powerpc/boot/wrapper
@@ -183,7 +183,7 @@ cuboot*)
*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555|*-ksi8560*)
platformo=$object/cuboot-85xx-cpm2.o
;;
-*-mpc85*|*-tqm85*|*-sbc85*)
+*-mpc85*|*-tqm85*|*-sbc85*|*-socrates)
platformo=$object/cuboot-85xx.o
;;
Is this a new or old platform? Can U-Boot on the board boot with a
uImage + dtb instead of a cuImage? I'd prefer to avoid adding new
cuImages to the wrapper script if at all possible.
It's a new platform. Therefore I will drop cuboot support.
Index: linux-2.6/arch/powerpc/configs/85xx/socrates_defconfig
===
--- /dev/null
+++ linux-2.6/arch/powerpc/configs/85xx/socrates_defconfig
Is a socrates-specific defconfig really warranted?
--- linux-2.6.orig/arch/powerpc/platforms/85xx/Makefile
+++ linux-2.6/arch/powerpc/platforms/85xx/Makefile
@@ -13,4 +13,6 @@ obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx)+= tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
obj-$(CONFIG_SBC8548) += sbc8548.o
+obj-$(CONFIG_SOCRATES)+= socrates.o
+obj-$(CONFIG_SOCRATES)+= socrates_fpga_pic.o
The pic stuff isn't all that big. Personally I'd roll it all into the
socrates.c file.
Well,
$ wc -l socrates_fpga_pic.c
156 socrates.c
320 socrates_fpga_pic.c
Personally, I'd prefer to separate the pic from the board init code,
especially with that size.
--- /dev/null
+++ linux-2.6/arch/powerpc/platforms/85xx/socrates.c
+static void __init socrates_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, open-pic);
+ if (!np) {
+ printk(KERN_ERR Could not find open-pic node\n);
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, r)) {
+ printk(KERN_ERR Could not map mpic register space\n);
+ of_node_put(np);
+ return;
+ }
+
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
+ 0, 256, OpenPIC );
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_init(mpic);
Heh, this is a block of code cloned between all the 85xx boards it
seems. Smells like a small refactoring candidate. This isn't really
a critique of this patch, but I noticed it so I thought I'd mention
it.
+static void socrates_show_cpuinfo(struct seq_file *m)
+{
+ uint pvid, svid, phid1;
+ uint memsize = total_memory;
+
+ pvid = mfspr(SPRN_PVR);
+ svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, PVR\t\t: 0x%x\n, pvid);
+ seq_printf(m, SVR\t\t: 0x%x\n, svid);
+
+ /* Display cpu Pll setting */
+ phid1 = mfspr(SPRN_HID1);
+ seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
+
+ /* Display the amount of memory */
+ seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
+}
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
David Gibson wrote:
On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
[snip]
[snip[
+disp...@2,0 {
+compatible = fujitsu,lime;
This compat string looks slightly worryingly non-specific.
The node is for the Lime graphic controller from Fujitsu. What does
worry you?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
Hi Kumar,
Kumar Gala wrote:
On Mar 19, 2009, at 10:26 AM, Wolfgang Grandegger wrote:
+m...@24520 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = fsl,gianfar-mdio;
+reg = 0x24520 0x20;
+
+phy0: ethernet-...@0 {
+interrupt-parent = mpic;
+interrupts = 0 1;
+reg = 0;
+device_type = ethernet-phy;
+};
+phy1: ethernet-...@1 {
+interrupt-parent = mpic;
+interrupts = 0 1;
+reg = 1;
+device_type = ethernet-phy;
+};
+tbi0: tbi-...@11 {
+reg = 0x11;
+device_type = tbi-phy;
+};
+};
+
+m...@26520 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = fsl,gianfar-tbi;
+reg = 0x26520 0x20;
+
+tbi1: tbi-...@11 {
+reg = 0x11;
+device_type = tbi-phy;
+};
+};
+
+enet0: ether...@24000 {
+cell-index = 0;
+device_type = network;
+model = eTSEC;
+compatible = gianfar;
+reg = 0x24000 0x1000;
+local-mac-address = [ 00 00 00 00 00 00 ];
+interrupts = 29 2 30 2 34 2;
+interrupt-parent = mpic;
+phy-handle = phy0;
+tbi-handle = tbi0;
+phy-connection-type = rgmii-id;
+};
+
See Anton's recent post in moving the mdio node under the ethernet.
Please match.
I have fixed it for the socrates board. Is there a GIT tree with that
modifications which I can base my patches on, also for the one for the
TQM8548 posted recently:
http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069364.html
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
David Gibson wrote:
On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
This patch adds support for the socrates board based on the MPC8544.
Supported are Ethernet, serial console, I2C, I2C-based RTC and
temperature sensors, NOR and NAND flash, PCI, USB, CAN and Lime
display controller.
The multiplexing of FPGA interrupts onto PowerPC interrupt lines is
supported through our own fpga_pic interrupt controller driver.
For example the SJA1000 controller is level low sensitive connected to
fpga_pic line 2 and is routed to the second (of three) irq lines to
the CPU:
A few minor device tree nits.
+soc8...@e000 {
+#address-cells = 1;
+#size-cells = 1;
+device_type = soc;
+
+ranges = 0x 0xe000 0x0010;
+reg = 0xe000 0x1000; // CCSRBAR 1M
+bus-frequency = 0;// Filled in by U-Boot
+compatible = fsl,socrates-immr, simple-bus;
This should probably refer to 8544 instead of socrates. Unless you
really do have a board-specific version of the SoC...
OK, that should then be:
+compatible = fsl,mpc8544-immr, simple-bus;
It should always be with the prefix mpc, I guess. But some of the
following compatible names are without that prefix:
$ grep -h '\-l2-cache-controller' *
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,mpc8536-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,8541-l2-cache-controller;
compatible = fsl,8544-l2-cache-controller;
compatible = fsl,8548-l2-cache-controller;
compatible = fsl,8555-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,8568-l2-cache-controller;
compatible = fsl,mpc8572-l2-cache-controller;
compatible = fsl,mpc8572-l2-cache-controller;
compatible = fsl,mpc8572-l2-cache-controller;
compatible = fsl,8548-l2-cache-controller;
compatible = fsl,8560-l2-cache-controller;
compatible = fsl,mpc8544-l2-cache-controller;
compatible = fsl,mpc8544-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,mpc8548-l2-cache-controller;
compatible = fsl,mpc8548-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
compatible = fsl,8540-l2-cache-controller;
That's confusing.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
This patch adds support for the socrates board based on the MPC8544.
Supported are Ethernet, serial console, I2C, I2C-based RTC and
temperature sensors, NOR and NAND flash, PCI, USB, CAN and Lime
display controller.
The multiplexing of FPGA interrupts onto PowerPC interrupt lines is
supported through our own fpga_pic interrupt controller driver.
For example the SJA1000 controller is level low sensitive connected to
fpga_pic line 2 and is routed to the second (of three) irq lines to
the CPU:
A few minor device tree nits.
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+
+ ranges = 0x 0xe000 0x0010;
+ reg = 0xe000 0x1000; // CCSRBAR 1M
+ bus-frequency = 0;// Filled in by U-Boot
+ compatible = fsl,socrates-immr, simple-bus;
This should probably refer to 8544 instead of socrates. Unless you
really do have a board-specific version of the SoC...
[snip]
+ m...@24520 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+
+ phy0: ethernet-...@0 {
+ interrupt-parent = mpic;
+ interrupts = 0 1;
+ reg = 0;
+ device_type = ethernet-phy;
No device_type here.
+ };
+ phy1: ethernet-...@1 {
+ interrupt-parent = mpic;
+ interrupts = 0 1;
+ reg = 1;
+ device_type = ethernet-phy;
+ };
+ tbi0: tbi-...@11 {
+ reg = 0x11;
+ device_type = tbi-phy;
Or here.
[snip]
+ localbus {
+ compatible = fsl,socrates-localbus,
+ fsl,mpc85xx-localbus,
+ fsl,pq3-localbus;
Is this bus controller part of the SoC? If so, the first compatible
string probably shouldn't be there (as for the soc/immr node itself).
[snip[
+ disp...@2,0 {
+ compatible = fujitsu,lime;
This compat string looks slightly worryingly non-specific.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
On Mar 19, 2009, at 10:26 AM, Wolfgang Grandegger wrote:
+ m...@24520 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+
+ phy0: ethernet-...@0 {
+ interrupt-parent = mpic;
+ interrupts = 0 1;
+ reg = 0;
+ device_type = ethernet-phy;
+ };
+ phy1: ethernet-...@1 {
+ interrupt-parent = mpic;
+ interrupts = 0 1;
+ reg = 1;
+ device_type = ethernet-phy;
+ };
+ tbi0: tbi-...@11 {
+ reg = 0x11;
+ device_type = tbi-phy;
+ };
+ };
+
+ m...@26520 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-tbi;
+ reg = 0x26520 0x20;
+
+ tbi1: tbi-...@11 {
+ reg = 0x11;
+ device_type = tbi-phy;
+ };
+ };
+
+ enet0: ether...@24000 {
+ cell-index = 0;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 0x24000 0x1000;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = 29 2 30 2 34 2;
+ interrupt-parent = mpic;
+ phy-handle = phy0;
+ tbi-handle = tbi0;
+ phy-connection-type = rgmii-id;
+ };
+
See Anton's recent post in moving the mdio node under the ethernet.
Please match.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/85xx: Add support for the socrates board (MPC8544)
I agree 100% with David's comments, and I have some additional ones below.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
Drop device_type here too.
+
+ ranges = 0x 0xe000 0x0010;
+ reg = 0xe000 0x1000; // CCSRBAR 1M
+ bus-frequency = 0; // Filled in by U-Boot
+ compatible = fsl,socrates-immr, simple-bus;
As David said, fix this to be SoC specific, not board specific.
+ localbus {
+ compatible = fsl,socrates-localbus,
+ fsl,mpc85xx-localbus,
+ fsl,pq3-localbus;
1st entry shouldn't be there.
2nd entry should specify exact chip
3rd entry I don't like much, but others may debate me on it
Also, add simple-bus to this list. (important for a later comment)
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xe0005000 0x40;
+
+ ranges = 0 0 0xfc00 0x0400
+ 2 0 0xc800 0x0400
+ 3 0 0xc000 0x0010
+ ; /* Overwritten by U-Boot */
Just curious, why is U-Boot overwriting the ranges property?
+ fpga_pic: fpga-...@3,10 {
+ compatible = abb,socrates-fpga-pic;
Is 'abb' the companies' stock ticker symbol? If not, then use the
real name and not an abbreviation.
Index: linux-2.6/arch/powerpc/boot/wrapper
===
--- linux-2.6.orig/arch/powerpc/boot/wrapper
+++ linux-2.6/arch/powerpc/boot/wrapper
@@ -183,7 +183,7 @@ cuboot*)
*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555|*-ksi8560*)
platformo=$object/cuboot-85xx-cpm2.o
;;
- *-mpc85*|*-tqm85*|*-sbc85*)
+ *-mpc85*|*-tqm85*|*-sbc85*|*-socrates)
platformo=$object/cuboot-85xx.o
;;
Is this a new or old platform? Can U-Boot on the board boot with a
uImage + dtb instead of a cuImage? I'd prefer to avoid adding new
cuImages to the wrapper script if at all possible.
Index: linux-2.6/arch/powerpc/configs/85xx/socrates_defconfig
===
--- /dev/null
+++ linux-2.6/arch/powerpc/configs/85xx/socrates_defconfig
Is a socrates-specific defconfig really warranted?
--- linux-2.6.orig/arch/powerpc/platforms/85xx/Makefile
+++ linux-2.6/arch/powerpc/platforms/85xx/Makefile
@@ -13,4 +13,6 @@ obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
obj-$(CONFIG_SBC8548) += sbc8548.o
+obj-$(CONFIG_SOCRATES) += socrates.o
+obj-$(CONFIG_SOCRATES) += socrates_fpga_pic.o
The pic stuff isn't all that big. Personally I'd roll it all into the
socrates.c file.
--- /dev/null
+++ linux-2.6/arch/powerpc/platforms/85xx/socrates.c
+static void __init socrates_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, open-pic);
+ if (!np) {
+ printk(KERN_ERR Could not find open-pic node\n);
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, r)) {
+ printk(KERN_ERR Could not map mpic register space\n);
+ of_node_put(np);
+ return;
+ }
+
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
+ 0, 256, OpenPIC );
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_init(mpic);
Heh, this is a block of code cloned between all the 85xx boards it
seems. Smells like a small refactoring candidate. This isn't really
a critique of this patch, but I noticed it so I thought I'd mention
it.
+static void socrates_show_cpuinfo(struct seq_file *m)
+{
+ uint pvid, svid, phid1;
+ uint memsize = total_memory;
+
+ pvid = mfspr(SPRN_PVR);
+ svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, PVR\t\t: 0x%x\n, pvid);
+ seq_printf(m, SVR\t\t: 0x%x\n, svid);
+
+ /* Display cpu Pll setting */
+ phid1 = mfspr(SPRN_HID1);
+ seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
+
+ /* Display the amount of memory */
+ seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
+}
Another block of duplicated code. In fact, many platforms have
dropped the cpuinfo hook entirely and just use the default output.
+
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .name = soc, },
+ { .type = soc, },
+ { .name = localbus, },
Drop these three lines. It is considered bad form now to bind on
either name or type for flattened device
