Interrupt routing in prep_pci.c

VALETTE Eric valette at crf.canon.fr
Wed Feb 24 02:55:09 EST 1999


>>>>> "Johnnie" == Johnnie Peters <jpeters at phx.mcd.mot.com> writes:

Johnnie> I have tried Gabriels patches.  I used his boot loader stuff with my own
Johnnie> Raven changes
Johnnie> and for some of our boards it worked great (namely the VME boards). 

I use Cpci board (mcp750) and it works well.

Johnnie> When you send a patch to Cort and wish it too be included, he will test it on
Johnnie> the
Johnnie> machines he currently has.  They are not all inclusive and if It breaks one
Johnnie> of them
Johnnie> then that patch should be rejected.  If he does not reject it then he looses
Johnnie> credibility in his submissions to Linus and at some time no more PPC code
Johnnie> will make it into the main base because Linus will not trust Cort.  I cannot
Johnnie> and
Johnnie> will not beleive that this is what you want.

I say this way of doing is bad because :

  1) Cort admit that he has no recent board,
  2) Value of a patch should be mesured in number of additionnal cards that works with
  a patch versus the number of boards it breaks AND a cleaner design.
  3) Sometimes you must admit to breaks things because otherwyse
  you will not manage to get further. I understand the discussion
  on source tree layout reorganisation is vital in this regard.
  
Allthough the current way of doing slows down the development, update to regular
linux source tree are not frequent... Many people have complained about CVS
access being broken that just makes things worse... And there is linux-pmac 
that still complicates the picture...

Johnnie> link where you could retrieve his stuff.  He also stated that it did not work
Johnnie> with Open Firmware.

Its work is called "prepboot" so if you think it is for OF sure you will not get too
far...

Johnnie> I have been using Linux since the 0.96 release.  

And I (with others) have designed what could have been the next version of 
Unixware 2.x if novell did not sell USL to SCO...

Johnnie> I have stated to Cort that I can test pretty much anything he needs on
Johnnie> Motorola
Johnnie> boxes (Blackhawk, Utah, MTX, MVMEXXXX, Mequite, Sitka, etc.)  I will tell

How many motorola board having OF can you buy today? How many having PPCBUG?

Johnnie> him where it does and does not work.  You can do the same it you have
Johnnie> resources.
Johnnie> We will get pretty much everything working with time.  Give Cort a break
Johnnie> and work with him.

What I can say for sure is that :

     1) not a single kernel released by Cort does work without modification 
     on MCP750 because the old code for interrupt routing screw up anythings 
     relies on PCI interrupt value. Besides there is no code for identifying
     the machines that would enables to gracefully include codes...
     2) I have seen patches to support the raven that have never been
     integrated although they work on MVMW2700 and MCP750 (are there
     other PREP machines that use raven???),
     3) Multi-device PCI function will never be handled correctly with actual
     prep code...
     4) PREP Ide byte swapping is still broken. You cannot read IDE disk
     partitionned on a PC, nor use PPCBUG pboot to load linux on a prep machine
     (allthough someone has already provided a patch...),

So, given that : I keep my patches as the code is ugly enough so that
I do not find way to correctly integrate it and as I need to apply
patch anyway, I prefer to apply them on "official" tree.

But that is probably not arguments that could convince someone with your
perfect understanding and your immense experience...

BTW, as you work for motorolla, may be you could you tell us how 
PPCBUG identifies boards dynamically. As least THIS would be helpfull.


--
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette at crf.canon.fr

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request at lists.linuxppc.org ]]




More information about the Linuxppc-dev mailing list