[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[pbsd-mg2] GIU-ISA bridge
> それと、vrip自身のattachの時にというのは、Vr41x1自体の実装が異なるも
> のを振りわける必要があるということでしょうか?
かなり先の話になりますがMIPS 系の chip で全然別の周辺 I/O を入れた
ものなど。
VR 以外の MIPS 系の CPU のマシンも将来的にはサポートしたいですから。
(いつ頃かとか聞かないでくださいB-)
> vrgiubusじゃなく、ISA-busにしてしまうのはどうなんでしょう?
platform ごとの振り分けとは関係なく、ISA-bus になっていると
いいこともあるような気がします。
(かなり前に流した to-do にも一応いれてはあったのですが...)
> うか...。GPIOのポート番号と、PCICの理解するIRQのマッピングがいやらしい
> かなと感じてるんですが...
目的のデバイスから IRQ ラインが何本出ているか、
それが GIU のポートに何本接続されているか、でいろいろな
場合が考えられます。
● 1-1
単純に直結されている場合、現在の vrgiu でも、ISA-bus でも
問題ありません。ロケータ「irq」に GIU 側のポート番号を
書けばいい。
● N-1
デバイス側の IRQ 出力が複数あって、それらが OR されて
GIU 側のただ一つの port に接続されている。
デバイス側の N が固定ならば前述の 1-1 の場合と同じです。
N が固定でない場合(pcic は固定でない)や単純な
OR ではない場合は厄介です。
● N-N
デバイス側の IRQ 出力が複数あって、それらが個別に
GIU 側の port に接続されている。
デバイス側と GIU 側の接続が固定でも、
ロケータが N 個必要になってしまって、足りなくなります。
非常に厄介です。
N-1 または N-N の場合で、しかも、接続は platform 毎に
ことなります。
pcic_vrgiu.c 内で platform ID で場合分けして、hard cording し
ようと考えていました。
今のところ、Everex も MC-R も irq=3 で済んでいるみたいなので
(irq=3 は通常 pcic の何本かある irq のうち、最も番号が小さいもの)
ISA-bus で pcic_isa.c でももいいような気もしますが、
この先、へんな奴が出てくると破綻するような気がします。
# pcic_isa.c って、 同じ irq=3 にいくつも handler を establish
#できますか?
Takemura