MPC5xxx code issues

MPC5xxx code issues

[Tom Rini]

Okay, after giving the code a good review, here's my list of things to
try and get done on the MPC5xxx code:

I don't understand:
include/asm-ppc/io.h: Why does CONFIG_ICECUBE define _IO_BASE, etc to 0
when it sets isa_io_base, etc.
drivers/i2c/i2c-algo-mpc5xxx.c, drivers/i2c/i2c-icecube.c: Is the
-icecube file actually icecube specific or is this a case of following
the 8xx model?

Must clean: These files need some sort of rewrite to look less like a
drop of commerical code into the kernel and more like working the
commercial code into the kernel:
arch/ppc/5xxx_io/bestcomm/capi/Makefile
arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/Makefile
arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos2/Makefile
arch/ppc/5xxx_io/bestcomm/include/dummy files (should these be needed?)

Really should get reviewed: These drivers really should be run past the
respective overall maintainers.  I cannot push these to Marcelo (with
the exeception of the FEC driver) without their approval:
arch/ppc/5xxx_io/fec.[ch]
drivers/i2c/i2c-algo-mpc5xxx.c
drivers/i2c/i2c-icecube.c
drivers/ide/ide-dma.c (I've seen a similar patch for 2.6 so this should
be easy to get in).
drivers/ide/ppc/mpc5xxx_ide.c, etc (I'm not actually sure if Alan
reviews drivers, or would given that he's spending less time on Linux
right now).
drivers/mtd/maps/icecube.c (There's recent MTD changes so that the
physmap.c driver can be used instead on a lot of platforms, I don't know
if this would work for the IceCube or not.  Something to keep in mind
however, should MTD be updated in kernel.org)
drivers/usb/host/usb-ohci.c, etc.

Wishlist: It really would be nice to do this, but I can accept it if
they don't happen:
CONFIG_UBOOT: In all uses of it that I can see at least in the kernel
code we could just as easily have the in-tree bootwrapper create the
__res data and always act like we're on U-Boot.
defconfigs: Since I don't know the board families well (and google was
no help here), should both IceCube and Glacier default to MPC5200 ?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MPC5xxx code issues

[Wolfgang Denk]

Dear Tom,

in message <20031117202944.GH30251@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> Must clean: These files need some sort of rewrite to look less like
> a drop of commerical code into the kernel and more like working the
> commercial code into the kernel:
> arch/ppc/5xxx_io/bestcomm/capi/Makefile
> arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/Makefile
> arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos2/Makefile
> arch/ppc/5xxx_io/bestcomm/include/dummy files (should these be needed?)

I recommend NOT to touch anything in  the  bestocmm  directory.  This
stuff  is  supplied  directly by Motorola, and it is more than likely
that new versions of this code will have to be dropped in soon.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Anything free is worth what you pay for it.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MPC5xxx code issues

[Tom Rini]

On Mon, Nov 17, 2003 at 09:43:15PM +0100, Wolfgang Denk wrote:
>
> in message <20031117202944.GH30251@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > Must clean: These files need some sort of rewrite to look less like
> > a drop of commerical code into the kernel and more like working the
> > commercial code into the kernel:
> > arch/ppc/5xxx_io/bestcomm/capi/Makefile
> > arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/Makefile
> > arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos2/Makefile
> > arch/ppc/5xxx_io/bestcomm/include/dummy files (should these be needed?)
>
> I recommend NOT to touch anything in the bestocmm directory. This
> stuff is supplied directly by Motorola, and it is more than likely
> that new versions of this code will have to be dropped in soon.

I'd like to point to the xilinx_ocp directory in linuxppc_2_4_devel.
While Xilinx is probably more concerned with the code being in the
Linux kernel than Motorola (but I could be wrong), the OS-independant
code is still always the same.
Since I wasn't explicit enough, I'm hoping we can rewrite the Makefiles
(which shouldn't be too hard to keep in sync as it should end up being
just changing the file lists) and that the dummy files can just be
removed and ignored.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MPC5xxx code issues

[Benjamin Herrenschmidt]

