All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-08-01 11:31 Rudi
  0 siblings, 0 replies; 11+ messages in thread
From: Rudi @ 2010-08-01 11:31 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

Hi all,

is that still in the agenda ? Also, what is the reason why the last
parameter of AcpiOsDerivePciId() is "ACPI_PCI_ID **" and not just
"ACPI_PCI_ID *" ? Are there any situations, where AcpiOsDerivePciId
would want to reallocate PciId ?




Lin Ming wrote:
> 2010/4/22 Grégoire Sutre <gregoire.sutre(a)gmail.com>:
>> Hi Lin,
>>
>> Many thanks for your explanantion, I understand now why the second
>> argument passed to AcpiOsDerivePciId is a handle to the (PCI_Config)
>> operation region.
>>
>> But regarding the first argument of AcpiOsDerivePciId: the ACPICA
>> programmer reference says that: it is a handle to _the PCI device_.
>>
>> My question is: which PCI device?
>>
>> In my (possibly wrong) interpretation of the documentation, _the PCI
>> device_ is the device for which AcpiOsDerivePciId shall return an
>> updated Pci id.
>>
>> However, as far as I understand the code of AcpiEvPciConfigRegionSetup
>> (in file evrgnini.c), _the PCI device_ turns out to be an ancestor of
>> the device for which AcpiOsDerivePciId shall return an updated Pci id.
>> This ancestor being the upstream PCI root bridge (or the ACPI root node
>> if none was found).  This interpretation of _the PCI device_ is also
>> consistent with my understanding of the Linux implementation of
>> AcpiOsDerivePciId, which finds the updated PCI id by ``traversing'' the
>> PCI-to-PCI bridges that are on the branch from AcpiOsDerivePciId's first
>> argument to its second argument.
> 
> You are right, the first argument is the PCI root node.
> We may need to update the doc to figure out this.
> 
> Thanks,
> Lin Ming
> _______________________________________________
> Devel mailing list
> Devel(a)acpica.org
> http://lists.acpica.org/listinfo/devel
> 
> To: gregoire.sutre(a)gmail.com
> Cc: devel(a)acpica.org

-- 

Ruediger "Rudi" Ihle

"There's a fine line between wrong and visionary. Unfortunately
 you have to be a visionary to see it." - Sheldon Cooper, Ph.D.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-08-04 23:33 Moore, Robert
  0 siblings, 0 replies; 11+ messages in thread
From: Moore, Robert @ 2010-08-04 23:33 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 4934 bytes --]

Sorry, now to address your original question.

The AcpiOsDerivePciId interface was driven primarily by the needs of Linux, during the time that the Linux PCI-to-ACPI interaction was being designed and implemented.

I suspect that the ** was needed for the original implementation and then became obsolete later.

To my knowledge, we have never been asked to change the interface, so it has remained as-is.

Since AcpiOsDerivePciId is going to go away soon (we have the code running already), we will of course make the equivalent internal interface as simple as possible.

Bob


