public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: tn@semihalf•com (Tomasz Nowicki)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V3 10/10] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization.
Date: Fri, 12 Feb 2016 13:26:55 +0100	[thread overview]
Message-ID: <56BDCF8F.1080208@semihalf.com> (raw)
In-Reply-To: <56BB26E5.6060703@arm.com>

+ Charles

On 10.02.2016 13:02, Marc Zyngier wrote:
> On 19/01/16 13:11, Tomasz Nowicki wrote:
>> After refactoring DT code, we let ACPI to build ITS PCI MSI domain
>> and do requester ID to device ID translation using IORT table.
>>
>> We have now full PCI MSI domain stack, thus we can enable ITS initialization
>> from GICv3 core driver for ACPI scenario.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf•com>
>> ---
>>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 +++++++++++++++++++++++++++++++-
>>   drivers/irqchip/irq-gic-v3.c             |  3 +--
>>   drivers/pci/msi.c                        |  3 +++
>>   3 files changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> index 06165cb..7f0a958 100644
>> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> @@ -15,6 +15,8 @@
>>    * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>    */
>>
>> +#include <linux/acpi.h>
>> +#include <linux/iort.h>
>>   #include <linux/msi.h>
>>   #include <linux/of.h>
>>   #include <linux/of_irq.h>
>> @@ -143,10 +145,50 @@ static int __init its_pci_of_msi_init(void)
>>   	return 0;
>>   }
>>
>> +#ifdef CONFIG_ACPI
>> +
>> +static int __init
>> +its_pci_msi_parse_madt(struct acpi_subtable_header *header,
>> +		    const unsigned long end)
>> +{
>> +	struct acpi_madt_generic_translator *its_entry;
>> +	struct fwnode_handle *domain_handle;
>> +
>> +	its_entry = (struct acpi_madt_generic_translator *)header;
>> +	domain_handle = iort_find_its_domain_token(its_entry->translation_id);
>> +	if (!domain_handle) {
>> +		pr_err("ITS at 0x%lx: Unable to locate ITS domain handle\n",
>> +		       (long)its_entry->base_address);
>> +		return 0;
>> +	}
>> +
>> +	if (its_pci_msi_init_one(domain_handle))
>> +		return 0;
>> +
>> +	pci_msi_register_fwnode_provider(&iort_find_pci_domain_token);
>
> I'm a bit worried by this. You are registering this for each and every
> ITS that gets probed (useless, but why not). But also, you're using a
> hook that is designed to work at the bus level, without caring for the
> actual PCI devices. That's fine for something like GICv2m, which exposes
> a single domain, but I can't picture how this works when you have
> devices sitting behind a single RC that talk to different ITSs.
>
> My understanding is that IORT was behaving in a similar way the msi-map
> property works, so I'm a bit puzzled here.
>
> Can you please shed some light on that?
>

I see your point now. It is possible to describe such case in IORT, for 
example:

********************************************
RC0 node:
---------------
Mapping 0:
<input ID range> -> <output ID range>
<0:100> -> <0:100>
parent -> ITS0
---------------
Mapping 1:
<input ID range> -> <output ID range>
<101:200> -> <101:200>
parent -> ITS1
---------------
********************************************

So for this scenario I cannot use pci_host_bridge_acpi_msi_domain() to 
find IRQ domain based on bus device (unless there is only one ITS bound 
to e.g. RC), I should rather add ACPI implementation to 
pci_msi_get_device_domain on per-device MSI basis. Do you agree?

BTW. I should have put IORT specification link to changelog:
http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf

Thanks,
Tomasz

  reply	other threads:[~2016-02-12 12:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 13:11 [PATCH V3 00/10] Introduce ACPI world to GICv3 & ITS irqchip Tomasz Nowicki
2016-01-19 13:11 ` [PATCH V3 01/10] irqchip / GICv3: Refactor gic_of_init() for GICv3 driver Tomasz Nowicki
2016-02-10  9:50   ` Marc Zyngier
2016-01-19 13:11 ` [PATCH V3 02/10] irqchip / GICv3: Add ACPI support for GICv3+ initialization Tomasz Nowicki
2016-02-10  9:55   ` Marc Zyngier
2016-01-19 13:11 ` [PATCH V3 03/10] irqchip, GICv3, ACPI: Add redistributor support via GICC structures Tomasz Nowicki
2016-02-10 10:16   ` [PATCH V3 03/10] irqchip,GICv3,ACPI: " Marc Zyngier
2016-01-19 13:11 ` [PATCH V3 04/10] irqchip / GICv3: remove gic root node in ITS Tomasz Nowicki
2016-02-10 10:25   ` Marc Zyngier
2016-01-19 13:11 ` [PATCH V3 05/10] irqchip, gicv3, its: Mark its_init() and its children as __init Tomasz Nowicki
2016-02-10 10:30   ` Marc Zyngier
2016-01-19 13:11 ` [PATCH V3 06/10] irqchip, GICv3, ITS: Refator ITS dt init code to prepare for ACPI Tomasz Nowicki
2016-02-10 10:47   ` Marc Zyngier
2016-02-12 10:10     ` Tomasz Nowicki
2016-02-14  8:06     ` Hanjun Guo
2016-01-19 13:11 ` [PATCH V3 07/10] ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support Tomasz Nowicki
2016-01-19 13:11 ` [PATCH V3 08/10] irqchip, gicv3, its: Probe ITS in the ACPI way Tomasz Nowicki
2016-01-19 18:04   ` kbuild test robot
2016-02-10 11:46   ` Marc Zyngier
2016-02-12 10:14     ` Tomasz Nowicki
2016-01-19 13:11 ` [PATCH V3 09/10] acpi, gicv3, msi: Factor out code that might be reused for ACPI equivalent Tomasz Nowicki
2016-01-19 13:11 ` [PATCH V3 10/10] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization Tomasz Nowicki
2016-01-19 18:26   ` kbuild test robot
2016-02-10 12:02   ` Marc Zyngier
2016-02-12 12:26     ` Tomasz Nowicki [this message]
2016-02-12 13:22       ` Marc Zyngier
2016-01-22 21:56 ` [PATCH V3 00/10] Introduce ACPI world to GICv3 & ITS irqchip Christopher Covington
2016-01-22 23:06 ` Robert Richter
2016-02-10  8:55 ` Tomasz Nowicki
2016-02-10 10:19   ` Marc Zyngier
2016-02-11 11:47 ` Marc Zyngier
2016-02-11 14:02   ` Tomasz Nowicki

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=56BDCF8F.1080208@semihalf.com \
    --to=tn@semihalf$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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