Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932558AbdLGNS6 (ORCPT ); Thu, 7 Dec 2017 08:18:58 -0500 Received: from mail-ve1eur01on0052.outbound.protection.outlook.com ([104.47.1.52]:34177 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932478AbdLGNSx (ORCPT ); Thu, 7 Dec 2017 08:18:53 -0500 From: Nipun Gupta To: Laurentiu Tudor , "stuyoder@gmail.com" , Bharat Bhushan , "gregkh@linuxfoundation.org" , "cakturk@gmail.com" , "bretth256@gmail.com" , "arnd@arndb.de" CC: "linux-kernel@vger.kernel.org" , "devel@driverdev.osuosl.org" Subject: RE: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects Thread-Topic: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects Thread-Index: AQHTbnlsA973VZ3l8kKE77/CeeXYSaM2T8KAgAFzJtA= Date: Thu, 7 Dec 2017 13:18:48 +0000 Message-ID: References: <1512577087-5345-1-git-send-email-nipun.gupta@nxp.com> <5A27F0E2.6010403@nxp.com> In-Reply-To: <5A27F0E2.6010403@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nipun.gupta@nxp.com; x-originating-ip: [192.88.169.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;HE1PR0401MB2554;6:1KZdBlcgC81VMN4nk0GVmNv5TPuHIubtgwQ4DhKNxibTwRHSEHgX8Ozl5PaRImDxGoh3aFGspY92/gLmGz+h5dQM+d3EyVkhdVuRyPpHSBRFuwcP1CspnCyXOiu+cGW4JxUIjTqew7Sb0UdAutcoFlImyEFlrQHUvo2EsblFjqzyq5Oki64KXMknAGjgXYqmtXRvLYP8+gUGgbB0j60JpIfAMne5X9Qf/crPleD5yCzUkN7Po+ttVAbUuhkF4qxqF3eCiww5+nH1npNQeW8QDVbuchu3HsHu/VcAuoC8xLbLwfa2EjVdAtsn1X1QJfw1O/H72IrQuofIAwQDrb+jhavp5hyhy9zzQmKu3GlLOEs=;5:j6wquf4NFLXiBw/ezT4ZjBCThgbD8iH50yaW/c216nvkq7W/O7ua1Ul/9tvYBXY7oUAar+YqrWsay4rHWP/0ufu2WJ07RZypTe0PUU3GXnpoMhwPoHy/VKbqwG9oqewwLZkBEOpfXKsv//74lAqfAtyZs2Ht4LK/8axmsHQrT9A=;24:Vm3NhtG2W+F00rEwtxYtnXvYrvjgDnnKgGVSamjiimqmsSqEz1tg70/blzN+uMCB/YlE/vdAnWz384NOO8NXeUbpU1XZIDN2mBcgRkpEezQ=;7:HeArjO0c+VUFuV6TlmePa8fCRPY99IiuCmTHyXFh9jjvHJrc0LmLR9U02bDUrM+5D7w6lel6M9cgOVE3EpiOY6nHEjHBOZ+wGHLR3FUsc98xZvV9gkaKzGnGx18gVPvhrA83q8ZcXLhBstug6UE3ApXRvZpxnz7cTgYCJ7eX0pn9UY+q3sw8GTQ0Bamv8ozcdWM7LkjvxgrbM1eulRSGnWE7V95AZPl9edI8zJBfzhcrx9ZFQ2oaBUS4pISyfr8T x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI;SCL:-1;SFV:NSPM;SFS:(10009020)(39860400002)(346002)(366004)(376002)(24454002)(189003)(199004)(13464003)(86362001)(6116002)(3846002)(33656002)(66066001)(99286004)(305945005)(316002)(68736007)(478600001)(2900100001)(53546010)(5660300001)(229853002)(39060400002)(9686003)(102836003)(105586002)(6436002)(6506006)(101416001)(106356001)(2501003)(14454004)(7736002)(6246003)(81166006)(7696005)(2201001)(81156014)(8676002)(2950100002)(54906003)(25786009)(3280700002)(5250100002)(53936002)(74316002)(2906002)(3660700001)(55016002)(97736004)(76176011)(110136005)(8936002)(4326008);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0401MB2554;H:HE1PR0401MB2425.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; x-ms-office365-filtering-correlation-id: 427383e1-fe15-48b6-0f8f-08d53d750d7e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286);SRVR:HE1PR0401MB2554; x-ms-traffictypediagnostic: HE1PR0401MB2554: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(185117386973197)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011);SRVR:HE1PR0401MB2554;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:HE1PR0401MB2554; x-forefront-prvs: 05143A8241 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 427383e1-fe15-48b6-0f8f-08d53d750d7e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 13:18:48.7593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0401MB2554 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vB7DJQJF000586 Content-Length: 3353 Lines: 90 > -----Original Message----- > From: Laurentiu Tudor > Sent: Wednesday, December 06, 2017 19:00 > To: Nipun Gupta ; stuyoder@gmail.com; Bharat > Bhushan ; gregkh@linuxfoundation.org; > cakturk@gmail.com; bretth256@gmail.com; arnd@arndb.de > Cc: linux-kernel@vger.kernel.org; devel@driverdev.osuosl.org > Subject: Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC > objects > > Hi Nipun, > > Can you polish a bit this commit message? It doesn't seem to explain why > this is needed. Sure. Ill update the message. > > On 12/06/2017 06:18 PM, Nipun Gupta wrote: > > When DPRC probing is deferred (such as where IOMMU is not probed > > before the fsl-mc bus), all the devices in the DPRC containers gets > > initialized one after another. > > Are you referring to dprc probing being deferred (do we ever do that?) > or devices inside the dprc deferring the probe? Yes.. Currently following is the scenario when the devices are probed (please correct me if I am wrong): FSL_MC Bus probe ---> dprc probe ---> dprc devices scan ---> probe of devices in DPRC container ---> allocate IRQ's. In case the devices being probed in the DPRC container need the IRQ's; probing of that device will fail. In the current scenario DPIO device while getting probed for the first time gets deferred because the DPIO driver is not yet registered. So there is no impact seen in the current code. In case the DPRC probing gets deferred, does in case IOMMU is enabled (though it is not enabled till now for fsl-mc bus but we plan to add the support as soon as mc bus is out from staging); the DPIO gets probed before IRQ's being allocated. This causes DPIO probe to fail. So I think it makes sense that IRQ's are allocated before any devices In the DPRC container are probed. > > > As IRQ's were allocated only once the > > DPRC scanning is completed, the devices like DPIO which uses these > > IRQ's at initalization fails. This patch allocates the IRQ resources > > s/initalization/initialization > > > before scanning all the objects in the DPRC container. > > > > Signed-off-by: Nipun Gupta > > --- > > drivers/staging/fsl-mc/bus/dprc-driver.c | 49 ++++++++++++++++++------------ > -- > > 1 file changed, 27 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c b/drivers/staging/fsl- > mc/bus/dprc-driver.c > > index 06df528..7265431 100644 > > --- a/drivers/staging/fsl-mc/bus/dprc-driver.c > > +++ b/drivers/staging/fsl-mc/bus/dprc-driver.c > > @@ -206,7 +206,8 @@ static void dprc_add_new_devices(struct > fsl_mc_device *mc_bus_dev, > > * dprc_scan_objects - Discover objects in a DPRC > > * > > * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object > > - * @total_irq_count: total number of IRQs needed by objects in the DPRC. > > + * @total_irq_count: If argument is provided the function populates the > > + * total number of IRQs created by objects in the DPRC. > > As a side node, after a cursory look i noticed that this total_irq_count > parameter is used only for some sanity checks. I'm thinking of dropping > it in a follow-up cleanup patch. Do you plan to send it very recently. In that case I can rebase my patch on top of it. Regards, Nipun > > --- > Best Regards, Laurentiu