>-----Original Message-----
>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>Of Moore, Robert
>Sent: Wednesday, August 04, 2010 2:37 PM
>To: Rudi
>Cc: devel(a)acpica.org
>Subject: Re: [Devel] Error in documentation of AcpiOsDerivePciId?
>
>Yes, there is a reason for ACPI_PCI_ID **.
>
From the ACPI Component Architecture User Guide and Programmer Reference:
>
>
>AcpiOsDerivePciId
>-----------------
>
>PciId
>
>Input: The full PCI ID (The full PCI configuration space address,
>consisting of a segment number, bus number, device number, and function
>number) as obtained from control methods within the BIOS ACPI tables.
>
>Output: Where the derived PCI ID is returned. Some or all of the PCI ID
>subfields may be updated by this function.
>
>
>
>This function derives a full PCI ID for a PCI device, consisting of a
>Segment number, a Bus number, and a Device number.
>
>The PCI hardware dynamically configures PCI bus numbers depending on the
>bus topology discovered during system initialization. The AcpiOsDerivePciId
>function is invoked by the ACPICA subsystem during configuration of a
>PCI_Config Operation Region in order to (possibly) update the Bus number in
>the PciId with the actual Bus number as determined by the hardware and
>operating system configuration.
>
>The PciId parameter is initially populated by the ACPICA subsystem during
>the Operation Region initialization. ACPICA then calls AcpiOsDerivePciId,
>which is expected to make any necessary modifications to the Segment, Bus,
>or Device number PCI ID subfields as appropriate for the current hardware
>and OS configuration.
>
>
>
>>-----Original Message-----
>>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>>Of Rudi
>>Sent: Sunday, August 01, 2010 4:31 AM
>>Cc: devel(a)acpica.org
>>Subject: Re: [Devel] Error in documentation of AcpiOsDerivePciId?
>>
>>Hi all,
>>
>>is that still in the agenda ? Also, what is the reason why the last
>>parameter of AcpiOsDerivePciId() is "ACPI_PCI_ID **" and not just
>>"ACPI_PCI_ID *" ? Are there any situations, where AcpiOsDerivePciId
>>would want to reallocate PciId ?
>>
>>
>>
>>
>>Lin Ming wrote:
>>> 2010/4/22 Grégoire Sutre <gregoire.sutre(a)gmail.com>:
>>>> Hi Lin,
>>>>
>>>> Many thanks for your explanantion, I understand now why the second
>>>> argument passed to AcpiOsDerivePciId is a handle to the (PCI_Config)
>>>> operation region.
>>>>
>>>> But regarding the first argument of AcpiOsDerivePciId: the ACPICA
>>>> programmer reference says that: it is a handle to _the PCI device_.
>>>>
>>>> My question is: which PCI device?
>>>>
>>>> In my (possibly wrong) interpretation of the documentation, _the PCI
>>>> device_ is the device for which AcpiOsDerivePciId shall return an
>>>> updated Pci id.
>>>>
>>>> However, as far as I understand the code of AcpiEvPciConfigRegionSetup
>>>> (in file evrgnini.c), _the PCI device_ turns out to be an ancestor of
>>>> the device for which AcpiOsDerivePciId shall return an updated Pci id.
>>>> This ancestor being the upstream PCI root bridge (or the ACPI root node
>>>> if none was found).  This interpretation of _the PCI device_ is also
>>>> consistent with my understanding of the Linux implementation of
>>>> AcpiOsDerivePciId, which finds the updated PCI id by ``traversing'' the
>>>> PCI-to-PCI bridges that are on the branch from AcpiOsDerivePciId's
>first
>>>> argument to its second argument.
>>>
>>> You are right, the first argument is the PCI root node.
>>> We may need to update the doc to figure out this.
>>>
>>> Thanks,
>>> Lin Ming
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)acpica.org
>>> http://lists.acpica.org/listinfo/devel
>>>
>>> To: gregoire.sutre(a)gmail.com
>>> Cc: devel(a)acpica.org
>>
>>--
>>
>>Ruediger "Rudi" Ihle
>>
>>"There's a fine line between wrong and visionary. Unfortunately
>> you have to be a visionary to see it." - Sheldon Cooper, Ph.D.
>>_______________________________________________
>>Devel mailing list
>>Devel(a)acpica.org
>>http://lists.acpica.org/listinfo/devel
>_______________________________________________
>Devel mailing list
>Devel(a)acpica.org
>http://lists.acpica.org/listinfo/devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-08-04 21:36 Moore, Robert
  0 siblings, 0 replies; 11+ messages in thread
From: Moore, Robert @ 2010-08-04 21:36 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]

Yes, there is a reason for ACPI_PCI_ID **.

From the ACPI Component Architecture User Guide and Programmer Reference:


AcpiOsDerivePciId
-----------------

PciId	

Input: The full PCI ID (The full PCI configuration space address, consisting of a segment number, bus number, device number, and function number) as obtained from control methods within the BIOS ACPI tables.

Output: Where the derived PCI ID is returned. Some or all of the PCI ID subfields may be updated by this function.



This function derives a full PCI ID for a PCI device, consisting of a Segment number, a Bus number, and a Device number.

The PCI hardware dynamically configures PCI bus numbers depending on the bus topology discovered during system initialization. The AcpiOsDerivePciId function is invoked by the ACPICA subsystem during configuration of a PCI_Config Operation Region in order to (possibly) update the Bus number in the PciId with the actual Bus number as determined by the hardware and operating system configuration.

The PciId parameter is initially populated by the ACPICA subsystem during the Operation Region initialization. ACPICA then calls AcpiOsDerivePciId, which is expected to make any necessary modifications to the Segment, Bus, or Device number PCI ID subfields as appropriate for the current hardware and OS configuration.



