Changing how PCI-PCI bridges do resource allocation

[Alexander Motin]

On 27.04.2011 18:01, John Baldwin wrote:
> On Tuesday, April 26, 2011 5:54:34 pm Alexander Motin wrote:
>> John Baldwin wrote:
>>> On Tuesday, April 26, 2011 10:45:33 am Alexander Motin wrote:
>>>> John Baldwin wrote:
>>>>> On Tuesday, April 26, 2011 2:53:24 am Alexander Motin wrote:
>>>>>> On 26.04.2011 00:21, John Baldwin wrote:
>>>>>>> On Monday, April 25, 2011 3:09:47 pm John Baldwin wrote:
>>>>>>>> On Wednesday, April 20, 2011 4:38:30 am Alexander Motin wrote:
>>>>>>>>> On 19.04.2011 21:50, John Baldwin wrote:
>>>>>>>>>> I've already had at least one testing report that this fixes the issues with
>>>>>>>>>> some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI
>>>>>>>>>> is enabled as this code re-discovers the original windows and programs them
>>>>>>>>>> correctly.  More testing would be good however.
>>>>>>>>> I would like this helped my Acer TM6292 which also has alike problems
>>>>>>>>> with missing PCIe bridge resources, but unluckily it doesn't.
>>>>>>>>>
>>>>>>>>> Here is verbose dmesg when my system uses this dirty hack:
>>>>>>>>> http://people.freebsd.org/~mav/tm6292_pcie.patch
>>>>>>>>>     to restore bridges resources to the pre-ACPI state:
>>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.hacks
>>>>>>>>>
>>>>>>>>> Here is respective `pciconf -lvcb` output:
>>>>>>>>> http://people.freebsd.org/~mav/pciconf.hacks
>>>>>>>>>
>>>>>>>>> Here is dmesg with patches, but without NEW_PCIB:
>>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.olbpcib
>>>>>>>>>
>>>>>>>>> Here is dmesg with patches with NEW_PCIB:
>>>>>>>>> http://people.freebsd.org/~mav/dmesg.boot.newpcib
>>>>>>>> Ah, your problem is we pick bad ranges when we alloc fresh resources for your
>>>>>>>> bridges.  I am working on making that better for ACPI, but for now you can try
>>>>>>>> setting hw.acpi.host_mem_start to a value like '0xf0000000' in loader.conf.
>>>>>>>>
>>>>>>>> Although, it looks like it is not being honored currently.  Try adding a printf
>>>>>>>> in acpi_pcib_alloc_resource() in sys/dev/acpica/acpi_pcib_acpi.c to log the
>>>>>>>> type, start, and end of each resource range.
>>>>>>> Actually, try this patch.  Then I think you can use the host_mem_start tunable:
>>>>>> I've tried it. With this patch host_mem_start tunable seems like makes
>>>>>> effect. Numbers look closer, but bge0 and iwn0 beyond the bridges are
>>>>>> still not working.
>>>>> Hmmm, I think I need to clear the completely bogus windows when we fail to
>>>>> allocate the initial window.  Try this (relative to the previous patches):
>>>> Dmesg changed a bit, but still no luck:
>>>> http://people.freebsd.org/~mav/newpcib/dmesg.next
>>>
>>> Oh, I'm dumb.  'w->base' should be set to 'max_address' and 'w->limit' should
>>> be set to 0 to turn off the bogus windows like this:
>>
>> No luck:
>> http://people.freebsd.org/~mav/newpcib/dmesg.next2
>
> Ahh, I know what's wrong.  I need to force MEMEN and/or IOEN in the bridge's
> command register when enabling a window.  Here is an updated patch relative
> to pcib_window.patch (so it includes the previous patch to disable bogus
> windows):

Hurray! You did it! Congratulations! :)

After changing
	PCI_ENABLE_IO(device_get_parent(sc->dev), dev, type);
to
	PCI_ENABLE_IO(device_get_parent(sc->dev), sc->dev, type);
to fix the build I've got working devices:
http://people.freebsd.org/~mav/newpcib/dmesg.working

By the way, it also works without setting host_mem_start. Just uses 
different addresses for bge, iwn and the bridges.

Thank you!

-- 
Alexander Motin