Garrett D'Amore wrote: > Cyril Plisko wrote: >> Hi, >> >> Here is the story: >> I am writing [solaris] driver for a PCI device. Should be a simple task, >> but there is a catch - in the PCI configuration space there is a region >> of vendor registers above all the standard registers. In order to have >> one >> of the BARs accessible I need to tinker with one of the vendor registers. >> That's according to the device spec. >> The question is what should I do in Solaris - by the time my attach entry >> point has a chance to map PCI config space and fix that register all >> the BARs are scanned by the parent PCI bus driver. So if one of them >> becomes "alive" all of a sudden it will not be noticed, right ? >> So, is there any way to force the PCI nexus driver to recheck my config >> space ? >> >> I have to say I never saw such behaviour, so I am quite puzzled with it. >> Any ideas ? >> > > You can do this with pci_config_setup, and pci_config_put[8,16,32], > pci_config_get[8,16,32] > > PCI configuration space is is a fixed 64-register wide (IIRC) space, and > I expect the Solaris PCI code probably just maps the whole thing up. So > it should all "just work". :-) > > That is assuming that your device is compliant and doesn't stick any > registers _outside_ the allowed region for per-device/function registers.
It sounds like Cyril has a bigger problem - his device has a Base Address Register which isn't present when the device is enumerated (and possibly programmed on x86/x64). By the time he gets around to enabling this additional BAR, it's long after the enumeration of PCI devices is done. Cyril, what happens when you enabled this BAR - presumably it needs resources allocated to it? Does the device work in a degraded mode without this register enabled? Dana _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