>-----Original Message-----
>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>Of Rudi
>Sent: Sunday, August 01, 2010 4:31 AM
>Cc: devel(a)acpica.org
>Subject: Re: [Devel] Error in documentation of AcpiOsDerivePciId?
>
>Hi all,
>
>is that still in the agenda ? Also, what is the reason why the last
>parameter of AcpiOsDerivePciId() is "ACPI_PCI_ID **" and not just
>"ACPI_PCI_ID *" ? Are there any situations, where AcpiOsDerivePciId
>would want to reallocate PciId ?
>
>
>
>
>Lin Ming wrote:
>> 2010/4/22 Grégoire Sutre <gregoire.sutre(a)gmail.com>:
>>> Hi Lin,
>>>
>>> Many thanks for your explanantion, I understand now why the second
>>> argument passed to AcpiOsDerivePciId is a handle to the (PCI_Config)
>>> operation region.
>>>
>>> But regarding the first argument of AcpiOsDerivePciId: the ACPICA
>>> programmer reference says that: it is a handle to _the PCI device_.
>>>
>>> My question is: which PCI device?
>>>
>>> In my (possibly wrong) interpretation of the documentation, _the PCI
>>> device_ is the device for which AcpiOsDerivePciId shall return an
>>> updated Pci id.
>>>
>>> However, as far as I understand the code of AcpiEvPciConfigRegionSetup
>>> (in file evrgnini.c), _the PCI device_ turns out to be an ancestor of
>>> the device for which AcpiOsDerivePciId shall return an updated Pci id.
>>> This ancestor being the upstream PCI root bridge (or the ACPI root node
>>> if none was found).  This interpretation of _the PCI device_ is also
>>> consistent with my understanding of the Linux implementation of
>>> AcpiOsDerivePciId, which finds the updated PCI id by ``traversing'' the
>>> PCI-to-PCI bridges that are on the branch from AcpiOsDerivePciId's first
>>> argument to its second argument.
>>
>> You are right, the first argument is the PCI root node.
>> We may need to update the doc to figure out this.
>>
>> Thanks,
>> Lin Ming
>> _______________________________________________
>> Devel mailing list
>> Devel(a)acpica.org
>> http://lists.acpica.org/listinfo/devel
>>
>> To: gregoire.sutre(a)gmail.com
>> Cc: devel(a)acpica.org
>
>--
>
>Ruediger "Rudi" Ihle
>
>"There's a fine line between wrong and visionary. Unfortunately
> you have to be a visionary to see it." - Sheldon Cooper, Ph.D.
>_______________________________________________
>Devel mailing list
>Devel(a)acpica.org
>http://lists.acpica.org/listinfo/devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-08-02  0:29 Lin Ming
  0 siblings, 0 replies; 11+ messages in thread
From: Lin Ming @ 2010-08-02  0:29 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

On Sun, 2010-08-01 at 19:31 +0800, Rudi wrote:
> Hi all,
> 
> is that still in the agenda ? Also, what is the reason why the last
> parameter of AcpiOsDerivePciId() is "ACPI_PCI_ID **" and not just
> "ACPI_PCI_ID *" ? Are there any situations, where AcpiOsDerivePciId
> would want to reallocate PciId ?

Yes, this is in agenda.

Currently, AcpiOsDerivePciId is implemented by OS, but actually this
function can be OS independent. So we are implementing it in ACPICA,
once for every OS.

Any yes, the last parameter should be better to be "ACPI_PCI_ID *".
Thanks for the catch.

Lin Ming

> Lin Ming wrote:
> > 2010/4/22 Grégoire Sutre <gregoire.sutre(a)gmail.com>:
> >> Hi Lin,
> >>
> >> Many thanks for your explanantion, I understand now why the second
> >> argument passed to AcpiOsDerivePciId is a handle to the (PCI_Config)
> >> operation region.
> >>
> >> But regarding the first argument of AcpiOsDerivePciId: the ACPICA
> >> programmer reference says that: it is a handle to _the PCI device_.
> >>
> >> My question is: which PCI device?
> >>
> >> In my (possibly wrong) interpretation of the documentation, _the PCI
> >> device_ is the device for which AcpiOsDerivePciId shall return an
> >> updated Pci id.
> >>
> >> However, as far as I understand the code of AcpiEvPciConfigRegionSetup
> >> (in file evrgnini.c), _the PCI device_ turns out to be an ancestor of
> >> the device for which AcpiOsDerivePciId shall return an updated Pci id.
> >> This ancestor being the upstream PCI root bridge (or the ACPI root node
> >> if none was found).  This interpretation of _the PCI device_ is also
> >> consistent with my understanding of the Linux implementation of
> >> AcpiOsDerivePciId, which finds the updated PCI id by ``traversing'' the
> >> PCI-to-PCI bridges that are on the branch from AcpiOsDerivePciId's first
> >> argument to its second argument.
> > 
> > You are right, the first argument is the PCI root node.
> > We may need to update the doc to figure out this.
> > 
> > Thanks,
> > Lin Ming
> > _______________________________________________
> > Devel mailing list
> > Devel(a)acpica.org
> > http://lists.acpica.org/listinfo/devel
> > 
> > To: gregoire.sutre(a)gmail.com
> > Cc: devel(a)acpica.org
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-23 12:44 Lin Ming
  0 siblings, 0 replies; 11+ messages in thread
