Proposed Kconfig update patch for help text

Proposed Kconfig update patch for help text

[John Whitney]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

A couple of trivial changes for the processor choice help text to make
it a bit clearer.

John

--- Kconfig.orig    2004-03-31 17:25:53.000000000 -0500
+++ Kconfig 2004-03-31 17:38:57.000000000 -0500
@@ -44,13 +44,14 @@
     default 6xx

  config 6xx
-   bool "6xx/7xx/74xx/8260"
+   bool "6xx/7xx/74xx/82xx"
     help
-     There are four types of PowerPC chips supported.  The more common
+     There are four types of PowerPC chips supported: the more common
       types (601, 603, 604, 740, 750, 7400), the Motorola embedded
-     versions (821, 823, 850, 855, 860, 8260), the IBM embedded
versions
+     versions (821, 823, 850, 855, 860, 82xx), the IBM embedded
versions
       (403 and 405) and the high end 64 bit Power processors (POWER 3,
-     POWER4, and IBM 970 also known as G5)
+     POWER4, and IBM 970 also known as G5).
+
       Unless you are building a kernel for one of the embedded processor
       systems, 64 bit IBM RS/6000 or an Apple G5, choose 6xx.
       Note that the kernel runs in 32-bit mode even on 64-bit chips.



[-- Attachment #2: Kconfig.patch --]
[-- Type: application/octet-stream, Size: 911 bytes --]

--- Kconfig.orig	2004-03-31 17:25:53.000000000 -0500
+++ Kconfig	2004-03-31 17:38:57.000000000 -0500
@@ -44,13 +44,14 @@
 	default 6xx

 config 6xx
-	bool "6xx/7xx/74xx/8260"
+	bool "6xx/7xx/74xx/82xx"
 	help
-	  There are four types of PowerPC chips supported.  The more common
+	  There are four types of PowerPC chips supported: the more common
 	  types (601, 603, 604, 740, 750, 7400), the Motorola embedded
-	  versions (821, 823, 850, 855, 860, 8260), the IBM embedded versions
+	  versions (821, 823, 850, 855, 860, 82xx), the IBM embedded versions
 	  (403 and 405) and the high end 64 bit Power processors (POWER 3,
-	  POWER4, and IBM 970 also known as G5)
+	  POWER4, and IBM 970 also known as G5).
+
 	  Unless you are building a kernel for one of the embedded processor
 	  systems, 64 bit IBM RS/6000 or an Apple G5, choose 6xx.
 	  Note that the kernel runs in 32-bit mode even on 64-bit chips.

Re: Proposed Kconfig update patch for help text

[Wolfgang Denk]

In message <B755A2F6-8364-11D8-9FF0-000A95A07384@sands-edge.com> you wrote:
>
> A couple of trivial changes for the processor choice help text to make
> it a bit clearer.
...
>        types (601, 603, 604, 740, 750, 7400), the Motorola embedded
> -     versions (821, 823, 850, 855, 860, 8260), the IBM embedded
> versions
> +     versions (821, 823, 850, 855, 860, 82xx), the IBM embedded

How about types like 857, 862, the 866 family, the 885 family, ... ?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
God may be subtle, but He isn't plain mean.         - Albert Einstein

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

Re: Proposed Kconfig update patch for help text

[Dan Malek]

Wolfgang Denk wrote:
> In message <B755A2F6-8364-11D8-9FF0-000A95A07384@sands-edge.com> you wrote:
>
>>       types (601, 603, 604, 740, 750, 7400), the Motorola embedded
>>-     versions (821, 823, 850, 855, 860, 8260), the IBM embedded
>>versions
>>+     versions (821, 823, 850, 855, 860, 82xx), the IBM embedded
>
>
> How about types like 857, 862, the 866 family, the 885 family, ... ?

Well, the 821 should be canned, but I think all we differentiate
is 823/850 and "others", don't we?  The rest of the configuration
is determined by your I/O choices, which I personally like so we
don't have config files littered with all of the different CPM and
peripheral variations.  In fact, I think we currently just ask for
alternate SMC1 pin mapping, so we don't even need to specifically
know 823/850.

