Re: MPC5200 Patches

Re: MPC5200 Patches

[Wolfgang Denk]

[Repost - the original message did not make it to the  mailing  lists
because of the size of the attachment.]

Dear Tom,

in message <20031031155445.GA25446@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> > Will you accept these patches, and put the stuff  into  the  official
> > trees?
>
> What would be best is a patch against 2.4.23-pre9 (or semi-recent bk
> snapshot) posted to linuxppc-dev and/or linuxppc-embedded.

Please find attached below a  patch  against  2.4.23-pre9  (ChangeSet
1.1397, BK Key paulus@samba.org|ChangeSet|20031030220219|08345).

I've also uploaded the patch to
ftp://ftp.denx.de/pub/ppc/linux/bk_2_4_devel-1.1397-MPC5200.patch.gz

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
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Sat, Nov 01, 2003 at 09:36:28AM +0000, Wolfgang Denk wrote:
> Dear Tom,
>
> in message <20031031155445.GA25446@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > > Will you accept these patches, and put the stuff  into  the  official
> > > trees?
> >
> > What would be best is a patch against 2.4.23-pre9 (or semi-recent bk
> > snapshot) posted to linuxppc-dev and/or linuxppc-embedded.
>
> Please find attached below a  patch  against  2.4.23-pre9  (ChangeSet
> 1.1397, BK Key paulus@samba.org|ChangeSet|20031030220219|08345).
>
> I've also uploaded the patch to
> ftp://ftp.denx.de/pub/ppc/linux/bk_2_4_devel-1.1397-MPC5200.patch.gz
>
> Best regards,
>
> Wolfgang Denk

Thanks for motivating me to action, Wolfgang. :-)

The above patch is based on an early, unpublished version of my mpc5200
port.  While I was quite surprised to find it in Wolfgang's tree, I'm
confident that Wolfgang received it in good faith.

I did not publish the port because the ethernet support relies on a
Motorola-written DMA subsystem with a proprietary license that doesn't
permit redistribution.  A month ago, Motorola finally sent me an
updated, GPLed version of the DMA controller code.  I merged the new
version, but the DMA API has changed and I've been busy with other things
so ethernet isn't quite working again, yet.  I've made several changes
to the 5200 port as well.

I will post my updated code to this list this week and would prefer
to see it merged rather than my older code contained in the above patch.

Thanks,

-Dale Farnsworth

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

Re: MPC5200 Patches

[Wolfgang Denk]

Dear Dale,

sorry for replying so late, but I was out of office for some days.

In message <20031103233143.GA19177@zenos.farnsworth.org> you wrote:
>
> Thanks for motivating me to action, Wolfgang. :-)

;-)

> The above patch is based on an early, unpublished version of my mpc5200
> port.  While I was quite surprised to find it in Wolfgang's tree, I'm
> confident that Wolfgang received it in good faith.

The code is actually identical the the later version  where  Motorola
replaced  the  headers  with GPL preambles. I sent a tarball with the
GPL bestcomm code to Tom Rini.


> I did not publish the port because the ethernet support relies on a
> Motorola-written DMA subsystem with a proprietary license that doesn't
> permit redistribution.  A month ago, Motorola finally sent me an
> updated, GPLed version of the DMA controller code.  I merged the new
> version, but the DMA API has changed and I've been busy with other things

The main problem with the FEC code  is  that  it  does  NOT  use  the
offical  bestcomm  API but (for efficiency reasons?) meddles directly
with internal bestcomm data. This is why the code  breaks  with  each
new release of the bestcomm code.

> so ethernet isn't quite working again, yet.  I've made several changes
> to the 5200 port as well.
>
> I will post my updated code to this list this week and would prefer
> to see it merged rather than my older code contained in the above patch.

The code I submitted contains some things; some code was developed by
BenH, some by DENX. It would be sad if this stuff was  just  ignored.
How about merging our code and your new stuff?

For me the main issue is that  MPC5200  support  makes  it  into  the
official kernel trees as fast as possible.

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
I have often regretted my speech, never my silence.

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Fri, Nov 07, 2003 at 10:20:20PM +0000, Wolfgang Denk wrote:
> The code is actually identical the the later version where Motorola
> replaced the headers with GPL preambles. I sent a tarball with the GPL
> bestcomm code to Tom Rini.

I just thought that applying a patch that had "Motorola Confidential
Proprietary" all over it wasn't a good idea. :-)

> > I did not publish the port because the ethernet support relies on
> > a Motorola-written DMA subsystem with a proprietary license that
> > doesn't permit redistribution. A month ago, Motorola finally sent
> > me an updated, GPLed version of the DMA controller code. I merged
> > the new version, but the DMA API has changed and I've been busy with
> > other things
>
> The main problem with the FEC code is that it does NOT use the offical
> bestcomm API but (for efficiency reasons?) meddles directly with
> internal bestcomm data. This is why the code breaks with each new
> release of the bestcomm code.

I think you're referring to the way the fec code accesses the ring
buffers.  Motorola supports direct access to the ring buffer and this
is the only release of the bestcomm that broke that access.  Previous
breakages were due to other changes in bestcomm API.

> The code I submitted contains some things; some code was developed by
> BenH, some by DENX. It would be sad if this stuff was just ignored.
> How about merging our code and your new stuff?

I have merged your code, benh's and mine and placed it at
ftp://source.mvista.com/pub/linuxppc/mpc5200/linuxppc_2_4_devel.mpc5200.patch

This patch doesn't require uboot.  I retained the uboot code and added
CONFIG_UBOOT, but haven't tested with it.

I would appreciate it if you could take some time to test it with your
hardware.  I find that USB and PCI are not working here, but they also
fail with your patch, so it may be my icecube hardware.

I haven't tested this merged code on the MGT5100, and in fact, I removed
the MGT5100 FEC support because the #ifdefs in fec.c were just too ugly.
I'll insert a compatibility layer to support the MGT5100 FEC if there
is sufficient interest.  Is anyone still using the MGT5100?

> For me the main issue is that MPC5200 support makes it into the
> official kernel trees as fast as possible.

Agreed, with reasonable quality.

Thanks,
-Dale

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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <20031110190207.GA12163@zenos.farnsworth.org> you wrote:
>
> On Fri, Nov 07, 2003 at 10:20:20PM +0000, Wolfgang Denk wrote:
> > The code is actually identical the the later version where Motorola
> > replaced the headers with GPL preambles. I sent a tarball with the GPL
> > bestcomm code to Tom Rini.
>
> I just thought that applying a patch that had "Motorola Confidential
> Proprietary" all over it wasn't a good idea. :-)

You are absolutely right.

> I have merged your code, benh's and mine and placed it at
> ftp://source.mvista.com/pub/linuxppc/mpc5200/linuxppc_2_4_devel.mpc5200.patch
>
> This patch doesn't require uboot.  I retained the uboot code and added
> CONFIG_UBOOT, but haven't tested with it.

I'll look at it ASAP.

> I would appreciate it if you could take some time to test it with your
> hardware.  I find that USB and PCI are not working here, but they also
> fail with your patch, so it may be my icecube hardware.

They are  working  fine  here  (*)  on  three  boards  (2  x  labeled
"IceCube+", 1 x "LITE5200").

