Interrupt routing in prep_pci.c

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort at persephone.cs.nmt.edu> writes:

Cort> It doesn't work many of the boards I have.  The residual data isn't
Cort> always there and isn't always right when it is there.  The comment about
Cort> it going away soon was referring to the code to use residual data - but it
Cort> turns out that we can't always depend on it.  I still don't like the way
Cort> we do it, though.

> Rather than having hard-coded tables, can't the interrupt routing be determined
> from either firmware or the interrupt controller itself?  The comment at the
> top of the file is that this will go away soon.  What are you planning to
> }> > replace it?
> }>
> }> Indeed, that's what I do from residual data on PreP machines and it seems
> to work on several kinds of boards. You'll find it embedded somewhere
> in the patch file at:


OK but with the current code :

   1) you scew up the value that may have been correctly set for PCI devices,
   BY ANY KIND OF FIRMWARE (PPCBUG, ...),
   2) You force epople to write a config for each board,
   3) you assume old 105, 106 PCI interrupt routing scheme that makes nothing
   on newer chips like raven,

Of course, residual does not provide anything but firmware may program
correctly the harware and interrupt routing. So I really believes
that
	1) we should know wether the board firmware correctly
	set up the PCI devices. If this is the case, the old
	interrupt scheme must be removed. Note that this
	implies to have a better scheme for identifying board than the
	inb (0x800) currently used.
	2) If we have residual, we may override some value by the
	value provided by the residual,
	3) If an openpic compliant interrupt controller is
	there we should use it.

My 2 cents,


-- 
   __                 
  /  `                   	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 ]]