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? Rafael -- 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
