----- Original Message -----
From: "Jason Marini" <jason.marini@xxxxxxxxx>
To: <linux-omap@xxxxxxxxxxxxxxx>
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@xxxxxxxxx>
To: <linux-omap@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
