On 11/15/06, Dan Mick <[EMAIL PROTECTED]> wrote:
Cyril: Which device is this, and is its spec freely available?
I am not sure the spec is free - I'll check it.
And it appears to me now (after some additional research I did
on that) that it is BIOS fault/feature. It is BIOS that were to program
the vensor specific bit during initialization. Does it makes sense ?
Dan Mick wrote:
> Cyril Plisko wrote:
>> 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 ?
>
> Yes, but the problem is that's a multi-step process. First, the BAR has
> to be programmed with the base address of the physical region allocated
> for it; then, ddi_regs_map_setup() assigns a virtual address to that
> physical address. The latter is what most people mean by "mapping", but
> it's not going to happen without the first stage happening, which
> involves global resource allocation.
>
> (and, apparently, on this device, before all *that*, some
> device-specific register must be written to even make the BAR appear.)
>
>>> 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 ?
>
> If I knew for certain, I wouldn't say "I bet", but, "I bet".
>
>>> 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 ?
>
> yes; that's the global PCI enumerator and resource allocator.
>
>> 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 ?
>
> No, that's just assigning address space to BARs that are present but not
> written to non-zero (physical) base addresses. This is one step
> further, in that the BAR doesn't even appear to be present until
> device-specific code runs.
>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
--
Regards,
Cyril
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
