Izumi Tsutsui wrote:
> In article <43FDE116.8010506@netbsd.org>
> shige@NetBSD.org wrote:
>
>   
>> Almost Ok.
>> But Attaching wm0 failed. Hummmm...
>> kiyohara's OMS-AL400 works fine.
>>     
>
> Hmm, bad firmware revision (PCI space is not mapped properly)?
> pci_configure_bus(9) is recommended?
> Anyway, info by options PCI_CONFIG_DUMP may help.
>   
Possibly, but could also be that I don't have good IDSEL/interrupt
information.  That would cause an attach failure.

I believe the DBAU1550 sample config uses pci_configure_bus(9) -- it is
pretty much required for any YAMON board because YAMON doesn't
initialize PCI space at all.  (I have a version of YAMON that I've
hacked to do so, but I don't think I can give that away.)

    -- Garrett
>   
>>> aupsc* at aubus?
>>> ausmbus* at aupsc?
>>> smbus* at ausmbus?
>>>       
>> Is the role of aupsc device only switching/selecting protocols?
>>     
>
> Yes, and it will search children via config_found(9) etc.
>
>   
>> Is the following kernel config bad idea??
>>
>> aupsc* at aubus?
>> audio* at aupsc?
>> spi* at aupsc?
>> i2s* at aupsc?
>> smbus* at aupsc?
>>     
>
> audioprobe() and audioattach() require struct audio_attach_args,
> and other children may require their own attach args.
> There is no way to switch attach args in aupsc_attach(),
> i.e. smbus and audio should have differnt parents with
> proper attributes (audiobus etc.), I think.
> Or we could probe each psc as a different device per its
> configuration like:
>
> pscaudio* at aubus?
> audio* at pscaudio?
> pscsmbus* at aubus?
> smbus* at pscsmbus?
>  :
> ---
> Izumi Tsutsui
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191