> drivers/ide/ppc/mpc5xxx_ide.c, etc (I'm not actually sure if Alan
> reviews drivers, or would given that he's spending less time on Linux
> right now)

Well, I wrote this one, so it should be fairly ok as long as it
was fixed since the last time I had a 5200 at hand, the driver
didn't work (the bestcomm tasks weren't doing their job properly)

But maybe the one you have there is PIO only ? In which case
it will just work.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MPC5xxx code issues

[Dale Farnsworth]

On Mon, Nov 17, 2003 at 08:29:44PM +0000, Tom Rini wrote:
> Must clean: These files need some sort of rewrite to look less like a
> drop of commerical code into the kernel and more like working the
> commercial code into the kernel:
> arch/ppc/5xxx_io/bestcomm/capi/Makefile
> arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/Makefile
> arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos2/Makefile
> arch/ppc/5xxx_io/bestcomm/include/dummy files (should these be needed?)

The code beneath the arch/ppc/5xxx_io/bestcomm directory is supplied
by Motorola.  To ease the adoption of later revisions of this code,
we made minimal modifications.  Stupidly, the bestcomm code references
stdio.h, stdlib.h, string.h, but doesn't use their contents, so we
added empty files with these names.

The Makefiles are also supplied by Motorola and are not used by Linux
at all.  We can safely omit them to reduce confusion.

> defconfigs: Since I don't know the board families well (and google was
> no help here), should both IceCube and Glacier default to MPC5200 ?

IMHO, yes.

-Dale Farnsworth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MPC5xxx code issues

[Tom Rini]

On Tue, Nov 18, 2003 at 08:04:06AM -0700, Dale Farnsworth wrote:
>
> On Mon, Nov 17, 2003 at 08:29:44PM +0000, Tom Rini wrote:
> > Must clean: These files need some sort of rewrite to look less like a
> > drop of commerical code into the kernel and more like working the
> > commercial code into the kernel:
> > arch/ppc/5xxx_io/bestcomm/capi/Makefile
> > arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/Makefile
> > arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos2/Makefile
> > arch/ppc/5xxx_io/bestcomm/include/dummy files (should these be needed?)
>
> The code beneath the arch/ppc/5xxx_io/bestcomm directory is supplied
> by Motorola.  To ease the adoption of later revisions of this code,
> we made minimal modifications.  Stupidly, the bestcomm code references
> stdio.h, stdlib.h, string.h, but doesn't use their contents, so we
> added empty files with these names.

.. but those files _should_ be OK anyhow, if I recall all of the include
magic correctly.

> The Makefiles are also supplied by Motorola and are not used by Linux
> at all.  We can safely omit them to reduce confusion.

Can you give me a list of all of the files we don't actually need?
Thanks.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MPC5xxx code issues

[Dale Farnsworth]

On Wed, Nov 19, 2003 at 03:58:34PM +0000, Tom Rini wrote:
> On Tue, Nov 18, 2003 at 08:04:06AM -0700, Dale Farnsworth wrote:
> >
> > On Mon, Nov 17, 2003 at 08:29:44PM +0000, Tom Rini wrote:
> > > Must clean: These files need some sort of rewrite to look less like a
> > > drop of commerical code into the kernel and more like working the
> > > commercial code into the kernel:
> > > arch/ppc/5xxx_io/bestcomm/capi/Makefile
> > > arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/Makefile
> > > arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos2/Makefile
> > > arch/ppc/5xxx_io/bestcomm/include/dummy files (should these be needed?)
> >
> > The code beneath the arch/ppc/5xxx_io/bestcomm directory is supplied
> > by Motorola.  To ease the adoption of later revisions of this code,
> > we made minimal modifications.  Stupidly, the bestcomm code references
> > stdio.h, stdlib.h, string.h, but doesn't use their contents, so we
> > added empty files with these names.
>
> .. but those files _should_ be OK anyhow, if I recall all of the include
> magic correctly.
>
> > The Makefiles are also supplied by Motorola and are not used by Linux
> > at all.  We can safely omit them to reduce confusion.
>
> Can you give me a list of all of the files we don't actually need?
> Thanks.