Thanks.


	-- Dan


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

Re: Proposed Kconfig update patch for help text

[John Whitney]

We can put in "8xx", but I didn't think that the listed processors was
supposed to be an exhaustive list (just some examples).   Shall we just
prune them down to "8xx", "4xx", etc.?

John

On Mar 31, 2004, at 6:06 PM, Wolfgang Denk wrote:

> In message <B755A2F6-8364-11D8-9FF0-000A95A07384@sands-edge.com> you wrote:
>>
>> A couple of trivial changes for the processor choice help text to
>> make it a bit clearer.
> ...
>>        types (601, 603, 604, 740, 750, 7400), the Motorola embedded
>> -     versions (821, 823, 850, 855, 860, 8260), the IBM embedded
>> versions
>> +     versions (821, 823, 850, 855, 860, 82xx), the IBM embedded
>
> How about types like 857, 862, the 866 family, the 885 family, ... ?

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

Re: Proposed Kconfig update patch for help text

[Geert Uytterhoeven]

On Wed, 31 Mar 2004, John Whitney wrote:
> We can put in "8xx", but I didn't think that the listed processors was
> supposed to be an exhaustive list (just some examples).   Shall we just
> prune them down to "8xx", "4xx", etc.?

While you're at it, perhaps s/7400/74xx/ for consistency, too?

> On Mar 31, 2004, at 6:06 PM, Wolfgang Denk wrote:
> > In message <B755A2F6-8364-11D8-9FF0-000A95A07384@sands-edge.com> you wrote:
> >>
> >> A couple of trivial changes for the processor choice help text to
> >> make it a bit clearer.
> > ...
> >>        types (601, 603, 604, 740, 750, 7400), the Motorola embedded
> >> -     versions (821, 823, 850, 855, 860, 8260), the IBM embedded
> >> versions
> >> +     versions (821, 823, 850, 855, 860, 82xx), the IBM embedded
> >
> > How about types like 857, 862, the 866 family, the 885 family, ... ?

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: Proposed Kconfig update patch for help text

[Kumar Gala]

Also, what about 52xx?
- kumar

On Apr 1, 2004, at 2:35 AM, Geert Uytterhoeven wrote:

>
> On Wed, 31 Mar 2004, John Whitney wrote:
>> We can put in "8xx", but I didn't think that the listed processors was
>> supposed to be an exhaustive list (just some examples).   Shall we
>> just
>> prune them down to "8xx", "4xx", etc.?
>
> While you're at it, perhaps s/7400/74xx/ for consistency, too?
>
>> On Mar 31, 2004, at 6:06 PM, Wolfgang Denk wrote:
>>> In message <B755A2F6-8364-11D8-9FF0-000A95A07384@sands-edge.com> you
>>> wrote:
>>>>
>>>> A couple of trivial changes for the processor choice help text to
>>>> make it a bit clearer.
>>> ...
>>>>        types (601, 603, 604, 740, 750, 7400), the Motorola embedded
>>>> -     versions (821, 823, 850, 855, 860, 8260), the IBM embedded
>>>> versions
>>>> +     versions (821, 823, 850, 855, 860, 82xx), the IBM embedded
>>>
>>> How about types like 857, 862, the 866 family, the 885 family, ... ?
>
> 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: Proposed Kconfig update patch for help text

[Wolfgang Denk]

In message <67423B18-83E3-11D8-B6FB-000393DBC2E8@motorola.com> you wrote:
>
> Also, what about 52xx?

Excellent question. OTOH - what do we need a Kconfig option for, when
the whole 52xx code is still missing in the official trees?   Tom?

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 inappropriate cannot be beautiful.
             - Frank Lloyd Wright _The Future of Architecture_ (1953)

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

mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Tom Rini]

On Thu, Apr 01, 2004 at 05:02:06PM +0200, Wolfgang Denk wrote:

