Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1573363 > unrolled thread

Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen

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.

Contents

  Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-02-03 19:40 +0100
    Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Hanjun Guo <guohanjun@huawei.com> - 2017-02-04 08:10 +0100
      Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-02-06 15:30 +0100

#1573363 — Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen

Hanjun, Sinan,

On Wed, Jan 18, 2017 at 08:54:50PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
> 
> With platform msi support landed in the kernel, and the introduction
> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
> is ready, this patch set add few patches to enable the ACPI platform
> msi support.
> 
> For platform device connecting to ITS on arm platform, we have IORT
> table with the named componant node to describe the mappings of paltform
> device and ITS, so we can retrieve the dev id and find its parent
> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).

Depending on how things go, I prepared a branch with the first 12
patches (I basically updated some logs and added some cosmetics changes)
for testing (Hanjun please have a look in details since I may have misread
some logs), whether or not I will send a pull request for it we shall see
next week.

Here:

git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/platform-msi

Thanks,
Lorenzo

> v7 -> v8:
> 	- Using _CRS instead of _PRS for Interrupt resources for mbigen
> 
> 	- reshuffle the patch slightly to introduce iort_node_map_platform_id()
> 	  first and then retrieve the dev id for platform MSI, no functional
> 	  change
> 
> 	- Fix the compile error with patch "irqchip: gicv3-its: platform-msi:
> 	  scan MADT to create platform msi domain", which forgot to add 
> 	  <include/acpi_iort.h> (added in later patches in last version).
> 
> 	- renew some commit message which suggested by Lorenzo
> 
> 	- address some othe minor issues which commented by Lorenzo
> 
> 	- Add review and test tag as it's no functional change except
> 	  the last patch of mbigen
> 
> 	- rebase on top of 4.10-rc4 and test it on x86, ia64 and ARM64
> 	  platforms (also with Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
>           Add IRQ combiner driver" and Lorenzo's patch
>           https://patchwork.kernel.org/patch/9507041/)
> 
> v6 -> v7: 
> 	- Introduce iort_node_map_platform_id() to retrieve the
> 	  dev id for both NC (named component) -> ITS/SMMU and
> 	  NC -> SMMU -> ITS cases, suggested by Lorenzo;
> 
> 	- Reorder the patches and rewrite some commit message;
> 
> 	- Remove the test tags because it has major changes
> 	  to retrieve the dev id, Sinan, Majun, Xinwei, could
> 	  you please test them again on your platform?
> 
> 	- rebased on top of 4.10-rc3 and Lorenzo's patch
>           https://patchwork.kernel.org/patch/9507041/
> 
> 	- Tested against Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
>           Add IRQ combiner driver"
> 
> v5 -> v6:
>         - Call acpi_configure_pmsi_domain() for platform devices in
>           acpi_platform_notify() as it's cleaner (suggested by Rafael)
>         - Remove the "u8 type" for iort_id_map() because it's unused
>         - Rebase on top of 4.10-rc2
>         - Collect test and review tags
> 
> v4 -> v5:
>         - Add mbigen support back with tested on with Agustin's patchset,
>           and it's a good example of how ACPI platform MSI works
>         - rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)
> 
> v3 -> v4:
>         - Drop mbi-gen patches to just submit platform msi support because
>           will rebase mbi-gen patches on top of Agustin's patchset, and discusion
>           is going there.
>         - Add a patch to support device topology such as NC(named componant, paltform device)
>           ->SMMU->ITS which suggested by Lorenzo;
>         - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
>         - rebased on top of 4.9-rc7
> 
> v2 -> v3:
>         - Drop RFC tag
>         - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU support [1]
>         - Add 3 cleanup patches (patch 1, 2, 3)
>         - Drop arch_init call patch from last version
>         - Introduce a callback for platform device to set msi domain
>         - Introduce a new API to get paltform device's domain instead of
>           reusing the PCI one in previous version
>         - Add a patch to rework iort_node_get_id()
> 
> [1]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1251993.html
> 
> v1 -> v2:
>         - Fix the bug of if multi Interrupt() resoures in single _PRS,
>           we need to calculate all the irq numbers (I missed it in previous
>           version);
>         - Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
>           SMMU patches (also Robin's SMMu patches)
>         - Add patch irqchip: mbigen: promote mbigen init.
> 
> Hanjun Guo (13):
>   ACPI: IORT: fix the indentation in iort_scan_node()
>   ACPI: IORT: add missing comment for iort_dev_find_its_id()
>   ACPI: IORT: minor cleanup for iort_match_node_callback()
>   irqchip: gic-v3-its: keep the head file include in alphabetic order
>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
>     for ACPI
>   irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
>     domain
>   ACPI: IORT: rename iort_node_map_rid() to make it generic
>   ACPI: IORT: introduce iort_node_map_platform_id() to retrieve dev id
>   ACPI: platform-msi: retrieve dev id from IORT
>   ACPI: platform: setup MSI domain for ACPI based platform device
>   msi: platform: make platform_msi_create_device_domain() ACPI aware
>   irqchip: mbigen: Add ACPI support
> 
> Kefeng Wang (2):
>   irqchip: mbigen: drop module owner
>   irqchip: mbigen: introduce mbigen_of_create_domain()
> 
>  drivers/acpi/arm64/iort.c                     | 158 +++++++++++++++++++++-----
>  drivers/acpi/glue.c                           |   6 +
>  drivers/base/platform-msi.c                   |   3 +-
>  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++++++++++++----
>  drivers/irqchip/irq-gic-v3-its.c              |   3 +-
>  drivers/irqchip/irq-mbigen.c                  | 109 +++++++++++++++---
>  include/linux/acpi_iort.h                     |   8 ++
>  7 files changed, 316 insertions(+), 77 deletions(-)
> 
> -- 
> 1.7.12.4
> 

[toc] | [next] | [standalone]

#1573609

Hi Lorenzo,

On 2017/2/4 2:36, Lorenzo Pieralisi wrote:
> Hanjun, Sinan,
>
> On Wed, Jan 18, 2017 at 08:54:50PM +0800, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> With platform msi support landed in the kernel, and the introduction
>> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
>> is ready, this patch set add few patches to enable the ACPI platform
>> msi support.
>>
>> For platform device connecting to ITS on arm platform, we have IORT
>> table with the named componant node to describe the mappings of paltform
>> device and ITS, so we can retrieve the dev id and find its parent
>> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
> Depending on how things go, I prepared a branch with the first 12
> patches (I basically updated some logs and added some cosmetics changes)
> for testing (Hanjun please have a look in details since I may have misread
> some logs), whether or not I will send a pull request for it we shall see
> next week.
>
> Here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/platform-msi

Thanks a lot for putting them together, I fetched your git tree and
took a detail look, there is one issue in patch "msi: platform: make
platform_msi_create_device_domain() ACPI aware" which has two
"Cc: Greg KH <gregkh@linuxfoundation.org>" in the commit log
(it's in the original patch from me, my bad), others are pretty good
to me (to make sure it works I retested those patches and patches
in your branch work as before).

BTW, patches in Lorenzo's branch have no conflicts with Agustin's
patch set + my mbigen one, so after a pull request to Rafael, could
them (Agustin's patch set + my mbigen one) go via one tree such as
Marc's one for 4.11?  I know it's a little bit late but those patches
are quite self-contained, which Agustin's changes are conditional
on the ACPI_GENERIC_GSI config which is only available with
ARM64 ACPI and others (interrupt combiner and mbigen) are specific
to QC and Hisilicon platforms.

Marc, Lorenzo, could you give some comments that how can we
proceed those patches (Agustin's patch set + my mbigen one)?
It's really critical for us, thank you very much.

Best Regards
Hanjun

[toc] | [prev] | [next] | [standalone]

#1574824

On Sat, Feb 04, 2017 at 03:02:15PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
> 
> On 2017/2/4 2:36, Lorenzo Pieralisi wrote:
> > Hanjun, Sinan,
> >
> > On Wed, Jan 18, 2017 at 08:54:50PM +0800, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> With platform msi support landed in the kernel, and the introduction
> >> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
> >> is ready, this patch set add few patches to enable the ACPI platform
> >> msi support.
> >>
> >> For platform device connecting to ITS on arm platform, we have IORT
> >> table with the named componant node to describe the mappings of paltform
> >> device and ITS, so we can retrieve the dev id and find its parent
> >> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
> > Depending on how things go, I prepared a branch with the first 12
> > patches (I basically updated some logs and added some cosmetics changes)
> > for testing (Hanjun please have a look in details since I may have misread
> > some logs), whether or not I will send a pull request for it we shall see
> > next week.
> >
> > Here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/platform-msi
> 
> Thanks a lot for putting them together, I fetched your git tree and
> took a detail look, there is one issue in patch "msi: platform: make
> platform_msi_create_device_domain() ACPI aware" which has two
> "Cc: Greg KH <gregkh@linuxfoundation.org>" in the commit log
> (it's in the original patch from me, my bad), others are pretty good
> to me (to make sure it works I retested those patches and patches
> in your branch work as before).
> 
> BTW, patches in Lorenzo's branch have no conflicts with Agustin's
> patch set + my mbigen one, so after a pull request to Rafael, could
> them (Agustin's patch set + my mbigen one) go via one tree such as
> Marc's one for 4.11?  I know it's a little bit late but those patches
> are quite self-contained, which Agustin's changes are conditional
> on the ACPI_GENERIC_GSI config which is only available with
> ARM64 ACPI and others (interrupt combiner and mbigen) are specific
> to QC and Hisilicon platforms.
> 
> Marc, Lorenzo, could you give some comments that how can we
> proceed those patches (Agustin's patch set + my mbigen one)?
> It's really critical for us, thank you very much.

Ok, given that:

- We have decided that from now onwards ACPI IORT patches should go
  via the ARM64 tree
- This series does not yet handle ARM SMMU MSIs (but it has to and I
  want to see how this will work - waiting for spec updates)
- It depends on fixes that will get merged via the v4.11 arm64 queue
- We are at -rc7 and I do not think it is fair at all to ask Will
  and Catalin to pull this code now given that it comes out of thin
  air for them
- Last but not least: it is not bad to take time for the dust to
  settle given that we merged lots of IORT code last two cycles

I have decided that the whole series will be considered v4.12
material, I do not expect it to be a major disruption given that
we should have a stable code base for it come v4.11-rc1 (inclusive
of Agustin's key probe deferral series).

Thanks,
Lorenzo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web