From owner-freebsd-arm@FreeBSD.ORG Sun Jan 18 20:30:36 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB458201; Sun, 18 Jan 2015 20:30:36 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4C1B2E; Sun, 18 Jan 2015 20:30:36 +0000 (UTC) Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 51C3D73000; Sun, 18 Jan 2015 20:30:34 +0000 (UTC) Date: Sun, 18 Jan 2015 20:30:21 +0000 From: Andrew Turner To: Nathan Whitehorn Subject: Re: interrupt framework Message-ID: <20150118203021.3ecac737@bender.lan> In-Reply-To: <54B7EB67.6010702@freebsd.org> References: <54B7EB67.6010702@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 20:30:36 -0000 On Thu, 15 Jan 2015 08:31:35 -0800 Nathan Whitehorn wrote: > On 01/15/15 05:51, Svatopluk Kraus wrote: ... > > It's a controller responsibility to save an ISRC associated with > > cells. An ISRC is transparent for any controller. However, an > > controller can set/get its data to/from an ISRC. Further, an > > controller should set a name to an ISRC according to internal > > representation of associated interrupt. > > I'm assuming you are referring to arm_describe_irq? I had three > comments on that: > 1. Can you please make it part of the same API as ofw_bus_map_irq() > rather than an out-of-band thing? This will let other platforms use > it. It should also not be ofw/fdt specific as it will be needed on platforms that don't use these, e.g. I expect there to be an option on arm64 to use ACPI so it could be possible to have a kernel without either of these enabled. Another problem is most drivers will already be using resource_list_print_type so may need to be modified to replace a call to this with a call to some new function. I have a proof of concept patch at [1] to instead rework how resource_list_print_type works by allowing us to change how various resource types are printed. It does this by having a function to register a callback to print the resource type. If no callback has been registered it will use the default. In the short term I expect we could import the interrupt change without changing how we print interupts. The values in dmesg may not line up with the actual interrupt, but this shouldn't hold back testing. Andrew [1] https://people.freebsd.org/~andrew/rl_print_cb.diff -- ABT Systems Ltd Unit 11, Hove Business Centre, Fonthill Road, Hove, BN3 6HA Registered in England and Wales, No. 9285513