From owner-svn-src-all@freebsd.org Tue Jun 7 15:38:45 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D41F8B6E94F; Tue, 7 Jun 2016 15:38:45 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEBA91B15; Tue, 7 Jun 2016 15:38:45 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-oi0-f48.google.com with SMTP id p204so87191493oih.3; Tue, 07 Jun 2016 08:38:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NkFdeKIM5H2NBndTzAL3vMznGQWtDUZ6G07TBw1QygU=; b=G1sM7ItFUIxbgIzSZJpXei/QhJ74Ar3wlHYCD1mIetPzMG4etNrJRogc5mK+h0PEOS 63COvqQU64mlH9aroP+o2Gdg58A95RQk/K3XzDYc44yE+dMlukAs6EmlVCr2SPprZNah NHWH36zWfTyawmxsdD54h3LJSkUdO69cG14Cp9wQTR1Ul2f4/R+gJCgpxB1sXJAk4XZL w4R0dyPwfnUX2E3wrG73nKNKAETIPmq0pBvNXBnfdwiQ6/q1d+BT3pr49JLRNNwsjaBc vMX8zFyhTugudew8JS7x8hi6TyyUtjnSgxAGuB/jVbjBNwlv/1FA90BxpOBaRGwDlg/9 yYCQ== X-Gm-Message-State: ALyK8tK8b5ODotqfUlGv495yXubrMm/OUgXMK+mshY2QiP5Y/zYejyZkZAaqKwOhb6B6JA== X-Received: by 10.157.49.40 with SMTP id e37mr59619otc.38.1465313611931; Tue, 07 Jun 2016 08:33:31 -0700 (PDT) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com. [209.85.214.47]) by smtp.gmail.com with ESMTPSA id j7sm7270254otc.13.2016.06.07.08.33.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 08:33:31 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id h62so30769941itb.1; Tue, 07 Jun 2016 08:33:31 -0700 (PDT) X-Received: by 10.36.16.67 with SMTP id 64mr570456ity.88.1465313611059; Tue, 07 Jun 2016 08:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.60.67 with HTTP; Tue, 7 Jun 2016 08:33:30 -0700 (PDT) In-Reply-To: <3626355.rfEWHPgmKy@ralph.baldwin.cx> References: <201606051607.u55G7vUg062390@repo.freebsd.org> <3626355.rfEWHPgmKy@ralph.baldwin.cx> From: Svatopluk Kraus Date: Tue, 7 Jun 2016 17:33:30 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r301451 - in head/sys: kern sys To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 15:38:45 -0000 On Mon, Jun 6, 2016 at 8:47 PM, John Baldwin wrote: > On Sunday, June 05, 2016 04:07:57 PM Svatopluk Kraus wrote: >> Author: skra >> Date: Sun Jun 5 16:07:57 2016 >> New Revision: 301451 >> URL: https://svnweb.freebsd.org/changeset/base/301451 >> >> Log: >> (1) Add a new bus method to get a mapping data for an interrupt. >> >> BUS_MAP_INTR() is used to get an interrupt mapping data according >> to provided hints. The hints could be modified afterwards, but only >> if mapping data was allocated. This method is intended to be called >> before BUS_ALLOC_RESOURCE(). >> >> An interrupt mapping data describes an interrupt - hardware number, >> type, configuration, cpu binding, and whatever is needed to setup it. >> >> (2) Introduce a method which allows storing of an additional data >> in struct resource to be available for bus drivers. This method is >> convenient in two ways: >> - there is no need to rework existing bus drivers as they can simply >> be extended to provide an additional data, >> - there is no need to modify any existing bus methods as struct >> resource is already passed to them as argument and thus stored data >> is simply accessible by other bus drivers. >> For now, implement this method only for INTRNG. >> >> This is motivated by needs of modern SOCs where hardware initialization >> is not straightforward and resources descriptions are complex, opaque >> for everyone but provider, and may vary from SOC to SOC. Typical >> situation is that one bus driver can fetch a resource description for >> its child device, but it's opaque for this driver. Another bus driver >> knows a provider for this kind of resource and can pass this resource >> description to it. In fact, something like device IVARS would be >> perfect for that if implemented generally enough. Unfortunatelly, IVARS >> are usable only by their owners now. Only owner knows its IVARS layout, >> thus other bus drivers are not able to use them. >> >> Differential Revision: https://reviews.freebsd.org/D6632 > > Does anything need to query this data besides the "nexus" or similar > driver at the top of bus_alloc_resource()? If so, I'd much rather do > this by having an optional args structure passed to bus_alloc_resource > that is extensible ala make_dev_s() and bus_map_resource(). Previously > I had mentioned passing this as part of bus_setup_intr() rather than > bus_alloc_resource(), but it would actually work better for ACPI if > we did it for bus_alloc_resource() instead. > > I guess my question is do you need access to this beyond the lifetime > of the call to bus_alloc_resource(). On x86 for example the state that > would needed to be passed up from ACPI (currently via bus_config_intr()) > is stored in the interrupt source structure, so it doesn't need to be > attached to the resource directly, it just needs to be passed up with it > so it can be saved in the interrupt source structure. > > -- > John Baldwin INTRNG was designed with the idea that a description of an interrupt belongs to a device, not to an interrupt itself. The very same interrupt may be used by more devices and each device should keep own description for this interrupt as these descriptions may differ - one can be GPIO like, another FDT like - one can demand binding to cpu0, another to cpu3 - and so on. In FDT case, it's regular as there are configurations for all possible devices in FDT blob, and it may be runtime choice which device will be used and you may even alternate these devices (meaning those which use the same interrupt). In the interrupt source structure (in a controller specific part) is then saved the info how an interrupt is really setup, and it's done in a controller native form. For example, when an interrupt is shared, two devices can be attached, both can allocate the same interrupt, but their configurations may differ. They can be setup at the same time, but also in rotation. Now, to answer your question. The interrupt mapping data is only needed in two situation for now. First, when a global scope interrupt number is looked up. It may be done during bus_alloc_resource() call. Second, when an interrupt is setup during bus_setup_intr(). When this data is saved in struct resource, it belongs to a device and can be used repeatedly during lifetime of this struct. And there is no need to modify any driver. Look also at r301539. An interrupt mapping data is saved in gpio_alloc_intr_resource(), so bus_setup_intr() can be used as is. Svatopluk Kraus