Re: [PATCH 1/1] Patch for I2C transmit overflow error

["shekhar, chandra" <x0044955@ti.com>]

----- Original Message ----- 
From: "Jason Marini" <jason.marini@gmail.com>
To: <linux-omap@vger.kernel.org>
Sent: Friday, January 09, 2009 6:49 PM
Subject: Re: [PATCH 1/1] Patch for I2C transmit overflow error


> >
>> ----- Original Message ----- From: "Jason Marini" <jason.marini@gmail.com>
>> To: <linux-omap@vger.kernel.org>
>> Sent: Wednesday, January 07, 2009 1:42 AM
>> Subject: Re: [PATCH 1/1] Patch for I2C transmit overflow error
>>
>>
>>>>> This patch is to fix I2C transmit overflow error.
>>>>> I guess it should fix the OSK5912 error. I dont have the board to test
>>>>> it.
>>>>
>>>> Yes, it makes those error reports go away. I'd say to merge this patch.
>>>
>>> Chandra, why would the transmit underflow (XDR) status sometimes be
>>> set at the same time as the XRDY status?
>>
>> I dint say XDR and XRDY.
>> Its XDR and XUDF being set simultaneously.
>> Why would you want to ignore
>>>
>>> XDR (using 'continue') if XRDY is set?
>>>
>>
>> So i am not ignoring any XDR.  :)
>
> Whoops, jet lag.  Let me try again.  What I meant to ask was:
>
> Why did you insert the 'continue' statements?  It seems as though a
> valid transmit underflow or receive overrun message may be skipped
> with this change.  Can you explain why the 'continue' statements are
> necessary?

A race condition arises where even xdr and xudf is simultaneously
generated. even if xdr is handled control used  to go to  xudf handler and we 
get the print and hence
error in return.  so it might happen that ur data is transferred
but u get error in return. in the aforementioned case simultaneous xdr and xudf 
were followed by xrdy.
If there is a genuine XUDF we will not get ardy.





>
> Sorry for the garbled original question.
>
> -Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>