Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1400706 > unrolled thread
| Started by | Jayachandran C <jchandra@broadcom.com> |
|---|---|
| First post | 2016-05-13 13:30 +0200 |
| Last post | 2016-05-13 13:50 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Jayachandran C <jchandra@broadcom.com> - 2016-05-13 13:30 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-13 13:40 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-05-13 13:50 +0200
| From | Jayachandran C <jchandra@broadcom.com> |
|---|---|
| Date | 2016-05-13 13:30 +0200 |
| Subject | Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller |
| Message-ID | <ryjs5-2gO-3@gated-at.bofh.it> |
On Tue, May 10, 2016 at 8:49 PM, Tomasz Nowicki <tn@semihalf.com> wrote:
> This patch is going to implement generic PCI host controller for
> ACPI world, similar to what pci-host-generic.c driver does for DT world.
>
> All such drivers, which we have seen so far, were implemented within
> arch/ directory since they had some arch assumptions (x86 and ia64).
> However, they all are doing similar thing, so it makes sense to find
> some common code and abstract it into the generic driver.
>
> In order to handle PCI config space regions properly, we define new
> MCFG interface which does sanity checks on MCFG table and keeps its
> root pointer. User is able to lookup MCFG regions based on that root
> pointer and specified domain:bus_start:bus_end touple. We are using
> pci_mmcfg_late_init old prototype to avoid another function name.
>
> The implementation of pci_acpi_scan_root() looks up the MCFG entries
> and sets up a new mapping (regions are not mapped until host controller ask
> for it). Generic PCI functions are used for accessing config space.
> Driver selects PCI_ECAM and uses functions from drivers/pci/ecam.h
> to create and access ECAM mappings.
>
> As mentioned in Kconfig help section, ACPI_PCI_HOST_GENERIC choice
> should be made on a per-architecture basis.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> ---
[....]
> diff --git a/drivers/pci/ecam.h b/drivers/pci/ecam.h
> index 1ad2176..1cccf57 100644
> --- a/drivers/pci/ecam.h
> +++ b/drivers/pci/ecam.h
> @@ -45,6 +45,11 @@ struct pci_config_window {
> void __iomem *win; /* 64-bit single mapping */
> void __iomem **winp; /* 32-bit per bus mapping */
> };
> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
> + struct acpi_device *companion; /* ACPI companion device */
> +#endif
> + int domain;
> +
> };
Using struct pci_config_window to pass along domain and
companion looks bad. I think there are two possible options
to do this better:
1. add a 'struct fwnode_handle *' or 'struct device *parent_dev'
instead of the companion and domain fields above. In case of
ACPI either of them can be used to get the acpi_device and
both domain and companion can be set from that.
2. make pci_config_window fully embeddable by moving allocation
out of pci_ecam_create to its callers. Then it can be embedded
into acpi_pci_generic_root_info, and container_of can be used
to get acpi info from ->sysdata.
The first option should be easier to implement but the second may
be better on long run. I would leave it to the Bjorn or Rafael to
suggest which is preferred.
JC.
[toc] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-05-13 13:40 +0200 |
| Message-ID | <ryjBL-2nm-3@gated-at.bofh.it> |
| In reply to | #1400706 |
On Fri, May 13, 2016 at 1:25 PM, Jayachandran C <jchandra@broadcom.com> wrote:
> On Tue, May 10, 2016 at 8:49 PM, Tomasz Nowicki <tn@semihalf.com> wrote:
>> This patch is going to implement generic PCI host controller for
>> ACPI world, similar to what pci-host-generic.c driver does for DT world.
>>
>> All such drivers, which we have seen so far, were implemented within
>> arch/ directory since they had some arch assumptions (x86 and ia64).
>> However, they all are doing similar thing, so it makes sense to find
>> some common code and abstract it into the generic driver.
>>
>> In order to handle PCI config space regions properly, we define new
>> MCFG interface which does sanity checks on MCFG table and keeps its
>> root pointer. User is able to lookup MCFG regions based on that root
>> pointer and specified domain:bus_start:bus_end touple. We are using
>> pci_mmcfg_late_init old prototype to avoid another function name.
>>
>> The implementation of pci_acpi_scan_root() looks up the MCFG entries
>> and sets up a new mapping (regions are not mapped until host controller ask
>> for it). Generic PCI functions are used for accessing config space.
>> Driver selects PCI_ECAM and uses functions from drivers/pci/ecam.h
>> to create and access ECAM mappings.
>>
>> As mentioned in Kconfig help section, ACPI_PCI_HOST_GENERIC choice
>> should be made on a per-architecture basis.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>> ---
> [....]
>
>> diff --git a/drivers/pci/ecam.h b/drivers/pci/ecam.h
>> index 1ad2176..1cccf57 100644
>> --- a/drivers/pci/ecam.h
>> +++ b/drivers/pci/ecam.h
>> @@ -45,6 +45,11 @@ struct pci_config_window {
>> void __iomem *win; /* 64-bit single mapping */
>> void __iomem **winp; /* 32-bit per bus mapping */
>> };
>> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
>> + struct acpi_device *companion; /* ACPI companion device */
>> +#endif
>> + int domain;
>> +
>> };
>
> Using struct pci_config_window to pass along domain and
> companion looks bad. I think there are two possible options
> to do this better:
>
> 1. add a 'struct fwnode_handle *' or 'struct device *parent_dev'
> instead of the companion and domain fields above. In case of
> ACPI either of them can be used to get the acpi_device and
> both domain and companion can be set from that.
>
> 2. make pci_config_window fully embeddable by moving allocation
> out of pci_ecam_create to its callers. Then it can be embedded
> into acpi_pci_generic_root_info, and container_of can be used
> to get acpi info from ->sysdata.
>
> The first option should be easier to implement but the second may
> be better on long run. I would leave it to the Bjorn or Rafael to
> suggest which is preferred.
Personally, I'd probably try to use fwnode_handle, but the second
option makes sense too in principle.
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Nowicki <tn@semihalf.com> |
|---|---|
| Date | 2016-05-13 13:50 +0200 |
| Message-ID | <ryjLr-2sD-3@gated-at.bofh.it> |
| In reply to | #1400712 |
On 13.05.2016 13:31, Rafael J. Wysocki wrote:
> On Fri, May 13, 2016 at 1:25 PM, Jayachandran C <jchandra@broadcom.com> wrote:
>> On Tue, May 10, 2016 at 8:49 PM, Tomasz Nowicki <tn@semihalf.com> wrote:
>>> This patch is going to implement generic PCI host controller for
>>> ACPI world, similar to what pci-host-generic.c driver does for DT world.
>>>
>>> All such drivers, which we have seen so far, were implemented within
>>> arch/ directory since they had some arch assumptions (x86 and ia64).
>>> However, they all are doing similar thing, so it makes sense to find
>>> some common code and abstract it into the generic driver.
>>>
>>> In order to handle PCI config space regions properly, we define new
>>> MCFG interface which does sanity checks on MCFG table and keeps its
>>> root pointer. User is able to lookup MCFG regions based on that root
>>> pointer and specified domain:bus_start:bus_end touple. We are using
>>> pci_mmcfg_late_init old prototype to avoid another function name.
>>>
>>> The implementation of pci_acpi_scan_root() looks up the MCFG entries
>>> and sets up a new mapping (regions are not mapped until host controller ask
>>> for it). Generic PCI functions are used for accessing config space.
>>> Driver selects PCI_ECAM and uses functions from drivers/pci/ecam.h
>>> to create and access ECAM mappings.
>>>
>>> As mentioned in Kconfig help section, ACPI_PCI_HOST_GENERIC choice
>>> should be made on a per-architecture basis.
>>>
>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>>> ---
>> [....]
>>
>>> diff --git a/drivers/pci/ecam.h b/drivers/pci/ecam.h
>>> index 1ad2176..1cccf57 100644
>>> --- a/drivers/pci/ecam.h
>>> +++ b/drivers/pci/ecam.h
>>> @@ -45,6 +45,11 @@ struct pci_config_window {
>>> void __iomem *win; /* 64-bit single mapping */
>>> void __iomem **winp; /* 32-bit per bus mapping */
>>> };
>>> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
>>> + struct acpi_device *companion; /* ACPI companion device */
>>> +#endif
>>> + int domain;
>>> +
>>> };
>>
>> Using struct pci_config_window to pass along domain and
>> companion looks bad. I think there are two possible options
>> to do this better:
>>
>> 1. add a 'struct fwnode_handle *' or 'struct device *parent_dev'
>> instead of the companion and domain fields above. In case of
>> ACPI either of them can be used to get the acpi_device and
>> both domain and companion can be set from that.
>>
>> 2. make pci_config_window fully embeddable by moving allocation
>> out of pci_ecam_create to its callers. Then it can be embedded
>> into acpi_pci_generic_root_info, and container_of can be used
>> to get acpi info from ->sysdata.
>>
>> The first option should be easier to implement but the second may
>> be better on long run. I would leave it to the Bjorn or Rafael to
>> suggest which is preferred.
>
> Personally, I'd probably try to use fwnode_handle, but the second
> option makes sense too in principle.
>
Thanks for suggestions. I will try to use fwnode_handle
Tomasz
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web