Hi Bharat, On 12/06/2017 04:03 PM, Bharat Bhushan wrote: > Hi Laurentiu, > >> -----Original Message----- >> From: Laurentiu Tudor >> Sent: Wednesday, December 06, 2017 7:00 PM >> To: Nipun Gupta <nipun.gupta@xxxxxxx>; stuyoder@xxxxxxxxx; Bharat >> Bhushan <bharat.bhushan@xxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx; >> cakturk@xxxxxxxxx; bretth256@xxxxxxxxx; arnd@xxxxxxxx >> Cc: linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxx >> 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 <nipun.gupta@xxxxxxx> >>> --- >>> 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 ? In the current implementation we allocate a pool of FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS (= 256) no mater what total_irq_count is. I think this is enough for our current scenarios, but if in the future we ever hit this limit we can think of a mechanism along the lines of your example. Adding another chunk of irqs to the pool seems to me like a good idea in the future. --- Best Regards, Laurentiu _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
