On 6/26/19 3:19 PM, Melin Tomas wrote:
On 6/26/19 3:48 PM, Marek Vasut wrote:
On 6/26/19 2:45 PM, Melin Tomas wrote:
On 6/26/19 3:26 PM, Marek Vasut wrote:
On 6/26/19 2:19 PM, Melin Tomas wrote:
On 6/26/19 2:49 PM, Marek Vasut wrote:
On 6/26/19 1:25 PM, Melin Tomas wrote: > On 6/26/19 1:47 PM, Marek Vasut wrote: > >> On 6/26/19 12:39 PM, Melin Tomas wrote: >> >>> As such, it's probably a good idea to keep the same delay values here as >>> in the original driver unless good reason to use something else. >>> >>> As what goes for the original reasoning for 3ms, the commit history does >>> not mention that so I cannot comment. >> So would you be so kind and research this ? > Based on a short study of other i2c bus drivers it seems most have bus > busy timeout checks. > > The timeout values seems to differ, ranging from milliseconds to seconds. Yep
> So probably it's just a number, after all it's just a check to know if > we are good to go. And is the number large enough ?
As mentioned, good approach is probably using value known to work instead of
guessing a new number.
So why did kernel pick that specific number ? Surely there was some reasoning, they didn't just pull it out of /dev/random .
Yes, history does not tell.
I do see that this driver uses timeout of 1000ms for bus busy when probing, perhaps you can enlighten how that number was concluded? If that could give some clues about this.
I don't know.
But you are author of that line?
+ ret = wait_for_bit_8(priv->base + XIIC_SR_REG_OFFSET, + XIIC_SR_BUS_BUSY_MASK, false, 3, true); +
comes from 2/2 ?
You're the patch author, it's your responsibility to know why you're adding/changing the code you're adding/changing.
yes, and the reasoning is:
- the value has been deemed good in original driver. If it would be bad,
probably it would have been changed during course of time
- the value has been tested for this driver as well with success
So shouldn't there be some upper bound on the bus busy time , demanded either by the i2c bus spec or the xiic core spec ?