From owner-freebsd-arm@freebsd.org  Wed Jul 15 12:46:36 2015
Return-Path: <owner-freebsd-arm@freebsd.org>
Delivered-To: freebsd-arm@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 9BD689A2C2F
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Wed, 15 Jul 2015 12:46:36 +0000 (UTC)
 (envelope-from daemon-user@freebsd.org)
Received: from phabric-backend.isc.freebsd.org
 (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2])
 by mx1.freebsd.org (Postfix) with ESMTP id 84C5111E9
 for <freebsd-arm@freebsd.org>; Wed, 15 Jul 2015 12:46:36 +0000 (UTC)
 (envelope-from daemon-user@freebsd.org)
Received: by phabric-backend.isc.freebsd.org (Postfix, from userid 1346)
 id 81D5CE2EB; Wed, 15 Jul 2015 12:46:36 +0000 (UTC)
Date: Wed, 15 Jul 2015 12:46:36 +0000
To: freebsd-arm@freebsd.org
From: "andrew (Andrew Turner)" <phabric-noreply@FreeBSD.org>
Reply-to: D3034+327+45b7a5c19a24c07f@FreeBSD.org
Subject: [Differential] [Updated] D3034: Add BUS_UNMASK_INTR method
Message-ID: <626c4736eb20cb75e4f0b363bf302053@localhost.localdomain>
X-Priority: 3
Thread-Topic: D3034: Add BUS_UNMASK_INTR method
X-Herald-Rules: <28>, <31>, <32>, <34>
X-Phabricator-To: <PHID-USER-u7g3pamdppe4sw6i6zt6>
X-Phabricator-To: <PHID-USER-axkijn4pfdxlezgbnt7g>
X-Phabricator-To: <PHID-USER-q5lmute3rwskeizvu5gf>
X-Phabricator-To: <PHID-USER-yhwnadxnjthofqelhkdx>
X-Phabricator-To: <PHID-USER-6m5mo2kjikkzyd33ld4n>
X-Phabricator-To: <PHID-USER-pns6zgllnr6ze4h7ms3o>
X-Phabricator-Cc: <PHID-USER-xvjulcphpj66vffzpxft>
X-Phabricator-Cc: <PHID-USER-wjsgsqx4il4yblud7x6c>
X-Phabricator-Cc: <PHID-USER-ueipubl3jymguf56hiqy>
X-Phabricator-Cc: <PHID-USER-q5lmute3rwskeizvu5gf>
X-Phabricator-Cc: <PHID-USER-pns6zgllnr6ze4h7ms3o>
X-Phabricator-Cc: <PHID-USER-axkijn4pfdxlezgbnt7g>
In-Reply-To: <differential-rev-PHID-DREV-knxjlihey7dhpvtvtsyg-req@FreeBSD.org>
References: <differential-rev-PHID-DREV-knxjlihey7dhpvtvtsyg-req@FreeBSD.org>
Thread-Index: Njk5OTUyY2Q2NjQxNGE1MDJhNmZkNGQ3MjI0IFWmViw=
Precedence: bulk
X-Phabricator-Sent-This-Message: Yes
X-Mail-Transport-Agent: MetaMTA
X-Auto-Response-Suppress: All
X-Phabricator-Mail-Tags: <differential-reviewers>, <differential-comment>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.20
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2015 12:46:36 -0000

andrew added a comment.

I would like to see something like how Linux handles this. When they create interrupts they can mark them as per-core, i.e. they will be unmasked on all cores. I think we could do this with a new flag in `bus_setup_intr`.

Care would need to be taken to handle devices created both before and after we have enabled the secondary cpus as I would expect the code paths to be slightly different, e.g. before enabling we would need to record the need to unmask when new cpus are brought up, after enabling we will also need to signal to the other cpus to unmask the interrupt.


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D3034

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: wma_semihalf.com, emaste, imp, ian, zbb, andrew
Cc: onwahe-gmail-com, freebsd-arm-list, meloun-miracle-cz, imp, andrew, emaste