Re: ibm4xx pci (Re: IBM405GP/GPr OPB bus_space endian (powerpc/ibm4xx/dev/opb.c))

[Shigeyuki Fukushima <shige%netbsd.org@localhost>]

Izumi Tsutsui wrote:
>>> 1. we need to make an arrangement for a pchb driver.
>>>    ibm4xx/pci/pchb.c + ibm4xx/pci/pci_machdep.c + ibm4xx/dev/ibm405gp.c
>>>     -> ibm4xx/dev/pchb.c
> 
> With a quick grance, it seems okay to merge current ibm4xx/pci/pchb.c
> and ibm4xx/pci/pci_machdep.c, but I'm not sure whether ibm405gp.c
> could be merged.
> How can we handle any ibm405gp (or other cpu) specific stuff
> in a merged source?

With a quick grance of datasheets, perhaps we can use a common
pci implementaion for other 405xx and 440xx (having PCI 2.2 in
the processor).
I don't know the details about PCI-X (in the processor).
We may develop another driver for PCI-X Host-Bridge, ok?

If there are cpu specific stuff, we should prepare struct
ibm4xx_pci_chipset global variables per cpu.
Of course, we should add some members to struct ibm4xx_pci_chipset.


>>> 2. we need to tell pchb.c driver some configurations
>>>    (#defines with IBM405GP_ in *.c) by another way.
> 
> Do you say about pcicfg_tag in current ibm405gp.c?
> If pcicfg_tag is the only 405gp specific stuff in ibm405gp.c,
> we could change ibm4xx_setup_pci() to take some arguments
> to specify pcicfg_tag (or some other CPU or machine
> dependent values).

Yes.

>>> 3. we need to reconsider about machine dependent pci function.
>>>    What (pci_) functions shoud be in evbppc/<mach>/*.c?
>>>    pci_intr_map() and pci_conf_interrupt() had been already moved.
> 
> If we should have multiple pci(9) implementation in a single port,
> we can define pci_*(9) functions as macros which use indirect call
> with pci_chipset_tag_t in include/pci_machdep.h. In this case,
> all pci(9) functions could be in chipset dependent files.
> (see alpha/include/pci_machdep.h and alpha/pci/*.c)
> 
> I guess interrupt stuff and conf_hook might be machine (board)
> specific and configuration read/write stuff (with tag/dev/func etc.)
> might be chipset dependent, but I think it's better to summarize
> what variants (chipset/board combinations) we would have among
> all ibm4xx ports.

Ok.
I agree the way of alpha ports.

>>> 4. Is some global variables related bus_space_* ugly? or reasonable?
>>>    Should they be in pci_chipset_tag_t (struct ibm4xx_pci_chipset) ?
>>>    If need, define pchb_softc included pci_chipset_tag_t ?
> 
> I'm not sure what is your actual concern, but some bus_space_*
> values are required before autoconf(9) is started (to initialize
> console devices for example), so we can't allocate all of them in
> softc and it's okay to have some globals in that case.
> Once after autoconf(9) is started, we can put bus_space_* values
> (maybe they are pointers) to the globals into softc or
> pci_chipset_tag_t etc, though.

In my guess, some global bus_space_* might happen
by splitting a pci driver to 3 files.

If some must be globals, which must be global?
We really need to suppose that case on ibm4xx ports?

The current globals are the following:
  1. struct powerpc_bus_space pchb_io_tag;
  2. struct powerpc_bus_space pchb_mem_tag;
  3. struct powerpc_bus_space pci_iot;  /* PCI Configuration */
  4. struct powerpc_bus_space pcicfg_tag; /* PCI local configuration */


> Anyway, it isn't easy to clean up all stuff at once,
> so it's better to leave cosmetics/trivial part for now, IMO.

Ok. I will start with 3).

-- 
Kind Regards,
--- shige
Shigeyuki Fukushima <shige@{FreeBSD,jp.FreeBSD,NetBSD}.org>