[PATCH] i2c-pxa: fix scheduling while atomic in i2c_pxa_abort()

[PATCH] i2c-pxa: fix scheduling while atomic in i2c_pxa_abort()

[Dmitry Baryshkov]

i2c_pxa_abort can be called from the atomic context.
Change it to use mdelay and counted loop.

Signed-off-by: Dmitry Baryshkov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/i2c/busses/i2c-pxa.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index dde6ce9..9a0f788 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -188,14 +188,14 @@ static inline int i2c_pxa_is_slavemode(struct pxa_i2c *i2c)
 
 static void i2c_pxa_abort(struct pxa_i2c *i2c)
 {
-	unsigned long timeout = jiffies + HZ/4;
+	int i = 250;
 
 	if (i2c_pxa_is_slavemode(i2c)) {
 		dev_dbg(&i2c->adap.dev, "%s: called in slave mode\n", __func__);
 		return;
 	}
 
-	while (time_before(jiffies, timeout) && (readl(_IBMR(i2c)) & 0x1) == 0) {
+	while ((i > 0) && (readl(_IBMR(i2c)) & 0x1) == 0) {
 		unsigned long icr = readl(_ICR(i2c));
 
 		icr &= ~ICR_START;
@@ -205,7 +205,8 @@ static void i2c_pxa_abort(struct pxa_i2c *i2c)
 
 		show_state(i2c);
 
-		msleep(1);
+		mdelay(1);
+		i --;
 	}
 
 	writel(readl(_ICR(i2c)) & ~(ICR_MA | ICR_START | ICR_STOP),
-- 
1.5.6.3


-- 
With best wishes
Dmitry


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: [PATCH] i2c-pxa: fix scheduling while atomic in i2c_pxa_abort()

[Ben Dooks]

On Tue, Aug 05, 2008 at 03:17:11PM +0400, Dmitry Baryshkov wrote:
> i2c_pxa_abort can be called from the atomic context.
> Change it to use mdelay and counted loop.

if this can be called from an atomic context, is there a distinct
possibility you are going to stop execution of the entire cpu for
the time it takes to sort this out? Is it possible to disable the
interrupt request, fire a work-struct to deal with this and then
re-enabled the controller once it is finished?
 
> Signed-off-by: Dmitry Baryshkov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/i2c/busses/i2c-pxa.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index dde6ce9..9a0f788 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -188,14 +188,14 @@ static inline int i2c_pxa_is_slavemode(struct pxa_i2c *i2c)
>  
>  static void i2c_pxa_abort(struct pxa_i2c *i2c)
>  {
> -	unsigned long timeout = jiffies + HZ/4;
> +	int i = 250;
>  
>  	if (i2c_pxa_is_slavemode(i2c)) {
>  		dev_dbg(&i2c->adap.dev, "%s: called in slave mode\n", __func__);
>  		return;
>  	}
>  
> -	while (time_before(jiffies, timeout) && (readl(_IBMR(i2c)) & 0x1) == 0) {
> +	while ((i > 0) && (readl(_IBMR(i2c)) & 0x1) == 0) {
>  		unsigned long icr = readl(_ICR(i2c));
>  
>  		icr &= ~ICR_START;
> @@ -205,7 +205,8 @@ static void i2c_pxa_abort(struct pxa_i2c *i2c)
>  
>  		show_state(i2c);
>  
> -		msleep(1);
> +		mdelay(1);
> +		i --;
>  	}
>  
>  	writel(readl(_ICR(i2c)) & ~(ICR_MA | ICR_START | ICR_STOP),
> -- 
> 1.5.6.3
> 
> 
> -- 
> With best wishes
> Dmitry
> 
> 
> _______________________________________________
> i2c mailing list
> i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: [PATCH] i2c-pxa: fix scheduling while atomic in i2c_pxa_abort()

[Dmitry Baryshkov]

Ben Dooks wrote:

> On Tue, Aug 05, 2008 at 03:17:11PM +0400, Dmitry Baryshkov wrote:
>> i2c_pxa_abort can be called from the atomic context. Change it to use
>> mdelay and counted loop.
> 
> if this can be called from an atomic context, is there a distinct
> possibility you are going to stop execution of the entire cpu for the
> time it takes to sort this out? Is it possible to disable the interrupt
> request, fire a work-struct to deal with this and then re-enabled the
> controller once it is finished?

If the bus isn't stalled by some hanged device, the reset will happen very
fast, so I don't see a reason to take that route.

However I'd implement the suggestion by Eric to choose mdelay or msleep
based on the atomicity of the context.

>  
>> Signed-off-by: Dmitry Baryshkov
>> <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>




-- 
With best wishes
Dmitry



_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c