All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Tomasz Nowicki <tn@semihalf.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	rjw@rjwysocki.net
Cc: tglx@linutronix.de, jason@lakedaemon.net, helgaas@kernel.org,
	rafael@kernel.org, will.deacon@arm.com, catalin.marinas@arm.com,
	hanjun.guo@linaro.org, shijie.huang@arm.com,
	robert.richter@caviumnetworks.com, mw@semihalf.com,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linaro-acpi@lists.linaro.org, andrea.gallo@linaro.org,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	al.stone@linaro.org, graeme.gregory@linaro.org,
	ddaney.cavm@gmail.com, okaya@codeaurora.org
Subject: Re: [UPDATE PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support
Date: Mon, 12 Sep 2016 14:04:29 +0100	[thread overview]
Message-ID: <57D6A7DD.1060305@arm.com> (raw)
In-Reply-To: <38e36eee-cece-75db-4781-5727dd11c93d@semihalf.com>

On 12/09/16 13:37, Tomasz Nowicki wrote:
> Hi Rafael,
> 
> On 09.09.2016 11:20, Lorenzo Pieralisi wrote:
>> Hi Rafael,
>>
>> On Wed, Sep 07, 2016 at 01:56:52PM +0200, Tomasz Nowicki wrote:
>>> IORT shows representation of IO topology for ARM based systems.
>>> It describes how various components are connected together on
>>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>>>
>>> Initial support allows to detect IORT table presence and save its
>>> root pointer obtained through acpi_get_table(). The pointer validity
>>> depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
>>> is not set while using IORT nodes we would dereference unmapped pointers.
>>>
>>> For the aforementioned reason call iort_table_detect() from acpi_init()
>>> which guarantees acpi_gbl_permanent_mmap to be set at that point.
>>>
>>> Add generic helpers which are helpful for scanning and retrieving
>>> information from IORT table content. List of the most important helpers:
>>> - iort_find_dev_node() finds IORT node for a given device
>>> - iort_node_map_rid() maps device RID and returns IORT node which provides
>>>   final translation
>>>
>>> IORT support is placed under drivers/acpi/arm64/ new directory due to its
>>> ARM64 specific nature. The code there is considered only for ARM64.
>>> The long term plan is to keep all ARM64 specific tables support
>>> in this place e.g. GTDT table.
>>>
>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> ---
>>
>> Apart from the minor commit logs oversights we consider these two
>> patches ready to go, please let us know if there is something you want
>> changed since we are at risk of missing yet another merge window.
>>
>> It is ARM64 specific code, we created and moved the code to its
>> ARM64 specific directory and we are happy to maintain it as such,
>> we need your ACK to get this done so if there is something you
>> want changed please let us know otherwise I would ask your ACK
>> on these two patches to give Marc a go-ahead for -next and
>> hopefully 4.9.
> 
> Kindly reminder. Is there anything we need to do more about these 
> patches? Please let us know. Note this is the major thing for incoming 
> IORT more advance feature.

May I convey a slight sense of urgency here? I'd like to cut the irqchip
branch for 4.9 pretty soon (this week), in order to let it sink in -next
for a few days at the very least.

It'd be a bit disappointing if these patches missed the boat this time
again.

Thanks,

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

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [UPDATE PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support
Date: Mon, 12 Sep 2016 14:04:29 +0100	[thread overview]
Message-ID: <57D6A7DD.1060305@arm.com> (raw)
In-Reply-To: <38e36eee-cece-75db-4781-5727dd11c93d@semihalf.com>

On 12/09/16 13:37, Tomasz Nowicki wrote:
> Hi Rafael,
> 
> On 09.09.2016 11:20, Lorenzo Pieralisi wrote:
>> Hi Rafael,
>>
>> On Wed, Sep 07, 2016 at 01:56:52PM +0200, Tomasz Nowicki wrote:
>>> IORT shows representation of IO topology for ARM based systems.
>>> It describes how various components are connected together on
>>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>>>
>>> Initial support allows to detect IORT table presence and save its
>>> root pointer obtained through acpi_get_table(). The pointer validity
>>> depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
>>> is not set while using IORT nodes we would dereference unmapped pointers.
>>>
>>> For the aforementioned reason call iort_table_detect() from acpi_init()
>>> which guarantees acpi_gbl_permanent_mmap to be set at that point.
>>>
>>> Add generic helpers which are helpful for scanning and retrieving
>>> information from IORT table content. List of the most important helpers:
>>> - iort_find_dev_node() finds IORT node for a given device
>>> - iort_node_map_rid() maps device RID and returns IORT node which provides
>>>   final translation
>>>
>>> IORT support is placed under drivers/acpi/arm64/ new directory due to its
>>> ARM64 specific nature. The code there is considered only for ARM64.
>>> The long term plan is to keep all ARM64 specific tables support
>>> in this place e.g. GTDT table.
>>>
>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> ---
>>
>> Apart from the minor commit logs oversights we consider these two
>> patches ready to go, please let us know if there is something you want
>> changed since we are at risk of missing yet another merge window.
>>
>> It is ARM64 specific code, we created and moved the code to its
>> ARM64 specific directory and we are happy to maintain it as such,
>> we need your ACK to get this done so if there is something you
>> want changed please let us know otherwise I would ask your ACK
>> on these two patches to give Marc a go-ahead for -next and
>> hopefully 4.9.
> 
> Kindly reminder. Is there anything we need to do more about these 
> patches? Please let us know. Note this is the major thing for incoming 
> IORT more advance feature.

May I convey a slight sense of urgency here? I'd like to cut the irqchip
branch for 4.9 pretty soon (this week), in order to let it sink in -next
for a few days at the very least.

It'd be a bit disappointing if these patches missed the boat this time
again.

Thanks,

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

  reply	other threads:[~2016-09-12 13:04 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06  9:08 [PATCH V10 0/8] Introduce ACPI world to ITS irqchip Tomasz Nowicki
2016-09-06  9:08 ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-07 11:56   ` [UPDATE PATCH " Tomasz Nowicki
2016-09-07 11:56     ` Tomasz Nowicki
2016-09-08 13:59     ` Lorenzo Pieralisi
2016-09-08 13:59       ` Lorenzo Pieralisi
2016-09-09  9:20     ` Lorenzo Pieralisi
2016-09-09  9:20       ` Lorenzo Pieralisi
2016-09-12 12:37       ` Tomasz Nowicki
2016-09-12 12:37         ` Tomasz Nowicki
2016-09-12 13:04         ` Marc Zyngier [this message]
2016-09-12 13:04           ` Marc Zyngier
2016-09-12 13:43           ` Rafael J. Wysocki
2016-09-12 13:43             ` Rafael J. Wysocki
2016-09-09  3:09   ` [PATCH " Dennis Chen
2016-09-09  3:09     ` Dennis Chen
2016-09-09  3:09     ` Dennis Chen
2016-09-09  3:09     ` Dennis Chen
2016-09-09  8:45     ` Lorenzo Pieralisi
2016-09-09  8:45       ` Lorenzo Pieralisi
2016-09-06  9:08 ` [PATCH V10 2/8] ACPI: Add new IORT functions to support MSI domain handling Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06 10:20   ` Thomas Gleixner
2016-09-06 10:20     ` Thomas Gleixner
2016-09-06 10:27     ` Tomasz Nowicki
2016-09-06 10:27       ` Tomasz Nowicki
2016-09-07 10:35       ` Tomasz Nowicki
2016-09-07 10:35         ` Tomasz Nowicki
2016-09-07 11:32         ` Rafael J. Wysocki
2016-09-07 11:32           ` Rafael J. Wysocki
2016-09-07 11:32           ` Rafael J. Wysocki
2016-09-07 11:58   ` [UPDATE PATCH " Tomasz Nowicki
2016-09-07 11:58     ` Tomasz Nowicki
2016-09-07 13:01     ` Tomasz Nowicki
2016-09-07 13:01       ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 3/8] PCI/MSI: Setup MSI domain on a per-device basis using IORT ACPI table Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 4/8] irqchip/gicv3-its: Cleanup for ITS domain initialization Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 5/8] irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 6/8] irqchip/gicv3-its: Probe ITS in the ACPI way Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 7/8] irqchip/gicv3-its: Factor out PCI-MSI part that might be reused for ACPI Tomasz Nowicki
2016-09-06  9:08   ` Tomasz Nowicki
2016-09-06  9:50   ` Thomas Gleixner
2016-09-06  9:50     ` Thomas Gleixner
2016-09-06 10:22     ` Tomasz Nowicki
2016-09-06 10:22       ` Tomasz Nowicki
2016-09-06 11:29       ` Rafael J. Wysocki
2016-09-06 11:29         ` Rafael J. Wysocki
2016-09-06 11:29         ` Rafael J. Wysocki
2016-09-07  7:49         ` Tomasz Nowicki
2016-09-07  7:49           ` Tomasz Nowicki
2016-09-07  7:49           ` Tomasz Nowicki
2016-09-06  9:08 ` [PATCH V10 8/8] irqchip/gicv3-its: Use MADT ITS subtable to do PCI/MSI domain initialization Tomasz Nowicki
2016-09-06  9:08   ` 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=57D6A7DD.1060305@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=al.stone@linaro.org \
    --cc=andrea.gallo@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=graeme.gregory@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=helgaas@kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mw@semihalf.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=robert.richter@caviumnetworks.com \
    --cc=shijie.huang@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tn@semihalf.com \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.