Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932362AbVKFXfy (ORCPT ); Sun, 6 Nov 2005 18:35:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932365AbVKFXfy (ORCPT ); Sun, 6 Nov 2005 18:35:54 -0500 Received: from gate.crashing.org ([63.228.1.57]:743 "EHLO gate.crashing.org") by vger.kernel.org with ESMTP id S932362AbVKFXfx (ORCPT ); Sun, 6 Nov 2005 18:35:53 -0500 Subject: Re: Fwd: [RFC] IRQ type flags From: Benjamin Herrenschmidt To: Russell King Cc: Alan Cox , Linux Kernel List , Andrew Morton In-Reply-To: <20051106224225.GC6274@flint.arm.linux.org.uk> References: <20051106084012.GB25134@flint.arm.linux.org.uk> <1131316897.1212.61.camel@localhost.localdomain> <20051106221643.GB6274@flint.arm.linux.org.uk> <1131317998.1212.63.camel@localhost.localdomain> <20051106224225.GC6274@flint.arm.linux.org.uk> Content-Type: text/plain Date: Mon, 07 Nov 2005 10:33:00 +1100 Message-Id: <1131319980.5229.119.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1955 Lines: 45 > Good question - I'm not sure currently. In the places where set_irq_type > is used on ARM, we're mainly interested in setting the input according > to rising/falling edge or high/low levels rather than switching between > edge and level mode. > > We could do as you suggest, but my concern would be adding extra > complexity to drivers, causing them to do something like: > > ret = request_irq(..., SA_TRIGGER_HIGH, ...); > if (ret == -E) > ret = request_irq(..., SA_TRIGGER_RISING, ...); > > The alternative is: > > ret = request_irq(..., SA_TRIGGER_HIGH | SA_TRIGGER_RISING, ...); > > at which point the driver is telling the IRQ layer what it can support, > and allowing the IRQ layer to select the most appropriate type given > the driver and hardware constraints. We have similar things on ppc but dealt differently. The type of interrupt sense supported depends on the PIC (and you can have more than one PIC around). On Open Firmware based machines at least, the device-tree tells us the sense setting to use on all devices in the system, we program our PIC based on that information. Your proposal though is interesting as it would allow individual to override that setting (it may be broken, firmware occasionally are), and would probably be useful for embedded PPCs as well. However, I would suggest defining the absence of explicit trigger (0) as a constant rather than 0 (SA_TRIGGER_DEFAULT), just for consistency.That means using whatever the platform considers as a good default for this interrupt. In addition, I would still add a get_irq_trigger() function for a driver to enquire the kind of sense that was set by default by the platfrom for a given irq line. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/