>
> In message <67423B18-83E3-11D8-B6FB-000393DBC2E8@motorola.com> you wrote:
> >
> > Also, what about 52xx?
>
> Excellent question. OTOH - what do we need a Kconfig option for, when
> the whole 52xx code is still missing in the official trees?   Tom?

I'll take the high road and avoid an easy april fools joke here.

In all seriousness, when the 52xx code for 2.4 was brought up, there
were a number of objections to the Motorola provided code, from it's
buggy to it being unacceptable crap.  Finally, 2.4 is about to enter a
"deep freeze", or so Marcelo intends at least, so I think it's out of
the question for the mainline.  I don't mind keeping the
linux-2.4-mpc5xxx tree up to date so others can pull for what they need,
but it's a dead end.

For 2.6, I think one of the following options needs to be done.
- Motorola code, cleaned up with input from the community (and the bits
  Linux just doesn't need, left out).
- Ignore the Motorola code, or since it's GPL (must be to be in the
  kernel, so I'm just making the assumption here...) use it as a guide
  for how things work to implement a clean Linux implementation of the
  code.   I know there's someone working on this (who pops up on
  #mklinux on freenode from time to time) but I don't know how far
  they've gotten.

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

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Dan Malek]

Tom Rini wrote:

> In all seriousness, when the 52xx code for 2.4 was brought up, there
> were a number of objections to the Motorola provided code,

Does anyone actually use this code?  From the work I've done it appears
the FEC implements it's own DMA, other peripherals are used in programmed I/O
mode, and stuff I have done I've found it easier to just write my own
code manage the DMA.  IMHO we should just punt this stuff for Linux,
now that there is more public interest start collaborating on a better
solution, and maybe just use what Mot provided as documentation filler.
The Motorola solution seems like an attempt to be everything for everyone.

Thanks.


	-- Dan


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

Re: Proposed Kconfig update patch for help text)

[Tom Rini]

On Thu, Apr 01, 2004 at 11:58:14AM -0500, Dan Malek wrote:
> Tom Rini wrote:
>
> >In all seriousness, when the 52xx code for 2.4 was brought up, there
> >were a number of objections to the Motorola provided code,
>
> Does anyone actually use this code?  From the work I've done it appears
> the FEC implements it's own DMA, other peripherals are used in programmed
> I/O
> mode, and stuff I have done I've found it easier to just write my own
> code manage the DMA.  IMHO we should just punt this stuff for Linux,
> now that there is more public interest start collaborating on a better
> solution, and maybe just use what Mot provided as documentation filler.
> The Motorola solution seems like an attempt to be everything for everyone.

FWIW, I think I lean towards this (which to be clear if I wasn't before,
is the second option I described) approach as well.  Not that I have hw
handy. :)

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

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Wolfgang Denk]

In message <406C4A26.3040107@embeddededge.com> you wrote:
>
> > In all seriousness, when the 52xx code for 2.4 was brought up, there
> > were a number of objections to the Motorola provided code,
>
> Does anyone actually use this code?  From the work I've done it appears

Yes.

> the FEC implements it's own DMA, other peripherals are used in programmed I/O

Indeed, the FEC implementation should be cleaned up.

> mode, and stuff I have done I've found it easier to just write my own
> code manage the DMA.  IMHO we should just punt this stuff for Linux,
> now that there is more public interest start collaborating on a better
> solution, and maybe just use what Mot provided as documentation filler.

I cannot speak for Motorola, but I understand they would welcome  any
input for improvement. Instead of working separately and against each
other we should co-operate.

> The Motorola solution seems like an attempt to be everything for everyone.

Indeed. They have to support more than just Linux.

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
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
      - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Wolfgang Denk]

In message <20040401161622.GA26876@smtp.west.cox.net> you wrote:
>
> In all seriousness, when the 52xx code for 2.4 was brought up, there
> were a number of objections to the Motorola provided code, from it's
> buggy to it being unacceptable crap.  Finally, 2.4 is about to enter a

