subject:"\[PATCH 1\/2\] staging\: fsl\-mc\: Allocate IRQ's before scanning DPRC objects"

Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

2017-12-07 Thread Laurentiu Tudor



On 12/07/2017 03:18 PM, Nipun Gupta wrote:
>
>
>> -Original Message-
>> From: Laurentiu Tudor
>> Sent: Wednesday, December 06, 2017 19:00
>> To: Nipun Gupta <nipun.gu...@nxp.com>; stuyo...@gmail.com; Bharat
>> Bhushan <bharat.bhus...@nxp.com>; gre...@linuxfoundation.org;
>> cakt...@gmail.com; bretth...@gmail.com; a...@arndb.de
>> Cc: linux-ker...@vger.kernel.org; de...@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.

Thanks for the details. It would be great if you could update the commit 
message with these execution flow details.

>>
>>> 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.gu...@nxp.com>
>>> ---
>>>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.

It's not on my short term TODO.

---
Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

2017-12-07 Thread Nipun Gupta



> -Original Message-
> From: Laurentiu Tudor
> Sent: Wednesday, December 06, 2017 19:00
> To: Nipun Gupta <nipun.gu...@nxp.com>; stuyo...@gmail.com; Bharat
> Bhushan <bharat.bhus...@nxp.com>; gre...@linuxfoundation.org;
> cakt...@gmail.com; bretth...@gmail.com; a...@arndb.de
> Cc: linux-ker...@vger.kernel.org; de...@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 <nipun.gu...@nxp.com>
> > ---
> >   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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

2017-12-06 Thread Laurentiu Tudor

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.gu...@nxp.com>; stuyo...@gmail.com; Bharat
>> Bhushan <bharat.bhus...@nxp.com>; gre...@linuxfoundation.org;
>> cakt...@gmail.com; bretth...@gmail.com; a...@arndb.de
>> Cc: linux-ker...@vger.kernel.org; de...@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 <nipun.gu...@nxp.com>
>>> ---
>>>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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

2017-12-06 Thread Bharat Bhushan

Hi Laurentiu,

> -Original Message-
> From: Laurentiu Tudor
> Sent: Wednesday, December 06, 2017 7:00 PM
> To: Nipun Gupta <nipun.gu...@nxp.com>; stuyo...@gmail.com; Bharat
> Bhushan <bharat.bhus...@nxp.com>; gre...@linuxfoundation.org;
> cakt...@gmail.com; bretth...@gmail.com; a...@arndb.de
> Cc: linux-ker...@vger.kernel.org; de...@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 <nipun.gu...@nxp.com>
> > ---
> >   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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

2017-12-06 Thread Laurentiu Tudor

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.

---
Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

2017-12-06 Thread Nipun Gupta

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. 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
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.
  *
  * Detects objects added and removed from a DPRC and synchronizes the
  * state of the Linux bus driver, MC by adding and removing
@@ -228,6 +229,7 @@ static int dprc_scan_objects(struct fsl_mc_device 
*mc_bus_dev,
int error;
unsigned int irq_count = mc_bus_dev->obj_desc.irq_count;
struct fsl_mc_obj_desc *child_obj_desc_array = NULL;
+   struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_bus_dev);
 
error = dprc_get_obj_count(mc_bus_dev->mc_io,
   0,
@@ -297,7 +299,26 @@ static int dprc_scan_objects(struct fsl_mc_device 
*mc_bus_dev,
}
}
 
-   *total_irq_count = irq_count;
+   /*
+* Allocate IRQ's before scanning objects in DPRC as some devices like
+* DPIO needs them on being probed.
+*/
+   if (dev_get_msi_domain(_bus_dev->dev) && !mc_bus->irq_resources) {
+   if (irq_count > FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS) {
+   dev_warn(_bus_dev->dev,
+"IRQs needed (%u) exceed IRQs preallocated 
(%u)\n",
+irq_count, FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
+   }
+
+   error = fsl_mc_populate_irq_pool(mc_bus,
+   FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
+   if (error < 0)
+   return error;
+   }
+
+   if (total_irq_count)
+   *total_irq_count = irq_count;
+
dprc_remove_devices(mc_bus_dev, child_obj_desc_array,
num_child_objects);
 
@@ -322,7 +343,6 @@ static int dprc_scan_objects(struct fsl_mc_device 
*mc_bus_dev,
 static int dprc_scan_container(struct fsl_mc_device *mc_bus_dev)
 {
int error;
-   unsigned int irq_count;
struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_bus_dev);
 
fsl_mc_init_all_resource_pools(mc_bus_dev);
@@ -331,29 +351,14 @@ static int dprc_scan_container(struct fsl_mc_device 
*mc_bus_dev)
 * Discover objects in the DPRC:
 */
mutex_lock(_bus->scan_mutex);
-   error = dprc_scan_objects(mc_bus_dev, _count);
+   error = dprc_scan_objects(mc_bus_dev, NULL);
mutex_unlock(_bus->scan_mutex);
-   if (error < 0)
-   goto error;
-
-   if (dev_get_msi_domain(_bus_dev->dev) && !mc_bus->irq_resources) {
-   if (irq_count > FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS) {
-   dev_warn(_bus_dev->dev,
-"IRQs needed (%u) exceed IRQs preallocated 
(%u)\n",
-irq_count, FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
-   }
-
-   error = fsl_mc_populate_irq_pool(
-   mc_bus,
-   FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
-   if (error < 0)
-   goto error;
+   if (error < 0) {
+   fsl_mc_cleanup_all_resource_pools(mc_bus_dev);
+   return error;
}
 
return 0;
-error:
-   fsl_mc_cleanup_all_resource_pools(mc_bus_dev);
-   return error;
 }
 
 /**
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

RE: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

RE: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

Re: [PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

[PATCH 1/2] staging: fsl-mc: Allocate IRQ's before scanning DPRC objects

6 matches

Site Navigation

Mail list logo

Footer information