In article <43FD9754.2050902@netbsd.org>
shige@NetBSD.org wrote:

> I'm working on a port to Alchemy Au1550 and OpenMicroServer(OMS-AL400).
> OpenMicroServer is a small server box (sold at Japan).

I also ordered it a few days ago (though I have not received yet).

> On OMS-AL400, DBAU1550 code works fine. Thanks, Garrett!

Good news. How about PCI devices (wm and ehci)?

> PSC on Au1550 supports multi-protocols (SMBus, AC97, I2S, SPI).
> I think that we needs two-layer driver.
> One is for hardware controller layer, other is for protocol layer.

Well, with a quick glance at the Au1550 manual, it seems
there is few common "hardware controller layer" part on PSC ports.
The only common registers are the PSC protocol select register
and the PSC controll register, and all other registers seems
switched by protocols. So I guess the only work which should be
done in the common layer is to probe/select protocols on each
PSC port and pass bus space tag to upper layer.

If we can assume each PSC ports are initialized by the firmware
properly, we can read the protocol select register to probe
which protocol is selected. In this case the kernel config could be:

aupsc* at aubus?
ausmbus* at aupsc?
smbus* at ausmbus?

or so. aupsc_attach() should call config_search_ia() for each
probe function, and ausmbus* (and other children) should
read the select register in its probe function, and initialize
registers for its protocol and prepare softc structure
(including bus space tag or access functions etc.) passed to
MI protocol layer in the attach function.
(though we don't have the MI smbus driver (yet?))

If we can't use firmware settings, maybe we have to specify protocol
explicitly in the kernel config:

aupsc0 at aubus? addr 0x11a00000
ausmbus0 at aupsc0
smbus* at ausmbus0

In this case, ausmbus_match() (and other children) always matches.

But we should implement smbus and RTC drivers first
because logical layers for device configuration could be
changed later, IMHO.
---
Izumi Tsutsui