So far, it's all we have, right? Or do you have anything significant-
ly better?

> "deep freeze", or so Marcelo intends at least, so I think it's out of
> the question for the mainline.  I don't mind keeping the

So why made you me submit all the stuff in the first place  when  you
were going to put it on hold until it was too late for inclusion?

> linux-2.4-mpc5xxx tree up to date so others can pull for what they need,
> but it's a dead end.

Indeed. Develpment continues in our CVS tree. I will  not  waste  the
time and effort to produce any new patches if they get dumped anyway.

> For 2.6, I think one of the following options needs to be done.
> - Motorola code, cleaned up with input from the community (and the bits
>   Linux just doesn't need, left out).

I think this is the only option there is.

> - Ignore the Motorola code, or since it's GPL (must be to be in the
>   kernel, so I'm just making the assumption here...) use it as a guide
>   for how things work to implement a clean Linux implementation of the
>   code.   I know there's someone working on this (who pops up on
>   #mklinux on freenode from time to time) but I don't know how far
>   they've gotten.

Ummm... Why is there no discussion about this on  any  mailing  list?
And don't you think that that at least Motorola should be included in
any  such  attempts? [AFAICT they are not, at least not until today.]
Also, isn't this kind of wasted effort as the target is still moving?

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
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.

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

Re: Proposed Kconfig update patch for help text)

[Tom Rini]

On Thu, Apr 01, 2004 at 07:05:10PM +0200, Wolfgang Denk wrote:
> In message <20040401161622.GA26876@smtp.west.cox.net> you wrote:
> >
> > In all seriousness, when the 52xx code for 2.4 was brought up, there
> > were a number of objections to the Motorola provided code, from it's
> > buggy to it being unacceptable crap.  Finally, 2.4 is about to enter a
>
> So far, it's all we have, right? Or do you have anything significant-
> ly better?

As I said, someone is working on the second option I described, but I
don't know how far they have gotten.

> > "deep freeze", or so Marcelo intends at least, so I think it's out of
> > the question for the mainline.  I don't mind keeping the
>
> So why made you me submit all the stuff in the first place  when  you
> were going to put it on hold until it was too late for inclusion?

When I asked, there was time.  Once I started trying to get people to
review it (since that's what upstream people like, and it's good
practice) it became apparent that the code wasn't in good enough shape
to get in.

> > For 2.6, I think one of the following options needs to be done.
> > - Motorola code, cleaned up with input from the community (and the bits
> >   Linux just doesn't need, left out).
>
> I think this is the only option there is.
>
> > - Ignore the Motorola code, or since it's GPL (must be to be in the
> >   kernel, so I'm just making the assumption here...) use it as a guide
> >   for how things work to implement a clean Linux implementation of the
> >   code.   I know there's someone working on this (who pops up on
> >   #mklinux on freenode from time to time) but I don't know how far
> >   they've gotten.
>
> Ummm... Why is there no discussion about this on  any  mailing  list?

There was some discussion in the same thread where people like benh
pointed out how bad the code is.  And there's a discussion right now,
right here even.

> And don't you think that that at least Motorola should be included in
> any  such  attempts? [AFAICT they are not, at least not until today.]

Well, Kumar is cc'ed here, and he's even on #mklinux on freenode where
Paul, benh, myself, and a lot of other people (including the person who
I suspect is on this list, but I don't know) who're working on 5xxx for
2.6 support, without the Motorola code.  If there's a specific person at
Motorola who'd be interested in what the Linux community has to say
about the DMA code, no one has told me who.

> Also, isn't this kind of wasted effort as the target is still moving?

What target?  The Motorola code?  The 5xxx hw line?  If you're talking
about kernels, the only non-moving target right now is 2.2, but I don't
think you're talking about that.

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

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

Re: Proposed Kconfig update patch for help text)

[Wolfgang Denk]

In message <20040401171956.GD26876@smtp.west.cox.net> you wrote:
>
> > So far, it's all we have, right? Or do you have anything significant-
> > ly better?
>
> As I said, someone is working on the second option I described, but I
> don't know how far they have gotten.

Is this a secret or what? Why don't you give names?  Why  doesn't  he
show up on this list?

> 2.6 support, without the Motorola code.  If there's a specific person at
> Motorola who'd be interested in what the Linux community has to say
> about the DMA code, no one has told me who.

You are not working on this, or are you?

> > Also, isn't this kind of wasted effort as the target is still moving?
>
> What target?  The Motorola code?  The 5xxx hw line?  If you're talking

The Motorola code, and to some extend the hardware.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
How does a project get to be a year late?      ... One day at a time.

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

Re: Proposed Kconfig update patch for help text)

