quoted

quoted

quoted

quoted

"Cort" == Cort Dougan [off-list ref] writes:

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

Cort> Before you get too grumpy please realize I don't have any of the newer
Cort> boards.  I only have the "old interrupt" routing scheme boards to work
Cort> with first hand.  If someone wants to get to me 1) the newer boards or 2)
Cort> some code that handles both well I'd be more than happy to redo the
Cort> routing.  prep_pci.c has been a nasty piece of code for some time.

You can detect the raven. Gabriel has code for this for weeks...
You can detect you are on a motorola board also. Those two leads to 
have ppcbug and a valid PCI configuration. If furthermore, you
decide to use the openpic feature provided by the raven, then
you can translate the value. I have code working (mostly Gabriel code
+ some patches).

Besides I would like you to point out boards were PCI configuration
registers are wrong as they are initialized on reset... I think
those board are not PCI 2.x compliant and probably you can't even buy
them anymore...

In any case, if code for old boards is a mess but still needed for
many good reasons, then put it under a config variable and at least 
let clean code exist for newer boards that may work for any 
recent/upcoming board...

CONFIG_RESIDUAL Comes in mind
CONFIG_PCI_CONFIG_ON_RESET_OK also
CONFIG_OPEN_PIC also...

If you mange to have table for indirect calls this is evn better :)

eric>	1) we should know wether the board firmware correctly
eric>	set up the PCI devices. If this is the case, the old
eric>	interrupt scheme must be removed. Note that this
eric>	implies to have a better scheme for identifying board than the
eric>	inb (0x800) currently used.

Cort> That's right, we should keep the setup if it's correct.  Find me a better
Cort> scheme for identifying the board, then.

For motorola, use the sytem configuration register at physaddr 0xfef80400 for
example. I do not know all the boards but probably someone at motorola could 
make suggestions as I bet PPCBUG has code to make it :)

I think  correct board dentification is a key point for code
portability/autoconfiguration. Not working on this item will
prevent any good restructuration as adding code for one board will
break another...



-- 
   __                 
  /  `                   	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@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@lists.linuxppc.org ]]