(*) - some PCI cards cause problems, for example a 3C905C  card;  I'm
pretty  sure  it  is  a  hardware  issue,  but so far it has not been
confirmed by Motorola yet;  for  USB,  you  may  have  to  short  L15
("below" the USB connector)

> I haven't tested this merged code on the MGT5100, and in fact, I removed
> the MGT5100 FEC support because the #ifdefs in fec.c were just too ugly.
> I'll insert a compatibility layer to support the MGT5100 FEC if there
> is sufficient interest.  Is anyone still using the MGT5100?

Yes, I know of some cases. But too many things are failing on MGT5100
hardware anyway.

> > For me the main issue is that MPC5200 support makes it into the
> > official kernel trees as fast as possible.
>
> Agreed, with reasonable quality.

It has been my impression that the  strategy  is  to  get  things  in
quickly, and to fix them later?

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
The software required `Windows 95 or better', so I installed Linux.

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

Re: MPC5200 Patches

[Tom Rini]

On Mon, Nov 10, 2003 at 09:46:47PM +0100, Wolfgang Denk wrote:
> In message <20031110190207.GA12163@zenos.farnsworth.org> you wrote:
> >
> > On Fri, Nov 07, 2003 at 10:20:20PM +0000, Wolfgang Denk wrote:
[snip]
> > > For me the main issue is that MPC5200 support makes it into the
> > > official kernel trees as fast as possible.
> >
> > Agreed, with reasonable quality.
>
> It has been my impression that the  strategy  is  to  get  things  in
> quickly, and to fix them later?

As 2.4.23-rc1 just came out, this will not make 2.4.23.  And I suspect
that Marcelo will have a settling out period of at least one week if
there's to be no -rc2 (and I suspect that there'll be at least 2
2.4.24-pre releases before he'd reject something like this).  So we have
a little bit of time to work things out into the best shape that can be
before we submit to Marcelo.

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

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

Re: MPC5200 Patches

[Wolfgang Denk]

Hi Dale & Tom,

in message <20031110190207.GA12163@zenos.farnsworth.org> Dale Farnsworth wrote:
>
> I have merged your code, benh's and mine and placed it at
> ftp://source.mvista.com/pub/linuxppc/mpc5200/linuxppc_2_4_devel.mpc5200.patch
>
> This patch doesn't require uboot.  I retained the uboot code and added
> CONFIG_UBOOT, but haven't tested with it.

I've been browsing the code a bit for now.  No  actual  testing  doen
yet. Please see questions below.


> I would appreciate it if you could take some time to test it with your
> hardware.  I find that USB and PCI are not working here, but they also
> fail with your patch, so it may be my icecube hardware.

It seems you have an older board? [8 MB flash?] Both USB and PCI have
been tested here with a cuple of devices. They were working  fine  in
most cases.


> I haven't tested this merged code on the MGT5100, and in fact, I removed
> the MGT5100 FEC support because the #ifdefs in fec.c were just too ugly.

Ummm... but they were working. I understand that you want to clean up
the code, but IMHO we  should  not  simply  drop  support  for  older
hardware  if  it was working before. Some people still have (or want)
to use the old boards.

> I'll insert a compatibility layer to support the MGT5100 FEC if there
> is sufficient interest.  Is anyone still using the MGT5100?

Yes, we. Some of our customers. Some of Motorola's customers.


Here a few general questions / remarks:

* Did you actually test the code on a IceCube with MGT5100?

* Some files/directories have been renamed into 5xxx, others in
  m5xxx. The same applies to the CONFIG_ options: Maybe we can make
  this a bit more consistent?

  Given the fact that we use CONFIG_6xx, CONFIG_40x, CONFIG_44x,
  CONFIG_8xx, ... we should probably use CONFIG_5xxx instead of
  CONFIG_M5XXX ?

  We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
  i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?

  There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
  instead of i2c-algo-m5xxx.h ?

  We have include/asm-ppc/mpc8xx.h and mpc8260.h and ibm4xx.h - maybe
  we should use mpc5xxx.h instead of m5xxx.h ?

* Does it make sense to add a "Board uses UBoot" config option to
  individual boards? [BTW: the name is "U-Boot".] If we do something
  like this (which I'd appreciate) we should do it right - there
  might be some other boards that use this, too.

* In "arch/ppc/config.in" you write:
	...
	hex 'Flash Rom Size' CONFIG_M5XXX_FLASH_SIZE 0x800000

  I recommend to make this 0x1000000 instead - you will probably  not
  see new boards with 8 MB flash any more.

* I think you should not overwrite arch/ppc/defconfig


Will try to run your code ASAP.

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
I know engineers. They love to change things.             - Dr. McCoy

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Wed, Nov 12, 2003 at 12:34:57AM +0000, Wolfgang Denk wrote:
> Hi Dale & Tom,
> It seems you have an older board? [8 MB flash?] Both USB and PCI have
> been tested here with a cuple of devices. They were working  fine  in
> most cases.

I do have an older board.  Hmm.  I found nowhere in your patch where
the outbound PCI window registers were initialized.  Maybe that's
taken care of by U-Boot.  If so, I'd like to remove the dependency.
I could be missing something obvious, though.  I got farther after
initializing the window regs, but still couldn't read the 5200's
PCI config space registers.

> > I haven't tested this merged code on the MGT5100, and in fact, I removed
> > the MGT5100 FEC support because the #ifdefs in fec.c were just too ugly.
>
> Ummm... but they were working. I understand that you want to clean up
> the code, but IMHO we  should  not  simply  drop  support  for  older
> hardware  if  it was working before. Some people still have (or want)
> to use the old boards.

That code is too ugly to keep around.  It was a hack that I never
intended to publish.  I'm still angry that it was passed along to
you before I had a chance to clean it up.

> > I'll insert a compatibility layer to support the MGT5100 FEC if there
> > is sufficient interest.  Is anyone still using the MGT5100?
>
> Yes, we. Some of our customers. Some of Motorola's customers.

Ok.  I'll try to get to it next week.

> Here a few general questions / remarks:
>
> * Did you actually test the code on a IceCube with MGT5100?

Kent Borg tested on a 5100-based IceCube.  I haven't seen one.
I do have a 5100-based Glacier.

> * Some files/directories have been renamed into 5xxx, others in
>   m5xxx. The same applies to the CONFIG_ options: Maybe we can make
>   this a bit more consistent?
>
>   Given the fact that we use CONFIG_6xx, CONFIG_40x, CONFIG_44x,
>   CONFIG_8xx, ... we should probably use CONFIG_5xxx instead of
>   CONFIG_M5XXX ?
>
>   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
>   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
>
>   There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
>   instead of i2c-algo-m5xxx.h ?

Sounds good to me.

>   We have include/asm-ppc/mpc8xx.h and mpc8260.h and ibm4xx.h - maybe
>   we should use mpc5xxx.h instead of m5xxx.h ?

I chose m5xxx to include both mgt5xxx an mpc5xxx, but I don't feel
strongly about this.

> * Does it make sense to add a "Board uses UBoot" config option to
>   individual boards? [BTW: the name is "U-Boot".] If we do something
>   like this (which I'd appreciate) we should do it right - there
>   might be some other boards that use this, too.

Go for it.

> * In "arch/ppc/config.in" you write:
> 	...
> 	hex 'Flash Rom Size' CONFIG_M5XXX_FLASH_SIZE 0x800000
>
>   I recommend to make this 0x1000000 instead - you will probably  not
>   see new boards with 8 MB flash any more.

Thanks.

> * I think you should not overwrite arch/ppc/defconfig

Doh!  I noted that you included defconfig in your patch and I made
a mental note not to make the same mistake.  Oh well.  :-)

> Will try to run your code ASAP.

Thanks for the help, Wolfgang.

-Dale Farnsworth

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

Re: MPC5200 Patches

[Geert Uytterhoeven]

On Wed, 12 Nov 2003, Wolfgang Denk wrote:
> * Some files/directories have been renamed into 5xxx, others in
>   m5xxx. The same applies to the CONFIG_ options: Maybe we can make
>   this a bit more consistent?
>
>   Given the fact that we use CONFIG_6xx, CONFIG_40x, CONFIG_44x,
>   CONFIG_8xx, ... we should probably use CONFIG_5xxx instead of
>   CONFIG_M5XXX ?
>
>   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
>   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
>
>   There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
>   instead of i2c-algo-m5xxx.h ?
>
>   We have include/asm-ppc/mpc8xx.h and mpc8260.h and ibm4xx.h - maybe
>   we should use mpc5xxx.h instead of m5xxx.h ?

What's done in include/asm-ppc/ isn't that important for the outside (non-PPC)
world, but i2c-algo-5xxx.c may be a too generic name...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <Pine.GSO.4.21.0311121029220.885-100000@waterleaf.sonytel.be> you wrote:
>
> >   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
> >   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
> >
> >   There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
> >   instead of i2c-algo-m5xxx.h ?
...
> What's done in include/asm-ppc/ isn't that important for the outside (non-PPC)
> world, but i2c-algo-5xxx.c may be a too generic name...

Which name do you recommend to cover the MGT5100 and MPC5200 (and
probably other MPC5xxx) processors?

[There is already i2c-algo-8xx.[ch]...]


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
Perl already has an IDE.  It's called Unix.
                      -- Tom Christiansen in 375bd509@cs.colorado.edu

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

Re: MPC5200 Patches

[Geert Uytterhoeven]

On Wed, 12 Nov 2003, Wolfgang Denk wrote:
> In message <Pine.GSO.4.21.0311121029220.885-100000@waterleaf.sonytel.be> you wrote:
> >
> > >   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
> > >   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
> > >
> > >   There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
> > >   instead of i2c-algo-m5xxx.h ?
> ...
> > What's done in include/asm-ppc/ isn't that important for the outside (non-PPC)
> > world, but i2c-algo-5xxx.c may be a too generic name...
>
> Which name do you recommend to cover the MGT5100 and MPC5200 (and
> probably other MPC5xxx) processors?

i2c-algo-m5xxx.c, like the original?

> [There is already i2c-algo-8xx.[ch]...]

I know. And it may be too generic, too...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: MPC5200 Patches

[Gabriel Paubert]

On Wed, Nov 12, 2003 at 10:59:59AM +0100, Geert Uytterhoeven wrote:
>
> On Wed, 12 Nov 2003, Wolfgang Denk wrote:
> > In message <Pine.GSO.4.21.0311121029220.885-100000@waterleaf.sonytel.be> you wrote:
> > >
> > > >   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
> > > >   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
> > > >
> > > >   There is include/linux/i2c-algo-8xx.h - how about
> > > >   i2c-algo-5xxx.h instead of i2c-algo-m5xxx.h ?
> > ...
> > > What's done in include/asm-ppc/ isn't that important for the
> > > outside (non-PPC) world, but i2c-algo-5xxx.c may be a too generic
> > > name...
> >
> > Which name do you recommend to cover the MGT5100 and MPC5200 (and
> > probably other MPC5xxx) processors?
>
> i2c-algo-m5xxx.c, like the original?

Hmmm, dont't repeated x have a tendency to trigger spam filters
(especially the dumbest ones)?

Why not 5nnn or 5xyz?

	Gabriel

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

Re: MPC5200 Patches

[Geert Uytterhoeven]

On Wed, 12 Nov 2003, Gabriel Paubert wrote:
> On Wed, Nov 12, 2003 at 10:59:59AM +0100, Geert Uytterhoeven wrote:
> > On Wed, 12 Nov 2003, Wolfgang Denk wrote:
> > > In message <Pine.GSO.4.21.0311121029220.885-100000@waterleaf.sonytel.be> you wrote:
> > > >
> > > > >   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
> > > > >   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
> > > > >
> > > > >   There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
> > > > >   instead of i2c-algo-m5xxx.h ?
> > > ...
> > > > What's done in include/asm-ppc/ isn't that important for the
> > > > outside (non-PPC) world, but i2c-algo-5xxx.c may be a too
> > > > generic name...
> > >
> > > Which name do you recommend to cover the MGT5100 and MPC5200 (and
> > > probably other MPC5xxx) processors?
> >
> > i2c-algo-m5xxx.c, like the original?
>
> Hmmm, dont't repeated x have a tendency to trigger spam filters
> (especially the dumbest ones)?
>
> Why not 5nnn or 5xyz?

i2c-algo-m5x00.c? (or i2c-algo-m5<censored>.c :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <Pine.GSO.4.21.0311121250470.885-100000@waterleaf.sonytel.be> you wrote:
>
> > Why not 5nnn or 5xyz?
>
> i2c-algo-m5x00.c? (or i2c-algo-m5<censored>.c :-)

Do you guarantee that we will not see a MPC5210 soon?

And i2c-algo-m5<censored>.c just gives "censored: No such file or
directory" to the average luser ;-)

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
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein

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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <20031112114114.GA8526@iram.es> you wrote:
>
> > i2c-algo-m5xxx.c, like the original?
>
> Hmmm, dont't repeated x have a tendency to trigger spam filters
> (especially the dumbest ones)?

Who cares? This is Linux kernel source code.

> Why not 5nnn or 5xyz?

To have at least a minimal level of consistency?

Remember: we already have 8xx, 82xx, 4xx etc.

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
The more sins you confess, the more books you will sell.

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

Re: MPC5200 Patches

[Gabriel Paubert]

On Wed, Nov 12, 2003 at 03:45:14PM +0100, Wolfgang Denk wrote:
> In message <20031112114114.GA8526@iram.es> you wrote:
> >
> > > i2c-algo-m5xxx.c, like the original?
> >
> > Hmmm, dont't repeated x have a tendency to trigger spam filters
> > (especially the dumbest ones)?
>
> Who cares? This is Linux kernel source code.

I don't remeber the details, but I believe that some
people had problems when posting about the aic7xxx
driver some time ago. And yes, this was on the
linux kernel mailing list IIRC.

	Gabriel

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

Re: MPC5200 Patches

[Geert Uytterhoeven]

On Wed, 12 Nov 2003, Gabriel Paubert wrote:
> On Wed, Nov 12, 2003 at 03:45:14PM +0100, Wolfgang Denk wrote:
> > In message <20031112114114.GA8526@iram.es> you wrote:
> > > > i2c-algo-m5xxx.c, like the original?
> > >
> > > Hmmm, dont't repeated x have a tendency to trigger spam filters
> > > (especially the dumbest ones)?
> >
> > Who cares? This is Linux kernel source code.
>
> I don't remeber the details, but I believe that some people had
> problems when posting about the aic7xxx driver some time ago. And yes,
> this was on the linux kernel mailing list IIRC.

Yep. But IIRC the problem was not posting, but receiving. Apparently some
people subscribed to lkml are behind corporate spam filters that remove
everything that contains `xxx'. So people started to talk about the
aic7<censored> driver to fool the spam filters.