[Tom Rini]

On Thu, Apr 01, 2004 at 08:56:51PM +0200, Wolfgang Denk wrote:
> In message <20040401171956.GD26876@smtp.west.cox.net> you wrote:
> >
> > > So far, it's all we have, right? Or do you have anything significant-
> > > ly better?
> >
> > As I said, someone is working on the second option I described, but I
> > don't know how far they have gotten.
>
> Is this a secret or what? Why don't you give names?  Why  doesn't  he
> show up on this list?

Because I'm not omniscient?  Looking back in the linuxppc-embedded
archives, and recalling his nickname from IRC, it appears to be Sylvain
Munaut <tnt@246tNt.com>, whom you've even answered 5200 questions for.
Sylvain, have you made much progress on 52xx support in 2.6?

> > 2.6 support, without the Motorola code.  If there's a specific person at
> > Motorola who'd be interested in what the Linux community has to say
> > about the DMA code, no one has told me who.
>
> You are not working on this, or are you?

<hat="MontaVista Employee">I personally am not, but I know engineers
who are or have in the recent past, worked on 5xxx && Linux in MV</hat>
<hat="Community Person">Since I do try and get changes people make into
kernel.org, Yes</hat>

> > > Also, isn't this kind of wasted effort as the target is still moving?
> >
> > What target?  The Motorola code?  The 5xxx hw line?  If you're talking
>
> The Motorola code, and to some extend the hardware.

As I've stated before, in reference to other vendor-provided HAL code,
if the vendor is willing to work to address community concerns about the
vendor code (which includes subscribing to linuxppc-dev and -embedded so
they can field questions / comments / concerns about it), that works for
me.  But I had been under the impression that Motorola did not
particularly care to fix the concerns that had been raised.  If this
impression is incorrect, then I'd like to see someone step up, who has
authority to address said concerns (such as to paraphrase Dan Malek, why
do we need this?).

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

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Sylvain Munaut]

Wolfgang Denk wrote:

>>- Ignore the Motorola code, or since it's GPL (must be to be in the
>>  kernel, so I'm just making the assumption here...) use it as a guide
>>  for how things work to implement a clean Linux implementation of
>>  the code. I know there's someone working on this (who pops up on
>>  #mklinux on freenode from time to time) but I don't know how far
>>  they've gotten.
>
>Ummm... Why is there no discussion about this on any mailing list? And
>don't you think that that at least Motorola should be included in any
>such attempts? [AFAICT they are not, at least not until today.] Also,
>isn't this kind of wasted effort as the target is still moving?

Well, huh, I talked about it on the embedded ml :

http://lists.linuxppc.org/linuxppc-embedded/200403/msg00082.html

along with some 'strange stuff' in the 2.4 port memory map

http://lists.linuxppc.org/linuxppc-embedded/200403/msg00095.html

Yeah sure, having Motorola involved would certainly help, but I don't
have any official contact with them and my Motorola semiconductor
distributor and I are not in best terms recently so I just hoped that
some one concerned at motorola would be reading the list ...

