[Devel] [RESEND PATCH v9 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

Will Deacon will.deacon at arm.com
Tue Jun 27 07:06:00 PDT 2017


On Tue, Jun 27, 2017 at 03:56:10PM +0200, Robert Richter wrote:
> On 23.06.17 19:04:36, Geetha sowjanya wrote:
> > From: Geetha Sowjanya <geethasowjanya.akula at cavium.com>
> > 
> > Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq
> > lines for gerror, eventq and cmdq-sync.
> > 
> > New named irq "combined" is set as a errata workaround, which allows to
> > share the irq line by register single irq handler for all the interrupts.
> > 
> > Signed-off-by: Geetha sowjanya <gakula at caviumnetworks.com>
> > ---
> >  Documentation/arm64/silicon-errata.txt             |    1 +
> >  .../devicetree/bindings/iommu/arm,smmu-v3.txt      |    6 +
> >  drivers/acpi/arm64/iort.c                          |   57 ++++++++---
> >  drivers/iommu/arm-smmu-v3.c                        |  100 ++++++++++++++-----
> >  4 files changed, 121 insertions(+), 43 deletions(-)
> 
> > +static int arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
> > +{
> > +	int ret, irq;
> > +	u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN;
> > +
> > +	/* Disable IRQs first */
> > +	ret = arm_smmu_write_reg_sync(smmu, 0, ARM_SMMU_IRQ_CTRL,
> > +				      ARM_SMMU_IRQ_CTRLACK);
> > +	if (ret) {
> > +		dev_err(smmu->dev, "failed to disable irqs\n");
> > +		return ret;
> > +	}
> > +
> > +	irq = smmu->combined_irq;
> > +	if (irq) {
> > +		/*
> > +		 * Cavium ThunderX2 implementation doesn't not support unique
> > +		 * irq lines. Use single irq line for all the SMMUv3 interrupts.
> > +		 */
> > +		ret = devm_request_threaded_irq(smmu->dev, irq,
> > +					arm_smmu_combined_irq_handler,
> > +					arm_smmu_combined_irq_thread,
> > +					IRQF_ONESHOT,
> 
> Without the IRQF_SHARED flag set I see the following on a dual node
> system now:

We asked about that before:

https://marc.info/?l=linux-arm-kernel&m=149803613513068&w=2
https://marc.info/?l=linux-acpi&m=149803744713475&w=2

and Geetha didn't reply, but the next version of the patch dropped the flag.
Is it just that firmware is misprogramming something here, or something
more fundamental?

Will



More information about the linux-arm-kernel mailing list