BTW, there are similar problems with accessing the Video4Linux website, hosted
at bytesex.org.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Re: MPC5200 Patches

[Kumar Gala]

What about a single i2c-mpc.c that handles 10x/824x/85xx/5xxx since
they all seem to support the same programming model from what I can
tell (5xxx seems not to support broadcast).  This would cover all
non-CPM instances of I2C on Motorola PPC parts.

- kumar

On Nov 12, 2003, at 1:41 PM, Geert Uytterhoeven wrote:
>
> On Wed, 12 Nov 2003, Gabriel Paubert wrote:
>> On Wed, Nov 12, 2003 at 03:45:14PM +0100, Wolfgang Denk wrote:
>>> In message <20031112114114.GA8526@iram.es> you wrote:
>>>>> i2c-algo-m5xxx.c, like the original?
>>>>
>>>> Hmmm, dont't repeated x have a tendency to trigger spam filters
>>>> (especially the dumbest ones)?
>>>
>>> Who cares? This is Linux kernel source code.
>>
>> I don't remeber the details, but I believe that some people had
>> problems when posting about the aic7xxx driver some time ago. And
>> yes, this was on the linux kernel mailing list IIRC.
>
> Yep. But IIRC the problem was not posting, but receiving. Apparently
> some people subscribed to lkml are behind corporate spam filters that
> remove everything that contains `xxx'. So people started to talk about
> the aic7<censored> driver to fool the spam filters.
>
> BTW, there are similar problems with accessing the Video4Linux
> website, hosted at bytesex.org.

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

Re: MPC5200 Patches

[Tom Rini]

On Fri, Nov 14, 2003 at 12:11:06AM -0600, Kumar Gala wrote:

> What about a single i2c-mpc.c that handles 10x/824x/85xx/5xxx since
> they all seem to support the same programming model from what I can
> tell (5xxx seems not to support broadcast).  This would cover all
> non-CPM instances of I2C on Motorola PPC parts.

So long as it can be done in a clean manner, this is probably a great
idea.  Thanks for volunteering. :)

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

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

Re: MPC5200 Patches

[Tom Rini]

On Wed, Nov 12, 2003 at 01:34:57AM +0100, Wolfgang Denk wrote:

[snip]
> * Some files/directories have been renamed into 5xxx, others in
>   m5xxx. The same applies to the CONFIG_ options: Maybe we can make
>   this a bit more consistent?
>
>   Given the fact that we use CONFIG_6xx, CONFIG_40x, CONFIG_44x,
>   CONFIG_8xx, ... we should probably use CONFIG_5xxx instead of
>   CONFIG_M5XXX ?

Can I suggest breaking the trend slightly based on comments people have
made about 2.5/2.6?  Let's call it CONFIG_PPC_5xxx (and someday fix all
of the others).

>   We have drivers/i2c/i2c-algo-8xx.c, so maybe we should have
>   i2c-algo-5xxx.c instead of i2c-algo-m5xxx.c ?
>
>   There is include/linux/i2c-algo-8xx.h - how about i2c-algo-5xxx.h
>   instead of i2c-algo-m5xxx.h ?

As others have mentioned, this is too generic, and should someone have
time, 8xx should be renamed m8xx.

>   We have include/asm-ppc/mpc8xx.h and mpc8260.h and ibm4xx.h - maybe
>   we should use mpc5xxx.h instead of m5xxx.h ?

Sounds like a good idea.

> * Does it make sense to add a "Board uses UBoot" config option to
>   individual boards? [BTW: the name is "U-Boot".] If we do something
>   like this (which I'd appreciate) we should do it right - there
>   might be some other boards that use this, too.

My question is, is it possible to support both U-Boot and $(VENDOR
FIRMWARE) in the same build?  If possible I'd like to avoid adding a
question for any type of firmware or a define_bool based on board
selection.  I think we allow for this on Sandpoints, so...

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

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

Re: MPC5200 Patches

[Gary Thomas]

On Wed, 2003-11-12 at 08:18, Tom Rini wrote:
> On Wed, Nov 12, 2003 at 01:34:57AM +0100, Wolfgang Denk wrote:
>
> [snip]*
>
> > * Does it make sense to add a "Board uses UBoot" config option to
> >   individual boards? [BTW: the name is "U-Boot".] If we do something
> >   like this (which I'd appreciate) we should do it right - there
> >   might be some other boards that use this, too.
>
> My question is, is it possible to support both U-Boot and $(VENDOR
> FIRMWARE) in the same build?  If possible I'd like to avoid adding a
> question for any type of firmware or a define_bool based on board
> selection.  I think we allow for this on Sandpoints, so

Actually, I don't think it's possible to handle this in a general way.
In  particular, I'd also like to see a "Uses RedBoot" option, as the
booting process there is different from U-Boot, PPCBug, OF, ...  Sadly,
there is no real common ground and this truly is a target [board]
setting.

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: MPC5200 Patches

[Tom Rini]

On Wed, Nov 12, 2003 at 08:49:30AM -0700, Gary Thomas wrote:
> On Wed, 2003-11-12 at 08:18, Tom Rini wrote:
> > On Wed, Nov 12, 2003 at 01:34:57AM +0100, Wolfgang Denk wrote:
> >
> > [snip]*
> >
> > > * Does it make sense to add a "Board uses UBoot" config option to
> > >   individual boards? [BTW: the name is "U-Boot".] If we do something
> > >   like this (which I'd appreciate) we should do it right - there
> > >   might be some other boards that use this, too.
> >
> > My question is, is it possible to support both U-Boot and $(VENDOR
> > FIRMWARE) in the same build?  If possible I'd like to avoid adding a
> > question for any type of firmware or a define_bool based on board
> > selection.  I think we allow for this on Sandpoints, so
>
> Actually, I don't think it's possible to handle this in a general way.
> In  particular, I'd also like to see a "Uses RedBoot" option, as the
> booting process there is different from U-Boot, PPCBug, OF, ...  Sadly,
> there is no real common ground and this truly is a target [board]
> setting.

>From what I recall of how this worked for U-Boot vs in-kernel wrapper
was that the only thing the kernel cared about was how a data structure
was passed in, so we just checked to see if it was one or the other and
used whatever we had.

#include
<previous_too_long_never_implemented_sadly_bi_rec_thread_and_move_on>

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

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

Re: MPC5200 Patches

[Wolfgang Denk]

Dear Tom & Dale,

in message <20031112151824.GC31581@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> Can I suggest breaking the trend slightly based on comments people have
> made about 2.5/2.6?  Let's call it CONFIG_PPC_5xxx (and someday fix all
> of the others).

OK, so the discussion has stopped. What's happening now? I  sent  our
stuff.  Dale  has  added some modification. We have more works in the
queue. I think it makes little sense to  continue  without  a  common
code base.

Can you give any estimates when something will go into a public tree,
and what this will be, and which tree?

If there is any reason for you not to use the  "common"  trees  (like
linuxppc_2_4_devel  ?)  yet,  maybe  we  can at least put the current
state into a more dedicated tree like
bk://source.mvista.com/linuxppc_2_4_mgt5100

So that we can at least avoid to duplicate efforts while the work  is
going on?

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
panic: kernel trap (ignored)

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Sun, Nov 16, 2003 at 08:33:13PM +0000, Wolfgang Denk wrote:
> Dear Tom & Dale,
>
> OK, so the discussion has stopped. What's happening now? I  sent  our
> stuff.  Dale  has  added some modification. We have more works in the
> queue. I think it makes little sense to  continue  without  a  common
> code base.
>
> Can you give any estimates when something will go into a public tree,
> and what this will be, and which tree?
>
> If there is any reason for you not to use the  "common"  trees  (like
> linuxppc_2_4_devel  ?)  yet,  maybe  we  can at least put the current
> state into a more dedicated tree like
> bk://source.mvista.com/linuxppc_2_4_mgt5100
>
> So that we can at least avoid to duplicate efforts while the work  is
> going on?

Hi Wolfgang,

Have you had a chance to test my merged patch?  Any bug fixes?  I don't
think it's quite ready for linuxppc_2_4_devel, though it's close.

Per your suggestion above, I created
bk://source.mvista.com/linuxppc_2_4_mpc5200

It incorporates my merged patch with the following changes from the
discussion in this thread:
	o s/CONFIG_5XXX/CONFIG_PPC_5xxx/
	o s/i2c-algo-m5xxx.c/i2c-algo-ppc_5xxx.c/
	o s/UBoot/U-Boot/
	o s/M?5[xX][xX][xX]/MPC5xxx/
	o s/m?5[xX][xX][xX]/mpc5xxx/
	o changed default CONFIG_MPC5xxx_FLASH_SIZE to 0x1000000

I think the name changes are a definite improvement.  Thanks to all
for the input.

Please try this new tree and submit patches against it.

Thank you,
-Dale Farnsworth

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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <20031117060701.GA26252@zenos.farnsworth.org> you wrote:
>
> Per your suggestion above, I created
> bk://source.mvista.com/linuxppc_2_4_mpc5200

Which source tree / change set is this based on?

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
"The question of whether a computer can think is no more  interesting
than the question of whether a submarine can swim"
                                                - Edsgar W.  Dijkstra

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

Re: MPC5200 Patches

[Tom Rini]

On Mon, Nov 17, 2003 at 09:35:32AM +0100, Wolfgang Denk wrote:
>
> In message <20031117060701.GA26252@zenos.farnsworth.org> you wrote:
> >
> > Per your suggestion above, I created
> > bk://source.mvista.com/linuxppc_2_4_mpc5200
>
> Which source tree / change set is this based on?

It's semi-moot.  I've created a linux-2.4-mgt5100 tree, based off of
Marcelo's tree to carefully check things into, and hopefully get him to
pull from in 2.4.24-pre time-frame.  I'll email everyone again once I've
got it populated with stuff from Dale's tree.

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

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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <20031117151948.GB30251@ip68-0-152-218.tc.ph.cox.net> you wrote:
>
> > > Per your suggestion above, I created
> > > bk://source.mvista.com/linuxppc_2_4_mpc5200
> >
> > Which source tree / change set is this based on?
>
> It's semi-moot.  I've created a linux-2.4-mgt5100 tree, based off of

Can you please translate this into English for me?

My question was: is bk://source.mvista.com/linuxppc_2_4_mpc5200  base
on linuxppc_2_4 or linuxppc_2_4_devel, and which exact ChangeSet.

Why do you create a new tree ...-mgt5100 ? The MGT5100 can safely  be
considered  dead  (except that ther eare some systems out there which
remain being supported),.

> Marcelo's tree to carefully check things into, and hopefully get him to
> pull from in 2.4.24-pre time-frame.  I'll email everyone again once I've
> got it populated with stuff from Dale's tree.


Can you please explain the rationale behind  creating  a  new  source
tree?  There  is  the old bk://source.mvista.com/linuxppc_2_4_mgt5100
tree, there is now Dave's new  linuxppc_2_4_mpc5200  tree.  There  is
linux-2.4, linux-2.5, linuxppc_2_4_devel, linuxppc-2.4, linuxppc-2.5.
There  is  a  couple  other, less official source trees (like Ben's).
There is our CVS tree.

And instead of reducing the confusion about all the different  kernel
source trees you created yet another one?? Why?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It's like deja vu all over again."                      - Yogi Berra

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

Re: MPC5200 Patches

[Tom Rini]

On Mon, Nov 17, 2003 at 05:02:45PM +0100, Wolfgang Denk wrote:
>
> In message <20031117151948.GB30251@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > > > Per your suggestion above, I created
> > > > bk://source.mvista.com/linuxppc_2_4_mpc5200
> > >
> > > Which source tree / change set is this based on?
> >
> > It's semi-moot.  I've created a linux-2.4-mgt5100 tree, based off of
>
> Can you please translate this into English for me?
>
> My question was: is bk://source.mvista.com/linuxppc_2_4_mpc5200  base
> on linuxppc_2_4 or linuxppc_2_4_devel, and which exact ChangeSet.

Dale's is based off of linuxppc_2_4_devel as of 1.3998 I believe.

> Why do you create a new tree ...-mgt5100 ? The MGT5100 can safely  be
> considered  dead  (except that ther eare some systems out there which
> remain being supported),.

It's just a name, and I've renamed it to -mpc5xxx (and changed all refs
ot MGT5100/MGT5200 to MPC5xxx or MPC5100 or MPC5200 (in talking with
Dale 'MGT' seems to be going away as naming, so..).

> > Marcelo's tree to carefully check things into, and hopefully get him to
> > pull from in 2.4.24-pre time-frame.  I'll email everyone again once I've
> > got it populated with stuff from Dale's tree.
>
> Can you please explain the rationale behind  creating  a  new  source
> tree?  There  is  the old bk://source.mvista.com/linuxppc_2_4_mgt5100
> tree, there is now Dave's new  linuxppc_2_4_mpc5200  tree.  There  is
> linux-2.4, linux-2.5, linuxppc_2_4_devel, linuxppc-2.4, linuxppc-2.5.
> There  is  a  couple  other, less official source trees (like Ben's).
> There is our CVS tree.

This is a tree that we can check the initial MPC5xxx work into for 2.4,
make sure that it works and get Marcelo to take it.  Then it can die.
And the older (linuxppc_2_4_mgt5100) can be archived and die.  And the
new (linuxppc_2_4_mpc5200) tree should die now since it's only got
Dale's one patch in it, that I'm moving over.

> And instead of reducing the confusion about all the different  kernel
> source trees you created yet another one?? Why?

Because none of the others can be pulled directly into Marcelo's tree.
IFF we do this right the first time, more or less, in the end I can just
ask Marcelo to give bk://ppc.bkbits.net/linux-2.4-mpc5xxx a pull and
we'll all be happy.

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

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Mon, Nov 17, 2003 at 04:25:30PM +0000, Tom Rini wrote:
> It's just a name, and I've renamed it to -mpc5xxx (and changed all refs
> ot MGT5100/MGT5200 to MPC5xxx or MPC5100 or MPC5200 (in talking with
> Dale 'MGT' seems to be going away as naming, so..).

As near as I can tell, the MGT5100 chip has been replaced by the
MPC5200.  Since the MGT5100 is essentially dead, there is no need to
rename it to MPC5100.  I think the MPC5200 came on the scene before
the MGT5100 was used in any products (beyond Motorola's demo/eval
platforms).  If anyone is aware of any products using the MGT5100,
please speak up.  The MGT5100 doesn't merit our long-term support.

-Dale Farnsworth

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

Re: MPC5200 Patches

[Christoph Hellwig]

On Mon, Nov 17, 2003 at 09:25:30AM -0700, Tom Rini wrote:
> This is a tree that we can check the initial MPC5xxx work into for 2.4,
> make sure that it works and get Marcelo to take it.  Then it can die.
> And the older (linuxppc_2_4_mgt5100) can be archived and die.  And the
> new (linuxppc_2_4_mpc5200) tree should die now since it's only got
> Dale's one patch in it, that I'm moving over.

Umm, the code needs a rewrite before it's suitable for mainline.  In
it's current state is just bogus utter crap.  The bestcomm API needs
to go away and the dma engine used directly.


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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <20031120115315.GA7411@lst.de> you wrote:
>
> Umm, the code needs a rewrite before it's suitable for mainline.  In

Are you volunteering? ;-)

> it's current state is just bogus utter crap.  The bestcomm API needs
> to go away and the dma engine used directly.

It would be nice if you explained your reasons for such a statement.


I agree that there is better and more efficient code than the current
bescomm API. On the other hand, we have  already  seen  what  happens
when  you  do not use the official API and try to implement your own,
more efficient access routines. It's a maintenance nightmare.

Remember that this is _microcode_  which  is  not  finished  at  all.
Especially  in the near future changes and new versions from Motorola
are more than likely. Using the official Motorola  API  may  be  less
efficient  than what you can get with a different implementation, but
at least it will keep the existing code running.

If you bypass the official API, each new microcode version will break
your code. Been there before. This ain't fun.

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
Parkinson's Law:  Work expands to fill the time alloted it.

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

Re: MPC5200 Patches

[Christoph Hellwig]

On Thu, Nov 20, 2003 at 01:10:32PM +0100, Wolfgang Denk wrote:
> In message <20031120115315.GA7411@lst.de> you wrote:
> >
> > Umm, the code needs a rewrite before it's suitable for mainline.  In
>
> Are you volunteering? ;-)

Sure, feel free to contract me for that.

> > it's current state is just bogus utter crap.  The bestcomm API needs
> > to go away and the dma engine used directly.
>
> It would be nice if you explained your reasons for such a statement.

Because Linux is about doing things right, not fast?  Look at the bogus
taks abstractions - you just call into some deep multiplexer calls to
load pregenerated and (accoring to benh who worked with the even more
buggy predessecor) often bogus.  It looks like MOT once again produced
a really crappy chip and now hides the interface behind a huge bloated
API.  That might be find for them to sell the POS to someone wearing
Suits, but it's not really enough to get it included into the kernel
tree.


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

Re: MPC5200 Patches

[Paul Mackerras]

Wolfgang Denk writes:

> I agree that there is better and more efficient code than the current
> bescomm API. On the other hand, we have  already  seen  what  happens
> when  you  do not use the official API and try to implement your own,
> more efficient access routines. It's a maintenance nightmare.

I just took a look at the patch, and it is really horrible.  I can't
send stuff like that to Linus.  It is bloated, verbose, repetitive and
badly formatted.  It really doesn't inspire confidence to see comments
like "Generated by GUI" or to see 16 variations of a large structure
with just slightly different fields at the end.

I also don't like having a config option to select whether to use one
internal kernel API or another.  How am I supposed to know which one
to select?

Also, Ben tells me that the IDE driver doesn't even work, and the
interrupt controller code has major bugs.

Regards,
Paul.

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

Re: MPC5200 Patches

[Benjamin Herrenschmidt]

I only ever got DMA reads to work, DMA writes never kicked the
BestComm task..

Ben.


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

Re: MPC5200 Patches

[Benjamin Herrenschmidt]

On Tue, 2003-11-18 at 11:43, Benjamin Herrenschmidt wrote:
> I only ever got DMA reads to work, DMA writes never kicked the
> BestComm task..

Argh... I hate that evolution bug that when you remove the
signature,  it deletes 2 random lines of text...

So I was asking if you had the IDE DMA working correctly since
I see that you have my code in there.

Ben.


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

Re: MPC5200 Patches

[Wolfgang Denk]

Dear Ben,

in message <1069116274.7174.54.camel@gaston> you wrote:
>
> On Tue, 2003-11-18 at 11:43, Benjamin Herrenschmidt wrote:
> > I only ever got DMA reads to work, DMA writes never kicked the
> > BestComm task..
>
> Argh... I hate that evolution bug that when you remove the
> signature,  it deletes 2 random lines of text...
>
> So I was asking if you had the IDE DMA working correctly since
> I see that you have my code in there.

This is still your unmodified code. We're working  with  Motorola  on
this  issue,  but  it  was assigned lower priority because of other,
more pressing issues.

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
Swap read error.  You lose your mind.

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

Re: MPC5200 Patches

[Wolfgang Denk]

In message <20031117060701.GA26252@zenos.farnsworth.org> you wrote:
>
> Have you had a chance to test my merged patch?  Any bug fixes?  I don't
> think it's quite ready for linuxppc_2_4_devel, though it's close.

Actually I'm more or less waiting if you have a new  version  of  the
FEC driver that works on the MGT5100 again.

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
Presidency:  The greased pig in the field game of American politics.
- Ambrose Bierce

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

Re: MPC5200 Patches

[Tom Rini]

On Sun, Nov 16, 2003 at 09:33:13PM +0100, Wolfgang Denk wrote:

>
> Dear Tom & Dale,
>
> in message <20031112151824.GC31581@ip68-0-152-218.tc.ph.cox.net> you wrote:
> >
> > Can I suggest breaking the trend slightly based on comments people have
> > made about 2.5/2.6?  Let's call it CONFIG_PPC_5xxx (and someday fix all
> > of the others).
>
> OK, so the discussion has stopped. What's happening now? I  sent  our
> stuff.  Dale  has  added some modification. We have more works in the
> queue. I think it makes little sense to  continue  without  a  common
> code base.

Okay.  I've populated the following tree with what Dale had.  Since
there's a number of things which need to be cleaned up / tweaked (fear
not, I will follow up with my questions and conerns), I recommend that
you get this tree by doing the following:
1) Start with a clean copy of 'linux-2.4'.  You can get this from
bk://linux.bkbits.net/linux-2.4.
2) Copy linux-2.4 to linux-2.4-mpc5xxx (or whatever) and then do:
2a) cd linux-2.4-mpc5xxx
2b) bk parent bk://ppc.bkbits.net/linux-2.4-mpc5xxx
2c) bk pull -q

What I plan on doing, and I'll let people know when this happens is to
nuke this tree and start over, once things get fixed, so we can check
this in, in an incremental manner and split out things that need to be
run past lkml first for sanity's sake (such as exporting 2 more
functions from drivers/ide/ide.c.  It should be quickly accepted, but
nonetheless).  So what this means is DO NOT TRACK OR IMPORT THIS TREE
INTO SOMETHING ELSE.  THIS TREE EXISTS ONLY SO THAT WE CAN GET THE CODE
INTO SHAPE FOR MARCELO AND CHECK IT IN AS SUCH AND THEN DELETE THIS
PARTICULAR TREE.

For fixing things either in this tree or adding new features, or
whatever, a plain old GNU-style patch is probably best for now.

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

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Mon, Nov 17, 2003 at 06:50:18PM +0000, Tom Rini wrote:
> Okay.  I've populated the following tree with what Dale had.  Since
> there's a number of things which need to be cleaned up / tweaked (fear
> not, I will follow up with my questions and conerns), I recommend that
> you get this tree by doing the following:
> 1) Start with a clean copy of 'linux-2.4'.  You can get this from
> bk://linux.bkbits.net/linux-2.4.
> 2) Copy linux-2.4 to linux-2.4-mpc5xxx (or whatever) and then do:
> 2a) cd linux-2.4-mpc5xxx
> 2b) bk parent bk://ppc.bkbits.net/linux-2.4-mpc5xxx
> 2c) bk pull -q

Thanks Tom.  I finally got some time to try this out.  Here's a patch
with what I needed to change to get it to boot on my icecube.

-Dale

===== arch/ppc/5xxx_io/bestcomm/Makefile 1.1 vs edited =====
10c10
< EXTRA_CFLAGS = -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/include -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/capi -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/capi/task_api -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/code_dma/image_rtos1
---
> EXTRA_CFLAGS = -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/include -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/capi -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/capi/task_api -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/code_dma/image_rtos1
===== arch/ppc/boot/simple/Makefile 1.12 vs edited =====
138,139c138,139
< obj-$(CONFIG_GLACIER)		:= mpc7xxx_tty.o
< obj-$(CONFIG_ICECUBE)		:= mpc5xxx_tty.o
---
> obj-$(CONFIG_GLACIER)		+= mpc5xxx_tty.o
> obj-$(CONFIG_ICECUBE)		+= mpc5xxx_tty.o
===== arch/ppc/configs/icecube_defconfig 1.1 vs edited =====
36,37c36,37
< CONFIG_GLACIER=y
< # CONFIG_ICECUBE is not set
---
> # CONFIG_GLACIER is not set
> CONFIG_ICECUBE=y
51,52c51,52
< CONFIG_PPC_5xxx_PSC_CONSOLE_PORT=2
< CONFIG_PPC_5xxx_PROCFREQ=231000000
---
> CONFIG_PPC_5xxx_PSC_CONSOLE_PORT=0
> CONFIG_PPC_5xxx_PROCFREQ=396000000
53a54,55
> CONFIG_PPC_5xxx_FLASH_ADDR=ff800000
> CONFIG_PPC_5xxx_FLASH_SIZE=800000
95c97,163
< # CONFIG_MTD is not set
---
> CONFIG_MTD=y
> # CONFIG_MTD_DEBUG is not set
> CONFIG_MTD_PARTITIONS=y
> # CONFIG_MTD_CONCAT is not set
> # CONFIG_MTD_REDBOOT_PARTS is not set
> # CONFIG_MTD_CMDLINE_PARTS is not set
>
> #
> # User Modules And Translation Layers
> #
> CONFIG_MTD_CHAR=y
> CONFIG_MTD_BLOCK=y
> # CONFIG_FTL is not set
> # CONFIG_NFTL is not set
>
> #
> # RAM/ROM/Flash chip drivers
> #
> CONFIG_MTD_CFI=y
> # CONFIG_MTD_JEDECPROBE is not set
> CONFIG_MTD_GEN_PROBE=y
> # CONFIG_MTD_CFI_ADV_OPTIONS is not set
> # CONFIG_MTD_CFI_INTELEXT is not set
> CONFIG_MTD_CFI_AMDSTD=y
> # CONFIG_MTD_CFI_STAA is not set
> # CONFIG_MTD_RAM is not set
> # CONFIG_MTD_ROM is not set
> # CONFIG_MTD_ABSENT is not set
> # CONFIG_MTD_OBSOLETE_CHIPS is not set
> # CONFIG_MTD_AMDSTD is not set
> # CONFIG_MTD_SHARP is not set
> # CONFIG_MTD_JEDEC is not set
>
> #
> # Mapping drivers for chip access
> #
> # CONFIG_MTD_PHYSMAP is not set
> # CONFIG_MTD_TQM8XXL is not set
> # CONFIG_MTD_RPXLITE is not set
> # CONFIG_MTD_MBX860 is not set
> # CONFIG_MTD_DBOX2 is not set
> # CONFIG_MTD_CFI_FLAGADM is not set
> # CONFIG_MTD_REDWOOD is not set
> CONFIG_MTD_ICECUBE=y
> # CONFIG_MTD_PCI is not set
> # CONFIG_MTD_PCMCIA is not set
>
> #
> # Self-contained MTD device drivers
> #
> # CONFIG_MTD_PMC551 is not set
> # CONFIG_MTD_SLRAM is not set
> # CONFIG_MTD_MTDRAM is not set
> # CONFIG_MTD_BLKMTD is not set
>
> #
> # Disk-On-Chip Device Drivers
> #
> # CONFIG_MTD_DOC1000 is not set
> # CONFIG_MTD_DOC2000 is not set
> # CONFIG_MTD_DOC2001 is not set
> # CONFIG_MTD_DOCPROBE is not set
>
> #
> # NAND Flash Device Drivers
> #
> # CONFIG_MTD_NAND is not set
529c597
< # CONFIG_USE_MDIO is not set
---
> CONFIG_USE_MDIO=y
531c599
< # CONFIG_FEC_LXT971 is not set
---
> CONFIG_FEC_LXT971=y
559c627
< # CONFIG_CRC32 is not set
---
> CONFIG_CRC32=y
574a643
> # CONFIG_SERIAL_TEXT_DEBUG is not set
===== arch/ppc/platforms/icecube.h 1.1 vs edited =====
61c61
< 	.iomem_base = (void *)MPC5xxx_PSC##num##,	\
---
> 	.iomem_base = (void *)MPC5xxx_PSC##num,		\

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

Re: MPC5200 Patches

[Dale Farnsworth]

On Wed, Dec 03, 2003 at 07:53:05PM +0100, Wolfgang Denk wrote:
> Can you please resend the patch as unified (or context)  diff?

Oops.

Thanks,
-Dale

===== arch/ppc/5xxx_io/bestcomm/Makefile 1.1 vs edited =====
--- 1.1/arch/ppc/5xxx_io/bestcomm/Makefile	Wed Nov 26 07:41:36 2003
+++ edited/arch/ppc/5xxx_io/bestcomm/Makefile	Tue Dec  2 12:17:32 2003
@@ -7,7 +7,7 @@
 #
 # Note 2! The CFLAGS definition is now in the main makefile...

-EXTRA_CFLAGS = -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/include -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/capi -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/capi/task_api -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/code_dma/image_rtos1
+EXTRA_CFLAGS = -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/include -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/capi -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/capi/task_api -I$(TOPDIR)/arch/$(ARCH)/5xxx_io/bestcomm/code_dma/image_rtos1

 O_TARGET := bestcomm.o

===== arch/ppc/boot/simple/Makefile 1.12 vs edited =====
--- 1.12/arch/ppc/boot/simple/Makefile	Wed Nov 26 07:41:35 2003
+++ edited/arch/ppc/boot/simple/Makefile	Wed Dec  3 08:44:36 2003
@@ -135,8 +135,8 @@
 obj-$(CONFIG_8xx)		+= m8xx_tty.o
 obj-$(CONFIG_8260)		+= m8260_tty.o
 obj-$(CONFIG_SERIAL)		+= ../common/ns16550.o
-obj-$(CONFIG_GLACIER)		:= mpc7xxx_tty.o
-obj-$(CONFIG_ICECUBE)		:= mpc5xxx_tty.o
+obj-$(CONFIG_GLACIER)		+= mpc5xxx_tty.o
+obj-$(CONFIG_ICECUBE)		+= mpc5xxx_tty.o
 endif

 LIBS				:= ../lib/zlib.a
===== arch/ppc/configs/icecube_defconfig 1.1 vs edited =====
--- 1.1/arch/ppc/configs/icecube_defconfig	Wed Nov 26 07:41:41 2003
+++ edited/arch/ppc/configs/icecube_defconfig	Wed Dec  3 11:24:30 2003
@@ -33,8 +33,8 @@
 # CONFIG_ALL_PPC is not set
 # CONFIG_APUS is not set
 # CONFIG_SPRUCE is not set
-CONFIG_GLACIER=y
-# CONFIG_ICECUBE is not set
+# CONFIG_GLACIER is not set
+CONFIG_ICECUBE=y
 # CONFIG_LOPEC is not set
 # CONFIG_PPLUS is not set
 # CONFIG_PAL4 is not set
@@ -48,9 +48,11 @@
 CONFIG_MPC5200=y
 CONFIG_PPC_5xxx_PSC_CONSOLE_BAUD=115200
 # CONFIG_UBOOT is not set
-CONFIG_PPC_5xxx_PSC_CONSOLE_PORT=2
-CONFIG_PPC_5xxx_PROCFREQ=231000000
+CONFIG_PPC_5xxx_PSC_CONSOLE_PORT=0
+CONFIG_PPC_5xxx_PROCFREQ=396000000
 CONFIG_PPC_5xxx_IPBFREQ=66000000
+CONFIG_PPC_5xxx_FLASH_ADDR=ff800000
+CONFIG_PPC_5xxx_FLASH_SIZE=800000

 #
 # General setup
@@ -92,7 +94,73 @@
 #
 # Memory Technology Devices (MTD)
 #
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_CONCAT is not set
+# CONFIG_MTD_REDBOOT_PARTS is not set
+# CONFIG_MTD_CMDLINE_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+# CONFIG_MTD_OBSOLETE_CHIPS is not set
+# CONFIG_MTD_AMDSTD is not set
+# CONFIG_MTD_SHARP is not set
+# CONFIG_MTD_JEDEC is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_PHYSMAP is not set
+# CONFIG_MTD_TQM8XXL is not set
+# CONFIG_MTD_RPXLITE is not set
+# CONFIG_MTD_MBX860 is not set
+# CONFIG_MTD_DBOX2 is not set
+# CONFIG_MTD_CFI_FLAGADM is not set
+# CONFIG_MTD_REDWOOD is not set
+CONFIG_MTD_ICECUBE=y
+# CONFIG_MTD_PCI is not set
+# CONFIG_MTD_PCMCIA is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLKMTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC1000 is not set
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOCPROBE is not set
+
+#
+# NAND Flash Device Drivers
+#
+# CONFIG_MTD_NAND is not set

 #
 # Plug and Play configuration
@@ -526,9 +594,9 @@
 # MPC5xxx I/O Options
 #
 CONFIG_PPC_5xxx_FEC=y
-# CONFIG_USE_MDIO is not set
+CONFIG_USE_MDIO=y
 # CONFIG_FEC_GENERIC_PHY is not set
-# CONFIG_FEC_LXT971 is not set
+CONFIG_FEC_LXT971=y
 CONFIG_PPC_5xxx_PSC=y
 CONFIG_PPC_5xxx_PSC_CONSOLE=y
 CONFIG_SERIAL_CONSOLE=y
@@ -556,7 +624,7 @@
 #
 # Library routines
 #
-# CONFIG_CRC32 is not set
+CONFIG_CRC32=y
 CONFIG_ZLIB_INFLATE=y
 CONFIG_ZLIB_DEFLATE=y

@@ -572,4 +640,5 @@
 # CONFIG_XMON is not set
 CONFIG_BDI_SWITCH=y
 # CONFIG_MORE_COMPILE_OPTIONS is not set
+# CONFIG_SERIAL_TEXT_DEBUG is not set
 CONFIG_LOG_BUF_SHIFT=0
===== arch/ppc/platforms/icecube.h 1.1 vs edited =====
--- 1.1/arch/ppc/platforms/icecube.h	Wed Nov 26 07:41:42 2003
+++ edited/arch/ppc/platforms/icecube.h	Tue Dec  2 15:22:51 2003
@@ -58,7 +58,7 @@
 	.baud_base = MPC5xxx_INIT_BAUD_BASE,		\
 	.irq = MPC5xxx_PSC##num##_IRQ,			\
 	.flags = ASYNC_BOOT_AUTOCONF|ASYNC_SKIP_TEST, 	\
-	.iomem_base = (void *)MPC5xxx_PSC##num##,	\
+	.iomem_base = (void *)MPC5xxx_PSC##num,		\
 	.io_type = SERIAL_IO_MEM,			\
 },


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

Re: MPC5200 Patches

[Dale Farnsworth]

On Mon, Nov 10, 2003 at 04:25:36PM +0000, Tom Rini wrote:
> Speaking of the FEC code, someone should run one version (and for the
> moment, I vote for Wolfgang's version) past Jeff Garzik to see what he
> thinks.

The version contained in
ftp://source.mvista.com/pub/linuxppc/mpc5200/linuxppc_2_4_devel.mpc5200.patch
is a bit cleaner, since many ifdefs for mgt5100 support have been removed.
It could stand quite a bit of cleanup, but I'll ask Jeff to take a look.

> > > so ethernet isn't quite working again, yet.  I've made several changes
> > > to the 5200 port as well.
> > >
> > > I will post my updated code to this list this week and would prefer
> > > to see it merged rather than my older code contained in the above patch.
> >
> > The code I submitted contains some things; some code was developed by
> > BenH, some by DENX. It would be sad if this stuff was  just  ignored.
> > How about merging our code and your new stuff?
>
> I concur that it would be best to try and merge these two versions back
> together.

See my attempt at the above url.

Thanks,
-Dale

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