About the bestcomm code more precisly :
A lot of people told me that the code had some issues. So for the 2.6 I
just though that I would rewrite a code that would only fits the linux
needs. Of course I won't just ignore the motorola code, for me rewriting
is looking at the current implementation is just a way to a better
understanding on how it works. If at the end, the motorola code is
cleaner/more generic and works better, then just use it, but as I
understand it it's not the case right now. If I'm not right, then,
please correct me.

Sylvain Munaut

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Sylvain Munaut]

Hi

>For 2.6, I think one of the following options needs to be done.
>- Motorola code, cleaned up with input from the community (and the bits
>  Linux just doesn't need, left out).
>- Ignore the Motorola code, or since it's GPL (must be to be in the
>  kernel, so I'm just making the assumption here...) use it as a guide
>  for how things work to implement a clean Linux implementation of
>  the code. I know there's someone working on this (who pops up on
>  #mklinux on freenode from time to time) but I don't know how far
>  they've gotten.

I think you're referring to me ;)
What is done :
 - All the kconfig stuff to add options for MPC5xxx and the very low
level stuff like adding in cputable and so on, just to get it recognized.
 - A serial driver that provides a working console ( It still misses
some stuff like modem ctrl because I don't understand that one well )
 - The I2C driver is working ( I can access the on board eeprom of the
IceCube )
 - The USB driver is started however it's not functionnal yet.
Apparently there is a lot of endian issues. In the 2.4 core, they
modified the generic ohci driver with #ifdef #endif to  change the
access from little endian to big endian. But I don't like this solution
because I personnaly have on a custom board a OHCI on PCI and the built
in ports, so I need to find a 'clean' solution.
 - The ethernet code is in *VERY* early stages, I just have the global
arch and some ideas in my head on how to do it.

I'm planning on just ignoring the Motorola code since there apparently
are problem with it ( I though that the motorola update was planned for
mid-feb but ... ) , I was just gonna implement something very simple
that just does what it need for the linux drivers to work cleanly and
properly.

I've tried to write the code as cleany as possible, it uses the OCP
stuff that was on linux-2.5-ocp and also the generic dma stuff.

I can provide the patches on request, I just didn't published it because
I don't know where to ...

Also, for a couple of week, my work is 'paused' on this but since I
would need stuff like ethernet and I2S working for mid-may, I'll resume
my work on it ASAP.

Sylvain Munaut

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

New OCP for 2.6 was (Re: mpc5xxx support )

[Matt Porter]

On Fri, Apr 02, 2004 at 01:35:58AM +0200, Sylvain Munaut wrote:
> I've tried to write the code as cleany as possible, it uses the OCP
> stuff that was on linux-2.5-ocp and also the generic dma stuff.

I'll add you to the list of people developing 2.6 code against the
new OCP:
	Kumar	-> MPC85xx
	Mark G	-> MV64xxx
	Matt	-> IBM4xx
        Sylvain	-> MPC52xx

Just FYI for everybody wondering about new OCP.  The 2.6 port of
BenH's new OCP rewrite is at bk://source.mvista.com/linux-2.5-ocp.
The API and functionality match that of what is currently in
linux-2.4/linuxppc-2.4.  There are a number of changes/improvements
that have been discussed, but I want to get the equivalent to
the 2.4 functionality into 2.6 before we go any further.

BenH and I are slowly working on figuring out what if anything
needs to be done to get this in linux-2.5.

-Matt

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Wolfgang Denk]

In message <406CA75E.2070508@246tNt.com> Sylvain Munaut wrote:
>
> I'm planning on just ignoring the Motorola code since there apparently
> are problem with it ( I though that the motorola update was planned for
> mid-feb but ... ) , I was just gonna implement something very simple
> that just does what it need for the linux drivers to work cleanly and
> properly.

Let's rather co-operate with Motorola on this instead working against
them. At least give them a chance.

I guess they will show up here 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
The greatest threat towards future is indifference.

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Sylvain Munaut]

Wolfgang Denk wrote:

