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. You're the patch author, it's your responsibility to know why you're adding/changing the code you're adding/changing. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
