On Aug 31, 2005, at 7:47 PM, Arnd Bergmann wrote:
> Move all files from arch/ppc64/kernel/bpa_* to arch/powerpc/
> platforms/cell,
>
> I would like to see a patch like this go into 2.6.14, for multiple
> reasons:
>
> - The marketing folks have changed the names and we are no longer
> supposed
> to refer to Cell as 'BPA' or 'Broadband Processor Architecture'.
> The platform is officially known as 'Cell Broadband Engine
> Architecture',
> while the CPU is the 'Cell Broadband Engine'.
>
> - We are now moving all platforms into arch/powerpc/platforms and
> someone
> has to start so we get a template for the other architectures to
> follow.
>
> - It would be a big mess for me to maintain my own patches on top
> of file
> names that are different from mainline during the 2.6.14 freeze.
>
> My impression is that Cell is a good target for moving first,
> because I
> have to move it anyway and the number of users is extremely low, so it
> doesn't cause too much harm if we screw up. What thing that makes
> moving
> Cell relatively easy is that it only supports 64 bit and only a single
> hardware configuration so far.
>
> I have tested this a bit on Cell and also done compile-only test
> for the
> other platforms, but it doesn't really make any changes to the code
> itself.
>
> Please comment on wether this is what everybody like the merge process
> be like.
I'm not 100% sure if this is the right time for introducing a
platform into arch/powerpc. My concern is around that fact that we
have not tried to move any "code" from arch/ppc or arch/ppc64 into
arch/powerpc and so havent figured out how we are going to do that
will not breaking arch/ppc & arch/ppc64. By introducing cell this
way we create a dependency between ppc64 and powerpc that might
constrain decisions we want to make.
> Signed-off-by: Arnd Bergmann <[email protected]>
>
> --
> arch/powerpc/platforms/cell/Makefile | 1
> arch/ppc64/kernel/Makefile | 5
> arch/powerpc/platforms/cell/pic.c | 269 +++++++++++++++++++
> +++
> arch/ppc64/kernel/bpa_iic.c | 270
> ----------------------
> include/asm-powerpc/cell-pic.h | 62 +++++
> arch/ppc64/kernel/bpa_iic.h | 62 -----
> arch/powerpc/platforms/cell/iommu.c | 377 +++++++++++++++++++
> ++++++++++++
> arch/ppc64/kernel/bpa_iommu.c | 377
> -------------------------------
> arch/powerpc/platforms/cell/iommu.h | 65 +++++
> arch/ppc64/kernel/bpa_iommu.h | 65 -----
> arch/powerpc/platforms/cell/nvram.c | 118 +++++++++
> arch/ppc64/kernel/bpa_nvram.c | 118 ---------
Should pic, iommu, and nvram really be in arch/powerpc/sysdev/
Also, since your renaming things any chance there is a better name
for iic? (just wondering since its way to similar to what some people
use for I2C).
> arch/powerpc/platforms/cell/setup.c | 138 +++++++++++
> arch/ppc64/kernel/bpa_setup.c | 140 -----------
> arch/powerpc/platforms/cell/spider-pic.c | 190 +++++++++++++++
> arch/ppc64/kernel/spider-pic.c | 191 ---------------
> arch/ppc64/Kconfig | 10
> arch/ppc64/kernel/cpu_setup_power4.S | 2
> arch/ppc64/kernel/cputable.c | 6
> arch/ppc64/kernel/irq.c | 2
> arch/ppc64/kernel/pSeries_smp.c | 4
> arch/ppc64/kernel/setup.c | 8
> arch/ppc64/kernel/traps.c | 4
> include/asm-ppc64/nvram.h | 2
> include/asm-ppc64/processor.h | 7
> 25 files changed, 1248 insertions(+), 1245 deletions(-)
On Dunnersdag 01 September 2005 16:11, Kumar Gala wrote:
> I'm not 100% sure if this is the right time for introducing a
> platform into arch/powerpc. My concern is around that fact that we
> have not tried to move any "code" from arch/ppc or arch/ppc64 into
> arch/powerpc and so havent figured out how we are going to do that
> will not breaking arch/ppc & arch/ppc64. By introducing cell this
> way we create a dependency between ppc64 and powerpc that might
> constrain decisions we want to make.
I understand that there are good reasons for merging all the headers
first and only then start with the architecture code, that also
was my idea at first.
At least from the Kbuild side, it should not cause trouble
to refer to different architecture directories from
arch/ppc64/kernel/Makefile, that does not introduce any strong
dependency.
For the code itself, we probably need to make substantial changes
at some point, e.g. when we merge arch/powerpc/kernel/setup.c.
However, I don't think it makes much difference wether that
is done while the code resides in arch/ppc64 or arch/powerpc.
> > Signed-off-by: Arnd Bergmann <[email protected]>
> >
> > --
> > arch/powerpc/platforms/cell/Makefile | 1
> > arch/ppc64/kernel/Makefile | 5
> > arch/powerpc/platforms/cell/pic.c | 269 ++++++++++++++++++++++
> > arch/ppc64/kernel/bpa_iic.c | 270 ----------------------
> > include/asm-powerpc/cell-pic.h | 62 +++++
> > arch/ppc64/kernel/bpa_iic.h | 62 -----
> > arch/powerpc/platforms/cell/iommu.c | 377 +++++++++++++++++++++++++++++++
> > arch/ppc64/kernel/bpa_iommu.c | 377 -------------------------------
> > arch/powerpc/platforms/cell/iommu.h | 65 +++++
> > arch/ppc64/kernel/bpa_iommu.h | 65 -----
> > arch/powerpc/platforms/cell/nvram.c | 118 +++++++++
> > arch/ppc64/kernel/bpa_nvram.c | 118 ---------
>
> Should pic, iommu, and nvram really be in arch/powerpc/sysdev/
The pic and iommu are defined in the CBE Architecture documents
and different from all others, so I would prefer to keep them
here. Both the internal interrupt controller (IIC) and the
IO page tables are part of the CPU itself, so you will always
see them together with Cell based hardware.
For nvram, you are probably right that it belongs to a more
generic place, as I just wrote in my reply to Murali.
With regard to the arch/powerpc/sysdev/ location for putting
the drivers, I'm not sure if we should first find a better
definition of what goes in there. I remember that some people
did not like the current split between arch/ppc/kernel and
arch/ppc/syslib.
Do you think of arch/powerpc/sysdev/ as a different thing from
the current syslib (e.g. stuff using include/linux/sysdev.h),
or just a different name for the same thing?
> Also, since your renaming things any chance there is a better name
> for iic? (just wondering since its way to similar to what some people
> use for I2C).
Yes, Ben has expressed the same concern to me, therefore I have renamed
the file to 'pic' instead of 'iic'. However, the architecture is very
specifically calling it IIC, so my idea was to keep the identifiers
with that name, hoping that this does not cause trouble when the files
are clearly marked as belonging to one specific platform.
If you have a better idea for naming it, I can change it of course.
Arnd <><