From: Lin Ming @ 2010-04-23 12:44 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

2010/4/22 Grégoire Sutre <gregoire.sutre(a)gmail.com>:
> Hi Lin,
>
> Many thanks for your explanantion, I understand now why the second
> argument passed to AcpiOsDerivePciId is a handle to the (PCI_Config)
> operation region.
>
> But regarding the first argument of AcpiOsDerivePciId: the ACPICA
> programmer reference says that: it is a handle to _the PCI device_.
>
> My question is: which PCI device?
>
> In my (possibly wrong) interpretation of the documentation, _the PCI
> device_ is the device for which AcpiOsDerivePciId shall return an
> updated Pci id.
>
> However, as far as I understand the code of AcpiEvPciConfigRegionSetup
> (in file evrgnini.c), _the PCI device_ turns out to be an ancestor of
> the device for which AcpiOsDerivePciId shall return an updated Pci id.
> This ancestor being the upstream PCI root bridge (or the ACPI root node
> if none was found).  This interpretation of _the PCI device_ is also
> consistent with my understanding of the Linux implementation of
> AcpiOsDerivePciId, which finds the updated PCI id by ``traversing'' the
> PCI-to-PCI bridges that are on the branch from AcpiOsDerivePciId's first
> argument to its second argument.

You are right, the first argument is the PCI root node.
We may need to update the doc to figure out this.

Thanks,
Lin Ming

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-22 12:50 
  0 siblings, 0 replies; 11+ messages in thread
From:  @ 2010-04-22 12:50 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Hi Lin,

Many thanks for your explanantion, I understand now why the second
argument passed to AcpiOsDerivePciId is a handle to the (PCI_Config)
operation region.

But regarding the first argument of AcpiOsDerivePciId: the ACPICA
programmer reference says that: it is a handle to _the PCI device_.

My question is: which PCI device?

In my (possibly wrong) interpretation of the documentation, _the PCI
device_ is the device for which AcpiOsDerivePciId shall return an
updated Pci id.

However, as far as I understand the code of AcpiEvPciConfigRegionSetup
(in file evrgnini.c), _the PCI device_ turns out to be an ancestor of
the device for which AcpiOsDerivePciId shall return an updated Pci id.
This ancestor being the upstream PCI root bridge (or the ACPI root node
if none was found).  This interpretation of _the PCI device_ is also
consistent with my understanding of the Linux implementation of
AcpiOsDerivePciId, which finds the updated PCI id by ``traversing'' the
PCI-to-PCI bridges that are on the branch from AcpiOsDerivePciId's first
argument to its second argument.

Thanks for your help,

Grégoire


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-21 23:33 Lin Ming
  0 siblings, 0 replies; 11+ messages in thread
From: Lin Ming @ 2010-04-21 23:33 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 6029 bytes --]

On Wed, 2010-04-21 at 00:07 +0800, Grégoire Sutre wrote:
> Hi Robert,
> 
> First I want to thank you for your answer.
> 
> > It looks to me that the documentation (ACPICA programmer reference) is correct.
> > 
> > However, the acpiosxf.h file uses names that don't match the documentation and are not very descriptive.
> > 
> > The ACPICA code uses a variable named "PciRootNode" for the "DeviceHandle" parameter, that is ok.
> 
> The call to AcpiOsDerivePciId that I mentioned is performed in the
> function AcpiEvPciConfigRegionSetup of events/evrgnini.c.  Looking at
> this function (from acpica unix source code release 20100331), I see
> that:
> 
> - RegionObj->Region.Node is the PCI device node that we are interested

No, RegionObj->Region.Node is the region's containing namespace node,
for example below ASL code

Device(D000)
{
	OperationRegion (PMIO, SystemIO, 0x1000, 0x80)
}

RegionObj->Region.Node is the node of "PMIO".
Region object is RegionObj->Region.Node->Object

>    in.  This is confirmed by the part that finds the parent device
>    object, which starts with:
>    PciDeviceNode = RegionObj->Region.Node;

385     PciDeviceNode = RegionObj->Region.Node;
386     while (PciDeviceNode && (PciDeviceNode->Type != ACPI_TYPE_DEVICE))
387     {
388         PciDeviceNode = AcpiNsGetParentNode (PciDeviceNode);
389     }

See, it gets the parent node.
As above example, the parent node of PMIO is D000

