Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752078AbdLFODQ (ORCPT ); Wed, 6 Dec 2017 09:03:16 -0500 Received: from mail-he1eur01on0063.outbound.protection.outlook.com ([104.47.0.63]:40838 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751544AbdLFODK (ORCPT ); Wed, 6 Dec 2017 09:03:10 -0500 From: Bharat Bhushan To: Laurentiu Tudor , Nipun Gupta , "stuyoder@gmail.com" , "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: AQHTbnls+b3xKjWnSU68afFRHuZqXqM2T8KAgAAHZaA= Date: Wed, 6 Dec 2017 14:03:04 +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=bharat.bhushan@nxp.com; x-originating-ip: [223.190.55.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0401MB2431;6:1j1hAzaAPbFj2WNa7qdQVn+2c5mXQoj05mlaE35GLUEZqxf6qGVuYGYZPfW83CMUBeJ5vTcsumCfxrM+s8VmlICREtAr1IEdPU+nXQCKRUanHtT4YUZQ79gRlwdCKTL2c5IJckfUV6bnDLTg3cEbNeWCrKjjjZs/3ZikUsOLM8I/3CfrWC0dTiJgULJIWWBVdrHe7bfhQdUmpsUcWPKO30hvkbkreXQt7xeiAAKT5rS6oqd7qDpCN4VyI1/0vNzJC59xhFAUQ2WWPGpblM0e+qiBHR4OFq9GdPfKAxRbFpjS7nm67MxCkT+G6gmqFpWz4tyc4J7sIPOLcXfRNE+1Z/crfJECYzCtZEnbOoAmN9s=;5:FWRZ0zRKNnG0hfxstxyhTz5SmXhEVZrftzm2HMFkNjj1pSgdeE4r8Ai6SE03UqYB7b0CmP9f3CI52ckqbplwqDDdHADPU/OV4a4/y4fmZ5Xd6KmG22koNF2+uEtpEwsKPbKat5EhuunTaz0yeUHj564eazX1O+knAHDxB60PYZU=;24:UkvVe2Siu3/HthR2LXm+9oaQUei7BAza3uPB8BQUvqBf+1OrKNREDEPNQpaLYK2dc2Is1UYPZWaIXDQiOgAkp416mDhH1xkn27qm85iP360=;7:pqUqjSfoWhHJSzuMdjhbt1am+hPby06wjA6/jAmZMUCezHdteyJlGQiVsA7IVCM8Q9y2zPiYDaW1rujZhN5DNetmB9gwOSnVFqQbTxFzrFNEZgYDqPZhePljXkVxjnv7DJskEjbKg5l230KFAJlUHbTfuhKyk1UPgJ7nW1YAEcqp34ZAZ85Zo8CnLQCx5juGF9Uqtq06M7388VI9DAlON2oZkzorvIF7/3T7dpKPtbK/NRdIKF6PnNoBMI9CWznk x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI;SCL:-1;SFV:NSPM;SFS:(10009020)(376002)(39860400002)(346002)(366004)(13464003)(199004)(189003)(24454002)(102836003)(3846002)(53546010)(6116002)(8936002)(229853002)(55016002)(9686003)(6506006)(25786009)(6436002)(2501003)(101416001)(33656002)(53936002)(106356001)(66066001)(316002)(68736007)(74316002)(105586002)(305945005)(7736002)(54906003)(8676002)(81166006)(81156014)(478600001)(14454004)(5250100002)(110136005)(97736004)(76176011)(7696005)(86362001)(2900100001)(2201001)(99286004)(2950100002)(3660700001)(3280700002)(2906002)(4326008)(39060400002)(6246003)(5660300001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB2431;H:AM5PR0401MB2545.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2aa928ba-de3c-45ca-8d42-08d53cb2122d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(48565401081)(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286);SRVR:VI1PR0401MB2431; x-ms-traffictypediagnostic: VI1PR0401MB2431: 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)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011);SRVR:VI1PR0401MB2431;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:VI1PR0401MB2431; x-forefront-prvs: 05134F8B4F 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: 2aa928ba-de3c-45ca-8d42-08d53cb2122d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 14:03:04.9144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2431 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 vB6E3Jt5013064 Content-Length: 2543 Lines: 68 Hi Laurentiu, > -----Original Message----- > From: Laurentiu Tudor > Sent: Wednesday, December 06, 2017 7:00 PM > 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. > > 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? > > > 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. How you will ensure that number of IRQ needed are not sufficient for devices in the container? Do you think we need to either not enable additional devices or add irqs to irq-pool ? Thanks -Bharat > > --- > Best Regards, Laurentiu