Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Thursday, July 21, 2016 01:25:53 AM Lukas Wunner wrote: > On Thu, Jul 21, 2016 at 12:51:31AM +0200, Rafael J. Wysocki wrote: > > On Wednesday, July 20, 2016 05:23:40 PM Lukas Wunner wrote: > > > On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote: > > > > On Wednesday, July 20,

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Thu, Jul 21, 2016 at 12:51:31AM +0200, Rafael J. Wysocki wrote: > On Wednesday, July 20, 2016 05:23:40 PM Lukas Wunner wrote: > > On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote: > > > On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote: > > > > On Wed, Jul 20, 2016 at

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Wednesday, July 20, 2016 05:23:40 PM Lukas Wunner wrote: > On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote: > > On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote: > > > On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote: > > > > On Friday, June 17, 2016

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote: > On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote: > > On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote: > > > On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote: > > > > On Fri, Jun 17, 2016 at

Re: [RFC PATCH] iommu: create direct_mapping after device attached

On Wed, Jul 20, 2016 at 08:49:21PM +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > For mtk iommu, the domain_finalize was called in device attatch, the mtk > iommu iopgt ops was allocated and initialized in domain_finalize, the >

[RFC PATCH] iommu: create direct_mapping after device attached

From: Honghui Zhang For mtk iommu, the domain_finalize was called in device attatch, the mtk iommu iopgt ops was allocated and initialized in domain_finalize, the iommu_group_create_direct_mappings would call the map interface to implement the map. If it's earlier

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote: > On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote: > > On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote: > > > On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote: > > > > On Fri, Jun 17, 2016 at