> 
> - PciRootNode is the PCI root bridge upstream of the PCI device node
>    that we are interested in.  Indeed, there is a while-loop that walks
>    the ancestors of the PCI device node until a PCI root bridge is found,
>    iteratively assigning PciRootNode to these ancestors.  See lines 312
>    to 360.
> 
> This is the reason why I believe that in the call
> 
> AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
> 
> - PciRootNode is not a handle to the PCI device, it is a handle to its
>    upstream PCI root bridge, and
> - RegionObj->Region.Node is a handle to the PCI device.
> 
> >> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
> > 
> >> AcpiOsDerivePciId(
> >>    ACPI_HANDLE		PciRootHandle
> >>    ACPI_HANDLE		DeviceHandle
> >>    ACPI_PCI_ID		**PciId)
> > 
> > 
> > No, I don't think so. The second parameter is a handle to a region object.
> 
> In the above call to AcpiOsDerivePciId, the second parameter, which is
> RegionObj->Region.Node, is of type (ACPI_NAMESPACE_NODE *).  I'm not
> familiar with all the ACPI types, but I guess that this type is not for
> region objects.

Region has a node and the "object" is attached under the node.

> 
> Note that the implementation of AcpiOsDerivePciId in the linux kernel
> (as well as in the freebsd and netbsd kernels) seem to understand its
> interface in the same way as I did.
> 
> http://lxr.linux.no/#linux+v2.6.33/drivers/acpi/osl.c#L689

 632 static void acpi_os_derive_pci_id_2(acpi_handle rhandle,        /* upper bound  */
 633                                     acpi_handle chandle,        /* current node */
 634                                     struct acpi_pci_id **id,
 635                                     int *is_bridge, u8 * bus_number)
 636 {
 637         acpi_handle handle;
 638         struct acpi_pci_id *pci_id = *id;
 639         acpi_status status;
 640         unsigned long long temp;
 641         acpi_object_type type;
 642 
 643         acpi_get_parent(chandle, &handle);
 644         if (handle != rhandle) {
 645                 acpi_os_derive_pci_id_2(rhandle, handle, &pci_id, is_bridge,
 646                                         bus_number);

Check Linux code, chandle is the region node.
See line 643, it gets the parent node of region node first and then go
on...

Lin Ming

> 
> Best regards,
> 
> Grégoire
> 
> >> -----Original Message-----
> >> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
> >> Of Grégoire Sutre
> >> Sent: Tuesday, April 20, 2010 2:46 AM
> >> To: devel(a)acpica.org
> >> Subject: [Devel] Error in documentation of AcpiOsDerivePciId?
> >>
> >> Hi list,
> >>
> >> According to the ACPICA Programmer Reference, the function
> >> AcpiOsDerivePciId takes as arguments:
> >>
> >> AcpiOsDerivePciId(
> >>    ACPI_HANDLE		DeviceHandle
> >>    ACPI_HANDLE		PciRegionHandle
> >>    ACPI_PCI_ID		**PciId)
> >>
> >> with:
> >> - DeviceHandle:		a handle to the PCI device.
> >> - PciRegionHandle:	a handle the PCI configuration space operation
> >>                         region.
> >>
> >>
> >> However, the only call to AcpiOsDerivePciId in the ACPICA code, in
> >> events/evrgnini.c, is:
> >>
> >> AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
> >>
> >> Moreover, the file include/acpiosxf.h contains:
> >>
> >> /*
> >>  * Interim function needed for PCI IRQ routing
> >>  */
> >> void
> >> AcpiOsDerivePciId(
> >>     ACPI_HANDLE             Rhandle,
> >>     ACPI_HANDLE             Chandle,
> >>     ACPI_PCI_ID             **PciId);
> >>
> >>
> >> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
> >>
> >> AcpiOsDerivePciId(
> >>    ACPI_HANDLE		PciRootHandle
> >>    ACPI_HANDLE		DeviceHandle
> >>    ACPI_PCI_ID		**PciId)
> >>
> >> with:
> >> - PciRootHandle:	a handle the PCI root bridge upstream of the PCI
> >>                         device (or to the name space root node if no
> >>                         PCI root bridge was found in the ancestors).
> >> - DeviceHandle:		a handle to the PCI device.
> >>
> >>
> >> Is that correct?
> >>
> >> Thanks for your help,
> >>
> >> Grégoire
> >> _______________________________________________
> >> Devel mailing list
> >> Devel(a)acpica.org
> >> http://lists.acpica.org/listinfo/devel
> 
> _______________________________________________
> Devel mailing list
> Devel(a)acpica.org
> http://lists.acpica.org/listinfo/devel



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-20 16:10 Moore, Robert
  0 siblings, 0 replies; 11+ messages in thread
From: Moore, Robert @ 2010-04-20 16:10 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 4642 bytes --]

Yes, It looks like there may be more to this than it first appeared. I haven't looked at the DerivePciId interface for some time.

I'm not fully sure what RegionObj->Region.Node refers to. I will investigate further.

Bob

>-----Original Message-----
>From: Grégoire Sutre [mailto:gregoire.sutre(a)gmail.com]
>Sent: Tuesday, April 20, 2010 9:07 AM
>To: Moore, Robert
>Cc: devel(a)acpica.org
>Subject: Re: [Devel] Error in documentation of AcpiOsDerivePciId?
>
>Hi Robert,
>
>First I want to thank you for your answer.
>
>> It looks to me that the documentation (ACPICA programmer reference) is
>correct.
>>
>> However, the acpiosxf.h file uses names that don't match the
>documentation and are not very descriptive.
>>
>> The ACPICA code uses a variable named "PciRootNode" for the
>"DeviceHandle" parameter, that is ok.
>
>The call to AcpiOsDerivePciId that I mentioned is performed in the
>function AcpiEvPciConfigRegionSetup of events/evrgnini.c.  Looking at
>this function (from acpica unix source code release 20100331), I see
>that:
>
>- RegionObj->Region.Node is the PCI device node that we are interested
>   in.  This is confirmed by the part that finds the parent device
>   object, which starts with:
>   PciDeviceNode = RegionObj->Region.Node;
>
>- PciRootNode is the PCI root bridge upstream of the PCI device node
>   that we are interested in.  Indeed, there is a while-loop that walks
>   the ancestors of the PCI device node until a PCI root bridge is found,
>   iteratively assigning PciRootNode to these ancestors.  See lines 312
>   to 360.
>
>This is the reason why I believe that in the call
>
>AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
>
>- PciRootNode is not a handle to the PCI device, it is a handle to its
>   upstream PCI root bridge, and
>- RegionObj->Region.Node is a handle to the PCI device.
>
>>> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
>>
>>> AcpiOsDerivePciId(
>>>    ACPI_HANDLE		PciRootHandle
>>>    ACPI_HANDLE		DeviceHandle
>>>    ACPI_PCI_ID		**PciId)
>>
>>
>> No, I don't think so. The second parameter is a handle to a region
>object.
>
>In the above call to AcpiOsDerivePciId, the second parameter, which is
>RegionObj->Region.Node, is of type (ACPI_NAMESPACE_NODE *).  I'm not
>familiar with all the ACPI types, but I guess that this type is not for
>region objects.
>
>Note that the implementation of AcpiOsDerivePciId in the linux kernel
>(as well as in the freebsd and netbsd kernels) seem to understand its
>interface in the same way as I did.
>
>http://lxr.linux.no/#linux+v2.6.33/drivers/acpi/osl.c#L689
>
>Best regards,
>
>Grégoire
>
>>> -----Original Message-----
>>> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On
>Behalf
>>> Of Grégoire Sutre
>>> Sent: Tuesday, April 20, 2010 2:46 AM
>>> To: devel(a)acpica.org
>>> Subject: [Devel] Error in documentation of AcpiOsDerivePciId?
>>>
>>> Hi list,
>>>
>>> According to the ACPICA Programmer Reference, the function
>>> AcpiOsDerivePciId takes as arguments:
>>>
>>> AcpiOsDerivePciId(
>>>    ACPI_HANDLE		DeviceHandle
>>>    ACPI_HANDLE		PciRegionHandle
>>>    ACPI_PCI_ID		**PciId)
>>>
>>> with:
>>> - DeviceHandle:		a handle to the PCI device.
>>> - PciRegionHandle:	a handle the PCI configuration space operation
>>>                         region.
>>>
>>>
>>> However, the only call to AcpiOsDerivePciId in the ACPICA code, in
>>> events/evrgnini.c, is:
>>>
>>> AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
>>>
>>> Moreover, the file include/acpiosxf.h contains:
>>>
>>> /*
>>>  * Interim function needed for PCI IRQ routing
>>>  */
>>> void
>>> AcpiOsDerivePciId(
>>>     ACPI_HANDLE             Rhandle,
>>>     ACPI_HANDLE             Chandle,
>>>     ACPI_PCI_ID             **PciId);
>>>
>>>
>>> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
>>>
>>> AcpiOsDerivePciId(
>>>    ACPI_HANDLE		PciRootHandle
>>>    ACPI_HANDLE		DeviceHandle
>>>    ACPI_PCI_ID		**PciId)
>>>
>>> with:
>>> - PciRootHandle:	a handle the PCI root bridge upstream of the PCI
>>>                         device (or to the name space root node if no
>>>                         PCI root bridge was found in the ancestors).
>>> - DeviceHandle:		a handle to the PCI device.
>>>
>>>
>>> Is that correct?
>>>
>>> Thanks for your help,
>>>
>>> Grégoire
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)acpica.org
>>> http://lists.acpica.org/listinfo/devel


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-20 16:07 
  0 siblings, 0 replies; 11+ messages in thread
