From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:10
This is v5 of the series adding PCIe support for the M1 SoC. Not a lot
has changed this time around, and most of what I was saying in [1] is
still valid.
Very little has changed code wise (a couple of bug fixes). The series
however now carries a bunch of DT updates so that people can actually
make use of PCIe on an M1 box (OK, not quite, you will still need [2],
or whatever version replaces it). The corresponding bindings are
either already merged, or queued for 5.16 (this is the case for the
PCI binding).
It all should be in a state that makes it mergeable (yeah, I said that
last time... I mean it this time! ;-).
As always, comments welcome.
M.
[1] https://lore.kernel.org/r/20210922205458.358517-1-maz@kernel.org
[2] https://lore.kernel.org/r/20210921222956.40719-2-joey.gouly@arm.com
Alyssa Rosenzweig (2):
PCI: apple: Add initial hardware bring-up
PCI: apple: Set up reference clocks when probing
Marc Zyngier (10):
irqdomain: Make of_phandle_args_to_fwspec generally available
of/irq: Allow matching of an interrupt-map local to an interrupt
controller
PCI: of: Allow matching of an interrupt-map local to a PCI device
PCI: apple: Add INTx and per-port interrupt support
PCI: apple: Implement MSI support
iommu/dart: Exclude MSI doorbell from PCIe device IOVA range
PCI: apple: Configure RID to SID mapper on device addition
arm64: dts: apple: t8103: Add PCIe DARTs
arm64: dts: apple: t8103: Add root port interrupt routing
arm64: dts: apple: j274: Expose PCI node for the Ethernet MAC address
Mark Kettenis (2):
arm64: apple: Add pinctrl nodes
arm64: apple: Add PCIe node
MAINTAINERS | 7 +
arch/arm64/boot/dts/apple/t8103-j274.dts | 23 +
arch/arm64/boot/dts/apple/t8103.dtsi | 203 ++++++
drivers/iommu/apple-dart.c | 27 +
drivers/of/irq.c | 17 +-
drivers/pci/controller/Kconfig | 17 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-apple.c | 822 +++++++++++++++++++++++
drivers/pci/of.c | 10 +-
include/linux/irqdomain.h | 4 +
kernel/irq/irqdomain.c | 6 +-
11 files changed, 1127 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/controller/pcie-apple.c
--
2.30.2
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:02
of_phandle_args_to_fwspec() can be generally useful to code
extracting a DT of_phandle and using an irq_fwspec to use the
hierarchical irqdomain API.
Make it visible the the rest of the kernel, including modules.
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
include/linux/irqdomain.h | 4 ++++
kernel/irq/irqdomain.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
@@ -64,6 +64,10 @@ struct irq_fwspec {u32param[IRQ_DOMAIN_IRQ_SPEC_PARAMS];};+/* Conversion function from of_phandle_args fields to fwspec */+voidof_phandle_args_to_fwspec(structdevice_node*np,constu32*args,+unsignedintcount,structirq_fwspec*fwspec);+/**Shouldseveraldomainshavethesamedevicenode,butserve*differentpurposes(forexampleonedomainisforPCI/MSI,andthe
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:06
of_irq_parse_raw() has a baked assumption that if a node has an
interrupt-controller property, it cannot possibly also have an
interrupt-map property (the latter being ignored).
This seems to be an odd behaviour, and there is no reason why
we should avoid supporting this use case. This is specially
useful when a PCI root port acts as an interrupt controller for
PCI endpoints, such as this:
pcie0: pcie@690000000 {
[...]
port00: pci@0,0 {
device_type = "pci";
[...]
#address-cells = <3>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &port00 0 0 0 0>,
<0 0 0 2 &port00 0 0 0 1>,
<0 0 0 3 &port00 0 0 0 2>,
<0 0 0 4 &port00 0 0 0 3>;
};
};
Handle it by detecting that we have an interrupt-map early in the
parsing, and special case the situation where the phandle in the
interrupt map refers to the current node (which is the interesting
case here).
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/of/irq.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
@@ -156,10 +156,14 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)/* Now start the actual "proper" walk of the interrupt tree */while(ipar!=NULL){-/* Now check if cursor is an interrupt-controller and if it is-*thenwearedone+/*+*Nowcheckifcursorisaninterrupt-controllerand+*ifitisthenwearedone,unlessthereisan+*interrupt-mapwhichtakesprecedence.*/-if(of_property_read_bool(ipar,"interrupt-controller")){+imap=of_get_property(ipar,"interrupt-map",&imaplen);+if(imap==NULL&&+of_property_read_bool(ipar,"interrupt-controller")){pr_debug(" -> got it !\n");return0;}
@@ -173,8 +177,6 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)gotofail;}-/* Now look for an interrupt-map */-imap=of_get_property(ipar,"interrupt-map",&imaplen);/* No interrupt map, check for an interrupt parent */if(imap==NULL){pr_debug(" -> no map, getting parent\n");
@@ -255,6 +257,11 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)out_irq->args_count=intsize=newintsize;addrsize=newaddrsize;+if(ipar==newpar){+pr_debug("%pOF interrupt-map entry to self\n",ipar);+return0;+}+skiplevel:/* Iterate again with new parent */out_irq->np=newpar;
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:08
Just as we now allow an interrupt map to be parsed when part of an
interrupt controller, there is no reason to ignore an interrupt map that
would be part of a pci device node such as a root port since we already
allow interrupt specifiers.
Allow the matching of such property when local to the node of a PCI
device, which allows the device itself to use the interrupt map for for
its own purpose.
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/pci/of.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
@@ -423,7 +423,7 @@ static int devm_of_pci_get_host_bridge_resources(struct device *dev,*/staticintof_irq_parse_pci(conststructpci_dev*pdev,structof_phandle_args*out_irq){-structdevice_node*dn,*ppnode;+structdevice_node*dn,*ppnode=NULL;structpci_dev*ppdev;__be32laddr[3];u8pin;
@@ -452,8 +452,14 @@ static int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *if(pin==0)return-ENODEV;+/* Local interrupt-map in the device node? Use it! */+if(of_get_property(dn,"interrupt-map",NULL)){+pin=pci_swizzle_interrupt_pin(pdev,pin);+ppnode=dn;+}+/* Now we walk up the PCI tree */-for(;;){+while(!ppnode){/* Get the pci_dev of our parent */ppdev=pdev->bus->self;
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:11
From: Alyssa Rosenzweig <redacted>
Add a minimal driver to bring up the PCIe bus on Apple system-on-chips,
particularly the Apple M1. This driver exposes the internal bus used for
the USB type-A ports, Ethernet, Wi-Fi, and Bluetooth. Bringing up the
radios requires additional drivers beyond what's necessary for PCIe
itself.
At this stage, nothing is functionnal.
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sven Peter <redacted>
Co-developed-by: Stan Skowronek <redacted>
Signed-off-by: Stan Skowronek <redacted>
Signed-off-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 7 +
drivers/pci/controller/Kconfig | 12 ++
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-apple.c | 237 ++++++++++++++++++++++++++++
4 files changed, 257 insertions(+)
create mode 100644 drivers/pci/controller/pcie-apple.c
@@ -37,6 +37,7 @@ obj-$(CONFIG_VMD) += vmd.oobj-$(CONFIG_PCIE_BRCMSTB)+=pcie-brcmstb.oobj-$(CONFIG_PCI_LOONGSON)+=pci-loongson.oobj-$(CONFIG_PCIE_HISI_ERR)+=pcie-hisi-error.o+obj-$(CONFIG_PCIE_APPLE)+=pcie-apple.o# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DWobj-y+=dwc/obj-y+=mobiveil/
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:14
From: Alyssa Rosenzweig <redacted>
Apple's PCIe controller requires clocks to be configured in order to
bring up the hardware. Add the register pokes required to do so.
Adapted from Corellium's driver via Mark Kettenis's U-Boot patches.
Co-developed-by: Stan Skowronek <redacted>
Signed-off-by: Stan Skowronek <redacted>
Signed-off-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/pci/controller/pcie-apple.c | 46 +++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:16
Add support for the per-port interrupt controller that deals
with both INTx signalling and management interrupts.
This allows the Link-up/Link-down interrupts to be wired, allowing
the bring-up to be synchronised (and provide debug information).
The framework can further be used to handle the rest of the per
port events if and when necessary.
Likewise, INTx signalling is implemented so that end-points can
actually be used.
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/pci/controller/pcie-apple.c | 209 ++++++++++++++++++++++++++++
1 file changed, 209 insertions(+)
@@ -137,6 +140,200 @@ static void rmw_clear(u32 clr, void __iomem *addr)writel_relaxed(readl_relaxed(addr)&~clr,addr);}+staticvoidapple_port_irq_mask(structirq_data*data)+{+structapple_pcie_port*port=irq_data_get_irq_chip_data(data);++writel_relaxed(BIT(data->hwirq),port->base+PORT_INTMSKSET);+}++staticvoidapple_port_irq_unmask(structirq_data*data)+{+structapple_pcie_port*port=irq_data_get_irq_chip_data(data);++writel_relaxed(BIT(data->hwirq),port->base+PORT_INTMSKCLR);+}++staticboolhwirq_is_intx(unsignedinthwirq)+{+returnBIT(hwirq)&PORT_INT_INTx_MASK;+}++staticvoidapple_port_irq_ack(structirq_data*data)+{+structapple_pcie_port*port=irq_data_get_irq_chip_data(data);++if(!hwirq_is_intx(data->hwirq))+writel_relaxed(BIT(data->hwirq),port->base+PORT_INTSTAT);+}++staticintapple_port_irq_set_type(structirq_data*data,unsignedinttype)+{+/*+*Itdoesn'tseemthatthereisanywaytoconfigurethe+*trigger,soassumeINTxhavetobelevel(asperthespec),+*andtherestisedge(whichlookslikely).+*/+if(hwirq_is_intx(data->hwirq)^!!(type&IRQ_TYPE_LEVEL_MASK))+return-EINVAL;++irqd_set_trigger_type(data,type);+return0;+}++staticstructirq_chipapple_port_irqchip={+.name="PCIe",+.irq_ack=apple_port_irq_ack,+.irq_mask=apple_port_irq_mask,+.irq_unmask=apple_port_irq_unmask,+.irq_set_type=apple_port_irq_set_type,+};++staticintapple_port_irq_domain_alloc(structirq_domain*domain,+unsignedintvirq,unsignedintnr_irqs,+void*args)+{+structapple_pcie_port*port=domain->host_data;+structirq_fwspec*fwspec=args;+inti;++for(i=0;i<nr_irqs;i++){+irq_flow_handler_tflow=handle_edge_irq;+unsignedinttype=IRQ_TYPE_EDGE_RISING;++if(hwirq_is_intx(fwspec->param[0]+i)){+flow=handle_level_irq;+type=IRQ_TYPE_LEVEL_HIGH;+}++irq_domain_set_info(domain,virq+i,fwspec->param[0]+i,+&apple_port_irqchip,port,flow,+NULL,NULL);++irq_set_irq_type(virq+i,type);+}++return0;+}++staticvoidapple_port_irq_domain_free(structirq_domain*domain,+unsignedintvirq,unsignedintnr_irqs)+{+inti;++for(i=0;i<nr_irqs;i++){+structirq_data*d=irq_domain_get_irq_data(domain,virq+i);+irq_set_handler(virq+i,NULL);+irq_domain_reset_irq_data(d);+}+}++staticconststructirq_domain_opsapple_port_irq_domain_ops={+.translate=irq_domain_translate_onecell,+.alloc=apple_port_irq_domain_alloc,+.free=apple_port_irq_domain_free,+};++staticvoidapple_port_irq_handler(structirq_desc*desc)+{+structapple_pcie_port*port=irq_desc_get_handler_data(desc);+structirq_chip*chip=irq_desc_get_chip(desc);+unsignedlongstat;+inti;++chained_irq_enter(chip,desc);++stat=readl_relaxed(port->base+PORT_INTSTAT);++for_each_set_bit(i,&stat,32)+generic_handle_domain_irq(port->domain,i);++chained_irq_exit(chip,desc);+}++staticintapple_pcie_port_setup_irq(structapple_pcie_port*port)+{+structfwnode_handle*fwnode=&port->np->fwnode;+unsignedintirq;++/* FIXME: consider moving each interrupt under each port */+irq=irq_of_parse_and_map(to_of_node(dev_fwnode(port->pcie->dev)),+port->idx);+if(!irq)+return-ENXIO;++port->domain=irq_domain_create_linear(fwnode,32,+&apple_port_irq_domain_ops,+port);+if(!port->domain)+return-ENOMEM;++/* Disable all interrupts */+writel_relaxed(~0,port->base+PORT_INTMSKSET);+writel_relaxed(~0,port->base+PORT_INTSTAT);++irq_set_chained_handler_and_data(irq,apple_port_irq_handler,port);++return0;+}++staticirqreturn_tapple_pcie_port_irq(intirq,void*data)+{+structapple_pcie_port*port=data;+unsignedinthwirq=irq_domain_get_irq_data(port->domain,irq)->hwirq;++switch(hwirq){+casePORT_INT_LINK_UP:+dev_info_ratelimited(port->pcie->dev,"Link up on %pOF\n",+port->np);+complete_all(&port->pcie->event);+break;+casePORT_INT_LINK_DOWN:+dev_info_ratelimited(port->pcie->dev,"Link down on %pOF\n",+port->np);+break;+default:+returnIRQ_NONE;+}++returnIRQ_HANDLED;+}++staticintapple_pcie_port_register_irqs(structapple_pcie_port*port)+{+staticstruct{+unsignedinthwirq;+constchar*name;+}port_irqs[]={+{PORT_INT_LINK_UP,"Link up",},+{PORT_INT_LINK_DOWN,"Link down",},+};+inti;++for(i=0;i<ARRAY_SIZE(port_irqs);i++){+structirq_fwspecfwspec={+.fwnode=&port->np->fwnode,+.param_count=1,+.param={+[0]=port_irqs[i].hwirq,+},+};+unsignedintirq;+intret;++irq=irq_domain_alloc_irqs(port->domain,1,NUMA_NO_NODE,+&fwspec);+if(WARN_ON(!irq))+continue;++ret=request_irq(irq,apple_pcie_port_irq,0,+port_irqs[i].name,port);+WARN_ON(ret);+}++return0;+}+staticintapple_pcie_setup_refclk(structapple_pcie*pcie,structapple_pcie_port*port){
@@ -221,8 +418,20 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie,returnret;}+ret=apple_pcie_port_setup_irq(port);+if(ret)+returnret;++init_completion(&pcie->event);++ret=apple_pcie_port_register_irqs(port);+WARN_ON(ret);+writel_relaxed(PORT_LTSSMCTL_START,port->base+PORT_LTSSMCTL);+if(!wait_for_completion_timeout(&pcie->event,HZ/10))+dev_warn(pcie->dev,"%pOF link didn't come up\n",np);+return0;}
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:19
The MSI doorbell on Apple HW can be any address in the low 4GB
range. However, the MSI write is matched by the PCIe block before
hitting the iommu. It must thus be excluded from the IOVA range
that is assigned to any PCIe device.
Reviewed-by: Sven Peter <redacted>
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/iommu/apple-dart.c | 27 +++++++++++++++++++++++++++
drivers/pci/controller/Kconfig | 5 +++++
drivers/pci/controller/pcie-apple.c | 4 +++-
3 files changed, 35 insertions(+), 1 deletion(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:24
Probe for the 'msi-ranges' property, and implement the MSI
support in the form of the usual two-level hierarchy.
Note that contrary to the wired interrupts, MSIs are shared among
all the ports.
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/pci/controller/pcie-apple.c | 169 +++++++++++++++++++++++++++-
1 file changed, 168 insertions(+), 1 deletion(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:39:26
The Apple PCIe controller doesn't directly feed the endpoint's
Requester ID to the IOMMU (DART), but instead maps RIDs onto
Stream IDs (SIDs). The DART and the PCIe controller must thus
agree on the SIDs that are used for translation (by using
the 'iommu-map' property).
For this purpose, parse the 'iommu-map' property each time a
device gets added, and use the resulting translation to configure
the PCIe RID-to-SID mapper. Similarily, remove the translation
if/when the device gets removed.
This is all driven from a bus notifier which gets registered at
probe time. Hopefully this is the only PCI controller driver
in the whole system.
Reviewed-by: Sven Peter <redacted>
Tested-by: Alyssa Rosenzweig <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/pci/controller/pcie-apple.c | 165 +++++++++++++++++++++++++++-
1 file changed, 163 insertions(+), 2 deletions(-)
@@ -489,6 +497,14 @@ static int apple_pcie_setup_refclk(struct apple_pcie *pcie,return0;}+staticu32apple_pcie_rid2sid_write(structapple_pcie_port*port,+intidx,u32val)+{+writel_relaxed(val,port->base+PORT_RID2SID(idx));+/* Read back to ensure completion of the write */+returnreadl_relaxed(port->base+PORT_RID2SID(idx));+}+staticintapple_pcie_setup_port(structapple_pcie*pcie,structdevice_node*np){
@@ -496,7 +512,7 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie,structapple_pcie_port*port;structgpio_desc*reset;u32stat,idx;-intret;+intret,i;reset=gpiod_get_from_of_node(np,"reset-gpios",0,GPIOD_OUT_LOW,"#PERST");
@@ -540,6 +556,18 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie,if(ret)returnret;+/* Reset all RID/SID mappings, and check for RAZ/WI registers */+for(i=0;i<MAX_RID2SID;i++){+if(apple_pcie_rid2sid_write(port,i,0xbad1d)!=0xbad1d)+break;+apple_pcie_rid2sid_write(port,i,0);+}++dev_dbg(pcie->dev,"%pOF: %d RID/SID mapping entries\n",np,i);++port->sid_map_sz=i;++list_add_tail(&port->entry,&pcie->ports);init_completion(&pcie->event);ret=apple_pcie_port_register_irqs(port);
@@ -602,6 +630,121 @@ static int apple_msi_init(struct apple_pcie *pcie)return0;}+staticstructapple_pcie_port*apple_pcie_get_port(structpci_dev*pdev)+{+structpci_config_window*cfg=pdev->sysdata;+structapple_pcie*pcie=cfg->priv;+structpci_dev*port_pdev=pdev;+structapple_pcie_port*port;++/* Find the root port this device is on */+port_pdev=pcie_find_root_port(pdev);++/* If finding the port itself, nothing to do */+if(WARN_ON(!port_pdev)||pdev==port_pdev)+returnNULL;++list_for_each_entry(port,&pcie->ports,entry){+if(port->idx==PCI_SLOT(port_pdev->devfn))+returnport;+}++returnNULL;+}++staticintapple_pcie_add_device(structapple_pcie_port*port,+structpci_dev*pdev)+{+u32sid,rid=PCI_DEVID(pdev->bus->number,pdev->devfn);+intidx,err;++dev_dbg(&pdev->dev,"added to bus %s, index %d\n",+pci_name(pdev->bus->self),port->idx);++err=of_map_id(port->pcie->dev->of_node,rid,"iommu-map",+"iommu-map-mask",NULL,&sid);+if(err)+returnerr;++mutex_lock(&port->pcie->lock);++idx=bitmap_find_free_region(port->sid_map,port->sid_map_sz,0);+if(idx>=0){+apple_pcie_rid2sid_write(port,idx,+PORT_RID2SID_VALID|+(sid<<PORT_RID2SID_SID_SHIFT)|rid);++dev_dbg(&pdev->dev,"mapping RID%x to SID%x (index %d)\n",+rid,sid,idx);+}++mutex_unlock(&port->pcie->lock);++returnidx>=0?0:-ENOSPC;+}++staticvoidapple_pcie_release_device(structapple_pcie_port*port,+structpci_dev*pdev)+{+u32rid=PCI_DEVID(pdev->bus->number,pdev->devfn);+intidx;++mutex_lock(&port->pcie->lock);++for_each_set_bit(idx,port->sid_map,port->sid_map_sz){+u32val;++val=readl_relaxed(port->base+PORT_RID2SID(idx));+if((val&0xffff)==rid){+apple_pcie_rid2sid_write(port,idx,0);+bitmap_release_region(port->sid_map,idx,0);+dev_dbg(&pdev->dev,"Released %x (%d)\n",val,idx);+break;+}+}++mutex_unlock(&port->pcie->lock);+}++staticintapple_pcie_bus_notifier(structnotifier_block*nb,+unsignedlongaction,+void*data)+{+structdevice*dev=data;+structpci_dev*pdev=to_pci_dev(dev);+structapple_pcie_port*port;+interr;++/*+*Thisisabitugly.Weassumethatifwegetnotifiedfor+*anyPCIdevice,wemustbeinchargeofit,andthatthere+*isnootherPCIcontrollerinthewholesystem.Itprobably+*holdsfornow,butwhoknowsforhowlong?+*/+port=apple_pcie_get_port(pdev);+if(!port)+returnNOTIFY_DONE;++switch(action){+caseBUS_NOTIFY_ADD_DEVICE:+err=apple_pcie_add_device(port,pdev);+if(err)+returnnotifier_from_errno(err);+break;+caseBUS_NOTIFY_DEL_DEVICE:+apple_pcie_release_device(port,pdev);+break;+default:+returnNOTIFY_DONE;+}++returnNOTIFY_OK;+}++staticstructnotifier_blockapple_pcie_nb={+.notifier_call=apple_pcie_bus_notifier,+};+staticintapple_pcie_init(structpci_config_window*cfg){structdevice*dev=cfg->parent;
@@ -622,6 +765,9 @@ static int apple_pcie_init(struct pci_config_window *cfg)if(IS_ERR(pcie->base))returnPTR_ERR(pcie->base);+cfg->priv=pcie;+INIT_LIST_HEAD(&pcie->ports);+for_each_child_of_node(dev->of_node,of_port){ret=apple_pcie_setup_port(pcie,of_port);if(ret){
@@ -633,6 +779,21 @@ static int apple_pcie_init(struct pci_config_window *cfg)returnapple_msi_init(pcie);}+staticintapple_pcie_probe(structplatform_device*pdev)+{+intret;++ret=bus_register_notifier(&pci_bus_type,&apple_pcie_nb);+if(ret)+returnret;++ret=pci_host_common_probe(pdev);+if(ret)+bus_unregister_notifier(&pci_bus_type,&apple_pcie_nb);++returnret;+}+staticconststructpci_ecam_opsapple_pcie_cfg_ecam_ops={.init=apple_pcie_init,.pci_ops={
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:56:52
From: Mark Kettenis <redacted>
Add node corresponding to the apcie,t8103 node in the
Apple device tree for the Mac mini (M1, 2020).
Power domain references and DART (IOMMU) references are left out
at the moment and will be added once the appropriate bindings have
been settled upon.
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Mark Kettenis <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210921183420.436-5-kettenis@openbsd.org
---
arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
From: Hector Martin <hidden> Date: 2021-10-07 16:01:54
On 30/09/2021 01.38, Marc Zyngier wrote:
From: Mark Kettenis <redacted>
Add node corresponding to the apcie,t8103 node in the
Apple device tree for the Mac mini (M1, 2020).
Power domain references and DART (IOMMU) references are left out
at the moment and will be added once the appropriate bindings have
been settled upon.
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Mark Kettenis <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210921183420.436-5-kettenis@openbsd.org
---
arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
Acked-by: Hector Martin <redacted>
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:56:58
PCIe on the Apple M1 (aka t8103) requires the use of IOMMUs (aka
DARTs). Add the three instances that deal with the internal PCIe
ports and route each port's traffic through its DART.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/boot/dts/apple/t8103.dtsi | 30 ++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
From: Hector Martin <hidden> Date: 2021-10-07 16:02:35
On 30/09/2021 01.38, Marc Zyngier wrote:
PCIe on the Apple M1 (aka t8103) requires the use of IOMMUs (aka
DARTs). Add the three instances that deal with the internal PCIe
ports and route each port's traffic through its DART.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/boot/dts/apple/t8103.dtsi | 30 ++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Acked-by: Hector Martin <redacted>
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:57:05
At the moment, all the Minis running Linux have the same MAC
address (00:10:18:00:00:00), which is a bit annoying.
Expose the PCI node corresponding to the Ethernet device, and
declare a 'local-mac-address' property. The bootloader will update
it (m1n1 already has the required feature). And if it doesn't, then
the default value is already present in the DT.
This relies on forcing the bus number for each port so that the
endpoints connected to them are correctly numbered (and keeps dtc
quiet).
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/boot/dts/apple/t8103-j274.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
@@ -43,3 +44,25 @@ memory@800000000 {&serial0{status="okay";};++/*+*Forcethebusnumberassignmentssothatwecandeclaresomeofthe+*on-boarddevicesandpropertiesthatarepopulatedbythebootloader+*(suchasMACaddresses).+*/+&port00{+bus-range=<11>;+};++&port01{+bus-range=<22>;+};++&port02{+bus-range=<33>;+ethernet0:pci@0,0{+reg=<0x300000x00x00x00x0>;+/* To be filled by the loader */+local-mac-address=[001018000000];+};+};
From: Hector Martin <hidden> Date: 2021-10-07 16:03:35
On 30/09/2021 01.38, Marc Zyngier wrote:
At the moment, all the Minis running Linux have the same MAC
address (00:10:18:00:00:00), which is a bit annoying.
Expose the PCI node corresponding to the Ethernet device, and
declare a 'local-mac-address' property. The bootloader will update
it (m1n1 already has the required feature). And if it doesn't, then
the default value is already present in the DT.
This relies on forcing the bus number for each port so that the
endpoints connected to them are correctly numbered (and keeps dtc
quiet).
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/boot/dts/apple/t8103-j274.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
Acked-by: Hector Martin <redacted>
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-29 16:57:08
From: Mark Kettenis <redacted>
Add pinctrl nodes corresponding to the gpio,t8101 nodes in the
Apple device tree for the Mac mini (M1, 2020).
Clock references are left out at the moment and will be added once
the appropriate bindings have been settled upon.
Signed-off-by: Mark Kettenis <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210520171310.772-3-mark.kettenis@xs4all.nl
---
arch/arm64/boot/dts/apple/t8103.dtsi | 83 ++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
On Wed, Sep 29, 2021 at 6:56 PM Marc Zyngier [off-list ref] wrote:
From: Mark Kettenis <redacted>
Add pinctrl nodes corresponding to the gpio,t8101 nodes in the
Apple device tree for the Mac mini (M1, 2020).
Clock references are left out at the moment and will be added once
the appropriate bindings have been settled upon.
Signed-off-by: Mark Kettenis <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210520171310.772-3-mark.kettenis@xs4all.nl
In other discussions it turns out that the driver is abusing these gpio-ranges
to find out how many pins are in each pinctrl instance. This is not the
idea with gpio-ranges, these can be multiple and map different sets,
so we need something like
apple,npins = <212>;
(+ bindings)
or so...
Yours,
Linus Walleij
On Wed, Sep 29, 2021 at 6:56 PM Marc Zyngier [off-list ref] wrote:
quoted
From: Mark Kettenis <redacted>
Add pinctrl nodes corresponding to the gpio,t8101 nodes in the
Apple device tree for the Mac mini (M1, 2020).
Clock references are left out at the moment and will be added once
the appropriate bindings have been settled upon.
Signed-off-by: Mark Kettenis <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210520171310.772-3-mark.kettenis@xs4all.nl
In other discussions it turns out that the driver is abusing these gpio-ranges
to find out how many pins are in each pinctrl instance. This is not the
idea with gpio-ranges, these can be multiple and map different sets,
so we need something like
apple,npins = <212>;
(+ bindings)
or so...
Is it the driver that needs updating? Or the binding? I don't really
care about the former, but the latter is more disruptive as it has
impacts over both u-boot and at least OpenBSD.
How is that solved on other pinctrl blocks? I can't see anyone having
a similar a similar property.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Thu, Sep 30, 2021 at 10:00 AM Marc Zyngier [off-list ref] wrote:
quoted
In other discussions it turns out that the driver is abusing these gpio-ranges
to find out how many pins are in each pinctrl instance. This is not the
idea with gpio-ranges, these can be multiple and map different sets,
so we need something like
apple,npins = <212>;
(+ bindings)
or so...
Is it the driver that needs updating? Or the binding?
Both, I guess.
I don't really
care about the former, but the latter is more disruptive as it has
impacts over both u-boot and at least OpenBSD.
How is that solved on other pinctrl blocks? I can't see anyone having
a similar a similar property.
The Apple pincontroller is unique in having four instances using the
same compatible string (I raised this as an issue too).
Most SoCs has one instance of a pin controller, with one compatible
string and then we also know how many pins it has.
The maintainer seeme unhappy about my suggestion to name
the four pin controllers after function and insist to use the same
compatible for all four, which means they instead need to be
parametrized, which means this parameter has to be added
because ranges should not be used in this way.
I guess the code can survive using the ranges as a fallback at
the cost of some more complex code.
Yours,
Linus Walleij
From: Hector Martin <hidden> Date: 2021-10-07 16:00:44
On 30/09/2021 01.38, Marc Zyngier wrote:
quoted hunk
From: Mark Kettenis <redacted>
Add pinctrl nodes corresponding to the gpio,t8101 nodes in the
Apple device tree for the Mac mini (M1, 2020).
Clock references are left out at the moment and will be added once
the appropriate bindings have been settled upon.
Signed-off-by: Mark Kettenis <redacted>
Reviewed-by: Linus Walleij <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210520171310.772-3-mark.kettenis@xs4all.nl
---
arch/arm64/boot/dts/apple/t8103.dtsi | 83 ++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
[snip]
Looks good. Can you resend just this patch with the apple,npins
properties added? Once that's settled in the binding (which seems to
just be waiting on some linter issues) I can merge this and the rest of
the DT changes through my tree.
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
From: Lorenzo Pieralisi <hidden> Date: 2021-10-04 08:38:56
On Wed, Sep 29, 2021 at 05:38:33PM +0100, Marc Zyngier wrote:
This is v5 of the series adding PCIe support for the M1 SoC. Not a lot
has changed this time around, and most of what I was saying in [1] is
still valid.
Very little has changed code wise (a couple of bug fixes). The series
however now carries a bunch of DT updates so that people can actually
make use of PCIe on an M1 box (OK, not quite, you will still need [2],
or whatever version replaces it). The corresponding bindings are
either already merged, or queued for 5.16 (this is the case for the
PCI binding).
It all should be in a state that makes it mergeable (yeah, I said that
last time... I mean it this time! ;-).
As always, comments welcome.
M.
[1] https://lore.kernel.org/r/20210922205458.358517-1-maz@kernel.org
[2] https://lore.kernel.org/r/20210921222956.40719-2-joey.gouly@arm.com
Alyssa Rosenzweig (2):
PCI: apple: Add initial hardware bring-up
PCI: apple: Set up reference clocks when probing
Marc Zyngier (10):
irqdomain: Make of_phandle_args_to_fwspec generally available
of/irq: Allow matching of an interrupt-map local to an interrupt
controller
PCI: of: Allow matching of an interrupt-map local to a PCI device
PCI: apple: Add INTx and per-port interrupt support
PCI: apple: Implement MSI support
iommu/dart: Exclude MSI doorbell from PCIe device IOVA range
PCI: apple: Configure RID to SID mapper on device addition
arm64: dts: apple: t8103: Add PCIe DARTs
arm64: dts: apple: t8103: Add root port interrupt routing
arm64: dts: apple: j274: Expose PCI node for the Ethernet MAC address
Mark Kettenis (2):
arm64: apple: Add pinctrl nodes
arm64: apple: Add PCIe node
MAINTAINERS | 7 +
arch/arm64/boot/dts/apple/t8103-j274.dts | 23 +
arch/arm64/boot/dts/apple/t8103.dtsi | 203 ++++++
drivers/iommu/apple-dart.c | 27 +
drivers/of/irq.c | 17 +-
drivers/pci/controller/Kconfig | 17 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-apple.c | 822 +++++++++++++++++++++++
drivers/pci/of.c | 10 +-
include/linux/irqdomain.h | 4 +
kernel/irq/irqdomain.c | 6 +-
11 files changed, 1127 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/controller/pcie-apple.c
I have applied (with very minor log changes) patches [1-9] to
pci/apple for v5.16, I expect the dts changes to go via the
arm-soc tree separately, please let me know if that works for you.
Thanks,
Lorenzo
From: Marc Zyngier <maz@kernel.org> Date: 2021-10-04 09:05:49
Hi Lorenzo,
[+LinusW, Arnd]
On Mon, 04 Oct 2021 09:38:45 +0100,
Lorenzo Pieralisi [off-list ref] wrote:
On Wed, Sep 29, 2021 at 05:38:33PM +0100, Marc Zyngier wrote:
quoted
This is v5 of the series adding PCIe support for the M1 SoC. Not a lot
has changed this time around, and most of what I was saying in [1] is
still valid.
Very little has changed code wise (a couple of bug fixes). The series
however now carries a bunch of DT updates so that people can actually
make use of PCIe on an M1 box (OK, not quite, you will still need [2],
or whatever version replaces it). The corresponding bindings are
either already merged, or queued for 5.16 (this is the case for the
PCI binding).
It all should be in a state that makes it mergeable (yeah, I said that
last time... I mean it this time! ;-).
As always, comments welcome.
M.
[1] https://lore.kernel.org/r/20210922205458.358517-1-maz@kernel.org
[2] https://lore.kernel.org/r/20210921222956.40719-2-joey.gouly@arm.com
Alyssa Rosenzweig (2):
PCI: apple: Add initial hardware bring-up
PCI: apple: Set up reference clocks when probing
Marc Zyngier (10):
irqdomain: Make of_phandle_args_to_fwspec generally available
of/irq: Allow matching of an interrupt-map local to an interrupt
controller
PCI: of: Allow matching of an interrupt-map local to a PCI device
PCI: apple: Add INTx and per-port interrupt support
PCI: apple: Implement MSI support
iommu/dart: Exclude MSI doorbell from PCIe device IOVA range
PCI: apple: Configure RID to SID mapper on device addition
arm64: dts: apple: t8103: Add PCIe DARTs
arm64: dts: apple: t8103: Add root port interrupt routing
arm64: dts: apple: j274: Expose PCI node for the Ethernet MAC address
Mark Kettenis (2):
arm64: apple: Add pinctrl nodes
arm64: apple: Add PCIe node
MAINTAINERS | 7 +
arch/arm64/boot/dts/apple/t8103-j274.dts | 23 +
arch/arm64/boot/dts/apple/t8103.dtsi | 203 ++++++
drivers/iommu/apple-dart.c | 27 +
drivers/of/irq.c | 17 +-
drivers/pci/controller/Kconfig | 17 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-apple.c | 822 +++++++++++++++++++++++
drivers/pci/of.c | 10 +-
include/linux/irqdomain.h | 4 +
kernel/irq/irqdomain.c | 6 +-
11 files changed, 1127 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/controller/pcie-apple.c
I have applied (with very minor log changes) patches [1-9] to
pci/apple for v5.16, I expect the dts changes to go via the
arm-soc tree separately, please let me know if that works for you.
Yes, that's absolutely fine. I hope we can resolve the issue on the
pinctrl binding pretty quickly, and get the arm-soc folks to pull the
DT changes in for 5.16 too.
This would make the Mini a usable machine with a mainline kernel.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Mon, Oct 4, 2021 at 11:05 AM Marc Zyngier [off-list ref] wrote:
Yes, that's absolutely fine. I hope we can resolve the issue on the
pinctrl binding pretty quickly, and get the arm-soc folks to pull the
DT changes in for 5.16 too.
I think I ACKed a patch for apple,npins = <> yesterday.
This would make the Mini a usable machine with a mainline kernel.
From: Hector Martin <hidden> Date: 2021-10-07 15:43:46
On 05/10/2021 03.30, Linus Walleij wrote:
On Mon, Oct 4, 2021 at 11:05 AM Marc Zyngier [off-list ref] wrote:
quoted
Yes, that's absolutely fine. I hope we can resolve the issue on the
pinctrl binding pretty quickly, and get the arm-soc folks to pull the
DT changes in for 5.16 too.
I think I ACKed a patch for apple,npins = <> yesterday.
You reviewed it :)
It still needs some fixes to pass the schema linter though.
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
From: Rob Herring <robh+dt@kernel.org> Date: 2021-10-04 19:52:00
On Mon, Oct 4, 2021 at 3:38 AM Lorenzo Pieralisi
[off-list ref] wrote:
On Wed, Sep 29, 2021 at 05:38:33PM +0100, Marc Zyngier wrote:
quoted
This is v5 of the series adding PCIe support for the M1 SoC. Not a lot
has changed this time around, and most of what I was saying in [1] is
still valid.
Very little has changed code wise (a couple of bug fixes). The series
however now carries a bunch of DT updates so that people can actually
make use of PCIe on an M1 box (OK, not quite, you will still need [2],
or whatever version replaces it). The corresponding bindings are
either already merged, or queued for 5.16 (this is the case for the
PCI binding).
It all should be in a state that makes it mergeable (yeah, I said that
last time... I mean it this time! ;-).
As always, comments welcome.
M.
[1] https://lore.kernel.org/r/20210922205458.358517-1-maz@kernel.org
[2] https://lore.kernel.org/r/20210921222956.40719-2-joey.gouly@arm.com
Alyssa Rosenzweig (2):
PCI: apple: Add initial hardware bring-up
PCI: apple: Set up reference clocks when probing
Marc Zyngier (10):
irqdomain: Make of_phandle_args_to_fwspec generally available
of/irq: Allow matching of an interrupt-map local to an interrupt
controller
PCI: of: Allow matching of an interrupt-map local to a PCI device
PCI: apple: Add INTx and per-port interrupt support
PCI: apple: Implement MSI support
iommu/dart: Exclude MSI doorbell from PCIe device IOVA range
PCI: apple: Configure RID to SID mapper on device addition
arm64: dts: apple: t8103: Add PCIe DARTs
arm64: dts: apple: t8103: Add root port interrupt routing
arm64: dts: apple: j274: Expose PCI node for the Ethernet MAC address
Mark Kettenis (2):
arm64: apple: Add pinctrl nodes
arm64: apple: Add PCIe node
MAINTAINERS | 7 +
arch/arm64/boot/dts/apple/t8103-j274.dts | 23 +
arch/arm64/boot/dts/apple/t8103.dtsi | 203 ++++++
drivers/iommu/apple-dart.c | 27 +
drivers/of/irq.c | 17 +-
drivers/pci/controller/Kconfig | 17 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-apple.c | 822 +++++++++++++++++++++++
drivers/pci/of.c | 10 +-
include/linux/irqdomain.h | 4 +
kernel/irq/irqdomain.c | 6 +-
11 files changed, 1127 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/controller/pcie-apple.c
I have applied (with very minor log changes) patches [1-9] to
pci/apple for v5.16, I expect the dts changes to go via the
arm-soc tree separately, please let me know if that works for you.
FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
I am a bit worried about changes to the DT interrupt parsing and
ancient platforms (such as PowerMacs). Most likely there wouldn't be
any report until -rc1 or months later on those old systems.
Rob
On Mon, Oct 4, 2021 at 9:52 PM Rob Herring [off-list ref] wrote:
FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
I am a bit worried about changes to the DT interrupt parsing and
ancient platforms (such as PowerMacs). Most likely there wouldn't be
any report until -rc1 or months later on those old systems.
Lets page the PPC lists to see if someone can test on some powermac.
Linus Walleij
From: Marc Zyngier <maz@kernel.org> Date: 2021-10-05 09:57:31
On Mon, 04 Oct 2021 21:42:45 +0100,
Linus Walleij [off-list ref] wrote:
On Mon, Oct 4, 2021 at 9:52 PM Rob Herring [off-list ref] wrote:
quoted
FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
I am a bit worried about changes to the DT interrupt parsing and
ancient platforms (such as PowerMacs). Most likely there wouldn't be
any report until -rc1 or months later on those old systems.
Lets page the PPC lists to see if someone can test on some powermac.
/me eyes the XServe-G5 that hasn't been powered on in 10 years. What
could possibly go wrong?
M.
--
Without deviation from the norm, progress is not possible.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2021-10-06 05:56:19
Linus Walleij [off-list ref] writes:
On Mon, Oct 4, 2021 at 9:52 PM Rob Herring [off-list ref] wrote:
quoted
FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
I am a bit worried about changes to the DT interrupt parsing and
ancient platforms (such as PowerMacs). Most likely there wouldn't be
any report until -rc1 or months later on those old systems.
Lets page the PPC lists to see if someone can test on some powermac.
It boots and everything seems fine on an iMac-G5 of mine.
I don't have access to any other powermac hardware at the moment due to
the lockdown here.
cheers