[U-Boot] [PATCH v2 2/2] xilinx_xiic: Fix transfer initialisation

Melin Tomas tomas.melin at vaisala.com
Wed Jun 26 12:45:55 UTC 2019

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.




More information about the U-Boot mailing list