From:  @ 2010-04-20 16:07 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 4041 bytes --]

Hi Robert,

First I want to thank you for your answer.

> It looks to me that the documentation (ACPICA programmer reference) is correct.
> 
> However, the acpiosxf.h file uses names that don't match the documentation and are not very descriptive.
> 
> The ACPICA code uses a variable named "PciRootNode" for the "DeviceHandle" parameter, that is ok.

The call to AcpiOsDerivePciId that I mentioned is performed in the
function AcpiEvPciConfigRegionSetup of events/evrgnini.c.  Looking at
this function (from acpica unix source code release 20100331), I see
that:

- RegionObj->Region.Node is the PCI device node that we are interested
   in.  This is confirmed by the part that finds the parent device
   object, which starts with:
   PciDeviceNode = RegionObj->Region.Node;

- PciRootNode is the PCI root bridge upstream of the PCI device node
   that we are interested in.  Indeed, there is a while-loop that walks
   the ancestors of the PCI device node until a PCI root bridge is found,
   iteratively assigning PciRootNode to these ancestors.  See lines 312
   to 360.

This is the reason why I believe that in the call

AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);

- PciRootNode is not a handle to the PCI device, it is a handle to its
   upstream PCI root bridge, and
- RegionObj->Region.Node is a handle to the PCI device.

>> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
> 
>> AcpiOsDerivePciId(
>>    ACPI_HANDLE		PciRootHandle
>>    ACPI_HANDLE		DeviceHandle
>>    ACPI_PCI_ID		**PciId)
> 
> 
> No, I don't think so. The second parameter is a handle to a region object.

In the above call to AcpiOsDerivePciId, the second parameter, which is
RegionObj->Region.Node, is of type (ACPI_NAMESPACE_NODE *).  I'm not
familiar with all the ACPI types, but I guess that this type is not for
region objects.

Note that the implementation of AcpiOsDerivePciId in the linux kernel
(as well as in the freebsd and netbsd kernels) seem to understand its
interface in the same way as I did.

http://lxr.linux.no/#linux+v2.6.33/drivers/acpi/osl.c#L689

Best regards,

Grégoire

>> -----Original Message-----
>> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>> Of Grégoire Sutre
>> Sent: Tuesday, April 20, 2010 2:46 AM
>> To: devel(a)acpica.org
>> Subject: [Devel] Error in documentation of AcpiOsDerivePciId?
>>
>> Hi list,
>>
>> According to the ACPICA Programmer Reference, the function
>> AcpiOsDerivePciId takes as arguments:
>>
>> AcpiOsDerivePciId(
>>    ACPI_HANDLE		DeviceHandle
>>    ACPI_HANDLE		PciRegionHandle
>>    ACPI_PCI_ID		**PciId)
>>
>> with:
>> - DeviceHandle:		a handle to the PCI device.
>> - PciRegionHandle:	a handle the PCI configuration space operation
>>                         region.
>>
>>
>> However, the only call to AcpiOsDerivePciId in the ACPICA code, in
>> events/evrgnini.c, is:
>>
>> AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
>>
>> Moreover, the file include/acpiosxf.h contains:
>>
>> /*
>>  * Interim function needed for PCI IRQ routing
>>  */
>> void
>> AcpiOsDerivePciId(
>>     ACPI_HANDLE             Rhandle,
>>     ACPI_HANDLE             Chandle,
>>     ACPI_PCI_ID             **PciId);
>>
>>
>> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
>>
>> AcpiOsDerivePciId(
>>    ACPI_HANDLE		PciRootHandle
>>    ACPI_HANDLE		DeviceHandle
>>    ACPI_PCI_ID		**PciId)
>>
>> with:
>> - PciRootHandle:	a handle the PCI root bridge upstream of the PCI
>>                         device (or to the name space root node if no
>>                         PCI root bridge was found in the ancestors).
>> - DeviceHandle:		a handle to the PCI device.
>>
>>
>> Is that correct?
>>
>> Thanks for your help,
>>
>> Grégoire
>> _______________________________________________
>> Devel mailing list
>> Devel(a)acpica.org
>> http://lists.acpica.org/listinfo/devel


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-20 14:51 Moore, Robert
  0 siblings, 0 replies; 11+ messages in thread
From: Moore, Robert @ 2010-04-20 14:51 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

It looks to me that the documentation (ACPICA programmer reference) is correct.

