On Fri, Apr 10, 2015 at 12:37 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > On Thursday, April 09, 2015 05:00:08 PM Bjorn Helgaas wrote: >> On Thu, Apr 9, 2015 at 4:37 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >> > On Thursday, April 09, 2015 10:50:02 AM Jiang Liu wrote: >> >> On 2015/4/9 7:44, Rafael J. Wysocki wrote: >> >> > On Wednesday, April 08, 2015 01:48:46 PM Jiang Liu wrote: >> >> >> On 2015/4/7 8:28, Rafael J. Wysocki wrote: >> >> >>> On Friday, April 03, 2015 10:04:11 PM Bjorn Helgaas wrote: >> >> >>>> Hi Jiang, >> >> >> <snip> >> >> >>>>> Currently acpi_dev_filter_resource_type() is only used by ACPI pci >> >> >>>>> host bridge and IOAPIC driver, so it shouldn't affect other drivers. >> >> >>>> >> >> >>>> We should assume it will eventually be used for all ACPI devices, >> >> >>>> shouldn't we? >> >> >>> >> >> >>> I'm not sure about that, really. In fact, I'd restrict its use to devices >> >> >>> types that actually can "produce" resources (ie. do not require the resources >> >> >>> to be provided by their ancestors or to be available from a global pool). >> >> >>> >> >> >>> Otherwise we're pretty much guaranteed to get into trouble. >> >> >>> >> >> >>> And all of the above rules need to be documented in the kernel source tree >> >> >>> or people will get confused. >> >> >> Hi Rafael, >> >> >> How about following comments for acpi_dev_filter_resource_type()? >> >> >> Thanks! >> >> >> Gerry >> >> >> -------------------------------------------------------------------- >> >> >> /** >> >> >> * According to ACPI specifications, Consumer/Producer flag in ACPI resource >> >> >> * descriptor means: >> >> >> * 1(CONSUMER): This device consumes this resource >> >> >> * 0(PRODUCER): This device produces and consumes this resource >> >> >> * But for ACPI PCI host bridge, it is interpreted in another way: >> >> > >> >> > So first of all, this leads to a question: Why is it interpreted for ACPI PCI >> >> > host bridges differently? >> >> > >> >> > Is it something we've figured out from experience, or is there a standard >> >> > mandating that? >> >> Hi Rafael, >> >> I think we got this knowledge by experiences. PCI FW spec only >> >> states _CRS reports resources assigned to the host bridge by firmware. >> >> There's no statement about whether the resource is consumed by host >> >> bridge itself or provided to it's child bus/devices. On x86/IA64 side, >> >> the main resource consumed by PCI host bridge is IOPORT 0xCF8-0xCFF, >> >> but not sure about ARM64 side. So how about: >> > >> > This: >> > >> >> PCI Firmware specification states that _CRS reports resources >> >> assigned to the host bridge, but there's no way to tell whether >> >> the resource is consumed by host bridge itself or provided to >> >> its child bus/devices. >> > >> > looks OK to me, but I'd replace the below with something like: >> > >> > "However, experience shows, that in the PCI host bridge case firmware writers >> > expect the resource to be provided to devices on the bus (below the bridge) for >> > consumption entirely if its Consumer/Producer flag is clear. That expectation >> > is reflected by the code in this routine as follows:". >> >> What a mess. The spec is regrettably lacking in Consumer/Producer >> specifics. But I don't see what's confusing about the descriptors >> that have Consumer/Producer bits. >> >> QWord, DWord, and Word descriptors don't seem to have a >> Consumer/Producer bit, but they do contain _TRA, so they must be >> intended for bridge windows. Can they also be used for device >> registers? I don't know. >> >> The Extended Address descriptor has a Consumer/Producer bit, and I >> would interpret the spec to mean that if the flag is clear (the device >> produces and consumes this resource), the resource is available on the >> bus below the bridge, i.e., the bridge consumes the resource on its >> upstream side and produces it on its downstream side. > > OK, that makes sense for bridges. > >> If the bit were >> set (the device only consumes the resource), I would expect that to >> mean the descriptor is for bridge registers like 0xcf8/0xcfc that >> never appear on the downstream side. > > That part is clear. What is not clear is whether or not we can *always* > expect the resources with Consumer/Producer *clear* to be produced on the > downstram side. That appears to be the case for host bridges if my > understanding of things is correct, but is it the case in general? > >> Maybe I'm reading the spec too naively, but this doesn't seem a matter >> of experience. > > Well, the specification is not clear enough in that respect, at least as > far as I can say, or maybe it is, but then does firmware always follow that > interpretation? So I guess I'd like to propose to go back to the 3.19 behavior for PCI host bridges and then to handle the IOAPIC as a separate case. We can think about consolidating the two later. Any objections to doing that? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
