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

Groups > linux.kernel > #1573130 > 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 Sinan Kaya <okaya@codeaurora.org> - 2017-02-03 16:00 +0100
    Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Marc Zyngier <marc.zyngier@arm.com> - 2017-02-03 16:20 +0100
      Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Sinan Kaya <okaya@codeaurora.org> - 2017-02-03 16:40 +0100
        Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Sinan Kaya <okaya@codeaurora.org> - 2017-02-03 17:00 +0100
          Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-02-03 17:40 +0100
            Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Sinan Kaya <okaya@codeaurora.org> - 2017-02-03 18:00 +0100
        Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Marc Zyngier <marc.zyngier@arm.com> - 2017-02-03 17:00 +0100
    Re: [PATCH v8 00/15] ACPI platform MSI support and its example mbigen Hanjun Guo <guohanjun@huawei.com> - 2017-02-04 05:10 +0100

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

On 1/18/2017 7:54 AM, 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).
> 

I understand that there is a consensus on IORT/SMMUv3 specific pieces
of this series while there is some ongoing work on the MBIgen part in
due to dependency on Agustin's patch vs. ACPI definitions.

Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base
implementation comes in place?

Any objections to not doing so?


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

[toc] | [next] | [standalone]

#1573144

On 03/02/17 14:50, Sinan Kaya wrote:
> On 1/18/2017 7:54 AM, 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).
>>
> 
> I understand that there is a consensus on IORT/SMMUv3 specific pieces
> of this series while there is some ongoing work on the MBIgen part in
> due to dependency on Agustin's patch vs. ACPI definitions.
> 
> Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base
> implementation comes in place?

Sorry, but I may be missing something. Which IORT/SMMUv3 patches are we
talking about? Do you have a pointer to a series?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

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

#1573179

On 2/3/2017 10:11 AM, Marc Zyngier wrote:
> On 03/02/17 14:50, Sinan Kaya wrote:
>> On 1/18/2017 7:54 AM, 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).
>>>
>>
>> I understand that there is a consensus on IORT/SMMUv3 specific pieces
>> of this series while there is some ongoing work on the MBIgen part in
>> due to dependency on Agustin's patch vs. ACPI definitions.
>>
>> Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base
>> implementation comes in place?
> 
> Sorry, but I may be missing something. Which IORT/SMMUv3 patches are we
> talking about? Do you have a pointer to a series?
> 

I was talking about patches V8 00-12 of this particular one. 

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

Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.

> Thanks,
> 
> 	M.
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

#1573212

On 2/3/2017 10:49 AM, Marc Zyngier wrote:
>> Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.
> Is that to support SMMUv3's own MSI generation? It would be helpful if
> you explained why you want this code to be merged beforehand,
> potentially without any in-tree user.

Sure, I'm more interested in supporting MSI on my HIDMA code rather than
MSI on SMMUv3.

HIDMA MSI patches were merged November 2016.

https://github.com/torvalds/linux/commits/master/drivers/dma/qcom/hidma.c

Commits on Nov 3, 2016
 @vinodkoul
dmaengine: qcom_hidma: add MSI support for interrupts  …
Sinan Kaya committed with vinodkoul on Oct 21, 2016

I tested the first 12 patches of this series against HIDMA and provided
my tested-by.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

#1573248

On Fri, Feb 03, 2017 at 10:57:44AM -0500, Sinan Kaya wrote:
> On 2/3/2017 10:49 AM, Marc Zyngier wrote:
> >> Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.
> > Is that to support SMMUv3's own MSI generation? It would be helpful if
> > you explained why you want this code to be merged beforehand,
> > potentially without any in-tree user.
> 
> Sure, I'm more interested in supporting MSI on my HIDMA code rather than
> MSI on SMMUv3.
> 
> HIDMA MSI patches were merged November 2016.
> 
> https://github.com/torvalds/linux/commits/master/drivers/dma/qcom/hidma.c
> 
> Commits on Nov 3, 2016
>  @vinodkoul
> dmaengine: qcom_hidma: add MSI support for interrupts  …
> Sinan Kaya committed with vinodkoul on Oct 21, 2016
> 
> I tested the first 12 patches of this series against HIDMA and provided
> my tested-by.

Ok, we should have split this series before then. Now, if:

(1) Marc is ok with patches [4-7,10,12]
(2) Your HIDMA MSI does not depend on Agustin patch series to work
(3) Rafael is ok with a pull request at -rc7 (ie I won't be able to
    send it before then since I want to test it)

I will send a pull request to Rafael for patches [1-12] on Monday.

If any of (1)-(2)-(3) does not hold it is going to be v4.12, a
single driver is not the end of the world (and this will give us
time to add support for SMMUv3 MSI that this series can't handle).

Thanks,
Lorenzo

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

#1573271

On 2/3/2017 11:40 AM, Lorenzo Pieralisi wrote:
> (2) Your HIDMA MSI does not depend on Agustin patch series to work

I confirm that my driver doesn't depend on Agustin's patch.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

#1573218

On 03/02/17 15:35, Sinan Kaya wrote:
> On 2/3/2017 10:11 AM, Marc Zyngier wrote:
>> On 03/02/17 14:50, Sinan Kaya wrote:
>>> On 1/18/2017 7:54 AM, 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).
>>>>
>>>
>>> I understand that there is a consensus on IORT/SMMUv3 specific pieces
>>> of this series while there is some ongoing work on the MBIgen part in
>>> due to dependency on Agustin's patch vs. ACPI definitions.
>>>
>>> Can we merge the IORT/SMMUv3 specific pieces to 4.11 so that the base
>>> implementation comes in place?
>>
>> Sorry, but I may be missing something. Which IORT/SMMUv3 patches are we
>> talking about? Do you have a pointer to a series?
>>
> 
> I was talking about patches V8 00-12 of this particular one. 
> 
> [PATCH v8 00/15] ACPI platform MSI support and its example mbigen
> 
> Patches 13-15 are specific for MBIGEN. 00-12 are for the base functionality.

Is that to support SMMUv3's own MSI generation? It would be helpful if
you explained why you want this code to be merged beforehand,
potentially without any in-tree user.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

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

#1573594

On 2017/2/3 22:50, Sinan Kaya wrote:
> On 1/18/2017 7:54 AM, 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).
>>
> I understand that there is a consensus on IORT/SMMUv3 specific pieces
> of this series while there is some ongoing work on the MBIgen part in
> due to dependency on Agustin's patch vs. ACPI definitions.

I think both Agustin's patch set and my mbigen one are in good shape
now if I didn't miss something, Rafael and Lorenzo already acked Agustin's
patch [1-2/3], I provided my review and test tags on them.

And Lorenzo said about the mbigen patches:
"I think this patch (and the FW that goes with it) is wrong, but the rest
of the series, in particular the IORT bits, are ok with me."
and I fixed the wrong patch and updated the _PRS to _CRS as Lorenzo
suggested in v8.

So, can I kindly ask that those patches (Agustin's patch set and my mbigen one)
be merged to 4.11 please? It's really important for Hisilicon (Hip06/Hip07) SoCs
which native NIC [1], SAS [2], USB and even the console on Hip07-D05 drivers
depend on those patches, and those platform are completely dead without
them if PCI is not enabled...

Thanks
Hanjun

[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/hisilicon/hns/
[2]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/hisi_sas/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web