However, the acpiosxf.h file uses names that don't match the documentation and are not very descriptive.

The ACPICA code uses a variable named "PciRootNode" for the "DeviceHandle" parameter, that is ok.


>So it seems to me that the correct arguments for AcpiOsDerivePciId are:

>AcpiOsDerivePciId(
>    ACPI_HANDLE		PciRootHandle
>    ACPI_HANDLE		DeviceHandle
>    ACPI_PCI_ID		**PciId)


No, I don't think so. The second parameter is a handle to a region object.



>-----Original Message-----
>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>Of Grégoire Sutre
>Sent: Tuesday, April 20, 2010 2:46 AM
>To: devel(a)acpica.org
>Subject: [Devel] Error in documentation of AcpiOsDerivePciId?
>
>Hi list,
>
>According to the ACPICA Programmer Reference, the function
>AcpiOsDerivePciId takes as arguments:
>
>AcpiOsDerivePciId(
>    ACPI_HANDLE		DeviceHandle
>    ACPI_HANDLE		PciRegionHandle
>    ACPI_PCI_ID		**PciId)
>
>with:
>- DeviceHandle:		a handle to the PCI device.
>- PciRegionHandle:	a handle the PCI configuration space operation
>                         region.
>
>
>However, the only call to AcpiOsDerivePciId in the ACPICA code, in
>events/evrgnini.c, is:
>
>AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
>
>Moreover, the file include/acpiosxf.h contains:
>
>/*
>  * Interim function needed for PCI IRQ routing
>  */
>void
>AcpiOsDerivePciId(
>     ACPI_HANDLE             Rhandle,
>     ACPI_HANDLE             Chandle,
>     ACPI_PCI_ID             **PciId);
>
>
>So it seems to me that the correct arguments for AcpiOsDerivePciId are:
>
>AcpiOsDerivePciId(
>    ACPI_HANDLE		PciRootHandle
>    ACPI_HANDLE		DeviceHandle
>    ACPI_PCI_ID		**PciId)
>
>with:
>- PciRootHandle:	a handle the PCI root bridge upstream of the PCI
>                         device (or to the name space root node if no
>                         PCI root bridge was found in the ancestors).
>- DeviceHandle:		a handle to the PCI device.
>
>
>Is that correct?
>
>Thanks for your help,
>
>Grégoire
>_______________________________________________
>Devel mailing list
>Devel(a)acpica.org
>http://lists.acpica.org/listinfo/devel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Devel] Error in documentation of AcpiOsDerivePciId?
@ 2010-04-20  9:45 
  0 siblings, 0 replies; 11+ messages in thread
From:  @ 2010-04-20  9:45 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

Hi list,

According to the ACPICA Programmer Reference, the function
AcpiOsDerivePciId takes as arguments:

AcpiOsDerivePciId(
    ACPI_HANDLE		DeviceHandle
    ACPI_HANDLE		PciRegionHandle
    ACPI_PCI_ID		**PciId)

with:
- DeviceHandle:		a handle to the PCI device.
- PciRegionHandle:	a handle the PCI configuration space operation
                         region.


However, the only call to AcpiOsDerivePciId in the ACPICA code, in
events/evrgnini.c, is:

AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);

Moreover, the file include/acpiosxf.h contains:

/*
  * Interim function needed for PCI IRQ routing
  */
void
AcpiOsDerivePciId(
     ACPI_HANDLE             Rhandle,
     ACPI_HANDLE             Chandle,
     ACPI_PCI_ID             **PciId);


So it seems to me that the correct arguments for AcpiOsDerivePciId are:

AcpiOsDerivePciId(
    ACPI_HANDLE		PciRootHandle
    ACPI_HANDLE		DeviceHandle
    ACPI_PCI_ID		**PciId)

with:
- PciRootHandle:	a handle the PCI root bridge upstream of the PCI
                         device (or to the name space root node if no
                         PCI root bridge was found in the ancestors).
- DeviceHandle:		a handle to the PCI device.


Is that correct?

Thanks for your help,

Grégoire

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2010-08-04 23:33 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-01 11:31 [Devel] Error in documentation of AcpiOsDerivePciId? Rudi
  -- strict thread matches above, loose matches on Subject: below --
2010-08-04 23:33 Moore, Robert
2010-08-04 21:36 Moore, Robert
2010-08-02  0:29 Lin Ming
2010-04-23 12:44 Lin Ming
2010-04-22 12:50 
2010-04-21 23:33 Lin Ming
2010-04-20 16:10 Moore, Robert
2010-04-20 16:07 
2010-04-20 14:51 Moore, Robert
2010-04-20  9:45 

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.