Received: by 10.223.176.46 with SMTP id f43csp801089wra; Sat, 20 Jan 2018 05:09:48 -0800 (PST) X-Google-Smtp-Source: AH8x22684e3SdOhnp/YrBKF7rFz5708XBbtz2QsK2knsMSTSx0RDrzXYwnPFSYPHg+B0vIFV7zhm X-Received: by 10.99.106.69 with SMTP id f66mr1922607pgc.283.1516453788090; Sat, 20 Jan 2018 05:09:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516453788; cv=none; d=google.com; s=arc-20160816; b=pzmRWyTsJEDIBpLWEPnAGWbl80mngAyZHd3/jwt46N2ItHRSsPwCFCKnEphjqSG9Rr mT4MKoOcrAZJxmIZ1RRJtXoiloOtOzcu4Boy8WE4AZxLdP9ERBlwWLuh9bjvQRHAG8da gEKqBEWXSgqRQrAfjZulPpVgmrS9vhoWaE2fFnKnRmXUcebsClvlZ17OXt4iuwXp3DeL /AKBjz37zJSeQisooiGhqF9PCR5u8tLq3txq5whlmmN1FEpLCLH0XoM9SagwakXg0rtG aFfDxH2LtvY1F1MwKcwaZ+3h624VmkABQ3S/Pz20UtXsNSZS1njUVtv//Z0w7jiqW90U 4MBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=NqoG8p055aL2Gp+RgtmqQgtMEVFBecLP0ZC6032ILv8=; b=ygiI2AzAl7+u+pvyZOdnjxxcvDglb9k5Ty2CFLKZkvpCrvvnNncLcpweM48fFER2iY jkO1fqwqMceA/xeYmtb3ZY9/c8I/XT+NNQi6BCcG38/52cONRAONnYBVyFZNykcU+ZiW aNIRwu1ukmijIeEN7azKe8aXDwA09EhPPT/DRYOjYqoBd34K0753Q/oIRdEEZW8iJ4qP 07G7m6JVk/R2nApsHJHn8a4X6TNk0fEm/yqkhN8rEBTUVL7zQAHBXsAREMGFZX14hMGc Ps8KKI+Jupa8fPCQTUZ+z7fUM0DoxQEfrYKVA1NyKI0/mPBhvQyuUY7+UwPlC9TAfvAm kkBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j128si10178973pgc.122.2018.01.20.05.09.32; Sat, 20 Jan 2018 05:09:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754637AbeATNHG (ORCPT + 99 others); Sat, 20 Jan 2018 08:07:06 -0500 Received: from foss.arm.com ([217.140.101.70]:46754 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751130AbeATNG4 (ORCPT ); Sat, 20 Jan 2018 08:06:56 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 587F71435; Sat, 20 Jan 2018 05:06:56 -0800 (PST) Received: from why.wild-wind.fr.eu.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BBFB83F53D; Sat, 20 Jan 2018 05:06:53 -0800 (PST) Date: Sat, 20 Jan 2018 13:06:49 +0000 From: Marc Zyngier To: Paul Cercueil Cc: Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Thomas Gleixner , Jason Cooper , Daniel Lezcano , Lee Jones , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 6/9] irqchip: Add the ingenic-tcu-intc driver Message-ID: <20180120130649.7f326f75@why.wild-wind.fr.eu.org> In-Reply-To: <1515687945.2170.1@smtp.crapouillou.net> References: <20180101143344.2099-1-paul@crapouillou.net> <20180110224838.16711-1-paul@crapouillou.net> <20180110224838.16711-6-paul@crapouillou.net> <58349291-93cd-f803-52a9-f88120ace4dc@arm.com> <1515687945.2170.1@smtp.crapouillou.net> Organization: ARM Ltd X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 11 Jan 2018 17:25:45 +0100 Paul Cercueil wrote: > Hi Marc, > > >> +static int __init ingenic_tcu_intc_of_init(struct device_node > >> *node, > >> + struct device_node *parent) > >> +{ > >> + struct irq_domain *domain; > >> + struct irq_chip_generic *gc; > >> + struct irq_chip_type *ct; > >> + int err, i, num_parent_irqs; > >> + unsigned int parent_irqs[3]; > > > > 3 parent interrupts? Really? How do you pick one? Also, given the > > useage > > model below, "int" is the wrong type. Probably should be u32. > > See below. > > >> + struct regmap *map; > >> + > >> + num_parent_irqs = of_property_count_elems_of_size( > >> + node, "interrupts", 4); > > > > Nit: on a single line, as here is nothing that hurts my eyes more than > > reading something like( > > this). Also, 4 is better expressed as sizeof(u32). > > That will make checkpatch.pl unhappy :( And I don't care about checkpatch. I maintain the irqchip stuff, while checkpatch doesn't. Hence, I win. > > >> + if (num_parent_irqs < 0 || num_parent_irqs > > >> ARRAY_SIZE(parent_irqs)) > >> + return -EINVAL; > >> + > >> + map = syscon_node_to_regmap(node->parent); > >> + if (IS_ERR(map)) > >> + return PTR_ERR(map); > >> + > >> + domain = irq_domain_add_linear(node, 32, &irq_generic_chip_ops, > >> NULL); > >> + if (!domain) > >> + return -ENOMEM; > >> + > >> + err = irq_alloc_domain_generic_chips(domain, 32, 1, "TCU", > >> + handle_level_irq, 0, IRQ_NOPROBE | IRQ_LEVEL, 0); > >> + if (err) > >> + goto out_domain_remove; > >> + > >> + gc = irq_get_domain_generic_chip(domain, 0); > >> + ct = gc->chip_types; > >> + > >> + gc->wake_enabled = IRQ_MSK(32); > >> + gc->private = map; > >> + > >> + ct->regs.disable = TCU_REG_TMSR; > >> + ct->regs.enable = TCU_REG_TMCR; > >> + ct->regs.ack = TCU_REG_TFCR; > >> + ct->chip.irq_unmask = ingenic_tcu_gc_unmask_enable_reg; > >> + ct->chip.irq_mask = ingenic_tcu_gc_mask_disable_reg; > >> + ct->chip.irq_mask_ack = ingenic_tcu_gc_mask_disable_reg_and_ack; > >> + ct->chip.flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE; > >> + > >> + /* Mask all IRQs by default */ > >> + regmap_write(map, TCU_REG_TMSR, IRQ_MSK(32)); > >> + > >> + for (i = 0; i < num_parent_irqs; i++) { > >> + parent_irqs[i] = irq_of_parse_and_map(node, i); > >> + if (!parent_irqs[i]) { > >> + err = -EINVAL; > >> + goto out_unmap_irqs; > >> + } > >> + > >> + irq_set_chained_handler_and_data(parent_irqs[i], > >> + ingenic_tcu_intc_cascade, domain); > >> + } > > > > I don't get the multiple parent irq at all. How are the source > > interrupt routed to the various cascades? > > On JZ4740, channels 0 and 1 have their own interrupt, and channels > 2-7 share one interrupt line. > On JZ4770 and JZ4780, the OST (OS timer) channel has its own > interrupt, channel 5 has its own interrupt, and channels 0-4 and 6-7 > share one interrupt line. What a mess. I suppose you get a shared status register to find out which channel has fired? > To keep things simple, we register the same interrupt handler for the > three parent interrupts. Please add a comment to that effect, documenting the above HW blunder. Thanks, M. -- Without deviation from the norm, progress is not possible.