linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hanjun.guo@linaro.org (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/11] ARM64 / PCI: introduce struct pci_controller for ACPI
Date: Tue, 08 Sep 2015 21:35:39 +0800	[thread overview]
Message-ID: <55EEE42B.8000305@linaro.org> (raw)
In-Reply-To: <20150907084542.GA29293@red-moon>

On 09/07/2015 04:45 PM, Lorenzo Pieralisi wrote:
> On Mon, Sep 07, 2015 at 05:14:22AM +0100, Ganapatrao Kulkarni wrote:
>> Hi Hanjun,
>>
>> On Wed, May 27, 2015 at 1:51 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> Hi Liviu,
>>>
>>> On 2015???05???27??? 01:20, Jiang Liu wrote:
>>>>
>>>> On 2015/5/27 0:58, Liviu Dudau wrote:
>>>>>
>>>>> On Tue, May 26, 2015 at 01:49:14PM +0100, Hanjun Guo wrote:
>>>>>>
>>>>>> ARM64 ACPI based PCI host bridge init needs a arch dependent
>>>>>> struct pci_controller to accommodate common PCI host bridge
>>>>>> code which is introduced later, or it will lead to compile
>>>>>> errors on ARM64.
>>>>>
>>>>>
>>>>> Hi Hanjun,
>>>>>
>>>>> Two questions: why don't you introduce this patch next to the
>>>>> one that is going to make use of it (or even merge it there)?
>>>
>>>
>>> this is because of this patch is needed by Jiang Liu's patch set
>>> to fix the compile error on ARM64, I'd rather do that, but It's
>>> better to let Jiang Liu's patch goes in, and then this one, that's
>>> why I prepared a single patch for the struct. (I mentioned it
>>> in the cover letter)
>>>
>>>>> Second, why is the whole struct pci_controller not surrounded
>>>>> by #ifdef CONFIG_ACPI as you are implying that this is needed
>>>>> only for ACPI?
>>>
>>>
>>> I hope it can be reused, since the NUMA node and segment (domain)
>>> is both needed for DT and ACPI, if it's not the case foe now, I
>>> can surrounded them all by #ifdef CONFIG_ACPI.
>> we can make use of this structure to hold pci to numa node
>> mapping(pcibus_to_node).
>> can you please pull node member out of  CONFIG_ACPI ifdef.
>> or you can put only acpi_device under ifdef.
>
> That struct disappeared in the latest series:
>
> https://lkml.org/lkml/2015/6/8/443

Yes, I think that is the right direction going.

>
> we have to have a common way to handle the NUMA info in DT and ACPI
> so we should still find a solution that can be shared between the two,
> it is yet another thing to take into account for PCI ACPI on arm64.

Agreed, we can take that into account when finished the basic
support.

Thanks
Hanjun

  reply	other threads:[~2015-09-08 13:35 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-26 12:49 [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI Hanjun Guo
2015-05-26 12:49 ` [PATCH 01/11] ARM64 / PCI: introduce struct pci_controller for ACPI Hanjun Guo
2015-05-26 16:58   ` Liviu Dudau
2015-05-26 17:20     ` Jiang Liu
2015-05-27  8:21       ` Hanjun Guo
2015-09-07  4:14         ` Ganapatrao Kulkarni
2015-09-07  8:45           ` Lorenzo Pieralisi
2015-09-08 13:35             ` Hanjun Guo [this message]
2015-05-27  9:47       ` Liviu Dudau
2015-05-27 11:29         ` Jiang Liu
2015-05-26 12:49 ` [PATCH 02/11] x86, pci: Clean up comment about buggy MMIO config space access for AMD Fam10h CPUs Hanjun Guo
2015-08-31 12:04   ` Tomasz Nowicki
2015-05-26 12:49 ` [PATCH 03/11] x86, pci: Abstract PCI config accessors and use AMD Fam10h workaround exclusively Hanjun Guo
2015-05-26 12:49 ` [PATCH 04/11] x86, pci: Reorder logic of pci_mmconfig_insert() function Hanjun Guo
2015-05-26 12:49 ` [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Hanjun Guo
2015-05-26 17:08   ` Will Deacon
2015-05-27  8:06     ` Tomasz Nowicki
2015-06-02 13:32       ` Lorenzo Pieralisi
2015-06-04  9:28         ` Hanjun Guo
2015-06-04 10:22           ` Lorenzo Pieralisi
2015-06-04 12:28             ` Hanjun Guo
2015-06-08  2:57               ` Hanjun Guo
2015-06-08 15:14                 ` Lorenzo Pieralisi
2015-08-31 11:01                   ` Tomasz Nowicki
2015-09-07  9:59                     ` Tomasz Nowicki
2015-09-08 15:07                       ` Lorenzo Pieralisi
2015-09-09 13:47                         ` Tomasz Nowicki
2015-09-11 11:20                           ` Lorenzo Pieralisi
2015-09-11 12:35                             ` Tomasz Nowicki
2015-09-14  9:37                               ` Lorenzo Pieralisi
2015-09-14 11:34                                 ` Tomasz Nowicki
2015-09-14 14:55                             ` Tomasz Nowicki
2015-09-25 16:02                               ` Tomasz Nowicki
2015-09-25 16:19                                 ` Lorenzo Pieralisi
2015-10-15 13:22                               ` Lorenzo Pieralisi
2015-10-15 14:34                                 ` Tomasz Nowicki
2015-10-15 16:26                                   ` Marc Zyngier
2015-10-15 18:51                                     ` Tomasz Nowicki
2015-05-26 12:49 ` [PATCH 06/11] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization Hanjun Guo
2015-05-26 12:49 ` [PATCH 07/11] x86, pci: mmconfig_{32, 64}.c code refactoring - remove code duplication Hanjun Guo
2015-05-26 12:49 ` [PATCH 08/11] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver Hanjun Guo
2015-05-26 12:49 ` [PATCH 09/11] pci, acpi, mcfg: Share ACPI PCI config space accessors Hanjun Guo
2015-05-26 12:49 ` [PATCH 10/11] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Hanjun Guo
2015-05-26 13:54   ` Boris Ostrovsky
2015-05-26 14:00     ` Boris Ostrovsky
2015-05-26 14:54       ` Tomasz Nowicki
2015-05-26 15:44         ` Boris Ostrovsky
2015-05-27  3:55           ` Hanjun Guo
2015-05-26 12:49 ` [PATCH 11/11] ARM64 / PCI / ACPI: support for ACPI based PCI hostbridge init Hanjun Guo
2015-05-26 15:12   ` Tomasz Nowicki
2015-05-27  7:31     ` Hanjun Guo
2015-05-26 17:13   ` Will Deacon
2015-05-26 17:24     ` Jiang Liu
2015-05-27  0:30 ` [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI Rafael J. Wysocki
2015-05-27  3:57   ` Hanjun Guo
2015-06-08 12:05     ` Jagan Teki
2015-06-10  2:47       ` Hanjun Guo
2015-10-15 19:15 ` Jon Masters
2015-10-15 23:42   ` Hanjun Guo
2015-10-15 23:49     ` Jon Masters
2015-12-07 20:29 ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55EEE42B.8000305@linaro.org \
    --to=hanjun.guo@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).