On 11/14/06, Dan Mick <[EMAIL PROTECTED]> wrote:
>> 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
well, "map this BAR" is ambiguous. Physical memory space needs to be
Hm, by "map this BAR" I mean that I want ddi_regs_map_setup() call to succeed.
Is it less ambiguous now ?
carved out from the memory map of the machine, of a length appropriate for
the registers on the card. I've no idea how a generic PCI enumerator is
supposed to handle such an abomination.
Abomination is strong word, but it, probably, appropriate here...
>
>> 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.
or other OSes, I bet.
I lack a relevant experience to say that for other OSes.
Would, say, Linux have similar problems with such a device ?
The only thought that comes to mind is a device-specific hack in the
generic allocation routines.
I am willing to invest some time into hacking this, what would be the
place to start looking at (from your experience) ? pci_autoconfig ?
when my laptop boots it spits the following message to /var/adm/messages.
Nov 14 08:54:54 zulu pci_autoconfig: [ID 771164 kern.info] NOTICE:
reprogram pci device [0/2/1] (pci1014,582)
Does it mean that similar hacks are already exist in pci_autoconfig ?
--
Regards,
Cyril
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