Re: [PATCH v11 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

On Wed, Jul 20, 2016 at 01:03:00PM +0200, Auger Eric wrote: > Hi Dennis > On 20/07/2016 11:56, Dennis Chen wrote: > > Hi Eric, > > > > On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote: > >> This series introduces the msi-iommu api used to: > >> > >> - allocate/free resources for MSI

Re: [PATCH v11 4/8] iommu/msi-iommu: initialization

Hi Eric, Some small questions/comments below: On Tue, Jul 19, 2016 at 12:55:07PM +, Eric Auger wrote: > iommu_get/put_msi_cookie allocates/frees the resource used to store > and ref count the MSI doorbell mappings. iommu_msi_set_aperture > initializes the iova domain used for MSI IOVA

[RFC PATCH v3 12/13] drivers: acpi: iort: replace rid map type with type mask

IORT tables provide data that allow the kernel to carry out device ID mappings between endpoints and system components (eg interrupt controllers, IOMMUs). When the mapping for a given device ID is carried out, the translation mechanism is done on a per-subsystem basis rather than a component

[RFC PATCH v3 13/13] drivers: acpi: iort: introduce iort_iommu_configure

DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the

[RFC PATCH v3 11/13] drivers: iommu: arm-smmu-v3: add IORT platform device creation

In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU v3 components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU v3 components. Add static

[RFC PATCH v3 03/13] drivers: acpi: iort: add support for IOMMU fwnode registration

The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective fwnode.

[RFC PATCH v3 08/13] drivers: acpi: iort: add support for ARM SMMU platform devices creation

In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

[RFC PATCH v3 06/13] drivers: acpi: implement acpi_dma_configure

On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

[RFC PATCH v3 10/13] drivers: iommu: arm-smmu-v3: enable ACPI driver initialization

On systems booting with ACPI that enable the ARM SMMU components in the kernel config options, the ARM SMMU v3 init function (ie arm_smmu_init(), that registers the driver and sets-up bus iommu operations) does not run only because the device tree interface (of_find_matching_node()) fails to find

[RFC PATCH v3 09/13] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[RFC PATCH v3 07/13] drivers: acpi: iort: add node match function

Device drivers (eg ARM SMMU) need to know if a specific component is part of the IORT table, so that kernel data structures are not initialized at initcalls time if the respective component is not part of the IORT table. To this end, this patch adds a trivial function that allows detecting if a

[RFC PATCH v3 05/13] drivers: iommu: make iommu_fwspec OF agnostic

The iommu_fwspec structure, used to hold per device iommu configuration data is not OF specific and therefore can be moved to a generic and OF independent compilation unit. In particular, the iommu_fwspec handling hinges on the device_node pointer to identify the IOMMU device associated with the

[RFC PATCH v3 02/13] drivers: acpi: iort: introduce linker section for IORT entries probing

Since commit e647b532275b ("ACPI: Add early device probing infrastructure") the kernel has gained the infrastructure that allows adding linker script section entries to execute ACPI driver callbacks (ie probe routines) for all subsystems that register a table entry in the respective kernel section

[RFC PATCH v3 01/13] drivers: iommu: add FWNODE_IOMMU fwnode type

On systems booting with a device tree, every struct device is associated with a struct device_node, that represents its DT representation. The device node can be used in generic kernel contexts (eg IRQ translation, IOMMU streamid mapping), to retrieve the properties associated with the device and

[RFC PATCH v3 04/13] drivers: platform: add fwnode base platform devices retrieval

The platform device kernel API does not provide functions to retrieve a platform device through the corresponding struct device fwnode pointer. Implement the fwnode platform_device look-up in drivers core code by using the bus_find_device() API and a corresponding matching function. The OF

[RFC PATCH v3 00/13] ACPI IORT ARM SMMU v3 support

This RFC patch series is v3 of a previous posting: https://lkml.org/lkml/2016/6/7/523 v2 -> v3 - Rebased on top of dependencies series [1][2][3](v4.7-rc3) - Added back reliance on ACPI early probing infrastructure - Patch[1-3] merged through other dependent series

Re: [PATCH v11 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

Hi Dennis On 20/07/2016 11:56, Dennis Chen wrote: > Hi Eric, > > On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote: >> This series introduces the msi-iommu api used to: >> >> - allocate/free resources for MSI IOMMU mapping >> - set the MSI iova window aperture >> - map/unmap physical

Re: [PATCH v11 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

Hi Eric, On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote: > This series introduces the msi-iommu api used to: > > - allocate/free resources for MSI IOMMU mapping > - set the MSI iova window aperture > - map/unmap physical addresses onto MSI IOVAs. > - determine whether an msi needs to

Re: [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested

On Tue, 19 Jul 2016, Eric Auger wrote: First of all - valid for all patches: Subject: sys/subsys: Sentence starts with an uppercase letter Now for this particular one: genirq/msi: use the MSI doorbell's IOVA when requested > On MSI message composition we now use the MSI doorbell's IOVA in >

Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

On Tue, 19 Jul 2016, Eric Auger wrote: > /** > + * msi_handle_doorbell_mappings: in case the irq data corresponds to an > + * MSI that requires iommu mapping, traverse the irq domain hierarchy > + * to retrieve the doorbells to handle and iommu_map/unmap them according > + * to @map boolean. > +

Re: [PATCH v11 06/10] genirq/msi-doorbell: msi_doorbell_safe

On Tue, 19 Jul 2016, Eric Auger wrote: > +bool msi_doorbell_safe(void) > +{ > + struct irqchip_doorbell *db; > + bool irq_remapping = true; > + > + mutex_lock(_doorbell_mutex); > + list_for_each_entry(db, _doorbell_list, next) { > + irq_remapping &=

Re: [PATCH v11 05/10] genirq/msi-doorbell: msi_doorbell_pages

Hi Thomas, On 19/07/2016 16:38, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> msi_doorbell_pages sum up the number of iommu pages of a given order > > adding () to the function name would make it immediately clear that > msi_doorbell_pages is a function. > >> +/** >> + *

Re: [PATCH v11 04/10] genirq/msi-doorbell: allow MSI doorbell (un)registration

Hi Thomas, On 19/07/2016 16:22, Thomas Gleixner wrote: > On Tue, 19 Jul 2016, Eric Auger wrote: >> + >> +#include >> +#include >> +#include >> + >> +struct irqchip_doorbell { >> +struct irq_chip_msi_doorbell_info info; >> +struct list_head next; > > Again, please align the struct

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote: > On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote: > > On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote: > > > On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote: > > > > On Fri, Jun 17,