On Wed, May 18, 2016 at 4:25 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> On Wed, May 18, 2016 at 5:54 PM, Aaron Durbin <adurbin@xxxxxxxxxx> wrote:
>> Hi,
>>
>> We're currently running into a problem of resource conflicts with a
>> PCI device and ACPI devices.
>>
>> [ 0.243534] pci 0000:00:0d.0: can't claim BAR 0 [mem
>> 0xd0000000-0xd0ffffff 64bit]: address conflict with INT3452:03 [mem
>> 0xd0c00000-0xd0c03fff]
>>
>> The PCI BAR covers a large amount mmio resources, however, there are
>> ACPI devices with their own HID (for probing) which uses resources
>> that are a subset of the PCI BAR.
>>
>> Short of re-structuring the linux driver is there anything that can be
>> done with ASL to properly have the ACPI device use a sub-resource of
>> the PCI device during the ACPI/PCI probing?
>
> Do you have an ACPI device object corresponding to the PCI device?
I've been debugging this by proxy, and I did request that test. The
following is the overall structure:
scope (\_SB.PCI0) {
Device (P2S)
{
Name (_ADR, 0x000D0000)
Device (GPO0)
{
Name (_ADR, 0)
Name (_HID, "INT3452")
Name (_CID, "INT3452")
}
}
}
There are _STA methods in both Devices. The GP0 device has a _CRS
method which just returns a ResourceTemplate which is filled in with
static values. The PCI bar is at a fixed address from the firmware
which allows the fixed calculations. However there is no specific
reference to the P2S device's resources proper -- only the parent
child relationship within the ASL. I'm not sure how to directly say "I
want this sub-region of this other device's resource for my resource."
That seems like the right thing, but it's not clear if that's implied
by hierarchy of the devices.
Lastly, if it helps, the kernel being used is based on v4.4 (no core
patches on top).
Thanks.
-Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
