Cyril Plisko wrote: > On 11/14/06, Dana H. Myers <[EMAIL PROTECTED]> wrote:
>> 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. > > That is exactly what happens. > >> >> Cyril, what happens when you enabled this BAR - presumably it needs >> resources allocated to it? > > Yes, I need to map this BAR. If that is what you mean by allocating > resources > >> Does the device work in a degraded mode without this register enabled? > > It is more like the device is doing something else. This vendor specific > register has far reaching implication. When I set the bit I want, not only > additional BAR appears, but even PCI subclass is changing reflecting > the fact that device has new capability. > > I think the designers of that hardware assumed that tinkering with the > vendor specific register and enumeration is done as one step, but > with Solaris that is not true. That seems pretty odd; I'm wondering if even Windows requires some special magic to make this work, though my guess is that hot-plug configuration is involved. As for a Solaris solution for this, I tend to think some sort of hot-plug scheme would be the path of least resistance (which is not to say it is easy). Basically, once the "hidden" BAR is enabled, the device would need to be "unplugged" (not physically, but from the devinfo tree) and "inserted", and the BAR resources allocated and assigned. You could probably use the same device driver, which would have to detect whether the hidden BAR is enabled or not, and do the right thing. Automating this is the next trick; perhaps SMF is helpful here. At least that's my thinking off the top of my head; I haven't given it any deep thought. I don't know how implementable this is, but there certainly is hot-plug framework in Solaris. Perhaps Dan (Mick) has something more inspirational :-) Dana _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
