From owner-freebsd-arm@FreeBSD.ORG Mon Jan 19 00:03:32 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 B77951E5 for ; Mon, 19 Jan 2015 00:03:32 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84D5C16C for ; Mon, 19 Jan 2015 00:03:32 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0J03Nja008085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jan 2015 16:03:24 -0800 Message-ID: <54BC49CB.4020504@freebsd.org> Date: Sun, 18 Jan 2015 16:03:23 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Turner Subject: Re: interrupt framework References: <54B7EB67.6010702@freebsd.org> <20150118203021.3ecac737@bender.lan> In-Reply-To: <20150118203021.3ecac737@bender.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVahz86XIyzgOvRbwj2pYEfCZnEIIbigagNX6htecY+wIZ8qOS/CiWGCa3i+fypYMHoraDC7KVmVn9dGpCl5q+vIZRfYxrkIniA= X-Sonic-ID: C;KLTalW6f5BGP6tmh1eMT4g== M;zLtHlm6f5BGP6tmh1eMT4g== X-Spam-Flag: No X-Sonic-Spam-Details: 1.2/5.0 by cerberusd 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: Mon, 19 Jan 2015 00:03:32 -0000 On 01/18/15 12:30, Andrew Turner wrote: > 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. Right, this was my point #2. I'd forgotten it is immediately necessary on ARM with ACPI as an option. > 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. I think that's a good idea. > 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. This is what we have been doing on PowerPC for years now. It hasn't caused more than minor annoyance. -Nathan > Andrew > > [1] https://people.freebsd.org/~andrew/rl_print_cb.diff >