From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:04:07
The series builds the PCI/MSI domain stack based on initial IORT driver
which is added in first place. As a reference please see IORT spec:
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Tested on Cavium ThunderX server. The patches can be found here:
https://github.com/semihalf-nowicki-tomasz/linux.git (its-acpi-v7)
v6 -> v7
- rebased against irq/irqchip-4.8
- improvements for IORT ID mapping
- call IORT init call from acpi_init() instead of arch_initcall()
- split IORT driver in to two parts: core and ITS/MSI
v5 -> v6
- added locking mechanism for IORT list with domain token
- IORT function name improvements
- extended IORT RID mapping helper
- reworked IORT to be more SMMU friendly
- IORT functions which map RID and find corresponding domain are not
PCI specific any more (struct pci_dev -> struct device)
- bug fixes
v4 -> v5
- rebased against v4.7-rc1
- drop generic layer and call IORT functions directly
- improve resource abstraction and string formatting
v3 -> v4
- rebased against v4.5
- add ACPI support for IRQ domain handling on a per-device basis
- reorder domain setup step
- improve error handling
- code style improvements
v2 -> v3
- rebased on top of 4.4
- fixes and improvements for redistributor init via GICC structures
- fixes as per kbuild reports
v1 -> v2
- rebased on top of 4.4-rc4
- use pci_msi_domain_get_msi_rid for requester ID to device ID translation
Tomasz Nowicki (8):
ACPI: I/O Remapping Table (IORT) initial support
ACPI: Add new IORT functions to support MSI domain handling
PCI/MSI: Setup MSI domain on a per-device basis using IORT ACPI table
irqchip/gicv3-its: Cleanup for ITS domain initialization
irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI
irqchip/gicv3-its: Probe ITS in the ACPI way
irqchip/gicv3-its: Factor out code that might be reused for ACPI
irqchip/gicv3-its: Use MADT ITS subtable to do PCI/MSI domain
initialization
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 389 +++++++++++++++++++++++++++++++
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 88 +++++--
drivers/irqchip/irq-gic-v3-its.c | 169 ++++++++++----
drivers/irqchip/irq-gic-v3.c | 7 +-
drivers/pci/msi.c | 11 +-
include/linux/iort.h | 41 ++++
include/linux/irqchip/arm-gic-v3.h | 4 +-
11 files changed, 646 insertions(+), 70 deletions(-)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
--
1.9.1
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:04:18
It is possible to provide information about which MSI controller to
use on a per-device basis for DT. This patch supply this with ACPI support.
Currently, IORT is the only one ACPI table which can provide such mapping.
In order to plug IORT into MSI infrastructure we are adding ACPI
equivalents for finding PCI device domain and its RID translation
(pci_msi_domain_get_msi_rid and pci_msi_domain_get_msi_rid calls).
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/pci/msi.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:04:30
There is no point to initialize ITS without having msi-controller
property in corresponding DT node. However, its_probe is checking
msi-controller presence at the end, so we can save our time and do that
check prior to its_probe call. Also, for the code clarity purpose,
we put domain initialization to separate function.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/irq-gic-v3-its.c | 57 ++++++++++++++++++++++++----------------
1 file changed, 34 insertions(+), 23 deletions(-)
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:04:37
For ITS, MSI functionality consists on building domain stack and
during that process we need to reference to domain stack components
e.g. before we create new DOMAIN_BUS_PCI_MSI domain we need to specify
its DOMAIN_BUS_NEXUS parent domain. In order to manage that process
properly, maintain list which elements contain domain token
(unique for MSI domain stack) and ITS ID: iort_register_domain_token()
and iort_deregister_domain_token(). Then retrieve domain token
any time later with ITS ID being key off: iort_find_domain_token().
With domain token and domain type we are able to find corresponding
IRQ domain.
Since IORT is prepared to describe MSI domain on a per-device basis,
use existing IORT helpers and implement two calls:
1. iort_msi_map_rid() to map MSI RID for a device
2. iort_get_device_domain() to find domain token for a device
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/iort.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 11 ++++
2 files changed, 180 insertions(+)
@@ -22,12 +22,91 @@#include<linux/kernel.h>#include<linux/pci.h>+structiort_its_msi_chip{+structlist_headlist;+structfwnode_handle*fw_node;+u32translation_id;+};+typedefacpi_status(*iort_find_node_callback)(structacpi_iort_node*node,void*context);/* Root pointer to the mapped IORT table */staticstructacpi_table_header*iort_table;+staticLIST_HEAD(iort_msi_chip_list);+staticDEFINE_SPINLOCK(iort_msi_chip_lock);++/**+*iort_register_domain_token()-registerdomaintokenandrelatedITSID+*tothelistfromwherewecangetitbacklateron.+*@trans_id:ITSID.+*@fw_node:Domaintoken.+*+*Returns:0onsuccess,-ENOMEMifnomemorywhenallocatinglistelement+*/+intiort_register_domain_token(inttrans_id,structfwnode_handle*fw_node)+{+structiort_its_msi_chip*its_msi_chip;++its_msi_chip=kzalloc(sizeof(*its_msi_chip),GFP_KERNEL);+if(!its_msi_chip)+return-ENOMEM;++its_msi_chip->fw_node=fw_node;+its_msi_chip->translation_id=trans_id;++spin_lock(&iort_msi_chip_lock);+list_add(&its_msi_chip->list,&iort_msi_chip_list);+spin_unlock(&iort_msi_chip_lock);++return0;+}++/**+*iort_deregister_domain_token()-DeregisterdomaintokenbasedonITSID+*@trans_id:ITSID.+*+*Returns:none.+*/+voidiort_deregister_domain_token(inttrans_id)+{+structiort_its_msi_chip*its_msi_chip,*t;++spin_lock(&iort_msi_chip_lock);+list_for_each_entry_safe(its_msi_chip,t,&iort_msi_chip_list,list){+if(its_msi_chip->translation_id==trans_id){+list_del(&its_msi_chip->list);+kfree(its_msi_chip);+break;+}+}+spin_unlock(&iort_msi_chip_lock);+}++/**+*iort_find_domain_token()-FinddomaintokenbasedongivenITSID+*@trans_id:ITSID.+*+*Returns:domaintokenwhenfindonthelist,NULLotherwise+*/+structfwnode_handle*iort_find_domain_token(inttrans_id)+{+structfwnode_handle*fw_node=NULL;+structiort_its_msi_chip*its_msi_chip;++spin_lock(&iort_msi_chip_lock);+list_for_each_entry(its_msi_chip,&iort_msi_chip_list,list){+if(its_msi_chip->translation_id==trans_id){+fw_node=its_msi_chip->fw_node;+break;+}+}+spin_unlock(&iort_msi_chip_lock);++returnfw_node;+}+staticstructacpi_iort_node*iort_scan_node(enumacpi_iort_node_typetype,iort_find_node_callbackcallback,void*context)
@@ -205,6 +284,96 @@ iort_find_dev_node(struct device *dev)iort_match_node_callback,&pbus->dev);}+/**+*iort_msi_map_rid()-MapaMSIrequesterIDforadevice+*@dev:Thedeviceforwhichthemappingistobedone.+*@req_id:ThedevicerequesterID.+*+*Returns:mappedMSIRIDonsuccess,inputrequesterIDotherwise+*/+u32iort_msi_map_rid(structdevice*dev,u32req_id)+{+structacpi_iort_node*node;+u32dev_id;++if(!iort_table)+returnreq_id;++node=iort_find_dev_node(dev);+if(!node){+dev_err(dev,"can't find related IORT node\n");+returnreq_id;+}++iort_node_map_rid(node,req_id,&dev_id,ACPI_IORT_NODE_ITS_GROUP);+returndev_id;+}++/**+*iort_dev_find_its_id()-FindtheITSidentifierforadevice+*@dev:Thedevice.+*@idx:IndexoftheITSidentifierlist.+*@its_id:ITSidentifier.+*+*Returns:0onsuccess,appropriateerrorvalueotherwise+*/+staticint+iort_dev_find_its_id(structdevice*dev,u32req_id,unsignedintidx,+int*its_id)+{+structacpi_iort_its_group*its;+structacpi_iort_node*node;++node=iort_find_dev_node(dev);+if(!node){+dev_err(dev,"can't find related IORT node\n");+return-ENXIO;+}++node=iort_node_map_rid(node,req_id,NULL,ACPI_IORT_NODE_ITS_GROUP);+if(!node){+dev_err(dev,"can't find related ITS node\n");+return-ENXIO;+}++/* Move to ITS specific data */+its=(structacpi_iort_its_group*)node->node_data;+if(idx>its->its_count){+dev_err(dev,"requested ITS ID index [%d] is greater than available [%d]\n",+idx,its->its_count);+return-ENXIO;+}++*its_id=its->identifiers[idx];+return0;+}++/**+*iort_get_device_domain()-FindMSIdomainrelatedtoadevice+*@dev:Thedevice.+*@req_id:RequesterIDforthedevice.+*+*Returns:theMSIdomainforthisdevice,NULLotherwise+*/+structirq_domain*+iort_get_device_domain(structdevice*dev,u32req_id)+{+staticstructfwnode_handle*handle;+intits_id;++if(!iort_table)+returnNULL;++if(iort_dev_find_its_id(dev,req_id,0,&its_id))+returnNULL;++handle=iort_find_domain_token(its_id);+if(!handle)+returnNULL;++returnirq_find_matching_fwnode(handle,DOMAIN_BUS_PCI_MSI);+}+void__initiort_table_detect(void){acpi_statusstatus;
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:04:44
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.
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 256 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o# processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,220 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+break;+}++if(!strcmp(ncomp->device_name,(char*)buffer.pointer))+returnAE_OK;++break;+}+caseACPI_IORT_NODE_PCI_ROOT_COMPLEX:{+structacpi_iort_root_complex*pci_rc;+structpci_bus*bus;++bus=to_pci_bus(dev);+pci_rc=(structacpi_iort_root_complex*)node->node_data;++/*+*ItisassumedthatPCIsegmentnumbersmapsone-to-one+*withrootcomplexes.Eachsegmentnumbercanrepresentonly+*onerootcomplex.+*/+if(pci_rc->pci_segment_number==pci_domain_nr(bus))+returnAE_OK;++break;+}+}++returnAE_NOT_FOUND;+}++staticint+iort_id_map(structacpi_iort_id_mapping*map,u8type,u32rid_in,u32*rid_out)+{+if(!rid_out)+return-EINVAL;++/* Single mapping does not care for input id */+if(map->flags&ACPI_IORT_ID_SINGLE_MAPPING){+if(type==ACPI_IORT_NODE_NAMED_COMPONENT||+type==ACPI_IORT_NODE_PCI_ROOT_COMPLEX){+*rid_out=map->output_base;+return0;+}++pr_warn(FW_BUG"[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",+map,type);+return-ENXIO;+}++if(rid_in<map->input_base||+(rid_in>map->input_base+map->id_count))+return-ENXIO;++*rid_out=map->output_base+(rid_in-map->input_base);+return0;+}++staticstructacpi_iort_node*+iort_node_map_rid(structacpi_iort_node*node,u32rid_in,+u32*rid_out,u8type)+{+u32rid=rid_in;+intfound=0;++/* Climb up ID mapping tree to find specified node type */+while(node&&node->type!=type){+structacpi_iort_id_mapping*map;+inti;++if(!node->mapping_offset||!node->mapping_count){+node=NULL;+break;+}++map=ACPI_ADD_PTR(structacpi_iort_id_mapping,node,+node->mapping_offset);++/* Firmware bug! */+if(!map->output_reference){+pr_err(FW_BUG"[node %p type %d] ID map has NULL parent reference\n",+node,node->type);+node=NULL;+break;+}++/* Do the RID translation */+for(i=0;i<node->mapping_count;i++,map++){+if(!iort_id_map(map,node->type,rid,&rid)){+found=1;+break;+}+}++if(!found){+node=NULL;+break;+}++node=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+map->output_reference);+}++/* Take input RID as output RID in case of any error */+if(rid_out)+*rid_out=node?rid:rid_in;+returnnode;+}++staticstructacpi_iort_node*+iort_find_dev_node(structdevice*dev)+{+structpci_bus*pbus;++if(!dev_is_pci(dev))+returniort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,+iort_match_node_callback,dev);++/* Find a PCI root bus */+pbus=to_pci_dev(dev)->bus;+while(!pci_is_root_bus(pbus))+pbus=pbus->parent;++returniort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,+iort_match_node_callback,&pbus->dev);+}++void__initiort_table_detect(void)+{+acpi_statusstatus;++if(acpi_disabled)+return;++status=acpi_get_table(ACPI_SIG_IORT,0,&iort_table);+if(ACPI_FAILURE(status)&&status!=AE_NOT_FOUND){+constchar*msg=acpi_format_exception(status);+pr_err("Failed to get table, %s\n",msg);+}+}
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:05:40
Let ACPI build ITS PCI MSI domain. ACPI code is responsible for retrieving
inner domain token and passing it on to its_pci_msi_init_one generic
init call.
IORT maintains list of registered domain tokens and allows to find
corresponding domain based on MADT ITS subtable ID info.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 ++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
@@ -144,9 +145,52 @@ static int __init its_pci_of_msi_init(void)return0;}+#ifdef CONFIG_ACPI++staticint__init+its_pci_msi_parse_madt(structacpi_subtable_header*header,+constunsignedlongend)+{+structacpi_madt_generic_translator*its_entry;+structfwnode_handle*dom_handle;+constchar*node_name;+interr=-ENXIO;++its_entry=(structacpi_madt_generic_translator*)header;+node_name=kasprintf(GFP_KERNEL,"ITS at 0x%lx",+(long)its_entry->base_address);+dom_handle=iort_find_domain_token(its_entry->translation_id);+if(!dom_handle){+pr_err("%s: Unable to locate ITS domain handle\n",node_name);+gotoout;+}++err=its_pci_msi_init_one(dom_handle,node_name);+if(!err)+pr_info("PCI/MSI: %s domain created\n",node_name);++out:+kfree(node_name);+returnerr;+}++staticint__initits_pci_acpi_msi_init(void)+{+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,+its_pci_msi_parse_madt,0);+return0;+}+#else+staticint__initits_pci_acpi_msi_init(void)+{+return0;+}+#endif+staticint__initits_pci_msi_init(void){its_pci_of_msi_init();+its_pci_acpi_msi_init();return0;}
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:05:48
Firmware agnostic code lands in common functions which do necessary
domain initialization based on unique domain handler. DT specific
code goes to DT specific init call.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 +++++++++++++++++++++-----------
1 file changed, 29 insertions(+), 15 deletions(-)
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:05:54
ITS is prepared for being initialized different than DT,
therefore we can initialize it in ACPI way. We collect register base
address from MADT table and pass mandatory info to firmware-agnostic
ITS init call.
Use here IORT lib to register ITS domain which then can be found and
used on to build another PCI MSI domain in hierarchical stack domain.
NOTE: Waiting for proper ITS and NUMA node relation description in IORT
table, we pass around NUMA_NO_NODE to the its_probe_one init call.
This means that Cavium ThunderX erratum 23144 (pass1.1 only)
is not supported for ACPI boot method yet.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic-v3-its.c | 59 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 1 deletion(-)
@@ -1438,6 +1441,11 @@ static int its_irq_gic_domain_alloc(struct irq_domain *domain,fwspec.param[0]=GIC_IRQ_TYPE_LPI;fwspec.param[1]=hwirq;fwspec.param[2]=IRQ_TYPE_EDGE_RISING;+}elseif(is_fwnode_irqchip(domain->parent->fwnode)){+fwspec.fwnode=domain->parent->fwnode;+fwspec.param_count=2;+fwspec.param[0]=hwirq;+fwspec.param[1]=IRQ_TYPE_EDGE_RISING;}else{return-EINVAL;}
@@ -1792,6 +1800,55 @@ static int __init its_of_probe(struct device_node *node)return0;}+#ifdef CONFIG_ACPI++#define ACPI_GICV3_ITS_MEM_SIZE (SZ_128K)++staticint__initgic_acpi_parse_madt_its(structacpi_subtable_header*header,+constunsignedlongend)+{+structacpi_madt_generic_translator*its_entry;+structfwnode_handle*dom_handle;+structresourceres;+interr;++its_entry=(structacpi_madt_generic_translator*)header;+res.start=its_entry->base_address;+res.end=its_entry->base_address+ACPI_GICV3_ITS_MEM_SIZE-1;++dom_handle=irq_domain_alloc_fwnode((void*)its_entry->base_address);+if(!dom_handle){+pr_err("ITS@%pa: Unable to allocate GICv3 ITS domain token\n",+&res.start);+return-ENOMEM;+}++err=iort_register_domain_token(its_entry->translation_id,dom_handle);+if(err){+pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",+&res.start,its_entry->translation_id);+gotodom_err;+}++err=its_probe_one(&res,dom_handle,NUMA_NO_NODE);+if(!err)+return0;++iort_deregister_domain_token(its_entry->translation_id);+dom_err:+irq_domain_free_fwnode(dom_handle);+returnerr;+}++staticvoid__initits_acpi_probe(void)+{+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,+gic_acpi_parse_madt_its,0);+}+#else+staticvoid__initits_acpi_probe(void){}+#endif+int__initits_init(structfwnode_handle*handle,structrdists*rdists,structirq_domain*parent_domain){
@@ -1802,7 +1859,7 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,if(of_node)its_of_probe(of_node);else-return-ENODEV;+its_acpi_probe();if(list_empty(&its_nodes)){pr_warn("ITS: No ITS available, not enabling LPIs\n");
From: Tomasz Nowicki <hidden> Date: 2016-06-20 11:06:00
In order to add ACPI support we need to isolate ACPI&DT common code and
move DT logic to corresponding functions. To achieve this we are using
firmware agnostic handle which can be unpacked to either DT or ACPI node.
No functional changes other than a very minor one:
1. Terminate its_init call with -ENODEV for non-DT case which allows
to remove hack from its-gic-v3.c.
2. Fix ITS base register address type (from 'unsigned long' to 'phys_addr_t'),
as a bonus we get nice string formatting.
3. Since there is only one of ITS parent domain convert it to static global
variable and drop the parameter from its_probe_one. Users can refer to it
in more convenient way then.
Signed-off-by: Hanjun Guo <redacted>
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/irqchip/irq-gic-v3-its.c | 65 ++++++++++++++++++++++----------------
drivers/irqchip/irq-gic-v3.c | 7 ++--
include/linux/irqchip/arm-gic-v3.h | 4 +--
3 files changed, 42 insertions(+), 34 deletions(-)
@@ -1634,43 +1634,35 @@ static int its_init_domain(struct device_node *node, struct its_node *its,return0;}-staticint__initits_probe(structdevice_node*node,-structirq_domain*parent)+staticint__initits_probe_one(structresource*res,+structfwnode_handle*handle,intnuma_node){-structresourceres;structits_node*its;void__iomem*its_base;u32val;u64baser,tmp;interr;-err=of_address_to_resource(node,0,&res);-if(err){-pr_warn("%s: no regs?\n",node->full_name);-return-ENXIO;-}--its_base=ioremap(res.start,resource_size(&res));+its_base=ioremap(res->start,resource_size(res));if(!its_base){-pr_warn("%s: unable to map registers\n",node->full_name);+pr_warn("ITS@%pa: Unable to map ITS registers\n",&res->start);return-ENOMEM;}val=readl_relaxed(its_base+GITS_PIDR2)&GIC_PIDR2_ARCH_MASK;if(val!=0x30&&val!=0x40){-pr_warn("%s: no ITS detected, giving up\n",node->full_name);+pr_warn("ITS@%pa: No ITS detected, giving up\n",&res->start);err=-ENODEV;gotoout_unmap;}err=its_force_quiescent(its_base);if(err){-pr_warn("%s: failed to quiesce, giving up\n",-node->full_name);+pr_warn("ITS@%pa: Failed to quiesce, giving up\n",&res->start);gotoout_unmap;}-pr_info("ITS: %s\n",node->full_name);+pr_info("ITS@%pa\n",&res->start);its=kzalloc(sizeof(*its),GFP_KERNEL);if(!its){
@@ -1682,9 +1674,9 @@ static int __init its_probe(struct device_node *node,INIT_LIST_HEAD(&its->entry);INIT_LIST_HEAD(&its->its_device_list);its->base=its_base;-its->phys_base=res.start;+its->phys_base=res->start;its->ite_size=((readl_relaxed(its_base+GITS_TYPER)>>4)&0xf)+1;-its->numa_node=of_node_to_nid(node);+its->numa_node=numa_node;its->cmd_base=kzalloc(ITS_CMD_QUEUE_SZ,GFP_KERNEL);if(!its->cmd_base){
@@ -1731,7 +1723,7 @@ static int __init its_probe(struct device_node *node,writeq_relaxed(0,its->base+GITS_CWRITER);writel_relaxed(GITS_CTLR_ENABLE,its->base+GITS_CTLR);-err=its_init_domain(node,its,parent);+err=its_init_domain(handle,its);if(err)gotoout_free_tables;
@@ -1790,8 +1782,27 @@ int __init its_init(struct device_node *node, struct rdists *rdists,continue;}-its_probe(np,parent_domain);+if(of_address_to_resource(np,0,&res)){+pr_warn("%s: no regs?\n",np->full_name);+continue;+}++its_probe_one(&res,&np->fwnode,of_node_to_nid(np));}+return0;+}++int__initits_init(structfwnode_handle*handle,structrdists*rdists,+structirq_domain*parent_domain)+{+structdevice_node*of_node;++its_parent=parent_domain;+of_node=to_of_node(handle);+if(of_node)+its_of_probe(of_node);+else+return-ENODEV;if(list_empty(&its_nodes)){pr_warn("ITS: No ITS available, not enabling LPIs\n");
@@ -911,7 +911,6 @@ static int __init gic_init_bases(void __iomem *dist_base,u64redist_stride,structfwnode_handle*handle){-structdevice_node*node;u32typer;intgic_irqs;interr;
@@ -952,10 +951,8 @@ static int __init gic_init_bases(void __iomem *dist_base,set_handle_irq(gic_handle_irq);-node=to_of_node(handle);-if(IS_ENABLED(CONFIG_ARM_GIC_V3_ITS)&&gic_dist_supports_lpis()&&-node)/* Temp hack to prevent ITS init for ACPI */-its_init(node,&gic_data.rdists,gic_data.domain);+if(IS_ENABLED(CONFIG_ARM_GIC_V3_ITS)&&gic_dist_supports_lpis())+its_init(handle,&gic_data.rdists,gic_data.domain);gic_smp_init();gic_dist_init();
I have tested this patchset on Qualcomm Technologies server platform
QDF2XXX.
--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Hi Tomasz,
Sorry for jumping out late, just one comment below.
On 2016/6/20 19:02, 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.
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
For ITS, MSI functionality consists on building domain stack and
during that process we need to reference to domain stack components
e.g. before we create new DOMAIN_BUS_PCI_MSI domain we need to specify
its DOMAIN_BUS_NEXUS parent domain. In order to manage that process
properly, maintain list which elements contain domain token
(unique for MSI domain stack) and ITS ID: iort_register_domain_token()
and iort_deregister_domain_token(). Then retrieve domain token
any time later with ITS ID being key off: iort_find_domain_token().
With domain token and domain type we are able to find corresponding
IRQ domain.
Since IORT is prepared to describe MSI domain on a per-device basis,
use existing IORT helpers and implement two calls:
1. iort_msi_map_rid() to map MSI RID for a device
2. iort_get_device_domain() to find domain token for a device
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/iort.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 11 ++++
2 files changed, 180 insertions(+)
@@ -22,12 +22,91 @@#include<linux/kernel.h>#include<linux/pci.h>+structiort_its_msi_chip{+structlist_headlist;+structfwnode_handle*fw_node;+u32translation_id;+};+typedefacpi_status(*iort_find_node_callback)(structacpi_iort_node*node,void*context);/* Root pointer to the mapped IORT table */staticstructacpi_table_header*iort_table;+staticLIST_HEAD(iort_msi_chip_list);+staticDEFINE_SPINLOCK(iort_msi_chip_lock);++/**+*iort_register_domain_token()-registerdomaintokenandrelatedITSID+*tothelistfromwherewecangetitbacklateron.+*@trans_id:ITSID.+*@fw_node:Domaintoken.+*+*Returns:0onsuccess,-ENOMEMifnomemorywhenallocatinglistelement+*/+intiort_register_domain_token(inttrans_id,structfwnode_handle*fw_node)+{+structiort_its_msi_chip*its_msi_chip;++its_msi_chip=kzalloc(sizeof(*its_msi_chip),GFP_KERNEL);+if(!its_msi_chip)+return-ENOMEM;++its_msi_chip->fw_node=fw_node;+its_msi_chip->translation_id=trans_id;++spin_lock(&iort_msi_chip_lock);+list_add(&its_msi_chip->list,&iort_msi_chip_list);+spin_unlock(&iort_msi_chip_lock);++return0;+}++/**+*iort_deregister_domain_token()-DeregisterdomaintokenbasedonITSID+*@trans_id:ITSID.+*+*Returns:none.+*/+voidiort_deregister_domain_token(inttrans_id)+{+structiort_its_msi_chip*its_msi_chip,*t;++spin_lock(&iort_msi_chip_lock);+list_for_each_entry_safe(its_msi_chip,t,&iort_msi_chip_list,list){+if(its_msi_chip->translation_id==trans_id){+list_del(&its_msi_chip->list);+kfree(its_msi_chip);+break;+}+}+spin_unlock(&iort_msi_chip_lock);+}++/**+*iort_find_domain_token()-FinddomaintokenbasedongivenITSID+*@trans_id:ITSID.+*+*Returns:domaintokenwhenfindonthelist,NULLotherwise+*/+structfwnode_handle*iort_find_domain_token(inttrans_id)+{+structfwnode_handle*fw_node=NULL;+structiort_its_msi_chip*its_msi_chip;++spin_lock(&iort_msi_chip_lock);+list_for_each_entry(its_msi_chip,&iort_msi_chip_list,list){+if(its_msi_chip->translation_id==trans_id){+fw_node=its_msi_chip->fw_node;+break;+}+}+spin_unlock(&iort_msi_chip_lock);++returnfw_node;+}+staticstructacpi_iort_node*iort_scan_node(enumacpi_iort_node_typetype,iort_find_node_callbackcallback,void*context)
@@ -205,6 +284,96 @@ iort_find_dev_node(struct device *dev)iort_match_node_callback,&pbus->dev);}+/**+*iort_msi_map_rid()-MapaMSIrequesterIDforadevice+*@dev:Thedeviceforwhichthemappingistobedone.+*@req_id:ThedevicerequesterID.+*+*Returns:mappedMSIRIDonsuccess,inputrequesterIDotherwise+*/+u32iort_msi_map_rid(structdevice*dev,u32req_id)+{+structacpi_iort_node*node;+u32dev_id;++if(!iort_table)+returnreq_id;++node=iort_find_dev_node(dev);+if(!node){+dev_err(dev,"can't find related IORT node\n");+returnreq_id;+}++iort_node_map_rid(node,req_id,&dev_id,ACPI_IORT_NODE_ITS_GROUP);+returndev_id;+}++/**+*iort_dev_find_its_id()-FindtheITSidentifierforadevice+*@dev:Thedevice.+*@idx:IndexoftheITSidentifierlist.+*@its_id:ITSidentifier.+*+*Returns:0onsuccess,appropriateerrorvalueotherwise+*/+staticint+iort_dev_find_its_id(structdevice*dev,u32req_id,unsignedintidx,+int*its_id)+{+structacpi_iort_its_group*its;+structacpi_iort_node*node;++node=iort_find_dev_node(dev);+if(!node){+dev_err(dev,"can't find related IORT node\n");+return-ENXIO;+}++node=iort_node_map_rid(node,req_id,NULL,ACPI_IORT_NODE_ITS_GROUP);+if(!node){+dev_err(dev,"can't find related ITS node\n");+return-ENXIO;+}++/* Move to ITS specific data */+its=(structacpi_iort_its_group*)node->node_data;+if(idx>its->its_count){+dev_err(dev,"requested ITS ID index [%d] is greater than available [%d]\n",+idx,its->its_count);+return-ENXIO;+}++*its_id=its->identifiers[idx];+return0;+}++/**+*iort_get_device_domain()-FindMSIdomainrelatedtoadevice+*@dev:Thedevice.+*@req_id:RequesterIDforthedevice.+*+*Returns:theMSIdomainforthisdevice,NULLotherwise+*/+structirq_domain*+iort_get_device_domain(structdevice*dev,u32req_id)+{+staticstructfwnode_handle*handle;+intits_id;++if(!iort_table)+returnNULL;++if(iort_dev_find_its_id(dev,req_id,0,&its_id))+returnNULL;++handle=iort_find_domain_token(its_id);+if(!handle)+returnNULL;++returnirq_find_matching_fwnode(handle,DOMAIN_BUS_PCI_MSI);+}+void__initiort_table_detect(void){acpi_statusstatus;
It is possible to provide information about which MSI controller to
use on a per-device basis for DT. This patch supply this with ACPI support.
Currently, IORT is the only one ACPI table which can provide such mapping.
In order to plug IORT into MSI infrastructure we are adding ACPI
equivalents for finding PCI device domain and its RID translation
(pci_msi_domain_get_msi_rid and pci_msi_domain_get_msi_rid calls).
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/pci/msi.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
ITS is prepared for being initialized different than DT,
therefore we can initialize it in ACPI way. We collect register base
address from MADT table and pass mandatory info to firmware-agnostic
ITS init call.
Use here IORT lib to register ITS domain which then can be found and
used on to build another PCI MSI domain in hierarchical stack domain.
NOTE: Waiting for proper ITS and NUMA node relation description in IORT
table, we pass around NUMA_NO_NODE to the its_probe_one init call.
This means that Cavium ThunderX erratum 23144 (pass1.1 only)
is not supported for ACPI boot method yet.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic-v3-its.c | 59 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 1 deletion(-)
@@ -1438,6 +1441,11 @@ static int its_irq_gic_domain_alloc(struct irq_domain *domain,fwspec.param[0]=GIC_IRQ_TYPE_LPI;fwspec.param[1]=hwirq;fwspec.param[2]=IRQ_TYPE_EDGE_RISING;+}elseif(is_fwnode_irqchip(domain->parent->fwnode)){+fwspec.fwnode=domain->parent->fwnode;+fwspec.param_count=2;+fwspec.param[0]=hwirq;+fwspec.param[1]=IRQ_TYPE_EDGE_RISING;}else{return-EINVAL;}
@@ -1792,6 +1800,55 @@ static int __init its_of_probe(struct device_node *node)return0;}+#ifdef CONFIG_ACPI++#define ACPI_GICV3_ITS_MEM_SIZE (SZ_128K)++staticint__initgic_acpi_parse_madt_its(structacpi_subtable_header*header,+constunsignedlongend)+{+structacpi_madt_generic_translator*its_entry;+structfwnode_handle*dom_handle;+structresourceres;+interr;++its_entry=(structacpi_madt_generic_translator*)header;+res.start=its_entry->base_address;+res.end=its_entry->base_address+ACPI_GICV3_ITS_MEM_SIZE-1;++dom_handle=irq_domain_alloc_fwnode((void*)its_entry->base_address);+if(!dom_handle){+pr_err("ITS@%pa: Unable to allocate GICv3 ITS domain token\n",+&res.start);+return-ENOMEM;+}++err=iort_register_domain_token(its_entry->translation_id,dom_handle);+if(err){+pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",+&res.start,its_entry->translation_id);+gotodom_err;+}++err=its_probe_one(&res,dom_handle,NUMA_NO_NODE);+if(!err)+return0;++iort_deregister_domain_token(its_entry->translation_id);+dom_err:+irq_domain_free_fwnode(dom_handle);+returnerr;+}++staticvoid__initits_acpi_probe(void)+{+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,+gic_acpi_parse_madt_its,0);+}+#else+staticvoid__initits_acpi_probe(void){}+#endif+int__initits_init(structfwnode_handle*handle,structrdists*rdists,structirq_domain*parent_domain){
@@ -1802,7 +1859,7 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,if(of_node)its_of_probe(of_node);else-return-ENODEV;+its_acpi_probe();if(list_empty(&its_nodes)){pr_warn("ITS: No ITS available, not enabling LPIs\n");
There is no point to initialize ITS without having msi-controller
property in corresponding DT node. However, its_probe is checking
msi-controller presence at the end, so we can save our time and do that
check prior to its_probe call. Also, for the code clarity purpose,
we put domain initialization to separate function.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/irq-gic-v3-its.c | 57 ++++++++++++++++++++++++----------------
1 file changed, 34 insertions(+), 23 deletions(-)
Let ACPI build ITS PCI MSI domain. ACPI code is responsible for retrieving
inner domain token and passing it on to its_pci_msi_init_one generic
init call.
IORT maintains list of registered domain tokens and allows to find
corresponding domain based on MADT ITS subtable ID info.
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 ++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
@@ -144,9 +145,52 @@ static int __init its_pci_of_msi_init(void)return0;}+#ifdef CONFIG_ACPI++staticint__init+its_pci_msi_parse_madt(structacpi_subtable_header*header,+constunsignedlongend)+{+structacpi_madt_generic_translator*its_entry;+structfwnode_handle*dom_handle;+constchar*node_name;+interr=-ENXIO;++its_entry=(structacpi_madt_generic_translator*)header;+node_name=kasprintf(GFP_KERNEL,"ITS at 0x%lx",+(long)its_entry->base_address);+dom_handle=iort_find_domain_token(its_entry->translation_id);+if(!dom_handle){+pr_err("%s: Unable to locate ITS domain handle\n",node_name);+gotoout;+}++err=its_pci_msi_init_one(dom_handle,node_name);+if(!err)+pr_info("PCI/MSI: %s domain created\n",node_name);++out:+kfree(node_name);+returnerr;+}++staticint__initits_pci_acpi_msi_init(void)+{+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,+its_pci_msi_parse_madt,0);+return0;+}+#else+staticint__initits_pci_acpi_msi_init(void)+{+return0;+}+#endif+staticint__initits_pci_msi_init(void){its_pci_of_msi_init();+its_pci_acpi_msi_init();return0;}
From: Lorenzo Pieralisi <hidden> Date: 2016-06-21 11:23:13
On Mon, Jun 20, 2016 at 01:02:14PM +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.
Add the spec link if you want a reference to it otherwise "Also see IORT spec"
is pretty much useless.
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.
We still need Rafael's feeback on this.
For the aforementioned reason call iort_table_detect() from acpi_init()
which guarantees acpi_gbl_permanent_mmap to be set at that point.
Ditto.
quoted hunk
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 256 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o# processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -1118,6 +1119,7 @@ static int __init acpi_init(void)}pci_mmcfg_late_init();+iort_table_detect();
IORT is arch specific (and empty on any system other than ARM64), this call
here is fine by me because it provides us the ordering we need (ie
initialize the IORT table pointers before we start running scan handlers),
we need Rafael's feeback on this though.
[...]
+static int
+iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in, u32 *rid_out)
+{
+ if (!rid_out)
+ return -EINVAL;
Nit: It is an internal function honestly I do not see the need for
this check here, it is close to paranoia.
+ /* Single mapping does not care for input id */
+ if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
+ if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
+ type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
+ *rid_out = map->output_base;
+ return 0;
+ }
+
+ pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
+ map, type);
+ return -ENXIO;
+ }
+
+ if (rid_in < map->input_base ||
+ (rid_in > map->input_base + map->id_count))
+ return -ENXIO;
+
+ *rid_out = map->output_base + (rid_in - map->input_base);
+ return 0;
+}
+
+static struct acpi_iort_node *
+iort_node_map_rid(struct acpi_iort_node *node, u32 rid_in,
+ u32 *rid_out, u8 type)
+{
+ u32 rid = rid_in;
+ int found = 0;
+
+ /* Climb up ID mapping tree to find specified node type */
s/Climb/Parse the/
+ while (node && node->type != type) {
+ struct acpi_iort_id_mapping *map;
+ int i;
+
+ if (!node->mapping_offset || !node->mapping_count) {
+ node = NULL;
+ break;
+ }
+
+ map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
+ node->mapping_offset);
+
+ /* Firmware bug! */
+ if (!map->output_reference) {
+ pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
+ node, node->type);
+ node = NULL;
+ break;
+ }
+
+ /* Do the RID translation */
+ for (i = 0; i < node->mapping_count; i++, map++) {
+ if(!iort_id_map(map, node->type, rid, &rid)) {
+ found = 1;
You do not reset found to 0, for next iteration. I still think this function
is too complicated.
You could even remove "found" altogether:
if (i == node->mapping_count)
goto fail_map;
fail_map:
/* Map input RID to output RID unchanged on mapping failure*/
*rid_out = rid_in;
return NULL;
At least it is clear what you return when.
+
+ node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
+ }
+
+ /* Take input RID as output RID in case of any error */
+ if (rid_out)
+ *rid_out = node ? rid : rid_in;
+ return node;
+}
+
+static struct acpi_iort_node *
+iort_find_dev_node(struct device *dev)
+{
+ struct pci_bus *pbus;
+
+ if (!dev_is_pci(dev))
+ return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
+ iort_match_node_callback, dev);
+
+ /* Find a PCI root bus */
+ pbus = to_pci_dev(dev)->bus;
+ while (!pci_is_root_bus(pbus))
+ pbus = pbus->parent;
+
+ return iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
+ iort_match_node_callback, &pbus->dev);
+}
+
+void __init iort_table_detect(void)
+{
+ acpi_status status;
+
+ if (acpi_disabled)
+ return;
Nit: if you are here acpi_disabled == false, so this check is
pointless.
+ status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
+ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+ const char *msg = acpi_format_exception(status);
+ pr_err("Failed to get table, %s\n", msg);
+ }
We really need to know if relying on iort_table to stay mapped
is a valid approach, it seems to me that the answer is yes
given that that's how eg DMAR is handled on x86 but we need
an acknowledgment from Rafael on this.
Other than that and my minor comments above (inclusive of Hanjun's
bug fix for iort_match_node_callback(), I did not reiterate that comment
but we have to fix it) patch seems fine.
Lorenzo
From: Lorenzo Pieralisi <hidden> Date: 2016-06-21 17:36:26
Hi Rafael,
On Mon, Jun 20, 2016 at 01:02:14PM +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.
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.
This moot point has become a blocker for this patchset and we need
your feedback please. I noticed that x86 code (drivers/iommu/dmar.c)
makes the same assumption (ie a table pointer, dmar_tbl, retrieved
through acpi_get_table_with_size() can be stashed in a global variable
and reused in functions like dmar_acpi_dev_scope_init() and
dmar_ir_support() without going through the ACPI API to retrieve
it again.
Is this a valid assumption ? This patch relies on it, since
otherwise it would become quite unwieldy (and unnecessary) to
create a cache of IORT nodes entries, so if we can retrieve the
table pointer through acpi_get_table_size() in iort_table_detect()
and stash it for further use that would make things much simpler
(as they are in the current patch).
I think that's the whole point behind acpi_gbl_permanent_mmap,
if that's set the corresponding tables pointers can be considered
permanently mapped, we really need to know if that's a reliable
assumption to make progress.
Thanks,
Lorenzo
quoted hunk
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 256 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o# processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,220 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+break;+}++if(!strcmp(ncomp->device_name,(char*)buffer.pointer))+returnAE_OK;++break;+}+caseACPI_IORT_NODE_PCI_ROOT_COMPLEX:{+structacpi_iort_root_complex*pci_rc;+structpci_bus*bus;++bus=to_pci_bus(dev);+pci_rc=(structacpi_iort_root_complex*)node->node_data;++/*+*ItisassumedthatPCIsegmentnumbersmapsone-to-one+*withrootcomplexes.Eachsegmentnumbercanrepresentonly+*onerootcomplex.+*/+if(pci_rc->pci_segment_number==pci_domain_nr(bus))+returnAE_OK;++break;+}+}++returnAE_NOT_FOUND;+}++staticint+iort_id_map(structacpi_iort_id_mapping*map,u8type,u32rid_in,u32*rid_out)+{+if(!rid_out)+return-EINVAL;++/* Single mapping does not care for input id */+if(map->flags&ACPI_IORT_ID_SINGLE_MAPPING){+if(type==ACPI_IORT_NODE_NAMED_COMPONENT||+type==ACPI_IORT_NODE_PCI_ROOT_COMPLEX){+*rid_out=map->output_base;+return0;+}++pr_warn(FW_BUG"[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",+map,type);+return-ENXIO;+}++if(rid_in<map->input_base||+(rid_in>map->input_base+map->id_count))+return-ENXIO;++*rid_out=map->output_base+(rid_in-map->input_base);+return0;+}++staticstructacpi_iort_node*+iort_node_map_rid(structacpi_iort_node*node,u32rid_in,+u32*rid_out,u8type)+{+u32rid=rid_in;+intfound=0;++/* Climb up ID mapping tree to find specified node type */+while(node&&node->type!=type){+structacpi_iort_id_mapping*map;+inti;++if(!node->mapping_offset||!node->mapping_count){+node=NULL;+break;+}++map=ACPI_ADD_PTR(structacpi_iort_id_mapping,node,+node->mapping_offset);++/* Firmware bug! */+if(!map->output_reference){+pr_err(FW_BUG"[node %p type %d] ID map has NULL parent reference\n",+node,node->type);+node=NULL;+break;+}++/* Do the RID translation */+for(i=0;i<node->mapping_count;i++,map++){+if(!iort_id_map(map,node->type,rid,&rid)){+found=1;+break;+}+}++if(!found){+node=NULL;+break;+}++node=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+map->output_reference);+}++/* Take input RID as output RID in case of any error */+if(rid_out)+*rid_out=node?rid:rid_in;+returnnode;+}++staticstructacpi_iort_node*+iort_find_dev_node(structdevice*dev)+{+structpci_bus*pbus;++if(!dev_is_pci(dev))+returniort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,+iort_match_node_callback,dev);++/* Find a PCI root bus */+pbus=to_pci_dev(dev)->bus;+while(!pci_is_root_bus(pbus))+pbus=pbus->parent;++returniort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,+iort_match_node_callback,&pbus->dev);+}++void__initiort_table_detect(void)+{+acpi_statusstatus;++if(acpi_disabled)+return;++status=acpi_get_table(ACPI_SIG_IORT,0,&iort_table);+if(ACPI_FAILURE(status)&&status!=AE_NOT_FOUND){+constchar*msg=acpi_format_exception(status);+pr_err("Failed to get table, %s\n",msg);+}+}
From: Marc Zyngier <hidden> Date: 2016-06-22 10:50:48
On 21/06/16 08:12, Hanjun Guo wrote:
Hi Tomasz,
Sorry for jumping out late, just one comment below.
On 2016/6/20 19:02, Tomasz Nowicki wrote:
quoted
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.
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
From: Tomasz Nowicki <hidden> Date: 2016-06-22 11:06:12
On 22.06.2016 12:50, Marc Zyngier wrote:
quoted hunk
On 21/06/16 08:12, Hanjun Guo wrote:
quoted
Hi Tomasz,
Sorry for jumping out late, just one comment below.
On 2016/6/20 19:02, Tomasz Nowicki wrote:
quoted
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.
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
@@ -158,11 +158,15 @@ iort_match_node_callback(struct acpi_iort_node *node, void *context)if(ACPI_FAILURE(acpi_get_name(adev->handle,ACPI_FULL_PATHNAME,&buffer))){dev_warn(dev,"Can't get device full path name\n");-break;-}+}else{+intmatch;-if(!strcmp(ncomp->device_name,(char*)buffer.pointer))-returnAE_OK;+match=!strcmp(ncomp->device_name,buffer.pointer);+acpi_os_free(&buffer);++if(match)+returnAE_OK;+}break;}
assuming that Rafael is OK with the general approach, of course.
Thanks Marc. As Lorenzo pointed out, we need another fix for
iort_node_map_rid(). Do you want me to refresh the whole series or this
patch only?
Tomasz
From: Marc Zyngier <hidden> Date: 2016-06-22 12:04:17
On 22/06/16 12:06, Tomasz Nowicki wrote:
On 22.06.2016 12:50, Marc Zyngier wrote:
quoted
On 21/06/16 08:12, Hanjun Guo wrote:
quoted
Hi Tomasz,
Sorry for jumping out late, just one comment below.
On 2016/6/20 19:02, Tomasz Nowicki wrote:
quoted
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.
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
From: Tomasz Nowicki <hidden> Date: 2016-06-22 12:38:46
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o# processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,217 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+}else{+intmatch;++match=!strcmp(ncomp->device_name,buffer.pointer);+kfree(buffer.pointer);++if(match)+returnAE_OK;+}++break;+}+caseACPI_IORT_NODE_PCI_ROOT_COMPLEX:{+structacpi_iort_root_complex*pci_rc;+structpci_bus*bus;++bus=to_pci_bus(dev);+pci_rc=(structacpi_iort_root_complex*)node->node_data;++/*+*ItisassumedthatPCIsegmentnumbersmapsone-to-one+*withrootcomplexes.Eachsegmentnumbercanrepresentonly+*onerootcomplex.+*/+if(pci_rc->pci_segment_number==pci_domain_nr(bus))+returnAE_OK;++break;+}+}++returnAE_NOT_FOUND;+}++staticint+iort_id_map(structacpi_iort_id_mapping*map,u8type,u32rid_in,u32*rid_out)+{+/* Single mapping does not care for input id */+if(map->flags&ACPI_IORT_ID_SINGLE_MAPPING){+if(type==ACPI_IORT_NODE_NAMED_COMPONENT||+type==ACPI_IORT_NODE_PCI_ROOT_COMPLEX){+*rid_out=map->output_base;+return0;+}++pr_warn(FW_BUG"[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",+map,type);+return-ENXIO;+}++if(rid_in<map->input_base||+(rid_in>map->input_base+map->id_count))+return-ENXIO;++*rid_out=map->output_base+(rid_in-map->input_base);+return0;+}++staticstructacpi_iort_node*+iort_node_map_rid(structacpi_iort_node*node,u32rid_in,+u32*rid_out,u8type)+{+u32rid=rid_in;++/* Parse the ID mapping tree to find specified node type */+while(node){+structacpi_iort_id_mapping*map;+inti;++if(node->type==type){+if(rid_out)+*rid_out=rid;+returnnode;+}++if(!node->mapping_offset||!node->mapping_count)+gotofail_map;++map=ACPI_ADD_PTR(structacpi_iort_id_mapping,node,+node->mapping_offset);++/* Firmware bug! */+if(!map->output_reference){+pr_err(FW_BUG"[node %p type %d] ID map has NULL parent reference\n",+node,node->type);+gotofail_map;+}++/* Do the RID translation */+for(i=0;i<node->mapping_count;i++,map++){+if(!iort_id_map(map,node->type,rid,&rid))+break;+}++if(i==node->mapping_count)+gotofail_map;++node=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+map->output_reference);+}++fail_map:+/* Map input RID to output RID unchanged on mapping failure*/+if(rid_out)+*rid_out=rid_in;+returnNULL;+}++staticstructacpi_iort_node*+iort_find_dev_node(structdevice*dev)+{+structpci_bus*pbus;++if(!dev_is_pci(dev))+returniort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,+iort_match_node_callback,dev);++/* Find a PCI root bus */+pbus=to_pci_dev(dev)->bus;+while(!pci_is_root_bus(pbus))+pbus=pbus->parent;++returniort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,+iort_match_node_callback,&pbus->dev);+}++void__initiort_table_detect(void)+{+acpi_statusstatus;++status=acpi_get_table(ACPI_SIG_IORT,0,&iort_table);+if(ACPI_FAILURE(status)&&status!=AE_NOT_FOUND){+constchar*msg=acpi_format_exception(status);+pr_err("Failed to get table, %s\n",msg);+}+}
From: Tomasz Nowicki <hidden> Date: 2016-06-22 12:47:56
On 22.06.2016 14:35, 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
Signed-off-by: Tomasz Nowicki <redacted>
From: Marc Zyngier <hidden> Date: 2016-06-22 13:25:48
On 22/06/16 13:35, Tomasz Nowicki wrote:
quoted hunk
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o# processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,217 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+}else{+intmatch;++match=!strcmp(ncomp->device_name,buffer.pointer);+kfree(buffer.pointer);
Why did you change this to a naked kfree? The ACPI code clearly states:
/*
* Allocate a new buffer. We directectly call acpi_os_allocate here to
* purposefully bypass the (optionally enabled) internal allocation
* tracking mechanism since we only want to track internal
* allocations. Note: The caller should use acpi_os_free to free this
* buffer created via ACPI_ALLOCATE_BUFFER.
*/
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Tomasz Nowicki <hidden> Date: 2016-06-22 13:53:58
On 22.06.2016 15:25, Marc Zyngier wrote:
On 22/06/16 13:35, Tomasz Nowicki wrote:
quoted
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o # processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,217 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+}else{+intmatch;++match=!strcmp(ncomp->device_name,buffer.pointer);+kfree(buffer.pointer);
Why did you change this to a naked kfree? The ACPI code clearly states:
/*
* Allocate a new buffer. We directectly call acpi_os_allocate here to
* purposefully bypass the (optionally enabled) internal allocation
* tracking mechanism since we only want to track internal
* allocations. Note: The caller should use acpi_os_free to free this
* buffer created via ACPI_ALLOCATE_BUFFER.
*/
Yes we should use symmetric free function to acpi_os_allocate here,
which means acpi_os_free should be used here.
My main motivation was to free buffer.pointer instead of &buffer
Would you mind to fix that (s/kfree/acpi_os_free) before merging ?
Thanks,
Tomasz
From: Marc Zyngier <hidden> Date: 2016-06-22 14:52:10
On 22/06/16 14:52, Tomasz Nowicki wrote:
On 22.06.2016 15:25, Marc Zyngier wrote:
quoted
On 22/06/16 13:35, Tomasz Nowicki wrote:
quoted
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o # processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,217 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+}else{+intmatch;++match=!strcmp(ncomp->device_name,buffer.pointer);+kfree(buffer.pointer);
Why did you change this to a naked kfree? The ACPI code clearly states:
/*
* Allocate a new buffer. We directectly call acpi_os_allocate here to
* purposefully bypass the (optionally enabled) internal allocation
* tracking mechanism since we only want to track internal
* allocations. Note: The caller should use acpi_os_free to free this
* buffer created via ACPI_ALLOCATE_BUFFER.
*/
Yes we should use symmetric free function to acpi_os_allocate here,
which means acpi_os_free should be used here.
My main motivation was to free buffer.pointer instead of &buffer
Would you mind to fix that (s/kfree/acpi_os_free) before merging ?
Sure.
M.
--
Jazz is not dead. It just smells funny...
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.oobj-$(CONFIG_ACPI_BGRT)+=bgrt.oobj-$(CONFIG_ACPI_CPPC_LIB)+=cppc_acpi.oobj-$(CONFIG_ACPI_DEBUGGER_USER)+=acpi_dbg.o+obj-$(CONFIG_IORT_TABLE)+=iort.o # processor has its own "processor." module_param namespaceprocessor-y:=processor_driver.o
@@ -0,0 +1,217 @@+/*+*Copyright(C)2016,Semihalf+*Author:TomaszNowicki<tn@semihalf.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsandconditionsoftheGNUGeneralPublicLicense,+*version2,aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopeitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*Thisfileimplementsearlydetection/parsingofI/Omapping+*reportedtoOSthroughfirmwareviaI/ORemappingTable(IORT)+*IORTdocumentnumber:ARMDEN0049A+*/++#define pr_fmt(fmt) "ACPI: IORT: " fmt++#include<linux/iort.h>+#include<linux/kernel.h>+#include<linux/pci.h>++typedefacpi_status(*iort_find_node_callback)+(structacpi_iort_node*node,void*context);++/* Root pointer to the mapped IORT table */+staticstructacpi_table_header*iort_table;++staticstructacpi_iort_node*+iort_scan_node(enumacpi_iort_node_typetype,+iort_find_node_callbackcallback,void*context)+{+structacpi_iort_node*iort_node,*iort_end;+structacpi_table_iort*iort;+inti;++/* Get the first IORT node */+iort=(structacpi_table_iort*)iort_table;+iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort,+iort->node_offset);+iort_end=ACPI_ADD_PTR(structacpi_iort_node,iort_table,+iort_table->length);++for(i=0;i<iort->node_count;i++){+if(WARN_TAINT(iort_node>=iort_end,TAINT_FIRMWARE_WORKAROUND,+"IORT node pointer overflows, bad table!\n"))+returnNULL;++if(iort_node->type==type){+if(ACPI_SUCCESS(callback(iort_node,context)))+returniort_node;+}++iort_node=ACPI_ADD_PTR(structacpi_iort_node,iort_node,+iort_node->length);+}++returnNULL;+}++staticacpi_status+iort_match_node_callback(structacpi_iort_node*node,void*context)+{+structdevice*dev=context;++switch(node->type){+caseACPI_IORT_NODE_NAMED_COMPONENT:{+structacpi_bufferbuffer={ACPI_ALLOCATE_BUFFER,NULL};+structacpi_device*adev=to_acpi_device_node(dev->fwnode);+structacpi_iort_named_component*ncomp;++if(!adev)+break;++ncomp=(structacpi_iort_named_component*)node->node_data;++if(ACPI_FAILURE(acpi_get_name(adev->handle,+ACPI_FULL_PATHNAME,&buffer))){+dev_warn(dev,"Can't get device full path name\n");+}else{+intmatch;++match=!strcmp(ncomp->device_name,buffer.pointer);+kfree(buffer.pointer);
Why did you change this to a naked kfree? The ACPI code clearly states:
/*
* Allocate a new buffer. We directectly call acpi_os_allocate here to
* purposefully bypass the (optionally enabled) internal allocation
* tracking mechanism since we only want to track internal
* allocations. Note: The caller should use acpi_os_free to free this
* buffer created via ACPI_ALLOCATE_BUFFER.
*/
Yes we should use symmetric free function to acpi_os_allocate here,
which means acpi_os_free should be used here.
My main motivation was to free buffer.pointer instead of &buffer
It needs to be free buffer.pointer.
quoted
Would you mind to fix that (s/kfree/acpi_os_free) before merging ?
Sure.
I tracked Marc's tree on git.kernel.org, it's acpi_os_free(buffer.pointer) there so
my worry is gone :)
Thanks
Hanjun
On Mon, Jun 20, 2016 at 01:02:16PM +0200, Tomasz Nowicki wrote:
It is possible to provide information about which MSI controller to
use on a per-device basis for DT. This patch supply this with ACPI support.
Currently, IORT is the only one ACPI table which can provide such mapping.
In order to plug IORT into MSI infrastructure we are adding ACPI
equivalents for finding PCI device domain and its RID translation
(pci_msi_domain_get_msi_rid and pci_msi_domain_get_msi_rid calls).
Signed-off-by: Tomasz Nowicki <redacted>
Acked-by: Marc Zyngier <redacted>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
I assume this will be merged along with the rest of the series via
some non-PCI tree.
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Christopher Covington <hidden> Date: 2016-07-26 13:19:27
Hi Marc,
On 06/22/2016 09:34 PM, Hanjun Guo wrote:
On 2016/6/22 22:51, Marc Zyngier wrote:
quoted
On 22/06/16 14:52, Tomasz Nowicki wrote:
quoted
On 22.06.2016 15:25, Marc Zyngier wrote:
quoted
On 22/06/16 13:35, Tomasz Nowicki wrote:
quoted
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
I tracked Marc's tree on git.kernel.org, it's acpi_os_free(buffer.pointer) there so
my worry is gone :)
Do you plan on submitting this during the 4.8 merge window?
Thanks,
Cov
--
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.
From: Marc Zyngier <hidden> Date: 2016-07-26 14:49:16
On Tue, 26 Jul 2016 09:19:15 -0400
Christopher Covington [off-list ref] wrote:
Hi Christopher,
Hi Marc,
On 06/22/2016 09:34 PM, Hanjun Guo wrote:
quoted
On 2016/6/22 22:51, Marc Zyngier wrote:
quoted
On 22/06/16 14:52, Tomasz Nowicki wrote:
quoted
On 22.06.2016 15:25, Marc Zyngier wrote:
quoted
On 22/06/16 13:35, Tomasz Nowicki wrote:
quoted
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
Signed-off-by: Tomasz Nowicki <redacted>
---
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/iort.h | 30 +++++++
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
quoted
I tracked Marc's tree on git.kernel.org, it's acpi_os_free(buffer.pointer) there so
my worry is gone :)
Do you plan on submitting this during the 4.8 merge window?
Short of having received the necessary Ack from the ACPI maintainer,
the answer is unfortunately negative. I'm hoping that the new split
ACPI maintenance between generic code and arm64 will help getting
things moving for 4.9.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
From: Robert Richter <hidden> Date: 2016-08-09 11:18:51
On 20.06.16 13:02:13, Tomasz Nowicki wrote:
The series builds the PCI/MSI domain stack based on initial IORT driver
which is added in first place. As a reference please see IORT spec:
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Tested on Cavium ThunderX server. The patches can be found here:
https://github.com/semihalf-nowicki-tomasz/linux.git (its-acpi-v7)
v6 -> v7
- rebased against irq/irqchip-4.8
- improvements for IORT ID mapping
- call IORT init call from acpi_init() instead of arch_initcall()
- split IORT driver in to two parts: core and ITS/MSI
v5 -> v6
- added locking mechanism for IORT list with domain token
- IORT function name improvements
- extended IORT RID mapping helper
- reworked IORT to be more SMMU friendly
- IORT functions which map RID and find corresponding domain are not
PCI specific any more (struct pci_dev -> struct device)
- bug fixes
v4 -> v5
- rebased against v4.7-rc1
- drop generic layer and call IORT functions directly
- improve resource abstraction and string formatting
v3 -> v4
- rebased against v4.5
- add ACPI support for IRQ domain handling on a per-device basis
- reorder domain setup step
- improve error handling
- code style improvements
v2 -> v3
- rebased on top of 4.4
- fixes and improvements for redistributor init via GICC structures
- fixes as per kbuild reports
v1 -> v2
- rebased on top of 4.4-rc4
- use pci_msi_domain_get_msi_rid for requester ID to device ID translation
Tomasz Nowicki (8):
ACPI: I/O Remapping Table (IORT) initial support
ACPI: Add new IORT functions to support MSI domain handling
PCI/MSI: Setup MSI domain on a per-device basis using IORT ACPI table
irqchip/gicv3-its: Cleanup for ITS domain initialization
irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI
irqchip/gicv3-its: Probe ITS in the ACPI way
irqchip/gicv3-its: Factor out code that might be reused for ACPI
irqchip/gicv3-its: Use MADT ITS subtable to do PCI/MSI domain
initialization
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 2 +
drivers/acpi/iort.c | 389 +++++++++++++++++++++++++++++++
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 88 +++++--
drivers/irqchip/irq-gic-v3-its.c | 169 ++++++++++----
drivers/irqchip/irq-gic-v3.c | 7 +-
drivers/pci/msi.c | 11 +-
include/linux/iort.h | 41 ++++
include/linux/irqchip/arm-gic-v3.h | 4 +-
11 files changed, 646 insertions(+), 70 deletions(-)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
For the whole series:
Tested-by: Robert Richter <redacted>
Tested on Cavium ThunderX, test included:
[RFC PATCH V5 0/5] ECAM quirks handling for ARM64 platforms
Thanks Tomasz,
-Robert