>Let's rather co-operate with Motorola on this instead working against
>them. At least give them a chance.
>
>I guess they will show up here soon...
>
>
Ok, as I said by private mail, now that I know they are actively working
on solving the problem, I'll try to integrate the bestcom code into the
port I'm working on.
After all, they are the best placed people to get their hardware work
nicely ;)

The only things that bothers me in the BestComm API is the name of the
functions ... I think they should be prefixed with something ... just my
2 cents.


Sylvain Munaut

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Wolfgang Denk]

In message <406DA118.8050405@246tNt.com> you wrote:
>
> Ok, as I said by private mail, now that I know they are actively working
> on solving the problem, I'll try to integrate the bestcom code into the
> port I'm working on.

We have checked in the new BestComm API 2.0 code (release 02 April 2004)
on our CVS server.

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 game of life is a game of boomerangs.  Our  thoughts,  deeds  and
words return to us sooner or later with astounding accuracy.

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

Re: mpc5xxx support (Was: Re: Proposed Kconfig update patch for help text)

[Sylvain Munaut]

Wolfgang Denk wrote:

>In message <406DA118.8050405@246tNt.com> you wrote:
>
>
>>Ok, as I said by private mail, now that I know they are actively working
>>on solving the problem, I'll try to integrate the bestcom code into the
>>port I'm working on.
>>
>>
>
>We have checked in the new BestComm API 2.0 code (release 02 April 2004)
>on our CVS server.
>
>
Thanks. I just got from motorola. But extracting it from the linuxppc
devel tree will be more easy I think since it's already 'sorted'.

Does that mean that things got better with this release ?


Sylvain Munaut

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

Re: Proposed Kconfig update patch for help text

[Tom Rini]

On Thu, Apr 01, 2004 at 07:49:32AM -0600, Kumar Gala wrote:

> Also, what about 52xx?

Not in the tree, and a different can of worms. :)

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

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

Re: Proposed Kconfig update patch for help text

[John Whitney]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

Here's the latest Kconfig help-text patch for your consideration.  I
considered enumerating each chip supported, but that will be a
maintenance headache, and I'm not even sure I could list them all.  I'm
fairly sure that the 8250 is supported, but it isn't listed in
arch/ppc/kernel/cputable.c, so I'm guessing its PVR is covered by the
8260 entry.  I don't want to figure out which ones are supported but
not explicitly covered, so I went with the "##xx" method.

Let me know what you think...

John