Well, here are the files under arch/ppc/5xxx_io/bestcomm that we do use:
Makefile
capi/bestcomm_api.c
capi/bestcomm_api.h
capi/load_task.c
capi/ppctypes.h
capi/task_api/bestcomm_api_mem.h
capi/task_api/bestcomm_cntrl.h
capi/task_api/tasksetup_bdtable.c
capi/task_api/tasksetup_bdtable.h
capi/task_api/tasksetup_general.c
capi/tasksetup.c
capi/tasksetup.h
code_dma/image_rtos1/dma_image.c
code_dma/image_rtos1/dma_image.capi.c
code_dma/image_rtos1/dma_image.capi.h
code_dma/image_rtos1/dma_image.h
code_dma/image_rtos1/dma_image.reloc.c
code_dma/image_rtos1/task_capi/tasksetup_ata.c
code_dma/image_rtos1/task_capi/tasksetup_crc16_dp_0.c
code_dma/image_rtos1/task_capi/tasksetup_crc16_dp_1.c
code_dma/image_rtos1/task_capi/tasksetup_fec_rx_bd.c
code_dma/image_rtos1/task_capi/tasksetup_fec_tx_bd.c
code_dma/image_rtos1/task_capi/tasksetup_gen_dp_0.c
code_dma/image_rtos1/task_capi/tasksetup_gen_dp_1.c
code_dma/image_rtos1/task_capi/tasksetup_gen_dp_2.c
code_dma/image_rtos1/task_capi/tasksetup_gen_dp_3.c
code_dma/image_rtos1/task_capi/tasksetup_gen_dp_bd_0.c
code_dma/image_rtos1/task_capi/tasksetup_gen_dp_bd_1.c
code_dma/image_rtos1/task_capi/tasksetup_gen_rx_bd.c
code_dma/image_rtos1/task_capi/tasksetup_gen_tx_bd.c
code_dma/image_rtos1/task_capi/tasksetup_lpc.c
code_dma/image_rtos1/task_capi/tasksetup_pci_rx.c
code_dma/image_rtos1/task_capi/tasksetup_pci_tx.c
include/mgt5200/mgt5200.h
include/mgt5200/sdma.h
include/stdio.h
include/stdlib.h
include/string.h

So, it looks like we can get rid of:
capi/Makefile
capi/taskinfo_initiators.c
code_dma/image_rtos1/Makefile
code_dma/image_rtos1/dma_image.hex
code_dma/image_rtos2/Makefile
code_dma/image_rtos2/dma_image.c
code_dma/image_rtos2/dma_image.capi.c
code_dma/image_rtos2/dma_image.capi.h
code_dma/image_rtos2/dma_image.h
code_dma/image_rtos2/dma_image.hex
code_dma/image_rtos2/dma_image.reloc.c
code_dma/image_rtos2/task_capi/tasksetup_ata.c
code_dma/image_rtos2/task_capi/tasksetup_crc16_dp.c
code_dma/image_rtos2/task_capi/tasksetup_crc16_dp_bd.c
code_dma/image_rtos2/task_capi/tasksetup_fec_rx_bd.c
code_dma/image_rtos2/task_capi/tasksetup_fec_tx_bd.c
code_dma/image_rtos2/task_capi/tasksetup_gen_dp_0.c
code_dma/image_rtos2/task_capi/tasksetup_gen_dp_1.c
code_dma/image_rtos2/task_capi/tasksetup_gen_dp_2.c
code_dma/image_rtos2/task_capi/tasksetup_gen_dp_3.c
code_dma/image_rtos2/task_capi/tasksetup_gen_rx_bd_0.c
code_dma/image_rtos2/task_capi/tasksetup_gen_rx_bd_1.c
code_dma/image_rtos2/task_capi/tasksetup_gen_tx_bd_0.c
code_dma/image_rtos2/task_capi/tasksetup_gen_tx_bd_1.c
code_dma/image_rtos2/task_capi/tasksetup_lpc.c
code_dma/image_rtos2/task_capi/tasksetup_pci_rx.c
code_dma/image_rtos2/task_capi/tasksetup_pci_tx.c
include/ppctypes.h

-Dale Farnsworth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/