[-- Attachment #2: Kconfig.patch --]
[-- Type: application/octet-stream, Size: 3336 bytes --]

--- linuxppc-2.6.5-rc2.orig/arch/ppc/Kconfig	2004-04-01 14:23:12.000000000 -0500
+++ linuxppc-2.6.5-rc2/arch/ppc/Kconfig	2004-04-01 16:46:11.000000000 -0500
@@ -44,33 +44,77 @@
 	default 6xx

 config 6xx
-	bool "6xx/7xx/74xx/8260"
+	bool "6xx/7xx/74xx/82xx"
 	help
 	  There are four types of PowerPC chips supported.  The more common
-	  types (601, 603, 604, 740, 750, 7400), the Motorola embedded
-	  versions (821, 823, 850, 855, 860, 8260), the IBM embedded versions
-	  (403 and 405) and the high end 64 bit Power processors (POWER 3,
-	  POWER4, and IBM 970 also known as G5)
+	  types (6xx, 7xx, 74xx), the Motorola embedded versions (8xx, 82xx), the
+	  IBM embedded versions (4xx) and the high end 64 bit Power processors
+	  (POWER 3, POWER4, and IBM 970 also known as G5).
+
+	  Choose this option if you are building a kernel for a platform with a
+	  Motorola or IBM 6xx, 7xx, 74xx, or 82xx processor.
+
 	  Unless you are building a kernel for one of the embedded processor
 	  systems, 64 bit IBM RS/6000 or an Apple G5, choose 6xx.
+
 	  Note that the kernel runs in 32-bit mode even on 64-bit chips.
 	  Also note that because the 82xx family has a 603e core, specific
 	  support for that chipset is asked later on.

 config 40x
 	bool "40x"
+	help
+	  There are four types of PowerPC chips supported.  The more common
+	  types (6xx, 7xx, 74xx), the Motorola embedded versions (8xx, 82xx), the
+	  IBM embedded versions (4xx) and the high end 64 bit Power processors
+	  (POWER 3, POWER4, and IBM 970 also known as G5).
+
+	  Choose this option if you are building a kernel for a platform with an
+	  IBM 403 or 405 processor.

 config 44x
 	bool "44x"
+	help
+	  There are four types of PowerPC chips supported.  The more common
+	  types (6xx, 7xx, 74xx), the Motorola embedded versions (8xx, 82xx), the
+	  IBM embedded versions (4xx) and the high end 64 bit Power processors
+	  (POWER 3, POWER4, and IBM 970 also known as G5).
+
+	  Choose this option if you are building a kernel for a platform with an
+	  IBM 440 processor.

 config POWER3
 	bool "POWER3"
+	help
+	  There are four types of PowerPC chips supported.  The more common
+	  types (6xx, 7xx, 74xx), the Motorola embedded versions (8xx, 82xx), the
+	  IBM embedded versions (4xx) and the high end 64 bit Power processors
+	  (POWER 3, POWER4, and IBM 970 also known as G5).
+
+	  Choose this option if you are building a kernel for a platform with an
+	  IBM POWER3 processor.

 config POWER4
 	bool "POWER4 and 970 (G5)"
+	help
+	  There are four types of PowerPC chips supported.  The more common
+	  types (6xx, 7xx, 74xx), the Motorola embedded versions (8xx, 82xx), the
+	  IBM embedded versions (4xx) and the high end 64 bit Power processors
+	  (POWER 3, POWER4, and IBM 970 also known as G5).
+
+	  Choose this option if you are building a kernel for a platform with an
+	  IBM POWER4 or 970 (G5) processor.

 config 8xx
 	bool "8xx"
+	help
+	  There are four types of PowerPC chips supported.  The more common
+	  types (6xx, 7xx, 74xx), the Motorola embedded versions (8xx, 82xx), the
+	  IBM embedded versions (4xx) and the high end 64 bit Power processors
+	  (POWER 3, POWER4, and IBM 970 also known as G5).
+
+	  Choose this option if you are building a kernel for a platform with a
+	  Motorola 8xx embedded processor.

 endchoice

Re: Proposed Kconfig update patch for help text

[Kumar Gala]

I'm trying to figure how how I would fit the e500 core and 85xx into
your descriptions.

- kumar

On Apr 1, 2004, at 3:50 PM, John Whitney wrote:

> Here's the latest Kconfig help-text patch for your consideration.  I
> considered enumerating each chip supported, but that will be a
> maintenance headache, and I'm not even sure I could list them all.  I'm
> fairly sure that the 8250 is supported, but it isn't listed in
> arch/ppc/kernel/cputable.c, so I'm guessing its PVR is covered by the
> 8260 entry.  I don't want to figure out which ones are supported but
> not explicitly covered, so I went with the "##xx" method.
>
> Let me know what you think...
>
> John
>
>
> <Kconfig.patch>


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

Re: Proposed Kconfig update patch for help text

[Kumar Gala]

I'm trying to figure how how I would fit the e500 core and 85xx into
your descriptions.

- kumar

On Apr 1, 2004, at 3:50 PM, John Whitney wrote:

> Here's the latest Kconfig help-text patch for your consideration.  I
> considered enumerating each chip supported, but that will be a
> maintenance headache, and I'm not even sure I could list them all.  I'm
> fairly sure that the 8250 is supported, but it isn't listed in
> arch/ppc/kernel/cputable.c, so I'm guessing its PVR is covered by the
> 8260 entry.  I don't want to figure out which ones are supported but
> not explicitly covered, so I went with the "##xx" method.
>
> Let me know what you think...
>
> John
>
>
> <Kconfig.patch>


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